Diferencia entre revisiones de «Servicios integrados»

Contenido eliminado Contenido añadido
Rizquez (discusión · contribs.)
Se han realizado cambios de lingüística. Mejorando la construcción de las explicaciones.
Línea 1:
'''Servicios Integrados''' o '''Intserv''' constituyen una arquitectura cuyo cometido es gestionar los recursos necesarios para garantizar [[calidad de servicio]] (QoS) en una [[red de computadores]]. El concepto que los servicios integrados proponen para cumplir con su cometido, requiere de una nueva arquitectura de protocolos que es difícilmente escalable. Esto se debe a que funciona realizando una reserva extremo a extremo de recursos en los elementos que conforman la red a nivel de aplicación, extremo a extremo.
 
 
== Historia ==
El notable crecimiento de Internet ha causadooriginado un desbordamientoimportante crecimiento del tráfico. Este hecho, causado por la aparición de un diverso tipo de aplicaciones ya sean web, video en tiempo real, conversaciones de voz, aplicaciones [[P2P]] y un largo etcétera, ha incitado a los expertos a buscar soluciones para controlar y gestionar este tráfico.
Una de las soluciones adoptadas en los últimos años es el uso de servicios integrados, que de todas las soluciones propuestas para resolver esta problemática, podría considerarse como la más drástica debido a que sugiere modificaciones en todos los equipos que conforman la red de redes, es el uso de servicios integrados.
 
== Introducción ==
El diseño actual de IP da la misma prioridad en el envío a todos los paquetes, sin embargo, resulta de capital importancia establecer calidad de servicio a ciertas comunicaciones que, por su contenido y requisitos, no son aptas desde el punto de vista “best effort” que ofrece IP.
 
SupongaseSupóngase un caso en el que un usuario está utilizando simultáneamente dos aplicaciones [[multimedia]] diferentes: una para realizar llamadas a través de [[VoIP]] y otra para intercambiar información entre dos servidores [[FTP]]. Si este usuario decidiese dar preferencia a su llamada VoIP y, por ejemplo, asignar a la misma, un ancho de banda mínimo satisfactorio para una correcta comunicación (ancho de banda que no está teniendo dado que sus recursos están siendo compartidos con el intercambio de ficheros FTP), el usuario estará pidiendo una calidad de servicio distinta para sus dos aplicaciones. En otras palabras, estará pidiendo que los paquetes IP de su conversación de voz tengan preferencia sobre sus paquetes FTP.
 
Otro ejemplo englobaría al visionado de video y audio por [[streaming]]. Si se diferencia entre streaming almacenadosalmacenado en un servidor y streaming en tiempo real, este mismo usuario no tendrá problema en tener que esperar cierto tiempo para poder visionar un streaming almacenado pero, en cambio, no estarátendrá tanun deservicio tan acuerdosatisfactorio si el streaming está siendo emitido en directo.
 
Así, surgen para dar esta calidad de servicio dos arquitecturas generales:
Línea 21:
 
Antes de describir las diferentes funciones, vale la pena definir el concepto de flujo. Se considerará por '''flujo''' al tráfico continuo de datos generados por un usuario o una aplicación y que requieren una misma calidad de servicio.
En la versión de [[IPv4]] un flujo estará definido, a nivel de transporte, por el protocolo utilizado (usado a nivel de transporte), ya sea [[TCP]] o [[UDP]] y), por sus puertos y por las direcciones IP origen y destino. En la versión de [[IPv6]] existe además, un campo (etiqueta de flujo), creado expresamente para esta función, que junto a sus direcciones origen y destino caracterizarán un flujo. Este campo recibe el nombre de etiqueta de flujo.
 
Dentro de la arcquitecturaarquitectura de servicios integrados, podríapodrían distinguirse las siguientes funciones principales:
:# Control de admisión
:# Enrutamiento
Línea 29:
:# Descarte de paquetes
 
'''Control de admisión''': como se ha dicho anteriormente, antes de enviar la información a través de la red se reservarán los recursos en función de la [[QoS]] que se necesite. Para esto hay implementado un protocolo de reserva de recursos denominado [[RSVP]] (ReServation Protocol).
En una nueva sesión:
* SeDeclaración declararánde los requerimientos de QoS: seSe realizará mediante RSPEC (Request SPECification)
* SeCaracterización caracterízará eldel tráfico que será enviado a la red,: seSe hará mediante TSPEC (Traffic SPECification).

: TSPEC define el servicio de cada flujo., Sedonde se pueden diferenciar las siguientes categorías de servicio:
 
:* Servicio garantizado: la tasa de transmisión acordada está garantizada. También se garantiza la ausencia de pérdidas. Este servicio es el idóneo para aplicaciones en tiempo real.
Línea 40 ⟶ 42:
Para la comunicación de RSPEC y TSPEC a través de los routers que conforman la red, se utilizará el protocolo [[RSVP]].
 
'''Enrutamiento''': losLos routers se basarán en la [[QoS]] de cada flujo de datos para enrutar los paquetes. Para ello los paquetes serán clasificados por flujos. Una vez clasificados pasarán por un organizador que dictará el modo en que se envíenenvían los paquetes. Los paquetes serán enviados a una de las colas con QoS, o bien, si no se ha especificado QoS alguna, serán enviados a la cola por defecto, asociada al servicio Best Effort.
 
