Estudio del impacto de la gestión de tráfico sobre redes internet al usar servicios diferenciados

Texto completo

(1)ESTUDIO DEL IMPACTO DE LA GESTIÓN DE TRÁFICO SOBRE REDES INTERNET AL USAR SERVICIOS DIFERENCIADOS. SILVIA BARACALDO CASTILLA. Proyecto de grado para optar al título de Ingeniero Eléctrico. Asesor Néstor Peña Ingeniero Eléctrico. UNIVERSIDAD DE LOS ANDES FACULTAD DE INGENIERIA DEPARTAMENTO DE INGENIERIA ELECTRICA Y ELECTRONICA BOGOTA, DC 2003.

(2) IEL1-2002-II-04. CONTENIDO. Introducción. 5. 1. Generalidades de TCP/IP. 6. 1.1 Protocolo IP. 7. 1.2 Protocolo TCP. 10. 1.3 Control de congestión en TCP. 13. 14. 1.3.1 Slow Start y Congestion Avoidance 1.3.2 Fast Retransmit y Fast Recovery. 1.4 Propuestas para mejorar el servicio desde el protocolo IP. 15 17. 2. Servicios Diferenciados 20 2.1 Campo DS en el encabezado IP. 21. 2.2 Enrutadores de un dominio DS. 22. 2.3 Elementos de redes DS. 24. 2.4 Seguridad. 27. 3. Implementación de Servicios Diferenciados con NS Simulator. 28. 3.1 Módulo de Servicios Diferenciados. 30. 3.2 Topología simulada. 37. 4. Resultados. 41. 5. Conclusiones. 53. Bibliografía. 56. Anexo. Códigos desarrollados. 58. 2.

(3) IEL1-2002-II-04. LISTA DE TABLAS Tabla I. Factores para medir el tráfico. 34. Tabla II. Parámetros del tráfico. 38. Tabla III. Número de conexiones de cada aplicación. 40. Tabla IV. Pesos de las colas. 46. 3.

(4) IEL1-2002-II-04. LISTA DE FIGURAS Figura 1.Encabezado IP. 8. Figura 2. Ventana deslizante TCP 11 Figura 3. Encabezado TCP. 12. Figura 4. Encabezado IP con el campo de Tipo de Servicio resaltado. 21. Figura 5.Campo DS. 21. Figura 6. Clasificador y condicionador de tráfico. 26. Figura 7. Cola RED. 32. Figura 8. Topología usada. 39. Figura 9. Retardo medio en cola – No DS. 42. Figura 10. Retardo medio en cola – DS. 44. Figura 11. Retardo medio en cola 45 Figura 12. Retardos medio DS al variar el peso de la cola 2. 47. Figura 13. Retardo máximo en cola – no DS. 48. Figura 14. Retardo máximo en cola – DS. 48. Figura 15. Retardo máximo – Aplicación 1. 49. Figura 16. Retardos para la aplicación 1 50 Figura 17. Retardo máximo – Aplicación 4 Figura 18. Retardos para la aplicación 4 51. 4. 51.

(5) IEL1-2002-II-04. INTRODUCCIÓN. En la actualidad se han hecho muchos avances en muchos campos que hasta hace algún tiempo podrían haber parecido como sacados de un cuento de hadas. Algunos de esos avances nos ha tocado vivirlos a nosotros, y de otros nos damos cuenta por las historias que oímos de nuestros papás sobre como era la vida cuando ciertas cosas no existían. El Internet es uno de los avances que hemos vivido nosotros. Aunque este tiene cierto tiempo de haber sido inventado, su utilización masiva solo ha venido a desarrollarse hasta hace muy poco.. Cuando Internet fue inicialmente. desarrollado, se vio como una solución para las comunicaciones del ejército de los Estado Unidos, y nunca se pensó que fuera a evolucionar de la forma en que lo ha hecho hasta este momento.. Pero poco a poco su uso se ha ido. generalizando y cada vez se inventan nuevos usos que antes no estaban pensados. [2] Actualmente existen nuevas y más exigentes aplicaciones que necesitan que la red tenga un buen desempeño en cuanto a retardos y pérdidas de información. Aunque inicialmente la tecnología a usar se había diseñado para que fuera robusta en cuanto a fallas de la red, no se tenía las exigencias en cuanto a retardos, ni el volumen de tráfico que se tienen ahora [1]. Por esta razón es justificable pensar que la red necesita ser mejorada. Esto no quiere decir que se deba cambiar de tecnología, simplemente se ve la necesidad de estudiar los problemas que se están teniendo en este momento, para buscar una solución a estos.. 5.

(6) IEL1-2002-II-04. 1. GENERALIDADES DE TCP/IP. La red Internet, tal cual se usa hoy en día, está basada en el modelo TCP/IP, el cual describe la forma en que la información viaja a través de esta:. los. protocolos que se usan, la forma en que se manejan los paquetes, las capas que se van a considerar en el sistema, etc. Dentro del modelo TCP/IP se definen varias capas encargadas de distintos aspectos de la comunicación entre las máquinas. La primera de ellas es la capa Host-to-Network, en ella se define la forma en que cada usuario se conecta a la red. La siguiente es la capa de red la cual se encarga de insertar los paquetes a transmitir dentro de la red, y de recogerlos en el destino. Luego sigue la capa de transporte que se encarga de crear las conexiones necesarias para enviar los paquetes a través de la red. Por último se encuentra la capa de aplicación, en la cual se encuentran las distintas aplicaciones que pueden ser usadas en la red [1]. Cada una de estas capas se encarga de manejar y manipular la información que se va a transmitir de una forma diferente, y le va añadiendo a los paquetes a transmitir distintos encabezados que permiten recuperar la información de manera ordenada en el punto de recibo de esta. La principal función de los protocolos es permitir que dos máquinas se comuniquen y compartan información dentro de una red. Para esto es necesario establecer una serie de reglas para la comunicación y para la forma en que se va a manejar la información. Estas reglas deben ser conocidas por las máquinas que se están comunicando, esto quiere decir que los protocolos se encargan de manipular la información tanto desde el punto de vista del envío como desde el punto de vista del recibo. Por esta razón estos protocolos deben ser conocidos tanto por la máquina origen como por la máquina destino de la información, y es. 6.

(7) IEL1-2002-II-04. muy importante que ambas máquinas manejen los mismos protocolos para poder establecer una buena comunicación. Hay dos protocolos básicos en este sistema. El primero de ellos es el protocolo IP (Internet Protocol), este trabaja sobre la capa de red, y se encarga de enviar los diferentes paquetes de información a su dirección destino. El segundo, es el protocolo TCP (Transmission Control Protocol), este trabaja en la capa de transporte, y se encarga de fragmentar la información en paquetes de tamaño adecuado para ser pasados a través de la red.. 1.1 PROTOCOLO IP Como se había dicho antes, la principal función del protocolo IP es enviar los paquetes de información a su dirección destino.. Para esto se añade un. encabezado al paquete, que contiene información necesaria para trasladar los paquetes desde el emisor hasta el receptor. El protocolo IP se encarga de buscar las rutas a través de la red que permitan transportar los paquetes de información desde el emisor hasta el receptor, pero no se preocupa mucho por hacer que estos paquetes lleguen ordenados o sin retrazo a su destino, esta función la lleva a cabo el protocolo TCP en la capa inmediatamente superior. El encabezado usado por IP para cumplir su función incluye información a cerca de la dirección de origen, la dirección de destino, la longitud total del mensaje, una identificación del paquete, etc.. Todos estos datos son usados por los. distintos enrutadores por los que pasan los paquetes para tomar decisiones acerca del camino que se debe tomar hasta el destino. En la siguiente gráfica se puede observar la estructura de un encabezado IP.. 7.

(8) IEL1-2002-II-04. Bit 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 Versión. IHL Tipo de servicio Longitud total DF MF Identificación Fragment offset Tiempo de vida Protocolo Header checksum Dirección del origen Dirección del destino Opciones (cero o más palabras). Figura 1. Encabezado IP. El tamaño de este encabezado es variable debido al campo Opciones, de esta forma se hace necesaria la presencia de un campo que le diga al receptor cual es el tamaño del encabezado. El campo IHL dice la longitud total del encabezado. [1] El campo Versión indica la versión del protocolo IP al que pertenece el encabezado.. En la actualidad se usa la versión 4, aunque existen otras. propuestas como la versión 6 [11].. En esta última se hacen algunas. simplificaciones y mejoras en el encabezado, pero hasta el momento la versión 4 es la que está adoptada para su uso en los estándares de Internet. [12]. Tipo de servicio le dice a los enrutadores por los que pasa el paquete la clase de servicio se está pidiendo, esto quiere decir, si el mensaje tiene prioridad, si se necesita más confiabilidad, etc.. Hasta ahora este campo no se usa, y los. enrutadores simplemente lo ignoran. El campo de identificación sirve para decirle al receptor a que mensaje pertenece el paquete. Todos los paquetes de un mismo mensaje tienen la misma identificación. En el siguiente campo están los bits DF y MF. Si el bit DF está activo, el mensaje no se puede fragmentar y se debe buscar una forma de enviarlo que involucre una red que soporte paquetes de ese tamaño. El bit MF le dice al receptor si hay más fragmentos de ese mensaje, o si el fragmento que se recibió ya es el último.. 8.

