Diferencia entre revisiones de «Servicios integrados»
Contenido eliminado Contenido añadido
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
== Historia ==
El notable crecimiento de Internet ha
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
== 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
Otro ejemplo englobaría al visionado de video y audio por [[streaming]]. Si se diferencia entre streaming
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
Dentro de la
:# 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:
*
*
: TSPEC define el servicio de cada flujo :* 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''':
'''Disciplina de servicio''':
Para tratar la disciplina de servicio existen varias técnicas:
:* [[FIFO]] (First In First Out):
:* WFQ
'''Descarte de paquetes''':
:* Tail drop:
:* QoS:
:* RED (Random Early Detection
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.
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)
Objetivos principales de RSVP:
*
* 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,
* 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,
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
== Referencias ==
|