Arquitectura de balanceo de carga dinámico para la lógica de conmutación EtherChannel

Transcripción

1 PONTIFICIA UNIVERSIDAD JAVERIANA Arquitectura de balanceo de carga dinámico para la lógica de conmutación EtherChannel Jaime Alejandro Carlos Navarro Pontificia Universidad Javeriana Facultad de Ingeniería Bogotá, Colombia 2013

2

3 Arquitectura de balanceo de carga dinámico para la lógica de conmutación EtherChannel Jaime Alejandro Carlos Navarro Tesis en modalidad Profundización presentada como requisito parcial para optar por el título de: Magister en Ingeniería Electrónica con énfasis en Telecomunicaciones Director: Ing. LUIS CARLOS TRUJILLO ARBOLEDA, M.Sc. Línea de Investigación: Redes y Sistemas de Telecomunicaciones Pontificia Universidad Javeriana Facultad de Ingeniería Bogotá, Colombia 2013

4

5 A mi amada esposa quien con su entereza ante las adversidades me enseñó que siempre será posible lo imposible si aprendemos a quitar esa palabra de nuestras mentes y que donde los demás fracasan, nosotros venceremos.

6

7 NOTA DE ACEPTACIÓN Director del proyecto Jurado Jurado NOVIEMBRE DE 2013

8

9 Resumen El uso eficiente de la infraestructura de conmutación es un aspecto crítico en los objetivos de administración de red de las empresas que proveen servicios de comunicación masivos y de transporte de datos. Ciertamente las necesidades crecientes de ancho de banda están conduciendo el desarrollo y estandarización de nuevas tecnologías LAN y WAN del tipo Ethernet. Sin embargo, los entes de estandarización como IEEE reconocen que la tendencia del mercado siempre conducirá a mayores anchos de banda; y en cierto grado a aumentar la penetración de tecnologías existentes como 40Gigabit Ethernet y disminuir los costos actuales de despliegue 100Gigabit Ethernet. Cisco ha desarrollado una tecnología llamada EtherChannel cuyo objetivo es asistir a los usuarios en el crecimiento de la infraestructura de conmutación Ethernet de acuerdo a necesidades puntuales optimizando las inversiones relacionadas con el proceso (capex de infraestructura). Las implementaciones basadas en EtherChannel posibilitan una mejor explotación de la infraestructura existente agregando hasta ocho enlaces Ethernet del tipo FastEthernet, Gigabit Ethernet o 10Gigabit Ethernet en un canal lógico con un ancho de banda potencial de hasta 160Gbps full dúplex. El método de asignación de carga de esta tecnología se conoce como Hashing de Bits el cual localiza tráfico en los enlaces que hacen parte del canal agregado de acuerdo a un análisis de patrones binarios de la cabecera de los paquetes, sin tener en cuenta la ocupación en esos medios, aspecto que localiza a este método en el grupo de algoritmos de asignación de carga estáticos. La dependencia del desempeño del método en mención con los patrones de tráfico, naturaleza de las aplicaciones y nuevas tendencias en los servicios de red conlleva a una utilización desbalanceada del canal lógico por parte del método. Este trabajo aborda la consideración de un método de asignación de carga dinámico para la utilización de múltiples enlaces de comunicaciones en el marco de la tecnología EtherChannel, por medio del diseño y propuesta de una arquitectura de conmutación orientada a mejorar la utilización global del grupo de interfaces agregadas, la medición del desempeño, así como la detección temprana y reacción proactiva ante condiciones de tráfico en ráfaga de manera que pueda optimizarse el nivel de utilización del canal lógico y se extienda la vida útil de la infraestructura. Los resultados de este trabajo pretenden ser un soporte para futuras investigaciones orientadas a optimización de los métodos considerados, simulación con infraestructura Ethernet e implementaciones en plataformas hardware. Aspectos clave: 40GigabitEthernet; 100GigabitEthernet; EtherChannel; Infraestructura de Conmutación; Método de Asignación de Carga; Hashing de Bits; Algoritmos de Asignación de Carga Estáticos y Dinámicos; Tendencias en los Servicios de Red; Vida Útil de la Infraestructura; Capex.

10

11 Abstract The efficient deployment of the switching network infrastructure is a critical fact in the network management objectives of the enterprises that provide massive customers and data transport communication services. Indeed, the bandwidth growing needs are driving the development and standardization of the LAN/WAN Ethernet technologies. However, standardization bodies like IEEE recognize that market trends will ever drive towards more bandwidth; and, in some degree, to increase the existing network technologies penetration like 40Gigabit Ethernet, and to reduce the current 100Gigabit Ethernet unfolding costs. Cisco has developed a network technology called EtherChannel whose objective is to assist customers in the Ethernet switching infrastructure growing according to specific needs optimizing the investments related to the mentioned process (infrastructure capex). EtherChannel-based deployments make possible a better use of the existing infrastructure bundling up to 8 Ethernet links FastEthernet, Gigabit Ethernet or 10Gigabit Ethernet in a logical link with a potential bandwitdh up to full duplex 160Gbps. The EtherChannel s load allocation method is known as Bits Hashing which allocates traffic into the links that are part of the aggregate channel according to a bit pattern analysis of the packet s headers without take into account the links utilization, fact that locates this method into static load allocation algorithms group. The Bits Hashing method dependency with traffic patterns, applications nature and new network services trends leads to an unbalanced utilization to the logical channel. This work tackles the consideration of a dynamic load allocation method for the utilization of multiple communication links framed under EtherChannel technology, by means of the design and proposal of a switching architecture oriented to getting better the global utilization of the bundled links group, performance measurement as well as early detection and proactive reaction to burst traffic conditions so that logical channel utilization level can be optimized and it could be possible to extend the network infrastructure life cycle. The work results expect to be a technical support for future researches oriented to optimization of the methods taken into account, Ethernet infrastructure simulation, and hardware platforms deployments. Keywords: 40GigabitEthernet; 100GigabitEthernet; EtherChannel; Switching Infrastructure; Load Allocation Method; Bits Hashing; Static and Dynamic Load Allocation Algorithms; Network Services Trends; Infrastructure Duty Life Cycle; Capex.

12

13 CONTENIDO CONTENIDO Resumen... I Abstract... II CONTENIDO... III LISTA DE FIGURAS... VI LISTA DE TABLAS... XII LISTA DE TÉRMINOS Y ABREVIATURAS... XIII INTRODUCCIÓN... 1 Descripción del Problema - Justificación... 3 Objetivo General... 7 Objetivos Específicos (Alcance)... 7 Limitantes y Exclusiones (Alcance)... 8 Organización del Documento MARCO TEÓRICO TECNOLOGÍA DE CONMUTACIÓN ETHERCHANNEL CONCEPTOS SOBRE SIMULACIÓN MODELADO DE RED E INTRODUCCIÓN A LA SIMULACIÓN CLASIFICACIÓN DE LOS SIMULADORES INTRODUCCIÓN AL SIMULADOR OPNET SUITE DE APLICACIONES OPNET OPNET MODELER ESPECIFICACIONES PRESENTACIÓN DE ARQUITECTURA PROPUESTA ESPECIFICACIÓN OPERATIVA DE LA ARQUITECTURA ESPECIFICACIÓN MODULAR DE LA ARQUITECTURA Módulo SWFabric_Processor Módulo StatisticsPoller Módulo LeastLoad_Analysis...22

14 Arquitectura de balanceo de carga dinámico para la lógica de conmutación EtherChannel Módulo SM_Reqs_Queue Módulo EtherChannel_HA_Algorithm Módulo WeightsLoad_Settings Módulos Collector Conjunto de Módulos SM_Ctrl_Switch RoundRobin Scheduler RoundRobin Deficit.28 3.DESARROLLOS IMPLEMENTACIÓN DE NODO DE CONMUTACIÓN EN OPNET MODELER VALIDACIÓN DEL MODELO DE NODO EN OPNET Módulo LeastLoad_Analysis Módulo SM_Reqs_Queue Módulo EtherChannel_HA_Algorithm Módulo SWFabric_Processor Módulo StatisticsPoller Módulo WeightsLoad_Settings Módulos SM_Ctrl_Switch RoundRobin Scheduler RoundRobin Deficit Módulos Collector Estadísticas programadas ANALISIS DE RESULTADOS PLAN DE SIMULACIONES DEL PROYECTO Modelo de Tráfico de Entrada Definición de Estadísticas y Parametrización del Modelo de Red EJECUCIÓN DE PLAN DE SIMULACIONES ANÁLISIS DE RESULTADOS Análisis de resultados Simulación No. 1 (Método Hashing de Bits > src-ip) Análisis de resultados Simulación No. 1 (Método Hashing de Bits > dst-ip) Análisis de resultados Simulación No. 1 (Método Hashing de Bits > src-dst-ip) Análisis de resultados Simulación No Análisis de resultados Simulación No Análisis de resultados Simulación No Análisis de resultados Simulación No

15 CONTENIDO 5.CONCLUSIONES BIBLIOGRAFÍA ANEXOS Anexo A: PROCESO DE VALIDACIÓN DEL MÓDULO SM_REQS_QUEUE...72 Anexo B: PROCESO DE VALIDACIÓN DEL MÓDULO SWFABRIC_PROCESSOR...75 Anexo C: PROCESO DE VALIDACIÓN DEL MÓDULO STATISTICSPOLLER...77 Anexo D: PROCESO DE VALIDACIÓN DEL MÓDULO WEIGHTSLOAD_SETTINGS...79 Anexo E: PROCESO DE VALIDACIÓN DE MÓDULOS SM_CTRL_SWITCH - ROUNDROBIN SCHEDULER - CONJUNTO ROUNDROBIN DEFICIT...83 Anexo F: PROCESO DE VALIDACIÓN DEL MÓDULO COLLECTOR...89

16

17 LISTA DE FIGURAS LISTA DE FIGURAS Figura 1. Proyecciones de demanda de ancho de banda del IEEE HSSG:... 1 Figura 2. Comportamiento Diario Interfaz Gi0/15 THDPCB (Cisco3400) THDPolo1 (Cisco7600):... 4 Figura 3. Comportamiento Diario Interfaz Gi0/13 THDPCB (Cisco3400) THDPolo1 (Cisco7600):... 4 Figura 4. Comportamiento Diario PortChannel Po1 THDPCB (Cisco3400) - THDPolo1 (Cisco7600):.. 4 Figura 5. Delta Tráfico Inbound Outbound interfaces participantes EtherChannel THDPCB (Cisco3400) THDPolo1 (Cisco7600):... 4 Figura 6. Comportamiento en una base horaria Interfaz EtherChannel Po3 THBGoliat (Cisco7606) THBSuba2 (Cisco6500):... 5 Figura 7. Comportamiento en una base diaria Interfaz EtherChannel Po3 THBGoliat (Cisco7606) THBSuba2 (Cisco6500):... 5 Figura 8. Comportamiento en una base semanal Interfaz EtherChannel Po3 THBGoliat (Cisco7606) THBSuba2 (Cisco6500):... 5 Figura 9. Ambiente de simulación para el modelado de comportamiento y desempeño de los diferentes algoritmos de balanceo de carga:... 6 Figura 10. Canal lógico EtherChannel entre dos plataformas de conmutación Cisco:... 9 Figura 11. Diagrama de Flujo de la Simulación basada en Tiempo: Figura 12. Diagrama de Flujo de la Simulación basada en Eventos Discretos: Figura 13. Editor de Proyectos de OPNET Modeler: Figura 14. Editor de Nodos de OPNET Modeler: Figura 15. Editor de Procesos de OPNET Modeler: Figura 16. Diagrama de bloques de arquitectura modificada del nodo de conmutación propuesto con especificación de señales unidireccionales y señalización de control: Figura 17. Arquitectura propuesta operando en Modo Normal: Figura 18. Arquitectura propuesta operando en Modo Recuperación: Figura 19. Las operaciones de gestión de tráfico inbound son controladas por un multiplexor estadístico de salida y una cola atendida a una tasa específica, lo cual propone un modelo de módulo SwitchFabric_Processor conmutando tráfico outbound exclusivamente: Figura 20. Topología estrella entre los módulos Collector y el módulo StatisticsPoller : Figura 21. Señalización considerada en el modelo de nodo de la arquitectura propuesta: Figura 22. Ilustración de la operación del conjunto RRD Algorithm. La subcola q_7 controla el inicio y finalización del recorrido de las subcolas durante el modo Recuperación: Figura 23. Diagrama de bloques del módulo SM_Ctrl_Switch : Figura 24. Modelo de nodo diseñado en OPNET Modeler para la arquitectura propuesta del nodo de conmutación: Figura 25. Modelo de red de ambiente de simulación con subredes generando tráfico hacia dos nodos que implementan la arquitectura propuesta:... 32

18 Arquitectura de balanceo de carga dinámico para la lógica de conmutación EtherChannel Figura 26. Modelo de red de subred 0 con 8 estaciones de trabajo que generan tráfico TCP/IP: Figura 27. Modelo de red de subred 1 con 8 estaciones de trabajo que generan tráfico TCP/IP: Figura 28. Exposición de parametrización de generadores de entidades TCP/IP en el modelo de red OPNET: Figura 29. Parametrización de la operación del nodo EtherChannelADV_X en el modelo de red OPNET: Figura 30. Modelo de Proceso OPNET del módulo LeastLoad Analysis : Figura 31. Modelo de Nodo para validación del módulo LeastLoad Analysis : Figura 32. Flujo de mensajes y señalización esperada para la operación del módulo LeastLoad Analysis : Figura 33. Señalización involucrada en la operación del módulo LeastLoad Analysis : Figura 34. Contenido de los vectores de prueba que consolidan los valores promedio de tráfico para el grupo de ocho interfaces: Figura 35. Flujo de paquetes de prueba durante la simulación controlada: Figura 36. Contenido del paquete ID 91: Figura 37. Contenido del paquete ID 90: Figura 38. Paquete ID 92 resultado de la operación del módulo LeastLoad Analysis : Figura 39. Contenido del paquete ID 92: Figura 40. Flujo de paquetes de prueba durante la simulación controlada: Figura 41. Contenido del paquete ID 64: Figura 42. Contenido del paquete ID 63: Figura 43. Paquete ID 65 resultado de la operación del módulo LeastLoad Analysis : Figura 44. Contenido del paquete ID 65: Figura 45. Modelo de Proceso OPNET del módulo SM_Reqs_Queue : Figura 46. Modelo de Proceso OPNET del algoritmo Hashing de Bits de EtherChannel: Figura 47. Modelo de Red para validación del modelado del algoritmo de asignación de carga de EtherChannel: Figura 48. Modelo de Nodo en el cual fue aislado el módulo EtherChannel_HA_Algorithm objeto de validación: Figura 49. Direcciones IP origen y destino asignadas al generador de tráfico para fines de construcción de las entidades IP: Figura 50. Parametrización del módulo EtherChannel_HA_Algorithm : Figura 51. Flujo de paquetes hacia el módulo EtherChannel_HA_Algorithm durante validación: Figura 52. Mensajes de simulación para el paquete ID 5 que confirman direcciones IP y el contenido del campo ici_id con el índice de la interfaz: Figura 53. Parametrización del módulo EtherChannel_HA_Algorithm : Figura 54. Flujo de paquetes hacia el módulo EtherChannel_HA_Algorithm durante validación: Figura 55. Mensajes de simulación para el paquete ID 3 que confirman direcciones IP y el contenido del campo ici_id con el índice de interfaz:... 40

19 LISTA DE FIGURAS Figura 56. Parametrización del módulo EtherChannel_HA_Algorithm : Figura 57. Mensajes de simulación que confirman direcciones IP para un paquete procesado y el campo ici_id con el índice de la interfaz 5 : Figura 58. Modelo de Proceso OPNET para el módulo SWFabric_Processor : Figura 59. Modelo de Proceso OPNET para el módulo StatisticsPoller : Figura 60. Modelo de Proceso OPNET para el módulo WeightsLoad_Settings : Figura 61. Modelo de Proceso OPNET para el módulo SM_Ctrl_Switch : Figura 62. Modelo de nodo de conmutación donde se destaca el conjunto modular que implementa el algoritmo RRD ( SM_Ctrl_Switch RoundRobin_Scheduler Conjunto RoundRobin_Deficit ):. 43 Figura 63. Modelo de Proceso OPNET para el módulo de subcola q_0 q_6: Figura 64. Modelo de Proceso OPNET para el módulo de subcola q_7: Figura 65. Modelo de Proceso OPNET para el módulo Collector : Figura 66. Estadística Estado de Sistema : Figura 67. Estadística Retardo de Procesamiento Nodal : Figura 68. Plan de Simulaciones del Proyecto: Análisis de resultados Simulación No. 1 (Método Hashing de Bits > src-ip) Figura 69. Ocupación Outbound promedio de enlaces de salida: Figura 70. Frecuencias para observaciones de tráfico saliente: Figura 71. Ocupación Inbound promedio de enlaces de salida: Figura 72. Frecuencias de observaciones de tráfico entrante: Figura 73. Retardo de Procesamiento Nodal: Figura 74. CDF Retardo de Procesamiento Nodal: Análisis de resultados Simulación No. 1 (Método Hashing de Bits > dst-ip) Figura 75. Ocupación Outbound promedio de enlaces de salida: Figura 76. Frecuencias para observaciones de tráfico saliente: Figura 77. Ocupación Inbound promedio de enlaces de salida: Figura 78. Frecuencias de observaciones de tráfico entrante: Análisis de resultados Simulación No. 1 (Método Hashing de Bits > src-dst-ip) Figura 79. Ocupación Inbound promedio de enlaces de salida: Figura 80. Frecuencias de observaciones de tráfico entrante: Figura 81. Ocupación Outbound promedio de enlaces de salida: Figura 82. Frecuencias de observaciones de tráfico saliente: Figura 83. Retardo de Procesamiento Nodal: Figura 84. CDF Retardo de Procesamiento Nodal:... 52

20 Arquitectura de balanceo de carga dinámico para la lógica de conmutación EtherChannel Análisis de resultados Simulación No. 2 Figura 85. Ocupación Outbound promedio de enlaces de salida (Alpha 25%): Figura 86. Estadística Estado de Sistema (Alpha 25%): Figura 87. Frecuencias de observaciones de tráfico saliente (Alpha 25%): Figura 88. Ocupación Inbound promedio de enlaces de salida (Alpha 25%):..54 Figura 89. Diagrama de Frecuencias de observaciones de tráfico Inbound (Alpha 25%): Figura 90. Retardo de Procesamiento Nodal (Alpha 25%): Figura 91. CDF Retardo de Procesamiento Nodal (Alpha 25%): Figura 92. Ocupación Outbound promedio de enlaces de salida antes de modificación (Alpha 25%): Figura 93. Ocupación Outbound promedio de enlaces de salida después de modificación (Alpha 25%): 55 Figura 94. Diagrama de Frecuencias de observaciones de tráfico saliente post modificación (Alpha 25%): Figura 95. Estadística Estado de Sistema (Alpha 25%): Figura 96. Ocupación Inbound promedio de enlaces de salida antes de modificación (Alpha 25%): Figura 97. Ocupación Inbound promedio de enlaces de salida después de modificación (Alpha 25%): Figura 98. Diagrama de Frecuencias de observaciones de tráfico entrante (Alpha 25%): Figura 99. Comparación entre CDFs Retardo de Procesamiento Nodal antes (azul) y después (rojo) de modificación propuesta (Alpha 25% - Escala X logarítmica): Análisis de resultados Simulación No. 3 Figura 100. Ocupación Outbound promedio de enlaces de salida antes de modificación (Alpha 15%): Figura 101. Ocupación Outbound promedio de enlaces de salida post modificación (Alpha 15%): Figura 102. Diagrama de Frecuencias de observaciones de tráfico Outbound (Alpha 15%): Figura 103. Diagrama de frecuencias de observaciones de tráfico Outbound post modificación (Alpha 15%): Figura 104. Ocupación Inbound promedio de enlaces de salida antes de modificación (Alpha 15%): Figura 105. Ocupación Inbound promedio de enlaces de salida después de modificación (Alpha 15%):. 57 Figura 106. Diagrama de Frecuencias de observaciones de tráfico entrante pre modificación (Alpha 15%): Figura 107. Diagrama de Frecuencias de observaciones de tráfico entrante post modificación (Alpha 15%): Figura 108. Est. Estado de Sistema (pre modificación) (Alpha 15%): Figura 109. Est. Estado de Sistema (post modificación) (Alpha 15%): Figura 110. Retardo de Procesamiento Nodal pre modificación (Alpha 15%): Figura 111. Comparación entre CDFs Retardo de Procesamiento Nodal pre-post modific. (Alpha 15%):... 58

21 Análisis de resultados Simulación No. 4 LISTA DE FIGURAS Figura 112. Ocupación Outbound promedio de enlaces de salida antes de modificación (Alpha 5%): Figura 113. Ocupación Outbound promedio de enlaces de salida después de modificación (Alpha 5%): 59 Figura 114. Diagrama de Frecuencias de observaciones de ocupación Outbound antes de modificación (Alpha 5%): Figura 115. Diagrama de Frecuencias de observaciones de ocupación Outbound después de modif. (Alpha 5%): Figura 116. Diagrama de Frecuencias de observaciones de ocupación Inbound pre modificación (Alpha 5%): Figura 117. Diagrama de Frecuencias de observaciones de ocupación Inbound post modificación (Alpha 5%): Figura 118. Retardo de Procesamiento Nodal pre modificación (Alpha 5%): Figura 119. Comparación entre CDFs Retardo de Procesamiento Nodal pre (azul) post (verde) modificación (Alpha 5%): Figura 120. Estadística Estado de Sistema (pre modificación): Figura 121. Estadística Estado de Sistema (post modificación): Análisis de resultados Simulación No. 4 (con perturbaciones) Figura 122. Ocupación Outbound de enlaces de salida antes de modificación (Alpha 25%): Figura 123. Frecuencias de observaciones de ocupación enlaces de salida tráfico saliente antes de modificación (Alpha 25%): Figura 124. Ocupación Outbound de enlaces de salida antes de modificación (Alpha 15%): Figura 125. Frecuencias de observaciones de ocupación enlaces de salida tráfico salida antes de modificación (Alpha 15%): Figura 126. Ocupación Outbound de enlaces de salida antes de modificación (Alpha 5%): Figura 127. Frecuencias de observaciones de ocupación enlaces de salida tráfico saliente antes de modificación (Alpha 5%): Figura 128. Ocupación Inbound de enlaces de salida antes de modificación (Alpha 25%): Figura 129. Frecuencias de observaciones de ocupación enlaces de salida tráfico entrante antes de modificación (Alpha 25%): Figura 130. Ocupación Inbound de enlaces de salida antes de modificación (Alpha 15%): Figura 131. Frecuencias de observaciones de ocupación enlaces de salida tráfico entrante antes de modificación (Alpha 15%): Figura 132. Ocupación Inbound de enlaces de salida antes de modificación (Alpha 5%): Figura 133. Frecuencias de observaciones de ocupación enlaces de salida tráfico entrante antes de modificación (Alpha 5%): Figura 134. Estadística Estado de Sistema Escenario con Perturbaciones antes de modificación (Alpha 25%): Figura 135. CDF Retardo de Procesamiento. Nodal (Alpha 25%):... 62

22 Arquitectura de balanceo de carga dinámico para la lógica de conmutación EtherChannel Figura 136. Estadística Estado de Sistema Escenario con Perturbaciones antes de modificación (Alpha 15%): Figura 137. CDF Retardo de Procesamiento Nodal (Alpha 15%): Figura 138. Estadística Estado de Sistema Escenario con Perturbaciones antes de modificación (Alpha 5%): Figura 139. CDF Retardo de Procesamiento Nodal (Alpha 5%): Análisis de resultados Simulación No. 5 Escenario A: 75% de los valores considerados en los cálculos del módulo LeastLoad_Analysis Figura 140. Ocupación Outbound de enlaces de salida (Alpha 25% - 75% valores procesados por LeastLoad_Analysis): Figura 141. Frecuencias de observaciones de ocupación enlaces de salida tráfico saliente (Alpha 25%): 63 Figura 142. Ocupación Inbound de enlaces de salida (Alpha 25% - 75% valores procesados por LeastLoad_Analysis): Figura 143. Frecuencias de observaciones de ocupación enlaces de salida tráfico entrante (Alpha 25%): Figura 144. Estadística Estado de Sistema para el Escenario de Simulación No. 5 con análisis de muestras al 75%: Figura 145. Retardo de Procesamiento Nodal (Alpha 25%): Figura 146. CDF Retardo de Procesamiento Nodal (Alpha 25%): Escenario B: 95% de los valores considerados en los cálculos del módulo LeastLoad_Analysis Figura 147. Ocupación Outbound de enlaces de salida (Alpha 25% - 95% valores procesados por LeastLoad_Analysis): Figura 148. Frecuencias de observaciones de ocupación enlaces de salida tráfico saliente (Alpha 25%): 64 Figura 149. Ocupación Inbound de enlaces de salida (Alpha 25% - 95% valores procesados por LeastLoad_Analysis): Figura 150. Frecuencias de observaciones de ocupación enlaces de salida tráfico entrante (Alpha 25%): Figura 151. CDF Retardo de Procesamiento Nodal (Alpha 25%): Figura 152. Diagrama de bloques de la arquitectura del nodo de conmutación propuesto: Figura 153. Ocupación promedio de enlaces de salida para tráfico saliente Método de Asignación de Carga Hashing de Bits: Figura 154. Diagrama de Frecuencias de observaciones de ocupación Método de Asignación de Carga Hashing de Bits: Figura 155. Ocupación promedio de enlaces de salida para tráfico saliente, después de modificación, Método de Asignación de Carga Propuesto (Alpha 25%): Figura 156. Diagrama de Frecuencias de observaciones de ocupación Método de Asignación de Carga Propuesto (Alpha 25%):... 67

23 LISTA DE TABLAS LISTA DE TABLAS Tabla 1. Utilización de información de cabeceras por parte de la implementación EtherChannel por plataforma Cisco: Tabla 2. Asignación inequitativa de índices a enlaces dentro de configuraciones EtherChannel de 3, 5, 6, 7 enlaces:... 11

24

25 LISTA DE TÉRMINOS Y ABREVIATURAS LISTA DE TÉRMINOS Y ABREVIATURAS Término/Abrev. IDC IEEE HSSG Network Core Streaming P2P Network QoS Capex FastEthernet GigabitEthernet 10Gigabit Ethernet LAN WAN EtherChannel HP-UX Hashing de Bits Throughput SNMP NetFlow IP Overhead DMZ Proxy Firewall UDP TCP Interleaving Descripción International Data Corporation (Empresa líder en proyección, análisis e investigación de mercados especializada en tecnologías de consumo, información y de telecomunicaciones). Institute of Electrical and Electronics Engineers (Instituto de Ingenieros Eléctricos y Electricistas). IEEE Higher Speed Study Group (Grupo de Estudio de Mayor Velocidad del IEEE). Núcleo de Red (Permite enlazar diferentes servicios como Internet, redes privadas, redes LAN o telefonía, entre otros). (Método de transmisión y reproducción de archivos de audio y video por lotes). Redes Punto a Punto (Son redes de computadoras en la que todos o algunos aspectos funcionan sin clientes ni servidores fijos, sino una serie de nodos que se comportan como iguales entre sí). Quality of Service (Calidad de Servicio). Capital Expenditures (Gastos Capitales). (Tecnología de red LAN basada en IEEE con velocidad 100Mbps). (Tecnología de red LAN basada en IEEE con velocidad 1Gbps). (Tecnología de red LAN basada en IEEE con velocidad 10Gbps). Local Area Network (Red de Área Local). Wide Area Network (Red de Área Amplia). (Tecnología propietaria Cisco para agregar enlaces físicos IEEE en canales lógicos). (HP-UX es la versión de Unix desarrollada y mantenida por Hewlett-Packard desde 1983, ejecutable típicamente sobre procesadores HP PA RISC y, en sus últimas versiones, Intel Itanium (arquitectura Intel de 64 bits)). (Método de asignación de carga estático soportado en la tecnología EtherChannel). Rendimiento (Se llama throughput al volumen de trabajo o de información que fluye a través de un sistema). Simple Network Management Protocol (Protocolo de Gestión de Red Simple). (Protocolo de gestión de red propietario Cisco). Internet Protocol (Protocolo Internet). Carga (Se refiere, en el campo de las telecomunicaciones, al tiempo de procesamiento requerido por el código o su implementación para chequeo de errores y control de transmisiones de información). Demilitarized Zone (Zonas Desmilitarizadas). Proxy (En una red informática, es un programa o dispositivo que realiza una acción en representación de otro). Cortafuego (Es una parte de un sistema o una red que está diseñada para bloquear servicios de red y accesos no autorizados). User Datagram Protocol (Protocolo de Datagramas de Usuario). Transport Control Protocol (Protocolo de Control de Transporte). Entrelazado (Método utilizado para compensar los efectos de pérdida de paquetes en la transmisión de flujos en sistemas de audio y video en tiempo real).

