Test 57 pregunta 39,

[v_b_v_madrid]

Hola a todos,

Tengo una duda sobre esta pregunta:

39.- ¿En qué tipo de aplicación no sería adecuada la instalación de una conexión Frame Relay?:
a. Correo electrónico
b. Conexión de redes de area local
c. Video
d. Todas las anteriores son posibles aplicaciones de una red Frame Relay de alta velocidad


Da como correcta la c, pero no entiendo porque.

Entiendo que Frame Relay se creo para tx principalmente datos, y no para tx vídeo, pero no entiendo porque no es adecuado para Tx Video
¿Alguien puede arrojar algo de luz al asunto?

Gracias

[martuki]

Seguro que alguien te puede dar una respuesta más técnica, pero aquí va una de andar por casa: Frame Relay está pensado para redes poco fiables y por eso hace control de flujo y errores en todos los nodos intermedios entre el origen y el destino (hay ACKs y comprobaciones en todos los saltos), debido a eso se pierde tiempo procesando las tramas en el camino hasta el destino y no es adecuado para aplicaciones sensibles al retardo.
Un saludo.

[xavi_super]

Seguro que alguien te puede dar una respuesta más técnica, pero aquí va una de andar por casa: Frame Relay está pensado para redes poco fiables y por eso hace control de flujo y errores en todos los nodos intermedios entre el origen y el destino (hay ACKs y comprobaciones en todos los saltos), debido a eso se pierde tiempo procesando las tramas en el camino hasta el destino y no es adecuado para aplicaciones sensibles al retardo.
Un saludo.

Martuki, revisa tus apuntes porque éso precisamente es lo que NO hace Frame-Relay. Lo que has escrito se dice de las redes X.25. Con el tiempo las líneas de comunicaciones se fueron haciendo más estables, y los listos de las redes pensaron que ya no era necesario hacer comprobaciones en cada salto, que para la baja probabilidad de fallo que había no merecía la pena, que era preferible que las comprobaciones la hiciesen los nodos finales y descargar de trabajo a los nodos intermedios, ganando así en velocidad. Y en el caso de errores de transmisión, aunque hubiese que retransmitir tramas de extremo a extremo, aún así seguía siendo preferible no hacer comprobaciones en nodos intermedios. Y con estas premisas nació Frame-Relay.

Respondiendo a la pregunta inicial, yo dudaría entre las respuestas c y d. Si no estuviese la d, me quedaría sin duda con la c.
En principio nada impide enviar vídeo por un enlace FR, todo depende de la capacidad del enlace, de la resolución del vídeo, de si es tiempo real o no... Pero también es verdad que si queremos vídeo en tiempo real y con calidad de servicio, FR no es la mejor opción, principalmente porque FR no aporta mecanismos de priorización adecuados (alguno tiene, pero no es el más adecuado) para garantizar el retardo y el jitter constante que exige el vídeo de tiempo real. También hay que tener en cuenta que FR proporciona una velocidad máxima de 34 Mbps (hablo de memoria) y éso puede ser insuficiente para algunos flujos de vídeo.

En definitiva, en un examen real, sin más datos, yo tendría serias dificultades para elegir entre la c y la d. Por éso es bueno hacer tests

[jab]

Otro aspecto a tener en cuenta es que la carga de datos de una trama en Frame Relay es variable y eso no favorece la transmisión de datos que requieren un flujo constante. Por eso ATM es mejor para estos menesteres.

Al fin y al cabo Frame Relay nació para intercomunicar y transmitir datos, y aunque el CIR proporcione cierta QoS no es suficiente para servicios de tiempo real.

[martuki]

Tienes razón, vaya lapsus! Me lié con X.25! Como me pase esto en el examen lo llevo claro ((

[vfrades]

Desde el punto de vista de la calidad de servicio, la transmisión de vídeo en tiempo real estaría englobada dentro de los llamados servicios de streaming, que se caracterizan por requerir un fuerte control de la variación del retardo o jitter. FR sólo proporciona una cierta garantía sobre la tasa de transferencia (CIR) pero en ningún caso controla el jitter.

[v_b_v_madrid]

Muchas gracias a todos por vuestras respuestas.