(9) IEL1-2002-II-04. Fragment offset dice a que parte del datagrama pertenece el fragmento. Tiempo de vida, es un contador que al llegar a cero hace que el datagrama se descarte, y se manda una señal de aviso al emisor. Este contador hace que no halla datagramas dando vueltas por la red para siempre. [1] El campo Protocolo le dice a IP en el receptor a que protocolo de transporte se debe entregar el datagrama, una opción es TCP, pero también hay UDP. Para entregar los datagramas en su destino, el protocolo IP debe escoger el camino a seguir dentro de la red. Este proceso se llama enrutamiento, y los computadores encargados de tomar estas decisiones son los enrutadores. Cada vez que un datagrama llega a un enrutador este lee la dirección IP del receptor en su encabezado, y busca la forma más fácil de hacerlo llegar hasta su destino. Para esto cada enrutador tiene unas tablas donde se encuentran los posibles destinos y la forma de llegar a ellos [5]. Las direcciones IP guardan un esquema que permite a cada máquina por la que pasa el datagrama saber a que red pertenece el receptor, de esta forma los enrutadores no necesitan saber a que máquina específicamente va el datagrama, sino a que red. Una vez el mensaje llega a la red específica, los enrutadores de ahí en adelante pueden empezar a buscar la dirección IP del receptor.. Esto. ayuda a mantener las tablas de un tamaño aceptable y simplifica el proceso de búsqueda de la dirección. Del mismo modo las tablas solo tienen información a cerca del siguiente enrutador que se debe buscar, no del camino completo para llegar hasta el receptor. Como ya se vio, un mensaje que se envía a través de la red, debe pasar por distintos enrutadores hasta llegar a su destino.. Estos enrutadores reciben. mensajes de varias fuentes. Puede ocurrir que en el momento de la llegada de un mensaje en particular, el enrutador se encuentre transmitiendo otro mensaje. Como el mensaje que acaba de llegar no puede ser desechado, este es guardado en una cola mientras el enrutador se desocupa, y esto mismo se hace con los 9.

(10) IEL1-2002-II-04. otros mensajes que sigan llegando.. En la actualidad, estas colas se manejan. siguiendo un esquema FIFO (o drop tail) con el cual se van procesando los mensajes en el mismo orden en que van llegando, y cuando la cola se encuentra con su capacidad copada, los nuevos mensajes que llegan son desechados. El esquema drop tail presenta facilidad de implementación, y permite un buen desempeño de la red cuando se está en condiciones de garantizar capacidades suficientes para las colas. El problema surge al crecer el tráfico por encima de los valores esperados, o al empezar a ser más estrictos frente a problemas como la pérdida de datagramas. Para responder mejor a las diferentes exigencias que se le hacen a la red, y ofrecer una mejor calidad de servicio (QoS) se cuenta con otros esquemas de manejo de colas, estos difieren en la forma en que despachan los mensajes que están esperando y en la forma en que eliminan mensajes al coparse las capacidades.. 1.2 PROTOCOLO TCP El protocolo TCP se encuentra en la capa de transporte. Esta se encarga de ofrecer una comunicación confiable desde el origen hasta el destino, y para esto se ayuda del protocolo TCP.. Dentro de cualquier comunicación se pueden. presentar problemas como pérdidas de paquetes, llegada de paquetes desordenados, etc.. TCP se encarga de que todos los paquetes lleguen a su. destino y que se puedan ordenar una vez estén allí. Para que TCP pueda empezar a transmitir los datos a través de la red se necesita que el receptor y el transmisor se hayan comunicado previamente y ambos acepten la transmisión estableciendo una conexión entre ellos.. Una vez la. conexión se ha establecido, se empieza la transmisión de los datos, para esto se divide los mensajes en bytes y se empaqueta varios de estos dentro de un mismo. 10.

(11) IEL1-2002-II-04. segmento. Estos segmentos se empiezan a transmitir de un lado a otro hasta que se transmite el mensaje completo, y se puede soltar la conexión. Para asegurarse que los paquetes enviados llegan a su destino, cada vez que el receptor recibe un paquete nuevo origina un mensaje de confirmación llamado ACK. Estos mensajes de confirmación le dicen al emisor que la transmisión se va desarrollando de forma adecuada y que se puede seguir adelante sin problemas. No es necesario esperar la llegada del ACK de un segmento que se acaba de transmitir para enviar el siguiente segmento, esto haría la transmisión muy lenta. En lugar de esto TCP maneja una ventana móvil que le permite enviar varios segmentos antes de recibir el ACK del primero. Como su nombre lo indica esta ventana se va moviendo a través del mensaje a medida que se van recibiendo los ACK de segmentos ya enviados.. Los segmentos permanecen al interior de la. ventana si pueden ser enviados antes de la llegada de un nuevo ACK, o si ya han sido enviados pero su ACK no se ha recibido. En el siguiente diagrama se muestra el funcionamiento de esta ventana. [3] Apuntador de inicio de ventana Apuntador de división entre segmentos enviados y segmentos por enviar Apuntador de fin de ventana Ventana inicial: Ya se envió el primer segmento 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. Desplazamiento del apuntador central: A medida que se envían segmentos se desplaza el apuntador. 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 10. 11. 12. 13. 14. 15. 16. Llegada de un nuevo ACK: Se desliza la ventana 1. 2. 3. 4. 5. 6. 7. 8. Figura 2. Ventana deslizante TCP. 11. 9.

(12) IEL1-2002-II-04. Como se aprecia en el diagrama, el manejo de la ventana se hace por medio de tres apuntadores que se encargan de limitarla, y separar los octetos enviados de los no enviados. El tamaño de esta ventana no es siempre el mismo, este puede ir variando dependiendo de la congestión percibida en la red en cada momento. Para comenzar, TCP va probando la capacidad de la red, y de acuerdo a esto va aumentando la ventana, hasta llegar a cierto límite. Así como el protocolo IP, TCP también le pone un encabezado a cada segmento que va a enviar. Este encabezado es usado por la entidad TCP del receptor, para identificar el segmento recibido y ubicarlo en la posición correcta dentro del mensaje. Bit. 1. 2. 3. 4. 5. 6. 7. 8. 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32. Source port. Destination port Sequence number Acknow ledgement number. HLEN. URGACKPSHRSTSYNFIN Checksum. Window s ize Urgent Pointer. Options (cero o más palabras de 32 bits) Data (opcional). Figura 3. Encabezado TCP. El campo número de secuencia, dice la posición dentro del mensaje del segmento actual. El campo número de confirmación, dice el número del octeto que la fuente espera recibir enseguida. En HLEN está la longitud del encabezado, que puede variar dependiendo de la información consignada en el campo de opciones. Para establecer una conexión entre dos máquinas, lo primero que TCP hace es verificar que ambas máquinas se encuentren listas para empezar el flujo de información, esto se hace por medio de la siguiente secuencia: El emisor envía un mensaje con el bit SYN activado, cuando el receptor recibe este mensaje, envía otro con el bit SYN, y el bit ACK activados, esto quiere decir. 12.

(13) IEL1-2002-II-04. que está confirmando el mensaje del emisor y que va a continuar con la comunicación. A continuación el emisor envía otro mensaje de confirmación para el mensaje del receptor, y la comunicación se ha establecido. El protocolo TCP también cuenta con una serie de temporizadores que se usan para tener un mayor control sobre el flujo de información, y la forma como los segmentos están llegando a su destino. Uno de estos temporizadores es el de retransmisión. Este es inicializado por el emisor al enviar un mensaje, y si antes de que termine la cuenta no se ha recibido la respectiva confirmación, el mensaje es retransmitido.. Otro. temporizador usado por TCP, es el keepalive timer, cuando la conexión ha estado sin uso durante cierto tiempo, este temporizador hace que uno de los lados revise que el otro siga conectado, si se detecta una desconexión (el otro lado no responde), entonces se da por terminada la conexión. [1] Todos estos temporizadores son usados por TCP para asegurar una buena respuesta del sistema a la transmisión de datos, pero esta no es la única forma de actuar frente a problemas en la transmisión. En cuanto a esto existe una serie de algoritmos que se implementan junto con TCP para lograr mejores respuestas en cuanto a velocidad de transmisión, respuesta a congestión, y demás problemas que se pueda presentar en una red.. 1.3 CONTROL DE CONGESTIÓN EN TCP El problema de la congestión en las redes es muy común, y puede ocurrir por diversos factores como capacidad pequeña de las redes, uso de estas para otras transmisiones al mismo tiempo, etc.. 13.