26 Arquitectura de balanceo de carga dinámico para la lógica de conmutación EtherChannel RTP/RTCP Jitter Packet Loss Round Robin Weighted Round R. Random Least Connection Least Load PagP LACP OPNET DES FSM Real Time Transport Protocol / Real Time Transport Control Protocol (Protocolo de Transporte en Tiempo Real / Protocolo de Control de Transporte en Tiempo Real). Fluctuación (Variación indeseada y abrupta de la propiedad de una señal). Pérdida de Paquetes. Round Robin (Método de Asignación de Carga). Round Robin Ponderado (Método de Asignación de Carga). Aleatorio (Método de Asignación de Carga). Menor Conexión (Método de Asignación de Carga). Menor Carga (Método de Asignación de Carga) Port aggregation Protocol (Protocolo de Agregación de Puertos). Link Aggregation Control Protocol (Protocolo de Control de Agregación de Enlaces, definido en el estándar IEEE 802.3ad). OPtimized NETwork Engineering Tools (Herramientas de Ingeniería de Red Optimizadas). Discrete Event Simulation (Simulación de Eventos Discretos). Finite State Machine (Máquina de Estados Finitos).

27 INTRODUCCIÓN INTRODUCCIÓN La demanda de ancho de banda continúa creciendo a nivel mundial. Independientemente de la aceptación de las proyecciones de Cisco o de otras compañías consultoras como IDC, la realidad es que el tráfico está creciendo y deberían adecuarse las redes de acceso y de interconexión con altas velocidades y capacidad. En general, la mejora en el desempeño de una infraestructura Ethernet puede darse con el incremento de sus capacidades en ancho de banda. El nivel de adecuación de la infraestructura no es un aspecto claro pero lo que parece ser evidente es que cuando este aspecto corresponde al incremento de las velocidades Ethernet, la conclusión es que los operadores parecen demandar más velocidades sin considerar el factor de costos de despliegue y mantenimiento, aun cuando claman rápidamente por la estandarización [1]. Para 2007, año del nacimiento del IEEE HSSG, hubo intenso debate acerca de la necesidad de enfocar los esfuerzos en el desarrollo de dos velocidades Ethernet para satisfacer necesidades futuras [2]. Finalmente fue acordado que el tráfico de core y de las aplicaciones de computación estaban creciendo a ratas distintas. Así, se observó que, en promedio, el ancho de banda asociado con el networking de core estaba doblando sus requerimientos cada 18 meses; mientras que la capacidad en ancho de banda asociada con servidores de alto volumen x86 y aplicaciones de computación estaba doblándose cada 24 meses [3]. En la Figura 1 se presentan esas observaciones que condujeron al desarrollo de las tecnologías 40 Gigabit Ethernet y 100 Gigabit Ethernet por parte del IEEE 802.3ba Task Force. Sin embargo, estas proyecciones también llevaron al HSSG a trabajar en el desarrollo de la siguiente velocidad de Ethernet requerida una vez el estándar 100 Gigabit Ethernet fuera terminado. De acuerdo con [2], esta necesidad es corroborada en las proyecciones de la Figura 1, con Ethernet 400Gbps requerida para 2013 (Estado del Arte de esta tecnología) y 1Tbps para Figura 1. Proyecciones de demanda de ancho de banda del IEEE HSSG. Tomado de IEEE Industry Connections Ethernet Bandwidth Assessment. Para los fabricantes, las implementaciones están conduciendo el desarrollo y promoción de nuevos estándares. Tal es el caso de los grandes datacenters quienes están conduciendo las implementaciones Ethernet de 40Gbps [1]. Según mención a conclusiones de un reporte de IEEE en [1] acerca de las proyecciones futuras de ancho de banda de la industria, para 2015 el tráfico debería ser 10 veces el experimentado en 2010 y 100 veces en 2020! Conclusión importante de ese reporte tiene que ver con la tendencia de estandarización por parte del IEEE sobre el particular en la cual se encarnan ciertos miedos a cumplir con el proceso lejos de las expectativas del mercado (tener estándares listos de acuerdo a demanda pero a costos que no tengan sentido para los operadores quienes fuertemente demandan más velocidad sin necesariamente considerar el costo). Ethernet 1Tbps podría ser alcanzado pero su costo sería tal que 1

28 Arquitectura de balanceo de carga dinámico para la lógica de conmutación EtherChannel potencialmente limitaría su penetración en el mercado. Así las cosas, según [1] para 2013 los principales esfuerzos no van dirigidos hacia 400Gbps o 1Tbps; más a hacer de 100Gbps una solución económicamente atractiva. De acuerdo con [2], es proyectado que para 2015 habrá cerca de 15 billones de dispositivos de red fijos y móviles, así como conexiones máquina a máquina. La tendencia a ofrecer más y mejores prestaciones en ancho de banda de acceso y la disponibilidad de dispositivos de usuario de banda ancha propone un escenario en el cual los usuarios estarán constantemente consumiendo ancho de banda posiblemente en múltiples dispositivos simultáneamente. A su vez, cada uno de estos dispositivos soporta múltiples aplicaciones con tráficos importantes y requerimientos de calidad de servicio especiales. Hoy, las aplicaciones multimedia e intranet con necesidades incrementales de ancho de banda conducen la demanda de más y más recurso, mientras que las aplicaciones de misión crítica requieren diseños de red que ofrezcan alta disponibilidad. Así, la demanda de recursos de red por parte de aplicaciones de redes sociales, streaming de audio y video en tiempo real y contenido almacenado, así como de intercambio de archivos P2P, crece a ratas superiores al incremento de disponibilidad de recursos en el core. Tales aplicaciones son en cierto grado dependientes de la calidad de servicio, de manera que la administración de QoS se convierte con su consideración en una mejor solución a la intervención de la infraestructura de muchas redes a nivel mundial [4]. En lugar de considerar ítems en capex asociados al incremento de ancho de banda en el core de la red, la administración de red debe contemplar cuidadosamente los aspectos de QoS necesarios de manera que la gestión de tráfico se vuelva más robusta y la clave de la calidad de servicio de red [5]. Por otra parte, las empresas que han venido enfrentando este desafío con empleos incrementales de Ethernet conmutado en el escritorio, están buscando soluciones de mayor ancho de banda para el core que las capacidades ofrecidas por la tecnología FastEthernet o Gigabit Ethernet. Las soluciones implementadas hoy necesitan proteger las inversiones existentes, mientras provean una trayectoria de migración estable hacia anchos de banda 10Gigabit Ethernet y posteriores [6]. Acerca de la tecnología de conmutación LAN Ethernet, cuya especificación reside en el estándar IEEE 802.3, permite la utilización de enlaces con anchos de banda 10Mbps (Ethernet), 100Mbps (FastEthernet), 1Gbps, 10Gbps, 40Gbps y 100Gbps para soportar diferentes requerimientos de conectividad [7]. En lo referente a sus estrategias de escalamiento de ancho de banda, Cisco ha ampliado el alcance del estándar en sus plataformas y ofrece un método propietario para escalar el ancho de banda Ethernet entre equipos de conmutación por medio del uso simultáneo de múltiples enlaces sin necesidad de recurrir a la actualización tecnológica asociada al cambio de interfaces de velocidad superior [7]. Este método es conocido como EtherChannel, el cual posibilita un ancho de banda agregado, la compartición de carga de tráfico entre los enlaces del canal, así como redundancia en el evento que uno o más enlaces físicos fallen. Hoy, esta tecnología puede ser usada para interconectar muchos conmutadores LAN, enrutadores, servidores y clientes de otros fabricantes por medio de cableado UTP o fibras monomodo o multimodo [8]. A título de ejemplo, Hewlett Packard soporta actualmente la característica Fast EtherChannel en su línea de conmutadores HP1600 y HP8000. Es su vez soportada en múltiples plataformas de sistema operativo y productos LAN, incluyendo HP-UX versión 11.0 y posteriores, y un número selecto de NICs FastEthernet HP9000 [6]. Cisco es un proveedor de infraestructura de red y de telecomunicaciones con soluciones de amplia acogida a nivel mundial por proveedores de servicio de Internet y conectividad, entidades estatales, campus empresariales y académicos, etc. A partir de sus prestaciones, EtherChannel ha tenido gran acogida y aceptación como tecnología de core por quienes soportan sus necesidades de ancho de banda y el crecimiento de las mismas en la utilización de una estrategia basada en enlaces con soporte técnico ya adquirido o existentes en sus plataformas sin tener que recurrir a migraciones tecnológicas hacia versiones superiores de Ethernet que por lo general resultan costosas en la infraestructura de core. Ciertamente, sin la disposición de tecnologías como EtherChannel, a título de ejemplo el monitoreo del factor de ocupación de una única interfaz física Ethernet 100Mbps entre dos equipos de conmutación puede conducir, de acuerdo a los límites de utilización aceptados por una compañía en particular, a una actualización de la tecnología Ethernet utilizada (1Gbps). En este escenario, EtherChannel ofrece a los proveedores de servicio y compañías la oportunidad de utilizar hasta 8 enlaces Ethernet disponibles de 100Mbps con un ancho de banda agregado de 1600Mbps, tasa superior a la ofrecida por Ethernet 1Gbps (aspecto ampliado 2

29 INTRODUCCIÓN en detalle en el capítulo Marco Teórico). Si el crecimiento de ancho de banda conduce a una utilización del enlace EtherChannel cuyo valor de nuevo empieza a superar los umbrales de decisión, la administración de red puede ya con seguridad tomar la decisión de migrar hacia la siguiente versión de Ethernet (1Gbps Ethernet 2Gbps de ancho de banda full dúplex). En conclusión, esta tecnología conduce a un manejo estable y proyectado del capex requerido para infraestructura de interconexión interna y externa. Esta tecnología utiliza un método de asignación de carga a los medios participantes del canal EtherChannel denominado Hashing de Bits el cual verifica ciertos bits en las diferentes cabeceras de los paquetes que están buscando asignación en el grupo de enlaces de salida. Respecto a la clasificación de este método, la asignación de paquetes en el canal lógico no contempla la valoración de la ocupación de los medios, recurriendo entonces exclusivamente a la información de los paquetes para arbitrar la asignación, lo que localiza al Hashing de Bits entre los algoritmos de balanceo de carga estáticos. Así, el algoritmo de EtherChannel no está en capacidad de capturar información de tráfico sobre las interfaces participantes del método y a partir de su ocupación generar proactiva y reactivamente acciones sobre su configuración para balancear las cargas de tráfico. Por estas razones esta tesis de grado se concentra en el diseño y evaluación de una arquitectura de conmutación para la tecnología EtherChannel con capacidad de asignación dinámica de carga de manera que pueda ofrecer un mejor escenario de utilización de los enlaces participantes del método, una gestión de las condiciones de tráfico, así como una base teórico-experimental para futuros trabajos relacionados con optimización de la arquitectura y evaluación en ambientes en producción. Descripción del Problema - Justificación Algunos aspectos operativos de la tecnología EtherChannel impiden aseverar que necesariamente el canal lógico agregado cuenta con un ancho de banda igual a la suma del ancho de banda full dúplex de sus enlaces físicos. A título de ejemplo, el máximo throughput de una conexión EtherChannel de ocho enlaces FastEthernet es 1600Mbps, situación que propone que todos los enlaces constitutivos puedan llegar a cargarse a capacidad total y ser utilizados de forma equitativa por la lógica de conmutación EtherChannel con independencia de la naturaleza del tráfico cursado por el canal lógico. Sin embargo, cada enlace integrante del canal solo transportará las tramas que sean puestas en él por la lógica EtherChannel la cual, de hecho, toma las decisiones de selección de enlaces para envío de tramas basada en un algoritmo de asignación de carga que soporta Hashing de Bits. Este algoritmo, parametrizable por usuario 1, asimila bits pertenecientes a la información origen o destino de los paquetes, o bits resultantes de una combinación matemática de la información origen-destino. Respecto a los patrones binarios insumo del método en mención, son posibles las situaciones en las cuales resulten algunos enlaces favorecidos mayoritariamente por la asignación de carga dada la dependencia a la información de cabeceras del tráfico, lo cual indica que esos enlaces transportarán cargas no consistentes con respecto a otras interfaces. En este escenario, es posible encontrar interfaces participantes del canal lógico con factores de ocupación cercanos al 90% mientras otras interfaces están operando al 50% o menos, siendo las primeras las que conducen a no ofrecer garantías en calidad de servicio, acciones manuales sobre la configuración del método para aliviar las cargas de las interfaces en mención y a inversiones en capex de infraestructura para ampliación del ancho de banda del canal asociado. Los aspectos relacionados con medición y retroalimentación no hacen parte del alcance de la arquitectura EtherChannel y conllevan a sistemas adicionales de gestión para medición y evaluación que ofrezcan información de distribución de carga a los operadores de red quienes deciden el mantenimiento de la configuración actual del método o el cambio de la estrategia. Cisco soporta exclusivamente intervenciones manuales a la configuración EtherChannel del tipo operador, que normalmente generan disrupciones de servicio. Las mediciones de tráfico ofrecidas sobre interfaces 1 Ver Tabla 1. La parametrización del algoritmo de balanceo de carga es una característica dependiente de la plataforma de acuerdo con Cisco: Understanding EtherChannel Load Balancing and Redundancy on Catalyst Switches Document ID: p. 9. 3

30 17:40 19:25 21:10 22:55 00:40 02:25 04:10 05:55 07:40 09:25 11:10 12:55 14:40 16:25 Arquitectura de balanceo de carga dinámico para la lógica de conmutación EtherChannel individuales y el canal lógico EtherChannel responden al acumulado de cada 300 segundos sin mayor detalle de la distribución; e información de hecho solo disponible por medio de protocolos tales como SNMP y NetFlow para utilización en diversos sistemas de gestión de red. Para aclarar estos aspectos, se realiza una evaluación de la medición diaria de tráfico sobre un canal EtherChannel de dos enlaces que ofrece transporte interno entre dos equipos localizados en diferentes ubicaciones de la red Ethernet de Claro Colombia, con las siguientes especificaciones: Análisis de BW Agregado y Físico, estacionalidad sobre un tráfico interno EtherChannel (Diario) : Enlace: THDPCB(Cisco3400) THDPolo1(Cisco7600) Método Hashing Algorithm: source-destination ip Portchannel: 2 GigEth 1Gbps Throughput: 4Gbps. Portchannel enrutado IP. Figura 2. Comportamiento Diario Interfaz Gi0/15 THDPCB (Cisco3400) THDPolo1 (Cisco7600). Figura 3. Comportamiento Diario Interfaz Gi0/13 THDPCB (Cisco3400) THDPolo1 (Cisco7600). Figura 4. Comportamiento Diario PortChannel Po1 THDPCB (Cisco3400) THDPolo1 (Cisco7600). A partir de los datos que respaldan las gráficas de tráfico de las dos interfaces participantes del canal (Figura 2 Figura 3), se obtienen las diferencias para el tráfico entrante y saliente entre las dos interfaces con los resultados presentados en la Figura 5., calculadas para Gi0/15 con respecto a Gi0/13. Dada la naturaleza del tráfico y operación del método de balanceo de EtherChannel, hay situaciones con Gi0/13 más cargado que Gi0/15 y viceversa y de ahí las diferencias negativas en ancho de banda. Para el tráfico entrante llegan a registrarse picos de 70Mbps de diferencia que pueden responder a ráfaga y comportamiento de corto término, lo cual solo es especulación ya que se insiste en el hecho que son deltas de 5 minutos acumulativos sin información alguna acerca de la distribución de tráfico sobre ese periodo. 6,00E+07 4,00E+07 2,00E+07 0,00E+00-2,00E+07-4,00E+07-6,00E+07-8,00E+07 Diff Outbound Diff Inbound Figura 5. Delta Tráfico Inbound Outbound interfaces participantes EtherChannel THDPCB (Cisco3400) THDPolo1 (Cisco7600). 4

31 En el Anexo G (en medio digital), se encuentra la Figura 5 con mayor detalle (Figura G.1). INTRODUCCIÓN Adicionalmente se efectúa un análisis del ancho de banda agregado y estacionalidad sobre el tráfico EtherChannel (Horario Diario Semanal) para la salida internacional (Figura 6, Figura 7 y Figura 8). Enlace: THBGoliat(Cisco7606) - THBSuba2(Cisco6500) Método Hashing Algorithm: source-destination ip Portchannel: 4 GigEth 1Gbps Throughput: 8Gbps Portchannel enrutado IP. Figura 6. Comportamiento en una base horaria Interfaz EtherChannel Po3 THBGoliat (Cisco7606) - THBSuba2 (Cisco6500). Figura 7. Comportamiento en una base diaria Interfaz EtherChannel Po3 THBGoliat (Cisco7606) - THBSuba2 (Cisco6500). Figura 8. Comportamiento en una base semanal Interfaz EtherChannel Po3 THBGoliat (Cisco7606) - THBSuba2 (Cisco6500). El análisis anterior refuerza el concepto que la distribución resultante en las interfaces es aleatoria, dada la naturaleza de los flujos de tráfico (comportamiento de usuario y operación de las aplicaciones) y el hecho que el algoritmo de asignación de carga de EtherChannel procesa ciertos bits de las cabeceras de los paquetes. Así, es claro que, dada la invariabilidad en la información de cabeceras, flujos cursados entre dos hosts siempre utilizarán las mismas interfaces entre el canal EtherChannel. Dos conversaciones distintas pueden llegar a utilizar interfaces participantes EtherChannel diferentes. Sin embargo, de acuerdo al comportamiento de usuario y naturaleza de las aplicaciones, los volúmenes de tráfico en esas interfaces físicas pueden ser totalmente diferentes, razón por la cual en esta tecnología se argumenta la disponibilidad de múltiples esquemas de análisis de información en los paquetes, vía configuración del método. Se supone que la infraestructura EtherChannel funciona y tiene validez cuando un host trata de comunicarse con diferentes hosts o servicios, dando oportunidad a índices de interfaces EtherChannel diferentes. Son variados los esquemas de análisis de información origen destino que adecúan la operación del algoritmo de balanceo y asignación de carga EtherChannel, dependientes de la plataforma de enrutamiento o conmutación. De aquí se desprende que la lógica de conmutación de EtherChannel puede disponer de métodos de relación de información complejos con data de capas superiores lo que a su vez aumenta el overhead del proceso. Sin embargo, la información que menos overhead agrega al algoritmo es la asociada a la cabecera de capa 2 pero ambientes en los cuales se presentan DMZs, proxies y firewalls así como servicios de alto ancho de banda al interior y exterior de las compañías mantienen invariable el direccionamiento capa 2, cargando preferiblemente algunos enlaces con respecto a otros. En general ciertas configuraciones del método de asignación de carga EtherChannel pueden generar distribuciones de paquetes sobre las interfaces que alteran los streamings de aplicaciones en tiempo real (Audio y Video) dada la incapacidad de la lógica para identificar esos flujos UDP y mantenerlos en 5

32 Arquitectura de balanceo de carga dinámico para la lógica de conmutación EtherChannel interfaces únicas aislándolos de la influencia del algoritmo de balanceo de carga. Sin embargo, muchosmétodos asociados con esas aplicaciones contemplan ya el uso de buffers antes de reproducción, RTP/RTCP, números de secuencia, interpolación e Interleaving, etc. que ayudan a conciliar extremo a extremo situaciones en las cuales la multitrayectoria punto a punto inducida en capa 2 pueda desorganizar la información del flujo o inducir jitter, retardo excesivo y packet loss. A partir de las apreciaciones anteriores, resulta factible y paso lógico la consideración de las prestaciones de los algoritmos de balanceo de carga dinámicos en la lógica de conmutación de EtherChannel. El hecho que haya tal nivel de dependencia actual entre la asignación de carga estática de la conmutación EtherChannel, y las características variables del tráfico, comportamiento de usuario, así como con las tendencias de servicio, conducen a un bajo nivel de adaptabilidad de la infraestructura de conmutación, limitando su capacidad y escalabilidad en términos de utilización óptima de recursos e inversiones en infraestructura, respectivamente. La consideración de un método dinámico de asignación y balanceo de carga de tráfico implica la definición de una variable sobre la carga de los recursos que retroalimente el método de conmutación e influencie la asignación de tráfico en las interfaces. Esta variable es de facto la ocupación de los enlaces físicos participantes del método en mención. Respecto a las mediciones de tráfico en una base por enlace actualmente suministradas vía SNMP o NetFlow en plataformas Cisco, primero no son adecuadas para ser consideradas como efectivas desde el punto de vista de retroalimentación para un método de balanceo dinámico ya que son acumulados de bytes de entrada y bytes de salida en un periodo de 300 segundos; por ende cualquier entidad de gestión o administración necesita procesar sendas mediciones como ancho de banda full dúplex y obtener la medición para un segundo (con la consecuente disposición de una medida de bps full dúplex). Aun así, no es válida esta aproximación ya que propone una distribución de tráfico uniforme en el periodo de medición descrito. En adición, acumular mediciones en 300 segundos genera una absorción de las variaciones de tráfico en el corto término y suprime cualquier posibilidad de considerar la medición descrita en un ambiente de reacción rápida de cara a contrarrestar la congestión. En segundo lugar, hay una asociación inmediata de esas mediciones a su uso en herramientas de gestión propietarias que permiten a los clientes de la solución de conmutación evaluar la utilización de la infraestructura así como la toma de decisiones inmediatas y proyectadas sobre las configuraciones más acordes sobre la operación de la plataforma de conmutación. Con aplicación mayoritaria en ambientes de clusters de servicios, los algoritmos de asignación de carga dinámicos pueden alcanzar un buen balanceo de carga en clusters de servidores con recursos heterogéneos dada la consideración de la carga de los servidores y servicios suministrados, pero hace a los algoritmos tipificados en esta categoría complejos, e incrementa el tráfico de administración entre los servidores y el balanceador [9]. Sobre el particular, el desempeño del algoritmo directamente determina el desempeño del sistema de balanceo de carga; así el algoritmo de balanceo es la clave del sistema de balanceo de carga. En [9] se exploran las cualidades y funcionalidad, así como una simulación de desempeño vía OPNET, de los distintos métodos de balanceo de carga entre los cuales están Round Robin, Weighted Round Robin, Random, Weighted Random, Least Connection y Least Load. Figura 9. Ambiente de simulación para el modelado de comportamiento y desempeño de los diferentes algoritmos de balanceo de carga. Tomado de Simulation and Performance Analysis of Load Balancing Algorithms Using OPNET, School of Computer, Communication University of China. 6

33 INTRODUCCIÓN Según la referencia, el algoritmo de balanceo Least Load es aplicado con la conclusión que la utilización entre las CPUs de los servidores del cluster es la más cercana y consistente; su efecto aparece de manera temprana puesto que toma en cuenta el tamaño relativo de la tarea actual en cada servidor, similar a tener en cuenta la carga del servidor. En adición, el efecto balanceador positivo del algoritmo de balanceoround Robin aparece después de algunos ciclos de rotación mientras que el balanceador utilizando Least Load comienza a hacer el balanceo de carga efectivo tan pronto como el cluster de servidores recibe requerimientos. En conclusión, la consideración de métodos de balanceo de carga dinámicos basados en Least Load conduce a un mejor desempeño y a una reacción más rápida del algoritmo a las variaciones de carga. Ciertamente considerar un balanceador de carga para EtherChannel basado en el enlace menos cargado (Least Load) desvincula la operación del balanceador de las condiciones de tráfico, la infraestructura subyacente y tendencias en los servicios; reacciona rápidamente a cambios en el tráfico, conduce a utilización óptima de los medios de comunicación, generando ahorros importantes en capex asociados a infraestructura. De acuerdo a los aspectos cubiertos en parágrafos anteriores, queda patente que son varios los aspectos aún por evaluar y optimizar de esta tecnología. Actualizaciones a la lógica de asignación de carga de EtherChannel podrían posibilitar beneficios directos a los proveedores de servicio que cuentan con infraestructura de conmutación agregada de este tipo, por el manejo óptimo de capex, la automatización de la gestión de situaciones de tráfico excesivo con la mejora en calidad de servicio para los clientes que cursan sus flujos por esta infraestructura. Objetivo General Diseñar y evaluar una arquitectura dinámica de asignación y balanceo de carga para la lógica de conmutación de la tecnología EtherChannel, basada en el análisis estadístico del factor de ocupación de los enlaces participantes del canal lógico y en la consideración de algoritmos de selección de enlaces diferentes al Hashing de Bits. Objetivos Específicos (Alcance) Simular un entorno de red basado en el modelado y verificación de desempeño del método de balanceo de carga estático de hashing de bits soportado en EtherChannel, en la herramienta de simulación OPNET Modeler Identificar y desarrollar una arquitectura de balanceo de carga sobre enlaces físicos basada en la filosofía dinámica Least Load (Menor Carga) que permita influenciar la decisión de balanceo sobre enlaces EtherChannel de forma autónoma y consistente. Simular un entorno de red basado en el modelado y verificación de desempeño de la arquitectura de balanceo de carga dinámica propuesta, en la herramienta de simulación OPNET Modeler Verificar el desempeño del método de balanceo de carga y de la arquitectura propuesta en general frente a variaciones discretas de α como parámetro de la medición de tendencia central de ocupación de enlaces físicos EtherChannel y probar la validez de la Media de Rango InterCuartil. Determinar la validez de la arquitectura de conmutación propuesta frente al método tradicional de balanceo soportado en EtherChannel a partir de la comparación entre aspectos específicos de desempeño derivados de la simulación. 7

34 Arquitectura de balanceo de carga dinámico para la lógica de conmutación EtherChannel Limitantes y Exclusiones (Alcance) El alcance del proyecto de grado no contempla implementaciones en hardware o evaluación de resultados en plataformas de conmutación o enrutamiento. No se consideran aspectos relacionados con la evaluación, por medio de simulación, del impacto generado por la influencia de los protocolos de negociación de enlaces agregados EtherChannel (PagP, LACP). El tipo de interfaz agregada sobre la cual se realizarán los análisis iniciales y los similares bajo la nueva arquitectura de balanceo de carga es conmutada troncal. La simulación de modelos en OPNET solo corresponde a la lógica en transmisión. La recepción se mantiene con la lógica de conmutación ya implementada. La simulación de la implementación del método de balanceo de carga EtherChannel de laboratorio así como el diseño, simulación y verificación de la arquitectura de balanceo de carga propuesta se realizarán para un ambiente lógico de 8 canales físicos entre nodos de conmutación. No se discriminarán flujos ni sesiones TCP/UDP específicas. En ese orden de ideas, este proyecto solo se enfoca hacia la optimización del performance de la infraestructura de conmutación EtherChannel en lo referente a eficiencia en la asignación de carga de los enlaces participantes de interfaces agregadas, y a la automatización y proactividad del esquema de conmutación y balanceo de carga frente a situaciones de corto término y persistente de tráfico cursando EtherChannels. Organización del Documento Este documento de tesis de maestría está organizado en capítulos, los cuales presentan la temática investigada así como los resultados obtenidos y el análisis pertinente: En el capítulo 1 se abordan las definiciones y aspectos importantes de la tecnología EtherChannel así como los conceptos relevantes relacionados con los modelos de simulación existentes y el modelo de simulación soportado en la herramienta OPNET Modeler. En el capítulo 2 se presenta la arquitectura propuesta de conmutación, una especificación funcional detallada de su diseño modular y demás consideraciones técnicas tenidas en cuenta en su desarrollo. En el capítulo 3 se exploran los detalles técnicos relacionados con el modelado de la arquitectura propuesta en la herramienta de simulación OPNET Modeler, el desarrollo y resultados de su fase de validación, así como el diseño del escenario de simulación de red. En el capítulo 4 se efectúa una descripción de los objetivos y resultados esperados del Plan de Simulaciones del proyecto y se realiza una revisión exhaustiva, con su respectivo análisis, de los resultados obtenidos de la ejecución de los escenarios que hacen parte del Plan de Simulaciones en mención, con respecto a los objetivos propuestos para este proyecto de grado. En el capítulo 5 se presentan las conclusiones sobre el desarrollo de esta tesis de maestría, las recomendaciones para quienes deseen continuar con investigaciones sobre las temáticas tratadas, así como los trabajos futuros y las contribuciones de este trabajo de investigación. En el capítulo 6 encontrarán las fuentes consultadas que soportan todas las etapas del proyecto. En el capítulo 7 se relacionan todos los documentos, métodos, códigos anexos a la documentación del proyecto. 8

