Diferencia entre revisiones de «Servicios integrados»

Contenido eliminado Contenido añadido
Rizquez (discusión · contribs.)
Sin resumen de edición
quito algunos juicios de valor, quito el apartado "conclusión" que es propio de un ensayo y no de un artículo enciclopédico
Línea 6:
¡Gracias por contribuir! -->
 
'''Servicios Integrados''' o '''Intserv''' constituyen una arquitectura que nos muestra los recursos necesarios para garantizar [[calidad de servicio]] ([[QoS]]) en una [[red de computadores]]. En la actualidad, en cuanto a Internet se refiere, los servicios integrados requieren una nueva arquitectura de protocolos que es dificilmente escalable. Esto se debe a que han de introducirse cambios generales en Internet para, a nivel de aplicaciones, realizar una reserva de recursos extremo a extremo.
 
 
Línea 20:
== Introducción ==
 
Es fundamental la capacidad de poder diferenciar calidades[[calidad de servicio|calidades [[QoSde servicio]] en la Internet de hoy día. Pero el diseño actual de [[IP]] da la mismas prioridades a todos los paquetes y esto puede llevarnos a lapreguntar pregunta:por qué son necesarios mecanismos que proporcionen calidad de servicio.
 
¿Entonces, por qué necesitamos mecanismos que nos proporcionen calidad de servicio ([[QoS]])?
Supongamos un caso en que un usuario está utilizando simultáneamente dos aplicaciones [[multimedia]] diferentes: una para realizar llamadas [[VoIP]] y otra para intercambiar información entre dos computadoras [[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 sería respecto al visionado de video y audio quepor tan de moda está hoy día en Internet ([[Streamingstreaming]]), si diferenciamos en streaming almacenados 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á tan de acuerdo si el streaming está siendo emitido en directo. Otro ejemplo más de lo importante que puede llegar a ser tratar de manera distinta los paquetes en Internet.
 
Así, surgen para dar esta calidad de servicio dos arquitecturas generales:
Línea 41:
 
 
'''Control de admisión''':como hemos dicho anteriormente, antes de enviar la infromacióninformación por la red se reservarán los recursos según la [[QoS]] que necesitemos. Para esto hay implementado un protocolo de reserva de recursos [[RSVP]].
En una nueva sesión:
* Se declararán los requerimientos de QoS, se hará mediante [[Request Specification|RSPEC]] (Request SPECification)
* Se caracterízará el tráfico que se mandará a la red, se hará mediante [[Traffic Specification|TSPEC]] (Traffic SPECification). TSPEC define el servicio de cada flujo. Podemos 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.
:* Servicio controlado: la tasa de transmisión acordada se cumple si la red no está sobrecargada, la tasa de pérdidas es bastante baja. Se puede adaptar a aplicaciones en tiempo real pero no es más adecuado para navegación web, FTP y aplicaciones similares.
Para comunicar RSPEC y TSPEC a los routers se utilizará el protocolo [[RSVP]].
 
'''Enrutamiento''': nos basaremos en [[QoS]] para enrutar los paquetes
 
 
== Conclusiones ==