(14) IEL1-2002-II-04. Como se había visto antes TCP maneja una ventana móvil para la transmisión de los datos, pero el tamaño óptimo de esta puede variar de red a red, e incluso con el tiempo dentro de una misma red. Si esta ventana es mayor a lo que en ese momento puede soportar el sistema se empezará a perder paquetes, y esta es la primera indicación que se tiene de congestión en el sistema. 1.3.1 Slow Start y Congestion Avoidance En las primeras implementaciones que se hizo de TCP, a este se le equipo con unos algoritmos que permitían al sistema llegar a un buen tamaño de ventana probando la red y aumentando poco a poco la ventana hasta que se detectaba que el sistema estaba en su límite. Estas son slow start, y congestion avoidance. [4] El algoritmo Slow start se usa para probar la red al comenzar una transmisión. La idea principal es comenzar con un tamaño de ventana chiquito, e irlo aumentando cada vez más rápido a medida que se va detectando que la red responde bien. Para implementarlo se usa nuevas variables al protocolo TCP, estas son: cwnd (congestion window), rwnd (receiver’s advertised window), y ssthresh (slow start threshold). Cwnd le dice al emisor que tamaño de ventana puede manejar, es decir, la cantidad de segmentos que puede enviar antes de recibir un ACK del primero. Rwnd define el tamaño de la ventana que el emisor puede manejar. Ssthresh le dice al sistema si debe usar Slow start o Congestion avoidance para definir el tamaño de la ventana de transmisión. Para empezar una transmisión, Slow start define el tamaño de la ventana como menor o igual a 2*SMSS. SMSS es el tamaño máximo de segmento que el emisor puede enviar medido en bytes. [5] A medida que empiezan a llegar los ACK de cada uno de los mensajes enviados, el tamaño de la ventana (cwnd) se empieza a incrementar en un SMSS por cada ACK recibido. Este proceso sigue hasta que cwnd sobrepasa el valor de ssthresh. 14.

(15) IEL1-2002-II-04. Para empezar ssthresh se hace igual al tamaño de rwnd, pero este se puede ir cambiando a medida que aumenta la congestión.. Cuando cwnd sobrepasa. ssthresh, la actualización del valor de cwnd se hace de la siguiente forma: Cwnd = cwnd + SMSS*SMSS/cwnd Esta actualización hace que cwnd aumente más despacio que como lo venía haciendo antes, de esta forma, cuando la red está cerca de su máxima capacidad de transferencia, el tamaño de la ventana aumenta más lentamente evitando caer rápidamente en problemas de congestión. 1.3.2 Fast Retransmit y Fast Recovery Una señal de congestión en una red es la pérdida de segmentos, esto se puede detectar en el lado del receptor cuando se determina que hace falta un segmento anterior al último que llegue. En este caso se emite un ACK duplicado para avisarle al emisor que no se tiene todos los segmentos en el destino. El segmento faltante puede llegar después de un tiempo corto, en cuyo caso solo se ha tratado de un retardo, o puede que definitivamente no llegue, en este caso por cada nuevo segmento que llegue se vuelve a enviar un ACK duplicado. Después de tres ACK duplicados seguidos que lleguen al emisor se puede tener una mayor seguridad de que se perdió un segmento, y se debe proceder a retransmitirlo, aún antes de que el temporizador de retransmisión haya terminado su cuenta. En este punto entran en juego dos nuevos algoritmos, estos son Fast Retransmit y Fast Recovery.. La misión de estos es retransmitir el segmento perdido, y. recuperar la transmisión sin tener que usar Slow Start. Los pasos usados en estos algoritmos son los siguientes: [5] 1. Al llegar tres ACK duplicados seguidos, se hace: ssthresh = max (Flightsize/2, 2*SMSS). 15.

(16) IEL1-2002-II-04. Donde Flightsize representa la cantidad de datos en bytes, que han sido enviados por el emisor y de los cuales no se ha recibido confirmación, esto es la cantidad de datos que todavía se encuentran en la red. 2. Se retransmite el segmento perdido y se hace: cwnd = ssthresh + 3*SMSS Esto se hace ya que al haber recibido tres ACK duplicados, se sabe que tres de los segmentos que se habían enviado ya han llegado al receptor y por lo tanto no están consumiendo recursos de red. 3. Por cada ACK duplicado extra que se reciba, se hace: cwnd = cwnd + SMSS 4. Transmitir un nuevo segmento, si se puede. Esto lo determina los valores de cwnd y rwnd. 5. Cuando llegue el primer ACK no duplicado, que indica la llegada de nuevos datos, se hace: cwnd = ssthresh En este paso se disminuye el tamaño de cwnd a un tamaño de ventana en el que no se había presentado problemas, y se continúa con el algoritmo de congestion avoidance ya que cwnd va a ser mayor que ssthresh. Estos cuatro algoritmos son los más básicos que hay y los que se implementan más comúnmente en las redes Internet, sin embargo existen otras propuestas como los algoritmos SACK, D-SACK, y ECN entre otros.. 16.

(17) IEL1-2002-II-04. 1.4 PROPUESTAS PARA MEJORAR EL SERVICIO DESDE EL PROTOCOLO IP En cuanto al protocolo IP, al trabajar este en la capa de red, el enfoque que se usa para afrontar problemas de congestión y tráfico en la red es muy distinto. La principal tarea de IP es entregar la información en su destino, pero no se preocupa por ver si los paquetes llegaron completos, ordenados o retardados. Para tener una buena comunicación es muy importante la calidad de servicio (QoS) que brinda el sistema. Esta calidad de servicio tiene que ver con aspectos como los retardos percibidos, la llegada de la información completa a su destino, etc. Dependiendo de la aplicación que se vaya a usar depende la calidad de servicio exigida, por ejemplo si se quiere transmitir un archivo por FTP de un computador a otro, es muy importante que la información llegue completa, pero si lo que se busca es establecer una comunicación de voz entre dos computadores, es muy importante que el retardo no sea muy grande. Como cada aplicación requiere una calidad de servicio diferente, resulta difícil escoger el parámetro al que se le va a dar mayor importancia en la red, y tratar de garantizar todos los parámetros resultaría muy costoso. En la actualidad el tráfico de una red IP se maneja siguiendo una política del mejor esfuerzo (best effort). Bajo está política todas las aplicaciones y flujos que pasan por una red, compiten de igual forma por los recursos de red disponibles. Este modelo había funcionado bien durante algún tiempo, pero al masificarse el uso de Internet y al desarrollarse nuevas aplicaciones, este esquema no responde adecuadamente a los parámetros exigidos a la red [7]. Cuando se presenta congestión en una red, los niveles exigidos a determinados parámetros empiezan a fallar, y el sistema deja de estar en capacidad de ofrecer la calidad de servicio deseada. Aquí surge la necesidad de evitar la congestión en la red, y de buscar la forma de administrar los recursos de red de una forma más adecuada.. 17.

(18) IEL1-2002-II-04. La principal forma en la que un usuario puede percibir congestión en la red es mediante el retardo experimentado por la información que está transmitiendo. La principal causa de este retardo es el tiempo que deben esperar los paquetes en las colas de los enrutadores mientras esperan a ser atendidos. Existen tres enfoques para manejar el tráfico en una red IP, estos son: Best Effort, Servicios Integrados , y SERVICIOS DIFERENCIADOS. La primera es la que actualmente se usa. En ella no se hace ninguna clase de diferenciación entre los distintos flujos presentes en la red, y todos ellos deben competir entre si, en igualdad de condiciones para obtener recursos de red y transmitir su información. Con Servicios Integrados se busca tener un ancho de banda reservado para cada aplicación, de esta forma la que más recursos de red consuma, va a ser la que mayor ancho de banda reservado tendrá. El modelo de Servicios Integrados hace un paralelo con el modelo ATM en cuanto a la forma en que se administra el tráfico de información dentro de la red. [6] Por otro lado con el esquema de SERVICIOS DIFERENCIADOS se busca crear un punto medio entre los dos modelos anteriores, no se va a reservar recursos para cada flujo, pero sí se le va dar un trato distinto a cada uno. Para esto se establecen los distintos parámetros de desempeño exigidos a cada aplicación y de acuerdo a esto se trata a los paquetes de cada una de ellas con distintas prioridades dentro de la red. Este modelo establece un sistema de prioridades que lleva a proponer un manejo distinto de las colas en los enrutadores. Como se había explicado anteriormente, cada enrutador de la red posee una cola a la cual llegan todos los paquetes de información. Estas colas son administradas siguiendo un esquema FIFO. Si en una red se empieza a presentar mucho tráfico, las colas de los enrutadores empiezan a llenarse, y dejan de admitir los nuevos mensajes que lleguen. Estos nuevos paquetes son simplemente desechados.. 18.