35 MARCO TEÓRICO 1. MARCO TEÓRICO 1.1 TECNOLOGÍA DE CONMUTACIÓN ETHERCHANNEL Con mención en el capítulo Introducción, EtherChannel es una tecnología propietaria del fabricante Cisco por medio de la cual se amplía el alcance del estándar IEEE 802.3, en lo referente a escalamiento de ancho de banda, en sus plataformas de conmutación por medio de la agregación lógica de múltiples enlaces Ethernet ya existentes en la infraestructura de los usuarios, sin necesidad de recurrir a la actualización tecnológica asociada al cambio de interfaces de velocidad superior [7]. Este método actualmente posibilita un ancho de banda agregado entre switches y routers, así como con equipos de otros fabricantes y servidores; la compartición de carga de tráfico entre los enlaces del canal lógico, y un esquema de redundancia en el evento que uno o más enlaces físicos fallen (implicando desplazamiento de cargas hacia enlaces adyacentes, tiempos de conmutación no superiores a pocos milisegundos y con transparencia al usuario). En general, equipos que soporten esta funcionalidad están en capacidad de utilizar simultáneamente desde dos hasta ocho enlaces Ethernet de características y configuraciones similares. Figura 10. Canal lógico EtherChannel entre dos plataformas de conmutación Cisco. Tomado de Understanding EtherChannel Load Balancing and Redundancy on Catalyst Switches Document ID: Con respecto al estándar Ethernet, el ancho de banda de una interfaz según la especificación IEEE no corresponde al ancho de banda full dúplex. Así, una interfaz de 100Mbps cuenta con un ancho de banda full dúplex de 200Mbps. Con EtherChannel, de dos a ocho enlaces físicos de ya sea FastEthernet (FE), GigabitEthernet (GE), o 10-Gigabit Ethernet (10GE) pueden ser empaquetados en un enlace lógico de Fast EtherChannel (FEC), Gigabit EtherChannel (GEC), o 10-Gigabit EtherChannel (10GEC), respectivamente [7]. Cuatro enlaces FastEthernet conforman el estándar industrial Fast EtherChannel para proveer balanceo de carga de tráfico con hasta 800Mbps de ancho de banda full dúplex utilizable. La tecnología EtherChannel provee una capacidad en ancho de banda de hasta 1600Mbps FEC, 16Gbps GEC, 160Gbps 10GEC en los casos de utilización de 8 enlaces, límite de acuerdo a la especificación. Todos los enlaces físicos que hacen parte del método utilizan los mismos mecanismos estándar IEEE para autonegociación full dúplex y autosensado, son asociados y vistos como un todo extremo a extremo, en lo que respecta a ancho de banda y al comportamiento del canal lógico como una interfaz conmutada o enrutada. Existen tres posibilidades de negociación del canal lógico EtherChannel, dos de ellas relacionadas con protocolos que ofrecen una alternativa dinámica de negociación extremo a extremo, y una tercera que parte del hecho que configuraciones estáticas compatibles entre ambos equipos de conmutación garantizan el funcionamiento del canal agregado. Una primera opción, la solución propietaria de Cisco, PagP (Port Aggregation Protocol); la segunda, la utilización del estándar IEEE 802.3ad LACP (IEEE clausula 43 Link Aggregation), ofrecen un intercambio de paquetes de protocolo tendiente a garantizar el funcionamiento y estabilidad del enlace agregado así como la compatibilidad funcional y de configuración 9

36 Arquitectura de balanceo de carga dinámico para la lógica de conmutación EtherChannel previa a la activación del canal EtherChannel. Por último, es posible una configuración estática extremo a extremo en capa 2 del canal en la cual no hay intercambio protocolario alguno. Esta tecnología no está en capacidad de identificar flujos de tráfico para tratamiento diferenciado y asignación a enlaces únicos dentro del canal lógico. Algunos trabajos sugieren la modificación de la metodología de EtherChannel y la orientación hacia la identificación de tráfico y flujos en tiempo real y no tiempo real para ofrecer un manejo adecuado y diferenciado en la asignación de anchos de banda con la intención de solucionar el problema de retardo de red causado por congestión [5]. Como fue mencionado en el capítulo Introducción, cada enlace integrante del canal solo transportará las tramas que sean puestas en él por la lógica EtherChannel la cual toma las decisiones de asignación de carga basada en un algoritmo denominado Hashing de Bits. Este algoritmo asimila patrones binarios pertenecientes a la información origen o destino de los paquetes, o resultantes de una combinación matemática de la información origen-destino. Dentro de la información en mención están las direcciones MAC (que inmediatamente relacionan la tecnología EtherChannel con la utilización exclusiva de enlaces basados en IEEE 802.3), direcciones IP, así como números de puerto TCP/UDP. La utilización de solo direcciones origen o destino implica, de acuerdo al número de enlaces participantes, el procesamiento de un número proporcional de bits de bajo orden de una dirección a manera de índice de la interfaz de salida a seleccionar [7]. Como ejemplo, si el algoritmo utiliza la dirección IP destino (dst-ip) en los paquetes, el canal lógico cuenta con dos interfaces físicas y un paquete a procesar tiene una dirección destino IPv , el algoritmo solo necesita un bit (de más bajo orden) de la dirección como índice de la interfaz física a seleccionar. El cuarto octeto <15> corresponde al código binario y el último bit (1) indica la selección del enlace 1. En adición, cuatro interfaces requieren el análisis de 2 bits ( ) y ocho interfaces requieren el análisis de 3 bits ( ).Si la configuración del algoritmo Hashing de Bits implica la utilización de información origen y destino simultáneamente, el hardware EtherChannel desempeña una XOR lógica entre posiciones de bits similares de la información origen destino en mención, cuyo resultado corresponde al índice de la interfaz de salida a seleccionar. Así, a título de ejemplo, un canal EtherChannel de 4 enlaces físicos con una función de hashing procesando información origen y destino (configuración src-dst-ip) procesará en una base por paquete una XOR lógica entre los dos bits de más bajo orden en las dos direcciones capa 3. Bits 10 XOR Bits 11 = 01 con lo cual se selecciona el enlace 1 para enviar ese paquete. Plataforma de Conmutación Direcciones usadas por operación XOR Algoritmo basado en dirs fuente? Algoritmo basado en dirs destino? Algoritmo basado en dirs fuente / destino? Algoritmo configurable o fijo? 6500/6000 Dirs Capa 2/3, puertos Capa 4, data MPLS Si Si Si Configurable 5500/5000 Únicamente dirs. Capa 2 Si No modificable 4500/4000 Dirs Capa 2/3, o info. Capa 4. Si Si Si Configurable 2900XL / 3500XL Únicamente dirs. Capa 2 Si Si Configurable 3750/3560 Únicamente dirs Capa 2/3 Si Si Si Configurable 2950/2955/3550 Únicamente dirs. Capa 2 Si Si Configurable 1900/2820 Estas plataformas usan un método especial de balanceo. Por favor ver info detallada de Catalyst 1900/ Únicamente dirs. Capa 3 Si No modificable Tabla 1. Utilización de información de cabeceras por parte de la implementación EtherChannel por plataforma Cisco. Tomada de Understanding EtherChannel Load Balancing and Redundancy on Catalyst Switches Document ID:

37 MARCO TEÓRICO La Tabla 1 presenta una relación del fabricante Cisco en la cual se detalla en una base por plataforma la información de direccionamiento por capas que puede utilizarse como insumo por el algoritmo de Hashing de Bits del método EtherChannel, la capacidad para utilizar información origen destino simultáneamente y la condición fija o configurable del método de hashing. En general, la cantidad de información procesada en una base por paquete depende de 1. la plataforma, y 2. el número de interfaces físicas participantes del método. Respecto a la dependencia de la plataforma, la Tabla 1 muestra que no todos los equipos soportan las mismas capacidades de algoritmo (análisis de información proveniente de capas superiores y generación de complejas configuraciones del algoritmo son factores que dependen de la plataforma) e incluso algunas plataformas tienen configuración fija. En el caso de la plataforma Cisco Catalyst 6500/6000 Series corriendo el sistema operativo CatOS, puede configurarse un canal EtherChannel de 2 hasta 8 interfaces físicas (3, 5, 7 interfaces agregadas son instalaciones válidas); pero para todas esas configuraciones siempre se requieren 3 bits de información insumo para el algoritmo. 3 bits producen índices de interfaz del 0 (000) al 7 (111); así que hay enlaces que pueden ser indexados con más de un índice. El balanceo de carga Equitativo por índice aparece en la configuración de 2 (4 índices por interfaz), 4 (2 índices por interfaz), y 8 enlaces físicos (1 índice por interfaz). La siguiente tabla muestra la situación inequitativa para EtherChannels de 3, 5, 6 y 7 interfaces. Número de puertos en el EtherChannel Balanceo de Carga 8 1:1:1:1:1:1:1:1 7 2:1:1:1:1:1:1 6 2:2:1:1:1:1 5 2:2:2:1:1 4 2:2:2:2 3 3:3:2 2 4:4 Tabla 2. Asignación inequitativa de índices a enlaces dentro de configuraciones EtherChannel de 3, 5, 6, 7 enlaces. Tomada de Understanding EtherChannel Load Balancing and Redundancy on Catalyst Switches Document ID: CONCEPTOS SOBRE SIMULACIÓN MODELADO DE RED E INTRODUCCIÓN A LA SIMULACIÓN Un sistema es un conjunto de elementos que interactúan entre sí para lograr un objetivo específico. Se define Simulación como una técnica que imita el comportamiento de un sistema del mundo real conforme evoluciona en el tiempo. Por lo tanto, se podrá analizar y observar sus características, sin necesidad de acudir al sistema real [11]. En particular, hay varios métodos factibles para investigar los protocolos de red y el desempeño de red [10]: Análisis y Modelado Matemático, el cual puede proveer una rápida perspectiva de la operación de un sistema y respuestas a problemas objeto de estudio. Es en general más rápido que un proceso de simulación pero en muchos escenarios es impreciso e inaplicable. Los modelos analíticos no están disponibles en múltiples situaciones, muchos de los modelos disponibles carecen de precisión y algunos provienen de procesos de aproximación. Aún más, las dificultades durante el proceso de 11

38 Arquitectura de balanceo de carga dinámico para la lógica de conmutación EtherChannel modelado y pérdida de precisión aumentan con la complejidad del protocolo o sistema de networking a evaluar. Simulación (basada en tiempo o en eventos discretos), que provee una manera efectiva de modelar el comportamiento de un sistema calculando las interacciones entre sus módulos componentes. Simulación Híbrida, que considera las prestaciones del análisis matemático y la simulación explícita de forma simultánea, parcialmente modelando en simulación discreta para precisión; y parcialmente con análisis matemático para reducir la carga computacional y acelerar el proceso de simulación. Test-bed Emulation, que normalmente involucra la implementación hardware a baja escala de los protocolos, algoritmos y sistemas objeto de los procesos de análisis. Se considera la mejor manera de estimar la factibilidad de los protocolos y sistemas y para determinar qué tan eficaz y robusto es su comportamiento frente a situaciones reales. Sus desventajas están relacionadas con la consideración de aspectos derivados de la implementación física totalmente irrelevantes con la expectativa funcional del sistema, los costos del prototipado y el ámbito limitado para evaluar interacciones y comportamientos a mayor escala. Así, un proceso de simulación involucra el diseño, parametrización y observación del comportamiento de un modelo del sistema real a evaluar, que es una representación de ese sistema con cierto grado de aproximación a sus características. Como objetivos de la simulación se tiene la definición de estímulos de entrada al modelo en mención, así como una serie de variables objeto de análisis, y la observación en si misma del comportamiento del modelo a lo largo del tiempo, los que permiten catalogar el proceso global como una ejecución de la simulación. Esa observación está supeditada a los valores de las variables que se usan para ajustar la operación del modelo y su objeto responde a la obtención y análisis de ciertos parámetros que especifican el comportamiento del sistema. Así, estas apreciaciones permiten la definición de dos conceptos relevantes a la simulación [11]: Modelo de Simulación, que se refiere al conjunto de hipótesis acerca del funcionamiento del sistema expresado como relaciones matemáticas y/o lógicas entre los elementos del sistema. Proceso de Simulación, que se refiere a la ejecución del Modelo de Simulación a través del tiempo de un ordenador para generar las representaciones del comportamiento del sistema. Es importante tener en cuenta que los resultados de la simulación deben ser analizados para verificar su precisión con respecto a la expectativa funcional del sistema, de manera que tanto el modelo como los estímulos puedan ser ajustados y así lograr un balance entre el nivel de detalle del modelo y la expectativa sobre la simulación. Se dice que el Estado del Sistema corresponde al conjunto de variables necesarias para describir el comportamiento y estatus de un sistema en determinado instante de tiempo. Dada la naturaleza de las herramientas computacionales que soportan ambientes de simulación, este estado es discreto; se compone por las variables de entrada y salida, últimas que son objeto de estudio en el marco del análisis del sistema. Dentro de las variables de entrada se encuentran [11]: Las Condiciones Iniciales, que son valores que expresan el estado de sistema al principio de la simulación. Datos Determinísticos, que son valores conocidos que son necesarios para realizar los cálculos que producen las salidas. Datos Probabilísticos, cuyos valores son inciertos pero necesarios para obtener las salidas del sistema. La certeza sobre estos valores se deriva del análisis de sus distribuciones de probabilidad. De acuerdo con [11], se tienen las siguientes clasificaciones para los diferentes escenarios y modelos de simulación: Modelo de Simulación Estática: La representación de un sistema en cierto instante de tiempo. Modelo de Simulación Dinámica: La representación de un sistema cuando evoluciona el tiempo. Modelo de Simulación Determinista: La representación de un sistema que no contiene absolutamente ninguna variable aleatoria. 12

39 MARCO TEÓRICO Modelo de Simulación Aleatoria: La representación de un sistema que contendrá variables aleatorias. Modelo de Simulación Continua: La representación de un sistema donde su comportamiento cambia de forma continua en el tiempo. Modelo de Simulación Discreta: La representación de un sistema donde su comportamiento cambia únicamente en instantes de tiempo concretos, eventos CLASIFICACIÓN DE LOS SIMULADORES De acuerdo con [10], los simuladores de red pueden ser clasificados como Simuladores basados en Tiempo de Reloj y Simuladores de Eventos Discretos. En la simulación basada en tiempo de reloj, la simulación progresa a través de una progresión iterativa de ranuras de tiempo, mientras que en la simulación de eventos discretos la simulación progresa con la ejecución del siguiente evento programado MODELO DE SIMULACIÓN BASADO EN TIEMPO Las ranuras de tiempo en la simulación basada en tiempo de reloj corresponden a espacios de tiempo de reloj real. En este modelo de simulación los eventos dentro de la ranura de tiempo iterada son ejecutados mientras la simulación progresa. El tiempo de simulación corresponde al tiempo usado en correr el modelo. Puesto que un conjunto de ranuras de tiempo (con los eventos asignados por ranura) pueden ser iteradas en un escenario de múltiples corridas, el tiempo de simulación y el tiempo transcurrido en una corrida de la simulación son conceptos distintos. Un aspecto importante de este modelo es que el simulador iterará todas las ranuras de tiempo de una corrida de la simulación sin considerar si hay eventos asignados a una ranura de tiempo particular, por lo cual presenta un bajo desempeño si no hay eventos asignados en muchas ranuras de tiempo consecutivas, que deben ser ejecutadas para completar la ejecución de la simulación. La siguiente ilustración presenta el diagrama de flujo del modelo de simulación basado en tiempo. Figura 11. Diagrama de Flujo de la Simulación basada en Tiempo MODELO DE SIMULACIÓN BASADO EN EVENTOS DISCRETOS (DES) La simulación basada en eventos discretos es el método típico en estudios a gran escala con grandes ventajas sobre la simulación basada en tiempo, referentes al nivel de detalle alcanzado y desempeño. DES permite el modelado de una manera más precisa y real, creando modelos de interacción extremadamente detallados. Tiene requerimientos computacionales superiores a los mismos en plataformas de simulación basadas en tiempo, y en general tiempos de simulación extensos, con simulaciones en el orden de horas a días para finalización del proceso. En particular en el contexto de la simulación de entornos de red, provee soluciones sumamente precisas para modelado de sistemas de encolamiento, redes orientadas a paquetes, 13

40 Arquitectura de balanceo de carga dinámico para la lógica de conmutación EtherChannel desarrollo y análisis de desempeño de infraestructura y protocolos de red con múltiples niveles de complejidad, etc. En la simulación basada en eventos discretos, el tiempo de simulación avanza después que el siguiente evento ha sido ejecutado. El simulador itera los eventos programados, los cuales deben ser procesados en una manera secuencial y ordenada. Así, el simulador debe administrar una Lista de Eventos, la cual es accedida por los diferentes procesos que hacen parte del modelo. En [10] se detallan los siguientes elementos que hacen parte del entorno de simulación DES: Los Generadores Aleatorios, que representan las diferentes variables aleatorias como entradas de sistema iniciales, tales como tamaños de paquete, tiempo entre arribos de paquetes, retardo, etc. Tiempo de Simulación, puede ser actualizado con la ejecución de eventos para permitir que la simulación progrese. Listas de Eventos Priorizados, que almacenan eventos a ser ejecutados de forma ordenada y secuencial. Condiciones de Finalización de la Simulación, tales como Duración de la Simulación u otras condiciones de terminación especiales (interrupciones, llamadas a procedimientos desde código, etc). El procesamiento de un evento puede incluir el cálculo de fórmulas, registro de estadísticas, registro de interrupciones; creación, supresión, acceso y/o retiro de eventos de la Lista de Eventos, llamadas a procedimientos, liberación de espacios de memoria, creación de nuevas variables, etc. El valor actualizado del tiempo de simulación depende de la ejecución de un evento en particular. La siguiente ilustración presenta el diagrama de flujo del modelo de simulación basado en eventos discretos. Figura 12. Diagrama de Flujo de la Simulación basada en Eventos Discretos. 1.3 INTRODUCCIÓN AL SIMULADOR OPNET SUITE DE APLICACIONES OPNET OPNET significa OPtimized NETwork Engineering Tools y fue desarrollado por una compañía llamada OPNET Technologies Inc., fundada en De acuerdo con [10], OPNET es un conjunto de herramientas de simulación de red, los cuales direccionan diferentes necesidades de las redes de comunicaciones, entre las cuales están: Gestión de desempeño de aplicaciones: Dentro de esta clasificación se encuentran ACE Analyst para análisis de aplicaciones de red; ACE Live para análisis de red en tiempo real y monitoreo de experiencia de usuario final; OPNET Panorama, para monitoreo de aplicaciones en tiempo real; y IT Guru Systems Planner, para gestión de capacidad de sistemas para empresas. 14

41 MARCO TEÓRICO Planeación, Ingeniería y Operaciones de Red: Dentro de esta clasificación se encuentran IT/SP Guru Network Planner, para ingeniería y planeación de red para empresas y proveedores de servicio; SP Guru Transport Planner, para planeación e ingeniería de redes de transporte; NetMapper, para diagramación automatizada de red; IT/SP Sentinel, para cumplimiento de políticas, seguridad y auditoria para proveedores de servicio; y OPNET ncompass, para provisión de una visión unificada gráfica de grandes redes en producción para empresas y proveedores de servicio. I+D: Dentro de esta clasificación se encuentran OPNET Modeler, OPNET Modeler Wireless Suite, y OPNET Modeler Wireless Suite for Defense OPNET MODELER OPNET Modeler es una famosa herramienta comercial que provee una solución software de simulación y modelado de red. Es usado ampliamente por investigadores, ingenieros, la academia y las fuerzas militares de Estados Unidos. OPNET Modeler es una herramienta de simulación basada en eventos discretos dotada de una interfaz GUI, con orientación al objeto y al modelado, depuración y análisis jerárquicos [10]. Ha evolucionado para soportar simulación hibrida, simulación analítica, simulación completamente paralela de 32 y 64 bits, así como muchas otras características, tales como soporte de computación en malla para simulación distribuida. Cuenta con una interfaz denominada System-in-the-Loop que permite simulación con sistemas en vivo que alimentan información y data del mundo real dentro del entorno de simulación. Esta herramienta incorpora una amplia suite de protocolos y tecnologías, e incluye un entorno de desarrollo para permitir el modelado de un amplio rango de tipos de red y tecnologías. Con la liberación constante de versiones actualizadas, OPNET Modeler incorpora más y más características para mantenerse al día con la evolución de las aplicaciones, protocolos, dispositivos, y redes de comunicaciones. Cientos de protocolos y modelos de dispositivos de diferentes fabricantes con código fuente son ya incorporados en el modelador. OPNET Modeler acelera el proceso de investigación y desarrollo, y provee un entorno de desarrollo comprensible con un conjunto completo de herramientas incluyendo diseño de modelos, simulación, colección y análisis de datos, y soporte para modelado de redes de comunicaciones y sistemas distribuidos. OPNET Modeler puede ser usado como una plataforma para desarrollar modelos de un amplio rango de sistemas. Tales aplicaciones incluyen modelado de desempeño de redes de area local LAN y area amplia WAN basadas en estándares, planeación de red jerárquica, I+D de arquitecturas de redes de comunicación y protocolos, redes móviles, redes de sensores, y redes satelitales, así como dimensionado de recursos, recuperación ante fallos y cortes, etc. OPNET Modeler utiliza distintos niveles de modelado para representar los diferentes componentes de red. Cada nivel está asociado a un dominio y un editor [12]. Estos editores se encuentran organizados jerárquicamente; así los modelos de red (redes y subredes de la simulación) desarrollados en el Editor de Proyectos (Project Editor) (Figura 13) se componen de nodos y enlaces. Los modelos de nodos, que definen la estructura modular interna e interacciones entre los módulos que constituyen un nodo, son diseñados por una interacción entre módulos, y son accesibles desde el Editor de Nodos (Node Editor) (Figura 14). Los módulos, que cuentan con un modelo de procesos donde se define su lógica orientada al estado, son definidos en el Editor de Procesos (Process Editor) (Figura 15). En adición, hay otros editores que ofrecen soporte tales como el Editor de Enlaces (Link Editor), el Editor de Paquetes (Packet Format Editor) y el Probe Editor, último que permite la configuración de las estadísticas de interés durante el proceso de simulación. Hay gran variedad de módulos disponibles entre los cuales están transmisores y receptores tipo bus, punto a punto e inalámbricos; colas y procesadores, con modelos de proceso por defecto que pueden ser modificados para responder a necesidades específicas. En adición, estos módulos pueden interactuar por medio de Statistics Wires (información de variables) y Packet Streams (paquetes de datos). La definición funcional de un módulo reside en una máquina de estados finitos (FSM). Las transiciones entre estados pueden ser del tipo condicional e incondicional. Cada uno de los estados de la FSM (que 15

42 Arquitectura de balanceo de carga dinámico para la lógica de conmutación EtherChannel pueden ser del tipo no forzado o forzado, de acuerdo con la dependencia a interrupciones para progresar a través del estado) permite la especificación de un conjunto de instrucciones conocido como Directivas de Entrada y Directivas de Salida, que permiten la definición de funciones y comportamientos modulares. Figura 13. Editor de Proyectos de OPNET Modeler. Figura 14. Editor de Nodos de OPNET Modeler. Figura 15. Editor de Procesos de OPNET Modeler. 16

43 MARCO TEÓRICO El lenguaje de programación para escribir estas directivas en OPNET es denominado Proto-C. No hay muchas diferencias sintácticas entre la programación en C y Proto-C, desde que Proto-C conserva la generalidad incorporando todas las capacidades del lenguaje de programación C/C++ [10]. La mayor diferencia es la metodología adoptada por Proto-C para programar modelos. A diferencia de la programación de aplicaciones C/C++, Proto-C es diseñado para manipular tipos de datos predefinidos OPNET vía un motor de simulación existente, el cual puede ser visto como una aplicación a medio hacer en C++ [10]. Este motor de simulación necesita incorporar el código de modelo en Proto-C para generar la aplicación de simulación depurable y ejecutable. Así, el motor de simulación puede ser visto como un ambiente de trabajo o esqueleto preescrito el cual es el núcleo de toda aplicación de simulación [10]. El código del modelo OPNET es la parte cliente de la aplicación de simulación. Ese código es insertado en las posiciones designadas del ambiente de trabajo del motor de simulación para generar los archivos fuente completos finales. Esos archivos serán compilados y vinculados como una aplicación C/C++ normal. Con respecto a sus características y capacidades mencionadas, se considera que OPNET Modeler ofrece una serie de prestaciones atractivas que la hacen una herramienta idónea para su consideración como ambiente de simulación en este proyecto, en comparación con otros productos comerciales para la simulación de sistemas discretos, tales como OPNET IT Guru Academic Edition y OMNeT ++(considerados como otrasopciones en la etapa de planeación). Dentro de estas prestaciones está una fuerte orientación hacia el modelado de redes de comunicaciones y protocolos de red. Al igual que OPNET IT Guru Academic Edition, OPNET Modeler cuenta con modelos de nodo y de enlace predefinidos, que cubren las necesidades de simulación de redes modernas, los cuales posibilitan surápida inclusión en proyectos de diseño y desarrollo, ahorrando el recurso requerido para su diseño, validación e implementación. A diferencia de OPNET IT Guru, en OPNET Modeler es posible la modificación o adición de nuevas capacidades en modelos predefinidos ya existentes con relativa facilidad, lo cual permite verificar el comportamiento posterior de esos modelos de nodo y de red intervenidos. En adición, la generalidad de OMNeT ++ dificulta el modelado y verificación funcional de cierta parte de la operación de un modelo de nodo o red ya existente, ya que debe desarrollarse todo el modelo por completo y realizar las modificaciones requeridas. A diferencia de algunas herramientas de orientación y programación abierta como OMNeT ++, OPNET Modeler permite el modelado a nivel de proceso soportado en una serie de funciones predefinidas denominadas procedimientos de Kernel, que posibilitan la adecuada manipulación de estructuras y eventos predefinidos de interés tales como paquetes de datos, interrupciones de sistema, enlaces, etc. En herramientas como OMNeT++, estructuras como paquetes de protocolo, modelos de enlaces, protocolos de red, deben ser modelados por completo así como las funciones para su manipulación. Otra característica atractiva de OPNET Modeler es su soporte de modelado con orientación al estado. En herramientas como OMNeT ++ la programación es totalmente plana, ofreciendo las posibilidades del modelado de un sistema con orientación al estado por medio de la programación de esos estados. OPNET Modeler cuenta conun ambiente amigable de modelado y simulación en modo gráfico que facilita la construcción de modelos de proceso y nodo orientados al estado, dejando únicamente al diseñador la labor de programación de la función de cada uno de los estados y transiciones considerados en el modelo de proceso, en lenguaje Proto C. Hay buenas fuentes bibliográficas que ya abordan en profundidad la herramienta OPNET Modeler, en lo referente a conceptualización, funcionalidad, modelado de procesos y Proto-C. Para mayor referencia remítase a [10], [11], [12] y [14]. 17

