arquitectura de balanceo de carga dinámico para la lógica

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




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


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 38. Paquete ID 92 resultado de la operación del módulo “LeastLoad Analysis”: .......................... 36


Figura 40. Flujo de paquetes de prueba durante la simulación controlada: ............................................... 37



Figura 43. Paquete ID 65 resultado de la operación del módulo “LeastLoad Analysis”: .......................... 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 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 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 76. Frecuencias para observaciones de tráfico saliente: ................................................................. 50



Análisis de resultados Simulación No. 1 (Método Hashing de Bits > src-dst-ip)




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


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


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


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


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


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


Figura 130. Ocupación Inbound de enlaces de salida antes de modificación (Alpha 15%): ..................... 62



Figura 132. Ocupación Inbound de enlaces de salida 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



15%): .......................................................................................................................................................... 63

Figura 137. CDF Retardo de Procesamiento Nodal (Alpha 15%): ............................................................ 63


5%): ............................................................................................................................................................ 63

Figura 139. CDF Retardo de Procesamiento Nodal (Alpha 5%): .............................................................. 63


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


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


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


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


Figura 150. Frecuencias de observaciones de ocupación enlaces de salida tráfico entrante (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).


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


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.


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


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.


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


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?


destino?


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


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,


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


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].


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.


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.


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.


20

Figura 18. Arquitectura propuesta operando en Modo Recuperación.


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”


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”.


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)




Se define la variable EstadoActual igual a 0

Se define la variable PesosListos igual a 0

Se define la variable CambioEstado igual a 0


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…


ESPECIFICACIONES

23




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 “PesosListos” a 0

}

}

SI (EstadoActual =! SiguienteEstado y EstadoActual == Recuperacion (1)) {


Actualizar la variable “EstadoActual” con la variable “SiguienteEstado”


Crear trama de señalización con contenidos 2-0-0




}

}

SI (EstadoActual == SiguienteEstado){



}

}

SI (CambioEstado == 1) {


Crear trama de señalización con contenidos 2-0-“EstadoActual”




}

}


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.


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.




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)


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”:


Ingresar el paquete en la subcola 0


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”

}

}

}



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”.




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)) {


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

}


*************************************************************************************************

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.




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


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 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 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


*************************************************************************************************

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


*************************************************************************************************

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


*************************************************************************************************


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


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.


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 la estadística local “Switching”

Se define la estadística global “Estado de Sistema”


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”:


SI (Estampado del paquete con tiempo de simulación es exitoso) {

Insertar paquete en la subcola (0) por tail }


*************************************************************************************************

Estado “Commands_Queueing”:

Recuperar la trama de señalización del stream de entrada

Insertar trama en la subcola (1) por tail


*************************************************************************************************

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)


}

SI NO {

SI (subcola (1) no está vacía) {

Remover trama de señalización de subcola (1) por head

Analizando sus campos…




SI (EstadoSwitch != 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)


}

}

SI (subcola (1) si está vacía) {

Se define interrupción temporizada de atención de subcola interna de señalización

(1)


}

}

*************************************************************************************************


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 }


*************************************************************************************************

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)

}

}

}



*************************************************************************************************

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.


Se define y actualiza la variable “Port” = 0


Si se recibe un paquete de datos, ir al estado “RoundRobin”

*************************************************************************************************

Estado “RoundRobin”:


Enviar el paquete por el puerto indexado por la variable “Port”

Incrementar Port en 1

SI (Port == 8) {

Port = 0

}


*************************************************************************************************

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.


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


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”:


Insertar paquete en la subcola (0) por tail


**************************************************************************************

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 = 7: Q_i < campo “7” del vector; destruir vector!}

}

Ci_def = 0


**************************************************************************************

Estado “RoundRobin”:

Remover trama de señalización del stream de entrada

Analizando sus campos…




Definir variable “RRState” = 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

}


**************************************************************************************

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



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.


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


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


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:


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.


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”.


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.



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”.



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”.


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”.


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”.


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”.


42


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”.


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”.


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.


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.


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”.


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.


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




