PONTIFICIA UNIVERSIDAD CATÓLICA DEL ECUADOR INFORME FINAL PROYECTO

TITULO:

“Estudio de la factibilidad de utilizar herramientas de Vídeo-Teléfono con soporte de Calidad de Servicio (QoS) en la Intranet de la PUCE “

Preparado por: Gustavo Chafla Ph.D.

.......................................15 7.........4 4 ELECCIÓN DE LA APLICACIÓN DE VIDEO-TELEFONO.....2 Pruebas de estrés del conjunto ya configurado........................................................CONTENIDO 1 INTRODUCCION....................................................9 6 CONFIGURACIÓN DE LOS DISPOSITIVOS DE RED.................................................2 Netmeeting y el modelo de QoS.........14 7 PRUEBAS DE RENDIMIENTO...15 7...............5 5 ELECCIÓN DEL MANEJO DE QoS .................2 Creación del perfil...........................................................................................................................................17 8 CONCLUSIONES...................................12 6.................1 Configuración de la tasa de cuadros por segundo.......11 6.....................................................................................1 Creación del Clasificador................................................3 Niveles de servicio del conmutador........18 ...................................................................3 3 DESCRIPCIÓN DEL AMBIENTE DE PRUEBAS .................................................7 5.....................................................................................1 QoS bajo Windows XP...............................7 5...................................................................................................................................3 2 METODOLOGÍA....................................................................................................................10 6.....................................................................

Este ambiente permitirá la generación de tráfico con QoS y tráfico BE que permita evaluar los parámetros elegidos en la configuración de los equipos de comunicaciones y estaciones de trabajo. Es también objetivo determinar el manejo y configuración de los parámetros de calidad de servicio de los equipos conmutadores de la Intranet de la PUCE. Una vez identificada la tendencia tecnológica de hardware y software se procedió a determinar el equipamiento necesario para la realización de las pruebas. además de contar con la información que el Internet provee respecto al tema. que en esencia es del tipo mejor esfuerzo (Best Effort). Se ha realizado una búsqueda bibliográfica y de artículos relacionados con la investigación. utilizar las redes de datos no solamente para el intercambio de información digital. por lo que es necesario identificar los estándares adecuados para la transmisión de audio y vídeo. dada su capacidad de transmisión. la tecnología subyacente es sujeto de estudio detallado antes de tomar una decisión de adquirirlos. lo que se conoce como voz sobre IP (VoIP) y videoconferencia por Internet. donde todas las aplicaciones en red compiten en igualdad de condiciones por el ancho de banda. Las redes de datos actuales. 2 METODOLOGÍA Para la elaboración de la investigación se han seguido los siguientes pasos: Recopilación de información relevante al tema. es decir. sino que estas redes de datos sirvan como medio para transmitir voz y vídeo en tiempo real. por lo que se observan en el mercado equipos especializados para la transmisión de voz y vídeo en diferentes modelos y rangos de precios.1 INTRODUCCION Durante los últimos años se ha observado una creciente tendencia de la tecnología de las telecomunicaciones hacia la utilización de las redes de datos IP como una plataforma multi-servicio. estaría en teoría en la posibilidad de integrar dentro de sus servicios un sistema de video teléfono. Determinación del ambiente de pruebas. Esta tendencia ha sido claramente identificada también por los grandes proveedores de hardware y software. Determinación del estado del arte en la transmisión de audio y vídeo en una red de datos y sobre la configuración de QoS en los equipos de red. Sin embargo. como la red interna de la PUCE. . el ancho de banda mínimo indispensable y la forma de brindar calidad de servicio (QoS) en una red TCP/IP. Las pruebas de rendimiento y configuración se realizarán en un ambiente controlado de pruebas. De esta forma el objetivo del proyecto es identificar los estándares más adecuados para la utilización de una aplicación de vídeo-teléfono en la Intranet de la PUCE.