(19) IEL1-2002-II-04. La idea principal detrás de SERVICIOS DIFERENCIADOS es la de marcar los flujos pertenecientes a las distintas aplicaciones que se tenga de tal forma que se permita al sistema darle un distinto manejo a cada uno de ellos. La forma de implementar Servicios Diferenciados en los enrutadores de una red será explicada en el capítulo siguiente.. 19.

(20) IEL1-2002-II-04. 2. SERVICIOS DIFERENCIADOS. Como se vio anteriormente, no todas las aplicaciones exigen los mismos parámetros de desempeño para la red, y bajo el esquema del mejor esfuerzo, que es el que se usa actualmente, se hace imposible garantizar que cada una de ellas reciba el tratamiento que requiere. De ahí nace la necesidad de diferenciar entre los distintos flujos que pasan a través de una red, para de esta forma darle un tratamiento más adecuado a cada uno de ellos. Cuando una aplicación en particular requiere un mejor tratamiento, esto se traduce en unos tiempos de transmisión menores. La mayor causa de demoras en la transmisión es el tiempo que deben esperar los paquetes en las colas de los enrutadores hasta que puedan ser atendidos. Para ofrecer un mejor servicio a las aplicaciones que así lo requieran se debe buscar reducir el tiempo que estas deben esperar en las colas de los enrutadores. Servicios Diferenciados permite hacer esto marcando cada paquete en su encabezado IP para diferenciar los distintos flujos y poder darle a cada uno un tratamiento adecuado al interior de la red. Al implementar Servicios Diferenciados en una red, no se necesita que todo el camino que sigue un paquete desde su origen hasta su destino maneje este esquema. redes.. Para llegar hasta su destino un paquete debe atravesar diferentes. Cuando el paquete entra a la frontera de una red que usa Servicios. Diferenciados, se determina el comportamiento que va a tener dentro de esa red, y se marca el paquete en un campo (Campo DS) de su encabezado IP. Cuando sale de esta red y pasa a otra red que no usa Servicios Diferenciados,. 20.

(21) IEL1-2002-II-04. este paquete es simplemente tratado como cualquier otro, y se ignora la información del campo DS. 2.1 CAMPO DS. EN EL ENCABEZADO IP. Cada vez que un paquete entra a una red que usa el esquema de Servicios Diferenciados es clasificado y marcado en el campo DS de su encabezado IP. Para marcar los paquetes se va a usar el antiguo campo Tipo de Servicio, que ahora va a ser llamado campo DS. Se pensó en usar este campo ya que aunque este campo está definido dentro del estándar actual de Internet, es ignorado por la mayoría de los enrutadores.. Cuando se pensó en crear el campo Tipo de. Servicio se hizo con la idea de definir algunas características generales del servicio que cada paquete requería. Pero en la práctica este campo no se usa, y los enrutadores simplemente lo ignoran. Bit 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 Versión. IHL Tipo de servicio Longitud total DFMF Identificación Fragment offset Tiempo de vida Protocolo Header checksum Dirección origen Dirección destino Opciones (cero o más palabras). Figura 4. Encabezado IP con el campo de tipo de servicio resaltado. El campo DS está dividido en dos partes, una llamada DSCP compuesta por seis bits, y otra llamada CU, compuesta por dos bits, que están reservados para otras aplicaciones, y por lo tanto son ignorados por los enrutadores de una red DS [9].. Bit. 8. 9. 10. 11. DSCP Figura 5. Campo DS. 21. 12. 13. 14 CU. 15.

(22) IEL1-2002-II-04. La información almacenada en DSCP es usada por el nodo frontera de la red para clasificar cada uno de los paquetes dentro del flujo a que corresponde y de esta forma darles el tratamiento adecuado al interior de la red. Cuando se propuso el modelo inicial del encabezado IP, se había reservado los bits del campo TOS para definir la clase de servicio requerida por el paquete, pero para ello se usaba clases generales, como mínimo retrazo, o mínimo costo, y de acuerdo a este escoger la ruta que mejor se ciñera a estas características. La propuesta del campo DS es ser un poco más específico en cuanto al tratamiento de un paquete, asignando distintas clases a cada código DS reconocido por el enrutador [10]. De esta forma la información del campo no se usa para escoger una ruta determinada, sino para escoger el tratamiento que va a recibir el paquete en cada uno de los enrutadores al interior de la red. El principal motivo para haber escogido usar el campo TOS para servicios diferenciados es mantener la compatibilidad con el sistema actual, de esta forma si un paquete que ha sido marcado en su campo DS llega a una red que no usa el esquema de Servicios Diferenciados no va a causar ningún problema, ya que estas redes están acostumbradas a ver los encabezados IP con este campo. Un nodo que no usa Servicios Diferenciados simplemente ignora el contenido de este campo, y el paquete es retransmitido de la misma forma que todos los demás paquetes que llegan a ese nodo.. 2.2 ENRUTADORES DE UN DOMINIO DS Es muy importante distinguir la labor cumplida por los enrutadores en los límites de la red, y los enrutadores al interior de la red. Los enrutadores de la frontera están encargados de tomar las decisiones, y por lo tanto requieren de una implementación más complicada, mientras que los del interior simplemente siguen las decisiones tomadas por los primeros [10].. 22.

(23) IEL1-2002-II-04. Cuando un paquete llega a un enrutador frontera de una red de Servicios Diferenciados, el enrutador debe clasificarlo de acuerdo a las reglas que se sigan dentro de ese dominio DS, y de esta forma determina un comportamiento para ese paquete al interior de la red. Esta clasificación es la que permite darle a todos los paquetes pertenecientes a un mismo flujo el mismo tratamiento, mientras que paquetes de flujos distintos recibirán tratamientos diferentes. Cada. clasificación. corresponde. a. un. comportamiento. específico,. estos. comportamientos son denominados PHB (per-hop behavior) y determinan la forma en que los paquetes son reenviados y manejados por cada enrutador al interior de la red. En la mayoría de los casos las diferencias en los tratamientos de los paquetes son derivadas de una política de manejo de colas determinada en cada enrutador [9]. Cuando un paquete llega a un enrutador se clasifica en un PHB dependiendo del flujo al que pertenezca. Todos los paquetes de un mismo flujo son clasificados en el mismo PHB, pero en el mismo PHB se puede clasificar también varios flujos, formando así un agregado de flujos que van a tener el mismo comportamiento dentro de la red. Los PHB pueden especificar determinado ancho de banda, determinado tamaño de cola, cierta prioridad respecto a los demás PHB, o características como el retardo que se espera tenga el agregado de flujos [10].. La forma de. implementar un grupo de PHB dentro de un nodo es determinando reglas para manejo de espacio en las colas, y programación del orden de atender paquetes. Dentro de las recomendaciones que se han hecho sobre la forma de implementar los diferentes PHB en un nodo, se dice que debe existir un default PHB, en el cual se van a clasificar los paquetes con ningún código en el campo DS, o con un código que no corresponda a ninguno de los utilizados en ese nodo. [9].. El. comportamiento que van a tener los paquetes que hayan sido asignados a este comportamiento va a ser el de mejor esfuerzo (Best Effort) existente en las redes actualmente. 23.

(24) IEL1-2002-II-04. La clasificación se hace por agregados.. Flujos pertenecientes a un mismo. agregado recibirán el mismo tratamiento. Por esta razón se espera que los flujos de un mismo agregado tengan las mismas exigencias en cuanto a sus parámetros de desempeño. Por último se debe aclarar que la forma de implementar Servicios Diferenciados se ha propuesto de tal forma que sea compatible con las actuales condiciones de la red. Si un paquete que ha sido marcado en su campo DS llega a una red que no maneja el sistema de Servicios Diferenciados, no va a causar ningún problema dentro de esta, y será tratado de la misma forma que cualquier otro paquete dentro de esa red.. 2.3 ELEMENTOS DE REDES DS Dentro de una red DS hay una serie de elementos que se encargan de asegurar que se lleve a cabo la diferenciación entre los distintos agregados, y de clasificar cada uno de los paquetes pertenecientes a un flujo dentro del agregado correspondiente. Entre ellos los más importantes son los clasificadores, y los condicionadores de tráfico. Los clasificadores son entidades ubicadas en los límites de la red, y son las encargadas de seleccionar los paquetes que van a ser añadidos a determinado agregado.. Esta selección se hace de acuerdo a la información obtenida del. encabezado IP de cada paquete, y a ciertas reglas previamente definidas para esa red [9]. Si el nodo origen de la información a transmitir se encuentra dentro de una red que usa Servicios Diferenciados, entonces se toma como límite de la red, el primer nodo capaz de marcar los paquetes. En algunas ocasiones el mismo nodo origen hace esta marcación.. 24.

