Protocolo de reserva de recursos , la enciclopedia libre

El protocolo de reserva de recursos (RSVP o Resource Reservation Protocol), descrito en RFC 2205, es un protocolo de la capa de transporte diseñado para reservar recursos de una red bajo la arquitectura de servicios integrados (IntServ). "RSVP no es una aplicación de transporte, es más bien un protocolo de control de internet, como ICMP, IGMP, o protocolos de enrutamiento" - RFC 2205. RSVP reserva los canales o rutas en redes internet para la transmisión por unidifusión y multidifusión con escalabilidad y robustez.

RSVP puede ser utilizado tanto por hosts como por enrutadores para pedir o entregar niveles específicos de calidad de servicio (QoS) para los flujos de datos de las aplicaciones. RSVP define cómo deben hacer las reservas las aplicaciones y cómo liberar los recursos reservados una vez que han terminado. Las operaciones RSVP generalmente dan como resultado una reserva de recursos en cada nodo a lo largo de un camino.

RSVP no es en sí mismo un protocolo de encaminamiento y fue diseñado para interoperar con los actuales y futuros protocolos de encaminamiento.

RSVP por sí mismo rara vez es desplegado en redes de telecomunicaciones hoy en día pero para RSVP-TE, está comenzando a aceptarse de forma más común en muchas redes con QoS.

Atributos principales

A continuación se describen los atributos principales del protocolo:

RSVP pide recursos para los flujos simplex: un flujo de tráfico en una sola dirección desde el emisor a uno o más receptores.
RSVP no es un protocolo de encaminamiento, pero trabaja con protocolos de enrutamiento actuales y futuros.
RSVP está orientada hacia el receptor: es el receptor de un flujo de datos el que inicia y mantiene la reserva de recursos para ese flujo.
RSVP es soft state (la reserva en cada nodo necesita refresco periódico), mantiene solo temporalmente el estado de las reservas de recursos del host y de los enrutadores, de aquí que soporte cambios dinámicos de la red.
RSVP proporciona varios estilos de reserva (un conjunto de opciones) y permite que se añadan futuros estilos al protocolo para permitirle adaptarse a diversas aplicaciones.
RSVP transporta y mantiene parámetros del tráfico y de la política de control que son opacos a RSVP.

Historia

RSVP se describe en una serie de documentos RFC (Request For Comments) de la IETF:

RFC 2205: La versión 1 especificación funcional se ha descrito en el RFC 2205 (septiembre de 1997) por el IETF. La versión 1 describe la interfaz de admisión de control de tráfico que se basa "únicamente" en la disponibilidad de recursos. Más tarde la RFC2750 extendió el soporte del control de admisión.

RFC 2210: RFC 2210 define el uso de RSVP con los servicios de control de QoS de carga-controlada; RFC 2211 y garantizada; RFC 2212. Más detalles en Servicios Integrados. También se define el formato y el modo de uso de los datos de los objetos (que transportan la información de reserva de recursos) definido por RSVP en el RFC 2205.

RFC 2211: RFC 2211 especifica el comportamiento de los elementos de red necesarios para prestar los servicios de carga-controlada.

RFC 2212: RFC 2212 especifica el comportamiento de los elementos de red necesarios para prestar los servicios de QoS garantizada.

RFC 2750: RFC 2750 describe una extensión propuesta para el soporte de políticas genéricas de control de admisión en RSVP. La extensión incluye una especificación de los objetos de la política y una descripción del manejos de eventos de política (enero de 2000).

RFC 3936: RFC 3936 describe las mejores prácticas actuales, y detalla los procedimientos de modificación de la RSVP (octubre de 2004).

RFC 4495: (mayo de 2006).

Conceptos clave

Los dos conceptos clave del modelo RSVP son flowspec y filterspec:

Flowspec

RSVP reserva recursos para un flujo. Un flujo se identifica por la dirección de destino, el protocolo de identificación y, opcionalmente, el puerto de destino. En MPLS una corriente se define como un LSP. Para cada flujo RSVP también identifica a la particular calidad de los servicios requeridos por la corriente a pesar de que no entiende la información específica de la corriente QoS. Esos sistemas luego analizan el flowspec para aceptar y reservar los recursos. Un flowspec consta de:

Servicio de clase
Reserva de especificaciones -define la QoS
Tráfico de especificaciones - describe el flujo de datos

Filterspec

Filterspec define el conjunto de paquetes que serán afectados por un flowspec (es decir, los paquetes de datos para recibir la QoS definida por el flowspec). Un filerspec típicamente selecciona un subconjunto de todos los paquetes procesados por un nodo. La elección puede depender de cualquier atributo de un paquete (por ejemplo, la dirección IP del remitente y el puerto).

Los definidos en la actualidad son los estilos de reserva RSVP:

Filtro fijo - reserva de recursos para un determinado flujo.
Compartidas explícita - se reserva para varios flujos de recursos y compartir todos los recursos.
Filtro comodín - reservas de recursos para un tipo general de la corriente sin especificar el flujo

Una solicitud de reserva RSVP consiste en un flowspec y un filterspec y el par se llama flowdescriptor. Los efectos en la especificación de cada nodo, si bien el flowspec establece los parámetros de la bolsa en un nodo, la filterspec establece los parámetros en el clasificador de paquetes.

Mensajes

Hay dos tipos principales de mensajes:

Ruta de los mensajes (path)

La ruta de los mensajes es enviada por el remitente de acogida a lo largo de la ruta de datos y almacena la ruta estatal en cada nodo a lo largo de la ruta.

La ruta estatal incluye la dirección IP del nodo anterior, y algunos objetos de datos:

Plantilla remitente para describir el formato de los datos de remitente.
Tspec remitente para describir las características de tráfico del flujo de datos.
Adspec que lleva la publicidad de datos (véase el RFC 2210 para más detalles).

Reserva de mensajes (resv)

La reserva de mensajes se envía desde el receptor al remitente de acogida a lo largo de la ruta inversa de datos.

La reserva de mensajes incluye el flowspec objeto de datos que identifica los recursos del flujo de necesidades.

Los datos sobre los mensajes RSVP se pueden transmitir en cualquier orden. Para la lista completa de los mensajes RSVP y fecha objetos consulte RFC 2205.

Operaciones

Es necesario que una acogida envie un flujo de datos específicos con QoS transmitirá a RSVP una vía mensaje que viajará a lo largo de las rutas de unidifusión y multidifusión previamente establecido por el protocolo de enrutamiento de trabajo. Si la ruta mensaje llega a un router que no entiende RSVP, el router envía el mensaje sin interpretar el contenido del mensaje y la no reserva de los recursos para la corriente.

Cuando el destino router recibe el camino mensaje:

Hacer una reserva sobre la base de parámetros de la petición. Para este control de la admisión y las políticas de control de parámetros de proceso de la solicitud puede encargar el clasificador de paquetes para manejar correctamente el subconjunto seleccionado de paquetes de datos o de negociar con la capa superior de la forma en que el paquete de manejo se debe realizar.
Adelante la solicitud aguas arriba (en la dirección del remitente). En cada nodo de la resv mensaje, flowspec puede ser modificado por un nodo de transmisión.

Cada nodo en el camino puede aceptar o rechazar la petición.

Modo de operación de RSVP

Enlaces externos

RFCs

Datos: Q640435