Servicios integrados ( inglés Integrated services, IntServ ): en redes informáticas , una arquitectura de gestión de recursos que proporciona una determinada calidad de servicio ( QoS ). El método utilizado por los servicios integrados requiere una arquitectura de protocolo que es difícil de escalar. El problema de la escalabilidad está relacionado con el principio de funcionamiento de los servicios integrados, durante el cual se realiza la reserva de recursos de extremo a extremo en todos los elementos que componen la capa de red de la aplicación.
El notable crecimiento de Internet ha provocado un aumento significativo del tráfico. La aparición de nuevos tipos de aplicaciones, como aplicaciones web, video en tiempo real, telefonía IP y muchas otras, ha obligado a los especialistas a buscar nuevas formas de controlar el tráfico de la red. Una de las decisiones recientes fue el uso de servicios integrados que combinan todas las soluciones propuestas.
Los protocolos estándar de la pila TCP/IP brindan servicio en la medida de lo posible y dan la misma prioridad a todas las solicitudes. Al transportar tráfico de medios de transmisión (VoIP, audio y videoconferencia, y otros) o tráfico de datos con diferentes requisitos de ancho de banda sobre la misma red, es necesario poder procesar y clasificar diferentes tipos de tráfico de red, ya sea según los requisitos o contenido La entrega no garantizada no implicaba ninguna diferenciación de tráfico y no proporcionaba una entrega confiable, capacidad de canal garantizada o baja pérdida de paquetes.
Para resolver todos los problemas anteriores de entrega no garantizada, se crearon los siguientes dos modelos de calidad de servicio [1] :
Antes de revelar este tema, vale la pena definir el concepto de flujo . Entenderemos por "flujo" el tráfico continuo generado por un usuario o aplicación y que requiere la misma calidad de servicio. En la versión IPv4 , el flujo se determina en la capa de transporte del protocolo que se está utilizando (ya sea TCP o UDP ) a través de los puertos y direcciones IP de origen y destino. La versión IPv6 también tiene un campo especialmente creado para esta función que, junto con sus direcciones de origen y destino, caracteriza el flujo. Este campo se denomina etiqueta de flujo.
En el marco del modelo de servicios integrados, se pueden distinguir los siguientes subsistemas importantes [1] :
Como se mencionó anteriormente, antes de enviar información a través de la red, se reservan recursos de acuerdo con la calidad de servicio requerida. Al dar servicio a un nuevo flujo, se realiza el enunciado de los requisitos de calidad de servicio (por especificación de solicitud de servicio - RSPEC ) y se obtienen las características del tráfico que debe enviarse a través de la red (por especificación de tráfico - TSPEC ). Si el enrutador no tiene suficientes recursos libres para dar servicio a un nuevo flujo, dicho flujo será rechazado. Si se pueden satisfacer los requisitos del nuevo flujo, el enrutador indica al programador y al clasificador de paquetes que reserven una parte de sus recursos para brindar la calidad de servicio requerida para este flujo.
En RSPEC, se pueden distinguir las siguientes categorías de servicios de flujo:
RSPEC y TSPEC son proporcionados por el protocolo de reserva de recursos de red RSVP .
El clasificador de paquetes identifica los paquetes de flujo en los enrutadores. Cada paquete entrante pertenece a una determinada clase. Al estar divididos en clases, los paquetes reciben el mismo procesamiento para su clase del planificador de paquetes. La elección de una clase específica depende de las prioridades del remitente y el destinatario, la dirección IP y el número de puerto en el encabezado del paquete. Por regla general, los hilos del mismo tipo pertenecen a la misma clase.
El planificador de paquetes, utilizando el sistema de gestión de colas, regula el envío de paquetes a los enrutadores de acuerdo con la clasificación mencionada anteriormente y los parámetros de calidad de servicio especificados para cada flujo. El programador de paquetes debe funcionar en el punto donde los paquetes están en cola. Este punto suele ser los protocolos de capa de enlace en el sistema operativo del enrutador.
Para evitar interrupciones en la red, se proporciona control de congestión. Existen tres métodos para implementar el control de congestión mediante la exclusión de paquetes:
RSVP , o Protocolo de reserva de recursos, es un protocolo de marcado que permite a los usuarios comunicar sus requisitos de confiabilidad y eficiencia a la red. A pesar de que RSVP es un protocolo simplex, es decir, la redundancia ocurre en una sola dirección, fue concebido para conexiones dúplex. Para una conexión dúplex, como una conferencia de audio o video, donde cada parte es tanto un remitente como un receptor, ambos puntos finales envían una solicitud de reserva de recursos a RSVP.
En el marco del protocolo RSVP, se utiliza el concepto de " ruta " ( ing. PATH ). Una ruta es la ruta que toman los paquetes a través de varios enrutadores desde el remitente hasta el destino. A lo largo de esta ruta se realizan reservas de recursos. Todos los paquetes del mismo flujo seguirán el mismo camino. La ruta se determina cuando el remitente envía un mensaje RSVP, el llamado mensaje de ruta. Contiene información sobre la calidad de servicio del tráfico para un flujo determinado. Debido a que RSVP no es un protocolo de enrutamiento, utiliza información de las tablas de enrutamiento de cada enrutador para entregar el mensaje de la ruta lo antes posible [1] .
El formato del mensaje PATH es el siguiente (los datos entre corchetes son opcionales):
Encabezado común, [Integridad], Sesión, RSVP_Hop, Valores de tiempo, [Policy_Data], Plantilla de remitente, Sender_Tspec, [ADSPEC]Después de recibir el mensaje de ruta, los enrutadores están listos para reservar recursos para el flujo. Para reservar ciertos parámetros de QoS , el receptor envía un mensaje RESV . Cada dispositivo que admite el protocolo RSVP ya conoce la dirección del dispositivo anterior a lo largo de la ruta, por lo que el mensaje RESV viaja de regreso al remitente y le dice a los enrutadores de tránsito los parámetros necesarios para reservar recursos.
El formato del mensaje RESV es el siguiente:
Encabezado común, [Integridad], Sesión, RSVP_Hop, Valores de tiempo, [Reso_Confirm], [Ámbito], Estilo, Lista de descriptores de flujoAlgunas aclaraciones:
Cabe señalar que este método de reserva de recursos solo es posible si todos los margrutizadores a lo largo de la ruta admiten el protocolo RSVP. En ausencia de compatibilidad con RSVP, un enrutador intermedio puede o no cumplir con los requisitos de QoS, según su carga. La especificación completa del protocolo RSVP se define en RFC-2205.
Aunque la idea de IntServ y RSVP era muy prometedora a mediados de la década de 1990, el interés por esta arquitectura se desvaneció con el tiempo. La razón principal fue el problema de escalabilidad causado por la necesidad de almacenar y mantener la información del estado de transmisión en cada enrutador. Este problema, trasladado a WAN como Internet, aleja a RSVP de la realidad. Sin embargo, recientemente se ha vuelto a hablar de utilizar RSVP en MPLS o en ingeniería de transporte, ya que en estos casos el valor del tráfico es pequeño, lo que lo hace más manejable y reduce el coste de los equipos.