44 Arquitectura de balanceo de carga dinámico para la lógica de conmutación EtherChannel 2. ESPECIFICACIONES 2.1 PRESENTACIÓN DE ARQUITECTURA PROPUESTA De acuerdo con los objetivos propuestos, a continuación se presenta la arquitectura de conmutación, resultado de la fase de diseño. Figura 16. Diagrama de bloques de arquitectura modificada del nodo de conmutación propuesto con especificación de señales unidireccionales y señalización de control. En el Anexo G (en medio digital), se encuentra la Figura 16 con mayor detalle (Figura G.2). A título de referencia, las simulaciones en OPNET constan de tres modelos, a saber: Modelo de Red, Modelo de Nodo y Modelo de Proceso. En principio, este tipo de arquitectura permite un adecuado manejo de las operaciones de red, la definición de nodos y la programación orientada a objetos y estados de los submódulos que conforman los nodos de red. El diseño de la arquitectura de la Figura 18 así como la aplicación de simulación OPNET han sido parametrizadas de manera que cumplan con los objetivos del proyecto. Esta parametrización se encuentra expuesta en el Modelo de Red de manera que puedan realizarse fácilmente las modificaciones pertinentes al modelo y se cumplan las expectativas del Plan de Simulaciones del Proyecto. Con respecto a los objetivos relacionados con el modelado y simulación del método de asignación de carga de EtherChannel (1) así el modelado y simulación de la arquitectura de conmutación propuesta (2), estos objetivos propondrían en principio el diseño e implementación de dos modelos completamente diferentes. Sin embargo, puede verificarse en la Figura 18 que parte de la arquitectura de conmutación considera las prestaciones de asignación de carga del método hashing de bits de EtherChannel. Así, el diseño y parametrización de la arquitectura propuesta permite una aplicación de simulación única en la cual el módulo SM_Ctrl_Switch en un escenario solo considera las prestaciones de procesamiento de paquetes del módulo EtherChannel_HA_Algorithm sin considerar la señalización de ingreso del Switch en el modo de operación conjunta que hace parte del diseño de esta arquitectura, dando cumplimento a (1); en otro escenario de simulación, la parametrización permite la operación modular conjunta, dando cumplimiento a (2). En esta arquitectura, se proponen dos modos de operación: Modo Normal y Modo Recuperación. El modo Normal es el modo de operación por defecto de la arquitectura y es la respuesta del sistema a una condición de carga consistente entre los diferentes medios de salida participantes del canal lógico. En este modo la asignación de carga en los enlaces es efectuada por el módulo EtherChannel HASHING ALGORITHM el cual implementa el algoritmo determinístico de hashing de bits. Ciertas condiciones de 18

45 ESPECIFICACIONES tráfico en los medios de salida pueden inducir se invoque el modo Recuperación, orientado a influenciar la asignación de paquetes en el grupo de enlaces de tal manera que se recupere la que podría ser definida como una condición de balance. En la medida que se efectúe la especificación modular de esta arquitectura, tendrá sentido una posterior definición de este concepto. 2.2 ESPECIFICACIÓN OPERATIVA DE LA ARQUITECTURA Durante el modo Normal y con referencia a la Figura 17 El módulo SM_Ctrl_Switch procesa paquetes buscando asignación a los medios de salida y desvía el tráfico saliente hacia el módulo EtherChannel_HASHING_ALGORITHM_HA para análisis y contextualización de paquetes. Para la asignación de carga a los medios de salida el módulo EtherChannel_HASHING_ALGORITHM_HA se apoya en las prestaciones de conmutación del módulo Switch Fabric el cual examina los contextos anexos a los paquetes para determinar la interfaz de salida correcta en una base por paquete. Durante el proceso en mención, el módulo StatisticsPoller recibe la información de tráfico promedio del canal lógico, calculada de forma distribuida en una base por interfaz (módulos Collector), consolida la información y entrega un vector con los valores promedio de tráfico al módulo LeastLoad_Analysis el cual calcula la(s) interfaz(ces) con menor utilización o utilización excesiva y determina si su nivel es tal que sugieran la pérdida de la condición de balance y deba invocarse el modo Recuperación. Figura 17. Arquitectura propuesta operando en Modo Normal. En el Anexo G (en medio digital), se encuentra la Figura 17 con mayor detalle (Figura G.3). Durante el ingreso y permanencia del Switch en el modo Recuperación y con referencia a la Figura 18 Cuando el módulo LeastLoad_Analysis determina la pérdida de la condición de balance, para fines de sincronización y confiabilidad operacional con el algoritmo seleccionado para recuperación RoundRobin Deficit (RRD), espera que el módulo WeightsLoad_Settings finalice el cálculo de los créditos de recuperación RRD y su carga en el conjunto modular RRD Algorithm. Cuando esto sucede, el módulo LeastLoad_Analysis, por medio de la administración de requerimientos implementada en el módulo SM_Reqs_Queue, señaliza el cambio de modo operativo a Recuperación tanto hacia el módulo SM_Ctrl_Switch como hacia el módulo SwitchFabric, de manera que el módulo SwitchFabric ahora espera el arribo de tráfico contextualizado desde el conjunto modular RRD Algorithm y el módulo SM_Ctrl_Switch desvía el tráfico saliente hacia el conjunto modular RRD Algorithm para análisis y contextualización de paquetes. Durante el proceso en mención, el módulo StatisticsPoller recibe la información de tráfico promedio del canal lógico, calculada de forma distribuida en una base por interfaz (módulos Collector), consolida la información y entrega un vector con los valores promedio de tráfico al módulo LeastLoad_Analysis el cual calcula la(s) interfaz(ces) con menor utilización o utilización excesiva y determina si su nivel es tal que sugieran el retorno de la condición de balance y deba invocarse el modo Normal. 19

46 Arquitectura de balanceo de carga dinámico para la lógica de conmutación EtherChannel Figura 18. Arquitectura propuesta operando en Modo Recuperación. En el Anexo G (en medio digital), se encuentra la Figura 18 con mayor detalle (Figura G.4). 2.3 ESPECIFICACIÓN MODULAR DE LA ARQUITECTURA A continuación se presenta una descripción detallada de los diferentes módulos que conforman la arquitectura propuesta Módulo SWFabric_Processor Su función principal es la asignación correcta de tráfico outbound en el grupo de interfaces de salida de acuerdo a las operaciones de los módulos de asignación y balanceo de carga. Cada interfaz de salida es administrada por un módulo Collector el cual tiene un ID de 3 bits. De acuerdo a su algoritmo, los módulos de asignación y balanceo de carga considerados en los modos operacionales Normal y Recuperación contextualizan los paquetes con un ID de Interfaz de Salida. Así, este módulo recibe paquetes de datos contextualizados, analiza y retira los contextos de paquete y envía los paquetes de datos originales a los módulos Collector correctos. Tiene un estado por defecto en el cual conmuta los paquetes que recibe desde el módulo EtherChannel_HA_Algorithm. En forward, cuenta con conexiones punto a punto OW (One-Way) hacia los módulos Collector. En retorno, aplica multiplexación estadística hacia el Buffer de Salida. Así, hay un retiro de las operaciones de gestión de tráfico inbound de la carga operativa del módulo SwitchFabric_Processor, que eventualmente pudieran causar excesivo retardo de procesamiento nodal. Así, este módulo solo ofrece gestión de tráfico outbound. Figura 19. Las operaciones de gestión de tráfico inbound son controladas por un multiplexor estadístico de salida y una cola atendida a una tasa específica, lo cual propone un modelo de módulo SwitchFabric Processor conmutando tráfico outbound exclusivamente. El siguiente pseudocódigo presenta las definiciones y el algoritmo tentativo del módulo en mención, teniendo en cuenta la orientación al estado de la programación en OPNET Modeler. Estado Inicial : Se define la variable Estado igual al 0 >> Conmutar paquetes desde EtherChannel Ir al Estado Esperar Si se recibe un paquete de datos, ir al estado Packet_Service Si se recibe una trama de señalización desde el módulo SM_Reqs_Queue, ir al estado Switch_Mode 20

47 Estado Packet_Service : Recuperar el paquete del stream de entrada Obtener del paquete de datos el paquete ICI anexo Obtener del paquete ICI anexo el campo ici_id Destruir el paquete ICI anexo Enviar el paquete de datos a la interfaz de salida indexada con el valor ici_id Ir al Estado Esperar Estado Switch_Mode : Recuperar la trama de señalización del stream de entrada Examinar los campos de la trama SI (sus primeros dos campos son 3-0) { Capturar el tercer campo Selector de la trama Destruir la trama de señalización Casos del campo Selector : Caso 0: >> Conmutar paquetes desde EtherChannel Caso 1: >> Estado = Selector Conmutar paquetes desde Round Robin Deficit Estado = Selector ESPECIFICACIONES } Ir al Estado Esperar ************************************************************************************************* Módulo StatisticsPoller El módulo StatisticsPoller fue planeado como un proceso encargado de realizar una colecta cada 30 segundos de las muestras acotadas de tráfico de las interfaces, para generar un vector consolidado de muestras a ser entregado tanto en el módulo WeightsLoad_Settings, encargado de calcular los créditos de recuperación RRD, así como en el módulo LeastLoad_Analysis, encargado de determinar el modo de operación del Switch. La propuesta implicaba un mecanismo transaccional para realizar esta colecta. Sin embargo, posteriormente se determina que la mejor opción para consolidar la información de las interfaces no es la colecta; es mejor que los módulos Collector se encarguen de la preparación de la información de tráfico promedio y envíen un mensaje denominado PollerFrame (que tiene el ID del módulo Collector que generó el mensaje, así como un campo Payload con el valor del tráfico promedio acotado en una base por interfaz) destinado al módulo StatisticsPoller. Cuando el módulo StatisticsPoller detecta que en un ciclo ha colectado las muestras de las ocho interfaces, produce un mensaje que modela el vector consolidado con esas muestras, a manera de un integrador de información de control. Por tanto, la conectividad entre los módulos Collector (en un base por puerto; mediciones de tráfico) y el módulo StatisticsPoller es por medio de enlaces punto a punto en configuración estrella. Los módulos Collector, que corren temporizadores de operación a 1 segundo para fines de colecta de observaciones y 30 segundos para consolidación de la muestra y procesamiento de la misma, cuando tienen información estadística para enviar, la envían sin necesidad de un mecanismo transaccional; el módulo StatisticsPoller consolida las muestras de todas las interfaces y forma un paquete vector que ha de ser enviado tanto al módulo WeightsLoad_Settings como al módulo LeastLoadAnalysis. Figura 20. Topología estrella entre los módulos Collector y el módulo StatisticsPoller. 21

48 Arquitectura de balanceo de carga dinámico para la lógica de conmutación EtherChannel Módulo LeastLoad Analysis Este módulo se encarga de verificar las condiciones de balance de carga del grupo de enlaces y señalizar el cambio de modo de Normal a Recuperación y viceversa. Para este propósito implementa funciones matemáticas que evalúan el valor promedio de la carga de un enlace contra un rango estándar basado en la media y desviación estándar de un vector de valores promedio de tráfico. De acuerdo a la arquitectura propuesta, este módulo recibe información de control desde dos fuentes: el módulo StatisticsPoller, el cual le envía un vector consolidado con medias de tráfico para el grupo de enlaces; y el módulo WeightsLoad_Settings, el cual señaliza la disponibilidad de un paquete de créditos de recuperación RRD. Así, se soporta sincronización entre la señalización de cambio de modo y la disponibilidad de créditos confiables de restablecimiento de carga en el grupo de enlaces de salida. Esta señalización es requerida para transiciones estables y confiables del modo Normal al modo Recuperación. El algoritmo desarrollado para este módulo se basa principalmente en el procesamiento del vector de medias de tráfico full dúplex en el conjunto de enlaces para un periodo de medición: 0, 1, 2, 3, 4, 5, 6, 7] (1) Se define M, la media de la muestra; M, la desviación estándar de la muestra. El módulo LeastLoad_Analysis señaliza al módulo SM_Reqs_Queue (S1) en modo Normal si i : i - M M (Condición de Balance de Carga) (2) El módulo LeastLoad_Analysis señaliza al módulo SM_Reqs_Queue (S1) en modo Recuperación si i : i - M > M (3) Ejercicios de validación posteriores identificaron la efectividad de la expresión (3) para permitir el ingreso del Switch al modo Recuperación. A su vez, (2) presenta cierta incapacidad para permitir al módulo el retorno de la operación del Switch al modo Normal, puesto que ejercicios en Excel mostraron que siempre habrá observaciones de tráfico promedio por enlace cuyo delta con la media de la muestra es mayor que la desviación estándar de la misma. Así, se definió un decremento del 25% en los valores de esas diferencias para asegurar el retorno del Switch a modo Normal. Así, se tiene que El módulo LeastLoad_Analysis señaliza al módulo SM_Reqs_Queue (S1) en modo Normal si i : 75% i - M M (Condición de Balance de Carga) (4) El módulo LeastLoad_Analysis señaliza al módulo SM_Reqs_Queue (S1) en modo Recuperación si i : 75% i - M > M (5) El siguiente pseudocódigo presenta las definiciones y el algoritmo tentativo del módulo en mención, teniendo en cuenta la orientación al estado de la programación en OPNET Modeler. Estado Inicial : Se define la variable EstadoActual igual a 0 Se define la variable PesosListos igual a 0 Se define la variable CambioEstado igual a 0 Ir al Estado Esperar Si se recibe un vector de medias de tráfico, ir al estado ProcesamientoDePesos Si se recibe señalización desde el módulo WeightsLoad_Analysis, ir al estado QuantumsListos Estado QuantumsListos : Examinar los campos de la trama SI (sus primeros dos campos son 6-1) { 22

49 ESPECIFICACIONES Capturar el tercer campo Selector de la trama Destruir la trama de señalización Casos del campo Selector : Caso 1: >> Quantums Listos Actualizar variable PesosListos a 1 Caso 0: >> } SI NO { Ir al estado Esperar } Ir al estado ProcesamientoDePesos Quantums No Disponibles Ir al estado Esperar Estado ProcesamientoDePesos : SI (CambioEstado == 0) { Capturar el vector de medias de tráfico del stream de entrada Calcular la media de la muestra Calcular la desviación estándar de la muestra Calcular el ingreso al método al modo Normal (0) / Recuperacion (1) Definir y actualizar la variable SiguienteEstado con el modo calculado Destruir paquete vector de medias de tráfico SI (EstadoActual =! SiguienteEstado y EstadoActual == Normal (0)) { Actualizar la variable CambioEstado a 1 Actualizar la variable EstadoActual con la variable SiguienteEstado SI (PesosListos == 1) { Crear trama de señalización con contenidos Enviar trama al módulo SM_Reqs_Queue Actualizar la variable CambioEstado a 0 Actualizar la variable PesosListos a 0 } } SI (EstadoActual =! SiguienteEstado y EstadoActual == Recuperacion (1)) { Actualizar la variable CambioEstado a 1 Actualizar la variable EstadoActual con la variable SiguienteEstado SI (PesosListos == 1) { Crear trama de señalización con contenidos Enviar trama al módulo SM_Reqs_Queue Actualizar la variable CambioEstado a 0 Actualizar la variable PesosListos a 0 } } SI (EstadoActual == SiguienteEstado){ Actualizar la variable CambioEstado a 1 Actualizar la variable PesosListos a 0 } } SI (CambioEstado == 1) { SI (PesosListos == 1) { Crear trama de señalización con contenidos 2-0- EstadoActual Enviar trama al módulo SM_Reqs_Queue Actualizar la variable CambioEstado a 0 Actualizar la variable PesosListos a 0 } } Ir al Estado Esperar ************************************************************************************************* Módulo SM_Reqs_Queue En esta arquitectura hay uso controlado de señalización para fines de conmutación del modo operativo del Switch. La arquitectura considera un módulo denominado SM_Reqs_Queue, el cual es una cola de requerimientos que administra la señalización fuera de banda de cambio de modo operativo (proveniente desde el módulo LeastLoad Analysis ) y controla de manera sincronizada los cambios de modo operacional tanto en el módulo SM_Ctrl_Switch, así como del módulo SwitchFabric Processor. El servicio de atención de cola tiene una frecuencia de 10 req/sec. 23

50 Arquitectura de balanceo de carga dinámico para la lógica de conmutación EtherChannel Figura 21. Señalización considerada en el modelo de nodo de la arquitectura propuesta Módulo EtherChannel_HA_Algorithm En este módulo se modela el algoritmo de asignación de carga a los medios de salida Hashing de Bits de la tecnología EtherChannel. De acuerdo al escenario de simulación propuesto, los paquetes de entrada que se generan y procesan tanto por los generadores de tráfico en las subredes como en los nodos de conmutación son IP, de manera que las posibilidades de operación del algoritmo están relacionadas con el hashing de bits de la IP origen, IP destino o el hashing de bits de la operación XOR resultante entre el direccionamiento IP origen y destino. Como se tienen 8 enlaces de salida, se considera el procesamiento de 3 bits de menor orden en esas direcciones. El siguiente pseudocódigo presenta las definiciones y el algoritmo tentativo del módulo en mención, teniendo en cuenta la orientación al estado de la programación en OPNET Modeler. Estado Inicial : Se define la variable node_id igual al ID OPNET del nodo de conmutación Se define interrupción temporizada de atención de subcola interna de paquetes (0) Ir al Estado Esperar Si se recibe un paquete de datos, ir al estado Packet_Queueing Si se genera la interrupción de atención de subcola interna de paquetes (0), ir al estado Service_Packets Estado Packet_Queueing : Recuperar el paquete del stream de entrada Ingresar el paquete en la subcola 0 Ir al Estado Esperar Estado Service_Packets : SI (subcola 0 no está vacía) { SI (ATRIBUTO <<op_mode>> para el ID OPNET node_id EXISTE){ SI (variable op_mode << ATRIBUTO <<op_mode>> == SUCCEED){ Remover un paquete del head de la subcola 0 Accesar la estructura de datagrama IPv4 del paquete Recuperar la dirección origen IPv4 (src-ipadd) Recuperar la dirección destino IPv4 (dst-ipadd) Casos de la variable op_mode : Caso 0: (Operación por defecto -> ip-src hashing bits) { ici_id = (src-ipadd AND ) } Caso 1: ( -> ip-dst hashing bits) { ici_id = (dst-ipadd AND ) } Caso 2: ( -> ip-src-dst hashing bits) { ici_id = ((src-ipadd XOR dst-ipadd) AND ) } Crear el paquete de contexto OPNET ICI Cargar el campo ici_id en el paquete OPNET ICI Anexar paquete de contexto ICI a paquete IPv4 Enviar al módulo SwitchFabric_Proccesor } } } Se define interrupción temporizada de atención de subcola interna de paquetes (0) Ir al Estado Esperar ************************************************************************************************* 24

51 2.3.6 Módulo WeightsLoad_Settings ESPECIFICACIONES Este módulo recibe el vector de medias acotadas de tráfico desde el módulo StatisticsPoller y calcula los pesos y créditos de restablecimiento (en bytes) para el algoritmo RoundRobin Deficit. El cálculo de estos créditos no es condicional a la decisión del módulo LeastLoad_Analysis de conmutar el modo de operación del Switch. Por el contrario, una de las funciones de este módulo perse es hacer disponible al módulo LeastLoad_Analysis de señalización de disponibilidad de pesos, si la decisión del módulo en mención es cambiar a modo Recuperación, antes de generar la señalización de conmutación de modo. En adición, genera un vector de créditos de restablecimiento que es entregado a las subcolas del RRD, las cuales a su vez recuperan su valor de créditos, con respecto a un ID que coincide con la posición de los valores en el vector. El algoritmo desarrollado para este módulo se basa principalmente en el procesamiento del vector de medias de tráfico full dúplex en el conjunto de enlaces para un periodo de medición: 0, 1, 2, 3, 4, 5, 6, 7] (6) Se define M, la media de la muestra; M, la desviación estándar de la muestra; B, un peso base (200). Teniendo en cuenta que los pesos de restablecimiento deben ser mayores o menores que el peso base para efectuar operaciones de aumento y disminución de carga, respectivamente, Se define un vector de pesos ponderados de restablecimiento; / / / / / / / / ] (8) A partir de la disponibilidad de una medida de la proporción de restablecimiento en una base por enlace, se multiplica cada uno de los términos de la expresión anterior por un valor T (Créditos de Transmisión Totales, en bytes) para obtener i (Créditos de Transmisión por Enlace, en bytes). T puede ser definido como 10kbyte. Se define un vector de Créditos de Transmisión de Restablecimiento (vector de corrección), el cual se aplica al algoritmo de Round Robin Deficitario (conjunto de subcolas del método): ] (9) Cada uno de los términos del vector de corrección se aplica a los contadores deficitarios por subcola del método RRD; cada una de las cuales, en adición, contextualiza paquetes para su entrega al módulo SwitchFabric_Processor. El siguiente pseudocódigo presenta las definiciones y el algoritmo tentativo del módulo en mención, teniendo en cuenta la orientación al estado de la programación en OPNET Modeler. Ir al Estado Esperar Si se recibe una trama vector desde el módulo StatisticsPoller, ir al estado Weights_Processing Estado Weights_Processing : Recuperar el paquete vector del stream de entrada Calcular la media de la muestra MediaSample (observaciones del vector) Calcular la desviación estándar de la muestra (observaciones del vector) Para (cada observación MediaLink del vector) { >> llamar la subrutina de cálculo de pesos de recuperación Calcular peso de recuperación para cada ID de interfaz >> SI (MediaLink > 0 y MediaLink < (2 x MediaSample)) { 25 (7)

52 Arquitectura de balanceo de carga dinámico para la lógica de conmutación EtherChannel SI (MediaLink > MediaSample o MediaLink == MediaSample) { weight = x (MediaLink - MediaSample) MediaSample } SI (MediaLink < MediaSample) { weight = x (MediaSample - MediaLink) MediaSample } } SI (MediaLink == 0) { weight = x (MediaSample - MediaLink) MediaSample } SI (MediaLink == (2 x MediaSample) o MediaLink > (2 x MediaSample)) { weight = 1 } Retornar el valor del peso de recuperación } Destruir el paquete vector Sumar todos los pesos de recuperación >> weighttotal Obtener los créditos de recuperación para cada ID de interfaz >> Q_ i = bytes x (w i / weighttotal) Crear una trama de señalización con contenidos Pesos de Recuperación Listos Enviar trama de señalización al módulo LeastLoad_Analysis Para (cada subcola del algoritmo RRD) { Crear un vector con créditos de recuperación Enviar a subcola } Ir al Estado Esperar ************************************************************************************************* Módulos Collector Este módulo, habilitado en una base por interfaz, se encarga de múltiples funciones y tiene características entre las cuales se encuentran: La colecta de muestras de 30 observaciones, cada una por segundo, de trafico cursado inbound/outbound en una interfaz (bytes/sec). Un atributo de cada paquete en capa 4 es la longitud del segmento (Payload de capa 3) y se conoce la longitud de la cabecera de capa 3 IP (20 bytes), cuya suma corresponde a Longitud (Lenght). 8 bits x Length (bytes) x No. Paquetes de tráfico inbound /outbound que cursen la interfaz en un periodo de un segundo >>> Medición de BW (bps) (10) La determinación de la media muestral acotada de tráfico para múltiples valores de alpha como parámetro de la medida de tendencia en mención. Este parámetro debe ser expuesto en la simulación con valores de 25%, 15% y 5%. Generación de señalización interna con el valor de la media de tráfico hacia el módulo StatisticsPoller, último que consolida el vector de medias. Gestión de la estadística Retardo de Procesamiento Nodal, examinando una estampa de tiempo producida en una base por paquete en el módulo SM_Ctrl_Switch y comparándola contra el tiempo de simulación al momento del despacho del paquete hacia los medios de salida. Esta estadística es de índole global y objeto de los resultados de la simulación. El siguiente pseudocódigo presenta las definiciones y el algoritmo tentativo del módulo en mención, teniendo en cuenta la orientación al estado de la programación en OPNET Modeler. Estado Inicial : Se define la estadística global Nodal Processing Delay Se define y actualiza la variable Seconds_Counter igual a 0 26

53 ESPECIFICACIONES Se define y actualiza la variable bytes_out igual a 0 Se define y actualiza la variable bytes_in igual a 0 Se define y actualiza la variable pk_num igual a 0 Se define una interrupción temporizada de 1 segundo Se define una interrupción temporizada de 30 segundos Se define la variable module_id igual al ID del collector Se define la variable node_id igual al ID del nodo de conmutación Ir al Estado Esperar Si se recibe un paquete de datos inbound, ir al estado traffic_in Si se recibe un paquete de datos outbound, ir al estado traffic_out Si se genera la interrupción interna por vencimiento del temporizador de 1s, ir al estado 1Second_Service Si se genera la interrupción interna por vencimiento del temporizador de 30s, ir al estado 30Second_Service ************************************************************************************************* Estado traffic_in : Recuperar el paquete del stream de entrada Recuperar la carga del paquete IP (TCP) bytes_in = bytes_in + función >>> Tamaño en bytes (TCP Packet) + 20 (Header IP) Recuperar la estampa de tiempo del paquete y el tiempo de simulación Definir variable Nodal_Processing_Delay = tiempo de simulación time_stamp(packet) Escribir la estadística Nodal Processing Delay <Nodal_Processing_Delay Enviar paquete al multiplexor estadístico de salida -> Ir al Estado Esperar ************************************************************************************************* Estado traffic_out : Recuperar el paquete del stream de entrada Recuperar la carga del paquete IP (TCP) bytes_out = bytes_out + función >>> Tamaño en bytes (TCP Packet) + 20 (Header IP) Recuperar la estampa de tiempo del paquete y el tiempo de simulación Definir variable Nodal_Processing_Delay = tiempo de simulación time_stamp(packet) Escribir la estadística Nodal Processing Delay <Nodal_Processing_Delay Enviar paquete al módulo transmisor de salida -> Ir al Estado Esperar ************************************************************************************************* Estado 1Second_Service : Seconds_Counter = Seconds_Counter + 1 Casos de la variable Seconds_Counter : Caso x: variable Sample_x = bytes_out + bytes_in bytes_out = 0 bytes_in = 0 pk_num = 0 Se define una interrupción temporizada de 1 segundo -> Ir al Estado Esperar ************************************************************************************************* Estado 30Second_Service : Cargar las variables Sample_x en un array x Ordenar el array x de forma ascendente SI (ATRIBUTO alpha del nodo con ID node_id EXISTE) { SI (var. alpha < (ATRIBUTO alpha del nodo con ID node_id ) == SUCCEED) { Casos de la variable alpha : Caso -> 25: Calcular media muestral para el rango intercuartil Caso -> 15: Calcular media muestral para el rango inter-15perc Caso -> 5: Calcular media muestral para el rango inter-5perc } } Crear mensaje PollerFrame con ID = Collector_ID y Carga = media muestral calculada Enviar mensaje PollerFrame al módulo StatisticsPoller seconds_counter = 0 bytes_out = 0 bytes_in = 0 Muestras Sample_x = 0 Se define una interrupción temporizada de 1 segundo y 30 segundos -> Ir al Estado Esperar ************************************************************************************************* 27

54 Arquitectura de balanceo de carga dinámico para la lógica de conmutación EtherChannel Conjunto de Módulos SM_Ctrl_Switch RoundRobin Scheduler RoundRobin Deficit El módulo SM_Ctrl_Switch se encarga de administrar los cambios de estado (modo operativo) del Switch (ya sea Modo Normal o Modo Recuperación ) atendiendo mensajes de señalización S2, encola los paquetes de datos entrantes (implementa el módulo Sistema de Encolamiento de Entrada ), y ofrece servicio de conmutación a los mismos hacia los métodos EtherChannel o RRD, según corresponda. Así mismo, dadas las características de la simulación DES así como aspectos operacionales y de optimización, este módulo controla el mecanismo de inicio/finalización del ciclo de RoundRobin, dado el importante volumen de eventos que genera este ciclo cuando encuentra subcolas RRD vacías. Tiene un periodo de servicio de señalización de 100ms y un periodo de servicio de paquetes de usuario de 100us. A su vez, se encarga parcialmente de la gestión de la estadística Retardo de Procesamiento Nodal, modificando un parámetro de los paquetes de datos OPNET denominado Packet Stamp Time. Tan pronto recibe un paquete de datos y antes de encolamiento para servicio posterior, este módulo modifica el parámetro Packet Stamp Time al tiempo de la simulación. Este parámetro va a recuperarse en el grupo de módulos Collector de manera que su diferencia contra el tiempo de simulación actual responderá al retardo de procesamiento nodal en FWD. Adicionalmente, tiene una estadística de índole global denominada Estado de Sistema, discreta, que permite verificar el porcentaje de ingreso del Switch al modo Normal / Recuperación. Los módulos RoundRobin_Scheduler, RoundRobin_Deficit y el multiplexor estadístico conforman el conjunto modular RRD_Algorithm (ver arquitectura), y modelan una implementación OPNET del algoritmo Round Robin Deficit. La conmutación de este algoritmo es controlada por la señalización desde el módulo SM_Ctrl_Switch, el cual recibe y procesa las necesidades de conmutación desde el módulo LeastLoad_Analysis. Figura 22. Ilustración de la operación del conjunto RRD Algorithm. La subcola q_7 controla el inicio y finalización del recorrido de las subcolas durante el modo Recuperación. Figura 23. Diagrama de bloques del módulo SM_Ctrl_Switch. 28