Interfaces Ethernet LAN de 100 Mbps. Identificación del software y pruebas de funcionalidad. Se verificó que las aplicaciones y los equipos de red se ajustan de forma correcta a la configuración establecida. Análisis de los resultados de las pruebas de rendimiento y de configuración de QoS en los equipos de red. Generación de conclusiones. 3 Conmutadores 3COM 4400. Determinada la aplicación a utilizar se realizaron la instalación y pruebas de funcionalidad y compatibilidad con el esquema de QoS. Sistema Operativo Windows XP. NIC Ethernet 100 Mbps.Configuración de los parámetros de QoS en los equipos de red.8Ghz. Una vez determinados los equipos de red se realizó un estudio del tipo de configuración y parámetros de QoS a configurar. NIC Ethernet 100/1000 Mbps. Manejo de QoS con Perfiles DSCP 1 Cámara de captura de video Genios 30 fps Camera W indows XP Dual Core Laptop 3 Figura 2. 3 DESCRIPCIÓN DEL AMBIENTE DE PRUEBAS Para la realización de las pruebas de evaluación y rendimiento se utilizó un equipamiento hardware que incluía los siguientes equipos: • • • • 1 Ordenador portátil Toshiba Intel Dual Core 1. Sistema Operativo Windows XP.73 Ghz. 1Gb RAM. Intel 1. rendimiento y calidad. 1 Ordenador portátil HP.1 Esquema general del ambiente de pruebas .

entre otras características. Este trabajo cooperativo se habilita mediante herramientas como por ejemplo. un pizarrón virtual. Una vez instalado Netmeeting se puede observar la ventana principal de la aplicación tal como se muestra en la figura 4.El ambiente de pruebas está compuesto por una red privada Ethernet de 100 Mbps. Las condiciones de red no tienen influencia de tráfico externo al generado en las pruebas. Precisamente son estas utilidades de vídeo y audio conferencia las que hacen a Netmeeting como la herramienta escogida en este estudio. es decir. Los concentradores al ser dispositivos de nivel 1 no permiten realizar ningún tipo de configuración respecto al manejo de la calidad de servicio. consideramos que en cualquier caso Windows XP se puede considerar como un representante válido de la tendencia de Microsoft respecto del manejo de Calidad de Servicio (QoS). Para instalar Netmeeting bajo el sistema Windows XP es necesario ejecutar el archivo conf. En efecto esta tendencia fue identificada y descrita en la sección 4 ELECCIÓN DE LA APLICACIÓN DE VIDEO-TELEFONO Un requisito del proyecto de investigación era la utilización de herramientas estándar. . por lo tanto el emisor como receptor disponen de un máximo de 100 Mbps duplex. el intercambio de archivos.1 Netmeeting es una herramienta que permite el trabajo cooperativo tanto dentro de una red local como una red de área extendida. Entendemos que este sistema operativo es el de mayor utilización en los equipos de usuario de la red de la PUCE. Si el programa no ha sido ejecutado antes este archivo presenta el instalador de la aplicación donde se ajustan por ejemplo la captura del vídeo y audio. Independientemente de aquello. El esquema general de las pruebas se muestra en la figura 2. es también cierto que Microsoft provee por omisión del ejecutable que permite realizar una instalación del aplicativo Microsoft Netmeeting sin tener que incurrir en el pago de licencias adicionales por la utilización de este software.exe.1 Respecto a los equipos portátiles utilizados en el ambiente de pruebas estos fueron entregados al proyecto pre-configurados con el sistema operativo Windows XP. Como equipos de comunicaciones únicamente se han utilizado únicamente switches y no concentradores (Hubs). videoconferencia y audio-conferencia. tanto en el aspecto de aplicativos como de equipos de comunicaciones la investigación siempre debía estar encaminada a la utilización de herramientas que ya se encuentran disponibles en la configuración actual de la red de la PUCE. ya que por una lado nos permite utilizarla como una aplicación de vídeo-teléfono y por otro lado es una herramienta que se encuentra incluida en la distribución de los sistemas operativos Windows. Si bien es cierto que el requisito anterior no cierra las puertas a la instalación de aplicaciones de vídeo-teléfono de libre distribución.