(25) IEL1-2002-II-04. Aunque la clasificación hecha por los clasificadores se basa principalmente en el campo DS, también se ha propuesto que se tenga en cuenta la información dada por otros campos, como la dirección origen del paquete. Otra entidad ubicada en los límites de la red son los condicionadores de tráfico, estos incluyen mecanismos de medición, políticas, y marcadores. La unión de estos elementos es la que define la forma en que un paquete va a ser clasificado y tratado dentro de una red [9]. Después de que un paquete es clasificado por los clasificadores pasa a donde un condicionador de tráfico, que determina la forma en que este es tratado, siguiendo un perfil de tráfico específico. Los perfiles de tráfico dan las reglas para determinar la forma de tratar cada paquete de un flujo específico. Los perfiles de tráfico determinan una política de admisión que depende de alguna medición hecha al paquete, como su tamaño o su tasa de llegada [10].. Si un paquete en particular sobre pasa el límite. especificado para su medición, es declarado fuera de perfil, y se le da un tratamiento distinto bien sea desechándolo, o condicionándolo de alguna forma. El medidor es el encargado de medir y comparar el paquete con el perfil de tráfico específico.. Una vez hecha esta medición le transmite el resultado al. marcador y al shaper, para de esta forma indicarles que acción tomar respecto a ese paquete. Los marcadores se encargan de escribir el valor apropiado en el campo DS de un paquete, de esta forma cada paquete es incluido dentro de un agregado, y tratado como corresponde a ese agregado.. Cuando un paquete ya tiene su. campo DS lleno con un valor, y si ese valor no corresponde con los valores usados en la red específica, o si la medición arroja un resultado distinto, el campo DS es re-escrito por el marcador. Los shapers y los droppers se encargan de asegurar que el agregado se comporte como determina el perfil correspondiente. Los primeros retienen los paquetes durante un tiempo, y los segundos los desechan. Estas acciones se toman para 25.

(26) IEL1-2002-II-04. paquetes que no se ajusten al perfil de tráfico que se seleccionó para ellos. Los shapers retienen los paquetes en una cola, y cuando esta se llena desecha los nuevos paquetes que lleguen. De esta forma el dropper se puede ver como un shaper con capacidad de cola igual a cero [10].. Medidor. Paquetes. Clasificador. Marcador. Shaper / Dropper. Figura 6. Clasificador y condicionador de tráfico. Un conjunto de nodos que maneja las mismas políticas de tratamiento de los paquetes, la misma forma de agregar determinadas aplicaciones, y el mismo conjunto de PHB se llama un Dominio de Servicios Diferenciados. Para asegurar que todos los nodos de un mismo dominio DS sigan las mismas reglas y tengan los mismos PHB, es necesario que todos ellos pertenezcan a una misma administración [10]. Los nodos en la frontera del dominio son los encargados de clasificar los paquetes y se espera que los nodos al interior les den el mismo tratamiento a los paquetes que el designado por los primeros. Puede suceder que existan varios dominios DS colindantes pero que no comparten el mismo conjunto de PHB, y que no tienen las mismas reglas para tratar a los paquetes pertenecientes a un mismo flujo. En este caso se habla de una región de Servicios Diferenciados.. 2.4 SEGURIDAD El principal objetivo de Servicios Diferenciados es brindar un mejor servicio a los flujos que así lo requieran. Para lograr esto se usa la información del campo DS. 26.

(27) IEL1-2002-II-04. Se podría presentar un problema si alguien quisiera utilizar esta característica para obligar a la red a darle un mejor servicio a sus paquetes aún si estos no lo requieren. Esto causaría una degradación del servicio que se quiere garantizar a las aplicaciones más exigentes, ya que la red apreciaría un falso aumento en el flujo de estas. La ventaja que tiene la implementación que se ha propuesto es que se evita este problema al hacer que los nodos en la frontera de un dominio DS revisen cada paquete, lo midan y remarquen. Así todo paquete que va a entrar a un dominio DS tiene que someterse a las mismas reglas que todos los demás, si la marca que trae en su campo DS no corresponde con el resultado arrojado por la medición y clasificación hecha en este nodo, su campo DS es reescrito. Cada dominio DS es responsable de clasificar cada uno de los paquetes que entran de acuerdo a sus propias reglas.. 27.

(28) IEL1-2002-II-04. 3. IMPLEMETACIÓN DE SERVICIOS DIFERENCIADOS CON NS SIMULATOR. Para evaluar el desempeño de la red se usó un simulador desarrollado especialmente para modelar y evaluar redes TCP/IP.. NS Simulator, fue. desarrollado como resultado del proyecto VINT en el cuál participaron la Universidad de California Berckeley, la Universidad del Sur de California, el laboratorio Lawrence Berckeley, y el Palo Alto Research Center de Xerox [13]. NS trae implementados los distintos algoritmos usados en redes Internet, así como las diferentes propuestas que se han hecho para aplicaciones más específicas. Esta característica lo hace adecuado para un estudio como el que se hace en este trabajo, ya que permite evaluar el desempeño de la red Internet como se usa actualmente frente al desempeño que puede tener al usar alguna de las nuevas propuestas. Este simulador fue desarrollado en lenguaje C++, y tiene una interfase con el usuario en lenguaje OTcl. El simulador permite definir diversos parámetros para cada uno de los elementos de la red. También muestra todo el código del programa para hacer posible la acomodación de los distintos elementos a los requerimientos particulares del usuario, en caso de que esto sea necesario [14]. Sin embargo esta ultima opción no se puede usar tan fácilmente ya que hace falta documentación que explique los códigos. NS es un simulador por eventos discretos, y como tal se debe definir los distintos eventos que se van a tener en cuenta. NS se encarga de programar las distintas ocurrencias de estos dentro del desarrollo de la simulación, siguiendo la distribución definida por el usuario.. De esta forma se puede tener tráfico. generado por una fuente on-off que siga una distribución exponencial para los tiempos de actividad / inactividad y que genera tráfico a una tasa constante 28.

(29) IEL1-2002-II-04. definida por el usuario. Otra posibilidad que se tiene para definir los tiempos de los estados de la fuente, es usar una distribución de pareto. También se puede generar tráfico que sigue una distribución exponencial. NS permite definir la topología específica que se quiere usar, especificando nodos y conexiones, así como los protocolos que se van a usar en la red (TCP/reno, TCP/vegas, etc). Cada vez que se desee generar tráfico en la red, se debe especificar los nodos origen y destino de este. Para observar el resultado de las simulaciones, NS puede generar archivos en los que se va guardando la información de los paquetes que pasan por el punto del sistema que se quiere observar, esta información incluye datos como el nodo en que se originó el paquete, el nodo hacia el cual se dirige, la acción que ha ocurrido (llegada del paquete a la cola, desecho del paquete, etc), y el tamaño del paquete, entre otros. [14].. NS no hace ninguna interpretación de esta. información, esto corresponde al usuario del simulador. En este trabajo se usó Matlab para extraer la información que se quería de los archivos y finalmente analizarla. También existe otra clase de archivos que genera NS para permitir una visualización de la topología simulada y del tráfico de los paquetes por la red. Este tipo de archivos se puede abrir usando el visualizador NAM que viene incluido en la distribución de NS. En la siguiente tabla se muestra el orden en que se encuentra esta información dentro de un archivo generado por NS, así como un ejemplo de esta. Acción Tiempo Nodoi Nodof Tipo Tamaño Flag Flujo Origen Destino Secuencia Paquete r 0.156681 23 22 ack 40 ----3 23.16 16.0 0 19 + 0.156681 22 21 ack 40 ----3 23.16 16.0 0 19 + 0.156953 20 21 exp 1040 ----1 4.0 23.4 0 23. Nodoi y nodof representan los nodos iniciales y finales de la conexión que se está teniendo en cuenta, tipo muestra el tipo de tráfico al que pertenece el paquete, y paquete muestra la identificación del paquete que origina la acción [14]. 29.