Parámetro 1/α = 1 > 1 packets/s – IP Origen: 192.168.0.3 – IP Destino: 172.21.0.6











Para la Subred_1…








ANALISIS DE RESULTADOS

47

Parámetro 1/α = 1 > 1 packets/s – IP Origen: 172.21.0.4 – IP Destino: 192.168.0.3


Parámetro 1/α = 0.1 > 10 packets/s - IP Origen: 172.21.0.9 – IP Destino: 192.168.0.24







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


c. 5% de muestras (mínimas y máximas) no consideradas en el cálculo de la media muestral


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.


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.
















b. Tiempo de simulación: 5 horas Variación de Alpha: 25%

c. Objetivos: Verificar Ocupación de Enlaces.


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.


Parámetro 1/λ = 100 packets/s – IP Origen: 192.168.0.14 (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.


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.


Parámetro 1/λ = 100 packets/s – IP Origen: 172.21.0.3 – (Carga el enlace ID 3)


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)



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.


Parámetro 1/λ = 100 packets/s – IP Destino: 172.21.0.12 (Carga el enlace ID 4)


51





Para la dirección destino en PC_1 sus bits menos significativos son “100”, cargando el enlace ID 4.




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.





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)




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.


52


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)







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.


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)











Figura 83. Retardo de Procesamiento Nodal.

Figura 84. CDF Retardo de Procesamiento Nodal.


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


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%.


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%.


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.


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%).


saliente post modificación (alpha 25%).

Figura 95. Estadística – Estado de Sistema (alpha 25%).


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%).


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.



Ocupación de Enlaces (Tráfico saliente):



Figura 101. Ocupación Outbound promedio de enlaces de salida post modificación (alpha 15%).


57


Outbound (alpha 15%).

Figura 103. Diagrama de frecuencias de observaciones de tráfico

Outbound post modificación (alpha 15%).


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


Figura 105. Ocupación Inbound promedio de enlaces de salida después



entrante pre modificación (alpha 15%).


entrante post modificación (alpha 15%).


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.


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.


59






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%).



Inbound pre modificación (alpha 5%).


Inbound post modificación (alpha 5%).


Figura 118. Retardo de Procesamiento Nodal pre modificación (alpha

5%).

Figura 119. Comparación entre CDFs Retardo de Procesamiento

Nodal pre (azul) – post (verde) modificación (alpha 5%).


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


Parámetro 1/λ = 0.05 > 20 packets/s. Se sobre carga con 500 packets/s.



Solo PC_4 genera tráfico normalmente, las demás fuentes quedan deshabilitadas.


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.




Parámetro 1/λ = 1 > 1 packets/s. > Se sobre carga con 200 packets/s.



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


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%).


salida tráfico saliente antes de modificación (Alpha 5%).


62

Análisis tráfico entrante:

Figura 128. Ocupación Inbound de enlaces de salida antes de



salida tráfico entrante antes de modificación (Alpha 25%).









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%).


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.


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%).


64

Figura 142. Ocupación Inbound de enlaces de salida (Alpha 25% -

75% valores procesados por LeastLoad_Analysis).


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%).


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).


salida tráfico saliente (Alpha 25%).


65

Figura 149. Ocupación Inbound de enlaces de salida (Alpha 25% - 95% valores procesados por LeastLoad_Analysis).


salida tráfico entrante (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.


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%).


Método de Asignación de Carga Propuesto (alpha 25%).


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


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.

http://www.hp.com/


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”.


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 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”.



74

Figura 9. Generación de paquetes de señalización por parte del módulo “SM_Reqs_Queue”.



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”.


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.


78


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).


80


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.




Con respecto al primer caso detallado en la Figura 2, se presentan los contenidos del primer vector

consolidado de muestras.


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.


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.



82


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.


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


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








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.


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



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.


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.


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































ANEXOS

91



























































From procedure: traffic_collector [bytes_sample enter execs]

Information: AtributeRecovered >

Sampler_P1.alpha


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:


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.

arquitectura de balanceo de carga dinámico para la lógica

Documents