El protocolo de reserva de recursos (RSVP o Resource Reservation Protocol), descrito en RFC 2205, es un protocolo de la capa de transporte diseado para

reservar recursos de una red bajo la arquitectura de servicios integrados (IntServ). "RSVP no es una aplicacin de transporte, es ms 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 transmisin por unidifusin y multidifusin con escalabilidad y robustez. RSVP puede ser utilizado tanto por hosts como por routers para pedir o entregar niveles especficos de calidad de servicio (QoS) para los flujos de datos de las aplicaciones. RSVP define cmo deben hacer las reservas las aplicaciones y cmo 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 diseado para interoperar con los actuales y futuros protocolos de encaminamiento. RSVP por s mismo rara vez es desplegado en redes de telecomunicaciones hoy en da pero para RSVP-TE, est comenzando a aceptarse de forma ms comn en muchas redes con QoS. A continuacin se describen los atributos principales del protocolo: 1. RSVP pide recursos para los flujos simplex: un flujo de trfico en una sola direccin desde el emisor a uno o ms receptores. 2. RSVP no es un protocolo de encaminamiento, pero trabaja con protocolos de enrutamiento actuales y futuros. 3. 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. 4. RSVP es soft state (la reserva en cada nodo necesita refresco peridico), mantiene solo temporalmente es estado de las reservas de recursos del host y de los routers, de aqu que soporte cambios dinmicos de la red. 5. RSVP proporciona varios estilos de reserva (un conjunto de opciones) y permite que se aadan futuros estilos al protocolo para permitirle adaptarse a diversas aplicaciones. 6. RSVP transporta y mantiene parmetros del trfico y de la poltica 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 versin 1 especificacin funcional se ha descrito en el; RFC 2205 (septiembre de 1997) por el IETF. La versin 1 describe la interfaz de admisin de control de trfico que se basa "nicamente" en la disponibilidad de recursos. Ms tarde la RFC2750 extendi el soporte del control de admisin. 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. Ms detalles en Servicios Integrados. Tambin se define el formato y el modo de uso de los datos de los objetos (que transportan la informacin 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 extensin propuesta para el soporte de polticas genricas de control de admisin en RSVP. La extensin incluye una especificacin de los objetos de la poltica y una descripcin del manejos de eventos de poltica. (Enero de 2000). RFC 3936 RFC 3936 describe las mejores prcticas actuales, y detalla los procedimientos de modificacin 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[editar editar cdigo]

RSVP reserva recursos para un flujo. Un flujo se identifica por la direccin de destino, el protocolo de identificacin y, opcionalmente, el puerto de destino. En MPLS una corriente se define como un LSP. Para cada flujo RSVP tambin identifica a la particular calidad de los servicios requeridos por la corriente a pesar de que no entiende la informacin especfica de la corriente QoS. Esos sistemas luego analizan el flowspec para aceptar y reservar los recursos. Un flowspec consta de: 1. Servicio de clase

2. 3.

Reserva de especificaciones -define la QoS Trfico de especificaciones - describe el flujo de datos

Filterspec[editar editar cdigo]

Filterspec define el conjunto de paquetes que sern afectados por un flowspec (es decir, los paquetes de datos para recibir la QoS definida por el flowspec). Un filerspec tpicamente selecciona un subconjunto de todos los paquetes procesados por un nodo. La eleccin puede depender de cualquier atributo de un paquete (por ejemplo, la direccin IP del remitente y el puerto). Los definidos en la actualidad son los estilos de reserva RSVP: 1. 2. Filtro fijo - reserva de recursos para un determinado flujo. Compartidas explcita - se reserva para varios flujos de recursos y compartir todos los recursos. 3. Filtro comodn - 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 especificacin de cada nodo, si bien el flowspec establece los parmetros de la bolsa en un nodo, la filterspec establece los parmetros en el clasificador de paquetes.

Mensajes[editar editar cdigo]

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 direccin IP del nodo anterior, y algunos objetos de datos: 1. 2. 3. Plantilla remitente para describir el formato de los datos de remitente. Tspec remitente para describir las caractersticas de trfico del flujo de datos. Adspec que lleva la publicidad de datos (vase el RFC 2210 para ms detalles).

