Upload
others
View
4
Download
0
Embed Size (px)
Citation preview
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
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
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.
NOTA DE ACEPTACIÓN
______________________________________________________
______________________________________________________
______________________________________________________
_____________________________________________
Director del proyecto
________________________________________
Jurado
________________________________________
Jurado
NOVIEMBRE DE 2013
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.
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.
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 ..................................................................................................................... 8
1.MARCO TEÓRICO .................................................................................................................................... 9
1.1 TECNOLOGÍA DE CONMUTACIÓN ETHERCHANNEL ........................................................ 9
1.2 CONCEPTOS SOBRE SIMULACIÓN .......................................................................................11
1.2.1 MODELADO DE RED E INTRODUCCIÓN A LA SIMULACIÓN .................................11
1.2.2 CLASIFICACIÓN DE LOS SIMULADORES ...................................................................13
1.3 INTRODUCCIÓN AL SIMULADOR OPNET ...........................................................................14
1.3.1 SUITE DE APLICACIONES OPNET .................................................................................14
1.3.2 OPNET MODELER .............................................................................................................15
2.ESPECIFICACIONES .............................................................................................................................. 18
2.1 PRESENTACIÓN DE ARQUITECTURA PROPUESTA ..........................................................18
2.2 ESPECIFICACIÓN OPERATIVA DE LA ARQUITECTURA .................................................19
2.3 ESPECIFICACIÓN MODULAR DE LA ARQUITECTURA ....................................................20
2.3.1 Módulo SWFabric_Processor...............................................................................................20
2.3.2 Módulo StatisticsPoller ........................................................................................................21
2.3.3 Módulo LeastLoad_Analysis ...............................................................................................22
Arquitectura de balanceo de carga dinámico para la lógica de conmutación EtherChannel
2.3.4 Módulo SM_Reqs_Queue ....................................................................................................23
2.3.5 Módulo EtherChannel_HA_Algorithm ................................................................................24
2.3.6 Módulo WeightsLoad_Settings ............................................................................................25
2.3.7 Módulos Collector ................................................................................................................26
2.3.8 Conjunto de Módulos SM_Ctrl_Switch – RoundRobin Scheduler – RoundRobin Deficit .28
3.DESARROLLOS ...................................................................................................................................... 32
3.1 IMPLEMENTACIÓN DE NODO DE CONMUTACIÓN EN OPNET MODELER .................32
3.2 VALIDACIÓN DEL MODELO DE NODO EN OPNET ...........................................................34
3.2.1 Módulo LeastLoad_Analysis ...............................................................................................35
3.2.2 Módulo SM_Reqs_Queue ....................................................................................................38
3.2.3 Módulo EtherChannel_HA_Algorithm ................................................................................38
3.2.4 Módulo SWFabric_Processor...............................................................................................41
3.2.5 Módulo StatisticsPoller ........................................................................................................42
3.2.6 Módulo WeightsLoad_Settings ............................................................................................42
3.2.7 Módulos SM_Ctrl_Switch – RoundRobin Scheduler – RoundRobin Deficit ......................42
3.2.8 Módulos Collector ................................................................................................................44
3.2.9 Estadísticas programadas .....................................................................................................45
4.ANALISIS DE RESULTADOS ............................................................................................................... 46
4.1 PLAN DE SIMULACIONES DEL PROYECTO ........................................................................46
4.1.1 Modelo de Tráfico de Entrada ..............................................................................................46
4.1.2 Definición de Estadísticas y Parametrización del Modelo de Red .......................................47
4.2 EJECUCIÓN DE PLAN DE SIMULACIONES – ANÁLISIS DE RESULTADOS ..................49
4.2.1 Análisis de resultados Simulación No. 1 (Método Hashing de Bits > src-ip) ......................49
4.2.2 Análisis de resultados Simulación No. 1 (Método Hashing de Bits > dst-ip) ......................50
4.2.3 Análisis de resultados Simulación No. 1 (Método Hashing de Bits > src-dst-ip) ................51
4.2.4 Análisis de resultados Simulación No. 2 ..............................................................................53
4.2.5 Análisis de resultados Simulación No. 3 ..............................................................................56
4.2.6 Análisis de resultados Simulación No. 4 ..............................................................................59
4.2.7 Análisis de resultados Simulación No. 5 ..............................................................................63
CONTENIDO
5.CONCLUSIONES .................................................................................................................................... 66
6.BIBLIOGRAFÍA ....................................................................................................................................... 71
7.ANEXOS................................................................................................................................................... 72
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
LISTA DE FIGURAS
LISTA DE FIGURAS
Figura 1. Proyecciones de demanda de ancho de banda del IEEE 802.3 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:.......................................................... 13
Figura 12. Diagrama de Flujo de la Simulación basada en Eventos Discretos: ......................................... 14
Figura 13. Editor de Proyectos de OPNET Modeler: ................................................................................. 16
Figura 14. Editor de Nodos de OPNET Modeler: ...................................................................................... 16
Figura 15. Editor de Procesos de OPNET Modeler: .................................................................................. 16
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: ....................................................... 18
Figura 17. Arquitectura propuesta operando en Modo Normal: ................................................................ 19
Figura 18. Arquitectura propuesta operando en Modo Recuperación: ....................................................... 20
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: .............................................. 20
Figura 20. Topología estrella entre los módulos “Collector” y el módulo “StatisticsPoller”: ................... 21
Figura 21. Señalización considerada en el modelo de nodo de la arquitectura propuesta: ........................ 24
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: ................................................ 28
Figura 23. Diagrama de bloques del módulo “SM_Ctrl_Switch”: ............................................................. 28
Figura 24. Modelo de nodo diseñado en OPNET Modeler para la arquitectura propuesta del nodo de
conmutación: .............................................................................................................................................. 32
Figura 25. Modelo de red de ambiente de simulación con subredes generando tráfico hacia dos nodos que
implementan la arquitectura propuesta: ..................................................................................................... 32
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: .............. 33
Figura 27. Modelo de red de subred 1 con 8 estaciones de trabajo que generan tráfico TCP/IP: .............. 33
Figura 28. Exposición de parametrización de generadores de entidades TCP/IP en el modelo de red
OPNET: ...................................................................................................................................................... 34
Figura 29. Parametrización de la operación del nodo EtherChannelADV_X en el modelo de red OPNET:
.................................................................................................................................................................... 34
Figura 30. Modelo de Proceso OPNET del módulo “LeastLoad Analysis”: ............................................. 35
Figura 31. Modelo de Nodo para validación del módulo “LeastLoad Analysis”: ..................................... 35
Figura 32. Flujo de mensajes y señalización esperada para la operación del módulo “LeastLoad Analysis”:
.................................................................................................................................................................... 35
Figura 33. Señalización involucrada en la operación del módulo “LeastLoad Analysis”: ........................ 35
Figura 34. Contenido de los vectores de prueba que consolidan los valores promedio de tráfico para el
grupo de ocho interfaces: ........................................................................................................................... 36
Figura 35. Flujo de paquetes de prueba durante la simulación controlada: ............................................... 36
Figura 36. Contenido del paquete ID 91: ................................................................................................... 36
Figura 37. Contenido del paquete ID 90: ................................................................................................... 36
Figura 38. Paquete ID 92 resultado de la operación del módulo “LeastLoad Analysis”: .......................... 36
Figura 39. Contenido del paquete ID 92: ................................................................................................... 36
Figura 40. Flujo de paquetes de prueba durante la simulación controlada: ............................................... 37
Figura 41. Contenido del paquete ID 64: ................................................................................................... 37
Figura 42. Contenido del paquete ID 63: ................................................................................................... 37
Figura 43. Paquete ID 65 resultado de la operación del módulo “LeastLoad Analysis”: .......................... 37
Figura 44. Contenido del paquete ID 65: ................................................................................................... 37
Figura 45. Modelo de Proceso OPNET del módulo “SM_Reqs_Queue”: ................................................. 38
Figura 46. Modelo de Proceso OPNET del algoritmo Hashing de Bits de EtherChannel: ........................ 38
Figura 47. Modelo de Red para validación del modelado del algoritmo de asignación de carga de
EtherChannel: ............................................................................................................................................. 39
Figura 48. Modelo de Nodo en el cual fue aislado el módulo “EtherChannel_HA_Algorithm” objeto de
validación: .................................................................................................................................................. 39
Figura 49. Direcciones IP origen y destino asignadas al generador de tráfico para fines de construcción de
las entidades IP: .......................................................................................................................................... 39
Figura 50. Parametrización del módulo “EtherChannel_HA_Algorithm”: ............................................... 39
Figura 51. Flujo de paquetes hacia el módulo “EtherChannel_HA_Algorithm” durante validación: ....... 40
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: ............................................................................................... 40
Figura 53. Parametrización del módulo “EtherChannel_HA_Algorithm”: ............................................... 40
Figura 54. Flujo de paquetes hacia el módulo “EtherChannel_HA_Algorithm” durante validación: ....... 40
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
LISTA DE FIGURAS
Figura 56. Parametrización del módulo “EtherChannel_HA_Algorithm”: ............................................... 41
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”: .................................................................................................... 41
Figura 58. Modelo de Proceso OPNET para el módulo “SWFabric_Processor”:...................................... 41
Figura 59. Modelo de Proceso OPNET para el módulo “StatisticsPoller”: ............................................... 42
Figura 60. Modelo de Proceso OPNET para el módulo “WeightsLoad_Settings”: ................................... 42
Figura 61. Modelo de Proceso OPNET para el módulo “SM_Ctrl_Switch”: ............................................ 42
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: ......................................... 44
Figura 64. Modelo de Proceso OPNET para el módulo de subcola q_7: ................................................... 44
Figura 65. Modelo de Proceso OPNET para el módulo “Collector”: ........................................................ 44
Figura 66. Estadística “Estado de Sistema”: .............................................................................................. 45
Figura 67. Estadística “Retardo de Procesamiento Nodal”: ....................................................................... 45
Figura 68. Plan de Simulaciones del Proyecto: .......................................................................................... 48
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: .............................................................. 49
Figura 70. Frecuencias para observaciones de tráfico saliente: ................................................................. 49
Figura 71. Ocupación Inbound promedio de enlaces de salida: ................................................................. 49
Figura 72. Frecuencias de observaciones de tráfico entrante: .................................................................... 49
Figura 73. Retardo de Procesamiento Nodal: ............................................................................................. 50
Figura 74. CDF Retardo de Procesamiento Nodal: .................................................................................... 50
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: .............................................................. 50
Figura 76. Frecuencias para observaciones de tráfico saliente: ................................................................. 50
Figura 77. Ocupación Inbound promedio de enlaces de salida: ................................................................. 51
Figura 78. Frecuencias de observaciones de tráfico entrante: .................................................................... 51
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: ................................................................. 51
Figura 80. Frecuencias de observaciones de tráfico entrante: .................................................................... 51
Figura 81. Ocupación Outbound promedio de enlaces de salida: .............................................................. 52
Figura 82. Frecuencias de observaciones de tráfico saliente:..................................................................... 52
Figura 83. Retardo de Procesamiento Nodal: ............................................................................................. 52
Figura 84. CDF Retardo de Procesamiento Nodal: .................................................................................... 52
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%): ........................................ 53
Figura 86. Estadística – Estado de Sistema (Alpha 25%): ......................................................................... 53
Figura 87. Frecuencias de observaciones de tráfico saliente (Alpha 25%): ............................................... 53
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%): ........................ 54
Figura 90. Retardo de Procesamiento Nodal (Alpha 25%): ....................................................................... 54
Figura 91. CDF Retardo de Procesamiento Nodal (Alpha 25%): .............................................................. 54
Figura 92. Ocupación Outbound promedio de enlaces de salida antes de modificación (Alpha 25%):..... 55
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%):
.................................................................................................................................................................... 55
Figura 95. Estadística – Estado de Sistema (Alpha 25%): ......................................................................... 55
Figura 96. Ocupación Inbound promedio de enlaces de salida antes de modificación (Alpha 25%): ....... 55
Figura 97. Ocupación Inbound promedio de enlaces de salida después de modificación (Alpha 25%): ... 55
Figura 98. Diagrama de Frecuencias de observaciones de tráfico entrante (Alpha 25%): ......................... 56
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): ................................................................... 56
Análisis de resultados Simulación No. 3
Figura 100. Ocupación Outbound promedio de enlaces de salida antes de modificación (Alpha 15%):... 56
Figura 101. Ocupación Outbound promedio de enlaces de salida post modificación (Alpha 15%): ......... 56
Figura 102. Diagrama de Frecuencias de observaciones de tráfico Outbound (Alpha 15%): .................... 57
Figura 103. Diagrama de frecuencias de observaciones de tráfico Outbound post modificación (Alpha
15%): .......................................................................................................................................................... 57
Figura 104. Ocupación Inbound promedio de enlaces de salida antes de modificación (Alpha 15%): ..... 57
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%):
.................................................................................................................................................................... 57
Figura 107. Diagrama de Frecuencias de observaciones de tráfico entrante post modificación (Alpha
15%): .......................................................................................................................................................... 57
Figura 108. Est. Estado de Sistema (pre modificación) (Alpha 15%): ...................................................... 58
Figura 109. Est. Estado de Sistema (post modificación) (Alpha 15%): ..................................................... 58
Figura 110. Retardo de Procesamiento Nodal pre modificación (Alpha 15%): ......................................... 58
Figura 111. Comparación entre CDFs Retardo de Procesamiento Nodal pre-post modific. (Alpha 15%):
.................................................................................................................................................................... 58
LISTA DE FIGURAS
Análisis de resultados Simulación No. 4
Figura 112. Ocupación Outbound promedio de enlaces de salida antes de modificación (Alpha 5%):..... 59
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%): ................................................................................................................................................ 59
Figura 115. Diagrama de Frecuencias de observaciones de ocupación Outbound después de modif. (Alpha
5%): ............................................................................................................................................................ 59
Figura 116. Diagrama de Frecuencias de observaciones de ocupación Inbound pre modificación (Alpha
5%): ............................................................................................................................................................ 59
Figura 117. Diagrama de Frecuencias de observaciones de ocupación Inbound post modificación (Alpha
5%): ............................................................................................................................................................ 59
Figura 118. Retardo de Procesamiento Nodal pre modificación (Alpha 5%): ........................................... 59
Figura 119. Comparación entre CDFs Retardo de Procesamiento Nodal pre (azul) – post (verde)
modificación (Alpha 5%): .......................................................................................................................... 59
Figura 120. Estadística – Estado de Sistema (pre modificación): .............................................................. 60
Figura 121. Estadística – Estado de Sistema (post modificación): ............................................................ 60
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%): ................... 61
Figura 123. Frecuencias de observaciones de ocupación enlaces de salida tráfico saliente antes de
modificación (Alpha 25%): ........................................................................................................................ 61
Figura 124. Ocupación Outbound de enlaces de salida antes de modificación (Alpha 15%): ................... 61
Figura 125. Frecuencias de observaciones de ocupación enlaces de salida tráfico salida antes de
modificación (Alpha 15%): ........................................................................................................................ 61
Figura 126. Ocupación Outbound de enlaces de salida antes de modificación (Alpha 5%): ..................... 61
Figura 127. Frecuencias de observaciones de ocupación enlaces de salida tráfico saliente antes de
modificación (Alpha 5%): .......................................................................................................................... 61
Figura 128. Ocupación Inbound de enlaces de salida antes de modificación (Alpha 25%): ..................... 62
Figura 129. Frecuencias de observaciones de ocupación enlaces de salida tráfico entrante antes de
modificación (Alpha 25%): ........................................................................................................................ 62
Figura 130. Ocupación Inbound de enlaces de salida antes de modificación (Alpha 15%): ..................... 62
Figura 131. Frecuencias de observaciones de ocupación enlaces de salida tráfico entrante antes de
modificación (Alpha 15%): ........................................................................................................................ 62
Figura 132. Ocupación Inbound de enlaces de salida antes de modificación (Alpha 5%): ....................... 62
Figura 133. Frecuencias de observaciones de ocupación enlaces de salida tráfico entrante antes de
modificación (Alpha 5%): .......................................................................................................................... 62
Figura 134. Estadística Estado de Sistema Escenario con Perturbaciones antes de modificación (Alpha
25%): .......................................................................................................................................................... 62
Figura 135. CDF Retardo de Procesamiento. Nodal (Alpha 25%): ........................................................... 62
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%): .......................................................................................................................................................... 63
Figura 137. CDF Retardo de Procesamiento Nodal (Alpha 15%): ............................................................ 63
Figura 138. Estadística Estado de Sistema Escenario con Perturbaciones antes de modificación (Alpha
5%): ............................................................................................................................................................ 63
Figura 139. CDF Retardo de Procesamiento Nodal (Alpha 5%): .............................................................. 63
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): ................................................................................................................................ 63
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): ................................................................................................................................ 64
Figura 143. Frecuencias de observaciones de ocupación enlaces de salida tráfico entrante (Alpha 25%):
.................................................................................................................................................................... 64
Figura 144. Estadística “Estado de Sistema” para el Escenario de Simulación No. 5 con análisis de
muestras al 75%: ........................................................................................................................................ 64
Figura 145. Retardo de Procesamiento Nodal (Alpha 25%): ..................................................................... 64
Figura 146. CDF Retardo de Procesamiento Nodal (Alpha 25%): ............................................................ 64
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): ................................................................................................................................ 64
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): ................................................................................................................................ 65
Figura 150. Frecuencias de observaciones de ocupación enlaces de salida tráfico entrante (Alpha 25%):
.................................................................................................................................................................... 65
Figura 151. CDF Retardo de Procesamiento Nodal (Alpha 25%): ............................................................ 65
Figura 152. Diagrama de bloques de la arquitectura del nodo de conmutación propuesto: ....................... 66
Figura 153. Ocupación promedio de enlaces de salida para tráfico saliente Método de Asignación de
Carga Hashing de Bits: ............................................................................................................................... 67
Figura 154. Diagrama de Frecuencias de observaciones de ocupación Método de Asignación de Carga
Hashing de Bits: ......................................................................................................................................... 67
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%): ........................................................................ 67
Figura 156. Diagrama de Frecuencias de observaciones de ocupación Método de Asignación de Carga
Propuesto (Alpha 25%): ............................................................................................................................. 67
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: ....................................................................................................................................... 10
Tabla 2. Asignación inequitativa de índices a enlaces dentro de configuraciones EtherChannel de 3, 5, 6, 7
enlaces: ....................................................................................................................................................... 11
LISTA DE TÉRMINOS Y ABREVIATURAS
LISTA DE TÉRMINOS Y ABREVIATURAS
Término/Abrev. Descripción
IDC 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).
IEEE Institute of Electrical and Electronics Engineers (Instituto de Ingenieros
Eléctricos y Electricistas).
HSSG IEEE 802.3 Higher Speed Study Group (Grupo de Estudio de Mayor Velocidad
802.3 del IEEE).
Network Core Núcleo de Red (Permite enlazar diferentes servicios como Internet, redes privadas,
redes LAN o telefonía, entre otros).
Streaming (Método de transmisión y reproducción de archivos de audio y video por lotes).
P2P Network 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í).
QoS Quality of Service (Calidad de Servicio).
Capex Capital Expenditures (Gastos Capitales).
FastEthernet (Tecnología de red LAN basada en IEEE 802.3 con velocidad 100Mbps).
GigabitEthernet (Tecnología de red LAN basada en IEEE 802.3 con velocidad 1Gbps).
10Gigabit Ethernet (Tecnología de red LAN basada en IEEE 802.3 con velocidad 10Gbps).
LAN Local Area Network (Red de Área Local).
WAN Wide Area Network (Red de Área Amplia).
EtherChannel (Tecnología propietaria Cisco para agregar enlaces físicos IEEE 802.3 en canales
lógicos).
HP-UX (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)).
Hashing de Bits (Método de asignación de carga estático soportado en la tecnología
EtherChannel).
Throughput Rendimiento (Se llama throughput al volumen de trabajo o de información que
fluye a través de un sistema).
SNMP Simple Network Management Protocol (Protocolo de Gestión de Red Simple).
NetFlow (Protocolo de gestión de red propietario Cisco).
IP Internet Protocol (Protocolo Internet).
Overhead 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).
DMZ Demilitarized Zone (Zonas Desmilitarizadas).
Proxy Proxy (En una red informática, es un programa o dispositivo que realiza una
acción en representación de otro).
Firewall Cortafuego (Es una parte de un sistema o una red que está diseñada para bloquear
servicios de red y accesos no autorizados).
UDP User Datagram Protocol (Protocolo de Datagramas de Usuario).
TCP Transport Control Protocol (Protocolo de Control de Transporte).
Interleaving 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).
Arquitectura de balanceo de carga dinámico para la lógica de conmutación EtherChannel
RTP/RTCP Real Time Transport Protocol / Real Time Transport Control Protocol (Protocolo
de Transporte en Tiempo Real / Protocolo de Control de Transporte en Tiempo
Real).
Jitter Fluctuación (Variación indeseada y abrupta de la propiedad de una señal).
Packet Loss Pérdida de Paquetes.
Round Robin Round Robin (Método de Asignación de Carga).
Weighted Round R. Round Robin Ponderado (Método de Asignación de Carga).
Random Aleatorio (Método de Asignación de Carga).
Least Connection Menor Conexión (Método de Asignación de Carga).
Least Load Menor Carga (Método de Asignación de Carga)
PagP Port aggregation Protocol (Protocolo de Agregación de Puertos).
LACP Link Aggregation Control Protocol (Protocolo de Control de Agregación de
Enlaces, definido en el estándar IEEE 802.3ad).
OPNET OPtimized NETwork Engineering Tools (Herramientas de Ingeniería de Red
Optimizadas).
DES Discrete Event Simulation (Simulación de Eventos Discretos).
FSM Finite State Machine (Máquina de Estados Finitos).
INTRODUCCIÓN
1
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 802.3 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 2015.
Figura 1. Proyecciones de demanda de ancho de banda del IEEE 802.3 HSSG. Tomado de IEEE 802.3 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
Arquitectura de balanceo de carga dinámico para la lógica de conmutación EtherChannel
2
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
INTRODUCCIÓN
3
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 usuario1, 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
1Ver 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:
12023. p. 9.
Arquitectura de balanceo de carga dinámico para la lógica de conmutación EtherChannel
4
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.
Figura 5. Delta Tráfico Inbound – Outbound interfaces participantes EtherChannel THDPCB (Cisco3400) – THDPolo1 (Cisco7600).
-8,00E+07
-6,00E+07
-4,00E+07
-2,00E+07
0,00E+00
2,00E+07
4,00E+07
6,00E+07
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
Diff Outbound
Diff Inbound
INTRODUCCIÓN
5
En el Anexo G (en medio digital), se encuentra la Figura 5 con mayor detalle (Figura G.1).
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
Arquitectura de balanceo de carga dinámico para la lógica de conmutación EtherChannel
6
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.
INTRODUCCIÓN
7
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 14.5.
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 14.5.
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.
Arquitectura de balanceo de carga dinámico para la lógica de conmutación EtherChannel
8
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.
MARCO TEÓRICO
9
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: 12023.
Con respecto al estándar Ethernet, el ancho de banda de una interfaz según la especificación IEEE 802.3
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 802.3 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 802.3 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
Arquitectura de balanceo de carga dinámico para la lógica de conmutación EtherChannel
10
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 IPv4
192.168.15.15, 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 00001111 y el último bit
(1) indica la selección del enlace “1”. En adición, cuatro interfaces requieren el análisis de 2 bits (00-01-
10-11) y ocho interfaces requieren el análisis de 3 bits (000-001-010-011-100-101-110-111).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/2820.
8500 Ú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: 12023
MARCO TEÓRICO
11
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: 12023
1.2 CONCEPTOS SOBRE SIMULACIÓN
1.2.1 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
Arquitectura de balanceo de carga dinámico para la lógica de conmutación EtherChannel
12
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.
MARCO TEÓRICO
13
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.
1.2.2 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.
1.2.2.1 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.
1.2.2.2 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,
Arquitectura de balanceo de carga dinámico para la lógica de conmutación EtherChannel
14
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
1.3.1 SUITE DE APLICACIONES OPNET
OPNET significa OPtimized NETwork Engineering Tools y fue desarrollado por una compañía llamada
OPNET Technologies Inc., fundada en 1986. 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.
MARCO TEÓRICO
15
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.
1.3.2 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
Arquitectura de balanceo de carga dinámico para la lógica de conmutación EtherChannel
16
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.
MARCO TEÓRICO
17
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].
Arquitectura de balanceo de carga dinámico para la lógica de conmutación EtherChannel
18
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
ESPECIFICACIONES
19
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.
Arquitectura de balanceo de carga dinámico para la lógica de conmutación EtherChannel
20
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.
2.3.1 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”
ESPECIFICACIONES
21
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”
Estado = Selector
Caso 1: >> “Conmutar paquetes desde Round Robin Deficit”
Estado = Selector
}
Ir al Estado “Esperar” *************************************************************************************************
2.3.2 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”.
Arquitectura de balanceo de carga dinámico para la lógica de conmutación EtherChannel
22
2.3.3 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) {
ESPECIFICACIONES
23
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
Ir al estado “ProcesamientoDePesos”
Caso 0: >> Quantums No Disponibles
Ir al estado “Esperar”
}
SI NO { 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 2-0-1
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 2-0-0
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” *************************************************************************************************
2.3.4 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.
Arquitectura de balanceo de carga dinámico para la lógica de conmutación EtherChannel
24
Figura 21. Señalización considerada en el modelo de nodo de la arquitectura propuesta.
2.3.5 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 “0.0.0.7”)
}
Caso 1: ( -> ip-dst hashing bits) {
“ici_id” = (dst-IPAdd AND “0.0.0.7”)
}
Caso 2: ( -> ip-src-dst hashing bits) {
“ici_id” = ((src-IPAdd XOR dst-IPAdd) AND “0.0.0.7”)
}
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” *************************************************************************************************
ESPECIFICACIONES
25
2.3.6 Módulo WeightsLoad_Settings
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,…
(7)
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)) {
Arquitectura de balanceo de carga dinámico para la lógica de conmutación EtherChannel
26
SI (MediaLink > MediaSample o MediaLink == MediaSample) {
weight = 200.0 - 200.0 x (MediaLink - MediaSample)
-------------------------
MediaSample
}
SI (MediaLink < MediaSample) {
weight = 200.0 + 200.0 x (MediaSample - MediaLink)
-------------------------
MediaSample
}
}
SI (MediaLink == 0) {
weight = 200.0 + 200.0 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 = 10000 bytes x (wi / weightTotal)
Crear una trama de señalización con contenidos 6-1-1 “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”
*************************************************************************************************
2.3.7 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
ESPECIFICACIONES
27
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”
*************************************************************************************************
Arquitectura de balanceo de carga dinámico para la lógica de conmutación EtherChannel
28
2.3.8 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”.
ESPECIFICACIONES
29
En el Anexo G (en medio digital), se encuentra la Figura 22 con mayor detalle (Figura G.5).
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
Definir variable “CambioPendiente” = 1
Caso 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”
}
}
*************************************************************************************************
Arquitectura de balanceo de carga dinámico para la lógica de conmutación EtherChannel
30
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”
**************************************************************************************
ESPECIFICACIONES
31
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!
Caso x = 7: Q_i < campo “7” del vector; destruir vector!}
}
Ci_def = 0
Ir al Estado “Esperar”
**************************************************************************************
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 = 10000000
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”
Arquitectura de balanceo de carga dinámico para la lógica de conmutación EtherChannel
32
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.
DESARROLLOS
33
En el Anexo G (en medio digital), se encuentra la Figura 25 con mayor detalle (Figura G.7).
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
Arquitectura de balanceo de carga dinámico para la lógica de conmutación EtherChannel
34
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.
DESARROLLOS
35
3.2.1 Módulo LeastLoad Analysis
A continuación se presenta el modelo de proceso orientado al estado de este módulo:
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:
Arquitectura de balanceo de carga dinámico para la lógica de conmutación EtherChannel
36
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.
DESARROLLOS
37
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 65.
Arquitectura de balanceo de carga dinámico para la lógica de conmutación EtherChannel
38
3.2.2 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.16.
3.2.3 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.
DESARROLLOS
39
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”.
Arquitectura de balanceo de carga dinámico para la lógica de conmutación EtherChannel
40
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.
DESARROLLOS
41
Figura 56. Parametrización del módulo “EtherChannel_HA_Algorithm”.
El último octeto de 172.21.0.4 es “4” > 00000100. El último octeto de 192.168.0.1 es “1” > 00000001. El
resultado de la operación XOR entre ambos octetos es 00000101. 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).
3.2.4 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”.
Arquitectura de balanceo de carga dinámico para la lógica de conmutación EtherChannel
42
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.
3.2.5 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.
3.2.6 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.
3.2.7 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”.
DESARROLLOS
43
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 3-0-1
(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.
6. 250ms 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 3-0-0 (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.
Arquitectura de balanceo de carga dinámico para la lógica de conmutación EtherChannel
44
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).
3.2.8 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).
DESARROLLOS
45
3.2.9 Estadísticas programadas
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.
Arquitectura de balanceo de carga dinámico para la lógica de conmutación EtherChannel
46
4. ANALISIS DE RESULTADOS
4.1 PLAN DE SIMULACIONES DEL PROYECTO
4.1.1 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: 192.168.0.14 – IP Destino: 172.21.0.12
PC_2: Distribución de tiempos entre generaciones de paquetes: Exponencial.
Parámetro 1/α = 0.1 > 10 packets/s – IP Origen: 192.168.0.2 – IP Destino: 172.21.0.7
PC_3: Distribución de tiempos entre generaciones de paquetes: Exponencial.
Parámetro 1/α = 1 > 1 packets/s – IP Origen: 192.168.0.3 – IP Destino: 172.21.0.6
PC_4: Distribución de tiempos entre generaciones de paquetes: Exponencial.
Parámetro 1/α = 0.1 > 10 packets/s – IP Origen: 192.168.0.4 – IP Destino: 172.21.0.5
PC_5: Distribución de tiempos entre generaciones de paquetes: Exponencial.
Parámetro 1/α = 0.1 > 10 packets/s – IP Origen: 192.168.0.11 – IP Destino: 172.21.0.2
PC_6: Distribución de tiempos entre generaciones de paquetes: Exponencial.
Parámetro 1/α = 0.1 > 10 packets/s – IP Origen: 192.168.0.6 – IP Destino: 172.21.0.4
PC_7: Distribución de tiempos entre generaciones de paquetes: Exponencial.
Parámetro 1/α = 0.1 > 10 packets/s – IP Origen: 192.168.0.16 – IP Destino: 172.21.0.11
PC_8: Distribución de tiempos entre generaciones de paquetes: Exponencial.
Parámetro 1/α = 0.05 > 20 packets/s – IP Origen: 192.168.0.8 – IP Destino: 172.21.0.3
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: 172.21.0.1 – IP Destino: 192.168.0.8
PC_2: Distribución de tiempos entre generaciones de paquetes: Exponencial.
Parámetro 1/α = 0.1 > 10 packets/s – IP Origen: 172.21.0.2 – IP Destino: 192.168.0.7
PC_3: Distribución de tiempos entre generaciones de paquetes: Exponencial.
Parámetro 1/α = 0.1 > 10 packets/s – IP Origen: 172.21.0.3 – IP Destino: 192.168.0.1
PC_4: Distribución de tiempos entre generaciones de paquetes: Exponencial.
ANALISIS DE RESULTADOS
47
Parámetro 1/α = 1 > 1 packets/s – IP Origen: 172.21.0.4 – IP Destino: 192.168.0.3
PC_5: Distribución de tiempos entre generaciones de paquetes: Exponencial.
Parámetro 1/α = 0.1 > 10 packets/s - IP Origen: 172.21.0.9 – IP Destino: 192.168.0.24
PC_6: Distribución de tiempos entre generaciones de paquetes: Exponencial.
Parámetro 1/α = 0.1 > 10 packets/s – IP Origen: 172.21.0.6 – IP Destino: 192.168.0.4
PC_7: Distribución de tiempos entre generaciones de paquetes: Exponencial.
Parámetro 1/α = 0.1 > 10 packets/s – IP Origen: 172.21.0.7 – IP Destino: 192.168.0.6
PC_8: Distribución de tiempos entre generaciones de paquetes: Exponencial.
Parámetro 1/α = 0.1 > 10 packets/s – IP Origen: 172.21.0.24 – IP Destino: 192.168.0.21
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.
4.1.2 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.
Arquitectura de balanceo de carga dinámico para la lógica de conmutación EtherChannel
48
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.
ANALISIS DE RESULTADOS
49
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.
4.2.1 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: 192.168.0.14 (Carga el enlace 6)
PC_3: Distribución de tiempos entre generaciones de paquetes: Exponencial.
Parámetro 1/λ = 50 packets/s – IP Origen: 192.168.0.3 (Carga el enlace 3)
PC_5: Distribución de tiempos entre generaciones de paquetes: Exponencial.
Parámetro 1/λ = 10 packets/s – IP Origen: 192.168.0.11 (Carga el enlace 3)
PC_6: Distribución de tiempos entre generaciones de paquetes: Exponencial.
Parámetro 1/λ = 10 packets/s – IP Origen: 192.168.0.6 (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.
Arquitectura de balanceo de carga dinámico para la lógica de conmutación EtherChannel
50
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: 172.21.0.3 – (Carga el enlace ID 3)
PC_4: Distribución de tiempos entre generaciones de paquetes: Exponencial.
Parámetro 1/λ = 50 packets/s – IP Origen: 172.21.0.4 – (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.
4.2.2 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: 172.21.0.12 (Carga el enlace ID 4)
ANALISIS DE RESULTADOS
51
PC_3: Distribución de tiempos entre generaciones de paquetes: Exponencial.
Parámetro 1/λ = 50 packets/s – IP Destino: 172.21.0.6 (Carga el enlace ID 6)
PC_6: Distribución de tiempos entre generaciones de paquetes: Exponencial.
Parámetro 1/λ = 10 packets/s – IP Destino: 172.21.0.4 (Carga el enlace ID 4)
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: Distribución de tiempos entre generaciones de paquetes: Exponencial.
Parámetro 1/λ = 100 packets/s – IP Destino: 192.168.0.1 (Carga el enlace ID 1)
PC_4: Distribución de tiempos entre generaciones de paquetes: Exponencial.
Parámetro 1/λ = 50 packets/s – IP Destino: 192.168.0.3 (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 74.
4.2.3 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.
Arquitectura de balanceo de carga dinámico para la lógica de conmutación EtherChannel
52
PC_3: Distribución de tiempos entre generaciones de paquetes: Exponencial.
Parámetro 1/λ = 100 packets/s – IP Origen: 172.21.0.3 – IP Destino: 192.168.0.1 XOR (3 bits LSB) = “010” > 2 (Carga el enlace ID 2)
PC_4: Distribución de tiempos entre generaciones de paquetes: Exponencial.
Parámetro 1/λ = 50 packets/s – IP Origen: 172.21.0.4 – IP Destino: 192.168.0.3 XOR (3 bits LSB) = “111” > 7 (Carga el enlace ID 7)
PC_6: Distribución de tiempos entre generaciones de paquetes: Exponencial.
Parámetro 1/λ = 10 packets/s – IP Origen: 172.21.0.6 – IP Destino: 192.168.0.4 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: Distribución de tiempos entre generaciones de paquetes: Exponencial.
Parámetro 1/λ = 100 packets/s – IP Origen: 192.168.0.14 – IP Destino: 172.21.0.12
XOR (3 bits LSB) = “010” > 2 (Carga el enlace ID 2)
PC_2: Distribución de tiempos entre generaciones de paquetes: Exponencial.
Parámetro 1/λ = 10 packets/s – IP Origen: 192.168.0.2 – IP Destino: 172.21.0.7
XOR (3 bits LSB) = “101” > 5 (Carga el enlace ID 5)
PC_3: Distribución de tiempos entre generaciones de paquetes: Exponencial.
Parámetro 1/λ = 50 packets/s – IP Origen: 192.168.0.3 – IP Destino: 172.21.0.6
XOR (3 bits LSB) = “101” > 5 (Carga el enlace ID 5)
PC_6: Distribución de tiempos entre generaciones de paquetes: Exponencial.
Parámetro 1/λ = 10 packets/s – IP Origen: 192.168.0.6 – IP Destino: 172.21.0.4
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.
ANALISIS DE RESULTADOS
53
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.
4.2.4 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%.
Arquitectura de balanceo de carga dinámico para la lógica de conmutación EtherChannel
54
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.
ANALISIS DE RESULTADOS
55
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%).
Arquitectura de balanceo de carga dinámico para la lógica de conmutación EtherChannel
56
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.
4.2.5 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%).
ANALISIS DE RESULTADOS
57
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%).
Arquitectura de balanceo de carga dinámico para la lógica de conmutación EtherChannel
58
Estadística: Estado de Sistema:
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.
ANALISIS DE RESULTADOS
59
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):
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%).
Arquitectura de balanceo de carga dinámico para la lógica de conmutación EtherChannel
60
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: 192.168.0.3 - Dirección IP Destino: 172.21.0.6
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: 192.168.0.8 - Dirección IP Destino: 172.21.0.3
StartTime: 2000 segundos – StopTime: 2300 segundos
Solo PC_4 genera tráfico normalmente, las demás fuentes quedan deshabilitadas.
ANALISIS DE RESULTADOS
61
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: 172.21.0.1 - Dirección IP Destino: 192.168.0.8
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: 172.21.0.4 - Dirección IP Destino: 192.168.0.3
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%).
Arquitectura de balanceo de carga dinámico para la lógica de conmutación EtherChannel
62
Análisis tráfico entrante:
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%).
ANALISIS DE RESULTADOS
63
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.
4.2.7 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%).
Arquitectura de balanceo de carga dinámico para la lógica de conmutación EtherChannel
64
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%).
ANALISIS DE RESULTADOS
65
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 4.2.4.
Arquitectura de balanceo de carga dinámico para la lógica de conmutación EtherChannel
66
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.
CONCLUSIONES
67
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%).
Arquitectura de balanceo de carga dinámico para la lógica de conmutación EtherChannel
68
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
CONCLUSIONES
69
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
Arquitectura de balanceo de carga dinámico para la lógica de conmutación EtherChannel
70
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.
BIBLIOGRAFÍA
71
6. BIBLIOGRAFÍA
[1] Ethernet speeds in 2013: not a matter of 400G or 1TB, but cheaper 100G. Recuperado en
http://www.ethernetalliance.org/wp-content/uploads/2013/01/Ethernet-speeds-in-2013-2.pdf
[2]Law, D.J., Diab, W.W., Healey, A., Carlson, S.B., Maguire, V.(2012). IEEE 802.3™ Industry
Connections Ethernet Bandwidth Assessment. Recuperado en
http://www.ieee802.org/3/ad_hoc/bwa/BWA_Report.pdf
[3] Muller, S., Bechtolsheim, A., Hendel, A. (2007).HSSG Speeds and Feeds - Reality Check. Recuperado
en http://www.ieee802.org/3/hssg/public/jan07/muller_01_0107.pdf
[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://www.hp.com
[7] Hucaby, D. (2010). CCNP SWITCH 642-813 Official Certification Guide. Pearson Education, Inc.
[8] Understanding EtherChannel Load Balancing and Redundancy on Catalyst Switches. Documento
ID: 12023.Recuperado el 10 de Enero de 2013 en
http://www.cisco.com/en/US/tech/tk389/tk213/technologies_tech_note09186a0080094714.shtml
[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 www.opnet.com.
[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.
Arquitectura de balanceo de carga dinámico para la lógica de conmutación EtherChannel
72
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”.
ANEXOS
73
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 67.
Arquitectura de balanceo de carga dinámico para la lógica de conmutación EtherChannel
74
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 69.
ANEXOS
75
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
192.168.0.1 e IP destino 172.21.0.4, 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”.
Arquitectura de balanceo de carga dinámico para la lógica de conmutación EtherChannel
76
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”.
ANEXOS
77
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.
Arquitectura de balanceo de carga dinámico para la lógica de conmutación EtherChannel
78
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.
ANEXOS
79
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).
Arquitectura de balanceo de carga dinámico para la lógica de conmutación EtherChannel
80
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.
ANEXOS
81
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.
Arquitectura de balanceo de carga dinámico para la lógica de conmutación EtherChannel
82
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).
ANEXOS
83
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 : 125
Arquitectura de balanceo de carga dinámico para la lógica de conmutación EtherChannel
84
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.
ANEXOS
85
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.
Arquitectura de balanceo de carga dinámico para la lógica de conmutación EtherChannel
86
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.
ANEXOS
87
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 7-1-0 (que induce un vaciado de las
subcolas) así como para detener el recorrido RoundRobin al finalizar el ciclo en mención.
Arquitectura de balanceo de carga dinámico para la lógica de conmutación EtherChannel
88
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.
ANEXOS
89
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.
Arquitectura de balanceo de carga dinámico para la lógica de conmutación EtherChannel
90
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): 26640
Module (649), (top.Collector_Validation.Sampler_P1)
From procedure: traffic_collector [bytes_sec enter execs]
Sample S2 (number): 20720
Module (649), (top.Collector_Validation.Sampler_P1)
From procedure: traffic_collector [bytes_sec enter execs]
Sample S3 (number): 29600
Module (649), (top.Collector_Validation.Sampler_P1)
From procedure: traffic_collector [bytes_sec enter execs]
Sample S4 (number): 23680
Module (649), (top.Collector_Validation.Sampler_P1)
From procedure: traffic_collector [bytes_sec enter execs]
Sample S5 (number): 25160
Module (649), (top.Collector_Validation.Sampler_P1)
From procedure: traffic_collector [bytes_sec enter execs]
Sample S6 (number): 31080
Module (649), (top.Collector_Validation.Sampler_P1)
From procedure: traffic_collector [bytes_sec enter execs]
Sample S7 (number): 37000
Module (649), (top.Collector_Validation.Sampler_P1)
From procedure: traffic_collector [bytes_sec enter execs]
Sample S8 (number): 35520
Module (649), (top.Collector_Validation.Sampler_P1)
From procedure: traffic_collector [bytes_sec enter execs]
Sample S9 (number): 32560
Module (649), (top.Collector_Validation.Sampler_P1)
From procedure: traffic_collector [bytes_sec enter execs]
Sample S10 (number): 25160
Module (649), (top.Collector_Validation.Sampler_P1)
From procedure: traffic_collector [bytes_sec enter execs]
Sample S11 (number): 37000
ANEXOS
91
Module (649), (top.Collector_Validation.Sampler_P1)
From procedure: traffic_collector [bytes_sec enter execs]
Sample S12 (number): 17760
Module (649), (top.Collector_Validation.Sampler_P1)
From procedure: traffic_collector [bytes_sec enter execs]
Sample S13 (number): 48840
Module (649), (top.Collector_Validation.Sampler_P1)
From procedure: traffic_collector [bytes_sec enter execs]
Sample S14 (number): 22200
Module (649), (top.Collector_Validation.Sampler_P1)
From procedure: traffic_collector [bytes_sec enter execs]
Sample S15 (number): 25160
Module (649), (top.Collector_Validation.Sampler_P1)
From procedure: traffic_collector [bytes_sec enter execs]
Sample S16 (number): 22200
Module (649), (top.Collector_Validation.Sampler_P1)
From procedure: traffic_collector [bytes_sec enter execs]
Sample S17 (number): 23680
Module (649), (top.Collector_Validation.Sampler_P1)
From procedure: traffic_collector [bytes_sec enter execs]
Sample S18 (number): 26640
Module (649), (top.Collector_Validation.Sampler_P1)
From procedure: traffic_collector [bytes_sec enter execs]
Sample S19 (number): 31080
Module (649), (top.Collector_Validation.Sampler_P1)
From procedure: traffic_collector [bytes_sec enter execs]
Sample S20 (number): 31080
Module (649), (top.Collector_Validation.Sampler_P1)
From procedure: traffic_collector [bytes_sec enter execs]
Sample S21 (number): 25160
Module (649), (top.Collector_Validation.Sampler_P1)
From procedure: traffic_collector [bytes_sec enter execs]
Sample S22 (number): 35520
Module (649), (top.Collector_Validation.Sampler_P1)
From procedure: traffic_collector [bytes_sec enter execs]
Sample S23 (number): 50320
Module (649), (top.Collector_Validation.Sampler_P1)
From procedure: traffic_collector [bytes_sec enter execs]
Sample S24 (number): 26640
Module (649), (top.Collector_Validation.Sampler_P1)
From procedure: traffic_collector [bytes_sec enter execs]
Sample S25 (number): 34040
Module (649), (top.Collector_Validation.Sampler_P1)
From procedure: traffic_collector [bytes_sec enter execs]
Sample S26 (number): 26640
Module (649), (top.Collector_Validation.Sampler_P1)
From procedure: traffic_collector [bytes_sec enter execs]
Sample S27 (number): 37000
Module (649), (top.Collector_Validation.Sampler_P1)
From procedure: traffic_collector [bytes_sec enter execs]
Sample S28 (number): 38480
Module (649), (top.Collector_Validation.Sampler_P1)
From procedure: traffic_collector [bytes_sec enter execs]
Sample S29 (number): 31080
Module (649), (top.Collector_Validation.Sampler_P1)
From procedure: traffic_collector [bytes_sec enter execs]
Sample S30 (number): 32560
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): 29282
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:
Arquitectura de balanceo de carga dinámico para la lógica de conmutación EtherChannel
92
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 1292. 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%:
ANEXOS
93
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.