(30) IEL1-2002-II-04. 3.1 MÓDULO DE SERVICIOS DIFERENCIADOS Para el caso particular de SERVICIOS DIFERENCIADOS, NS trae un módulo para implementar y configurar enrutadores que manejen este esquema. Este módulo fue desarrollado por Nortel Networks y en la actualidad se distribuye como parte del simulador [7]. Este módulo permite configurar los distintos elementos de los enrutadores de un dominio DS y para esto ofrece diferentes alternativas, que serán explicadas en los párrafos siguientes. Como se había dicho antes, SERVICIOS DIFERENCIADOS busca establecer distintos tratamientos para los diferentes agregados de flujo.. Para conseguir esto NS. define hasta cuatro colas en las que van a ser clasificados los flujos que lleguen a cada enrutador. A cada una de estas colas se le asigna un número para que puedan ser identificadas dentro del código de la simulación. No es necesario usar todas las colas de un enrutador en una simulación; se puede usar el número que se desee, mientras este número no pase de cuatro. Estas colas se configuran independientemente, indicando las políticas que se van a seguir para aceptar o no los paquetes en cada una de ellas. Estas políticas son las que determinan los perfiles de tráfico que van a ser tenidos en cuenta dentro del dominio DS que se simula. Se puede usar un perfil distinto para cada flujo que se maneje, pero un solo perfil por cola [7]. Las colas son administradas siguiendo el algoritmo RED (Random Early Detection). El algoritmo RED busca reducir el tamaño promedio de las colas al monitorear constantemente el tamaño de estas. Cuando se empieza a presentar congestión en un enrutador, el tamaño de las colas de este empieza a aumentar. Con el esquema actualmente usado, si los paquetes que llegan sobrepasan la capacidad de las colas, todos los nuevos paquetes son desechados, esto hace que 30.

(31) IEL1-2002-II-04. se genere un ACK duplicado por cada paquete desechado notificando de esta forma a todas las conexiones que existe congestión y que se debe reducir el tamaño de las ventanas CWND.. Esto hace que se presente un efecto de. sincronismo en las conexiones del sistema, ya que todas estarán reduciendo y aumentando sus ventanas al mismo tiempo [8]. La propuesta del algoritmo RED es la de notificar de la presencia de congestión a algunas de las conexiones cuando se empiece a presentar una congestión incipiente. Para hacer esto se escoge probabilísticamente las conexiones de las cuales se van a desechar paquetes. De esta forma se hace que esas conexiones reduzcan sus ventanas, y que las colas en los enrutadores no crezcan tan rápidamente [8]. Con el algoritmo RED se definen dos niveles para monitorear el tamaño de la cola, uno inferior y otro superior. Cuando el tamaño de la cola es menor al nivel inferior, todos los paquetes son aceptados sin problemas, cuando el tamaño de la cola está entre los niveles inferior y superior, los nuevos paquetes que llegan son marcados probabilísticamente para ser desechados, y si el tamaño de la cola es mayor al nivel superior, todos los paquetes nuevos que lleguen son desechados [8].. Desechados Límite superior Marcados probabilísticamente para ser desechados. Límite inferior. Aceptados. Figura 7. Cola RED. 31.

(32) IEL1-2002-II-04. En el caso de NS la probabilidad con la que son desechados los paquetes en momentos de congestión incipiente depende del nivel de precedencia que se le asigne a cada paquete. Dentro de cada cola RED existen tres niveles distintos de precedencia.. Estos pueden ser vistos como tres colas virtuales dentro de la. misma cola real, donde cada una de estas colas virtuales tiene una probabilidad de desecho distinta [7]. Cada vez que un paquete llega a un nodo frontera de un dominio DS, este se clasifica en un PHB que identifica la cola real a la que pertenece.. Esta. clasificación se hace teniendo en cuenta el flujo al que pertenece el paquete. Cada uno de los flujos se identifica mirando el nodo en el que se originó el paquete, de esta forma en un nodo solo se originan paquetes pertenecientes a un mismo flujo. Esta información pasa al medidor, que dependiendo del perfil de tráfico que se maneje en la cola real que se ha identificado, asignará el paquete a una de las colas virtuales. En este momento el paquete es remarcado por el marcador para que de ahí en adelante el paquete siga siendo clasificado en la misma cola virtual. Después de esto el paquete debe entrar a esperar en la cola del shaper hasta que pueda ser atendido. Cada una de las colas virtuales se pueden configurar independientemente y todas usan el esquema RED. En general, los paquetes de una cola con un menor nivel de precedencia tendrán una mayor probabilidad de desecho que los paquetes de una cola con un mayor nivel de precedencia. Con este esquema se sigue con las recomendaciones hechas por [18] sobre la cantidad de grupos y de niveles de precedencia de cada uno de ellos que se debe tener en un nodo DS. En esta configuración se pueden observar todos los elementos de un nodo frontera de un dominio DS. Cada código DS está asociado con un par de colas real / virtual específico, las cuales determinan los distintos PHB presentes en el sistema [7]. En cada nodo frontera existe una tabla PHB, donde se relacionan cada uno de los códigos DS con su cola real / virtual. Estas tablas deben ser 32.

(33) IEL1-2002-II-04. definidas por el usuario del simulador dentro del código escrito por este para realizar la simulación.. Las entradas de esta tabla tienen la siguiente. información: a) Código DS, b) Clase, c) Precedencia. El siguiente es un ejemplo de un pedazo de código usado para definir cada uno de los datos de una tabla PHB: set qE1C [[$ns link $e1 $core] queue] $qE1C addPHBEntry 12 0 2. En la primera línea se define el nombre que se le va a dar al conjunto de todas las colas en el nodo e1 que almacenan el tráfico que se dirige hacía el nodo core. En la segunda línea, después de identificar el conjunto de colas en el que se va a trabajar viene el comando para adicionar una entrada a la tabla, seguido del código DS que se va a definir, el número de la cola real, y el número de la cola virtual. En este ejemplo se está definiendo que el código DS 12 se clasifica en el par de colas real / virtual: 0 / 2. Para configurar los distintos perfiles de tráfico que van a ser usados dentro del dominio DS se usa la siguiente línea: $qE1C addPolicyEntry [$s(0) id] [$dest id] srTCM 10 $cir1 $cbs1 $ebs1. En esta se define que el tráfico que viaja del nodo s(0) al nodo dest debe ser medido usando una política srTCM [15] con los valores de referencia cir1, cbs1, y ebs1. Al mismo tiempo se dice que este tráfico corresponde al código DS 10. En el código se debe añadir una línea como ésta por cada par de nodos origen y destino que se tenga en la simulación. El simulador usa cinco tipos de políticas distintos para definir los perfiles de tráfico a usar en la red: TSW2CM, TSW3CM [16], Token Bucket, srTCM [15], y trTCM [17]. Cada uno de estos utiliza factores distintos para medir el tráfico [9]. Estas políticas se basan en la generación de tokens que permitan la transmisión de los paquetes que llegan a cada nodo. Cuando un paquete llega a un nodo y no 33.

(34) IEL1-2002-II-04. hay tokens suficientes para transmitirlo este debe esperar.. Los tokens se. generan a una tasa determinada, y son guardados en un balde, de tal forma que cuando no llegan paquetes, los tokens son almacenados para cuando puedan ser usados.. TABLA I FACTORES PARA MEDIR EL TRÁFICO TSW2CM CIR TSW3CM CIR PIR Token Bucket CIR CBS srTCM CIR CBS EBS trTCM CIR CBS PIR. PBS. La tabla anterior muestra los parámetros que se deben tener en cuenta para definir las políticas a ser usadas en las simulaciones. CIR representa la tasa a la cual se generan tokens en el sistema. CBS representa el número máximo de tokens que se puede mantener.. PIR representa la tasa a la que se generan. tokens en el balde de exceso. EBS, y PBS representan el número máximo de tokens de exceso que se puede mantener [7]. El uso de estas políticas favorece la utilización de las colas virtuales: cuando el flujo pasa a través de los medidores, y es comparado con los valores de referencia, se puede determinar a que nivel de precedencia de la cola pertenece. Con estas políticas se puede tener dos o tres niveles de precedencia. Para determinar a que cola virtual pertenece cada uno de los paquetes que llegan, estos son medidos (bien sea en su tamaño o su tasa de llegada), y de acuerdo al número de tokens presente en el sistema se le asigna un nivel de precedencia diferente a cada paquete. Volviendo al ejemplo visto anteriormente, el tráfico que llega proveniente del nodo s(0) va a ser medido usando un perfil srTCM con tasa de generación de tokens cir1. Si en el momento de la llegada de un paquete hay suficientes tokens 34.