55 En el Anexo G (en medio digital), se encuentra la Figura 22 con mayor detalle (Figura G.5). ESPECIFICACIONES El siguiente pseudocódigo presenta las definiciones y el algoritmo tentativo del módulo SM_Ctrl_Switch, teniendo en cuenta la orientación al estado de la programación en OPNET Modeler. Estado Inicial : Se define y actualiza la variable EstadoSwitch con 0 -> Estado por Defecto Se define la variable node_id igual al ID OPNET del nodo de conmutación Se define interrupción temporizada de atención de subcola interna de señalización (1) Se define interrupción temporizada de atención de subcola interna de paquetes (0) Se define la estadística local Switching Se define la estadística global Estado de Sistema Ir al Estado Esperar Si se recibe un paquete de datos, ir al estado Packet_Queueing Si se genera la interrupción de atención de subcola interna de paquetes (0), ir al estado Sending_Packets Si se recibe un mensaje de señalización, ir al estado Commands_Queueing Si se genera la interrupción de atención de subcola interna de señalización (1), ir al estado Analyze Si se genera la interrupción interna por vencimiento del temporizador de 250ms, ir al estado RR_Management ************************************************************************************************* Estado Packet_Queueing : Recuperar el paquete del stream de entrada SI (Estampado del paquete con tiempo de simulación es exitoso) { Insertar paquete en la subcola (0) por tail } Ir al Estado Esperar ************************************************************************************************* Estado Commands_Queueing : Recuperar la trama de señalización del stream de entrada Insertar trama en la subcola (1) por tail Ir al Estado Esperar ************************************************************************************************* Estado Analyze : SI (Evento de Interrupción -> INVALIDO o CODIGO DE INTERRUPCIÓN!= analyzer_code ){ Se define interrupción temporizada de atención de subcola interna de señalización (1) Ir al Estado Esperar } SI NO { SI (subcola (1) no está vacía) { Remover trama de señalización de subcola (1) por head Analizando sus campos SI (sus primeros dos campos son 3-0) { Capturar el tercer campo Selector de la trama Destruir la trama de señalización SI (EstadoSwitch!= Selector) { Casos del campo Selector : Caso 0: >> RRD Algorithm >> HA EtherChannel Escribir la estadística Switching >> 2 Iniciar subrutina de temp. 250ms } Caso 1: >> Definir variable CambioPendiente = 1 HA EtherChannel >> RRD Algorithm EstadoSwitch = 1 Definir variable CambioPendiente = 0 Iniciar subrutina de temp. 250ms } Se define interrupción temporizada de atención de subcola interna de señalización (1) Ir al Estado Esperar } } SI (subcola (1) si está vacía) { Se define interrupción temporizada de atención de subcola interna de señalización (1) Ir al Estado Esperar } ************************************************************************************************* 29

56 Arquitectura de balanceo de carga dinámico para la lógica de conmutación EtherChannel Subrutina de temp. 250ms >Estado RR_Management SI (EstadoSwitch == 1 y CambioPendiente == 0) { Escribir la estadística Switching >> 1 Escribir la estadística: Estado de Sistema <- EstadoSwitch CambioPendiente = 0 } SI (EstadoSwitch == 1 y CambioPendiente == 1) { EstadoSwitch = 0 Escribir la estadística: Estado de Sistema <- EstadoSwitch CambioPendiente = 0 } Ir al Estado Esperar ************************************************************************************************* Estado Sending_Packets : SI (subcola 0 no está vacía y CambioPendiente == 0) { SI (variable mode < ATRIBUTO DE SWITCH <<mode>> para el ID OPNET node_id ){ SI (mode == TRUE) { EstadoSwitch = 0 } Casos de la variable EstadoSwitch : Caso 0: Remover paquete de datos de subcola (0) por head Enviar paquete hacia módulo EtherChannel_HA_Algorithm Caso 1: Remover paquete de datos de subcola (0) por head Enviar paquete hacia módulo LB_Algorithm (conmutador de RRD) } } } Se define interrupción temporizada de atención de subcola interna de paquetes (0) Ir al Estado Esperar ************************************************************************************************* El siguiente pseudocódigo presenta las definiciones y el algoritmo tentativo del módulo RoundRobin_Scheduler, teniendo en cuenta la orientación al estado de la programación en OPNET Modeler. Estado Inicial : Se define y actualiza la variable Port = 0 Ir al Estado Esperar Si se recibe un paquete de datos, ir al estado RoundRobin ************************************************************************************************* Estado RoundRobin : Recuperar el paquete del stream de entrada Enviar el paquete por el puerto indexado por la variable Port Incrementar Port en 1 SI (Port == 8) { Port = 0 } Ir al Estado Esperar ************************************************************************************************* El siguiente pseudocódigo presenta las definiciones y el algoritmo tentativo del módulo de subcola RRD q_i, sin presentar la variación técnica en q_7 para el control del mecanismo de recorrido del conjunto de colas. Téngase en cuenta la orientación al estado de la programación en OPNET Modeler. Estado Inicial : Se define y actualiza la variable Ci_def con 0 Se define y actualiza la variable x con 0 Se define la variable module_id igual al ID de la subcola Ir al Estado Esperar Si se recibe un paquete de datos, ir al estado Queue_Ingress Si se recibe un vector con pesos de recuperación, ir al estado Queue_Recovery Si se recibe un mensaje de señalización de recorrido RoundRobin, ir al estado RoundRobin Si se genera la interrupción interna por vencimiento del temporizador de 5ms, ir al estado Cycle_Delay ************************************************************************************** Estado Queue_Ingress : Recuperar el paquete del stream de entrada Insertar paquete en la subcola (0) por tail Ir al Estado Esperar ************************************************************************************** 30