los datagramas de audio y vídeo generados por la aplicación sí incluyen información para el manejo de QoS.Figura 4. y como se podrá observar más adelante en la sección de pruebas de rendimiento. Mayor información respecto a este punto puede obtenerse de la siguiente dirección web //support. Netmeeting sí hace uso de la capacidad de manejo de QoS que ofrece Windows XP y de forma automática. Una vez que el audio y vídeo han sido ajustados en Netmeeting son pocas las variantes que Netmeeting permite hacer a estos dos flujos. Este es un problema menor si consideramos que Netmeeting incorpora la interfaz y se encuentra previamente configurada. .com/kb/316666/es. desafortunadamente la información existente sobre este API es muy escueta y poco documentada. Microsoft Windows hace hincapié que las aplicaciones que necesiten incorporan el manejo de QoS en el envío de sus datagramas deberán incluir el API de QoS. Básicamente permite configurar la calidad del audio e incluso cambiar el codificador. pero respecto al vídeo únicamente permite configurar la calidad y el tamaño del mismo. No permite ajustar por ejemplo el tipo de codificador peor aún la tasa de cuadros por segundo fps. es decir. Podría pensarse que la calidad del vídeo esta directamente relacionada con los fps pero como se verá más adelante esta relación no se cumple en su totalidad.microsoft.1 Netmeeting En efecto.

Es un método más sencillo que el anterior pero esta simplicidad se paga con la especificación o aprovisionamiento manual a realizarse en los routers. El método de control de admisión se basa en algún tipo de protocolo de señalización con el que las aplicaciones especifican sus parámetros de calidad de servicio (ancho de banda.e: voz y vídeo) del que no lo necesita y con el que se realiza el mejor esfuerzo (p. A la hora de diferenciar el tráfico que necesita granarías de calidad (p. elimina el soporte al protocolo RSVP. Desafortunadamente a partir de Windows XP. Windows había puesto a disposición de los usuarios una serie de herramientas que permitían la configuración de estos parámetros. ahora los flujos deben diferenciarse unos de otros en base a alguna característica del datagrama. es muy probable que esta configuración se mantenga en las nuevas versiones de los sistemas operativos de Microsoft. Microsoft decide eliminar el soporte de QoS utilizando un control de admisión. . es decir. como por ejemplo la utilidad TCMON disponible en las versiones Windows 2000 o Server. Esta entidad decide si el flujo con las características indicadas puede o no ser admitido por el sistema en base a los flujos que se encuentran activos y que requieren de garantías de calidad. tasa de error admitida. 5. Windows Vista.5 ELECCIÓN DEL MANEJO DE QoS Se realizó una recopilación de información del estado del arte en provisión de QoS en los sistemas operativos Windows con especial atención a los mecanismos que provee Microsoft Windows XP.1 QoS bajo Windows XP El principal método de control de admisión utilizado en los sistemas operativos Windows estaba representado por el protocolo RSVP (Resource Reservation Protocol) que implica la señalización específica de los parámetros de QoS de las aplicaciones.e: navegación web. Es decir. correo electrónico) existen básicamente dos enfoques: Realizar un control de admisión de los nuevos flujos de datos que generan las aplicaciones o realizar un control del tráfico generado por las aplicaciones. como por ejemplo. picos de velocidad. Dado que el soporte a RSVP fue eliminado del sistema Windows XP y únicamente se cuenta con la especificación del modelo DiffServ. El método de control de tráfico por otra parte no necesita un protocolo de señalización más sí la especificación explícita en los routers de qué tratamiento se dará a un determinado tipo de flujo. Justifica esta decisión considerando que para las aplicaciones resulta extremadamente complicado especificar sus parámetros de QoS. retardo admitido) a una entidad de control antes de físicamente enviar los datos. De esta forma para Windows XP únicamente es posible realizar un control de tráfico mediante la configuración de códigos DSCP utilizando el modelo propuesto por los servicios diferenciados DiffServ.