Reserva de mensajes (resv)

La reserva de mensajes se enva 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[editar editar cdigo]

Es necesario que una acogida envie un flujo de datos especficos con QoS transmitir a RSVP una va mensaje que viajar a lo largo de las rutas de unidifusin y multidifusin previamente establecido por el protocolo de enrutamiento de trabajo. Si la ruta mensaje llega a un router que no entiende RSVP, el router enva 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: 1. Hacer una reserva sobre la base de parmetros de la peticin. Para este control de la admisin y las polticas de control de parmetros 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. 2. Adelante la solicitud aguas arriba (en la direccin del remitente). En cada nodo de la resv mensaje, flowspec puede ser modificado por un nodo de transmisin. Cada nodo en el camino puede aceptar o rechazar la peticin. Modo de operacin de RSVP

RSVP la implementacin

As surge RSVP (ReSerVation Protocol), protocolo de reservacin de recursos, un protocolo de control de la red que permite que los programas que van a trabajar en Internet puedan obtener la calidad de servicio que sus flujos de datos puedan requerir. Se trata de un protocolo totalmente emergente que se encuentra an en fase de normalizacin por parte del IETF, que est desarrollando su estandarizacin partiendo de los trabajos iniciales que se realizaron en la Universidad del Sur de California con la participacin de Xerox, en donde fue concebido. Este protocolo no es, en contra de lo que pudiera parecer, un protocolo de enrutamiento. Es un protocolo que se inscribe dentro de la capa de Transporte del modelo de conectividad OSI y se apoya en las tablas de rutas dinmicas que manejan los protocolos de enrutado clsicos para establecer una conexin a modo de circuito virtual entre emisor y receptor o receptores implicados.

Para RSVP el flujo de datos es simplemente una secuencia de paquetes que tienen un mismo origen, uno o varios destinos, segn sea la difusin, unicast o multicast, y una calidad de servicio, todo ello caracterizado mediante sesiones. Una sesin RSVP es cada torrente de datos que el protocolo maneja de forma independiente.

Las especificaciones de operacin de este protocolo se materializan en un programa, en un demonio, RSVP estructurado en mdulos, cada uno de ellos con unas funciones especficas. Por una parte estn el mdulo de Control de Admisin y el mdulo de Control de Poltica. El primero se encarga de determinar si el nodo tiene los recursos solicitados disponibles para soportar la calidad de Servicio pedida. El Control de Poltica determina si el solicitante tiene los permisos necesarios para poder disponer de los recursos que solicita. En otro lado se encuentra el motor de la reserva, el mdulo de Clasificacin, encargado de recepcionar los paquetes para determinar su ruta y QoS necesaria y el mdulo Esquemtico, al que se le encomienda la transmisin de los paquetes.

Este protocolo no es, en contra de lo que pudiera parecer, un protocolo de enrutamiento. Es un protocolo que se inscribe dentro de la capa de Transporte del modelo de conectividad OSI y se apoya en las tablas de rutas dinmicas que manejan los protocolos de enrutado clsicos para establecer una conexin a modo de circuito virtual entre emisor y receptor o receptores implicados.

El demonio RSVP recepciona los paquetes y los clasifica, encolndolos segn criterios temporales. Se les asigna ruta, Calidad de Servicio y en funcin del temporizador se colocan en el interface del router adecuado. Si la capa de enlace del puerto seleccionado tiene su propia gestin de QoS, el programa del protocolo de reservacin, negociar con l la obtencin de la Calidad de Servicio requerida. Si no dispone de esta capacidad, es el propio programa quien puede encargarse de reservar la capacidad necesaria para la transmisin, pudindose ocupar no slo de los parmetros. que afecten a la lnea de comunicacin, si no que puede abarcar CPU y almacenamiento.

El inicio del proceso de reservacin de este protocolo comienza realmente cuando el programa consulta a los protocolos de enrutado local las rutas que ha de utilizar. En cada salto, en cada nodo del camino, el programa RSVP local tiene que aplicar el mismo procedimiento, es decir, calcular si puede ofrecer la Calidad de Servicio que le han solicitado. Si este Control de Admisin y Control de Poltica es satisfactorio, el nodo local clasifica y encola los paquetes para