(35) IEL1-2002-II-04. en el balde principal entonces al paquete se le asigna la mayor precedencia. Si no hay suficientes tokens en el balde principal, pero sí en el balde de exceso, se le asigna la precedencia intermedia, y si no hay suficientes tokens en ninguno de los dos, el paquete se ubica en la cola virtual de menor precedencia. Como se había dicho antes, cada vez que un paquete es ubicado en una cola de menor precedencia este debe ser remarcado con un nuevo código DS. Para que el simulador sepa cómo debe remarcar estos paquetes se usa la siguiente línea de código, en la cual se especifica que si un paquete que llega al nodo se ajusta al flujo identificado con el código DS 10, este debe ser remarcado con 11 para indicar una precedencia intermedia, o 12 para la precedencia menor. $qE1C addPolicerEntry srTCM 10 11 12. Finalmente se debe configurar las colas RED usando los parámetros adecuados: a) nivel inferior, b) nivel superior, y c) probabilidad de desecho. Para esto se usa la siguiente línea de código, donde se configura la cola virtual 1 de la cola real 0, para tener un nivel inferior de 20, nivel superior de 40, y probabilidad de desecho de 0.02, estos parámetros se manejan como se explica en [8]. $qE1C configQ 0 1 20 40 0.02. Hasta este momento se ha explicado la forma en que se configura cada una de las colas en un enrutador, pero no se ha dicho nada de la forma en que cada una de ellas va a ser atendida. En este sentido NS presenta varias posibilidades. Entre ellas están: (Priority) [7].. RR (Round Robin), WRR (Weighted Round Robin), y PRI. En la forma de atender las colas es donde se generan las. diferencias entre los tratamientos que se le puede dar a cada flujo. Al programar el simulador para que atienda los flujos usando una política RR, todas las colas reciben el mismo tiempo de atención dentro de cada una de las rondas. Con una programación de atención WRR, se define un peso diferente para cada cola, de tal forma que se permite despachar mayor número de paquetes de unas que de otras, mientras se asegura que siempre se manda por lo 35.

(36) IEL1-2002-II-04. menos un paquete de cada cola. No sucede lo mismo al usar la programación PRI en la cual la cola con mayor prioridad va a ser atendida primero que las demás, pero se corre el riesgo de que la cola de menor prioridad no sea atendida. Para decirle al simulador la disciplina de programación de colas que se va a usar se escribe una línea de comando como la siguiente, en la cual se especifica una programación WRR. $qE1C setSchedularMode WRR. Para este caso en particular se debe especificar los pesos asignados a cada cola En el siguiente ejemplo se asigna un peso de 5 a la cola real 0, un peso de 4 a la cola real 1, y un peso de 1 a la cola real 2. $qE1C addQueueWeights 0 5 $qE1C addQueueWeights 1 4 $qE1C addQueueWeights 2 1. Como se había dicho en capítulos anteriores, los nodos de la frontera de un dominio DS se configuran distinto que los nodos del interior.. Los nodos del. interior simplemente siguen la clasificación hecha en la frontera.. Para. configurar los nodos interiores basta con llenar las entradas de la tabla PHB, y determinar el comportamiento de cada cola definiendo sus límites inferior y superior, y la probabilidad de desecho para cada nivel de precedencia. Es muy importante que los nodos del interior tengan la misma configuración de los nodos de la frontera, esto quiere decir, el mismo número de colas reales, el mismo número de niveles de precedencia, y los mismos códigos DS. Esto se debe hacer para asegurar la compatibilidad del sistema en todos sus nodos.. 3.2 TOPOLOGÍA SIMULADA El objetivo principal de este trabajo es evaluar el desempeño del esquema de SERVICIOS DIFERENCIADOS en una red Internet. 36. Para esto se usó una topología.

(37) IEL1-2002-II-04. consistente en una serie de fuentes con un destino común. Esta topología se simuló para dos casos: usando un dominio DS que uniera las fuentes y los destinos, y usando una red que no maneje este esquema. En ambos casos la red que une las fuentes con el destino representa un cuello de botella para el tráfico y las colas de los enrutadores empiezan a llenarse con los paquetes que deben esperar hasta ser atendidos. Para las fuentes de este sistema, se usaron cuatro tipos de tráfico distinto, representando cada uno de ellos una aplicación diferente. A cada una de las aplicaciones se le dio diferentes características para simular distintos tipos de tráfico, aunque ninguna corresponde a características reales de una aplicación existente. Dos de las aplicaciones tienen las mismas exigencias en cuanto a calidad de servicio y por lo tanto van a ser clasificadas en el mismo agregado, de manera que solo es necesario usar tres colas reales en cada enrutador DS. La aplicación 1 exigirá un mejor tratamiento que las demás, mientras que las aplicaciones 3 y 4 tendrán la menor prioridad dentro del sistema, y serán clasificadas dentro del mismo agregado por tener exigencias similares. Los paquetes de cada una de las aplicaciones son generados siguiendo un proceso de Poisson con una tasa distinta para cada una, y con un tamaño distinto de paquete, para de esta forma poder darle a cada aplicación características distintas.. Aunque ninguna de ellas corresponde a una aplicación real, se. escogieron características distintas para asemejar las simulaciones a lo que ocurre en la realidad. También es importante notar que se buscó tener una red congestionada, para de esta forma observar el comportamiento de las colas en los enrutadores ante los dos esquemas de manejo de tráfico. Los parámetros usados para la generación de paquetes fueron los siguientes:. 37.

(38) IEL1-2002-II-04. TABLA II. PARÁMETROS DEL TRÁFICO Aplicación Tamaño Tasa (bps) (bytes) Apl. 1 64 64 Apl. 2 512 1500 Apl. 3 512 128 Apl. 4 1500 1000. Los perfiles de tráfico de todos los flujos están definidos con una política srTCM, que implica usar las tres colas virtuales disponibles para implementar los distintos niveles de precedencia que tiene cada uno de los perfiles de tráfico. Para satisfacer los requerimientos de prioridad que tiene cada una de las aplicaciones se usó un esquema de programación de atención a las colas WRR, dándole un peso de 5 a la cola de la aplicación 1, un peso de 4 a la cola de la aplicación 2, y un peso de 1 a la cola de las aplicaciones 3, y 4. Todo esto se ve definido en el siguiente pedazo de código: $qE1C set numQueues_ 3 $qE1C setNumPrec 3 $qE1C setSchedularMode WRR $qE1C addQueueWeights 0 5 $qE1C addQueueWeights 1 4 $qE1C addQueueWeights 2 1. La topología empleada para hacer las simulaciones es la siguiente, donde se puede observar la forma en que están conectados los distintos nodos de la red. Se tiene cuatro aplicaciones que entran al dominio de SERVICIOS DIFERENCIADOS por el mismo nodo, y comparten todas un destino común.. 38.

(39) IEL1-2002-II-04. Apl. 1 Apl. 2. Apl. 3. Apl. 4. Edge. Core. Edge. Dest. Cuello de botella. Figura 8. Topología usada. Aunque en este esquema aparece solo un nodo por cada aplicación, en realidad se usaron varias fuentes del mismo tipo, que generan paquetes de cada una de estas aplicaciones. Para unir los nodos de generación con el dominio DS se usan enlaces de 200 Mbps, que aseguran que ningún paquete sufra retardos en estos enlaces. En las distintas simulaciones hechas se varió el número de conexiones de la aplicación 1 aumentándolas de cinco en cinco desde 5 hasta 35.. Al ser la. aplicación 1 la de mayor prioridad, se varió el número de conexiones de ésta, ya que el dominio DS hará todo lo posible por atender los paquetes de esta aplicación sacrificando la atención que se le brinda a las otras aplicaciones. De esta forma se puede ver la forma en que el sistema va a responder ante congestión. TABLA III. NÚMERO DE CONEXIONES DE CADA APLICACIÓN Aplicación Número de conexiones Apl. 1 Variable entre 5 y 35 Apl. 2 3 Apl. 3 9 Apl. 4 8 39.

(40) IEL1-2002-II-04. El cuello de botella se garantiza usando un enlace de 20 Mbps dentro de la red, , de esta forma varios de los paquetes deben esperar en las colas de los enrutadores y se puede observar las diferencias en su comportamiento con cada uno de los esquemas. Como parámetro de desempeño para evaluar el comportamiento de las redes se usó el retardo sufrido por los paquetes en el primer enrutador de la red. Para comparar este parámetro, se usó tanto el retardo promedio sufrido por todos los paquetes, así como el retardo máximo sufrido por alguno de los paquetes atendidos en ese enrutador.. 40.

(41) IEL1-2002-II-04. 4. RESULTADOS. NS Simulator puede monitorear el comportamiento de cada uno de los paquetes que llegan a una cola. Para hacer esto se escribe en un archivo de texto la información referente a cada uno de los paquetes que llegan a ésta.. Esta. información incluye datos del paquete como identificación, tiempo en el que se produjo el evento, flujo al que pertenece, etc, siguiendo el esquema mostrado en el capitulo anterior.. La información es guardada cada vez que ocurre un. evento en el sistema, y los eventos que son registrados en estos archivos son: a) la llegada de un paquete a la cola, b) la atención de un paquete que estaba en cola, c) el recibimiento de un paquete en el otro extremo del enlace, y d) el desecho de un paquete de la cola. Pero como se había explicado antes NS no hace ningún tipo de análisis de los datos. Para esto se debe extraer la información relevante de los archivos, y analizarla usando otro programa. En este trabajo, los archivos fueron procesados con Matlab para obtener los datos que permitieran realizar las mediciones de los parámetros de desempeño buscados. Los códigos de los programas usados se encuentran en los anexos al final del trabajo. El primero de estos programas permite leer los archivos .tr arrojados por el simulador, y extraer información que permita calcular el tiempo que cada paquete esperó en cola. Para esto se debe leer el tiempo en que cada paquete llega a la cola, y usando la identificación del paquete buscar el tiempo en que el paquete fue atendido. Dependiendo del flujo al que pertenezca el paquete esta información es guardada en uno de cuatro archivos.. 41.