Figura 5. Sin embargo. A continuación se muestra la ventana de configuración de QoS de Windows. El manejo de los códigos diferenciados de servicios DSCP de la capa 3 del modelo ISO/OSI se lo realiza utilizando el programador de paquetes QoS.Para el manejo de ciertos parámetros de QoS Windows XP provee de la herramienta group policy editor para presentarla es necesario ejecutar gpedit. Si la versión del sistema no lo trae preinstalado. Es posible cambiar estos valores de omisión en caso de que por ejemplo la administración de los códigos en los equipos de red así lo determine. Para el servicio garantizado el programador usará el valor predeterminado de DSCP igual a 40 (0x28). Como se verá más adelante son estos códigos los que utiliza la aplicación de vídeo-teléfono seleccionada. para el caso de estas pruebas esta instalación se la realizó en la interfaz de red de área local ethernet. existen muchas personas que señalan que esta configuración aplica de forma permanente a todas las conexiones de red por lo que recomiendan encerar este valor a fin de utilizar el . puede notarse la especificación de los valores del código DiffServ DSCP. su instalación se lo realiza en la interfaz en la que se desee realizar un control de los paquetes de QoS. debería aplicar cuando efectivamente existe tráfico de este tipo generado por la estación. esto en teoría. Como dato curioso en este punto está la reserva de ancho de banda que Windows XP define para el manejo de QoS. El programador de paquetes usa el valor predeterminado de DSCP igual a 24 (0x18) para el servicio de carga controlada.1 Editor de políticas de grupo Importante en este punto verificar que es efectivamente el modelo DiffServ el que utiliza Windows XP.msc. El sistema reserva el 20% del total del ancho de banda para tráfico con garantías de calidad.

dicho en otras palabras. 5. la principal preocupación que surgió era determinar si esta aplicación se ajusta al modelo de QoS que implanta el sistema operativo. una interfaz de red únicamente utiliza el 80% de su capacidad. Mostramos de esta forma dos pantallas de la captura de datos hecha con Ethereal para los datos de audio y vídeo. el vídeo es enviado utilizando el código DSCP 24 (0x18 hexadecimal) que corresponde al servicio de carga controlada del programador de paquetes como puede observarse en la figura 5. Netmeeting no muestra en su configuración ninguna forma de especificar los parámetros de QoS por lo que la duda era razonable sobre si la aplicación implanta o no un modelo de QoS y de forma más específica el modelo DiffServ.2 Captura trama de audio De la captura realizada puede notarse que el audio utiliza lo que el programado de paquetes identifica como servicio garantizado con el código DSCP 40 (0x28 hexadecimal). No quedaba en este punto otra opción que realizar una captura de tramas y constatar de la existencia o no del manejo de QoS de la aplicación. Figura 5. . Esta era otra razón que reforzaba en el momento la idea de instalar una aplicación hecha por Microsoft.2 Netmeeting y el modelo de QoS Una vez elegida la aplicación de vídeo-teléfono a utilizar. Microsoft desmiente este comportamiento del sistema cuando no existe tráfico QoS en el sistema. Por otro lado.3.100% del ancho de banda disponible.

Para la realización de estas pruebas se han escogido. .Figura 5. Dentro de estos dispositivos y de buena utilización dentro de la LAN de la PUCE se encuentran los switches 3COM. Habiendo avanzado ya en la investigación y determinado que el modelo escogido por los hosts de la red de pruebas era el de servicios diferenciados que utiliza los códigos DSCP para la diferenciación de los flujos de red. switches del fabricante 3COM modelo SuperStack 4400. Efectivamente se observó que los switches 3COM permiten manejar distintos niveles de QoS y mas concretamente son capaces de manejar estos niveles mediante el uso de códigos DSCP configurables mediante la línea de comandos. Estos switches son administrables mediante una interfaz de línea de comando (CLI) indispensable para configurar los parámetros de calidad de servicio del modelo que implementen. 6 CONFIGURACIÓN DE LOS DISPOSITIVOS DE RED Tomando en cuenta que en una red de área local básicamente se utilizan como dispositivos de conexión a los conmutadores o switches.3 Captura trama de vídeo En este punto entonces se ha determinado que efectivamente la aplicación se ajusta al modelo propuesto por el sistema operativo queda por configurar el comportamiento de los equipos de comunicaciones que forman parte de la red de pruebas. por lo antes expresado. quedaba por identificar si el modelo adoptado por los switches era compatible con el primero.