'''Disciplina de servicio''': seSe podría considerar como disciplina de servicio al modo de funcionamiento con el que trabajarán las colas para llevar a cabo la mencionada diferenciación atendiendo a la [[QoS]] de los flujos.
Para tratar la disciplina de servicio existen varias técnicas:
:* [[FIFO]] (First In First Out): esEs la técnica más extendida, aunque para el caso de servicios integrados resulta irrelevante. Esto se debe a que esta técnica no nos proporciona la opción de dar preferencia a distintos flujos de comunicación.
:* WFQ, (Weighted Fair Queuing): esEs una técnica que nos proporciona múltiples colas de espera. Se asignará a cada cola de espera, un determinado flujo., Asíasí se logrará un peso (W) distinto en función de cuan buena sea la QoS requerida por cada flujo. Por ejemplo: si un flujo A requiere una calidad de servicio con W=12 y un flujo B requiere otra calidad de servicio con W=1. Este tipo de disciplina enviará 12 bits de flujo A y 1 bits de flujo B por ciclo.
 
'''Descarte de paquetes''': conCon el fin de evitar colapsos en las redes de comunicación se realizan controles de congestión. A continuación se introducirán tres métodos para realizar control de congestión mediante descarte de paquetes.
:* Tail drop: descartaDescarta los paquetes recién llegados con el fin de no llenar las colas.
:* QoS: descartaDescarta los paquetes con menos calidad de servicio.
:* RED (Random Early Detection,) RED: descartaDescarta continua y aleatoriamente paquetes, de una manera controlada, así se estará tratando la congestión de la red antes de que se produzca. Es uno de los más utilizados.
 
 
Línea 58 ⟶ 60:
Aunque no hay nada que impida la utilización de RSVP en tráfico [[unicast]], originalmente este protocolo había sido pensado para tráfico [[multicast]]. En multicast, es común ver distintos flujos de video y audio en tiempo real y estos flujos requieren distintas calidades de servicio.
 
En el protocolo RSVP vale la pena destacar el concepto de ruta (path). Una ruta define el camino que llevará el flujo de información desde el router emisor hasta el router receptor. CadaAsí, cada uno de los paquetes que pertenezcan a un flujo específico de información seguirán la misma ruta. Por lo tanto cada emisor enviará periódicamente un mensaje de ruta por cada flujo de información que genere,. ésteÉste contendrá información acerca de la calidad de servicio de cada tipo de flujo.
RSVP se vale de las tablas de rutas de cada router para envíar sus mensajes RSVP ya que este protocolo, por sí solo, no trabaja en labores de enrutamiento.
 
Se destacarán los dos mensajes principales:
*PATH: con este mensaje enviado en el sentido del flujo de datos por las rutas facilitadas por el protocolo de routing, una aplicación solicita tomar parte en una sesión RSVP con comportamiento emisor. El formato del mensaje PATH contiene:
:Common Header,[Integrity], Session, RSVP_Hop, Time Values, [Policy_Data], Sender Template, Sender_Tspec y [ADSPEC]. (Los objetos entre [] pueden aparecer pero no son obligatorios.)
 
*RESV: en consecuencia a la llegada de un mensaje PATH el receptor contesta con un mensaje RESV en el cual se indica el tipo de reserva a realizar en todo el camino. Este mensaje RESV viajará por la misma ruta seguida por su antecesor PATH pero justo en sentido contrario llegando así al emisor. El formato del mensaje RESV contiene: Common Header,[Integrity], Session, RSVP_Hop, Time Values, [Reso_Confirm], [Scope], Style y Flow Descriptor List. Los objetos entre [] pueden aparecer pero no son obligatorios.
 
*RESV: en consecuencia a la llegada de un mensaje PATH el receptor contesta con un mensaje RESV en el cual se indica el tipo de reserva a realizar en todo el camino. Este mensaje RESV viajará por la misma ruta seguida por su antecesor PATH pero justo en sentido contrario llegando así al emisor. El formato del mensaje RESV contiene: Common Header,[Integrity], Session, RSVP_Hop, Time Values, [Reso_Confirm], [Scope], Style y Flow Descriptor List. Los objetos entre [] pueden aparecer pero no son obligatorios.
:Common Header,[Integrity], Session, RSVP_Hop, Time Values, [Reso_Confirm], [Scope], Style y Flow Descriptor List. (Los objetos entre [] pueden aparecer pero no son obligatorios)
 
Objetivos principales de RSVP:
* Ha deDebe permitir anchos de banda distintos a lo largo de los caminos de red.
* Permitir aplicaciones con diferentes requerimientos.
* Funcionamiento unicast y multicast.
Línea 76 ⟶ 80:
 
Aclaraciones respecto a RSVP:
* RSVP es un mecanismo para informar cómo reservar los recursos, asíaunque quepor su parte no especifica cómo han de hacerse estas reservas.
* RSVP no proporciona la ruta que han de seguir los paquetes, este trabajo pertenece a los protocolos de routing.
* RSVP no interactúa en el seguimiento de los paquetes.
Línea 87 ⟶ 91:
== Problema principal ==
 
Aunque a mediados de los 90 la idea Intserv/[[RSVP]] generó una gran expectación, máscon tardeel paso del tiempo el interés por esta arquitectura se fuehizo alejandodecreciente. El motivo principal fuefueron los problemas de escalabilidad causados por la necesidad de almacenar y mantener información de estado en cada router. Estos motivos aplicados a una gran red como es internet, apartan RSVP de la realidad. LosAdemás, los fabricantes de routers tampoco realizan implementaciones eficientes de RSVP debido a su elevado coste hardware.
Recientemente, se ha vuelto a hablar de RSVP por su aplicación en [[MPLS]] e ingeniería de tráfico, ya que en estos casos, la cantidad de flujos noes suelemenos serelevada, tanlo elevadaque permite hacer implementaciones a menor coste, haciéndolo más asumible.
 
== Referencias ==