57 ESPECIFICACIONES Estado Queue_Recovery : Recuperar el paquete vector del stream de entrada SI (ATRIBUTO queue_id del módulo con ID module_id EXISTE) { SI ((x < (ATRIBUTO queue_id del módulo con ID module_id ) == SUCCEED) { Casos de la variable x : Caso x = 0: Q_i < campo 0 del vector; destruir vector! Caso x = 1: Q_i < campo 1 del vector; destruir vector! Caso x = 2: Q_i < campo 2 del vector; destruir vector! Caso x = 3: Q_i < campo 3 del vector; destruir vector! Caso x = 4: Q_i < campo 4 del vector; destruir vector! Caso x = 5: Q_i < campo 5 del vector; destruir vector! Caso x = 6: Q_i < campo 6 del vector; destruir vector! } Ci_def = 0 Ir al Estado Esperar Caso x = 7: Q_i < campo 7 del vector; destruir vector!} ************************************************************************************** Estado RoundRobin : Remover trama de señalización del stream de entrada Analizando sus campos SI (sus primeros dos campos son 7-1) { Capturar el tercer campo Selector de la trama Destruir la trama de señalización Definir variable RRState = Selector Casos del campo Selector : Caso 0: Ci_def = Caso 1: Ci_def = Ci_def + Q_i Definir variable pktcurrentsize = 0 SI (subcola (0) no está vacía) { Haga { Variable nxt_eval = 0 Remover paquete de datos de la subcola (0) por head Actualizar pktcurrentsize con tamaño de paquete en bytes SI (pktcurrentsize <= Ci_def) { Ci_def = Ci_def pktcurrentsize SI (ATRIBUTO queue_id del módulo con ID module_id EXISTE) { SI ((ici_id < (ATRIBUTO queue_id del módulo con ID module_id ) == SUCCEED) { Crear paquete de contexto OPNET ICI Definir ID del paquete ICI con ici_id Anexar paquete ICI a paquete de datos Enviar paquete indexado a multiplexor } } SI (Ci_def!= 0) { nxt_eval = 1 } SI NO { nxt_eval = 0 } } SI NO { Inserte paquete en subcola (0) por head nxt_eval = 0 } } Mientras ( subcola (0) no esté vacía y nxt_eval sea igual a 1) } SI ( subcola (0) está vacía ) { Ci_def = 0 } SI (subcola (0) está vacía) { Ci_def = 0 } Definir subrutina de retardo de 5ms y acceso a interrupción relacionada } Ir al Estado Esperar ************************************************************************************** Estado Cycle_Delay Crear mensaje de señalización de recorrido RoundRobin con contenidos 7-1-RRState Enviar mensaje de señalización a la subcola q_i+1 Ir al Estado Esperar 31

58 Arquitectura de balanceo de carga dinámico para la lógica de conmutación EtherChannel 3. DESARROLLOS 3.1 IMPLEMENTACIÓN DE NODO DE CONMUTACIÓN EN OPNET MODELER A partir de la arquitectura propuesta presentada en la Figura 16, se realiza la implementación en la herramienta de simulación OPNET Modeler, ilustrada en la Figura 24. Figura 24. Modelo de nodo diseñado en OPNET Modeler para la arquitectura propuesta del nodo de conmutación. En el Anexo G (en medio digital), se encuentra la Figura 24 con mayor detalle (Figura G.6). Respecto a los comentarios acerca de la parametrización del modelo, expuestos en la sección 2.1 (Presentación de Arquitectura Propuesta), el módulo SM_Ctrl_Switch tiene un parámetro expuesto en el modelo de red OPNET denominado mode el cual se superpone a la señalización de cambio de estado generada desde el módulo LeastLoad_Analysis. Uno de los objetivos del proyecto es simular el comportamiento del algoritmo de asignación de carga de EtherChannel. El problema radica en que no puede caracterizarse este comportamiento sobre el modelo propuesto dada la acción del módulo LeastLoad_Analysis, el cual puede determinar un cambio de estado y sacar de operación el módulo de EtherChannel para entrar en el modo Recuperación con el conjunto de módulos RRD Algorithm. Si este parámetro se encuentra DISABLED, el modelo de Switch opera bajo las reglas de la arquitectura propuesta. Si se encuentra en ENABLED, solo opera bajo las reglas de EtherChannel. Se propone el ambiente de simulación para la arquitectura propuesta por medio del siguiente modelo de red en OPNET. Figura 25. Modelo de red de ambiente de simulación con subredes generando tráfico hacia dos nodos que implementan la arquitectura propuesta. 32

59 En el Anexo G (en medio digital), se encuentra la Figura 25 con mayor detalle (Figura G.7). DESARROLLOS Figura 26. Modelo de red de subred 0 con 8 estaciones de trabajo que generan tráfico TCP/IP. Figura 27. Modelo de red de subred 1 con 8 estaciones de trabajo que generan tráfico TCP/IP. En el Anexo G (en medio digital), se encuentran la Figura 26 y la Figura 27 con mayor detalle (Figura G.8 y G.9 respectivamente). Los nodos denominados EtherChannelADV_0/1 en la Figura 25 representan la implementación OPNET de la arquitectura propuesta de conmutación para este proyecto. El indicador 8 sobre el enlace que conecta esos nodos de conmutación corresponde a un grupo de 8 enlaces los cuales han sido parametrizados para operar individualmente a 56kbps en modo full dúplex. En lo que respecta a la consideración lógica de infraestructura Ethernet para soporte del modelo, ciertamente la experiencia sobre la simulación DES indica alguna limitante a nivel de procesamiento para modelar tráfico a velocidades Ethernet, puesto que volúmenes de tráfico importantes sugieren listas de eventos grandes y tiempos de simulación excesivamente largos. En adición, no hay mayor documentación acerca de los requerimientos de integración de la capa MAC de Ethernet a proyectos que requieran las prestaciones de este tipo de enlaces. De hecho, la capa MAC no es necesaria en esta implementación dado el uso de enlaces dedicados punto a punto y un ambiente exclusivamente conmutado, pero las pruebas muestran que no pueden utilizarse enlaces Ethernet si esta capa no es incluida en el modelo de nodo. Así, las estaciones de trabajo así como los switches de acceso presentados en la Figura 26 y la Figura 27 son modelados para generar y conmutar entidades que recrean paquetes TCP/IP sin la encapsulación Ethernet, respectivamente. La parametrización de cada generador de entidades está expuesta en el modelo de red del ambiente de simulación de manera que puedan modificarse las direcciones IP, tiempo entre generación de entidades de 33

60 Arquitectura de balanceo de carga dinámico para la lógica de conmutación EtherChannel acuerdo a una distribución exponencial y tiempo de inicio de generación con respecto al tiempo de simulación (Figura 28). Figura 28. Exposición de parametrización de generadores de entidades TCP/IP en el modelo de red OPNET. De acuerdo a los objetivos del proyecto, se han contemplado las configuraciones del caso en la programación de los módulos constitutivos de los nodos EtherChannelADV_X de manera que, en conjunto con la parametrización a nivel de generación de tráfico y la simulación DES en sí misma, ofrecen una serie de parámetros de operación que proponen una matriz en la que se consolida el Plan de Simulaciones del Proyecto, presentado posteriormente. Figura 29. Parametrización de la operación del nodo EtherChannelADV_X en el modelo de red OPNET. En el Anexo G (en medio digital), se encuentra la Figura 28 y la Figura 29 con mayor detalle (Figura G.10 y Figura G.11, respectivamente). 3.2 VALIDACIÓN DEL MODELO DE NODO EN OPNET La validación del modelo de nodo de conmutación propuesto se realiza bajo la siguiente metodología general, basada en el uso del depurador gráfico de OPNET: Aislando sus módulos constitutivos (generando modelos de nodo de prueba en OPNET). Aplicando estímulos de entrada (paquetes de datos y señalización) de forma contralada por medio de una simulación con el depurador gráfico de OPNET. Verificando el contenido de paquetes estimulo de entrada y de salida de acuerdo a expectativa. La validación de dos de los modelos de módulos relevantes en este proyecto ( LeastLoad_Analysis, EtherChannel_HA_Algorithm ) son presentados en esta sección. Los resultados de los procesos de validación de otros módulos se referencian respectivamente en la sección de Anexos. 34

61 3.2.1 Módulo LeastLoad Analysis A continuación se presenta el modelo de proceso orientado al estado de este módulo: DESARROLLOS Figura 30. Modelo de Proceso OPNET del módulo LeastLoad Analysis. El código en Proto-C de este modelo de proceso, se encuentra en la documentación digital del proyecto. Se prepara el siguiente modelo de nodo en cual fue aislado el módulo LeastLoad Analysis para operaciones de validación. Figura 31. Modelo de Nodo para validación del módulo LeastLoad Analysis. La siguiente es la expectativa de la operación del módulo en mención: Figura 32. Flujo de mensajes y señalización esperada para la operación del módulo LeastLoad Analysis. Figura 33. Señalización involucrada en la operación del módulo LeastLoad Analysis. Se modela un generador de paquetes que produce tanto paquetes vector de valor medio de tráfico cursado por el grupo de enlaces, como paquetes de señalización S3 correspondientes al mensaje Pesos de Recuperación Listos. Los vectores de valor medio de prueba son los siguientes: 35

62 Arquitectura de balanceo de carga dinámico para la lógica de conmutación EtherChannel Figura 34. Contenido de los vectores de prueba que consolidan los valores promedio de tráfico para el grupo de ocho interfaces. El segundo vector debe permitir el ingreso del Switch a modo Recuperación y el primer vector debe permitir el reingreso del Switch a modo Normal. Para el vector del segundo caso, dos de los valores de tráfico (40000, 5000) se encuentran por fuera de la desviación estándar e invocan el modo de operación Recuperación generando la señal S1 para cambio de modo (2-0-1). Figura 35. Flujo de paquetes de prueba durante la simulación controlada. Con respecto a la Figura 35, los contenidos de los paquetes ID 90 e ID 91 son descritos en las siguientes figuras, las cuales son presentadas con mayor detalle en el Anexo G (Figuras G.12 y G.13). Figura 36. Contenido del paquete ID 91. Figura 37. Contenido del paquete ID 90. Estos mensajes deben invocar el ingreso del Switch en el modo Recuperación generando la señal S1 para cambio de modo (2-0-1), lo cual se verifica en la simulación con el contenido del paquete ID 92. Figura 38. Paquete ID 92 resultado de la operación del módulo LeastLoad Analysis. Figura 39. Contenido del paquete ID 92. En el Anexo G (en medio digital), se encuentra la Figura 38 y la Figura 39 con mayor detalle (Figura G.14 y Figura G.15, respectivamente). En el caso del primer vector, el 75% del valor de todas las observaciones de tráfico de la muestra, relativas a la media muestral del vector, se encuentran dentro del rango de su desviación estándar. 36

63 DESARROLLOS Figura 40. Flujo de paquetes de prueba durante la simulación controlada. Con respecto a la Fig. 40, el detalle de los paquetes ID 63 e ID 64 es descrito en las siguientes figuras. Figura 41. Contenido del paquete ID 64. Figura 42. Contenido del paquete ID 63. Estos mensajes deben invocar el ingreso del Switch en el modo de operación Normal generando la señal S1 para cambio de modo (2-0-0), lo cual se verifica en la simulación con el contenido del paquete ID 65. Figura 43. Paquete ID 65 resultado de la operación del módulo LeastLoad Analysis. Figura 44. Contenido del paquete ID

64 Arquitectura de balanceo de carga dinámico para la lógica de conmutación EtherChannel Módulo SM_Reqs_Queue A continuación se presenta el modelo de proceso orientado al estado de este módulo: Figura 45. Modelo de Proceso OPNET del módulo SM_Reqs_Queue. El código en Proto-C de este modelo de proceso, se encuentra en la documentación digital del proyecto. En el Anexo A se puede encontrar el proceso de validación de este módulo y un mayor detalle gráfico en el anexo digital G Módulo EtherChannel_HA_Algorithm A continuación se presenta el modelo de proceso OPNET de este módulo. Figura 46. Modelo de Proceso OPNET del algoritmo Hashing de Bits de EtherChannel. La parametrización funcional del método (src-ip, dst-ip, src-dst-ip) se encuentra expuesta en el modelo de red del escenario de simulación propuesto para fines de ajustes de la operación de los nodos con respecto al Plan de Simulaciones del proyecto. Así, este modelo de proceso tiene un atributo expuesto denominado op_mode del tipo entero con las siguientes posibilidades que controlan el modo operativo del método: 0 (default) > ip-src, 1 > ip-dst, 2 > ip-src-dst. El modelo funciona creando un paquete de contexto OPNET denominado ICI el cual se anexa al paquete que busca asignación a los medios de salida. Este paquete anexo contiene un campo denominado ici_id en el cual se carga el resultado del hashing de bits que corresponde al índice de la interfaz de salida. Este campo es recuperado por el módulo SwitchFabric Processor para seleccionar la interfaz de salida, para después retirar el paquete ICI anexo. Desde la interfaz de simulación gráfica de OPNET no pueden leerse los contenidos del paquete ICI anexo, así que la validación de este modelo se realizará imprimiendo las IPs que han sido recuperadas por el algoritmo en una base por paquete, y el valor del campo ici_id. El código en Proto-C de este modelo de proceso, se encuentra en la documentación digital del proyecto. Se ha preparado el siguiente ambiente de validación que consiste en un generador de tráfico TCP/IP el cual tiene una distribución exponencial para modelar el tiempo de arribo entre generación de paquetes y cuenta con dos atributos expuestos en el modelo de red para parametrizar las direcciones IP origen y destino de manera que puedan confirmarse las operaciones del algoritmo de hashing. 38

65 DESARROLLOS Figura 47. Modelo de Red para validación del modelado del algoritmo de asignación de carga de EtherChannel. Figura 48. Modelo de Nodo en el cual fue aislado el módulo EtherChannel_HA_Algorithm objeto de validación. Con respecto a la Figura 49, se prepara el direccionamiento IP en el nodo PC_4. Como primera prueba de esta validación, se parametriza el algoritmo a su operación por defecto (0 (default) > ip-src Figura 50) y se corre la simulación: Figura 49. Direcciones IP origen y destino asignadas al generador de tráfico para fines de construcción de las entidades IP. Figura 50. Parametrización del módulo EtherChannel_HA_Algorithm. 39

66 Arquitectura de balanceo de carga dinámico para la lógica de conmutación EtherChannel Para uno de los paquetes generados (ID 5) (Figura 51), se verifican los mensajes de simulación confirmando la correcta operación del módulo (Figura 52): Figura 51. Flujo de paquetes hacia el módulo EtherChannel_HA_Algorithm durante validación. Figura. 52. Mensajes de simulación para el paquete ID 5 que confirman direcciones IP y el contenido del campo ici_id con el índice de la interfaz. Como segunda prueba de esta validación, se parametriza el algoritmo para procesar direcciones IP destino en los paquetes ( 1 > ip-dst ) y se corre la simulación: Figura 53. Parametrización del módulo EtherChannel_HA_Algorithm. Para uno de los paquetes generados (ID 3) (Figura 54), se verifican los mensajes de simulación confirmando la correcta operación del módulo (Figura 55): Figura 54. Flujo de paquetes hacia el módulo EtherChannel_HA_Algorithm durante validación. Figura 55. Mensajes de simulación para el paquete ID 3 que confirman direcciones IP y el contenido del campo ici_id con el índice de interfaz. Como tercera prueba de esta validación, parametriza el algoritmo para procesar direcciones IP origen y destino con (2 > ip-src-dst) y se corre la simulación. 40

67 DESARROLLOS Figura 56. Parametrización del módulo EtherChannel_HA_Algorithm. El último octeto de es 4 > El último octeto de es 1 > El resultado de la operación XOR entre ambos octetos es Se aplica una operación AND entre este octeto y el código binario de ocho bits para el número 7 (lo cual equivale a 5 ). Posteriormente se recuperan los tres bits menos significativos del octeto resultado, los cuales corresponden al índice de la interfaz de salida. Esto puede verificarse en la Figura 57. Figura 57. Mensajes de simulación que confirman direcciones IP para un paquete procesado y el campo ici_id con el índice de la interfaz 5. En el Anexo G (en medio digital), se encuentran las Figuras 47 a 57 con mayor detalle gráfico (Figura G.18 a Figura G.28, respectivamente) Módulo SWFabric_Processor Este módulo recibe paquetes de datos con el paquete de contexto ICI anexo, recupera el campo ici_id (determinado por el algoritmo de asignación de carga en operación) y selecciona la interfaz de salida respectiva. Tiene un estado por defecto en el cual conmuta los paquetes que recibe desde el módulo EtherChannel_HA_Algorithm. A continuación se presenta el modelo de proceso desarrollado en OPNET Modeler para este módulo: Figura 58. Modelo de Proceso OPNET para el módulo SWFabric_Processor. 41

68 Arquitectura de balanceo de carga dinámico para la lógica de conmutación EtherChannel El código en Proto-C de este modelo de proceso, se encuentra en la documentación digital del proyecto. En el Anexo B puede encontrarse el proceso de validación de este módulo Módulo StatisticsPoller A continuación se presenta el modelo de proceso desarrollado en OPNET Modeler para este módulo: Figura 59. Modelo de Proceso OPNET para el módulo StatisticsPoller. El código en Proto-C de este modelo de proceso, se encuentra en la documentación digital del proyecto. En el Anexo C se puede encontrar el proceso de validación de este módulo Módulo WeightsLoad_Settings A continuación se presenta el modelo de proceso desarrollado en OPNET Modeler para este módulo. Figura 60. Modelo de Proceso OPNET para el módulo WeightsLoad_Settings. El código en Proto-C de este modelo de proceso, se encuentra en la documentación digital del proyecto. En el Anexo D se puede encontrar el proceso de validación de este módulo Módulos SM_Ctrl_Switch RoundRobin Scheduler RoundRobin Deficit A continuación se presenta el modelo de proceso desarrollado en OPNET Modeler para el módulo SM_Ctrl_Switch. Figura 61. Modelo de Proceso OPNET para el módulo SM_Ctrl_Switch. 42

69 DESARROLLOS En el Anexo G (en medio digital), se encuentra la Figura 61 con mayor detalle gráfico (Figura G.29). La Figura 62 presenta la relación operacional entre los módulos SM_Ctrl_Switch y el conjunto modular RRD Algorithm, orientada a una operación coordinada durante el ingreso, permanencia y salida del Switch del modo Recuperación.En el Anexo G (en medio digital), se encuentra la Figura 62 con mayor detalle gráfico (Figura G.30). Figura 62. Modelo de nodo de conmutación donde se destaca el conjunto modular que implementa el algoritmo RRD ( SM_Ctrl_Switch RoundRobin_Scheduler Conjunto RoundRobin_Deficit ). A continuación se presenta la operación del conjunto. 1. La operación por defecto del módulo SM_Ctrl_Switch es Modo Normal (EtherChannel Hashing Algorithm). 2. Las ocho subcolas RRD reciben los créditos calculados desde el módulo WeightsLoad_Settings. 3. Cada subcola RRD, cuando puede atender un paquete, lo contextualiza con su ID (creación y anexado de paquete OPNET ICI) de manera que corresponda al índice de una interfaz de salida. 4. Iniciando el proceso, cuando el módulo SM_Ctrl_Switch recibe un mensaje de señalización (Ingreso a Modo Recuperación RRD Algorithm), primero conmuta el Switch para desviar tráfico hacia el módulo RoundRobin_Scheduler, de manera que los paquetes fluyan hacia las subcolas y haya oportunidad para cargar algunos paquetes en las 8 subcolas del método alterno. 5. Todas las 8 subcolas tienen funcionalidad similar en lo referente al algoritmo Round Robin Deficit. La única cola que tiene diferencias funcionales relacionadas con la activación y desactivación del control Round Robin es la cola q_7. La simulación DES en principio funciona con una lista de eventos que es alimentada por los módulos que necesitan crear o modificar eventos. El algoritmo Round Robin, en caso de no encontrar paquetes de usuario para extraer de las subcolas internas, produce excesivamente paquetes de señalización que copan la Lista de Eventos de la simulación y no dan oportunidad a los paquetes de datos de usuario de accesar a esa lista. Esto tiene el efecto de no permitir que avance el tiempo de simulación. El módulo de proceso de la subcola q_7 tiene un control que permite iniciar y detener la señalización de recorrido Round Robin de acuerdo a instrucción desde el módulo SM_Ctrl_Switch. En adición, hay una variación del algoritmo Round Robin con la cual hay un retardo de 5ms antes de pasar la señal de recorrido Round Robin entre subcolas, el cual da la oportunidad de ingreso de nuevos paquetes al modelo de nodo del Switch ms después, el módulo SM_Ctrl_Switch señaliza la subcola q_7 e inicia el recorrido de las subcolas, como parte del algoritmo RR. Deficit. 7. Cuando el módulo SM_Ctrl_Switch recibe un mensaje de señalización (Modo Normal ), primero el módulo SM_Ctrl_Switch señaliza la subcola q_7 para activar un último ciclo de Round Robin durante el cual el nivel de créditos es alto para desocupar las subcolas. Para esto se estima un retardo de peor caso de 250ms. 8. Durante este periodo, el Switch no conmuta paquetes de datos de usuario; encola los mismos para que sean atendidos posteriormente por el algoritmo de hashing de bits de EtherChannel. 9. Terminado este periodo, el Switch conmuta el tráfico outbound hacia el módulo EtherChannel_HA_Algorithm para operación Normal. 43

70 Arquitectura de balanceo de carga dinámico para la lógica de conmutación EtherChannel A continuación se presentan los modelos de proceso OPNET para cualquiera de las subcolas q_0 q_6, y la subcola q_7. Figura 63. Modelo de Proceso OPNET para el módulo de subcola q_0 q_6. Figura 64. Modelo de Proceso OPNET para el módulo de subcola q_7. El código en Proto-C de este modelo de proceso, se encuentra en la documentación digital del proyecto. En el Anexo E se puede encontrar el proceso de validación de este módulo. En el Anexo G (en medio digital), se encuentran la Figura 63 y la Figura 64 con mayor detalle gráfico (Figura G.31 y Figura G.32, respectivamente) Módulos Collector A continuación se presenta el modelo de proceso OPNET para el módulo Collector. Este modelo se instancia para cubrir las necesidades de ocho colectores; cada instancia se identifica por un ID de Collector asociado al índice de interfaz de salida. Figura 65. Modelo de Proceso OPNET para el módulo Collector. El código en Proto-C de este modelo de proceso, se encuentra en la documentación digital del proyecto. En el Anexo F puede encontrarse el proceso de validación de este módulo. En el Anexo G (en medio digital), se encuentra la Figura 65 con mayor detalle gráfico (Figura G.33). 44

71 3.2.9 Estadísticas programadas DESARROLLOS Respecto a las estadísticas programadas, se tiene la estadística Estado de Sistema y la estadística Retardo de Procesamiento Nodal : Figura 66. Estadística Estado de Sistema. El Switch puede estar en uno de dos estados: 0 > Modo Normal; 1 > Modo Recuperación. Para el escenario de simulación, la estadística responde a la expectativa con una forma de onda cuadrada dada la programación de 0,5 transiciones por segundo. Figura 67. Estadística Retardo de Procesamiento Nodal. Se puede verificar una parte de la distribución con comportamiento constante cercana a los 1,25ms atribuible al método de hashing de bits de EtherChannel y una dispersión de retardos atribuible al método RRD dadas las características de encolamiento y servicio RRD. 45

72 Arquitectura de balanceo de carga dinámico para la lógica de conmutación EtherChannel 4. ANALISIS DE RESULTADOS 4.1 PLAN DE SIMULACIONES DEL PROYECTO Modelo de Tráfico de Entrada Con respecto a las Figuras 25 y 26, el tráfico de entrada al modelo de nodos es producido por dos subredes (Subred_0 / Subred_1), cada una de las cuales cuenta con 8 estaciones conectadas a un nodo Access_SW que modela un multiplexor estadístico para tráfico outbound. El enlace de salida desde el multiplexor estadístico hasta el puerto de acceso del nodo de conmutación fue modelado con un ancho de banda de 512kbps en modo full dúplex. En adición, cada una de las estaciones de trabajo fue modelada con un generador de tráfico cuya operación es parametrizada con dos funciones de distribución que responden a las siguientes necesidades: Tiempo entre generación de entidades de datos, que responde a una distribución exponencial con parámetro α, el cual será detallado en parágrafos posteriores para cada estación. Tamaños de Paquete, que responden una distribución uniforme con Tamaño de Paquete Promedio de 760 bytes. Por esta razón, los tiempos de servicio en el sistema de espera del multiplexor estadístico son independientes con la misma distribución de probabilidad. Así, el multiplexor estadístico puede modelarse con un sistema de espera M/G/1. Respecto a las configuraciones de cada una de las estaciones de trabajo Para la Subred_0 PC_1: Distribución de tiempos entre generaciones de paquetes: Exponencial. Parámetro 1/α = 0.1 > 10 packets/s IP Origen: IP Destino: PC_2: Distribución de tiempos entre generaciones de paquetes: Exponencial. Parámetro 1/α = 0.1 > 10 packets/s IP Origen: IP Destino: PC_3: Distribución de tiempos entre generaciones de paquetes: Exponencial. Parámetro 1/α = 1 > 1 packets/s IP Origen: IP Destino: PC_4: Distribución de tiempos entre generaciones de paquetes: Exponencial. Parámetro 1/α = 0.1 > 10 packets/s IP Origen: IP Destino: PC_5: Distribución de tiempos entre generaciones de paquetes: Exponencial. Parámetro 1/α = 0.1 > 10 packets/s IP Origen: IP Destino: PC_6: Distribución de tiempos entre generaciones de paquetes: Exponencial. Parámetro 1/α = 0.1 > 10 packets/s IP Origen: IP Destino: PC_7: Distribución de tiempos entre generaciones de paquetes: Exponencial. Parámetro 1/α = 0.1 > 10 packets/s IP Origen: IP Destino: PC_8: Distribución de tiempos entre generaciones de paquetes: Exponencial. Parámetro 1/α = 0.05 > 20 packets/s IP Origen: IP Destino: Para la Subred_1 PC_1: Distribución de tiempos entre generaciones de paquetes: Exponencial. Parámetro 1/α = 0.05 > 20 packets/s IP Origen: IP Destino: PC_2: Distribución de tiempos entre generaciones de paquetes: Exponencial. Parámetro 1/α = 0.1 > 10 packets/s IP Origen: IP Destino: PC_3: Distribución de tiempos entre generaciones de paquetes: Exponencial. Parámetro 1/α = 0.1 > 10 packets/s IP Origen: IP Destino: PC_4: Distribución de tiempos entre generaciones de paquetes: Exponencial. 46

73 ANALISIS DE RESULTADOS Parámetro 1/α = 1 > 1 packets/s IP Origen: IP Destino: PC_5: Distribución de tiempos entre generaciones de paquetes: Exponencial. Parámetro 1/α = 0.1 > 10 packets/s - IP Origen: IP Destino: PC_6: Distribución de tiempos entre generaciones de paquetes: Exponencial. Parámetro 1/α = 0.1 > 10 packets/s IP Origen: IP Destino: PC_7: Distribución de tiempos entre generaciones de paquetes: Exponencial. Parámetro 1/α = 0.1 > 10 packets/s IP Origen: IP Destino: PC_8: Distribución de tiempos entre generaciones de paquetes: Exponencial. Parámetro 1/α = 0.1 > 10 packets/s IP Origen: IP Destino: De acuerdo a la propiedad de fusión para procesos de arribo de Poisson independientes, se tiene una tasa de arribo agregada a los multiplexores estadísticos de las dos subredes de 81 packets/s. 81 packets / s * 760 bytes / packet * 8 bits / byte = 492.5kbps valor esperado. En este orden de ideas, 8 enlaces de 56kbps = 448kbps ofrecen capacidad agregada fija suficiente para el tráfico saliente. Así, un enlace de 512kpbs entre el nodo Access_SW y el nodo de conmutación ofrece un ρ esperado del 96% aproximadamente. Con un enlace de salida de 512kpbs y valor esperado de paquete de 760 bytes por paquete, se tiene una tasa de servicio esperada para el multiplexor de 81 packets por segundo y por tanto un retardo entre servicios de 0.01segundos. Para fines de simulación y verificación del comportamiento de los algoritmos, se carga el generador PC_3 con 50 packets/s y PC_1 con 100 packets/s en la Subred_0; y se carga el generador PC_4 con 50 packets/s y PC_3 con 100 packets/s en la Subred_1, como valores esperados de acuerdo a distribución exponencial Definición de Estadísticas y Parametrización del Modelo de Red De acuerdo a los objetivos del proyecto, se han definido y configurado las siguientes parametrizaciones y estadísticas en el modelo que pueden modificar el comportamiento del Switch; y pueden ser colectadas desde la simulación, respectivamente: 1. Estadística: RETARDO DE PROCESAMIENTO NODAL FWD (basado en el tiempo de simulación y estampas de tiempo en los paquetes de datos). 2. Parametrización: VARIACIONES DEL ARGUMENTO ALPHA, α, como parámetro de la media acotada de la muestra de tráfico en los módulos Collector. a. 25% de muestras (mínimas y máximas) no consideradas en el cálculo de la media muestral discreta de tráfico por collector [aberrantes]. b. 15% de muestras (mínimas y máximas) no consideradas en el cálculo de la media muestral discreta de tráfico por collector [aberrantes]. c. 5% de muestras (mínimas y máximas) no consideradas en el cálculo de la media muestral discreta de tráfico por collector [aberrantes]. 3. Parametrización: OPERACIÓN DEL SWITCH. a. DISABLED: Operación conjunta modo Normal/modo Recuperación. b. ENABLED: Operación exclusiva modo Normal (EtherChannel Hashing). 4. Estadística: NIVEL DE INGRESO EN MODO RECUPERACIÓN/NORMAL. 5. Estadística: REGISTRO DEL FACTOR DE UTILIZACIÓN DE ENLACES OUTBOUND (resultante de las estadísticas predefinidas de la simulación DES en OPNET). 6. Parametrización: TIEMPO DE SIMULACIÓN. a. 1 hora b. 5 horas. 47

74 Arquitectura de balanceo de carga dinámico para la lógica de conmutación EtherChannel A partir de estas configuraciones y resultados, así como los objetivos del proyecto, se puede definir el siguiente plan de configuraciones y registro de simulaciones de acuerdo a expectativas. Figura 68. Plan de Simulaciones del Proyecto. De acuerdo a la Figura 68, se proponen las siguientes 5 simulaciones: 1. Operación del Switch en Modo Normal (Exclusivamente EtherChannel Hashing de Bits). a. Método de conmutación EtherChannel: src-ip / dst-ip / src-dst-ip b. Tiempo de simulación: 1 hora. c. Objetivos: Verificar el Retardo de Procesamiento Nodal / Ocupación de Enlaces. 2. Operación del Switch con operación conjunta (Arquitectura Propuesta) (Modo Normal: EtherChannel Hashing de Bits / Modo Recuperación: Round Robin Deficit). a. Método de conmutación EtherChannel: src-dst-ip b. Tiempo de simulación: 1 hora Variación de Alpha: 25% c. Objetivos: Verificar el Retardo de Procesamiento Nodal / Ocupación de Enlaces / Nivel de ingreso en modo Normal Recuperación. 3. Operación del Switch con operación conjunta (Arquitectura Propuesta) (Modo Normal: EtherChannel Hashing de Bits / Modo Recuperación: Round Robin Deficit). a. Método de conmutación EtherChannel: src-dst-ip b. Tiempo de simulación: 1 hora Variación de Alpha: 15% c. Objetivos: Verificar el Retardo de Procesamiento Nodal / Ocupación de Enlaces / Nivel de ingreso en modo Normal Recuperación. 4. Operación del Switch con operación conjunta (Arquitectura Propuesta) (Modo Normal: EtherChannel Hashing de Bits / Modo Recuperación: Round Robin Deficit). a. Método de conmutación EtherChannel: src-dst-ip b. Tiempo de simulación: 1 hora Variación de Alpha: 5% c. Objetivos: Verificar el Retardo de Procesamiento Nodal / Ocupación de Enlaces / Nivel de ingreso en modo Normal Recuperación. 5. Operación del Switch con operación conjunta (Arquitectura Propuesta) (Modo Normal: EtherChannel Hashing de Bits / Modo Recuperación: Round Robin Deficit). a. Método de conmutación EtherChannel: src-dst-ip b. Tiempo de simulación: 5 horas Variación de Alpha: 25% c. Objetivos: Verificar Ocupación de Enlaces. 48

75 ANALISIS DE RESULTADOS 4.2 EJECUCIÓN DE PLAN DE SIMULACIONES ANÁLISIS DE RESULTADOS Con respecto a la simulación del modelo del método de asignación de carga EtherChannel y la simulación del modelo de arquitectura propuesta de asignación y balanceo de carga, así como el establecimiento de un marco comparativo y analítico de los resultados de la simulación, se ejecuta el Plan de Simulaciones del proyecto descrito en la Figura 68. A continuación se presentan los resultados y los análisis pertinentes. Todas las imágenes presentadas en esta sección son detalladas gráficamente en el Anexo G en medio digital Análisis de resultados Simulación No. 1 (Método Hashing de Bits > src-ip) Ocupación de Enlaces (Tráfico Saliente): Figura 69. Ocupación Outbound promedio de enlaces de salida. Figura 70. Frecuencias para observaciones de tráfico saliente. Con respecto a la Figura 69 y Figura 70, se verifica la operación del algoritmo Hashing de Bits de EtherChannel, según expectativa. De acuerdo a la Figura 70, pueden apreciarse dos enlaces con ocupaciones de relevancia, enlace 3 y enlace 6. Puesto que la parametrización del método es src-ip y verificando las configuraciones de los generadores de tráfico en la subred_0, se encuentra el argumento de estos resultados. PC_1: Distribución de tiempos entre generaciones de paquetes: Exponencial. Parámetro 1/λ = 100 packets/s IP Origen: (Carga el enlace 6) PC_3: Distribución de tiempos entre generaciones de paquetes: Exponencial. Parámetro 1/λ = 50 packets/s IP Origen: (Carga el enlace 3) PC_5: Distribución de tiempos entre generaciones de paquetes: Exponencial. Parámetro 1/λ = 10 packets/s IP Origen: (Carga el enlace 3) PC_6: Distribución de tiempos entre generaciones de paquetes: Exponencial. Parámetro 1/λ = 10 packets/s IP Origen: (Carga el enlace 6) Para la dirección origen en PC_1 sus bits menos significativos son 110, cargando el enlace ID 6. Para la dirección origen en PC_5 sus bits menos significativos son 011, cargando el enlace ID 3. Ocupación de Enlaces (Tráfico Entrante): Figura 71. Ocupación Inbound promedio de enlaces de salida. Figura 72. Frecuencias de observaciones de tráfico entrante. 49

76 Arquitectura de balanceo de carga dinámico para la lógica de conmutación EtherChannel La Figura 71 y Figura 72 presentan el comportamiento de tráfico entrante en el conjunto de interfaces. De acuerdo a la Figura 72, pueden apreciarse dos enlaces con ocupaciones de relevancia, enlace 3 y enlace 4. Puesto que la parametrización del método EtherChannel es src-ip y verificando las configuraciones de los generadores de tráfico en la subred_1, se encuentra el argumento de estos resultados. PC_3: Distribución de tiempos entre generaciones de paquetes: Exponencial. Parámetro 1/λ = 100 packets/s IP Origen: (Carga el enlace ID 3) PC_4: Distribución de tiempos entre generaciones de paquetes: Exponencial. Parámetro 1/λ = 50 packets/s IP Origen: (Carga el enlace ID 4) Para la dirección origen en PC_3 sus bits menos significativos son 011, cargando el enlace ID 3. Para la dirección origen en PC_4 sus bits menos significativos son 100, cargando el enlace ID 4. Retardo de Procesamiento Nodal: Figura 73. Retardo de Procesamiento Nodal. Figura74. CDF Retardo de Procesamiento Nodal. De acuerdo a la Figura 73 y Figura 74 puede verificarse un comportamiento multimodal del retardo de procesamiento nodal y hay una probabilidad de casi el 84% de encontrar esta medición por debajo de 3,1ms aproximadamente Análisis de resultados Simulación No. 1 (Método Hashing de Bits > dst-ip) Ocupación de Enlaces (Tráfico Saliente): Figura 75. Ocupación Outbound promedio de enlaces de salida. Figura 76. Frecuencias para observaciones de tráfico saliente. Con respecto a la Figura 75 y Figura 76, se verifica la operación del algoritmo Hashing de Bits de EtherChannel, según expectativa. De acuerdo a la Figura 76, pueden apreciarse dos enlaces con ocupaciones de relevancia, enlace 4 y enlace 6. Puesto que la parametrización del método EtherChannel es dst-ip y verificando las configuraciones de los generadores de tráfico en la subred_0, se encuentra el argumento de estos resultados. PC_1: Distribución de tiempos entre generaciones de paquetes: Exponencial. Parámetro 1/λ = 100 packets/s IP Destino: (Carga el enlace ID 4) 50

77 PC_3: PC_6: Distribución de tiempos entre generaciones de paquetes: Exponencial. Parámetro 1/λ = 50 packets/s IP Destino: (Carga el enlace ID 6) Distribución de tiempos entre generaciones de paquetes: Exponencial. Parámetro 1/λ = 10 packets/s IP Destino: (Carga el enlace ID 4) ANALISIS DE RESULTADOS Para la dirección destino en PC_1 sus bits menos significativos son 100, cargando el enlace ID 4. Ocupación de Enlaces (Tráfico Entrante): Figura 77. Ocupación Inbound promedio de enlaces de salida. Figura 78. Frecuencias de observaciones de tráfico entrante. La Figura 77 y la Figura 78 presentan el comportamiento de tráfico entrante en el conjunto de interfaces. De acuerdo a la Figura 78, pueden apreciarse dos enlaces con ocupaciones de relevancia, enlace 1 y enlace 3. Puesto que la parametrización del método EtherChannel es dst-ip y verificando las configuraciones de los generadores de tráfico en la subred_1, se encuentra el argumento de estos resultados. PC_3: PC_4: Distribución de tiempos entre generaciones de paquetes: Exponencial. Parámetro 1/λ = 100 packets/s IP Destino: (Carga el enlace ID 1) Distribución de tiempos entre generaciones de paquetes: Exponencial. Parámetro 1/λ = 50 packets/s IP Destino: (Carga el enlace ID 3) Respecto a la estadística Retardo de Procesamiento Nodal, se tienen resultados similares a los presentados en la Figura 73 y la Figura Análisis de resultados Simulación No. 1 (Método Hashing de Bits > src-dst-ip) Ocupación de Enlaces (Tráfico Entrante): Figura 79. Ocupación Inbound promedio de enlaces de salida. Figura 80. Frecuencias de observaciones de tráfico entrante. La Figura 79 y la Figura 80 presentan el comportamiento de tráfico entrante en el conjunto de interfaces. La Figura 80 presenta la distribución de frecuencias en las observaciones de tráfico, en la cual puede apreciarse la preferencia que el método de conmutación ofrece sobre los enlaces 2 y 7. Puesto que la parametrización del método EtherChannel es src-dst-ip y verificando las configuraciones de los generadores de tráfico en la subred_1, se encuentra el argumento de estos resultados. 51

78 Arquitectura de balanceo de carga dinámico para la lógica de conmutación EtherChannel PC_3: PC_4: PC_6: Distribución de tiempos entre generaciones de paquetes: Exponencial. Parámetro 1/λ = 100 packets/s IP Origen: IP Destino: XOR (3 bits LSB) = 010 > 2 (Carga el enlace ID 2) Distribución de tiempos entre generaciones de paquetes: Exponencial. Parámetro 1/λ = 50 packets/s IP Origen: IP Destino: XOR (3 bits LSB) = 111 > 7 (Carga el enlace ID 7) Distribución de tiempos entre generaciones de paquetes: Exponencial. Parámetro 1/λ = 10 packets/s IP Origen: IP Destino: XOR (3 bits LSB) = 010 > 2 (Carga el enlace ID 2) Ocupación de Enlaces (Tráfico Saliente): Figura 81. Ocupación Outbound promedio de enlaces de salida. Figura 82. Frecuencias de observaciones de tráfico saliente. La Figura 81 y la Figura 82 presentan el comportamiento de tráfico saliente en el conjunto de interfaces. La Figura 82 presenta la distribución de frecuencias en las observaciones de tráfico, en la cual puede apreciarse la preferencia que el método de conmutación ofrece sobre los enlaces 2 y 5. Puesto que la parametrización del método EtherChannel es src-dst-ip y verificando las configuraciones de los generadores de tráfico en la subred_0, se encuentra el argumento de estos resultados. PC_1: PC_2: PC_3: PC_6: Distribución de tiempos entre generaciones de paquetes: Exponencial. Parámetro 1/λ = 100 packets/s IP Origen: IP Destino: XOR (3 bits LSB) = 010 > 2 (Carga el enlace ID 2) Distribución de tiempos entre generaciones de paquetes: Exponencial. Parámetro 1/λ = 10 packets/s IP Origen: IP Destino: XOR (3 bits LSB) = 101 > 5 (Carga el enlace ID 5) Distribución de tiempos entre generaciones de paquetes: Exponencial. Parámetro 1/λ = 50 packets/s IP Origen: IP Destino: XOR (3 bits LSB) = 101 > 5 (Carga el enlace ID 5) Distribución de tiempos entre generaciones de paquetes: Exponencial. Parámetro 1/λ = 10 packets/s IP Origen: IP Destino: XOR (3 bits LSB) = 010 > 2 (Carga el enlace ID 2) Retardo de Procesamiento Nodal: Figura 83. Retardo de Procesamiento Nodal. Figura 84. CDF Retardo de Procesamiento Nodal. 52

79 ANALISIS DE RESULTADOS De acuerdo a la Figura 83 y la Figura 84 puede verificarse un comportamiento multimodal del retardo de procesamiento nodal, similar a los casos anteriores, y hay una probabilidad de casi 84% de encontrar esta medición por debajo de 3,1ms aproximadamente. Por tanto, de acuerdo a los resultados de la simulación para las tres parametrizaciones del método Hashing de Bits del método EtherChannel, se encuentra que el retardo de procesamiento nodal que imprime el método EtherChannel es independiente de la configuración del algoritmo para condiciones de tráfico similares en escenarios distintos Análisis de resultados Simulación No. 2 Arquitectura propuesta (Modo Normal: EtherChannel Hashing / Modo Recuperación: RRD) Alpha: 25% - Método Hashing: src-dst-ip Ocupación de Enlaces (Tráfico Saliente): Figura 85. Ocupación Outbound promedio de enlaces de salida (alpha 25%). Figura 86. Estadística Estado de Sistema (alpha 25%). Figura 87. Frecuencias de observaciones de tráfico saliente (alpha 25%). La Figura 85 y la Figura 87 presentan el comportamiento de tráfico saliente en el conjunto de interfaces del canal lógico. Dada la operación alternada entre el modo Normal y el modo Recuperación para esta simulación, la Figura 86 muestra la estadística Estado de Sistema en la cual las franjas azules corresponden al ingreso del Switch en el modo Recuperación, y la ausencia de franjas muestra el tiempo durante el cual el Switch ha estado en modo Normal. Así, puede evidenciarse la consistencia entre la finalización de los ingresos del Switch al modo Recuperación y el alcance de una condición de balance (Figura 85 y Figura 86). La Figura 87 presenta la distribución de frecuencias en las observaciones de la variable Link Utilization Ocupación, en la cual puede apreciarse que cerca del 90% de las observaciones de esa variable para los 8 enlaces se encuentra alrededor del 3,6%. 53

80 Arquitectura de balanceo de carga dinámico para la lógica de conmutación EtherChannel La Figura 88 y la Figura 89 presentan el comportamiento de tráfico entrante en el conjunto de interfaces de salida. Como puede verificarse en la Figura 88, el comportamiento de la ocupación en el canal lógico es similar al presentado en la Figura 85. De acuerdo a las curvas de salida, se evidencia la convergencia característica del método RRD hacia la condición de balance prestablecida. Por su definición, su alcance puede ser más o menos exigente para el modelo en términos de permanencia del Switch en modo Recuperación, como puede apreciarse en la Figura 86. La Figura 89 presenta la distribución de frecuencias de las observaciones de la variable Link Utilization Ocupación, en la cual puede apreciarse, al igual que en el caso anterior, que cerca del 90% de las observaciones de esa variable para los 8 enlaces del canal lógico se encuentran alrededor del 3,6%. Ocupación de Enlaces (Tráfico Entrante): Figura 88. Ocupación Inbound promedio de enlaces de salida (alpha 25%). Figura 89. Diagrama de Frecuencias de observaciones de tráfico Inbound (alpha 25%). Figura 90. Retardo de Procesamiento Nodal (alpha 25%). Figura 91. CDF Retardo de Procesamiento Nodal (alpha 25%). En la Figura 90 y la Figura 91 puede verificarse el comportamiento del retardo de procesamiento nodal. Con respecto a la expectativa funcional del modo operacional conjunto, de acuerdo a la Figura 91 hay una probabilidad de casi 95% de encontrar la medición por debajo de 75ms aproximadamente. Por medio del análisis de los escenarios anteriores, en las Figuras 79 y 81 se confirma que el método de Hashing de Bits de EtherChannel, en particular con la configuración src-dst-ip, puede no preferir algunos enlaces los cuales tendrían ocupaciones promedio cercanas a 0 durante algunos periodos de tiempo y el algoritmo del módulo WeightsLoad_Settings solo tiene en cuenta pesos de recuperación para enlaces con ocupaciones promedio superiores mas no iguales a 0. Así, se corre de nuevo esta simulación con una serie de modificaciones al modelo que involucran la consideración de un peso máximo de recuperación (400) para enlaces con ocupaciones promedio de 0 durante el periodo de medición de los módulos Collector, un tiempo de servicio interno de paquetes en el módulo SM_Ctrl_Switch de 150us aproximadamente, así como un porcentaje del 95% de los valores en las medias de tráfico para influenciar la decisión de cambio de modo operacional por parte del módulo LeastLoad_Analysis. Se efectúa la comparación entre las ocupaciones del canal lógico para el tráfico entrante y saliente, así como la estadística Estado de Sistema, para los resultados antes y después de las modificaciones en mención. 54

81 ANALISIS DE RESULTADOS Ocupación de Enlaces (Tráfico saliente): Figura 92. Ocupación Outbound promedio de enlaces de salida antes de modificación (alpha 25%). Figura 93. Ocupación Outbound promedio de enlaces de salida después de modificación (alpha 25%). Figura 94. Diagrama de Frecuencias de observaciones de tráfico saliente post modificación (alpha 25%). Figura 95. Estadística Estado de Sistema (alpha 25%). La Figura 92 y la Figura 93 presentan el comportamiento de tráfico saliente en el conjunto de interfaces del canal lógico pre y post modificación. Puede evidenciarse la habilidad del Switch mejorada para restablecer mucho más rápidamente la condición de balance, lo cual se confirma con los resultados de la Figura 95, con un solo ingreso de 30 segundos al modo Recuperación para efectuar el restablecimiento del caso. En adición, la Figura 94 presenta la distribución de frecuencias en las observaciones de la variable Ocupación, en la cual puede apreciarse que cerca del 96% (6% más que antes de la modificación) de las observaciones para los 8 enlaces se encuentran alrededor del 3,6%. Situación similar para las mediciones de tráfico entrante, lo cual se verifica en la Figura 96, la Figura 97 y la Figura 98 (a continuación). En adición, en la Figura 98 puede apreciarse que cerca del 98% (8% más que antes de la modificación) de las observaciones de la variable Ocupación para los 8 enlaces se encuentran alrededor del 3,6%. Ocupación de Enlaces (Tráfico entrante): Figura 96. Ocupación Inbound promedio de enlaces de salida antes de modificación (alpha 25%). Figura 97. Ocupación Inbound promedio de enlaces de salida después de modificación (alpha 25%). 55

82 Arquitectura de balanceo de carga dinámico para la lógica de conmutación EtherChannel Figura 98. Diagrama de Frecuencias de observaciones de tráfico entrante (alpha 25%). Figura 99. Comparación entre CDFs Retardo de Procesamiento Nodal antes (azul) y después (rojo) de modificación propuesta (alpha 25% - Escala X logarítmica). La Figura 99 presenta una comparación pre (traza azul) y post (traza roja) modificación de la distribución de probabilidad acumulativa de la estadística Retardo de Procesamiento Nodal. Se puede verificar una convergencia en la tendencia a mantener el retardo global por debajo de 75ms. El hecho que la operación conjunta del modelo cambie el retardo de procesamiento nodal desde 3,1ms promedio a 75ms mayoritariamente viene de un retardo inducido de 5ms entre atención de subcolas del método RRD durante el modo Recuperación. 8 subcolas sugieren un retardo mínimo de atención del conjunto de subcolas de 40ms (bajo la presunción de subcolas vacías) y casi dos ciclos de Round Robin para atender paquetes de datos por parte del método propuesto. Si se extrapolan estas conclusiones a partir de los resultados de la gráfica, se puede afirmar que el 100% de las observaciones de retardo están por debajo de 80ms aproximadamente Análisis de resultados Simulación No. 3 Alpha: 15% - Método Hashing: src-dst-ip Ocupación de Enlaces (Tráfico saliente): Figura 100. Ocupación Outbound promedio de enlaces de salida antes de modificación (alpha 15%). Figura 101. Ocupación Outbound promedio de enlaces de salida post modificación (alpha 15%). 56

83 ANALISIS DE RESULTADOS Figura 102. Diagrama de Frecuencias de observaciones de tráfico Outbound (alpha 15%). Figura 103. Diagrama de frecuencias de observaciones de tráfico Outbound post modificación (alpha 15%). La Figura 100 y la Figura 101 presentan el comportamiento de tráfico saliente en el conjunto de interfaces de salida, pre y post modificación. Como el parámetro alpha 15% implica considerar más aberrantes en el cálculo de la media de tráfico por módulo Collector, el modelo debe considerar un aumento en la desviación estándar de la muestra de tráfico de las interfaces por ciclo de análisis, conllevando a más ingresos del Switch al modo Recuperación y un aumento del retardo de recuperación de la condición de balance (ver Figura 108). La Figura 102 presenta el diagrama de frecuencias de observaciones de la variable ocupación con hasta 77 % de las observaciones (14% menos que el escenario anterior) alrededor de la tendencia de ocupación de 3,6%. Contrasta este resultado con el diagrama de frecuencias post modificación presentado en la Figura 103, donde se observa una menor dispersión muestral y hasta un 96% de las observaciones alrededor de la tendencia del 3,6%. La Figura 101 muestra el comportamiento ágil del modelo para recuperar el balance entre las ocupaciones del canal lógico, aún en este escenario donde se consideran más variaciones de tráfico saliente. Las mismas consideraciones aplican para los resultados de la simulación para tráfico entrante, con la Figura 104 y la Figura 105 presentando el comportamiento de tráfico entrante en el conjunto de interfaces de salida. La Figura 106 y la Figura 107 presentan los diagramas de frecuencias de observaciones de la variable ocupación pre y post modificación. Ocupación de Enlaces (Tráfico entrante): Figura 104. Ocupación Inbound promedio de enlaces de salida antes de modificación (alpha 15%). Figura 105. Ocupación Inbound promedio de enlaces de salida después de modificación (alpha 15%). Figura 106. Diagrama de Frecuencias de observaciones de tráfico entrante pre modificación (alpha 15%). Figura 107. Diagrama de Frecuencias de observaciones de tráfico entrante post modificación (alpha 15%). 57

84 Estadística: Estado de Sistema: Arquitectura de balanceo de carga dinámico para la lógica de conmutación EtherChannel Figura 108. Est. Estado de Sistema (pre modificación) (alpha 15%). Figura 109. Est. Estado de Sistema (post modificación) (alpha 15%). La Figura 108 y la Figura 109 presentan los resultados de la estadística Estado de Sistema, evidenciando el volumen de ingresos del Switch en modo Recuperación pre modificación, con respecto a la única entrada del Switch en este modo, post modificación, para recuperar la condición de balance. Sobre el particular, debe tenerse en cuenta que hay una relativa baja variabilidad del tráfico de entrada que explicaría el nivel de ingresos del Switch en el modo Recuperación según Figura 109, pero condiciones de tráfico similar afectaron igualmente la simulación del modelo pre modificación con los múltiples accesos al método de recuperación verificables en la Figura 108. Retardo de Procesamiento Nodal: Figura 110. Retardo de Procesamiento Nodal pre modificación (alpha 15%). Figura 111. Comparación entre CDFs Retardo de Procesamiento Nodal pre-post modific. (alpha 15%). La Figura 110 muestra los resultados de la estadística Retardo de Procesamiento Nodal pre modificación. La Figura 111 presenta una comparación, pre y post modificación, de la distribución de probabilidad acumulativa de la estadística en mención, donde se verifica, similar al escenario de simulación anterior, una característica convergente y una tendencia a mantener el retardo global por debajo de 75ms. Para describir el comportamiento de la característica de retardo en la Figura 90 y en la Figura 110, nótese la coincidencia entre las líneas de crecimiento de retardo en esas figuras con respecto a los instantes de tiempo de las estadísticas Estado de Sistema en los cuales el modo operacional del Switch está conmutando de Recuperación a Normal (Figura 86 y Figura 108, respectivamente). La razón de esta coincidencia radica en la administración del sistema de subcolas del método RRD. Cuando el módulo LeastLoad_Analysis determina que debe realizarse la conmutación de modo, el módulo SM_Ctrl_Switch observa aún en las colas del método RRD puede haber paquetes en espera por servicio de despacho. Así, todo el tráfico entrante al nodo de conmutación es encolado, incrementando el retardo nodal en una base por paquete, hasta que las 8 subcolas RRD son atendidas por completo. Cuando finaliza ese último ciclo de RoundRobin, el módulo SM_Ctrl_Switch realiza la conmutación de modo operacional hacia Normal y comienza a atender la cola de ingreso al sistema. 58

85 4.2.6 Análisis de resultados Simulación No. 4 Alpha: 5% - Método Hashing: src-dst-ip Ocupación de Enlaces (Tráfico Saliente): ANALISIS DE RESULTADOS Figura 112. Ocupación Outbound promedio de enlaces de salida antes de modificación (alpha 5%). Figura 113. Ocupación Outbound promedio de enlaces de salida después de modificación (alpha 5%). Figura 114. Diagrama de Frecuencias de observaciones de ocupación Outbound antes de modificación (alpha 5%). Figura 115. Diagrama de Frecuencias de observaciones de ocupación Outbound después de modif. (alpha 5%). Ocupación de Enlaces (Tráfico Entrante): Figura 116. Diagrama de Frecuencias de observaciones de ocupación Inbound pre modificación (alpha 5%). Figura 117. Diagrama de Frecuencias de observaciones de ocupación Inbound post modificación (alpha 5%). Retardo de Procesamiento Nodal: Figura 118. Retardo de Procesamiento Nodal pre modificación (alpha 5%). Figura 119. Comparación entre CDFs Retardo de Procesamiento Nodal pre (azul) post (verde) modificación (alpha 5%). 59

86 Arquitectura de balanceo de carga dinámico para la lógica de conmutación EtherChannel La Figura 118 muestra los resultados de la estadística Retardo de Procesamiento Nodal pre modificación, para la simulación con parámetro alpha igual a 5%. La Figura 119 presenta una comparación pre y post modificación de la distribución de probabilidad acumulativa de la estadística en mención, donde se puede verificar de nuevo la tendencia a mantener el retardo por debajo de 75ms. Estadística: Estado de Sistema: Figura 120. Estadística Estado de Sistema (pre modificación). Figura 121. Estadística Estado de Sistema (post modificación). Dadas las mismas condiciones de tráfico aplicadas al escenario anterior (alpha 15%) y el escenario actual (alpha 5%), los resultados de la simulación son similares en lo referente a respuesta del Switch y características de tráfico sobre las interfaces de salida, dada la relativa baja variabilidad del tráfico cursado. Sin embargo, la consideración de más muestras para el cálculo de la media muestral de tráfico sobre el conjunto de enlaces (alpha 5%) propone una asignación de créditos de recuperación de carga sobre enlaces de baja ocupación más exigente por parte del módulo WeightsLoad_Settings, lo cual puede evidenciarse en el menor tiempo que el Switch debe permanecer en el modo Recuperación. La Figura 120 muestra el nivel de ingreso al modo Recuperación para las condiciones de simulación presentes pre modificación, y la Figura 121 muestra el nivel de ingreso post modificación. En adición, la Figura 120 muestra una condición casi permanente del Switch en modo Recuperación dada la mayor consideración de observaciones de tráfico por ciclo de procesamiento de los módulos Collector. De acuerdo a los escenarios pre modificación, la simulación con alpha igual al 25% tiene un delta de recuperación que aumenta en 28,8% en el escenario con alpha igual a 15%, y a su vez hay una disminución del 21,6% para el escenario con alpha igual a 5% con respecto al escenario del 15%, considerando un tráfico relativamente bajo en variaciones, lo cual, junto a las características de ocupación pre modificaciones sobre el canal lógico y distribuciones de observaciones de trafico entrante/saliente, muestra que el cálculo de la media de ocupación por enlace es efectivo y presenta rendimiento superior si el cálculo en mención considera una acotación de aberrantes dentro del rango intercuartil para las observaciones de tráfico. Con respecto a los resultados post modificaciones, esta afirmación no es decisiva, siendo aún más importante el corroborar esta apreciación si el tráfico que ha de cursar por los medios de salida tiene características aberrantes de corto término (ráfaga). Para corroborar la validez de la consideración de la media muestral acotada intercuartil como medida de tendencia central de tráfico en los módulos Collector así como la parametrización alpha asociada, se introduce un escenario de simulación de 1 hora (3600 segundos) pre modificación con 2 perturbaciones de tráfico en 1000 y 2000 segundos, con duración de 5 minutos respectivamente, en las dos subredes como se presenta a continuación. Subred 0: PC_3: Distribución de tiempos entre generaciones de paquetes: Exponencial. Parámetro 1/λ = 1 > 1 packets/s. > Se sobre carga con 500 packets/s. Dirección IP Origen: Dirección IP Destino: StartTime: 1000 segundos StopTime: 1300 segundos PC_8: Distribución de tiempos entre generaciones de paquetes: Exponencial. Parámetro 1/λ = 0.05 > 20 packets/s. Se sobre carga con 500 packets/s. Dirección IP Origen: Dirección IP Destino: StartTime: 2000 segundos StopTime: 2300 segundos Solo PC_4 genera tráfico normalmente, las demás fuentes quedan deshabilitadas. 60

87 ANALISIS DE RESULTADOS Subred 1: PC_1: Distribución de tiempos entre generaciones de paquetes: Exponencial. Parámetro 1/λ = 0.05 > 20 packets/s. Se sobre carga con 200 packets/s. Dirección IP Origen: Dirección IP Destino: StartTime: 2000 segundos StopTime: 2300 segundos PC_4: Distribución de tiempos entre generaciones de paquetes: Exponencial. Parámetro 1/λ = 1 > 1 packets/s. > Se sobre carga con 200 packets/s. Dirección IP Origen: Dirección IP Destino: StartTime: 1000 segundos StopTime: 1300 segundos Solo PC_2 genera tráfico normalmente, las demás fuentes quedan deshabilitadas. Análisis tráfico saliente: Figura 122. Ocupación Outbound de enlaces de salida antes de modificación (Alpha 25%). Figura 123. Frecuencias de observaciones de ocupación enlaces de salida tráfico saliente antes de modificación (Alpha 25%). Figura 124. Ocupación Outbound de enlaces de salida antes de modificación (Alpha 15%). Figura 125. Frecuencias de observaciones de ocupación enlaces de salida tráfico salida antes de modificación (Alpha 15%). Figura 126. Ocupación Outbound de enlaces de salida antes de modificación (Alpha 5%). Figura 127. Frecuencias de observaciones de ocupación enlaces de salida tráfico saliente antes de modificación (Alpha 5%). 61

88 Análisis tráfico entrante: Arquitectura de balanceo de carga dinámico para la lógica de conmutación EtherChannel Figura 128. Ocupación Inbound de enlaces de salida antes de modificación (Alpha 25%). Figura 129. Frecuencias de observaciones de ocupación enlaces de salida tráfico entrante antes de modificación (Alpha 25%). Figura 130. Ocupación Inbound de enlaces de salida antes de modificación (Alpha 15%). Figura 132. Ocupación Inbound de enlaces de salida antes de modificación (Alpha 5%). Figura 131. Frecuencias de observaciones de ocupación enlaces de salida tráfico entrante antes de modificación (Alpha 15%). Figura 133. Frecuencias de observaciones de ocupación enlaces de salida tráfico entrante antes de modificación (Alpha 5%). La Figura 122 y la Figura 123 (para el tráfico saliente), y la Figura 128 y la Figura 129 (para el tráfico entrante) muestran, para la parametrización Alpha igual a 25%, un mejor comportamiento sobre el canal lógico y una menor dispersión muestral de las observaciones de ocupación sobre los enlaces físicos con respecto a variables similares para los escenarios con parametrizaciones Alpha iguales a 15 y 5%, aunque hay un comportamiento estadístico similar para tráfico entrante con parametrización Alpha igual a 5%. Estadísticas: Estado de Sistema Retardo de Procesamiento Nodal: Figura 134. Estadística Estado de Sistema Escenario con Perturbaciones antes de modificación (Alpha 25%). Figura 135. CDF Retardo de Proc. Nodal (Alpha 25%). 62

89 ANALISIS DE RESULTADOS Figura 136. Estadística Estado de Sistema Escenario con Perturbaciones antes de modificación (Alpha 15%). Figura 137. CDF Retardo de Proc. Nodal (Alpha 15%). Figura 138. Estadística Estado de Sistema Escenario con Perturbaciones antes de modificación (Alpha 5%). Figura 139. CDF Retardo de Procesamiento Nodal (Alpha 5%). Si se comparan los resultados de la Figura 135 (alpha 25%), la Figura 137 (alpha 15%) y la Figura 139 (alpha 5%) con respecto a los mismos resultados de escenarios anteriores, se evidencia que la distribución del retardo de procesamiento nodal para el modelo tiene un comportamiento similar bajo diferentes escenarios de la parametrización Alpha de la media acotada de tráfico por interfaz y la distribución es independiente del nivel de tráfico en la red Análisis de resultados Simulación No. 5 Alpha: 25% - Método Hashing: src-dst-ip Tiempo de Simulación: 5 horas A continuación se presentan los resultados de esta simulación para un escenario con la consideración de las perturbaciones de tráfico del escenario descrito en la sección 4.2.6, inicialmente con un ajuste del 75% en los valores de las observaciones de tráfico utilizadas por el módulo LeastLoad_Analysis, y a continuación con el ajuste de un 95% en los valores de las observaciones utilizadas por el mismo módulo. Escenario: 75% de los valores considerados en los cálculos del módulo LeastLoad_Analysis : Figura 140. Ocupación Outbound de enlaces de salida (Alpha 25% - 75% valores procesados por LeastLoad_Analysis). Figura 141. Frecuencias de observaciones de ocupación enlaces de salida tráfico saliente (Alpha 25%). 63

90 Arquitectura de balanceo de carga dinámico para la lógica de conmutación EtherChannel Figura 142. Ocupación Inbound de enlaces de salida (Alpha 25% - 75% valores procesados por LeastLoad_Analysis). Figura 143. Frecuencias de observaciones de ocupación enlaces de salida tráfico entrante (Alpha 25%). Figura 144. Estadística Estado de Sistema para el Escenario de Simulación No. 5 con análisis de muestras al 75%. Figura 145. Retardo de Procesamiento Nodal (Alpha 25%). Figura 146. CDF Retardo de Procesamiento Nodal (Alpha 25%). Escenario: 95% de los valores considerados en los cálculos del módulo LeastLoad_Analysis Figura 147. Ocupación Outbound de enlaces de salida (Alpha 25% - 95% valores procesados por LeastLoad_Analysis). Figura 148. Frecuencias de observaciones de ocupación enlaces de salida tráfico saliente (Alpha 25%). 64

91 ANALISIS DE RESULTADOS Figura 149. Ocupación Inbound de enlaces de salida (Alpha 25% - 95% valores procesados por LeastLoad_Analysis). Figura 150. Frecuencias de observaciones de ocupación enlaces de salida tráfico entrante (Alpha 25%). Figura 151. CDF Retardo de Procesamiento Nodal (Alpha 25%). Al comparar la Figura 140 y la Figura 147, para la característica de ocupación del canal lógico con tráfico saliente, y la Figura 142 y la Figura 149, para la característica de ocupación del canal lógico con tráfico entrante, se identifica que Para el ajuste al 75%, el modelo reacciona de forma consistente a la sucesión de perturbaciones de tráfico (Figura 140 y Figura 142) y la Figura 144 evidencia la permanencia del Switch en modo Recuperación alcanzando la condición de balance y la ocupación del canal en estado estable en el largo término. Para el ajuste al 95%, el modelo, con una operación transitoria en modo Recuperación incitada por el ingreso de perturbaciones de tráfico, trata de acercar rápidamente las ocupaciones de todos los enlaces para alcanzar la condición de balance de forma temprana (Figura 147 y Figura 149). En el largo término, la implementación trata de sostener la condición de balance del canal lógico mientras se alcanza la ocupación del canal de estado estable, demostrando la eficiencia del modelo bajo este ajuste y revalidando el conjunto de modificaciones sugeridas en la sección

92 Arquitectura de balanceo de carga dinámico para la lógica de conmutación EtherChannel 5. CONCLUSIONES Con respecto a los objetivos propuestos para este proyecto de grado, se tienen inicialmente Simular un entorno de red basado en el modelado y verificación de desempeño del método de balanceo de carga estático de hashing de bits soportado en EtherChannel, en la herramienta de simulación OPNET Modeler 14.5 (1). Identificar y desarrollar una arquitectura de balanceo de carga sobre enlaces físicos basada en la filosofía dinámica Least Load (Menor Carga) que permita influenciar la decisión de balanceo sobre enlaces EtherChannel de forma autónoma y consistente (2). Simular un entorno de red basado en el modelado y verificación de desempeño de la arquitectura de balanceo de carga dinámica propuesta, en la herramienta de simulación OPNET Modeler 14.5 (3). De acuerdo con (2), se desarrolló una arquitectura totalmente modular para responder a los objetivos y necesidades del proyecto, la cual es presentada en la Figura 152. A partir de esta arquitectura, se efectúa la implementación de un modelo de nodo en la herramienta de simulación OPNET Modeler (Figura 24) con la parametrización requerida de manera que la implementación contara con la habilidad para presentar diferentes escenarios funcionales requeridos de acuerdo a los objetivos. Así, un único ajuste en el modelo de red, diseñado para ambientar la simulación del desempeño del modelo de la arquitectura propuesta, permite simular el método de asignación de carga de EtherChannel (Hashing de Bits) (1), así como la operación conjunta objeto de la arquitectura de conmutación propuesta (2-3). El núcleo de esta arquitectura (conjunto modular RRD_Algorithm, módulo LeastLoad_Analysis, módulo WeightsLoad_Settings junto a la serie de modificaciones ejecutadas durante los escenarios de simulación alternos) está desarrollado bajo una total adhesión a la filosofía LeastLoad al tratar de forma preferente los enlaces menos cargados con un mayor volumen de créditos de recuperación, de acuerdo al método de asignación de carga Round Robin Deficit. El diseño y funcionalidad de los módulos Collector posibilita la consideración de procedimientos de asignación de carga dinámicos que automatizan los modelos de compartición de carga equitativa en el grupo de enlaces del canal agregado. Figura 152. Diagrama de bloques de la arquitectura del nodo de conmutación propuesto La arquitectura propuesta presenta un alto grado de modularidad en su diseño lo cual ofrece flexibilidad para adicionar nuevas capacidades vía inserción de módulos, modificar la funcionalidad de subsistemas específicos existentes en respuesta a nuevas necesidades, así como optimizar la arquitectura. En adición, su diseño de interfaz y la documentación de soporte permiten su integración con otros modelos de nodo y su consideración en trabajos futuros. 66

93 CONCLUSIONES La consideración de un proceso de validación general de toda la arquitectura propuesta, para garantizar la operación global del modelo y un comportamiento cercano a expectativas de diseño, fue un aspecto de relevancia en la ejecución de este proyecto. Uno de los últimos aspectos del simulador que fueron asimilados durante la etapa de validación de la arquitectura, es el OPNET Simulation Debugger (ODB), que es una herramienta de simulación controlada en modo gráfico que permite verificar el flujo de paquetes y señalización en el modelo objeto de simulación. Sin el uso de este tipo de herramientas, es muy difícil garantizar la aproximación de un modelo a la expectativa funcional, incluso si un nodo o módulo específico está realizando correctamente los procedimientos para los cuales fue desarrollado. Como puede verificarse en los capítulos Desarrollos y Anexos, hay un uso extensivo de la herramienta ODB en el proceso de validación del modelo desagregado, para lo cual fueron desarrollados varios modelos de prueba que pretenden evidenciar y comparar la respuesta de un módulo específico frente a unas entradas conocidas con respecto a la expectativa funcional derivada de los objetivos de su programación. Con respecto a la simulación del método de asignación de carga de la tecnología EtherChannel (1), de acuerdo a expectativa, se evidencia que son notorios los efectos de desbalance sobre el canal agregado dadas las preferencias por ciertos índices de enlace que el método en mención puede tomar basado en la información de cabeceras de los paquetes. Bajo este método, se verifican enlaces que, bajo ciertas condiciones de tráfico y configuraciones de direccionamiento, pueden ser omitidos del proceso de asignación de carga. De acuerdo al capítulo Análisis de Resultados, se realizó la ejecución de unos escenarios de simulación alternos adicionales que consideran una serie de modificaciones con aspectos no contemplados en el diseño inicial del modelo propuesto, con respecto a resultados de simulaciones preliminares (3). Los resultados antes y después de modificación demuestran una habilidad mejorada del modelo de la arquitectura para tratar de restablecer el balance en el canal agregado. La modificación documentada asigna el máximo peso de recuperación para enlaces con ocupaciones cercanas a cero durante un ciclo de evaluación, y modela un comportamiento muestral más exclusivo por parte del módulo LeastLoad_Analysis para considerar cambios de estado. Los efectos son un comportamiento altamente reactivo al desbalance y la aparición temprana del efecto balanceador Round Robin Deficit en la ocupación de los enlaces (Figura 153 a Figura 156). Figura 153. Ocupación promedio de enlaces de salida para tráfico saliente Método de Asignación de Carga Hashing de Bits. Figura 154. Diagrama de Frecuencias de observaciones de ocupación Método de Asignación de Carga Hashing de Bits. Figura 155. Ocupación promedio de enlaces de salida para tráfico saliente, después de modificación, Método de Asignación de Carga Propuesto (alpha 25%). Figura 156. Diagrama de Frecuencias de observaciones de ocupación Método de Asignación de Carga Propuesto (alpha 25%). 67

94 Arquitectura de balanceo de carga dinámico para la lógica de conmutación EtherChannel Así mismo, la relativa baja variabilidad en el comportamiento del tráfico de ingreso al modelo llevó a la simulación de otro escenario alterno con perturbaciones de tráfico (Figura 122 a Figura 139). Aun así, el efecto balanceador aparece de forma temprana y el resultado en el largo término es una condición de balance generalizada con una mejor respuesta del sistema bajo la consideración de la media acotada de tráfico por interfaz física calculada dentro del rango intercuartil. Se supone mejor desempeño de esta configuración ante modelos de tráfico de ingreso con variaciones de corto término (ráfaga). Al revisar los resultados de la simulación en los diferentes escenarios propuestos, pueden verificarse tiempos prolongados de recuperación de la condición de balance estipulada para el modelo. Sin embargo, hay ya un buen escenario de balance relativo en el canal agregado mucho antes de alcanzar la condición mencionada, lo que propone un trabajo posterior para revaluar esa condición para operación óptima. Los resultados de la estadística Estado de Sistema muestran un constante ingreso del Switch en el modo Recuperación ya que se tiene una ventana de 30 segundos para verificar el canal lógico, y si el análisis resulta que aún no se alcanza la condición de balance, el Switch puede permanecer en ese estado por muchos ciclos de análisis. Este proceso recurrente disminuye el desempeño de la simulación, y se propondría para trabajos futuros la consideración de una ventana de recuperación variable automática basada en las condiciones de tráfico detectadas, de manera que minimice el número de conmutaciones del modo operacional del Switch y mejore el desempeño de la arquitectura propuesta. Uno de los resultados encontrados en la simulación del modelo de la arquitectura propuesta fue un Retardo de Procesamiento Nodal incrementado de hasta 75ms, con respecto a similar resultado para la simulación del modelo de conmutación de EtherChannel. Dos de los aspectos que quedaron bastante claros de esta experiencia y a su vez proponen una serie de desafíos de diseño, necesaria en este tipo de simulación, es la naturaleza DES de la herramienta OPNET, y el cuidado que debe tenerse con todos los procesos que intervienen en la Lista de Eventos de la simulación. Las primeras ejecuciones de la simulación del modelo mostraban tiempos de simulación excesivamente largos así como situaciones en las cuales en determinado momento se bloqueaba la simulación y el equipo de cómputo. Una verificación en el log de esas simulaciones mostró un crecimiento desmesurado en la utilización de la memoria RAM del equipo de cómputo. Sobre el particular, la lectura de la bibliografía, así como algunos consejos de estudiantes que ya se han enfrentado a la situación en mención, son concluyentes en dos aspectos que apuntan a una adecuada administración de la simulación DES: asegurar la destrucción de todo paquete o entidad de datos que ya haya cursado por el sistema de red, por medio de sumideros o procedimientos de Kernel; y el cuidado con los procesos iterativos que, por su objeto, producen mensajes de señalización o paquetes de datos. La implementación del algoritmo de Round Robin Deficit es uno de esos procesos que produce excesiva señalización cuando encuentra reiteradamente subcolas vacías. Durante ese proceso, esa señalización copa la Lista de Eventos y no permite que otros procesos la accedan para ingresar o retirar entidades de datos o interrupciones, lo que detiene el tiempo de simulación y dispara el consumo de memoria RAM. Así, una solución fue la consideración de un retardo en la atención de subcolas RRD consecutivas de 5ms, el cual da la oportunidad a que otros procesos accedan la Lista de Eventos y pueda avanzar el tiempo de simulación. Esta consideración mejoró de forma importante la evolución del tiempo de las simulaciones y la obtención de los resultados presentados en este documento. Sin embargo, en este modelo se verifica que hasta dos ciclos de Round Robin pueden requerirse para atender un paquete que accede al método y para un sistema de 8 subcolas, se evidenció que el retardo de procesamiento nodal está acotado a 80ms con un 95% de probabilidad de encontrar todo el retardo por debajo de 75ms, en contraste con el retardo de procesamiento nodal para el método de EtherChannel con retardos no superiores a 3.1ms. Por tanto, podría el lector llevarse una sensación incorrecta del desempeño de la arquitectura propuesta sobre este aspecto (poniendo en desventaja el modelo asociado), pero debe aclararse que en gran medida este retardo es necesario dada la necesidad de simular en un ambiente DES. Por tanto, esta situación no es un problema si parte de la labor de validación y simulación se efectúa en un sistema real con desagregación hardware de los procesos que conforman el sistema, así un conjunto de módulos que producen paquetes y señalización en un parte del sistema no debe afectar otra parte del mismo. Durante la búsqueda de referencias bibliográficas acerca de los conceptos y guía de usuario de desarrollo de modelos en OPNET Modeler, la mayor parte del trabajo encontrado en la Internet y bibliografía disponible aborda aspectos relacionados con análisis de desempeño y modelado de redes por medio de la 68

95 69 CONCLUSIONES aplicación OPNET Guru Academic Edition. Otros trabajos relacionados con el modelado de protocolos de red y nodos, por medio de la herramienta OPNET Modeler, permiten acceso a alguna información descriptiva de los modelos de red y de nodo, sin mayor detalle acerca de las interrelaciones entre módulos o procesos de diseño o construcción de modelos específicos. En adición, la compañía OPNET Inc, que tradicionalmente ofrecía buen soporte sobre sus aplicaciones, fue adquirida por Riverbed, la cual solo ofrece soporte a desarrolladores bajo contrato, y la documentación disponible con el aplicativo hace énfasis en los procedimientos de Kernel integrados mas no en ejercicios de modelado y modificación de modelos existentes. Estos aspectos dificultan el aprendizaje y asimilación de la herramienta. Sobre el particular, de manera alterna hay varios foros y comunidades en Google enfocados en la resolución de problemas encontrados en las diferentes etapas de los procesos de modelado y simulación. Sin embargo, muchas de las situaciones encontradas durante el diseño y desarrollo del modelo objeto de este proyecto de grado fueron superadas por medio de prueba y error, mucha inversión en sentido común y cotejando algunas conclusiones de la lectura de una u otra fuente relacionada. En este trabajo fueron de suma importancia los contenidos y aportes de las referencias bibliográficas [10], [11], [13] y [14], donde abordan una construcción conceptual progresiva y ejemplos de complejidad incremental que orientan adecuadamente acerca de cómo realizar tareas específicas acerca del proyecto propio. Uno de los aspectos de relevancia verificados en la herramienta OPNET Modeler es el soporte de simulación híbrida, la cual propone parte del trabajo de modelado en análisis matemático y otra parte en DES, el cual mejora de forma importante el desempeño de las simulaciones. Muchos de los cálculos matemáticos de relevancia en el modelado de la arquitectura propuesta fueron realizados en C++ sin la consideración de las herramientas suministradas por OPNET, que, aunque de enfoque similar, consumen recursos que finalmente afectan la ejecución de la simulación. Ciertamente es muy importante la experiencia previa en programación y el dominio de algún lenguaje próximo en sintaxis y semántica a Proto-C, como PERL en mi caso, que permita la explotación de las prestaciones de la simulación híbrida. Dada la orientación de la herramienta OPNET, cada nodo, estructura o módulo en el sistema es modelado como un objeto, y las fuentes en mención dan cuenta de la susceptibilidad de estos objetos de ser instanciados y utilizados en muchas partes de un modelo de red o nodo con comportamientos distintos de acuerdo a parametrización. Así, un desarrollador podría instanciar un módulo completo del cual no dispone (que hace parte de un modelo de nodo diferente) y que responde funcionalmente a una necesidad de su proyecto, e instalarlo en otro modelo de nodo realizando las conexiones necesarias del módulo en mención (Packet Streams, Statistics Wires) y debe funcionar! Aparentemente este no es el caso y una situación similar impidió la integración de la capa MAC de Ethernet en las interfaces de los nodos de conmutación propuestos, con el resultado de no poder considerar medios del tipo Ethernet así como prescindir de la utilización de las herramientas de simulación de tráfico de red (Application Servers, Application Configs, Application Profiles) disponibles en el modelo de red en OPNET Modeler, ya que estas características son disponibles desde nodos servidor y estaciones de trabajo Ethernet. Por esta razón, la estrategía de modelado se amplió al diseño y depuración de estaciones de trabajo, generadores de tráfico y medios de comunicaciones, que en conjunto posibilitaran una infraestructura y tráfico para validar el modelo de la arquitectura propuesta de conmutación. No hay mayor documentación OPNET sobre la integración de esta tecnología de red en modelos de nodos. Por tanto, se espera que trabajos futuros puedan ahondar sobre el particular, con un enfoque distinto (tomando un modelo de nodo predefinido OPNET con soporte Ethernet ya existente y modificando sus capas superiores, con el objeto de integrar la metodología de conmutación propuesta). Este desarrollo es de suma importancia para una validación más decisiva de la parametrización alpha de la arquitectura, ya que podrá someterse el modelo a comportamientos de protocolo prestablecidos en OPNET que por naturaleza contemplan tráfico en ráfagas y podrá verificarse con mayor eficacia la validez de la media muestral acotada de rango intercuartil como configuración aceptada y óptima para un rápido restablecimiento de la condición de balance del canal agregado. En adición, la consideración de medios y métodos Ethernet en la arquitectura serán necesarios para un mayor acercamiento del modelo propuesto a la operación de una implementación real en capa 2. A partir de la realización de la serie de trabajos propuestos, a futuro se propondrá un proyecto de prototipado de la arquitectura revisada en un ambiente hardware basado en NetFPGAs e infraestructura de conmutación Cisco de manera que puedan verificarse sus características funcionales y de compatiblidad

96 Arquitectura de balanceo de carga dinámico para la lógica de conmutación EtherChannel así como el nivel de desempeño en un escenario que involucre tráfico real, aplicaciones de alto uso de ancho de banda y en tiempo real, y conexiones del tipo GigabitEthernet y 10GigabitEthernet. Con respecto al cumplimiento del siguiente objetivo propuesto: Verificar el desempeño del método de balanceo de carga y de la arquitectura propuesta en general frente a variaciones discretas de α como parámetro de la medición de tendencia central de ocupación de enlaces físicos EtherChannel y probar la validez de la Media de Rango InterCuartil. Se generaron tres escenarios de simulación con parametrizaciones alpha α 5%, 15% y 25% para condiciones de tráfico similares, encontrando que el mejor comportamiento lo exhibe la consideración de la media acotada de rango intercuartil (25%) (Figura 155 y Figura 156) en las mediciones y cálculos por parte de los módulos Collector, puesto que suprime suficientes aberrantes de tráfico y comportamiento en ráfagas que eventualmente podrían llevar a la arquitectura modelada a tomar decisiones de restablecimiento de balance innecesarias. Las aseveraciones realizadas sobre el particular se derivan del comportamiento muestral de las observaciones de la variable Ocupación y las características gráficas de ocupación de los enlaces del canal agregado antes y después de las modificaciones sugeridas en los tres escenarios del parámetro alpha. Sin embargo, como se mencionó con anterioridad, los trabajos futurossugeridos donde se pueda someter el modelo a tráfico prestablecido en OPNET en esas condiciones permitirán evidenciar más fuertemente este aspecto. Con respecto al cumplimiento del último objetivo propuesto:determinar la validez de la arquitectura de conmutación propuesta frente al método tradicional de balanceo soportado en EtherChannel a partir de la comparación entre aspectos específicos de desempeño derivados de la simulación. El Plan de Simulaciones del Proyecto es el marco de comparación seleccionado para confrontar aspectos operacionales y de desempeño de interés entre el método de asignación parte de la especificación EtherChannel y los métodos propuestos en este trabajo de grado. Se han analizado y cotejado aspectos como Ocupación Promedio del Grupo de Enlaces, Distribución Estadística de las Observaciones de Ocupación, Retardo de Procesamiento Nodal, Distribución de Probabilidad Acumulativa (CDFs) del Retardo. La estadística Estado de Sistema no es objeto de confrontación ya que hace parte exclusiva de la arquitectura propuesta. Se puede concluir que la arquitectura propuesta presenta una metodología de administración de enlaces agregados con un mejor uso de la infraestructura desvinculando la asignación de carga de la información del tráfico de ingreso que intenta cursar por los nodos de conmutación. Presenta un comportamiento ágil y proactivo para identificar y tratar de restablecer las condiciones de balance. Se determina que la arquitectura propuesta podría soportar servicios transaccionales y en tiempo real dentro de la infraestructura de red al interior de una compañía o proveedor de servicios. Seguramente el retiro del retardo inducido en el modelo y la consideración de un ambiente de simulación con conectividad nacional e internacional en un trabajo posterior mostrará la validez de la arquitectura propuesta para soportar esos servicios en redes WAN y de transporte de datos. Así, la expectativa sobre los resultados de los trabajossugeridos y la adopción de la arquitectura de conmutación propuesta en plataformas hardware comerciales podrían resultar en una tecnología de gran interéspor los proveedores de servicio dados los beneficios directos derivados del despliegue de infraestructura de conmutación agregada de este tipo, por el manejo óptimo de capex, los ahorros en ancho de banda de interconexión, así como la automatización en la gestión de tráfico y la consecuente mejora en la calidad de servicio para los clientes que cursan sus flujos por esta infraestructura, que a su vez aumenta el retorno de inversión por ahorros dado el mayor cumplimiento de SLAs de cliente. Para finalizar, se considera exitosa la alineación que tuvo la ejecución del proyecto con respecto a la metodología planteada en el anteproyecto. Fue fundamental un claro entendimiento del problema y las expectativas de diseño que decidieron el horizonte y factibilidad de los objetivos, así como la selección de una arquitectura candidata objeto de desarrollo e implementación. Así mismo, se considera de suma importancia el proceso de selección de la herramienta de simulación y la consideración de una etapa de acercamiento a la herramienta, de manera que pudo evidenciarse la efectividad de la selección y la mejor explotación posible de sus características (simulación híbrida). En adición, su utilización a lo largo del proyecto no conllevó a conclusiones posteriores relacionadas con incapacidad de la herramienta paraposibilitar el cumplimiento con los objetivos de diseño propuestos. 70

97 BIBLIOGRAFÍA 6. BIBLIOGRAFÍA [1] Ethernet speeds in 2013: not a matter of 400G or 1TB, but cheaper 100G. Recuperado en [2]Law, D.J., Diab, W.W., Healey, A., Carlson, S.B., Maguire, V.(2012). IEEE Industry Connections Ethernet Bandwidth Assessment. Recuperado en [3] Muller, S., Bechtolsheim, A., Hendel, A. (2007).HSSG Speeds and Feeds - Reality Check. Recuperado en [4] Armitage, G. (2000). Quality of service in IP networks: Foundations for a multi-service Internet. Indianapolis, EUA: Macmillan Technical Publishing. [5] Mahmood, B.(2009). Developing the design of the Etherchannel switch for the enhancement of the Quality of Service (QoS) performance.college of electronics engineering.university of Mosul.Al- Rafidain Engineering, 3 (17). [6] Cisco Systems and HP fast etherchannel and auto-port aggregation software. Recuperado enhttp:// [7] Hucaby, D. (2010). CCNP SWITCH Official Certification Guide. Pearson Education, Inc. [8] Understanding EtherChannel Load Balancing and Redundancy on Catalyst Switches. Documento ID: Recuperado el 10 de Enero de 2013 en [9] Li, W., Wang, Y., y Hong, Z.(2012). Simulation and Performance Analysis of Load Balancing Algorithms Using OPNET.School of Computer and Communication.University of China.16TH INTERNATIONAL CONFERENCE ON MECHATRONICS TECHNOLOGY. [10] Lu, Z., Yang, H. (2012). Unlocking the Power of OPNET Modeler. New York, United States of America: Cambridge University Press. [11] (2004). OPNET: Manual de Usuario. Departamentd EnginyeriaTelemàtica, Secciód EnginyeriaTelemàtica de l EPSEVG. Recuperado en [12] Nicolás, L. Control de Congestión con OPNET. E.T.S DE INGENIERÍA INFORMÁTICA. Universidad de Valladolid. [13] Sethi, A.S., Hnatyshin, V.Y. (2013). The Practical OPNET User Guide for Computer Network Simulation. Boca Raton, United States of America: Taylor & Francis Group. [14] (2004). OPNET LAB MANUAL. Training Manual for: Introduction to Modeler. Software Release: 11.0.A PL3. Manual Version: 3. 71

98 Arquitectura de balanceo de carga dinámico para la lógica de conmutación EtherChannel 7. ANEXOS Anexo A: PROCESO DE VALIDACIÓN DEL MÓDULO SM_REQS_QUEUE Se prepara el siguiente modelo de nodo para operaciones de validación del módulo SM_Reqs_Queue (Figura 1) en cual se considera la ampliación del escenario de validación del módulo LeastLoad_Analysis con el módulo SM_Reqs_Queue de manera que pueda producirse adecuadamente la señalización de entrada del módulo objeto de validación. En la misma figura se presenta un primer paquete de entrada con ID No. 2 cuyos contenidos se pueden verificar en la Figura 2. Figura 1. Escenario de Validación del módulo SM_Reqs_Queue. Figura 2. Contenido del paquete ID 2. El sumidero A simula la aceptación de paquetes de señalización por parte del módulo SM_Ctrl_Switch y el sumidero B simula la aceptación de paquetes de señalización por parte del módulo SwitchFabric_Processor. Como resultado de la operación del módulo SM_Reqs_Queue (Figura 3) se producen dos paquetes de señalización cuyos contenidos pueden verificarse en la Figura 4 y la Figura 5, respondiendo correctamente a la señalización planificada en la Figura 6. Figura 3. Generación de paquetes de señalización por parte del módulo SM_Reqs_Queue. 72

99 ANEXOS Figura 4. Contenido del paquete ID 4. Figura 5. Contenido del paquete ID 3. Figura 6. Señalización considerada en el modelo de nodo de la arquitectura propuesta. Como resultado de la operación del módulo SM_Reqs_Queue ante el estímulo con ID 67 (Figura 8) se producen dos paquetes de señalización (Figura 9) cuyos contenidos pueden verificarse en la Figura 10 y la Figura 11, respondiendo correctamente a la señalización planificada en la Figura 6. Figura 7. Escenario de Validación del módulo SM_Reqs_Queue. Figura 8. Contenido del paquete ID

100 Arquitectura de balanceo de carga dinámico para la lógica de conmutación EtherChannel Figura 9. Generación de paquetes de señalización por parte del módulo SM_Reqs_Queue. Figura 10. Contenido del paquete ID 68. Figura 11. Contenido del paquete ID

101 ANEXOS Anexo B: PROCESO DE VALIDACIÓN DEL MÓDULO SWFABRIC_PROCESSOR A partir del escenario de validación de la implementación del algoritmo de asignación de carga del método EtherChannel (Hashing de Bits), descrito en la Figura 1, se amplía ese ambiente de validación para verificar la asignación de paquetes a medios de salida por parte del módulo SWFabric_Processor. Figura 1. Modelo de Red para validación del modelado del algoritmo de asignación de carga de EtherChannel. A partir del ambiente de validación del método de asignación de carga de EtherChannel, se ha configurado la operación del algoritmo a 2 >ip-src-dst. El nodo PC_4 produce paquetes con dirección IP origen e IP destino , lo cual debe producir un paquete contexto ICI anexo con campo ici_id igual a 5. Así el módulo SWFabric_Processor producirá la conmutación del paquete hacia el enlace con índice 5. Figura 2. Paquete ID 3 sin contexto ingresando al módulo EtherChannel_HA_Algorithm. 75

102 Arquitectura de balanceo de carga dinámico para la lógica de conmutación EtherChannel Figura 3. Paquete ID 3 con contexto ICI ingresando al módulo SWFabric_Processor. Figura 4. Paquete ID 3 sin contexto ICI asignado a la interfaz de salida 5. 76

103 ANEXOS Anexo C: PROCESO DE VALIDACIÓN DEL MÓDULO STATISTICS_POLLER Para fines de validación, se modela el siguiente escenario, en el cual el módulo Pruebas está generando paquetes PollerFrame en dos ciclos, simulando las muestras de tráfico desde los ocho módulos Collector. Figura 1. Escenario de Validación OPNET para el módulo StatisticsPoller. La Figura 2, Figura 3, Figura 4, Figura 5, Figura 6, y Figura 7 describen el proceso de validación. Figura 2. Ciclo 1 > Se producen los mensajes PollerFrame para las interfaces 1, 3, 5, 7. Figura 3. Contenido del mensaje PollerFrame ID 0. 77

104 Arquitectura de balanceo de carga dinámico para la lógica de conmutación EtherChannel Figura 4. Ciclo 2 > Se producen los mensajes PollerFrame para las interfaces 0, 2, 4, 6. Figura 5. Contenido del mensaje PollerFrame ID 7. Figura 6. El módulo StatisticsPoller produce mensajes vector MeanVector consolidados. Figura 7. Contenido del mensaje MeanVector ID 8. 78

105 ANEXOS Anexo D: PROCESO DE VALIDACIÓN DEL MÓDULO WEIGHTSLOAD _ SETTINGS Se ha preparado el siguiente escenario de validación basado en el escenario de validación del módulo StatisticsPoller descrito en el anexo anterior. Figura 1. Escenario de Validación OPNET para el módulo WeightsLoad_Settings. Se ha calculado previamente en Excel el vector de créditos de restablecimiento a partir de dos vectores con muestras de tráfico del grupo de interfaces (Figura 2, Figura 3), para los casos en los cuales las condiciones de tráfico llevarían al modelo a conmutar el estado operacional del Switch a modo Recuperación : Figura 2. Créditos de Restablecimiento Recovery Credits para las muestras acotadas de tráfico del grupo de interfaces (Caso 1). 79

106 Arquitectura de balanceo de carga dinámico para la lógica de conmutación EtherChannel Figura 3. Créditos de Restablecimiento Recovery Credits para las muestras acotadas de tráfico del grupo de interfaces (Caso 2). A continuación, se presentan los resultados de la simulación controlada en OPNET en modo gráfico, detallando la secuencia de las operaciones, el flujo de paquetes y los contenidos de los mensajes relevantes para fines de validación. Figura 4. Ciclo 1 > Se producen los mensajes PollerFrame para las interfaces 0, 2, 4, 6. Figura 5. Ciclo 2 > Se producen los mensajes PollerFrame para las interfaces 1, 3, 5, 7. Figura 6. El módulo StatisticsPoller produce mensajes vector MeanVector consolidados. Con respecto al primer caso detallado en la Figura 2, se presentan los contenidos del primer vector consolidado de muestras. Figura 7. Contenido del mensaje MeanVector ID 8. 80

107 ANEXOS El módulo WeightsLoad_Settings efectúa el cálculo de los créditos de restablecimiento y envía un mensaje consolidado con esos créditos a las subcolas del algoritmo RRD. Figura 8. El módulo WeightsLoad_Settings produce mensajes consolidados con el vector de créditos de restablecimiento hacia las subcolas RRD. Cada una aceptará un valor del vector con referencia a su ID de subcola. Figura 9. Contenido del mensaje consolidado de créditos ID 14. La columna Recovery Credits puede verificarse contra los cálculos Excel de la Figura 10. Figura 10. Créditos de Restablecimiento Recovery Credits para las muestras acotadas de tráfico del grupo de interfaces (Caso 1). Con respecto al segundo caso detallado en la Figura 3, se presenta tanto la salida del módulo StatisticsPoller como los contenidos del segundo vector consolidado de muestras. Figura 11. El módulo StatisticsPoller produce mensajes vector MeanVector consolidados. 81

108 Arquitectura de balanceo de carga dinámico para la lógica de conmutación EtherChannel Figura 12. Contenido del mensaje MeanVector ID 9. Figura 13. El módulo WeightsLoad_Settings produce mensajes consolidados con el vector de créditos de restablecimiento hacia las subcolas RRD. Cada una aceptará un valor del vector con referencia a su ID de subcola. Figura 14. Contenido del mensaje consolidado de créditos ID 14. La columna Recovery Credits puede verificarse contra los cálculos Excel de la Figura 15. Figura 15. Créditos de Restablecimiento Recovery Credits para las muestras acotadas de tráfico del grupo de interfaces (Caso 2). 82

109 ANEXOS Anexo E: PROCESO DE VALIDACIÓN DE MÓDULOS SM_CTRL_SWITCH - ROUNDROBIN SCHEDULER - CONJUNTO ROUNDROBIN DEFICIT En la Figura 1 y Figura 2 se presentan los modelos de red y nodo que conforman el escenario de validación para la operación de los módulos SM_Ctrl_Switch, RoundRobin Scheduler y Conjunto RoundRobin Deficit. Figura 1. Modelo de Red OPNET para el escenario de validación. Figura 2. Modelo de Nodo OPNET RoundRobin_Validation para el escenario de validación. De acuerdo al modelo de nodo de la Figura 2, el módulo WeightsLoad_Simulated envía alternadamente señalización para acceso a los modos Normal y Recuperación a intervalos de 1 segundo. Adicionalmente produce el siguiente vector de créditos de recuperación que han ser cargados consistentemente en cada uno de los módulos de subcola del conjunto Round Robin Deficit: Q_0 : 1000 Q_1 : 500 Q_2 : 250 Q_3 : 125 Q_4 : 1000 Q_5 : 500 Q_6 : 250 Q_7 :

110 Arquitectura de balanceo de carga dinámico para la lógica de conmutación EtherChannel Los paquetes producidos desde el nodo PC_4 tienen una carga continua de 1000 bytes, de manera que si las subcolas tienen por lo menos 1 de esos paquetes Q_0 : 1000 > Paquete despachado en ciclo RR No.1 Q_1 : 500 > Paquete despachado en ciclo RR No.2 Q_2 : 250 > Paquete despachado en ciclo RR No.4 Q_3 : 125 > Paquete despachado en ciclo RR No.8 Q_4 : 1000 > Paquete despachado en ciclo RR No.1 Q_5 : 500 > Paquete despachado en ciclo RR No.2 Q_6 : 250 > Paquete despachado en ciclo RR No.4 Q_7 : 125 > Paquete despachado en ciclo RR No.8 Respecto al escenario de validación, la conmutación del Switch por defecto es hacia el método EtherChannel Hashing Bits, lo cual se verifica en la Figura 3 y la Figura 4. Figura 3. Operación por defecto del módulo SM_Ctrl_Switch. Figura 4. Operación por defecto del módulo SM_Ctrl_Switch. Cuando la simulación registra un segundo de operación el módulo WeightsLoad_Simulated produce señalización para conmutar el módulo SM_Ctrl_Switch al modo Recuperación (Paquete ID 34 Figura 6) y un vector de créditos de recuperación hacia el conjunto de subcolas (Figura 7), de acuerdo a estimación. Figura 5. Interrupción a 1 segundo Tiempo de Simulación. 84

111 ANEXOS Figura 6. Visualización de la generación de señalización por parte del módulo WeightsLoad_Simulated. Figura 7. Contenido del paquete ID 33 con créditos de restablecimiento hacia una de las subcolas. A partir de este punto, el módulo SM_Ctrl_Switch envía paquetes de usuario hacia el módulo RoundRobin Scheduler para fines de encolamiento en el conjunto de subcolas durante un periodo de 250ms; terminado este periodo el módulo SM_Ctrl_Switch señaliza la subcola q_7 para iniciar el recorrido Round Robin por el conjunto de subcolas. Figura 8. Operación en modo Recuperación del módulo SM_Ctrl_Switch. Figura 9. Operación en modo Recuperación del módulo SM_Ctrl_Switch. 85

112 Arquitectura de balanceo de carga dinámico para la lógica de conmutación EtherChannel Iniciado el ciclo de mensajes de recorrido RoundRobin, pueden verificarse ya estos mensajes sobre la simulación gráfica saliendo de una cola e ingresando en la siguiente. Por ejemplo, el primer mensaje de señalización Round Robin es el paquete No. 45: Figura 10. Contenidos del mensaje de señalización ID 45. El atributo Selector = 1 denota operación Recuperación y Ciclo Round Robin Normal. Respecto a la Figura 11, el paquete de datos ID 40 (con carga 1000 bytes) se encoló en la subcola q_0; por la cantidad de créditos de restablecimiento de esa subcola se despachó en el primer ciclo, de antemano contextualizado con el atributo ici_id = 0. Figura 11. Despacho del paquete de datos de usuario ID 40 durante el primer ciclo RoundRobin. Figura 12. Despacho del paquete de datos de usuario ID 40 durante el primer ciclo RoundRobin. De aquí en adelante la señalización RoundRobin, similar a la del mensaje No. 45, fluirá recorriendo el sistema de subcolas, como puede verificarse en la Figura 13, la Figura 14 y la Figura 15. Figura 13. Mensajes de ciclo RoundRobin recorriendo el sistema de subcolas. 86

113 ANEXOS Figura 14. Mensajes de ciclo RoundRobin recorriendo el sistema de subcolas. Figura 15. Mensajes de ciclo RoundRobin recorriendo el sistema de subcolas. A los dos segundos de tiempo de simulación, el módulo WeightsLoad_Simulated produce señalización (mensaje ID 188) para regresar el Switch al modo Normal. Figura 16. Mensaje producido por el módulo WeightsLoad_Simulated para inducir en el módulo SM_Ctrl_Switch un cambio de modo operacional hacia Modo Normal. Figura 17. Contenidos del mensaje de señalización ID 188. De inmediato, el módulo SM_Ctrl_Switch produce señalización hacia la subcola q_7 para producir un último ciclo Round Robin con señalización interna de proceso (que induce un vaciado de las subcolas) así como para detener el recorrido RoundRobin al finalizar el ciclo en mención. 87

114 Arquitectura de balanceo de carga dinámico para la lógica de conmutación EtherChannel Figura 18. Ultimo ciclo RoundRobin para dar paso al reingreso del Switch en Modo Normal. Figura 19. Contenidos del mensaje de señalización ID 194 de finalización de rutina RoundRobin. Terminado el último ciclo RoundRobin, el módulo SM_Ctrl_Switch conmuta hacia el método EtherChannel para operación en modo Normal. Figura 20. Reingreso del modelo de Switch a modo de operación Normal. De acuerdo a la gráfica anterior, el paquete de datos ID. 205 ya está siendo conmutado hacia el módulo EtherChannel Hashing Algorithm. 88

115 ANEXOS Anexo F: PROCESO DE VALIDACIÓN DEL MÓDULO COLLECTOR Se prepara el siguiente escenario de validación, en el cual temporalmente se están realizando impresiones vía procedimiento de Kernel op_sim_message, de manera que puedan analizarse los valores de las observaciones, la media muestral acotada calculada por el módulo Collector para cierto valor de alpha y así poder comparar esos resultados contra un análisis en Excel previo. Figura 1. Modelo de Red OPNET para el escenario de validación. Figura 2. Modelo de Nodo OPNET para el escenario de validación. 89

116 Arquitectura de balanceo de carga dinámico para la lógica de conmutación EtherChannel Figura 3. Parametrización del nodo Collector_Validation para operación exclusiva del módulo EtherChannel, verificación src_ip del algoritmo EtherChannel y parámetro Alpha 25%. Con respecto a la Figura 1 y la Figura 2, los valores de las direcciones IP parametrizadas en los nodos generadores de tráfico PC_4 y PC_5 y la operación del método de hashing de bits de EtherChannel están calculados de manera que el tráfico de paquetes outbound ha de ser desviado al collector Sampler_P1. De la simulación controlada se obtienen los siguientes mensajes con información de las observaciones de tráfico y media muestral calculada por la aplicación: Module (649), (top.collector_validation.sampler_p1) From procedure: traffic_collector [bytes_sec enter execs] Sample S1 (number): Module (649), (top.collector_validation.sampler_p1) From procedure: traffic_collector [bytes_sec enter execs] Sample S2 (number): Module (649), (top.collector_validation.sampler_p1) From procedure: traffic_collector [bytes_sec enter execs] Sample S3 (number): Module (649), (top.collector_validation.sampler_p1) From procedure: traffic_collector [bytes_sec enter execs] Sample S4 (number): Module (649), (top.collector_validation.sampler_p1) From procedure: traffic_collector [bytes_sec enter execs] Sample S5 (number): Module (649), (top.collector_validation.sampler_p1) From procedure: traffic_collector [bytes_sec enter execs] Sample S6 (number): Module (649), (top.collector_validation.sampler_p1) From procedure: traffic_collector [bytes_sec enter execs] Sample S7 (number): Module (649), (top.collector_validation.sampler_p1) From procedure: traffic_collector [bytes_sec enter execs] Sample S8 (number): Module (649), (top.collector_validation.sampler_p1) From procedure: traffic_collector [bytes_sec enter execs] Sample S9 (number): Module (649), (top.collector_validation.sampler_p1) From procedure: traffic_collector [bytes_sec enter execs] Sample S10 (number): Module (649), (top.collector_validation.sampler_p1) From procedure: traffic_collector [bytes_sec enter execs] Sample S11 (number):

117 ANEXOS Module (649), (top.collector_validation.sampler_p1) From procedure: traffic_collector [bytes_sec enter execs] Sample S12 (number): Module (649), (top.collector_validation.sampler_p1) From procedure: traffic_collector [bytes_sec enter execs] Sample S13 (number): Module (649), (top.collector_validation.sampler_p1) From procedure: traffic_collector [bytes_sec enter execs] Sample S14 (number): Module (649), (top.collector_validation.sampler_p1) From procedure: traffic_collector [bytes_sec enter execs] Sample S15 (number): Module (649), (top.collector_validation.sampler_p1) From procedure: traffic_collector [bytes_sec enter execs] Sample S16 (number): Module (649), (top.collector_validation.sampler_p1) From procedure: traffic_collector [bytes_sec enter execs] Sample S17 (number): Module (649), (top.collector_validation.sampler_p1) From procedure: traffic_collector [bytes_sec enter execs] Sample S18 (number): Module (649), (top.collector_validation.sampler_p1) From procedure: traffic_collector [bytes_sec enter execs] Sample S19 (number): Module (649), (top.collector_validation.sampler_p1) From procedure: traffic_collector [bytes_sec enter execs] Sample S20 (number): Module (649), (top.collector_validation.sampler_p1) From procedure: traffic_collector [bytes_sec enter execs] Sample S21 (number): Module (649), (top.collector_validation.sampler_p1) From procedure: traffic_collector [bytes_sec enter execs] Sample S22 (number): Module (649), (top.collector_validation.sampler_p1) From procedure: traffic_collector [bytes_sec enter execs] Sample S23 (number): Module (649), (top.collector_validation.sampler_p1) From procedure: traffic_collector [bytes_sec enter execs] Sample S24 (number): Module (649), (top.collector_validation.sampler_p1) From procedure: traffic_collector [bytes_sec enter execs] Sample S25 (number): Module (649), (top.collector_validation.sampler_p1) From procedure: traffic_collector [bytes_sec enter execs] Sample S26 (number): Module (649), (top.collector_validation.sampler_p1) From procedure: traffic_collector [bytes_sec enter execs] Sample S27 (number): Module (649), (top.collector_validation.sampler_p1) From procedure: traffic_collector [bytes_sec enter execs] Sample S28 (number): Module (649), (top.collector_validation.sampler_p1) From procedure: traffic_collector [bytes_sec enter execs] Sample S29 (number): Module (649), (top.collector_validation.sampler_p1) From procedure: traffic_collector [bytes_sec enter execs] Sample S30 (number): Module (649), (top.collector_validation.sampler_p1) From procedure: traffic_collector [bytes_sample enter execs] Information: AtributeRecovered > Sampler_P1.alpha Module (649), (top.collector_validation.sampler_p1) From procedure: traffic_collector [bytes_sample enter execs] Muestra Collector 1 (number): En la siguiente figura se presenta el procesamiento de las observaciones de la muestra anterior en Excel y se confirma el valor de la medida acotada de tendencia central calculada por el módulo: 91

118 Arquitectura de balanceo de carga dinámico para la lógica de conmutación EtherChannel Figura 4. Análisis en Excel de la muestra de 30 observaciones de carga del enlace con índice 1 y determinación teórica de la medida acotada de tendencia central para Alpha 25%. Se verifica el paquete PollerFrame producido por el módulo Collector : Figura 5. Paquete PollerFrame con ID 1292 producido por el módulo Collector con información de la medida acotada de tendencia central para una muestra de 30 observaciones de carga de tráfico sobre interfaz con índice 1. Figura 6. Contenidos del paquete PollerFrame con ID El valor cargado en el Payload del paquete (29282 bytes) se confirma de acuerdo a los resultados de la Figura 4. Se repite la simulación controlada, ahora con un parámetro alpha del 15%: 92

119 ANEXOS Figura 7. Parametrización del nodo Collector_Validation para operación exclusiva del módulo EtherChannel, verificación src_ip del algoritmo EtherChannel y parámetro Alpha 15%. Figura 8. Análisis en Excel de la muestra de 30 observaciones de carga del enlace con índice 1 y determinación teórica de la medida acotada de tendencia central para Alpha 15%. Nótese la coincidencia exacta de la media calculada en Excel y el valor suministrado por la simulación. 93