en este caso el DSCP. El proceso quedaría entonces estructurado de la siguiente forma: • • • • • Creación de un clasificador por cada tipo de tráfico Crear un perfil Asociar los clasificadores al perfil Definir un nivel de servicio para los clasificadores Asociar el perfil a los puertos del conmutador a utilizar 6.Para entrar en el proceso de configuración de QoS de los switches es necesario ingresar a la sección de qos dentro de la sección de control de tráfico trafficManagement tal como se muestra en la figura 6. uno para el tráfico de audio y otro para el tráfico de vídeo. En otras palabras.1 Creación del Clasificador Para crear el clasificador se utiliza la opción create dentro del menú . mediante un clasificador filtramos los paquetes que cumplen la especificación de QoS. Cabe aclarar en este punto que son necesarios dos perfiles. CLI para manejo de QoS Realizadas las pruebas de configuración correspondientes se determinó que la configuración que requiere el switch 3COM incluye la creación de un perfil que cuenta con clasificador al que se la asigna uno de los niveles de servicio previamente configurados en el conmutador (desde best effort hasta network control) para finalmente asignar el perfil a los puertos correspondientes del conmutador.1. Una vez filtrados los paquetes se les da un nivel de servicio distinto de los demás paquetes que no cumplen la especificación.1 Figura 6.

Figura 6. CLI para creación del perfil . Este mismo procedimiento aplicamos para la creación del clasificador de vídeo. CLI para creación del clasificador 6.2 podemos ver los pasos para crear el clasificador del flujo de audio que genera la aplicación Netmeeting (código DSCP 24).2. En la figura 6. tal como se muestra en la figura 6.trafficManagement/qos/classifier.3 Figura 6.2 Creación del perfil La creación del perfil se realiza en la sección profile dentro del menú trafficManagement/qos escogiendo la opción create.3.

En el caso de la prueba utilizamos los puertos 1 y 2 con capacidad de manejo de tráfico QoS. Resumen de configuración del perfil y clasificador Puede notarse en esta configuración el perfil creado video_phone y asociados los clasificadores 102 y 101 con los niveles de servicio 4 y 5 respectivamente.4 Figura 6. En este punto es necesario asociar los clasificadores al perfil que acabamos crear. Para añadir a un puerto los perfiles creados utilizamos la opción assign dentro del menú trafficManagement/qos/profile.5 la asociación de los puertos 1 y 2 al perfil video_phone.4. Puede notarse en la figura 6. cuando se hace esta asociación el proceso de configuración preguntará el nivel de servicio que se asignará a esta asociación. Esta asociación de omisión de alguna forma . añadimos los perfiles de audio y vídeo a los puertos tanto al puerto 1 como al 2.5. en otras palabras. Adicionalmente puede verse que el resto de los puertos están asociados al perfil de omisión con un nivel de servicio de 2. Una vez realizado este procedimiento se debería ver la información de resumen de los puertos (opción listport) tal como se muestra en la figura 6. Para asociar un clasificador a un perfil se utiliza la instrucción addClassifier. El trabajo únicamente quedará completo cuando podamos asociar estos perfiles a los puertos del conmutador que vayamos a utilizar en las pruebas de la aplicación de vídeo teléfono.Una vez creados los dos perfiles es posible comprobar esta información con la opción summary. En la siguiente sección hará una descripción más en detalle de estos niveles y su significado. Un ejemplo completado de la configuración de perfil con los dos clasificadores se muestra en el resumen de la figura 6.