darles la QoS que requieren. Si no le es posible proporcionar los recursos que le han sido pedidos, la aplicacin que origin el flujo de datos recibir una indicacin de error.

En el contexto de operacin de RSVP, la distribucin de datos puede hacerse por difusin en unicast en donde slo hay un emisor y un receptor o por multicast, en cuyo caso hay un emisor y varios receptores. El flujo de datos que se maneja en una sesin de este protocolo siempre tiene un solo emisor y los paquetes de cada sesin en particular irn dirigidos a la misma direccin IP y a un puerto. Si hay difusin multicast, la direccin IP ser la direccin del grupo. Si para este protocolo cada emisor y receptor debe corresponderse con un host nico, no hay inconveniente para que un mismo host pueda contener varios emisores o receptores lgicos que se identifiquen por los puertos.

El protocolo UDP
UDP es un protocolo no orientado a conexin. Es decir cuando una maquina A enva paquetes a una maquina B, el flujo es unidireccional. La transferencia de datos es realizada sin haber realizado previamente una conexin con la maquina de destino (maquina B), y el destinatario recibir los datos sin enviar una confirmacin al emisor (la maquina A). Esto es debido a que la encapsulacin de datos enviada por el protocolo UDP no permite transmitir la informacin relacionada al emisor. Por ello el destinatario no conocer al emisor de los datos excepto su IP.

El protocolo UDP
El grupo de protocolos de Internet tambin maneja un protocolo de transporte sin conexiones, el UDP (User Data Protocol, protocolo de datos de usuario). El UDP ofrece a las aplicaciones un mecanismo para enviar datagramas IP en bruto encapsulados sin tener que establecer una conexin. Muchas aplicaciones cliente-servidor que tienen una solicitud y una respuesta usan el UDP en lugar de tomarse la molestia de establecer y luego liberar una conexin. El UDP se describe en el RFC 768. Un segmento UDP consiste en una cabecera de 8 bytes seguida de los datos. La cabecera se muestra a continuacin. Los dos puertos sirven para lo mismo que en el TCP: para identificar los puntos terminales de las mquinas origen y destino. El campo de longitud UDP incluye la cabecera de 8 bytes y los datos. La suma de comprobacin UDP incluye la misma pseudocabecera de formato, la cabecera UDP, y los datos, rellenados con una cantidad par de bytes de ser necesario. Esta suma es opcional, y se almacena como 0 si no se calcula. Inutilizarla seria absurdo, a menos que la cantidad de los datos no importe, por ejemplo, voz digitalizada.

UDP no admite numeracin de los datagramas, factor que, sumado a que tampoco utiliza seales de confirmacin de entrega, hace que la garanta de que un paquete llegue a su destino sea mucho menor que si se usa TCP. Esto tambin origina que los datagramas pueden llegar duplicados y/o desordenados a su destino. Por estos motivos el control de envo de datagramas, si existe, debe ser implementado por las aplicaciones que usan UDP como medio de transporte de datos, al igual que el reeensamble de los mensajes entrantes. Es por ello un protocolo del tipo best-effort (mximo esfuerzo), porque hace lo que puede para transmitir los datagramas hacia la aplicacin, pero no puede garantizar que la aplicacin los reciba. Tampoco utiliza mecanismos de deteccin de errores. Cuando se detecta un error en un datagrama, en lugar de entregarlo a la aplicacin destino, se descarta. Cuando una aplicacin enva datos a travs de UDP, stos llegan al otro extremo como una unidad. Por ejemplo, si una aplicacin escribe 5 veces en el puerto UDP, la aplicacin al otro extremo har 5 lecturas del puerto UDP. Adems, el tamao de cada escritura ser igual que el tamao de las lecturas.

El protocolo TCP
Contrariamente a UDP, el protocolo TCP est orientado a conexin. Cuando una mquina A enva datos a una mquina B, la mquina B es informada de la llegada de datos, y confirma su buena recepcin. Aqu interviene el control CRC de datos que se basa en una ecuacin matemtica que permite verificar la integridad de los datos transmitidos. De este modo, si los datos recibidos son corruptos, el protocolo TCP permite que los destinatarios soliciten al emisor que vuelvan a enviar los datos corruptos.