stringtranslate.com

Protocolo de reserva de recursos

El Protocolo de reserva de recursos ( RSVP ) es un protocolo de capa de transporte [1] diseñado para reservar recursos a través de una red utilizando el modelo de servicios integrados . RSVP opera sobre IPv4 o IPv6 y proporciona una configuración iniciada por el receptor de reservas de recursos para flujos de datos de multidifusión o unidifusión . No transporta datos de aplicaciones, pero es similar a un protocolo de control, como el Protocolo de mensajes de control de Internet (ICMP) o el Protocolo de administración de grupos de Internet (IGMP). La confirmación de asistencia se describe en RFC  2205.

Los hosts y enrutadores pueden utilizar RSVP para solicitar o entregar niveles específicos de calidad de servicio (QoS) para flujos de datos de aplicaciones . RSVP define cómo las aplicaciones realizan reservas y cómo pueden renunciar a los recursos reservados una vez que ya no sean necesarios. Las operaciones de confirmación de asistencia generalmente darán como resultado que se reserven recursos en cada nodo a lo largo de una ruta. RSVP no es un protocolo de enrutamiento , pero fue diseñado para interoperar con protocolos de enrutamiento actuales y futuros.

En 2003, el esfuerzo de desarrollo se trasladó de RSVP a RSVP-TE para ingeniería de teletráfico . Next Steps in Signalling (NSIS) fue un reemplazo propuesto para RSVP.

Atributos principales

  1. RSVP solicita recursos para flujos simplex : un flujo de tráfico en una sola dirección desde el remitente a uno o más receptores.
  2. RSVP no es un protocolo de enrutamiento pero funciona con protocolos de enrutamiento actuales y futuros.
  3. RSVP está orientado al receptor en el sentido de que el receptor de un flujo de datos inicia y mantiene la reserva de recursos para ese flujo.
  4. RSVP mantiene el estado suave (la reserva en cada nodo necesita una actualización periódica) de las reservas de recursos del host y de los enrutadores, por lo que admite la adaptación automática dinámica a los cambios de la red.
  5. RSVP proporciona varios estilos de reserva (un conjunto de opciones de reserva) y permite agregar estilos futuros en revisiones de protocolo para adaptarse a diversas aplicaciones.
  6. RSVP transporta y mantiene parámetros de control de políticas y tráfico que son opacos para RSVP. [ Se necesita más explicación ]

Historia y estándares relacionados.

Los conceptos básicos de RSVP se propusieron originalmente en 1993. [2]

RSVP se describe en una serie de documentos RFC del IETF:

Conceptos clave

Los dos conceptos clave del modelo de reserva RSVP son flowspec y filterspec .

Especificaciones de flujo

RSVP reserva recursos para un flujo. Un flujo se identifica por la dirección de destino, el identificador de protocolo y, opcionalmente, el puerto de destino. En la conmutación de etiquetas multiprotocolo (MPLS), un flujo se define como una ruta de conmutación de etiquetas (LSP). Para cada flujo, RSVP también identifica la calidad de servicio (QoS) particular requerida por el flujo. Esta información de QoS se denomina especificación de flujo y RSVP pasa la especificación de flujo desde la aplicación a los hosts y enrutadores a lo largo de la ruta. Luego, esos sistemas analizan la especificación de flujo para aceptar y reservar los recursos. Una especificación de flujo consta de:

  1. Clase de servicio
  2. Especificación de reserva: define la QoS
  3. Especificaciones de tráfico: describe el flujo de datos.

Especificaciones del filtro

La especificación de filtro define el conjunto de paquetes que se verán afectados por una especificación de flujo (es decir, los paquetes de datos para recibir la QoS definida por la especificación de flujo). Una especificación de filtro normalmente selecciona un subconjunto de todos los paquetes procesados ​​por un nodo. La selección puede depender de cualquier atributo de un paquete (por ejemplo, la dirección IP y el puerto del remitente).

Los estilos de reserva de confirmación de asistencia definidos actualmente son:

  1. Filtro fijo: reserva recursos para un flujo específico.
  2. Explícito compartido: reserva recursos para varios flujos y todos comparten los recursos
  3. Filtro comodín: reserva recursos para un tipo general de flujo sin especificar el flujo; todos los flujos comparten los recursos

Una solicitud de reserva de RSVP consta de una especificación de flujo y una especificación de filtro , y el par se denomina descriptor de flujo . La especificación de flujo establece los parámetros del programador de paquetes en un nodo y la especificación de filtro establece los parámetros en el clasificador de paquetes.

Mensajes

Hay dos tipos principales de mensajes:

El mensaje de ruta se envía desde el host del remitente a lo largo de la ruta de datos y almacena el estado de la ruta en cada nodo a lo largo de la ruta.
El estado de la ruta incluye la dirección IP del nodo anterior y algunos objetos de datos:
  1. Plantilla de remitente para describir el formato de los datos del remitente en forma de Filterspec [3]
  2. remitente tspec para describir las características del tráfico del flujo de datos
  3. adspec que transporta datos publicitarios (consulte RFC 2210 para obtener más detalles).
El mensaje resv se envía desde el receptor al host del remitente a lo largo de la ruta de datos inversa. En cada nodo, la dirección IP de destino del mensaje resv cambiará a la dirección del siguiente nodo en la ruta inversa y la dirección IP de origen a la dirección del nodo anterior en la ruta inversa.
El mensaje resv incluye el objeto de datos flowspec que identifica los recursos que necesita el flujo.

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

Operación

Un host RSVP que necesita enviar un flujo de datos con QoS específica transmitirá un mensaje de ruta RSVP cada 30 segundos que viajará a lo largo de las rutas unidifusión o multidifusión preestablecidas por el protocolo de enrutamiento en funcionamiento. Si el mensaje de ruta llega a un enrutador que no entiende RSVP, ese enrutador reenvía el mensaje sin interpretar el contenido del mensaje y no reservará recursos para el flujo.

Aquellos que quieran escucharlos envían el correspondiente mensaje resv (abreviatura de reserva ) que luego rastrea el camino de regreso al remitente. El mensaje resv contiene una especificación de flujo . El mensaje resv también tiene un objeto filterspec ; define los paquetes que recibirán la QoS solicitada definida en la especificación de flujo. Una especificación de filtro simple podría ser simplemente la dirección IP del remitente y, opcionalmente, su puerto UDP o TCP. Cuando un enrutador recibe el mensaje RSVP resv :

  1. Realice una reserva en función de los parámetros de la solicitud. El control de admisión procesa los parámetros de solicitud y puede indicarle al clasificador de paquetes que maneje correctamente el subconjunto seleccionado de paquetes de datos o negociar con la capa superior cómo se debe realizar el manejo de paquetes. Si no se puede admitir, se envía un mensaje de rechazo para informar al oyente.
  2. Reenviar la solicitud en sentido ascendente (en la dirección del remitente). En cada nodo, un nodo de reenvío puede modificar la especificación de flujo en el mensaje de resv (por ejemplo, en el caso de una reserva de flujo de multidifusión, las solicitudes de reserva se pueden fusionar).
  3. Luego, los enrutadores almacenan la naturaleza del flujo y, opcionalmente, configuran la vigilancia de acuerdo con la especificación de flujo correspondiente.

Si no se escucha nada durante un período de tiempo determinado, la reserva caducará y se cancelará. Esto resuelve el problema si el remitente o el receptor fallan o se cierran sin cancelar primero la reserva.

Otras características

Integridad
Los mensajes RSVP van acompañados de un resumen del mensaje creado combinando el contenido del mensaje y una clave compartida utilizando un algoritmo de resumen del mensaje (comúnmente MD5 ). La clave se puede distribuir y confirmar mediante dos tipos de mensajes: solicitud de desafío de integridad y respuesta de desafío de integridad .
Error al reportar
Cuando un nodo detecta un error, se genera un mensaje de error con un código de error y se propaga en sentido ascendente por la ruta inversa hasta el remitente.
Información sobre el flujo de confirmación de asistencia
Dos tipos de mensajes de diagnóstico permiten a un operador de red solicitar información del estado de RSVP sobre un flujo específico.
Centro de diagnóstico
Una extensión del estándar que permite al usuario recopilar información sobre el estado de RSVP a lo largo de una ruta. [4]

RFC

Referencias

  1. ^ Garrett, Aviva; Drenan, Gary; Morris, Cris (2002). Guía de campo y referencia de Juniper Networks. Profesional de Addison-Wesley. pag. 583.ISBN​ 9780321122445.
  2. ^ Zhang, L., Deering, S., Estrin, D., Shenker, S. y D. Zappala, "RSVP: A New Resource ReSerVation Protocol", IEEE Network, septiembre de 1993
  3. ^ Lixia, Zhang; Steve, Berson; Shai, Herzog; Sugih, Jamin (septiembre de 1997). Protocolo de reserva de recursos (RSVP): especificación funcional versión 1. pag. 19.doi : 10.17487 /RFC2205 . RFC 2205.
  4. ^ Mensajes de diagnóstico de confirmación de asistencia. doi : 10.17487/RFC2745 . RFC 2745.

enlaces externos