El investigador deja abierta la posibilidad de que no necesariamente el nivel de servicio sea mejor cuanto más alto es el número asociado al nivel de servicio debido principalmente a que el tráfico crítico del negocio (Business Critical) tiene un nivel igual a 3.6. Figura 6. En contraposición el tráfico de control de red tendrá el nivel más alto de servicio. En cualquier caso lo importante en este punto es diferenciar el tráfico de audio y vídeo del tráfico del mejor esfuerzo. Cabe recalcar en este punto que no es posible crear niveles de servicio. nivel 2 al más alto nivel 7. Asociación del perfil a los puertos 6.3 Niveles de servicio del conmutador Los conmutadores 3COM utilizados en el proyecto cuentan con 6 niveles de servicio tal como se muestra en la figura 6. el conmutador viene preconfigurado con estos niveles. 6 niveles de servicio son más que suficientes para las pruebas del proyecto. Esta conclusión la podemos inferir considerando que el nivel 2 esta asociado al tráfico Best Effort que corresponde al tráfico con el que el conmutador hará su mejor esfuerzo. Los niveles de servicio del conmutador van desde el más bajo. En cualquier caso. Efectivamente el lector puede inferir que fueron precisamente estos niveles los que se utilizaron para nuestros perfiles de audio y vídeo respectivamente. Dentro de los niveles de servicio con los que cuenta el conmutador podemos observar que existen niveles de servicio diferenciados para aplicaciones de audio (4) y vídeo (5). .sugiere que posiblemente el nivel 2 corresponde al más bajo y para el tráfico con el que el conmutador hará su mejor esfuerzo.5.

A continuación incluye una pantalla de la captura de trazas de uno de los experimentos que se ha realizado. 30 tramas por segundo. La calidad de imagen del vídeo es buena pero su tasa de trama es inferior a la especificación de la cámara utilizada. Las pruebas realizadas muestran un tasa máxima de 4 a 5 fps para el vídeo.6. Estudios muestran que una tasa de muestreo en Video-Teléfono superior a las 8 tramas por segundo podría ser suficiente considerando que los interlocutores no tienen mayor movimiento y la mayoría de conversaciones consisten en busto-parlantes. Una tasa de muestreo de 30 tramas por segundo es suficiente para que el ojo humano no detecte la superposición de tramas y en su defecto las imágenes se perciben en movimiento continuo. es decir. la columna tiempo muestra el instante en que la trama es generada por lo que es sencillo determinar el número de tramas por segundo que se han .1 Configuración de la tasa de cuadros por segundo Se ha identificado que la tasa de cuadros por segundo (fps) ésta es determinada por el sistema operativo y el equipo de captura involucrado. Niveles de servicio del conmutador 7 PRUEBAS DE RENDIMIENTO Se realizan pruebas de rendimiento del sistema en un ambiente poco cargado se observa una calidad bastante aceptable del audio pero el comportamiento del vídeo no parece ser el más óptimo a pesar de que las condiciones de saturación de red son mínimas.Figura 6. Esta captura utiliza un filtro DSCP 0x18 utilizado por las tramas que transportan el vídeo. 7.

Captura de tramas de vídeo de la aplicación Para el caso del audio la tasa de muestreo supera las 70 unidades por segundo según la captura realizada por lo que la calidad del audio es bastante aceptable.2 .enviado en el experimento. Adicionalmente la captura permite identificar que no existen problemas de rendimiento de TCP/IP del emisor y tampoco del receptor. nótese que las tramas capturadas que tienen un tiempo de generación muy similar se puede considerar como correspondientes al mismo cuadro.1. Figura 7. Si es de su interés puedo facilitarle la captura completa de este experimento para su análisis. Una captura de la información de audio puede observarse en la figura 7.