(42) IEL1-2002-II-04. El segundo programa permite calcular el tiempo medio de retardo, y extraer el retardo mayor experimentado por un paquete para cada una de las aplicaciones. Se va a empezar analizando el comportamiento de los dos sistemas frente al retardo promedio en cola que sufren los paquetes al pasar por la red. Para hacer esto se va a tener en cuenta el comportamiento de las colas en el primer enrutador de la red, o sea, donde empieza el cuello de botella del sistema, ya que es acá donde los paquetes van a experimentar congestión por primera vez, y donde van a ser desechados si las colas se empiezan llenar. Al observar el comportamiento de la red que no usa SERVICIOS DIFERENCIADOS, se ve cómo todas las aplicaciones reciben el mismo tratamiento. El retardo medio que los paquetes de cada una de estas aplicaciones experimenta en la cola del enrutador es similar. Esto es explicable, ya que al no usar SERVICIOS DIFERENCIADOS solo se usa una cola en los enrutadores y no se hace ninguna clase de distinción entre los flujos, todos ellos reciben el mismo tratamiento dentro de la red. En este caso todas las aplicaciones compiten en igualdad de condiciones por los recursos de red, que se reparten dependiendo del orden de llegada de los paquetes a la cola.. Aplicación1. Aplicación2. Aplicación3. Aplicación4. 80 70. Retardo (ms). 60 50 40 30 20 10 0 0. 5. 10. 15 20 Conexiones apl. 1. Figura 9. Retardo medio en cola – No DS. 42. 25. 30. 35.

(43) IEL1-2002-II-04. En la gráfica anterior también se puede ver como a partir de 10 conexiones de la aplicación 1, el comportamiento de la cola es similar para todos los casos, esto quiere decir que a partir de ese momento la cola se llena sobrepasando el límite superior de esta, y deja de haber diferencias entre tener más o menos conexiones de cualquier aplicación. El límite superior para la cola en este caso se fijó en 200 paquetes, que equivale a la suma de las capacidades de las cuatro colas usadas para las simulaciones con SERVICIOS DIFERENCIADOS. Por otro lado al observar lo que pasa al usar SERVICIOS DIFERENCIADOS, se ve que la red se preocupa por ofrecer la calidad de servicio requerida a las aplicaciones de mayores exigencias. Esto hace que éstas sean atendidas más rápidamente y por lo tanto los tiempos que deben esperar en cola sean inferiores al compararlos con lo ocurrido en el caso anterior. NS implementa el esquema de SERVICIOS DIFERENCIADOS usando colas RED.. Esta. implementación tiene la ventaja de disminuir el tamaño promedio de las colas, al revisarlas constantemente para decidir si se aceptan o se marcan los paquetes para ser desechados.. Al reducir el tamaño promedio de la cola se puede. disminuir el tiempo que los paquetes deben esperar hasta ser atendidos, y de esta forma se está en la capacidad de ofrecer un mejor servicio a las distintas aplicaciones. En la siguiente gráfica se ve que esto funciona bien mientras la congestión originada por la conexión de mayor prioridad no sea muy grande.. 43.

(44) IEL1-2002-II-04. A plicació n 1. A plicació n2. A plicació n3. A plicació n4. 100 90 80 Retardo (ms). 70 60 50 40 30 20 10 0 0. 5. 10. 15 20 Conexiones apl. 1. 25. 30. 35. Figura 10. Retardo medio en cola - DS. En la gráfica se observa que cuando el número de conexiones de la aplicación 1 no es muy grande los retardos de todas las aplicaciones se mantienen dentro del mismo rango, aunque el retardo para la aplicación 1 es menor. Pero al aumentar considerablemente el número de conexiones de la aplicación 1 que es la de mayor prioridad, el tratamiento dado a los flujos de menor prioridad va a ser afectado negativamente. Cuando el número de conexiones de la aplicación 1 es 35, la mayoría de los recursos de la red son gastados en esta aplicación tratando de ofrecerle el servicio que ésta espera, lo que hace que se descuide el servicio que se presta a los flujos de menor prioridad. Al comparar los tiempos medios para una misma aplicación frente a los dos sistemas, se puede contrastar el tratamiento recibido por aplicaciones de distinta prioridad.. Mientras a la aplicación 1, que tiene la mayor prioridad, se le. garantizan tiempos bajos de retardo, así el enlace se encuentre congestionado, la aplicación 4 se ve afectada por el mejor trato que recibe la aplicación 1. Cuando el número de conexiones de la aplicación 1 sube a 35, el retardo medio sufrido por los paquetes de la aplicación 4 es mayor que cuando no se estaba usando el esquema de SERVICIOS DIFERENCIADOS. 44.

(45) IEL1-2002-II-04. DS. No DS. DS. No DS. 80 100. 70. 90. 60. 80. 50. 70 60. 40. 50. 30. 40 30. 20. 20 10. 10. 0. 0 0. 10. 20. 0. 30. 10. 20. 30. C o n e x io n e s a p l . 1. C o n e x io n e s a p l . 1. Figura 11. a) Retardo medio en cola – Aplicación 1. b) Retardo medio en cola – Aplicación 4. En este último caso se observa un problema que se puede presentar con SERVICIOS DIFERENCIADOS.. Al buscar garantizar un buen servicio para las aplicaciones de. mayores exigencias se puede descuidar las de menor prioridad.. Aunque este. problema solo se evidenció en un caso de congestión excesiva, es un problema que se puede presentar al aumentar el uso de una aplicación que exija una mayor calidad de servicio. El objetivo principal detrás del esquema de SERVICIOS DIFERENCIADOS es ofrecer mejor calidad de servicio a las aplicaciones que transitan por una red, así que cuando se espera que la aplicación de mayor prioridad tenga un volumen de tráfico muy grande, se deben tomar medidas que permitan mantener los parámetros ofrecidos a las demás aplicaciones. Una opción que se tiene para corregir este problema es variar la manera de atender las colas, de tal forma que se siga manteniendo las prioridades de cada agregado. Para este caso se va a seguir manteniendo la política WRR, pero se van a variar los pesos que se la dado a cada cola. Para hacer este cambio se debe seguir teniendo en cuenta que la aplicación de mayor prioridad es la primera, y esto no se puede desconocer dentro del sistema. TABLA IV. Aplicación Apl. 1 Apl. 2 Apl. 3 y 4. PESOS DE LAS COLAS Pesos anteriores 5 4 1. 45. Nuevos pesos 5 4 3.

(46) IEL1-2002-II-04. Al aumentar el peso de la cola de las aplicaciones 3 y 4, de 1 a 3, se logra mejorar el servicio ofrecido a éstos flujos, al mismo tiempo que se conserva el mejor tratamiento ofrecido a las aplicaciones 1 y 2. En un sistema real un cambio de este tipo se debe hacer con mucho cuidado para que se pueda seguir asegurando la calidad de servicio de las aplicaciones de mayor prioridad. Al cambiar el servicio ofrecido a un flujo, los demás flujos se ven afectados, y la calidad de servicio brindada a ellos también cambiará. Eso se puede observar en la siguiente gráfica, donde al comparar el resultado obtenido para la aplicación 1 con el del esquema de pesos anterior se ve que se presentó un aumento en el retardo promedio que experimentaba esta aplicación. Sin embargo el objetivo principal del nuevo esquema de pesos era el de poder brindarle un mejor servicio a las aplicaciones 3, y 4, incluso ante el caso de mayor congestión de este estudio. Al observar la gráfica se ve como con este esquema de pesos se cumple con ese objetivo.. Aplicación 1. Aplicación 2. Aplicación 3. Aplicación 4. 45 40. Retardo (ms). 35 30 25 20 15 10 5 0 0. 5. 10. 15 20 Conexiones Apl. 1. 25. 30. 35. Figura 12. Retardos medios DS, al variar el peso de la cola 2. En la anterior gráfica se ve que incluso cuando hay 35 conexiones de la aplicación 1 se pudo seguir manteniendo un buen nivel de servicio para las aplicaciones 3 y 46.