Generador de paquetes en una transferencia de archivos sin código DSCP. 2. De esta forma el punto 1 generaría tráfico siguiendo el modelo DiffServ de QoS.Figura 7. Generador de paquetes de la aplicación de vídeo-teléfono desde una de las estaciones de usuario con especificación de QoS mediante el uso de 2 códigos DSCP distintos para audio y vídeo. Captura de tramas de audio de la aplicación 7. Se pudo observar en la prueba que la aplicación de vídeo teléfono mantuvo una calidad de audio bastante aceptable. es decir con un código DSCP de omisión (0x00) que no es diferenciado en las estaciones de usuario o los equipos de comunicaciones en cuanto a otorgarle un tratamiento distinto. tráfico best effort.2. La parte 2 generaría tráfico best effort. De esta forma sería posible observar si el modelo de QoS de las estaciones y de los equipos de comunicaciones era el adecuado y correctamente procesado por ambas partes. los datagramas estarían marcados con el código DSCP asignado por la aplicación (0x28 y 0x18 para audio y vídeo).2 Pruebas de estrés del conjunto ya configurado Finalmente se procedió con la pruebas de estrés en las que someteremos a tráfico importante tanto a las estaciones de trabajo como a los conmutadores. La prueba consistió básicamente de dos generadores de tráfico activados de forma simultánea: 1. es decir. La tasa de generación de cuadros para el vídeo llego a una .

Figura 7. El requisito en este último caso es que los conmutadores sean administrables y dispongan de la utilidad de manejo de tráfico. Definitivamente el modelo más sencillo y de mayor utilización por la comunidad científica es el de servicios diferenciados con sus códigos DSCP.máxima de 6 cuadros por segundo y no se notaron cambios en la calidad de la imagen respecto a pruebas anteriores. No podemos • .2 que la utilización de la interfaz de red del equipo que genera el audio y vídeo llegaba a picos que superaban el 80 % de utilización. se ha generado una situación de utilización máxima de la interfaz de red sin observar un deterioro significado de la calidad del audio y vídeo. Puede notarse en la figura 7. valor que es bastante elevado considerando una actividad promedio de la interfaz durante el día. Es decir.2. Utilización de la NIC durante la prueba de estrés 8 CONCLUSIONES A continuación se exponen las principales conclusiones que se pudieron obtener de toda la investigación realizada dentro del proyecto: • Sí es posible configurar parámetros de QoS tanto en los hosts como en los equipos de red (conmutadores en el caso de la prueba) dentro de una red de área local.

sino más bien se ha especificado un método de tratar con prioridad un tráfico de cualquier aplicación de la red que sea capaz de marcar un código DSCP. Sin embargo. Microsoft ha dejado de utilizar el enfoque de modelos integrados precisamente por su compleja utilización y ha preferido que las aplicaciones utilicen un código DSCP previamente establecido. Un problema en este punto con este modelo es: ¿qué pasa si alguien maliciosamente genera un tráfico con una especificación DSCP que no le corresponde?. es posible controlar que esto no suceda dentro una red LAN. Existe una tendencia evidente de adoptar en los sistemas operativos un modelo sencillo de manejo de QoS. En contraparte. Si bien es cierto que se ha utilizado un modelo específico de un fabricante de conmutadores como es el caso de 3COM. el aprovisionamiento de los recursos deber ser hecho de forma manual. tampoco son categóricamente dispositivos de nivel 2 ya que son capaces de interpretar y dar un servicio diferente utilizando un código DSCP que se encuentra en el nivel 3 de la torre ISO/OSI. En general no es aventurado pensar que los conceptos manejados de clasificador. . desventaja con la que no se cuenta en el modelo de servicios integrados.• • • • concluir que los conmutadores utilizados en la prueba son de nivel 3 debido en especial por su incapacidad de encaminar paquetes. Es importante anotar que el manejo de QoS expuesto en esta investigación no es restrictivo para otras aplicaciones que no sean de vídeo teléfono. Si hubiera un proceso de aceptación previa a un flujo es lo ideal en esta circunstancia pero eso implica una mayor complejidad y mantenimiento de estados que precisamente es una de las razones que no ha permitido una adopción mayoritaria del modelo de servicios integrados. perfil y asociación de puertos son procesos inevitables al momento de manejar QoS en cualquier switch independientemente fabricante. si podemos extrapolar la información en otros modelos superiores del mismo fabricante como es el caso del encaminador 5500.