Universidad de Costa Rica Facultad de Ingeniera Escuela de Ingeniera Elctrica

IE 0502 Proyecto Elctrico

Anlisis y comparacin de mtodos de medicin del desempeo de redes de computadores Ethernet y Metro Ethernet

Por: Francisco Andrs Vargas Piedra

Ciudad Universitaria Rodrigo Facio Enero de 2011

Anlisis y comparacin de mtodos de medicin del desempeo de redes de computadores Ethernet y Metro Ethernet
Por: Francisco Andrs Vargas Piedra

Sometido a la Escuela de Ingeniera Elctrica de la Facultad de Ingeniera de la Universidad de Costa Rica como requisito parcial para optar por el grado de: BACHILLER EN INGENIERA ELCTRICA Aprobado por el Tribunal:

_________________________________ Ing. Eduardo Antonio Navas Carro, M. Sc. Profesor Gua

_________________________________ Ing. Patricia Navas Carro, M. Sc. Profesor lector ii

_________________________________ Ing. Andrs Castro Ulate Profesor lector

DEDICATORIA
A las personas que realmente creen en m: por ser ncleo de mi vitalidad y mis ganas de vivir. A mi madre y a mi padre, como forjadores de mi carcter. Y a mi padrino, por demostrarme tras su enfermedad, el valor del desapego material y de la vida.

iii

RECONOCIMIENTOS
A Antonio Navas Carro por su valiosa tutela. A los maestros que realmente se preocuparon por construir en m algo ms que una leccin de Ingeniera Elctrica, ensendome que detrs de toda labor o profesin, hay un ser humano.

iv

NDICE GENERAL
1. 1.1
1.1.1 1.1.2

CAPTULO 1: INTRODUCCIN ..................................................... 1 Objetivos .............................................................................................. 3

Objetivo general .......................................................................................................... 3 Objetivos especficos .................................................................................................. 3

1.2 2 2.1
2.1.1 2.1.2 2.1.3 2.1.4 2.1.5 2.1.6

Metodologa ......................................................................................... 4 CAPTULO 2: DESARROLLO TERICO ...................................... 5 Conceptos preliminares....................................................................... 5

Modelo de referencia OSI ........................................................................................... 5 Modelo de referencia TCP/IP ..................................................................................... 7 Telecomunicaciones.................................................................................................... 8 Red de telecomunicaciones ......................................................................................... 8 Red de computadores .................................................................................................. 9 Red de computadores Ethernet ................................................................................. 11
2.1.6.1 Protocolo IEEE 802.1Q................................................................................... 16

2.1.7 2.1.8

Red de computadores Metro Ethernet ...................................................................... 17 Desempeo de redes, calidad de servicio y desempeo de servicio ......................... 18
2.1.8.1 Calidad de servicio (QoS) ............................................................................... 19

2.1.8.2 2.1.8.3 2.1.8.4

Desempeo de red .......................................................................................... 20 Desempeo de servicio ................................................................................... 21 Relacin entre desempeo de red, desempeo de servicio y calidad de servicio 22

2.2
2.2.1 2.2.2

Sistema de regulacin de las telecomunicaciones en Costa Rica .... 25

Superintendencia de Telecomunicaciones ................................................................ 27 Ley General de Telecomunicaciones (8642) ............................................................ 28
2.2.2.1 Artculos relacionados con la medicin de desempeo de red (NP).................. 29

2.2.3

Reglamento de prestacin y calidad de los servicios ................................................ 31

2.2.3.1 Artculos relacionados con la medicin de desempeo de red (NP).................. 32

2.3

Entidades internacionales de recomendaciones sobre desempeo de

red y calidad de servicio .............................................................................. 39 3. 3.1.

3.1.1. 3.1.2

CAPTULO 3: HERRAMIENTAS DE MEDICIN DE NP ......... 42 Introduccin a la medicin del desempeo de red (NP) .................. 42
Tipos de medicin de desempeo de red .......................................................... 43 Mtricas de desempeo de red .................................................................................. 44

3.2.
3.2.1. 3.2.2.

Recomendacin Y.1564 de la UIT y RFC 2544 ................................ 50

RFC 2544 .......................................................................................................... 50 Recomendacin Y.1564 (o Y.156sam) de la UIT ............................................ 54
3.2.2.1. 3.2.2.2. SCT (prueba de configuracin del servicio)..................................................... 58 SPT (prueba de desempeo del servicio) ......................................................... 60

vi

3.3.
3.3.1. 3.3.2. 3.3.3. 3.3.4.

Herramientas bsicas para la medicin de NP ................................ 61

PING ................................................................................................................. 61 Traceroute ......................................................................................................... 63 Pathchar, pchar e iperf ...................................................................................... 63 SNMPwalk ........................................................................................................ 64

3.4.

Herramientas complejas para la medicin de NP (nivel de

proveedor de servicios) ............................................................................... 64 3.5. Herramientas para la medicin de NP (a nivel del suscriptor de

servicios) ...................................................................................................... 68
3.5.1. NetPerSec.......................................................................................................... 68
3.5.1.1. Metodologa de funcionamiento de NetPerSec ................................................ 69

3.5.2.

Speedtest de Ookla............................................................................................ 71
3.5.2.1. 3.5.2.2. Metodologa de funcionamiento de la prueba de descarga ............................... 72 Metodologa de funcionamiento de la prueba de subida ................................... 73

3.6.

Parmetros configurables en el CPE del suscriptor que pueden

afectar algunas mediciones de desempeo ................................................. 73

3.6.1. Modificacin de RWIN para afinamiento de TCP ........................................... 74
3.6.1.1. Modificacin de la ventana de recepcin TCP en Windows 7 para mejorar la tasa

de descarga...................................................................................................................... 77

vii

3.6.1.2. Linux

Modificacin de la ventana de recepcin TCP en sistemas operativos basados en 81

4.

CAPTULO 4: IMPLEMENTACIN Y COMPARACIN

ANALTICA DE LAS HERRAMIENTAS DE NP ................................... 83 4.1. 4.2. 4.3.

4.3.1. 4.3.2. 4.3.3.

Prueba de implementacin: PING ................................................... 85 Prueba de implementacin: traceroute ............................................ 87 Prueba de implementacin: D-ITG .................................................. 88
Instalacin de D-ITG con D-ITG GUI ............................................................. 89 Ejecucin de pruebas en D-ITG con D-ITG GUI ............................................. 91 Pruebas de implementacin ejecutadas............................................................. 94
4.3.3.1. 4.3.3.2. 4.3.3.3. Prueba UDP .................................................................................................... 94 Prueba TCP .................................................................................................... 98 Prueba de flujos mltiples ............................................................................. 103

4.4.
4.4.1. 4.4.2. 4.4.3. 4.4.4.

Prueba de implementacin: Netperf .............................................. 107

Instalacin de Netperf ..................................................................................... 107 Prueba throughput ....................................................................................... 108 Prueba throughput con omni test ............................................................. 110 Prueba latencia (RTT) ..................................................................................... 112

4.5.

Prueba de implementacin: Bing ................................................... 113

viii

4.6.
4.6.1. 4.6.2. 4.6.3.

Prueba de implementacin: MGEN ............................................... 115

Instalacin de MGEN con TRPR.................................................................... 116 Prueba TCP ..................................................................................................... 116 Grfica del trfico en tiempo real ................................................................... 118

4.7.
4.7.1. 4.7.2.

Prueba de implementacin: mdulo comercial ............................. 119

Metodologa de pruebas .................................................................................. 120 Prueba Y.1564 ................................................................................................ 121
4.7.2.1. 4.7.2.2. Prueba de datos de 5 Mbps............................................................................ 122 Prueba de datos de 15 Mbps .......................................................................... 123

4.7.3.

Prueba RFC 2544 ............................................................................................ 125

4.7.2.3. Prueba con throughput de 15 Mbps ............................................................ 126

4.8.

Prueba de implementacin a nivel de suscriptor: Speedtest de

Ookla .......................................................................................................... 128

4.8.1. 4.8.2. 4.8.3. 4.8.4. Metodologa de la prueba ............................................................................... 128 Instalacin del servidor de Speedtest de Ookla .............................................. 129 Resultados de la prueba .................................................................................. 130 Anlisis de los resultados de la prueba con el Speedtest de Ookla................. 136

4.9.

Prueba de implementacin a nivel de suscriptor: NetPerSec y

monitor del sistema de red de Linux ........................................................ 138

4.9.1. Implementacin de NetPerSec ........................................................................ 138 ix

4.9.1.1.

Anlisis de la implementacin de NetPerSec ................................................. 141

4.9.2.

Implementacin del monitor del sistema para Gnome en Ubuntu.................. 141

4.10.

Anlisis global y comparacin de los resultados y las

herramientas implementadas ................................................................... 143

4.10.1. Evaluacin de las herramientas en relacin con las metodologas de pruebas

RFC 2544 y la recomendacin de UIT Y.1564 .................................................................. 143

4.11.

Ejemplos de implementacin de herramientas de monitoreo de

desempeo no intrusivas: Nagios.............................................................. 146 5. CAPTULO 5: UTILIZACIN DE LAS HERRAMIENTAS DE

NP PARA LA MEDICIN DE LOS PARMETROS ESTABLECIDOS POR LA SUTEL........................................................................................ 150 5.1. 5.2. 5.3. Mtodo de medicin segn la recomendacin de la UIT Y.1541 .. 150 Cumplimiento de niveles de retardo a nivel local e internacional 151 Cumplimiento de niveles de variaciones en el retardo a nivel local e

internacional .............................................................................................. 153 5.4. Cumplimiento de niveles de prdida de paquetes a nivel local e

internacional .............................................................................................. 155

5.5.

Cumplimiento de niveles de ocupacin de enlaces locales e

internacionales ........................................................................................... 156 5.6. Cumplimiento del desempeo de la velocidad de transferencia local

e internacional respecto a la velocidad contratada.................................. 157 5.7. Sanciones aplicadas para los proveedores de servicios en el

incumplimiento de las mtricas ................................................................ 158 5.8. Evaluacin de las herramientas en relacin con los parmetros

solicitados por la SUTEL .......................................................................... 160 6. 6.1. 6.2. CAPTULO 6: CONCLUSIONES Y RECOMENDACIONES.... 163 Conclusiones .................................................................................... 163 Recomendaciones ............................................................................ 169

BIBLIOGRAFA ....................................................................................... 172 APNDICES ............................................................................................. 177 Apndice 1 ................................................................................................. 177

Configuracin terminal ProyectoElectricoNP .................................................................... 177 Configuracin terminal ProyectoElectricoNP2 .................................................................. 177

xi

NDICE DE FIGURAS
Figura 2.1. Esquema general del modelo de referencia OSI (Tanenbaum, 2003) .................. 6 Figura 2.2. Modelo de referencia TCP/IP (Tanenbaum, 2003) .............................................. 7 Figura 2.3. Topologa clsica de una red WAN (Tanenbaum, 2003) ................................... 10 Figura 2.4. Relacin del estndar IEEE 802.3 con el modelo de referencia OSI (IEEE, 2008) ..................................................................................................................................... 12 Figura 2.5. Estructura de una trama Ethernet segn el estndar IEEE 802.3 (IEEE, 2008) . 15 Figura 2.6. Tipos ms utilizados de cableado Ethernet (Tanenbaum, 2003) ........................ 16 Figura 2.7. Trama Ethernet con encabezado 802.1Q (IEEE, 2008) ..................................... 16 Figura 2.8. Servicio EPL (Ethernet Private Line) sobre una red Metro Ethernet ................. 18 Figura 2.9. Diagrama de interrelacin de desempeo de red, desempeo de servicio y calidad de servicio ................................................................................................................ 22 Figura 2.10. Relacin entre QoS y desempeo de red .......................................................... 23 Figura 2.11. Diagrama de relaciones conceptuales de QoS y NP (ETSI, 1994) .................. 24 Figura 3.1. Concepto de jitter: la figura superior no tiene jitter, la inferior s (Giguer, 2008) ..................................................................................................................................... 46 Figura 3.2. Efectos de la congestin de la red sobre las configuraciones de QoS en relacin con el tiempo de servicio y el rendimiento de la red (Mrquez & Ravelo, 2010) ................ 49 Figura 3.3. Topologa de prueba recomendada por el RFC 2544 ......................................... 50 Figura 3.4. Alegora del perfil de ancho de banda (Marshall, 2011) .................................... 57 xii

Figura 3.5. Fase 1 de la SCT (Diallo, 2011) ......................................................................... 59 Figura 3.6. Fase 2 de la SCT (Diallo, 2011) ......................................................................... 59 Figura 3.7. Fase 3 de la SCT (Diallo, 2011) ......................................................................... 60 Figura 3.8. Fase 3 de la SCT (Diallo, 2011) ......................................................................... 60 Figura 3.9. Salida de la utilidad PING .................................................................................. 62 Figura 3.10. Establecimiento de coincidencia entre las ventanas de envo y recepcin (Davies, 2007) ....................................................................................................................... 76 Figura 3.11. Tipos de datos de la ventana de recepcin TCP (Davies, 2007) ...................... 77 Figura 3.12. Parmetros globales de TCP en Windows 7 .................................................... 78 Figura 4.1. Esquema de pruebas implementado ................................................................... 84 Figura 4.2. Prueba de implementacin del PING ................................................................. 86 Figura 4.3. Prueba de implementacin del Traceroute ......................................................... 87 Figura 4.4. Configuracin de D-ITG GUI ............................................................................ 92 Figura 4.5. Configuracin del analizador de D-ITG GUI..................................................... 93 Figura 4.6. Configuracin de la prueba UDP ....................................................................... 94 Figura 4.7. Grfica de bits transmitidos en funcin del tiempo en la prueba UDP de D-ITG .............................................................................................................................................. 95 Figura 4.8. Grfica de jitter en prueba UDP de D-ITG ..................................................... 96 Figura 4.9. Grfica de prdida de paquetes en prueba UDP de D-ITG ................................ 96 Figura 4.10. Grfica de retardo en prueba UDP de D-ITG................................................... 97

xiii

Figura 4.11. Configuracin de la prueba TCP en D-ITG ..................................................... 99 Figura 4.12. Grfica de bits en funcin del tiempo de la prueba TCP en D-ITG ............... 100 Figura 4.13. Grfica de prdida de paquetes de la prueba TCP en D-ITG ......................... 101 Figura 4.14. Grfica de jitter de la prueba TCP en D-ITG.............................................. 101 Figura 4.15. Grfica de retardo de la prueba TCP en D-ITG ............................................. 102 Figura 4.16. Grfica de transferencias de red del monitor del sistema por defecto de la distribucin Ubuntu ............................................................................................................ 103 Figura 4.17. Configuracin de la prueba de mltiples flujos en D-ITG ............................. 104 Figura 4.18. Grfica de bits en funcin del tiempo para la prueba de flujos mltiples de DITG ...................................................................................................................................... 105 Figura 4.19. Grfica de retardo para la prueba de flujos mltiples de D-ITG .................... 105 Figura 4.20. Grfica de prdida de paquetes para la prueba de mltiples flujos de D-ITG106 Figura 4.21. Grfica de jitter en la prueba de mltiples flujos de D-ITG ....................... 106 Figura 4.22. Script de Netperf para el clculo del throughput..................................... 109 Figura 4.23. Prueba de throughput con Netperf .............................................................. 110 Figura 4.24. Prueba de throughput con omni test de Netperf ...................................... 111 Figura 4.25. Monitor de trfico de red en Ubuntu para prueba de Netperf ........................ 112 Figura 4.26. Prueba de RTT en Netperf.............................................................................. 112 Figura 4.27. Prueba de throughput mediante la herramienta Bing.................................. 114 Figura 4.28. Grfica de ancho de banda en funcin del tiempo para MGEN ..................... 118

xiv

Figura 4.29. Grfica en tiempo real del ancho de banda en funcin del tiempo para MGEN ............................................................................................................................................ 119 Figura 4.30. Resumen de resultados de la prueba de 15 Mbps para el RFC 2544 ............. 127 Figura 4.31. Grficas de resultados de la prueba de 15 Mbps para el RFC 2544 ............... 127 Figura 4.32. Resultados de la prueba del Speedtest de Ookla en el mejor escenario ......... 131 Figura 4.33. Resultados de la prueba del Speedtest de Ookla en el mejor escenario con parmetros de configuracin modificados .......................................................................... 132 Figura 4.34. Trfico generado de 1 Mbps de datos UDP para la prueba del Speedtest de Ookla ................................................................................................................................... 133 Figura 4.35. Resultados de la prueba del Speedtest de Ookla con trfico UDP de 1 Mbps generado desde la interfaz del servidor............................................................................... 133 Figura 4.36. Resultados de la prueba del Speedtest de Ookla con trfico UDP de 5 Mbps generado desde la interfaz del servidor............................................................................... 134 Figura 4.37. Resultados de la prueba del Speedtest de Ookla con trfico UDP de 5 Mbps generado desde la interfaz de ambas terminales ................................................................. 135 Figura 4.38. Resultados de la prueba del Speedtest de Ookla con trfico UDP de 10 Mbps generado desde la interfaz de ambas terminales ................................................................. 136 Figura 4.39. Interfaz principal de NetPerSec ...................................................................... 139 Figura 4.40. Opciones de configuracin de NetPerSec ...................................................... 140 Figura 4.41. Opciones de configuracin de pantalla de NetPerSec .................................... 140

xv

Figura 4.42. Men principal de Nagios 3 ........................................................................... 146 Figura 4.43. Grfica de ancho de banda obtenida mediante la herramienta de monitoreo . 148 Figura 5.1. Trayecto de referencia UNI a UNI para los objetivos QoS de la red (UIT, 2006) ............................................................................................................................................ 151 Figura 5.2. Grfica de frmula de cumplimiento de la SUTEL con k=0,5 ........................ 159 Figura 5.3. Grfica de frmula de cumplimiento de la SUTEL con k=50 ......................... 160

xvi

NDICE DE TABLAS
Tabla 2.1. Estndares requeridos por tecnologa (ARESEP, 2008)...................................... 36 Tabla 2.2. Parmetros de calidad de los servicios de transferencia de datos ........................ 38 Tabla 3.1. Mtricas fundamentales de NP (Davenhall & Leese, 2005)................................ 45 Tabla 3.2. Mtricas fundamentales para IP segn la ITU Y-1540 ....................................... 46 Tabla 3.3. Directrices para clases QoS IP (ITU, 2001) ........................................................ 47 Tabla 3.4. Clasificacin de servicios en una red NGN (Blandon & Daz, 2008) ................. 48 Tabla 3.5. Pruebas de benchmarking del RFC 2544 ......................................................... 51 Tabla 3.6. Parmetros principales de desempeo segn el Y.1564 (KPI) ............................ 57 Tabla 3.7. Herramientas complejas para la medicin de NP ................................................ 65 Tabla 4.1. Mtricas obtenidas con PING .............................................................................. 86 Tabla 4.2. Mtricas obtenidas con Traceroute ...................................................................... 87 Tabla 4.3. Mtricas obtenidas en prueba UDP de D-ITG ..................................................... 98 Tabla 4.4. Mtricas obtenidas en prueba Y.1564 de datos de 5 Mbps ............................... 123 Por su parte, la prueba de desempeo de servicio arroja los resultados globales obtenidos para los KPI; los cuales se resumen en la ........................................................................... 124 Tabla 4.5. Mtricas obtenidas en prueba Y.1564 de datos de 15 Mbps ............................. 125 Tabla 4.6. Resumen de los resultados obtenidos en las pruebas del Speedtest de Ookla ... 137 Tabla 4.7. Comparacin de las herramientas de desempeo para pruebas RFC 2544 y Y.1564................................................................................................................................. 144 Tabla 5.1. Umbral de retardo local permitido por la SUTEL (ARESEP, 2009) ................ 152 xvii

Tabla 5.2. Umbral de retardo internacional permitido por la SUTEL (ARESEP, 2009) ... 152 Tabla 5.3. Umbral de variacin en el retardo local permitido por la SUTEL (ARESEP, 2009) ................................................................................................................................... 154 Tabla 5.4. Umbral de variacin de retardo internacional permitido por la SUTEL (ARESEP, 2009) ................................................................................................................. 154 Tabla 5.5. Umbral de prdida de paquetes a nivel local permitido por la SUTEL (ARESEP, 2009) ................................................................................................................................... 155 Tabla 5.6. Umbral de prdida de paquetes a nivel internacional permitido por la SUTEL (ARESEP, 2009) ................................................................................................................. 156 En la Tabla 5.5 se encuentran los mbitos para el retardo a nivel local clasificado de acuerdo con la clase de calidad de servicio. De igual forma en la ..................................... 156 Tabla 5.7. Umbrales de throughput (ARESEP, 2009) .................................................... 157 Tabla 5.8. Comparacin de las herramientas de desempeo para verificar las mtricas solicitadas por la SUTEL .................................................................................................... 162

xviii

NOMENCLATURA
ACK CAIDA CBS CIR CPE DCE DTE DUT DWDM EBS EIR EPL ETSI EVC HFC HTTP Acknowledge Cooperative Association for Internet Data Analysis Committed Burst Size Committed Information Rate Customer Premises Equipment Data Communication Equipment Data Terminal Equipment Device Under Test Dense Wavelength Division Multiplexing Excess Burst Size Excess Information Rate Ethernet Private Line European Telecommunications Standards Institute Ethernet Virtual Connection Hybrid Fiber-Coaxial Hypertext Transfer Protocol
xix

IETF IP IS-IS ISO ISP ITU KPI LAN MAN MEF MIB MPLS NGN NP NPM OSI OWD QoS

Internet Engineering Task Force Internet Protocol Intermediate System to Intermediate System International Standard Organization Internet Service Provider International Telecommunication Union Key Performance Indicator Local Area Network Metropolitan Area Network Metro Ethernet Forum Management Information Base Multiprotocol Level Switching Next Generation Network Network Performance Network Performance Monitor Open System Interconnection One Way Delay Quality of Service
xx

RFC RTT RWIN SAC SCT SDH SLA SPT SUTEL TCP UDP UIT UNI VLAN WAN

Request for Comments Round Trip Time Receive Window Service Acceptance Criteria Service Configuration Test Synchronous Digital Hierarchy Service Level Agreement Service Performance Test Superintendencia de Telecomunicaciones Transmission Control Protocol User Datagram Protocol Unin Internacional de Telecomunicaciones User-Network Interface Virtual LAN Wide Area Network

xxi

RESUMEN
El presente proyecto puede dividirse en dos grandes reas. La primera se aboca a la investigacin terica de los aspectos fundamentales que rodean la medicin de desempeo de redes Ethernet y Metro Ethernet. Se parte de la revisin de las recomendaciones de la UIT Y.1540, Y.1541, Y.1564, G.1010, as como la normativa de la IETF RFC 2544 y RFC 1242 y la normativa de la ETSI EG 202 057-4. Una vez abarcados los conceptos tericos, se realiza una exploracin de la legislacin nacional relacionada con la regulacin de redes Ethernet y Metro Ethernet. El ente responsable a nivel nacional es la Superintendencia de Telecomunicaciones; por lo tanto se analizan los artculos relacionados con medicin de desempeo tanto de la Ley General de Telecomunicaciones como del Reglamento de Prestacin y Calidad de los Servicios. La segunda rea que alcanza el proyecto, se refiere a la implementacin de herramientas de medicin de desempeo. Para ello se estructura una topologa de pruebas configurando tres conmutadores Cisco 3750-ME, con puertos especficamente diseados para servicios de Metro Ethernet. Esta arquitectura emula un servicio EPL. Sobre dicha topologa se efectan pruebas con herramientas comerciales y no comerciales. El anlisis de sus atributos se lleva a cabo tomando como referencia una serie de rubros y criterios para la comparacin con las metodologas de pruebas Y.1564 y RFC

xxii

2544 y con las mtricas requeridas en el Captulo 7 del Reglamento de Prestacin y Calidad de los Servicios referente al servicio de transferencia de datos. Mediante los resultados de estas pruebas se logra concluir que las herramientas de medicin de desempeo disponibles (tanto comerciales como no comerciales) son capaces de suplir los requerimientos de evaluacin de las metodologas de pruebas Y.1564 y RFC 2544 as como las mediciones de las mtricas requeridas por la SUTEL para redes de transferencia de datos. Las plataformas comerciales proveen interfaces mucho ms amistosas, pero carecen de versatilidad para la generacin de las pruebas.

xxiii

1. CAPTULO 1: Introduccin
La desbordante trascendencia de las redes de computadores para el intercambio de informacin, as como la necesidad de implementar tcnicas y tecnologas que mejoren el rendimiento y la velocidad de la transmisin de datos, desembocan inevitablemente en la necesidad de desarrollar mecanismos de medicin de desempeo de redes que permitan determinar sus puntos dbiles y mejorar el aprovechamiento de su capacidad. Dada la invaluable necesidad de optimizar las redes de computadores a cualquier escala (redes locales, proveedores de servicios de Internet, transporte de datos, etc.) y la problemtica que implica prescindir de las tcnicas de medicin de desempeo y requerimientos de redes, se consider necesario investigar y evaluar las posibilidades actuales y desarrollar una serie de pruebas que permitan concluir cules son las mejores opciones para aumentar el rendimiento de redes Ethernet y Metro Ethernet. El presente proyecto centra sus esfuerzos en compilar y analizar los requerimientos bsicos para un buen desempeo de redes Ethernet y Metro Ethernet. Por lo tanto se revisan documentos importantes de entes internacionales como la MEF (de sus siglas en ingls Metro Ethernet Forum) y la UIT (de sus siglas Unin Internacional de Telecomunicaciones) y entes reguladores nacionales; as como aplicaciones para la medicin de desempeo de redes tomadas de los benchmarks y los RFC (de sus siglas en ingls Request For Comments) publicados hasta la actualidad. Una vez compilada la informacin, se efectan pruebas de medicin de desempeo en redes Ethernet y Metro Ethernet de un proveedor de servicios de Internet nacional de 1

modo que se pueda concluir en relacin con cules de los mtodos implementados o cul conjunto de mtodos son los ms apropiados para conocer el estado de la red y cumplir los requerimientos nacionales e internacionales.

1.1
1.1.1

Objetivos
Objetivo general Comparar cuantitativa y cualitativamente mtodos de medicin del desempeo de

redes de computadores Ethernet y Metro Ethernet. 1.1.2 Objetivos especficos Investigar los mtodos de medicin del desempeo de redes de computadores Ethernet y Metro Ethernet mediante la revisin de legislaciones, RFCs y benchmarks relacionados. Revisar las normas de regulacin nacional en relacin con la calidad de servicio en redes de computadores Ethernet y Metro Ethernet y los mtodos de medicin de desempeo que se solicitan para la comprobacin de dichos parmetros de servicio. Implementar varios mtodos de medicin de desempeo de redes de computadores Ethernet y Metro Ethernet en una red de un ISP nacional para la obtencin de datos cuantitativos y tablas comparativas. recomendaciones, normas,

1.2

Metodologa
Dada la naturaleza del tema y los objetivos planteados para el presente proyecto, es

necesario implementar una metodologa en dos sentidos. En primer plano se utiliza el mtodo analtico para tomar las generalidades de una red Ethernet y Metro Ethernet y diseccionarlas hasta llegar a las especificidades concernientes al estudio de su desempeo. De igual forma se proceder con el anlisis terico de los requerimientos de una red Ethernet y Metro Ethernet a travs de documentos de regulaciones nacionales e internacionales. Una vez entendidos los elementos particulares, se tendr una idea general de la cual se partir para aplicar el mtodo deductivo que admita concluir (mediante pruebas experimentales de los diferentes procedimientos de medicin de desempeo de redes) cules son los parmetros y herramientas especficas ptimas que permiten medir el desempeo de redes Ethernet y Metro Ethernet. En otras palabras, se utilizar un mtodo analtico enfocado a la teora y un mtodo deductivo enfocado a la experimentacin; evidentemente mediante la combinacin de ambas premisas ser posible emitir criterios vlidos y dar recomendaciones a la problemtica planteada.

CAPTULO 2: Desarrollo terico

El presente captulo consiste en una recopilacin de los aspectos tericos del

proyecto de investigacin que permitirn abordar el anlisis de los diferentes mtodos de medicin de desempeo de una red de computadores Ethernet y Metro Ethernet con una slida base conceptual y como punto de partida para emitir un criterio final. Es importante recordar que los alcances del presente proyecto de investigacin se limitaron a redes de datos de mejor esfuerzo basados en paquetes IP; dejndose de un lado servicios como telefona, televisin, radiodifusin, etc. Esta limitacin se debe a que la contemplacin de todos estos servicios involucrara un escalamiento prcticamente inalcanzable en la investigacin.

2.1

Conceptos preliminares
Antes de adentrarse en el estudio terico relacionado con los parmetros

fundamentales para la medicin del desempeo de redes de computadores, es importante conocer una serie de conceptos bsicos. 2.1.1 Modelo de referencia OSI El primer concepto fundamental sobre el cual se cimienta toda la teora del desempeo de redes tiene que ver con el modelo de referencia principal para la comunicacin de dos dispositivos en una red.

Para solventar las necesidades tecnolgicas en bsqueda de un modelo de comunicacin y la independencia en relacin con el desarrollo de hardware para el transporte fsico de los datos, la ISO (por sus siglas en ingls International Standard Organization) estructur el modelo OSI (por sus siglas en ingls Open System Interconnection).

Figura 2.1. Esquema general del modelo de referencia OSI (Tanenbaum, 2003) La Figura 2.1 muestra el esquema general del modelo OSI. Cada capa o nivel del modelo ofrece un servicio (conjunto de operaciones) a su capa o nivel superior; a su vez, 6

cada capa o nivel del modelo se comunica mediante un protocolo que es un conjunto de normas que rigen el significado y la interpretacin de un conjunto de datos de un determinado nivel. nicamente el nivel fsico se comunica directamente, los dems niveles lo hacen virtualmente. 2.1.2 Modelo de referencia TCP/IP Este modelo constituye la base de toda red de rea amplia (especialmente la utilizacin de sus protocolos) incluyendo el Internet. Se diferencia del modelo OSI porque se eliminaron ciertos niveles y porque se definieron muy bien los protocolos implementados en cada capa.

Figura 2.2. Modelo de referencia TCP/IP (Tanenbaum, 2003) En la Figura 2.2 se muestra el esquema general de los niveles involucrados en el modelo TCP/IP. Se debe notar que se eliminaron las capas de sesin y presentacin en relacin con el modelo OSI, adems, se defini una sola capa fsica llamada Host a red en 7

la cual no se especific la tecnologa de hardware utilizada de modo que el modelo no estuviese supeditado al desarrollo tecnolgico. En el nivel de transporte se definieron los protocolos TCP (de sus siglas en ingls Transmission Control Protocol) y UDP (de sus siglas en ingls User Datagram Protocol) y en la de interred se defini el conocido protocolo IP (de sus siglas en ingls Internet Protocol), que es hoy en da el protocolo que por excelencia utiliza Internet para la transmisin de la informacin. 2.1.3 Telecomunicaciones Se define el trmino segn el expuesto en la Ley General de Telecomunicaciones de Costa Rica en su Artculo 6. Entonces, se entender por telecomunicaciones toda transmisin, emisin y/o recepcin de signos, seales, escritos, datos, imgenes, sonidos o informacin de cualquier naturaleza por hilo, conductores, ondas radioelctricas, medios pticos u otros sistemas electromagnticos. (ARESEP, 2008) 2.1.4 Red de telecomunicaciones Se define el trmino segn lo expuesto en la Ley General de Telecomunicaciones de Costa Rica en su Artculo 6. Se entender por red de telecomunicaciones sistemas de transmisin y dems recursos que permiten la transmisin de seales entre puntos de terminacin definidos mediante cables, ondas hertzianas, medios pticos u otros medios radioelctricos, con inclusin de las redes satelitales, redes terrestres fijas (de conmutacin 8

de circuitos o de paquetes, incluida Internet) y mviles, sistemas de tendido elctrico, utilizadas para la transmisin de seales, redes utilizadas para la radiodifusin sonora y televisiva y redes de televisin por cable, con independencia del tipo de informacin transportada. (ARESEP, 2008) Los alcances del anlisis de desempeo de una red en el presente proyecto de investigacin, se limitan a redes de datos sobre Ethernet y Metro Ethernet, con aplicacin de protocolos de transporte como MPLS que operan entre la capa de enlace de datos y la capa de red del modelo OSI y protocolos de enrutamiento como IS-IS. 2.1.5 Red de computadores Se entender como red de computadores un conjunto de computadores autnomos interconectados. Se dice que dos computadores estn interconectados si pueden intercambiar informacin. (Tanenbaum, 2003) Ahora bien, existen muchas formas de clasificar las redes de computadores; por ejemplo, segn su escala o su tipo de transmisin. En relacin con la escala, se enfocar el estudio a redes WAN (red de rea amplia) y LAN (red de rea local). Una red WAN (de sus siglas en ingls Wide Area Network) normalmente comprende una gran rea geogrfica (un pas por ejemplo). Est formada por los hosts (mquinas diseadas para ejecutar aplicaciones de usuario, como una computadora de escritorio) y por la subred de comunicacin que es la encargada de interconectarlos.

Dicha subred de comunicacin a su vez abarca las lneas de transmisin (fibra ptica, cable coaxial, medios inalmbricos, etc.) y los dispositivos de conmutacin responsables de tomar decisiones para trazar una ruta de un mensaje entre un host y otro. La Figura 2.3 muestra la topologa clsica de una red WAN que incluye muchas veces pequeas redes LAN (red de rea local) donde se conectan los hosts del usuario final. Esta topologa emula una red general de un proveedor de servicios de Internet (ISP).

Figura 2.3. Topologa clsica de una red WAN (Tanenbaum, 2003) Por lo tanto, se tomar como punto de partida para la medida del desempeo, redes cuyo transporte se base en HFC (hbrido de fibra ptica y cable coaxial), dispositivos de conmutacin y redes de rea local (LAN) para la conexin de los usuarios finales. Para el servicio de redes de rea local se emplean redes Ethernet y para servicios de conectividad de rea amplia se utiliza Metro Ethernet. En relacin con el tipo de transmisin, se toman como base las redes de computadores de punto a punto. En una red de punto a punto, la comunicacin se realiza de host a host pasando la informacin que se intercambia de uno a otro a travs de una 10

subred o un conjunto de mquinas intermedias que deciden cmo y por dnde transportar el mensaje. Por ltimo, se delimita el anlisis del desempeo de redes de computadores a redes de datos de mejor esfuerzo. Es decir, una red de datos de mejor esfuerzo describe un servicio de red en el que no se proporciona ninguna garanta de que los datos son entregados, o bien, en la que el usuario no tiene un nivel de calidad de servicio (QoS) o una cierta prioridad en relacin con el otro trfico que ocupa el ancho de banda de la red. En otras palabras, no se har un anlisis especial para redes que involucren parmetros de calidad de servicio (QoS) especficos como en el caso de la telefona IP. 2.1.6 Red de computadores Ethernet Las redes Ethernet fueron concebidas en Hawaii a principios de la dcada de 1970. Sus orgenes se pueden atribuir al esfuerzo realizado por Norman Abramson (investigador de la Universidad de Hawaii), David Boggs (empleado de Xerox) y Bob Metcalfe (empleado de Xerox) para desarrollar un sistema de red de rea local capaz de intercomunicar computadores personales. Las especificaciones de la red Ethernet de Xerox fueron tan bien acogidas que DEC, Intel y Xerox desarrollaron un estndar para 10 Mbps (llamado DIX). DIX fue tomado como referencia para crear el estndar 802.3 de la IEEE. El estndar IEEE 802.3 define Ethernet para redes de rea local, redes de acceso y redes metropolitanas. Se brinda el detalle para velocidades de operacin seleccionadas y 11

utiliza las especificaciones del Control de Acceso al Medio (MAC) y de la Base de Informacin de Gestin (MIB). El protocolo MAC con Acceso Mltiple con Deteccin de Portadora con Deteccin de Colisin (CSMA/CD) especifica la operacin del medio compartido (semidplex) as como la operacin de dplex total. (IEEE, 2008) Bsicamente en el estndar IEEE 802.3 se definen las caractersticas de conexin (cableado) y de sealizacin a nivel fsico, as como el formato de las tramas propias del nivel de enlace de datos en el modelo OSI. En la Figura 2.4 se muestra la relacin entre el estndar IEEE 802.3 y el modelo de referencia OSI. Ntese que se tienen dos subcapas para la capa de enlace y que la implementacin fsica variar segn la velocidad de operacin.

Figura 2.4. Relacin del estndar IEEE 802.3 con el modelo de referencia OSI (IEEE, 2008) Las redes de rea local Ethernet estn conformadas por nodos de red y medios interconectados. Los nodos de red se pueden clasificar de dos maneras: 12

a. DTE (de sus siglas en ingls Data Terminal Equipment): son los dispositivos de destino u origen de las tramas de datos. Por ejemplo: un computador personal, un servidor de archivos, etc. b. DCE (de sus siglas en ingls Data Communication Equipment): son los dispositivos intermedios que reciben y redireccionan las tramas a travs de la red. Por ejemplo: repetidores, enrutadores, conmutadores, etc. La subcapa de enlace de datos llamada MAC-client puede ser un LLC (de sus siglas en ingls Logical Link Control) si se trata de un DTE; o bien, un puente si la unidad es un DCE. En el caso del LLC, provee una interfaz entre el MAC Ethernet y los protocolos de nivel superior del modelo que se est utilizando. El puente por su parte nicamente brindar una interfaz LAN a LAN usando el mismo protocolo (Ethernet) o uno distinto (Ethernet a Token Ring por ejemplo). Como ya se mencion, los sistemas de comunicacin basados en Ethernet dividen el flujo de datos en tramas individuales; la subcapa MAC del nivel de enlace de datos es la encargada de ensamblar dichas tramas. El formato de la trama definido en el estndar IEEE 802.3 se muestra en la Figura 2.5 y corresponde especficamente al protocolo de subcapa MAC de Ethernet, por lo que estrictamente se debera llamar trama MAC. En ella se pueden distinguir distintos grupos de octetos destinados a definir varios parmetros de la trama; a saber: Prembulo (7 octetos): corresponde a octetos con la secuencia de bits 10101010 que permiten que el reloj del emisor y el receptor se sincronicen. 13

Obsrvese que estrictamente un paquete MAC encapsula una trama MAC y que el prembulo y el SFD pertenecen al paquete MAC y no a la trama MAC. SFD (1 octeto): el SFD (por sus siglas en ingls Start Frame Delimiter) corresponde a la secuencia de bits 10101011, se ubica inmediatamente despus del patrn de prembulo y define el inicio de la trama MAC justo despus de su secuencia. Direccin de destino (6 octetos): especifica la direccin (unicast) o las direcciones (multicast o broadcast) de destino de la trama MAC. Direccin de origen (6 octetos): especifica la direccin en la que se origin la trama MAC. Longitud/tipo (2 octetos): si el valor de este campo es menor o igual a 1500 decimal, entonces indica el nmero de octetos contenidos en el siguiente espacio destinado a los datos del cliente MAC. Si el nmero es mayor o igual a 1536, entonces indica el tipo de protocolo del cliente MAC. Datos del cliente MAC: son varios octetos con la informacin que se pretende transmitir procedente de las capas superiores de la arquitectura de red que se est utilizando. Como mnimo una implementacin del estndar IEEE 802.3 debe soportar uno de los tres siguientes tamaos mximos para este campo de la trama: trama bsica (1500 octetos), tramas etiquetadas Q (1504 octetos) o tramas sobre (1982 octetos). 14

Relleno o Pad: dado que la implementacin correcta del protocolo CSMA/CD requiere un tamao mnimo de la trama MAC, entonces se colocan los octetos necesarios con informacin intil para completar esta longitud mnima.

FCS (4 octetos): el FCS (por sus siglas en ingls Frame Check Sequence) es utilizado por los algoritmos de recepcin y transmisin para generar un cdigo de chequeo cclico que permita la deteccin de errores de las secciones de direccin destino, direccin origen, longitud o tipo y datos del cliente MAC.

Figura 2.5. Estructura de una trama Ethernet segn el estndar IEEE 802.3 (IEEE, 2008) Por ltimo, es importante conocer las caractersticas bsicas del cableado estandarizado para las diferentes implementaciones fsicas del IEEE 802.3. Dichas 15

caractersticas se resumen en la Figura 2.6. Existen muchas especificaciones ms; para distintas distancias y velocidades de operacin; el nmero ubicado antes de la palabra base se refiere a la tasa de transferencia soportada.

Figura 2.6. Tipos ms utilizados de cableado Ethernet (Tanenbaum, 2003) 2.1.6.1 Protocolo IEEE 802.1Q Anteriormente se destacaron las caractersticas de una trama Ethernet en la subcapa MAC del nivel de enlace de datos. En el espacio dedicado a los datos se especific un tipo de datos de 1504 octetos llamado trama etiquetada Q, la cual posee 4 octetos ms que los datos de una trama bsica. Esto es porque en este tipo de tramas se incluye un encabezado 802.1Q.

Figura 2.7. Trama Ethernet con encabezado 802.1Q (IEEE, 2008) En la Figura 2.7 se muestra una trama Ethernet que incluye los 4 octetos del encabezado 802.1Q. Este estndar es el que permite la implementacin de LANs virtuales 16

(llamadas VLANs) en una red Ethernet y su consiguiente manejo mediante puentes y conmutadores. Se utiliza un sistema de etiquetas utilizando los mencionados 4 octetos. La aplicacin de este estndar permite que varias redes compartan con limpieza un mismo medio fsico. Se hace nfasis especial al estndar 802.1Q debido a que este mtodo es utilizado para brindar varios servicios mediante redes Metro Ethernet. 2.1.7 Red de computadores Metro Ethernet Una red Metro Ethernet es una red de computadores que cubre un rea metropolitana (MAN) o un rea amplia (WAN) y cuya estructura se basa en el estndar Ethernet. La idea principal de su implementacin es poder brindar servicios de conectividad de nivel 2 mediante la utilizacin de UNIs (de sus siglas en ingls User Network Interface) que segn el MEF (de sus siglas en ingls Metro Ethernet Forum) son un punto de referencia bidireccional para la entrega del servicio Ethernet. En otras palabras, una red Metro Ethernet es cualquier red destinada a suministrar servicios de Metro Ethernet; en general el trmino se aplica a redes de operador. (Schmidberg, 2009). Para la determinacin de los estndares y la evolucin del Metro Ethernet se cre en el 2001 el MEF (de sus siglas en ingls Metro Ethernet Forum). Una red Metro Ethernet comn de un proveedor de servicios consiste en un conjunto de conmutadores (de nivel de enlace de datos y nivel de red) y enrutadores conectados mediante fibra ptica. Adems, la estructura jerrquica de la red se suele dividir 17

en ncleo, transporte y acceso, siendo el ncleo formado por una columna IP/MPLS por ejemplo. El nivel de transporte o distribucin puede darse utilizando Ethernet puro (para pequea escala), Ethernet sobre SDH, Ethernet sobre MPLS o Ethernet sobre DWDM. El anlisis de desempeo para la presente investigacin se efectuar para redes basadas en MPLS.

Figura 2.8. Servicio EPL (Ethernet Private Line) sobre una red Metro Ethernet En la Figura 2.8 se muestra un esquema de un servicio que implementa una red Metro Ethernet. En este caso se genera una lnea Ethernet virtual; es decir, la sede central se conectar con la oficina 1 como si se tratara de una conexin directa. 2.1.8 Desempeo de redes, calidad de servicio y desempeo de servicio Actualmente el concepto de calidad de servicio y desempeo de red suelen confundirse; o bien, utilizarse inadecuadamente. Saber discriminar entre una definicin y

18

otra es de suma importancia, pues a pesar de que se relacionan no son lo mismo y se hace trascendental enmarcar la lnea que une ambos conceptos. 2.1.8.1 Calidad de servicio (QoS) En la norma ISO 8402 se define calidad como todas las caractersticas de una entidad que inciden en su capacidad de satisfacer las necesidades indicadas e implcitas. (ITU, 2001) Adems, en la recomendacin G.1000 de la UIT (de sus siglas Unidad Internacional de Telecomunicaciones) se define calidad de servicio (QoS de sus siglas en ingls Quality of Services) como: efecto global de la calidad de funcionamiento de un servicio, que determina el grado de satisfaccin de los usuarios. (ITU, 2001) Amn de la definicin genrica de calidad de servicio, se deben abarcar cuatro definiciones particulares: 1. Requerimientos de calidad de servicio del usuario o cliente: se refiere al nivel de calidad de un servicio particular requerido o preferido por el usuario final o cliente. Es prescindible el uso de lenguaje tcnico para expresar el nivel de calidad por parte del cliente. Ntese que es un punto de vista totalmente apartado de criterios especficos de la implementacin tecnolgica; ms bien es una visin particular y subjetiva. 2. Calidad de servicio ofrecida por un proveedor: se refiere al nivel de calidad que el proveedor espera ofrecer al usuario final. Se utilizan parmetros de calidad de 19

servicio para medir dicha expectativa; dichos parmetros deben ser interpretables por clientes que no necesariamente poseen conocimientos tcnicos. Por ejemplo, ofrecer telefona con una disponibilidad anual del 99,9% y 20 minutos mximos de duracin por avera. 3. Calidad de servicio lograda por el proveedor: se refiere al nivel de calidad lograda por el proveedor. Se expresa mediante parmetros que intentan alcanzar las expectativas del inciso anterior. La recoleccin de la informacin se suele hacer peridicamente; por ejemplo, cada tres meses. 4. Calidad de servicio percibida por el cliente o usuario final: se refiere al nivel de calidad experimentada por el cliente. Se debe utilizar terminologa tcnica cuando el cliente tenga el suficiente conocimiento para hacerlo. Ntese que algunas de las definiciones adyacentes al concepto genrico de calidad de servicio requieren una percepcin subjetiva del cliente que no necesariamente se respalda en conocimientos tcnicos; es decir, la calidad de servicio tambin se debe medir mediante encuestas que no necesariamente involucren parmetros tcnicos. 2.1.8.2 Desempeo de red El desempeo de red o calidad de funcionamiento de la red (NP de sus siglas en ingls Network Performance) es definido por la recomendacin E.800 de la UIT como: la habilidad de una red o una porcin de red para proveer funciones relativas a comunicaciones entre usuarios. (UIT, 1994) 20

Se refiere al desempeo de los elementos de conexin o de la concatenacin de los elementos de conexin empleados para ofrecer un servicio. Dicho desempeo es definido y medido en trminos de parmetros que tienen un significado para la red y el proveedor de servicios y que a su vez son utilizados para el diseo del sistema, su configuracin, operacin y mantenimiento. Cabe rescatar que el desempeo de una red es independiente del desempeo del dispositivo final o de las acciones del cliente o suscriptor. El Captulo 4 de la recomendacin E.800 de la UIT define la mayora de los parmetros involucrados con la calidad del funcionamiento de una red o desempeo de red (NP). Divide este captulo segn los conceptos que define en: aptitud para cursar trfico, seguridad de funcionamiento, transmisin y tarificacin, y tasacin. Estos parmetros cuantitativos se estudiarn en secciones posteriores del presente proyecto de investigacin. 2.1.8.3 Desempeo de servicio Segn el ETR 003 (por sus siglas en ingls ETSI Technical Report) de la ETSI (por sus siglas en ingls European Telecommunications Standards Institute), desempeo de servicio se refiere al desempeo de un servicio de telecomunicaciones expresado en parmetros aplicables a ese servicio y sus respectivos valores. Estos parmetros se aplicarn a las especificaciones tcnicas y no tcnicas de ese servicio. (ETSI, 1994)

21

Cada servicio debe tener su propio conjunto de parmetros de desempeo. Dicho desempeo se expresar en un lenguaje ms formal pero sin dejar a un lado la factibilidad de entendimiento para el cliente o suscriptor. Los parmetros de servicio incluidos en el desempeo de servicio componen parte de la calidad de servicio ofrecida por el proveedor. Un ejemplo de un parmetro de desempeo de servicio sera que la prdida de servicio requerir x horas en el 90% de los casos. (ETSI, 1994) 2.1.8.4 Relacin entre desempeo de red, desempeo de servicio y calidad de servicio La Figura 2.9 muestra un esquema en donde se interrelacionan los conceptos de desempeo de red, desempeo de servicio y calidad de servicio. Las lneas punteadas representan retroalimentacin y las lneas continuas representan actividad y flujo.

Figura 2.9. Diagrama de interrelacin de desempeo de red, desempeo de servicio y calidad de servicio 22

Ntese entonces que el proveedor de servicios traslada los requerimientos de calidad de servicio en parmetros de desempeo de red y asigna objetivos para los valores del desempeo de la red. Ahora bien, es importante entender que el concepto de calidad de servicio involucra criterios subjetivos del usuario final que no necesariamente se pueden traducir en criterios relacionados con la red. Es aqu donde se ubica una de las mayores diferencias y es uno de los grandes focos de confusin que existe en el mundo de las redes de telecomunicaciones. La Figura 2.10 muestra la relacin expuesta en el prrafo anterior. Obsrvese que slo los criterios de QoS relacionados con la red son los que provocan una accin directa en el mapeo de parmetros del desempeo de redes.

Figura 2.10. Relacin entre QoS y desempeo de red De esta relacin se puede concluir que desde el punto de vista del proveedor, la calidad de funcionamiento de la red es un concepto con respecto al cual se definen, miden y 23

controlan las caractersticas de la red para lograr un nivel satisfactorio de calidad de servicio. (UIT, 1994)

Figura 2.11. Diagrama de relaciones conceptuales de QoS y NP (ETSI, 1994)

24

La Figura 2.11 muestra la relacin de los conceptos que envuelve la calidad de servicio con los conceptos que envuelve la calidad del funcionamiento de una red o el desempeo de red. Es importante recalcar que cada concepto est ligado al situado por encima de l en el sentido de que lo puede afectar individual o colectivamente. Obsrvese adems de la Figura 2.11 que la calidad de servicio involucra definiciones intrnsecamente no cuantitativas, como los aspectos relacionados con la facilidad de utilizacin.

2.2

Sistema de regulacin de las telecomunicaciones en Costa Rica

Antes de comprender el sistema de regulacin de servicios en Costa Rica, es

necesario citar algunos hitos de su historia. Entre 1870 y 1928 la regulacin de los servicios pblicos en Costa Rica era prcticamente inexistente; se otorgaron gran cantidad de concesiones a empresas extranjeras que culminaron en el establecimiento de acueductos, electrificacin, alumbrado, entre otros servicios. A finales de la dcada de 1920, la Liga Cvica junto con el ingeniero Max Koberg Bolandi presentaron una propuesta al gobierno de un proyecto de ley para nacionalizar los servicios hidroelctricos en Costa Rica. Es as como se emiti la ley que cre el Servicio Nacional de Electricidad (SNE), el 31 de julio de 1928, bajo la filosofa de servicio al costo y empez a controlar a las compaas elctricas privadas para que mantuvieran tarifas bajas para los abonados. (ARESEP, 2011) 25

En la dcada de 1990, se pudo estructurar un concepto de regulacin ms afn con las necesidades del pas y que culmin con la concrecin de la Ley 7593 (Ley de la Autoridad Reguladora de los Servicios Pblicos) mediante la cual se transform al SNE en la Autoridad Reguladora de los Servicios Pblicos de Costa Rica (ARESEP), especficamente el 9 de agosto de 1996. Segn lo enuncia la Ley 7593 en su primer artculo: transfrmase el Servicio Nacional de Electricidad en una institucin autnoma denominada Autoridad Reguladora de los Servicios Pblicos, en adelante y para los efectos de esta Ley llamada Autoridad Reguladora. La Autoridad Reguladora tendr personalidad jurdica y patrimonio propio, as como autonoma tcnica y administrativa. Se regir por las disposiciones establecidas en esta Ley, sus Reglamentos y las leyes que la complementen. (ARESEP, 2008) Con la aprobacin el 30 de junio de 2008 de la Ley General de las Telecomunicaciones se pas de un mercado de telecomunicaciones con un modelo de monopolio regulado, a uno con un modelo de apertura y convergencia tecnolgica. De ah que fue forzoso efectuar modificaciones en el 2008 a la Ley 7593 redactada en 1996. Una de las modificaciones fundamentales de la Ley 7593 fue la creacin de la Superintendencia de Telecomunicaciones (SUTEL), as como la definicin del marco normativo de operacin y definicin de las relaciones con otros rganos. Dicha creacin se estableci de acuerdo con los objetivos estipulados en el Artculo 2 de la Ley 8660 para el fortalecimiento y modernizacin de las entidades pblicas del sector telecomunicaciones.

26

2.2.1

Superintendencia de Telecomunicaciones De acuerdo al Artculo 59 de la Ley de la Autoridad Reguladora de los Servicios

Pblicos, corresponde a la Superintendencia de Telecomunicaciones (SUTEL) regular, aplicar, vigilar y controlar el ordenamiento jurdico de las telecomunicaciones; para ello se regir por lo dispuesto en esa Ley y en las dems disposiciones legales y reglamentarias que resulten aplicables. (ARESEP, 2008) En este mismo artculo se aade: la SUTEL es un rgano de desconcentracin mxima adscrito a la Autoridad Reguladora de los Servicios Pblicos; tendr personalidad jurdica instrumental propia, para administrar el Fondo Nacional de Telecomunicaciones, realizar la actividad contractual, administrar sus recursos y su presupuesto, as como para suscribir los contratos y convenios que requiera para el cumplimiento de sus funciones. (ARESEP, 2008) Las obligaciones fundamentales de la Superintendencia de Telecomunicaciones se describen en el Artculo 60 de la Ley 7593. Entre las principales funciones se encuentran administrar el Fondo Nacional de Telecomunicaciones (FONATEL), procurar el acatamiento de los derechos y deberes de los operadores de redes y proveedores de servicios de telecomunicaciones y pactar y avalar estndares de calidad de las redes y los servicios de telecomunicaciones.

27

Debe subrayarse que la ltima funcin descrita, involucra ciertos parmetros o requerimientos mnimos en relacin con el desempeo de la red; que de hecho son establecidos por la SUTEL en su Reglamento de Prestacin y Calidad de Servicio. Otra funcin importante y que se relaciona con la necesidad de que los proveedores de servicio posean un procedimiento correcto para la obtencin de las mediciones de los parmetros del desempeo de la red, es que la SUTEL establece y administra el Registro Nacional de Telecomunicaciones en donde especficamente se deben inscribir segn el Artculo 80 de la Ley de la Autoridad Reguladora de los Servicios Pblicos en su inciso h: las normas y los estndares de calidad de los servicios de telecomunicaciones, as como los resultados de la supervisin y verificacin de su cumplimiento. (ARESEP, 2008) 2.2.2 Ley General de Telecomunicaciones (8642) La aprobacin de la Ley General de Telecomunicaciones el 30 de junio de 2008, provoc la modificacin del modelo de telecomunicaciones de un modelo de monopolio regulado a uno de apertura y convergencia tecnolgica tal y como se mencion anteriormente. En esta Ley se establecen los rangos y mtodos de regulacin de las telecomunicaciones, que a su vez implican la utilizacin de las redes y la prestacin de los servicios. El alcance de la Ley es aplicable a todo operador de redes o prestador de servicios de telecomunicaciones que se originen, terminen o transiten por el territorio nacional. 28

Segn el Artculo 6, los trminos tcnicos referidos y los requeridos para el desarrollo de la Ley son definidos por la SUTEL. Es decir, todos los parmetros de NP sern especificados por la SUTEL tambin. 2.2.2.1 Artculos relacionados con la medicin de desempeo de red (NP) En el marco del estudio de las herramientas disponibles para la medicin del desempeo de red (NP) es imprescindible conocer los lmites establecidos por la ley para la inspeccin de paquetes por parte de un proveedor de servicios (lo cual permitira mejorar parmetros del NP); o bien, las infracciones impuestas en caso de incumplir algn requerimiento de NP. Recurdese que el presente proyecto de investigacin abarca redes WAN. A continuacin se exponen algunos artculos importantes de la Ley General de Telecomunicaciones: Artculo 42 (privacidad de las comunicaciones y proteccin de datos personales): Los operadores de redes pblicas y proveedores de servicios de telecomunicaciones disponibles al pblico, debern garantizar el secreto de las comunicaciones, el derecho a la intimidad y la proteccin de los datos de carcter personal de los abonados y usuarios finales, mediante la implementacin de los sistemas y las medidas tcnicas y administrativas necesarias. (ARESEP, 2008)

29

Slo mediante una autorizacin judicial las comunicaciones o los datos transferidos pueden ser intervenidos. En otras palabras los proveedores de servicios de datos a travs de redes WAN deben procurar evitar la utilizacin de Inspectores Profundos de Paquetes (o DPI de sus siglas en ingls Deep Packet Inspection) para manipular la informacin contenida en los paquetes transmitidos por su red; ya que eso violentara el derecho a la intimidad de los suscriptores. Artculo 65 (potestad sancionatoria): sin perjuicio de la responsabilidad penal o civil, a la SUTEL le corresponde conocer y sancionar las infracciones administrativas en que incurran los operadores o proveedores y tambin los que exploten redes de telecomunicaciones o presten servicios de telecomunicaciones de manera ilegtima. (ARESEP, 2008). En otras palabras, la SUTEL es el ente regulador encargado de sancionar cualquier falta en la que incurra un proveedor de servicios. Esto es muy importante, ya que un correcto estudio del NP puede significar un mejoramiento de la calidad de servicio y evitar alguna sancin. Artculo 67 (clases de infracciones): las infracciones aplicables en telecomunicaciones se clasifican en graves o muy graves. Se considera una leccin muy grave negar, ocultar o falsear informacin que de acuerdo a la Ley solicite la SUTEL; esta informacin incluye datos tcnicos de NP, por lo que la SUTEL evala el NP de las redes nacionales. 30

Adems, es una falta grave incumplir las normas tcnicas aplicables segn la Ley; dichas normas tambin involucran parmetros tcnicos de NP. Artculo 77 (reglamentacin de ley): en este artculo se enuncian los reglamentos aplicables a la Ley General de Telecomunicaciones. Especficamente se seala un reglamento donde se exponen parmetros tcnicos de NP llamado Reglamento de prestacin y calidad de servicios. 2.2.3 Reglamento de prestacin y calidad de los servicios Como parte de las necesidades implicadas en la Ley General de

Telecomunicaciones y la Ley de la Autoridad Reguladora de los Servicios Pblicos, se cre el Reglamento de Prestacin y Calidad de los Servicios como un reglamento aplicable a la ley y sobre el cual se constituyen los parmetros que utilizar la SUTEL para evaluar las condiciones de calidad, cantidad, oportunidad, continuidad y confiabilidad necesarias para la prestacin de los servicios de telecomunicaciones. (ARESEP, 2009) Adems, tal y como se enuncia en el Artculo 2 del Reglamento las disposiciones respecto a la regulacin de las condiciones de la calidad con que se brindan los servicios de telecomunicaciones disponibles al pblico previstas en la Ley General de

Telecomunicaciones (Ley 8642) y en la Ley de la Autoridad Reguladora de los Servicios Pblicos (Ley 7593) y desarrolladas en este reglamento son irrenunciables y de aplicacin obligatoria sobre cualesquiera otras leyes, reglamentos, costumbres, prcticas, usos o estipulaciones contractuales en contrario. (ARESEP, 2009) 31

En otras palabras, los criterios de NP descritos en el Reglamento, son ineludibles y deben ser cumplidos a cabalidad, de otro modo se podr estar sometido a las sanciones establecidas en la Ley 8642. 2.2.3.1 Artculos relacionados con la medicin de desempeo de red (NP) Debido a que el Reglamento de la Prestacin y la Calidad del Servicio expone la mayora de los criterios tcnicos relacionados con el NP, es necesario recalcar los artculos ms importantes contenidos en l. En el siguiente captulo se relacionarn estos parmetros con las herramientas de medicin de NP disponibles para el anlisis y la comparacin final que requiere el presente proyecto de investigacin. Artculo 4 (calidad de servicio): en este artculo se define el trmino calidad de servicio tal y como se expresa en la norma E.800 de la UIT: efecto global de las caractersticas de servicio que determinan el grado de satisfaccin de un usuario. (ITU, 1994) Adems, basndose en la norma E.800 y la recomendacin G.1010 as como la norma ETSI EG 201 769, se definen los parmetros, los indicadores y las formas de medicin y evaluacin como: o Servicio desde el punto de vista del suscriptor. o Efectos desde el punto de vista des suscriptor, sin exponer la causa del problema. o Independencia de tecnologas y arquitecturas de la red. 32

o Aplicacin de la medicin objetiva o subjetivamente en el sitio de acceso al servicio. o Una comparacin simple con los parmetros de NP de la red. Artculo 10 (establecimiento de parmetros de calidad): la SUTEL ser la encargada de establecer los estndares mnimos de calidad de las redes y servicios de telecomunicaciones disponibles. Cada parmetro que se defina estar conformado por un indicador que tendr un umbral de cumplimiento y sus caractersticas de medicin y evaluacin. A su vez, cada parmetro contendr un peso relativo en relacin con otros parmetros que al final constituirn lo que se considerar como el indicativo absoluto de calidad. Artculo 11 (parmetros de eficiencia del servicio) y Artculo 12 (parmetros tcnicos del servicio): los parmetros de eficiencia del servicio se refieren a la presteza con que se atiende un requerimiento de un suscriptor del servicio (involucra accin del Centro de Contacto y del Centro de Operaciones de Red); estos parmetros no se relacionan con el NP. Por su parte, los parmetros tcnicos del servicio son los relacionados con la cuantificacin de las condiciones de calidad de la red; es decir, son los que se relacionan directamente con el NP. Estos criterios se ilustraron en la Figura 2.10. Artculo 17 (informacin sobre parmetros de calidad): se especifica la obligacin de los proveedores y operadores de redes de proporcionar peridicamente a la SUTEL los resultados de las mediciones de los 33

parmetros de calidad de servicio (que incluyen los parmetros de NP) establecidos en el reglamento. La SUTEL tambin podr requerir la informacin de cualquier parmetro cuando lo considere necesario. Actualmente la SUTEL solicita un informe trimestral, en un formato de tablas dividido por secciones en un archivo tipo EXCEL que se puede descargar de su sitio en Internet. Artculo 20 (resoluciones de condiciones particulares de medicin de los parmetros de calidad de servicio): la SUTEL tiene la potestad de establecer los mtodos para la obtencin de los parmetros; basados en la gama de herramientas disponibles que pretende estudiar el presente proyecto de investigacin. Es responsabilidad del proveedor u operador del servicio, llevar un registro mensual para cada uno de los parmetros que solicita la SUTEL. Los indicadores tcnicos podrn ser obtenidos mediante la informacin registrada por programas informticos; o bien por los registros de los dispositivos involucrados en el transporte de la informacin. Si se instalan dispositivos externos para la medicin de parmetros, debe comunicarse a la SUTEL previo a la colocacin de dicho dispositivo para su aprobacin. Otro aspecto muy importante es que todas las mediciones de NP deben efectuarse en la hora cargada media, que corresponde a la hora de mayor trfico en la red. 34

A su vez, la SUTEL tiene la potestad de efectuar sus propias mediciones de NP en la red de cualquier proveedor u operador de servicios. Artculo 25 (disponibilidad de equipos de prueba y registros de parmetros de calidad): el presente artculo constituye uno de los ejes de la problemtica que justifica el desarrollo del presente proyecto de investigacin; en relacin con conocer las herramientas disponibles para la evaluacin de los parmetros de NP en redes WAN basadas en Metro Ethernet y Ethernet sobre MPLS. Todos los operadores o proveedores dispondrn mediante programas informticos, equipos de medicin o gestin externos a la red o en los centros de averas del operador, lo necesario para medir, registrar y almacenar, de acuerdo con lo establecido por la SUTEL, cada uno de los parmetros de calidad dispuestos en el presente reglamento o que posteriormente sean publicados por el Ente Regulador. (ARESEP, 2009) Artculo 29 (parmetros de la red): en este artculo se definen las especificaciones o estndares internacionales afines a cada tecnologa aplicada. En la Tabla 2.1 se muestra una tabla con los estndares que deben cumplirse segn la tecnologa aplicada.

35

Tabla 2.1. Estndares requeridos por tecnologa (ARESEP, 2008)

Tecnologa ADSL ADSL2 ADSL2+ HDSL RDSI (ISDN, ISDL) BRI y PRI SHDSL/G-HDSL VDSL VDSL2 Estndar UIT-T G992.1, G992.2 y ANSI TI.413.2 UIT-T G992.3 y G992.4 UIT-T G992.5 UIT-T G991.1, ANSI T1.418, ETSI ETR 152
UIT-T I.430, UIT-T I.431, UIT-T Q.931 ETSI ETS 300 012-1, ETSI ETS 300 102 UIT-T G991.2, ANSI T1E1.4/2001-174, ETSI TS 101524 UIT-T G993.1 UIT-T G993.2 UIT-T J.110, UIT-T J.111, UIT-T J.112, UIT-T J.122, UIT-T J.124, UIT-T J.125, UIT-T J.126, UIT-T J.127, UIT-T J.141, UIT-T J.142, UIT-T J.143, UIT-T J.144, UIT-T J.145, UIT-T J.146, UIT-T J.147, UIT-T J.148, UIT-T J.149, UIT-T J.163 ITU-T G.811, ITU-T G.813, ITU-T G.823, ITU-T G.824, ITU-T G.957, ANSI T1.105.03, ANSI T1.105.04, ANSI T1.105.06, ANSI T1.105.09, ANSI T1.416, ANSI T1.416.01, ANSI T1.416.02 UIT-T G.703, UIT-T G.704, UIT-T G.706, UIT-T G.732 y UIT-T G.823 UIT-T G.703, UIT-T G.704, UIT-T G.706, UIT-T G.733, UIT-T G.824 y ANSI T1.403 Estndares de la serie IEEE 802.1, 802.1q, 802.1p

Cable modem

Fibra ptica (OC-3.OC-12, OC-48, OC192, STM-1, STM-4, STM-16 y STM-64) E1 T1 Ethernet

Captulo Sptimo (parmetros de calidad de los servicios de transferencia de datos): este captulo abarca los artculos del 86 al 103 y se divide en tres secciones fundamentales: la seccin 1 (condiciones de prestacin de los servicios de transferencia de datos), la seccin 2 (parmetros de eficiencia del servicio de transferencia de datos) y la seccin 3 (parmetros tcnicos de los servicios de transferencia de datos). 36

Se utilizan los parmetros requeridos en la seccin 1 y la seccin 3, que son los que se relacionan directamente con el NP. La seccin 2 slo trata aspectos de facturacin, atencin al cliente y percepcin del servicio por parte del suscriptor que se relacionan con calidad de servicio pero no con NP. En el Captulo 5 del presente documento se exponen cada uno de los parmetros intrnsecos al captulo sptimo del Reglamento de prestacin y calidad del servicio y se analizan las posibles herramientas que permitan cuantificar los parmetros de NP requeridos. Tambin se brindan opciones para mejorar el NP. Artculo 138 (definicin del Factor de Ajuste por Calidad, FAC): en este artculo se define un factor (llamado Factor de Ajuste por Calidad) que permite aplicar la sancin directa sobre el precio de su servicio al proveedor u operador en caso de incumplir con los mbitos pactados para cada parmetro del NP segn el servicio ofrecido. Artculo 139 (ponderacin de indicadores de calidad): para el clculo del FAC especficamente en redes de transmisin de datos, se utiliza la ponderacin mostrada en la Tabla 2.2.

37

Tabla 2.2. Parmetros de calidad de los servicios de transferencia de datos

Parmetro Oportunidad en la prestacin de servicios. Atencin y reporte de incidencias. Oportunidad en la facturacin de servicios. Reclamaciones sobre facturaciones. Cumplimiento del tiempo de respuesta en el centro de telegestin. Grado de satisfaccin y percepcin de la calidad. Cumplimiento de los niveles de sobresuscripcin a nivel local de los servicios de transferencia de datos. Cumplimiento de los niveles de sobresuscripcin a nivel internacional de los servicios de transferencia de datos. Cumplimiento de niveles de retardo a nivel local. Cumplimiento de niveles de retardo a nivel internacional. Cumplimiento de niveles de variaciones en el retardo a nivel local. Cumplimiento de niveles de variaciones en el retardo a nivel internacional. Cumplimiento de niveles de prdida de paquetes a nivel local. Cumplimiento de niveles de prdida de paquetes a nivel internacional. Cumplimiento de niveles de ocupacin de los enlaces local e internacional. Cumplimiento del desempeo de la velocidad de transferencia local e internacional respecto a la velocidad contratada. Completacin de llamadas de los servidores de acceso conmutado. Peso relativo asignado 5% 5% 3% 2% 5% 5% 10% 10% 5% 5% 5% 5% 5% 5% 10% 10% 10%

1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17.

La

evaluacin

de

calidad

de

cada

uno

de

los

servicios

de

telecomunicaciones, ser cuantificada a travs de la sumatoria de los valores ponderados del nivel de cumplimiento de cada indicador de calidad, respecto al peso relativo asignado a cada uno de stos. (ARESEP, 2009) El precio final del servicio corresponder a la multiplicacin del valor porcentual del FAC por el precio cobrado por el servicio.

38

Por lo tanto, el Factor de Ajuste por Calidad se calcular segn la ecuacin 2.2-1:
% % ( 2.2-1)

Artculo 141 (obtencin del Indicador General de Calidad de los Servicios de Telecomunicaciones disponibles al pblico): el Indicador General de Calidad de los Servicios de Telecomunicaciones (IGCST) corresponde al promedio simple trimestral de los indicadores mensuales de Calidad de los Servicios de Telecomunicaciones (IMCST), calculado para cada servicio de telecomunicaciones. (ARESEP, 2009). Reclquese la importancia de obtener buenos resultados en la medicin del NP si se pretenden evitar consecuencias directas en el precio de los servicios ofrecidos. Entonces, las herramientas para mejorar y medir desempeo de red adquieren suma importancia para los proveedores de servicios actuales en Costa Rica ya que se asume esta nueva legislacin en aos recientes y la entrega de los informes trimestrales a partir del ao 2011.

2.3

Entidades internacionales de recomendaciones sobre desempeo de red y calidad de servicio

Existen dos entidades predominantemente importantes en relacin con el

establecimiento de normas, recomendaciones y parmetros al servicio de las redes tecnolgicas de telecomunicaciones implementadas en todo el mundo. 39

En primera instancia se encuentra la UIT (de sus siglas Unin Internacional de Telecomunicaciones) la cual se encarga de elaborar recomendaciones con normas que definen el funcionamiento de las redes de telecomunicaciones a nivel global. Dichas normas han sido ampliamente aceptadas internacionalmente, a pesar de que no son de ninguna forma vinculantes. Por su parte, el ETSI (de sus siglas en ingls European Telecommunications Standards Institute) es una entidad europea que genera estndares para esa regin. Ellos se encargan de estructurar Especificaciones Tcnicas. De la misma manera que con las recomendaciones de la UIT, las Especificaciones Tcnicas de la ETSI tiene trascendencia y aceptacin mundial. En el presente proyecto de investigacin, se toman en cuenta como marco referencial las siguientes recomendaciones (se puede hacer mencin a ms

recomendaciones durante el desarrollo de los captulos): ITU-T Y.1540: Esta recomendacin define parmetros que se pueden utilizar para especificar y evaluar la calidad de funcionamiento en cuanto a velocidad, exactitud, seguridad de funcionamiento y disponibilidad de la transferencia de paquetes IP del servicio de comunicacin de datos con protocolo Internet. (ITU, 2011) ITU-T Y.1541: En esta recomendacin se especifican los valores de calidad de funcionamiento IP de la red (UNI-UNI) para cada uno de los parmetros

40

de calidad de funcionamiento definidos en la recomendacin UIT-T Y.1540. (UIT, 2006) ITU-T G.1010: Esta recomendacin define un modelo de categoras de calidad de servicio (QoS) para servicios multimedios desde el punto de vista del usuario extremo. (ITU, 2001)

41

3. CAPTULO 3: Herramientas de medicin de NP

De acuerdo con las bases tericas expuestas en el captulo anterior, se pretende efectuar un estudio de las diferentes herramientas disponibles para la medicin del NP de una red WAN basada en Ethernet y Metro Ethernet. Del mismo modo, las herramientas a estudiar se consideran en funcin de los parmetros que solicita el ente regulador nacional de las telecomunicaciones (SUTEL); especficamente para redes de transferencia de datos segn lo estipulado en el Captulo 7 del Reglamento de Prestacin y Calidad de Servicio.

3.1.

Introduccin a la medicin del desempeo de red (NP)

En el captulo anterior se defini el concepto exacto de desempeo de red. Ahora

bien, es necesario conocer algunas definiciones mucho ms especficas para adecuar el presente captulo al anlisis certero de las herramientas de NP. En primer trmino, la percepcin del suscriptor sobre el funcionamiento global de la red (a lo que se llam QoS en el captulo anterior), est supeditada a muchas variables que inoportunamente pueden o no ser dependientes del proveedor u operador de la red. Por ejemplo, se sabe que a pesar de que el trfico en una red WAN sea liviano, el cuello de botella podra ocurrir en algn lugar entre el enrutador final, la lnea troncal y el host del usuario final (Davenhall & Leese, 2005) Un cortafuego (firewall en ingls) en el host del usuario final puede afectar la tasa de transmisin de datos entre dos suscriptores, ya que todos los paquetes son inspeccionados primero por el cortafuego; lo que adhiere un retardo a la transmisin. 42

Es decir, determinar el punto de falla de una red requiere no solo la medicin de los parmetros de NP, sino tambin el monitoreo de dichos parmetros a travs de herramientas como el protocolo SNMP (de sus siglas en ingls Simple Network Management Protocol) y software que lo implemente como los NPMs (de sus siglas en ingls Network Performance Monitor). De este modo se garantiza que la problemtica de una avera aislada de un suscriptor no se relaciona con el NP de la red WAN. Diagnosticar el NP de una red de datos Ethernet y Metro Ethernet implica tambin la necesidad de analizar registros de mediciones recabadas a lo largo de perodos definidos de tiempo y no solo mediciones puntuales, en este caso es muy til la implementacin de los NPMs. La SUTEL recomienda recabar la informacin en la hora cargada media (hora de mayor trfico en la red) y de forma mensual para el clculo del Indicador General de Calidad de los Servicios de Telecomunicaciones. 3.1.1. Tipos de medicin de desempeo de red A continuacin se enumera una clasificacin sobre los tipos de medicin de desempeo de red: Monitoreo activo o pasivo: en el monitoreo pasivo (no intrusivo) se monitorea el trfico en algn punto de la red. Por ejemplo, la medicin de paquetes que transitan por un enrutador. Se dice que el monitoreo es pasivo porque no se afecta de ninguna forma el estado operacional de la red. Se debe declarar un cierto nmero de paquetes n para ser monitoreados cada intervalo definido de tiempo. 43

Por su parte, en el monitoreo activo (intrusivo) se insertan algunos paquetes de prueba a la red para medir algn parmetro de su NP. Necesariamente se perturbar el estado operacional de la red. Un ejemplo puede ser el envo de un paquete a un host remoto para conocer el tiempo de propagacin de dicho paquete. Medicin en uno o varios puntos: suele ser tentador efectuar mediciones en una serie de puntos representativos de la red. Esta prctica es un error ya que impide visualizar correctamente los resultados; por lo tanto, es preferible efectuar una medicin entre dos hosts en los puntos de ingreso y egreso de la red. (Davenhall & Leese, 2005) Desempeo de la red y desempeo de las aplicaciones: es diferente aplicar mediciones de desempeo de red directamente mediante paquetes de prueba y mediciones a travs de programas de prueba a nivel de aplicaciones. Una no puede ser predicha a travs de la implementacin de la otra; en otras palabras, no es posible saber el desempeo de las aplicaciones mediante pruebas de red ni viceversa. 3.1.2 Mtricas de desempeo de red Las mtricas ms bsicas utilizadas en NP se compilan en la Tabla 3.1 junto con su definicin.

44

Tabla 3.1. Mtricas fundamentales de NP (Davenhall & Leese, 2005)

Mtrica Definicin La latencia es la definicin del rango temporal en el que sucede un acontecimiento. La medida ms comn de latencia se hace mediante el tiempo de viaje redondo (en ingls Round Trip Time o RTT), que es el tiempo que hay entre el despacho de un paquete y la recepcin del ACK (del diminutivo en ingls Acknowledge). Ntese que el RTT incluye el tiempo de propagacin del paquete y del ACK as como el tiempo de procesamiento para la generacin del ACK. A pesar de esto la latencia en trminos del RTT es ampliamente utilizada. La latencia puede variar por varias razones: Un host destino con poca carga responder ms rpido que uno altamente cargado. Si la red posee poca carga, entonces los paquetes tardarn menos tiempo en las colas de los enrutadores. Los enrutadores intermedios segn la configuracin de la red podrn modificar la latencia. Es una variacin en cortos perodos de la posicin ideal en el tiempo de una seal digital a travs de una red. Es la fraccin (normalmente expresada en porcentaje) del total de paquetes enviados en relacin con el total de ACKs recibidos en un perodo de tiempo definido. Una de las causas ms importantes de prdida de paquetes es la utilizacin completa de una cola de un enrutador. En este caso los paquetes son desechados y se produce la prdida de paquetes. Se trata de la tasa de datos real que pasa a travs de un punto especfico de la red. Es muy difcil medir el flujo real de datos a travs de un punto, por lo tanto el throughput suele medirse contando el trfico sobre un intervalo de tiempo que debe ser concienzudamente elegido. Si se elige un intervalo de tiempo muy largo se promediarn tanto transitorios como momentos de poco trfico; por el contrario si el intervalo es demasiado corto se tomarn en cuenta efectos temporales que no necesariamente reflejan el verdadero comportamiento de la red. Se refiere a la utilizacin de los enlaces a redes externas suplidas por otros proveedores de servicios de telecomunicaciones. Se tendr una tasa mxima de transferencia de datos contratada llamada tasa de acceso. Entonces la utilizacin del enlace se calcula como la razn porcentual de la utilizacin del enlace dividida por la tasa de acceso.

Latencia o retardo

Jitter (trmino en ingls)

Prdida de paquetes

Throughput (trmino en ingls)

Utilizacin del enlace

45

Tabla 3.2. Mtricas fundamentales para IP segn la ITU Y-1540

Mtrica IPTD (de sus siglas en ingls IP Packet Time Delay) IPDV (de sus siglas en ingls IP Packet Delay Variation) IPRL (IP Packet Loss Ratio) IPER (se sus siglas en ingls IP Packet Error Ratio) Definicin Tiempo que toma el paquete en atravesar un elemento de la red (host, enrutador, seccin de red, etc.). Variacin en el tiempo de retardo en el arribo de cada paquete; tambin conocido como jitter. Es una razn de prdida de paquetes. Es la proporcin de paquetes perdidos y el total de paquetes transmitidos, en un flujo de datos. Razn de paquetes con errores. Es la proporcin del total de paquetes con errores y el total de paquetes sin errores.

Segn las especificaciones de la recomendacin ITU Y.1540, se definen algunas otras mtricas que en trminos generales son similares a las expuestas en la Tabla 3.1. Dichas mtricas se exponen en la Tabla 3.2. El concepto de jitter en ocasiones es difcil de entender mediante una definicin. Por ello en la Figura 3.1 se muestra un esquema explicativo. La figura superior no tiene jitter y por ello los intervalos entre tramas consecutivas son equivalentes; sin embargo, la figura inferior s tiene jitter y por ello los intervalos entre las tramas consecutivas son irregulares.

Figura 3.1. Concepto de jitter: la figura superior no tiene jitter, la inferior s (Giguer, 2008) 46

Por ltimo, de acuerdo con el tipo de servicio para el cual se efecte la medicin de QoS, existen lmites operativos que determinan la clase de QoS. Dichas clases se enumeran y definen en la Tabla 3.3. Tabla 3.3. Directrices para clases QoS IP (ITU, 2001)
Clase de QoS Aplicaciones (ejemplos) Tiempo real, sensibles a la fluctuacin de fase, alta interaccin (VoIP, VTC) Tiempo real, sensibles a la fluctuacin de fase, alta interaccin (VoIP, VTC) Datos transaccionales, altamente interactivas (sealizacin) Datos transaccionales, interactivas Slo prdida baja (transacciones cortas, datos en grandes cantidades, flujo continuo de video) Aplicaciones tradicionales de redes IP por defecto Mecanismos de nodo Tcnicas de red Encaminamiento y distancia limitados Encaminamiento y distancia menos limitados Encaminamiento y distancia limitados Encaminamiento y distancia menos limitados Cualquier ruta/trayecto

Cola separada con servicio preferencial, preparacin del trfico

Cola separada, prioridad por supresin

Cola larga, prioridad por supresin

Cola separada (prioridad inferior)

Cualquier ruta/trayecto

Luego, segn la Especificacin Tcnica de la ETSI 3GGP TS 123 104, la clase 0 y 1 son de tiempo real y la clase 2, 3, 4 y 5 de mejor esfuerzo. Siendo la clase 0 una clase de servicios conversacionales, la clase 1 de streaming (distribucin multimedia a travs de una red en la que el usuario disfruta del medio al mismo tiempo que lo descarga), la clase 2, 3 y 4 interactivo y la clase 5 de background. 47

Tabla 3.4. Clasificacin de servicios en una red NGN (Blandon & Daz, 2008)
Clase de servicio Servicios Audio de baja demanda Audio con calidad de estudio Audio sub-estndar Difusin de audio Telefona Difusin de video de alta definicin Difusin de video estndar Difusin de video subestndar Videoconferencia Videotelefona VoD de alta definicin VoD estndar VoD subestndar Correo Difusin de datos Mensajera Navegacin P2P Transferencia de archivos e-administration e-commerce e-games e-learning

Audio digital

Video digital

Servicio bsico de datos

Servicio de valor aadido

La obtencin de un nivel de calidad y su evaluacin depende entonces de cada servicio en particular. Para una red de prxima generacin (NGN, de sus siglas en ingls Next Generation Network); en la que se incluyen las redes Metro Ethernet, los servicios ofrecidos se sintetizan en la Tabla 3.4. Se debe tener claro que un proveedor de Internet podr ofrecer o no a sus clientes un Acuerdo de Nivel de Servicio (SLA, de sus siglas en ingls Service Level Agreement). En caso de ofrecerse garanta en relacin con una clase de nivel de servicio, se deben 48

configurar los dispositivos de red intermedios para priorizar trfico segn su clase o el nivel adquirido por el suscriptor. En la Figura 3.2 se muestra que la aplicacin de configuraciones de QoS sobre los dispositivos de red no es viable cuando la congestin es muy fuerte.

Figura 3.2. Efectos de la congestin de la red sobre las configuraciones de QoS en relacin con el tiempo de servicio y el rendimiento de la red (Mrquez & Ravelo, 2010) En el caso en el que el proveedor de Internet no se compromete con la QoS ofrecida, entonces se dice que se ofrece un servicio de mejor esfuerzo (clase 5). En las recomendaciones internacionales (UIT Y.1541) no hay lmites para las mtricas de clase 5; sin embargo, la SUTEL s establece mbitos para las mtricas en redes de mejor esfuerzo los cuales se revisarn en el Captulo 5.

49

3.2.

Recomendacin Y.1564 de la UIT y RFC 2544

En esta seccin se estudian dos de las metodologas internacionales ms

ampliamente difundidas que se utilizan actualmente para medir el desempeo de redes Ethernet y Metro Ethernet. 3.2.1. RFC 2544 Se trata de una metodologa de benchmark (referencia) en la que se discuten y definen una serie de pruebas que pueden ser utilizadas para describir las caractersticas de desempeo de una red. (Bradner & McQuaid, 1999) Fue publicado en marzo de 1999 en el RFC 2544 de la EITF. La forma sugerida para efectuar las pruebas coincide con la implementada para las pruebas de desempeo en el presente proyecto de investigacin. En la Figura 3.3 se muestra dicha topologa de pruebas; el DUT (de sus siglas en ingls Device Under Test) se puede referir a toda una red. Adems, las pruebas efectuadas son activas (intrusivas), por lo tanto se deben hacer antes de poner la red en produccin; o bien, durante ventanas de mantenimiento afectando el servicio al cliente.

Emisor

DUT

Receptor

Figura 3.3. Topologa de prueba recomendada por el RFC 2544

50

La RFC 2544 sugiere que las pruebas efectuadas deben ser para tramas Ethernet de 64, 128, 256, 512, 1024, 1280 y 1518 bits. Adems, recomienda que la duracin de las pruebas sea de al menos 60 segundos. En la Tabla 3.5 se enlistan las pruebas de benchmarking que contempla el RFC 2544 junto con el objetivo, el procedimiento y el formato de presentacin de los resultados: Tabla 3.5. Pruebas de benchmarking del RFC 2544
Parmetro Objetivo Determinar el throughput del DUT. Donde throughput se entiende como la mnima tasa de transferencia en la cual ningn paquete se pierde. Determinar la latencia del DUT, en un solo sentido. Es decir, el intervalo de tiempo en el que el ltimo bit entra al dispositivo de entrada y el primer bit sale por el puerto de salida (en otras palabras se refiere a la Procedimiento Presentacin de los datos

Throughput

Enviar un nmero especfico a una tasa especfica a travs del DUT y luego contar las tramas que fueron transmitidas por el DUT. El throughput ser la tasa ms veloz en la cual el nmero de tramas transmitidas por el DUT es igual al nmero de tramas de prueba enviadas por el emisor. (Bradner & McQuaid, 1999) Efectuar la prueba de latencia para los diferentes tamaos de trama sugeridos y a la tasa determinada en cada prueba throughput efectuada anteriormente. La prueba debe durar al menos 120 segundos; luego de los 60 segundos se debe utilizar una etiqueta en una de las tramas para marcar el tiempo en el que se termin de transmitir la misma (tiempo A); luego el receptor debe marcar el tiempo en el que se recibi empez a recibir dicha trama (tiempo B). La latencia ser el tiempo B menos el tiempo A. Se debe repetir al menos 20 veces y tomar como

Los resultados deben presentarse en un grfico. Donde la coordenada X ser el tamao de la trama y la coordenada Y la tasa de transferencia.

Latencia

El reporte debe indicar la definicin de latencia utilizada. Debe desplegarse en una tabla; en cada fila de la misma se debe presentar el tamao de la trama utilizada as como el resultado obtenido.

51

latencia en un resultado de latencia el promedio de solo sentido). las 20 o ms pruebas. Cuando la latencia vara de trama en trama provocar problemas con servicios de tiempo real. (Giguer, 2008) Medir la tasa de prdida de tramas. Dicha tasa se refiere al porcentaje de tramas que tuvieron que haber sido redirigidas por la red en estado estacionario y que no lo fueron. Se deben presentar los resultados de forma grfica. En la coordenada X se debe presentar la tasa de transferencia de entrada como un porcentaje en funcin de la tasa mxima para un tamao de trama especfico. En la coordenada Y se debe presentar el porcentaje de prdida de paquetes para la correspondiente tasa de transferencia.

Tasa de prdida de tramas

Se envan tramas a una tasa de transferencia del 100% de la mxima tasa para ese tamao especfico de trama. Luego se reduce la prueba en intervalos de 10% hasta que no haya prdida de paquetes.

Caracterizar la habilidad del DUT para procesar tramas backto-back. Permite conocer el nmero de Tramas back- tramas que se to-back pudieron enviar completament e en rfaga con un tiempo mnimo entre tramas y un tamao de trama especfico.

Enviar rfagas de tramas con el mnimo tiempo entre tramas posible. Efectuar la prueba hasta que el nmero de tramas recibidas sea el mismo que el nmero de tramas enviadas, reduciendo para ello el tamao de la trama. El back-toback ser el nmero de tramas que se pudieron enviar completamente en rfaga con un tiempo mnimo entre tramas y un tamao de trama especfico. La prueba debe ser de al menos 2 segundos y hacerse al menos 50 veces para cada tamao de trama. En redes portadoras de Ethernet (como Metro Ethernet), esta medicin es muy til ya que valida el parmetro de EIR (de sus siglas en ingls Excess Information Rate) definido en muchos SLAs. (Giguer, 2008)

Se debe presentar en una tabla con una columna para el tamao de trama, otra para el promedio de las 50 pruebas y otra con la desviacin estndar.

52

Recuperacin de sistema

Se pretende caracterizar la velocidad con la que el DUT se recupera de una condicin de sobrecarga.

Reinicio

Se pretende caracterizar la velocidad a la cual el DUT se recupera de una condicin de reinicio.

Enviar un flujo de tramas al 110% del throughput previamente determinado por 60 segundos. En el tiempo A reducir ese flujo al 50% y luego capturar el tiempo B en el que se perdi el ltimo paquete. Se debe repetir varias veces. El tiempo de recuperacin del sistema ser el promedio de la resta del tiempo B menos el tiempo A para las distintas pruebas. Se envan tramas pequeas con un throughput igual al calculado anteriormente. Se reinician los dispositivos intermedios y se toma el tiempo A de la ltima trama recibida y el tiempo B cuando se vuelven a recibir. La diferencia de dichos tiempos se considerar el tiempo de levantamiento del sistema. Tambin se debe hacer una prueba quitando la potencia del equipo por 10 segundos.

Se debe presentar en forma de tabla, incluyendo el tamao de trama, el throughput y el resultado obtenido.

Simplemente se debe presentar el resultado en prosa, indicando los tipos de reinicio del equipo que se probaron.

Los conceptos expuestos en la Tabla 3.5 se obtuvieron del RFC 1242, en el cual se define la terminologa utilizada en el benchmarking del RFC 2544. Si se estudia la metodologa del RFC 2544 parecera que se trata de una recomendacin de medicin de desempeo enfocada a un DUT especfico; es decir, a un solo dispositivo de red. Sin embargo, RFC 2544 es altamente efectiva para valorar el desempeo de dispositivos de red interconectados en redes portadoras de Ethernet (en ingls llamadas Carrier Ethernet). (Giguer, 2008) Ahora bien, otro aspecto muy importante que se debe mencionar es que dada la estructura de la metodologa de las pruebas y la cantidad de intentos que se deben hacer, se 53

toma mucho tiempo probando la red. Esto es una desventaja si las pruebas se quieren realizar sobre redes que estn en produccin. Algunos proveedores de servicios de Carrier Ethernet han optado por limitar el nmero de pruebas y el tamao de las tramas utilizadas. (Giguer, 2008) Otra carencia importante del RFC 2544 es la prueba del jitter. Esta prueba es fundamental ya que mucho jitter en una red provoca desmejoras en la calidad perceptibles en aplicaciones de tiempo real como VoIP o streaming de video. En el Captulo 4 se implementar la metodologa del RFC 2544 mediante una plataforma comercial utilizando un mdulo especficamente diseado para las pruebas. 3.2.2. Recomendacin Y.1564 (o Y.156sam) de la UIT La recomendacin Y.1564 (cuyo nombre provisional es Y.156sam) fue creada por el Sector de Normalizacin de las Telecomunicaciones la UIT-T (de sus siglas Unin Internacional de Telecomunicaciones) y aprobada en el mes de marzo de 2011. Se trata de una recomendacin sumamente actual que define una metodologa de pruebas que puede ser utilizada para validar el adecuado desempeo y configuracin de una red Ethernet para brindar servicios basados en Ethernet. Esta metodologa de pruebas outof-service fue creada para que los proveedores de servicios tuvieran una forma estandarizada de medir el desempeo de sus servicios basados en Ethernet (como los ofrecidos en una red Metro Ethernet). (ITU-T, 2011) El trmino out-of-service se refiere a que la metodologa debe ser aplicada en redes que an no estn en produccin. Adems, la metodologa de pruebas es aplicable a 54

conectividades punto a punto y punto a multipunto en la capa Ethernet como los ofrecidos por una EPL de Metro Ethernet y que constituye el foco de las pruebas mostradas en el Captulo 4. Los objetivos de la metodologa de pruebas que se definen en la recomendacin se enumeran a continuacin: Servir como una herramienta de validacin de SLA (de sus siglas en ingls Service Level Agreement), asegurndose de que el servicio cumpla su garanta de desempeo en una prueba controlada. Un SLA es un contrato entre el proveedor de un servicio y un cliente, en el cual se garantiza el cumplimiento de un rendimiento mnimo. Asegurarse de que todos los servicios transportados por la red cumplan sus objetivos de SLA, probando que bajo carga mxima los dispositivos y los enlaces de red podrn soportar todo el trfico. Desarrollar pruebas de servicios a mediano y largo plazo para confirmar que los dispositivos de la red podrn transportar todos los servicios a pesar de estar bajo condiciones de estrs. La metodologa utilizada define un perfil de ancho de banda. Si el cliente transmite trfico a la red de acuerdo a este perfil, se le garantizar un cierto nivel de desempeo de servicio. (Marshall, 2011) El perfil de ancho de banda est formado por los siguientes parmetros:

55

CIR (de sus siglas en ingls Committed Information Rate): se refiere al ancho de banda que est disponible de forma garantizada siempre para un servicio especfico y donde los KPIs (de sus siglas en ingls Key Performance Indicators, es decir, las mtricas de desempeo) se cumplen de forma garantizada. (EXFO, 2010).

CBS (de sus siglas en ingls Committed Burst Size): se refiere a la libertad que tiene el cliente de sobrepasar el CIR sobre determinados intervalos de tiempo. Normalmente el cliente y el proveedor llegan a un acuerdo en relacin con este parmetro. El trfico CBS o CIR es considerado trfico verde y el proveedor debe asegurar que se cumplan las mtricas de desempeo mnimas establecidas en el SLA.

EIR (de sus siglas en ingls Excess Information Rate): se trata del promedio de trfico adicional sobre el valor de CBS que el cliente tiene permitido enviar. Se vende ms barato que el trfico de CIR; sin embargo, no se garantiza el cumplimiento de los valores mnimos de desempeo. Este trfico es marcado como amarillo.

EBS (de sus siglas en ingls Excess Burst Size): define cunta libertad se dar al cliente para transmitir su trfico en exceso en rfagas en intervalos temporales sobre el CIR ms el EIR. El trfico que excede este lmite es marcado como rojo y es inmediatamente desechado por la red. En la Figura 3.4 se muestra un esquema ilustrativo relacionado con los conceptos

recin abarcados. 56

Figura 3.4. Alegora del perfil de ancho de banda (Marshall, 2011) Tabla 3.6. Parmetros principales de desempeo segn el Y.1564 (KPI)
Parmetro Ancho de banda Descripcin Es la tasa de la cantidad total de trfico enviada durante durante una ventana de medicin de 1 segundo. Es el tiempo transcurrido entre el envo de un paquete y su recepcin. Tpicamente se puede utilizar el RTT para servicios como FTP y el one-way-delay para servicios como VoIP. Se aplica la misma definicin que para RFC 2544 Se aplica la misma definicin que para recomendacin Y.1540 expuesta anteriormente.

Frame delay (latencia)

Prdida de tramas Frame Delay Variation (jitter)

Ahora bien, los indicadores clave de desempeo son las caractersticas especficas del trfico que indican el desempeo mnimo de un perfil particular de trfico. En condicin verde, la red debe garantizar el cumplimiento de estos KPIs. La Tabla 3.6 resume las mtricas contempladas por la metodologa de pruebas Y.1564. 57

Conocidos los parmetros y las caractersticas del perfil de ancho de banda, la recomendacin Y.1564 incluye el trmino SAC (de sus siglas en ingls Service Acceptance Criteria). El SAC se elige de modo que el proveedor de servicios tenga alta seguridad de que un servicio aceptado de acuerdo con el SAC aprobar el SLA cuando la red se ponga en produccin. En otras palabras, el SAC son los parmetros que se configuran durante las pruebas que simular el SLA a la hora de la puesta en produccin de la red. Ahora bien, una vez establecido el SAC de la prueba, la metodologa propuesta por la recomendacin Y.1564 separa las pruebas en dos partes: la SCT (de sus siglas en ingls Service Configuration Test) y la SPT (de sus siglas en ingls Service Performance Test). En la SCT se encuentran y corrigen problemas de configuracin de la prueba. En la SPT se ejecutan las pruebas para verificar que el desempeo es estable sobre el tiempo y que adems satisface el SAC. 3.2.2.1. SCT (prueba de configuracin del servicio)

Se trata de una prueba por servicio que verifica el ancho de banda y los requerimientos de desempeo de un servicio especfico definido por el usuario. El proceso sigue tres fases primordiales y monitorea todos los indicadores de desempeo durante estos pasos. (Diallo, 2011) Fase 1: en esta fase el ancho de banda para un servicio especfico es escalado desde una tasa de transferencia mnima hasta el CIR. Se asegura de que el servicio sea soportable por la red para las condiciones de SAC establecidas por el usuario que 58

desea probar el circuito. En cada paso del escalamiento el sistema debe medir los KPIs para verificar que se cumplan los objetivos del SAC. Si algn KPI no cumple, entonces la fase tampoco lo hace. La Figura 3.5 ilustra esta fase.

Figura 3.5. Fase 1 de la SCT (Diallo, 2011) Fase 2: en esta fase el servicio pasa del CIR al EIR. Se asegura de que la red soporte la tasa de transferencia del EIR; sin embargo, si se falla en algn KPI la prueba no se detiene ya que se trata de trfico amarillo con parmetros de desempeo no garantizados. En la Figura 3.6 se ilustra esta fase.

Figura 3.6. Fase 2 de la SCT (Diallo, 2011) Fase 3: en esta fase se sobrepasa el EIR. En este caso se debe descartar todo el trfico superior a l para aprobar la prueba. Se pierde la prueba ya que el proveedor ms bien est ofreciendo ms ancho de banda del contratado. La Figura 3.7 ilustra esta fase.

59

Figura 3.7. Fase 3 de la SCT (Diallo, 2011) Las tres fases se efectan servicio por servicio secuencialmente. No de forma simultnea. 3.2.2.2. SPT (prueba de desempeo del servicio)

En esta prueba todos los servicios configurados se generan al mismo tiempo y para el CIR respectivo en perodos de tiempos que pueden desde los minutos hasta los das. (Diallo, 2011) Evidentemente la diferencia con el SCT es que en este caso todos los servicios se prueban simultneamente; sin embargo, se monitorean individualmente para determinar si algn KPI es incumplido, en cuyo caso la prueba se da por perdida.

Figura 3.8. Fase 3 de la SCT (Diallo, 2011) 60

En el Captulo 4 se implementar la metodologa de pruebas de la recomendacin Y.1564 mediante una plataforma comercial utilizando un mdulo especficamente diseado para las pruebas.

3.3.

Herramientas bsicas para la medicin de NP

En esta seccin se presentan las herramientas bsicas que se utilizan para obtener

mediciones de NP. Es importante utilizar estas herramientas con discrecin ya que la mayora implican trfico dentro de la red, lo que sacrificara irnicamente su desempeo. Estas herramientas bsicas junto con sus algoritmos representan la base de otras utilidades ms robustas para medicin de desempeo de red que al fin de cuenta slo las implementan incorporndoles mayores ndices de funcionalidad. 3.3.1. PING PING (de sus siglas en ingls Packet Internet Groper) es una utilidad para el diagnstico de la conexin entre dos dispositivos en una red TCP/IP mediante el envo de paquetes ICMP (de sus siglas en ingls Internet Control Message Protocol) de solicitud y respuesta. El dispositivo destino debe estar configurado para responder a PING. El diagnstico de conexin que efecta es a nivel de la capa de Internet o red del modelo de referencia TCP/IP; por lo tanto, no se puede garantizar que algn servicio del nivel de aplicacin del modelo de referencia TCP/IP funcionar a pesar de que la respuesta del PING sea afirmativa.

61

Adems del diagnstico de conexin, la utilidad PING permite obtener el RTT; es decir, es una herramienta que puede utilizarse para la medicin de la mtrica de latencia. Tambin especifica la prdida de paquetes. No es una prctica correcta efectuar PING a enrutadores ya que estos procesan los paquetes PING con baja prioridad. La versin de PING para sistemas basados en Unix muestra la siguiente informacin: El nombre del host destino. El nmero de paquetes transmitidos. El nmero de paquetes recibidos. La prdida porcentual de paquetes. El promedio, el valor mximo y el valor mnimo del RTT.

Figura 3.9. Salida de la utilidad PING En la Figura 3.9 se muestra la salida de la utilidad PING. Se utiliz la herramienta de consola del sistema operativo Ubuntu 11.04 para ejecutar el PING. La opcin w 62

utilizada define que se efectuarn 10 pruebas; por defecto cada prueba se realiza en intervalos de 1 s. Se pueden utilizar varias opciones para el PING las cuales estn documentadas en la pgina man de Linux para PING (ejecutando man ping en la consola). Ntese que al final de la ejecucin del PING se brinda la estadstica de la cantidad de paquetes transmitidos, la cantidad de paquetes recibidos, el porcentaje de prdida de paquetes y el valor promedio, mximo y mnimo del RTT. 3.3.2. Traceroute Es similar a la utilidad PING, salvo que enlista salto por salto todos los enrutadores por los que pasa un paquete hasta llegar a su destino (slo de la ruta saliente). Tambin muestra la latencia para cada salto efectuado. Suele utilizarse como una herramienta de diagnstico para conocer por qu no se puede alcanzar por PING un host. 3.3.3. Pathchar, pchar e iperf Son utilidades similares a traceroute pero ms enfocadas a la medicin de mtricas de desempeo de red. Pathchar y pchar permiten determinar problemas de congestin de red. Permite medir la razn de transferencia de datos, el retardo y la tasa de prdidas para cada salto desde el host origen hasta el host destino. Iperf permite medir el ancho de banda disponible hacia un host destino. Permite configurar mltiples parmetros de TCP y UDP. Tambin puede utilizarse para determinar 63

el jitter. Se basa en un sistema cliente-servidor, por lo tanto, en ambos hosts debe instalarse la aplicacin. 3.3.4. SNMPwalk Es una utilidad de SNMP (de sus siglas en ingls Simple Network Management Protocol) que permite inquirir a los dispositivos de red para obtener alguna informacin. El protocolo SNMP es un protocolo de la capa de aplicacin para el intercambio de informacin con los elementos de red. No es una herramienta de medicin de desempeo de red en s, pero s constituye la base de muchas aplicaciones de monitoreo para obtener los datos requeridos; por ejemplo, los NPM obtienen la informacin que almacenan para el anlisis a partir de SNMP, ya que realizan peridicamente consultas a los equipos sobre algn tipo de informacin; por ejemplo, ancho de banda utilizado en un enlace. Luego de un perodo de tiempo se pueden tomar esos datos obtenidos mediante SNMP y graficarlos para generar parmetros estadsticos sobre desempeo de red, como por ejemplo el percentil 95 de utilizacin de un enlace.

3.4.

Herramientas complejas para la medicin de NP (nivel de proveedor de servicios)

En esta seccin se incluyen una serie de herramientas complejas para la medicin de

NP. Existe una asociacin cooperativa a nivel global que se encarga de desarrollar e impulsar herramientas e investigaciones para mejorar la calidad de servicio y las 64

implementaciones del Internet. Dicha cooperativa se denomina CAIDA (por sus siglas en ingls Cooperative Association for Internet Data Analysis). En su sitio de Internet es posible encontrar muchas aplicaciones para la medicin del NP. Tabla 3.7. Herramientas complejas para la medicin de NP
Herramienta D-ITG (de sus siglas en ingls Distributed Internet Traffic Generator) Descripcin Se trata de una plataforma de cdigo abierto con la capacidad de producir trfico a nivel de paquetes con mucha precisin (IPv4 e IPv6). Tambin puede replicar procesos estocsticos para IDT (de sus siglas en ingls Inter Departure Time) y para las variables PS (de sus siglas en ingls Packet Size) aleatorias (Pareto, uniforme, exponencial, etc.). La herramienta puede inyectar trfico a nivel de red, de transporte y de aplicacin. Adems permite medir el retardo de ida OWD (de sus siglas en ingls One Way Delay), el RTT, la tasa de prdida de paquetes, el jitter y el throughput. Sigue el paradigma cliente-servidor y posee 4 ejecutables principales: ITGSend, ITGRecv, ITGLog e ITGDec; adems de dos secundarios: ITGPlot e ITGapi. En el Captulo 4 se detallan las funciones de cada mdulo para ser implementadas. Se trata de un sistema de monitoreo de cdigo abierto que permite vigilar tanto los dispositivos (hardware) como los servicios (software) que se deseen monitorear. La informacin de los estados de los equipos se obtiene mediante scripts que implementan SNMP para inquirir la informacin de los diferentes dispositivos de la red. Plataforma Linux y Windows Licencia Freeware Tipo de medicin Activa

Nagios

Linux

GPL

Pasiva

65

Netperf

Bing

Es posible utilizar aditamentos diseados para adaptarse a la implementacin bsica de Nagios y que le proporcionan una gran versatilidad. Por ejemplo, se puede utilizar el aditamento pnp4nagios el cual permite utilizar los datos almacenados en la base de datos de Nagios y generar grficas. Dichas grficas se pueden utilizar para el clculo de la utilizacin de un enlace en un intervalo de tiempo deseado. En el captulo 4 se detallan ms aspectos del uso de esta poderosa herramienta de monitoreo pasivo (no intrusiva, se limita a observar y respaldar los datos del comportamiento de la red). Se trata de un benchmark de cdigo abierto que puede ser utilizado para medir el desempeo de muchos aspectos de la red. El software fue escrito por Rick Jones; un empleado de la empresa HewlettPackard. De hecho la documentacin del software est bajo la licencia de dicha empresa; la cual no se hace responsable de la fiabilidad del programa. Su enfoque principal es en la transferencia de grandes volmenes de datos y el desempeo en trfico de tipo solicitud/respuesta, usando TCP y UDP y la interfaz de sockets BSD (se refiere a los sockets de Unix, que permiten la comunicacin entre dos procesos en la misma computadora o en dos distintas). (Velsquez & Gamess, 2009) Est diseado para ser utilizado como cliente-servidor. Siendo el cliente netperf y el servidor netserver. Permite obtener la medicin cruda o real del ancho de banda de un enlace de

Linux

Freeware

Activa

Linux y Windows

Freeware

Activa

66

red remoto (no directamente conectado a la computadora). NetStress Es una herramienta de benchmark para el clculo del desempeo de redes tanto cableadas como inalmbricas. Implementa grandes transferencias de volmenes de datos con TCP (slo ofrece TCP como protocolo de transporte e IPv4 como protocolo de red), dando el throughput resultante. Utiliza el paradigma cliente-servidor. MGEN Se trata de una utilidad de cdigo abierto desarrollada por PROTEAN (de sus siglas en ingls PROTocol Engineering Advanced Networking. Permite efectuar pruebas de rendimiento para redes IP con trfico UDP unicast o multicast. Implementa el paradigma de clienteservidor. LANforge Est comprendida por dos utilidades bsicas, una para la generacin de trfico de red (llamada LANforge-fire) y la otra para la simulacin del ncleo de la red (llamada LANforge-ICE). En trminos generales es una herramienta para la simulacin de redes y la ejecucin de pruebas de medicin sobre ellas. Permite generar llamadas VoIP (de sus siglas en ingls Voice over IP). Soporta la simulacin de gran cantidad de protocolos: MPLS, IPv6, IPv4, OSPF, etc. Rude & Crude Es una aplicacin dividida en dos componentes fundamentales; por un lado RUDE (de sus siglas en ingls Realtime UDP Data Emitter) para generar trfico de red y por otro CRUDE (de sus siglas en ingls Collector for RUDE) para la recepcin del trfico generado por RUDE. Genera estadsticas de trfico UDP, especficamente paquetes

Windows

Freeware

Activa

Linux y Windows

GPL

Activa

Linux y Windows

Licencia privativa

Simulacin

Linux

GPL

Activa

67

Network Traffic Generator

recibidos, paquetes recibidos fuera de secuencia, paquetes perdidos, bytes recibidos, retardo promedio, jittery throughput. Se trata de una utilidad de cdigo abierto que permite la generacin de trfico TCP y UDP bajo el paradigma cliente-servidor de modo que se generen escenarios de estrs de dispositivos de red. No es en s una herramienta para la medicin de desempeo, pero es muy til para crear escenarios controlados de pruebas que permitan predecir el desempeo futuro de la red.

Linux

GPL

Activa (slo generacin de trfico)

3.5.

Herramientas para la medicin de NP (a nivel del suscriptor de servicios)

No slo existen herramientas con caractersticas tcnicas de difcil acceso para los

usuarios de un servicio de datos e Internet. Esta seccin expone los conceptos iniciales de aplicaciones que pueden ser utilizadas por los suscriptores de un servicio de datos e Internet para comprobar la tasa de transferencia real de datos. En el Captulo 4 se efectan las pruebas correspondientes a estas herramientas y se analiza la factibilidad y las desventajas de este tipo de pruebas. 3.5.1. NetPerSec Monitorea toda la actividad TCP/IP tanto de descarga como de subida hacia Internet u otras redes y grafica la velocidad de comunicacin en tiempo real. Se puede ajustar la tasa de muestreo y la cantidad de datos utilizados para graficar el promedio. 68

Es una herramienta til a nivel de suscriptor de Internet si se pretenden obtener estadsticas de la tasa de transferencia real que se posee. Se trata de una utilidad que implementa mediciones pasivas (no intrusivas) ya que se limita a analizar y graficar el trfico en la interfaz de red del computador del cliente. Es un proyecto pequeo desarrollado por Mark Sweeney para la plataforma Windows (hasta Windows XP). No tiene pgina oficial en Internet y se lanz oficialmente en una publicacin de la revista PC Magazine en 2001 (Sweeney, 2001). Para descargarlo es necesario ser suscriptor de la revista; o bien, pagar un pequeo precio ($7,97); adems se trata de una herramienta de cdigo cerrado. 3.5.1.1. Metodologa de funcionamiento de NetPerSec

Como ya se mencion, NetPerSec es una herramienta pasiva (no intrusiva); por lo tanto se apoya en utilidades de monitoreo. Especficamente implementa SNMP para recoger la informacin de la interfaz de red del equipo y graficarla. SNMP se basa en el paradigma servidor-cliente; en este caso el cliente o administrador (NetPerSec) se conecta con un servidor llamado agente SNMP (la interfaz de red), el cual se encarga de mantener actualizada la base de datos de los MIBs (de sus siglas en ingls Management Information Base) que contiene la informacin estadstica y de control que pueden ser accedidos por el administrador SNMP (NetPerSec). Por ejemplo, un objeto MIB puede representar el nmero de bytes que han sido transmitidos por la red; otro puede representar el tiempo total en el que la red estuvo corriendo. (Sweeney, 2001) 69

Para obtener un parmetro del MIB especfico se utiliza una nomenclatura de punto similar a la de una direccin IP. El esquema numrico de direccionamiento se llama Notacin de Sintaxis Abstracta y cada direccin se llama un identificador de objeto u OID. NetPerSec utiliza dos OIDs, uno llamado ifInOctets que devuelve el nmero de bytes recibidos por la interfaz de red y otro llamado ifOutOctets que devuelve el nmero de bytes que han sido enviados fuera de la interfaz. En otras palabras, se tiene la impresin de que la velocidad mostrada por NetPerSec involucra todos los bits extras o de overhead correspondientes al encapsulamiento de la informacin desde la capa de aplicacin hasta la fsica (segn el modelo de referencia TCP/IP expuesto en el Captulo I). Sin embargo, el desarrollador dice textualmente: se puede entonces calcular el data throughput dividiendo los deltas (diferencias) de los valores recibidos y transmitidos por el nmero de milisegundos que han pasado entre las peticiones de SNMP. (Sweeney, 2001) Por lo tanto no queda claro si se mide el ancho de banda total o la tasa de transferencia real (throughput). NetPerSec utiliza varias libreras de Windows para la manipulacin de la informacin, adems llama a la funcin SnmpExtensionQuery( ) mediante la cual efecta las consultas de los OIDs especificados en el prrafo anterior. Al final de cuentas NetPerSec toma la diferencia de los valores transmitidos y de los valores recibidos y los divide por el nmero de milisegundos que han transcurrido entre cada peticin de SNMP para obtener la tasa de transferencia de descarga y subida.

70

3.5.2. Speedtest de Ookla Se trata de un medidor de la tasa de transferencia de descarga y subida mediante una interfaz web, ampliamente difundido y utilizado a nivel mundial. La prueba de Speedtest opera enteramente sobre HTTP (protocolo de la capa de aplicacin utilizado para la comunicacin de arquitecturas basadas en web, utiliza TCP como protocolo de transporte a travs del puerto 80). (Ookla, 2010) En realidad el Speedtest de Ookla es una medicin del throughput de HTTP entre un servidor web y un cliente. El tamao de los paquetes y todos los otros parmetros del TCP son controlados por el servidor en s, por lo que existe cierto rango de afinacin que puede ser configurado para obtener un mximo throughput. (Ookla, 2010) La interfaz web est diseada utilizando Flash; por lo tanto existe un margen de error en relacin con la utilizacin de la CPU en ambos sentidos (tanto del servidor como del cliente), adems del tiempo adherido en pasar por todas las capas del modelo de referencia TCP/IP hasta llegar a la de aplicacin que es controlada mediante una interfaz en Flash. (Ookla, 2010) Como la prueba se efecta en trminos de transacciones de archivos a nivel HTTP, el tiempo de dichas transacciones resulta vital para el clculo final de la tasa de descarga y subida. Dadas las condiciones del prrafo anterior, el Speedtest de Ookla intenta compensar ese margen de error eliminando cierto porcentaje de los resultados compilados para luego efectuar el clculo final que se despliega en pantalla.

71

A pesar de su gran difusin, esta prueba no refleja el verdadero throughput que posee un usuario final que paga por un servicio de Internet a un ISP. Se trata de una aplicacin que mide la tasa de transferencia de descarga y subida a un servidor por lo tanto la velocidad variar de sitio de prueba en sitio de prueba basado en muchas variables como la distancia fsica del servidor, los tamaos de archivos usados en las transacciones, la capacidad de conexin a Internet en ambos sitios, la hora del da, etc. (Sprint, 2011) 3.5.2.1. Metodologa de funcionamiento de la prueba de descarga

A continuacin se enumeran los pasos que sigue el Speedtest de Ookla para obtener el valor de la tasa de descarga (Ookla, 2010): 1. Se descargan pequeos archivos binarios del servidor web a la mquina cliente para estimar la velocidad de conexin. 2. Con base en estos resultados, el servidor elige uno de muchos tamaos de archivos para utilizarlos en la verdadera prueba de velocidad. 3. Se anexan varias cadenas de caracteres aleatorias a cada descarga para evitar la utilizacin del cach en la CPU de la mquina cliente (lo que arruinara la prueba). 4. Ms de 8 hilos HTTP en paralelo pueden ser utilizados para la prueba. 5. Las muestras del throughput son recibidas ms de 30 veces por segundo. 6. Estas muestras se agrupan en 20 segmentos (cada segmento utiliza 5% de las muestras totales). 7. El 10% ms rpido y el 30% ms lento de los segmentos son descartados (por las razones expuestas anteriormente). 72

8. Los segmentos restantes se promedian para obtener el resultado final y desplegarlo en la interfaz web. 3.5.2.2. Metodologa de funcionamiento de la prueba de subida

A continuacin se enumeran los pasos que sigue el Speedtest de Ookla para obtener el valor de la tasa de subida (Ookla, 2010): 1. Una pequea cantidad de datos aleatorios se genera en la mquina cliente y se enva al servidor web para estimar la velocidad de conexin. 2. Basado en este resultado, se generan datos aleatorios con un tamao apropiado para la subida. 3. La informacin subida se procesa en tamaos de informacin configurables por el servidor, empujados al mismo mediante un script va POST (mtodo de peticiones de HTTP). 4. Se pueden utilizar hasta 8 hilos de HTTP en forma paralela. 5. Los fragmentos de informacin formados por el servidor (llamados chunks) son ordenados por velocidad y se utilizan la mitad ms rpida de ellos para promediarlos y dar el resultado.

3.6.

Parmetros configurables en el CPE del suscriptor que pueden afectar algunas mediciones de desempeo
Muchas de las herramientas de medicin de desempeo de red involucran la

conexin de un CPE (de sus siglas en ingls Customer Premises Equipment) que es un 73

equipo terminal del lado del cliente y que est conectado de alguna forma a la UNI. Un ejemplo de este tipo de herramientas son las que utilizan el paradigma cliente-servidor, en cuyo caso se requiere la conexin de dos equipos terminales en puntos de acceso diferentes de la red. De este modo, los resultados de las pruebas efectuadas pueden verse afectados por los parmetros propios del equipo terminal conectado. En estos casos se recomienda asegurarse de que la interfaz de red del equipo slo est siendo utilizada para la prueba. Otro mtodo que permite en algunos casos modificar los resultados obtenidos en relacin con pruebas de velocidad se relaciona con la configuracin de los parmetros de la ventana TCP; dicha configuracin se expone en la siguiente seccin. 3.6.1. Modificacin de RWIN para afinamiento de TCP RWIN (de sus siglas en ingls Receive Window) se refiere a la ventana de recepcin de TCP. Antes de comprender la importancia del afinamiento de la ventana de TCP para un mejor desempeo de un dispositivo en la red, es necesario comprender las caractersticas intrnsecas del protocolo y que hacen que sea muy importante para el desempeo de muchas de las aplicaciones que se utilizan a nivel de usuario final: 1. Se trata de un protocolo de transporte que permite definir circuitos lgicos punto a punto entre dos protocolos de la capa de aplicacin. Por lo tanto se trata de un protocolo para servicios de uno a uno.

74

2. TCP est orientado a la conexin; por lo tanto, si se pretenden transferir datos a travs de una conexin TCP, los procesos de la capa de aplicacin deben establecer una negociacin de conexin antes de comenzar la transaccin. 3. Todos los datos confiables que se transmiten mediante una conexin TCP se encuentran secuenciados, por lo tanto siempre se espera una confirmacin por parte del receptor. De no recibirse, el segmento ser enviado nuevamente. El receptor se encarga de reordenar los segmentos. 4. Las conexiones TCP se efectan en modo dplex completo. Es decir, se tienen un par de canalizaciones lgicas, una para la salida y otra para la entrada. El protocolo de la capa de aplicacin debe propiciar el correcto anlisis de la secuencia de bytes que ingresa al dispositivo. Ahora bien, para limitar el nmero de datos que se pueden enviar simultneamente y para proporcionar el control del flujo del lado del receptor, los puntos TCP usan una ventana. La ventana son todos los datos de la secuencia de bytes que el receptor permite que el remitente enve. El remitente slo puede enviar los bytes de la secuencia de bytes incluidos en la ventana. La ventana recorre la secuencia saliente de bytes del remitente y la secuencia entrante de bytes del receptor. (Davies, 2007) Entonces, el remitente tendr una ventana de envo y el receptor una de recepcin (en dplex completo). Se establece un acuerdo entre todos los bytes de datos que la secuencia de salida puede enviar desde el remitente y todos los entrantes que el receptor

75

puede recibir. En la Figura 3.10 se muestra el establecimiento de coincidencia entre las ventanas de envo y recepcin. Ahora bien, en el encabezado del segmento TCP existe un campo de 16 bits para la ventana. Cuando el receptor enva un ACK (confirmando la recepcin correcta de bytes), en el campo de ventana se escribe el nmero de bytes que permanecen en la ventana de recepcin. Una vez que la aplicacin enva, confirma y recupera datos, ambas ventanas se mueven hacia la derecha.

Figura 3.10. Establecimiento de coincidencia entre las ventanas de envo y recepcin (Davies, 2007) En la ventana de recepcin pueden existir datos que la aplicacin no ha recuperado o que ha recibido pero no ha reconocido. Por esta razn la ventana TCP posee bytes

76

adicionales. En la Figura 3.11 se observa que el tamao de ventana mximo es fijo mientras que el tamao de la ventana de recepcin actual es variable.

Figura 3.11. Tipos de datos de la ventana de recepcin TCP (Davies, 2007) 3.6.1.1. Modificacin de la ventana de recepcin TCP en Windows 7 para mejorar la tasa de descarga Una vez conocidos los aspectos tericos bsicos relacionados con la ventana TCP de transmisin y recepcin, es posible comprender que la ventana TCP de recepcin juega un papel importante en el desempeo de la tasa de descarga de un usuario final, ya que define la cantidad de datos en bytes que un servidor remoto puede enviar sin haber recibido los paquetes ACK (confirmacin). (Banda Ancha, 2011) De esta forma, una ventana TCP de recepcin pequea provoca que el servidor remoto pueda enviar pocos datos para luego esperar las confirmaciones; si la red tiene una alta latencia, entonces el tiempo que demorarn las confirmaciones en llegar al servidor har que existan lapsos inutilizados en donde no se enviarn datos.

77

La pila TCP/IP en Windows Vista y Windows 7 ajusta dinmicamente el tamao de la ventana de recepcin TCP en funcin de la velocidad de la conexin, por lo que no hace falta modificarla; sin embargo, existen algunos parmetros configurables por el usuario. (Banda Ancha, 2011) Para poder observar los parmetros configurables se debe ejecutar en el smbolo de sistema (CMD de Windows) el siguiente comando: netsh int tcp show global Se obtendr una lista de parmetros comparable a la de la Figura 3.12.

Figura 3.12. Parmetros globales de TCP en Windows 7 El significado de cada uno de estos parmetros se enumera a continuacin: Estado de ajuste de escala en lado de recepcin: permite optimizar el procesamiento de paquetes para computadoras con 2 ncleos o ms en su CPU. Estado de descarga Chimney: permite que algunas tareas relacionadas con el procesamiento de red sean efectuadas por la tarjeta de red y no por el CPU. Estado de NetDMA: permite evitar la utilizacin del CPU para la transferencia de datos entre la red y la memoria del sistema. 78

Acceso directo a cach (DCA): permite que el controlador de red entregue los datos directamente al cach del procesador (en caso de que tanto la tarjeta como la CPU lo soporten). Se puede activar para probar la mejora en la eficiencia de las transacciones de red mediante el comando netsh int tcp set global dca=enabled accediendo al smbolo del sistema como administrador.

Nivel de ajuste automtico de ventana de recepcin: define las polticas que sigue el sistema para el clculo de los lmites mximos del RWIN. Por defecto viene en modo normal que es el recomendable (Banda Ancha, 2011)

Proveedor de control de congestin de complementos: Este es el algoritmo con el que se calcula el RWIN ptimo de cada conexin. En el modo none que viene por defecto se eleva progresivamente el RWIN hasta llegar al lmite o detectar prdida de paquetes. Existe otro modo, el ctcp (de sus siglas en ingls Compound TCP), un algoritmo que calcula el RWIN de forma ms agresiva, lo que reduce el tiempo de arranque de la descarga. Este es el parmetro ms importante que se puede modificar, con resultados visibles en conexiones de ms de 15 Mbps. (Banda Ancha, 2011) Se puede activar con el siguiente comando en el smbolo del sistema y en modo administrador: netsh int tcp set global congestionprovider=ctcp.

Capacidad ECN: detecta los paquetes que el enrutador marca como congestionados antes de que se produzca la prdida de paquetes. Slo enrutadores modernos lo soportan; por lo tanto es necesario hacer la prueba (en el enlace:

http://www.microsoft.com/windows/using/tools/igd/results.mspx) para ver si es 79

soportada esta capacidad. Para activarla se escribe en el smbolo de sistema en modo administrador: netsh int tcp set global ecncapability=enabled. Marcas de tiempo RFC1323: Se insertan 12 bytes en cada paquete con una marca de tiempo. Su funcin es permitir el clculo de la latencia de conexin (a costa de mayor cantidad de overhead). Se puede desactivar escribiendo en el smbolo del sistema en modo de administrador: netsh int tcp set global timestamps=disabled. Desactivando la heurstica: el sistema operativo tiene la capacidad de modificar los parmetros de auto-afinacin. Mediante la desactivacin de la heurstica se fuerza a utilizar los que se han establecido manualmente. Se desactiva escribiendo en el smbolo del sistema en modo administrador: netsh int tcp heuristics disabled. Dos herramientas para la definicin de parmetros de TCP disponibles para Windows XP y posteriores son: DrTCP: una aplicacin gratuita obtenida del sitio web de DSL Reports (sitio especializado en el anlisis del desempeo de las redes de los diferentes proveedores de Internet a nivel mundial) que permite mediante una interfaz grfica modificar los parmetros ms significativos del TCP; entre ellos el tamao de la ventana de recepcin TCP para efectuar varias pruebas y evaluar la mejor opcin de configuracin. TCP Optimizer: es una aplicacin gratuita desarrollada por SpeedGuide (sitio especializado en noticias relacionadas con telecomunicaciones y en el anlisis del desempeo de los parmetros configurados en una PC) que permite mediante una 80

interfaz grfica auto-ajustar o bien ajustar manualmente los parmetros relacionados con el TCP, incluyendo la ventana de recepcin de TCP. En el sitio tambin se puede efectuar una evaluacin en lnea sobre la configuracin de los parmetros a nivel de la PC en la que se est efectuando la consulta. 3.6.1.2. Modificacin de la ventana de recepcin TCP en sistemas operativos basados en Linux A partir de la versin 2.6.17 del kernel de Linux (ao 2006), se implement un sofisticado sistema de auto-afinacin TCP; slo en casos muy raros la afinacin manual de los parmetros TCP en Linux mejorarn sustancialmente el desempeo de la tasa de descarga y subida. Por lo tanto, en Linux no es muy recomendable la modificacin de los parmetros TCP. (Mattis, 2006) A pesar de la observacin del prrafo anterior, los parmetros de TCP pueden ser fcilmente modificables mediante los siguientes comandos ejecutados en la terminal del sistema: Supngase que se desea configurar una ventana de recepcin TCP de tamao 256,960 kb, se ejecuta como sper-usuario en la lnea de comandos: echo 256960 > /proc/sys/net/core/rmem_default echo 256960 > /proc/sys/net/core/rmem_max echo 256960 > /proc/sys/net/core/wmem_default echo 256960 > /proc/sys/net/core/wmem_max echo 0 > /proc/sys/net/ipv4/tcp_timestamps 81

echo 1 > /proc/sys/net/ipv4/tcp_sack echo 1 > /proc/sys/net/ipv4/tcp_window_scaling Para que los cambios no se pierdan cuando se reinicie la computadora se pueden ejecutar los siguientes comandos en la terminal del sistema: net.core.rmem_default = 256960 net.core.rmem_max = 256960 net.core.wmem_default = 256960 net.core.wmem_max = 256960

net.ipv4.tcp_timestamps = 0 net.ipv4.tcp_sack =1 net.ipv4.tcp_window_scaling = 1 Por ltimo, si se desea modificar el valor del MTU se debe aadir la siguiente lnea al archivo /etc/rc.local: ifconfig mi_interfaz mtu valor_requerido

82

4. CAPTULO 4: Implementacin y comparacin analtica de las herramientas de NP

En esta seccin se implementan las herramientas expuestas en el Captulo 3 (desde las ms bsicas hasta las ms complejas) para estructurar un anlisis comparativo de sus funcionalidades, opciones, ventajas y desventajas. Para las pruebas se implement un escenario que simula un servicio de Metro Ethernet sobre MPLS/IP para el transporte del trfico; especficamente un servicio de EPL (de sus siglas en ingls Ethernet Private Line). Este servicio es ofrecido por muchos proveedores de Internet a nivel global (como Comcast Corporation que es considerada una de las mayores empresas proveedoras del servicio de Internet de Banda Ancha en Estados Unidos); por lo tanto, la emulacin efectuada se puede adaptar para muchos de los escenarios encontrados en la vida real. Un servicio EPL corresponde a una EVC (de sus siglas en ingls Ethernet Virtual Connection) de tipo E-line; es decir, una Conexin Ethernet Virtual entre dos UNIs (en el Captulo 2 se definieron estos conceptos) punto a punto.

83

Figura 4.1. Esquema de pruebas implementado En la Figura 4.1 se muestra el diagrama de conexiones e interfaces utilizados para las pruebas. Debe anotarse que la red es de mejor esfuerzo y no efecta ningn tipo de priorizacin de trfico. Los parmetros involucrados en la configuracin de los equipos estn fuera del alcance del proyecto; se estudiaron los aspectos fundamentales relacionados con la configuracin y se cont con la asesora de un especialista en la materia de configuracin de equipos Cisco. Se escogi MPLS/IP como sistema de transporte sobre IS-IS como protocolo de enrutamiento por ser una configuracin ampliamente difundida a nivel de proveedor de servicios de Internet. Adems se limit el ancho de banda a 10 Mbps, mediante la configuracin de los conmutadores. Se utiliz un direccionamiento privado del rango de direcciones 172.16.1.0/24 para las terminales de la EPL. Este rango no tiene relacin con el utilizado en la configuracin de las direcciones IP de los conmutadores utilizados; de hecho, al ser una EPL los equipos 84

terminales piensan que estn directamente conectados a travs de lo que se conoce como un cable falso. Se utiliz como sistema operativo para los equipos terminales la ltima versin LTS (de sus siglas en ingls Long Term Support) de Ubuntu, especficamente el Ubuntu Lucid Lynx 10.04. Esta decisin se bas principalmente en la versatilidad del manejo de las aplicaciones a nivel de terminal del sistema; adems de que se trata de un sistema operativo gratuito y abierto, por lo tanto no fue necesario invertir en la adquisicin de licencias. Adems, las tarjetas de red de las terminales de prueba eran idnticas. Se utiliz el modelo NIC Fast Ethernet PCI Familia RTL 8139 de Realtek (100 Mbps). Su archivo de configuracin se adjunta en el Apndice 1. Las pruebas del RFC 2544 y la Y.1564 de la UIT se efectuaron bajo una plataforma comercial con un licenciamiento de prueba. Dicha plataforma se basa en Windows XP con Service Pack 3.

4.1.

Prueba de implementacin: PING

Se efectu una prueba de PING en la EPL de pruebas de una terminal (172.16.1.3) a la otra (172.16.1.2). El resultado obtenido se muestra en la Figura 4.2.

85

Figura 4.2. Prueba de implementacin del PING Se utiliz un tamao de paquete ICMP de 64 bytes, que es el valor por defecto de la prueba PING y el mnimo permitido. De esta prueba se puede obtener el parmetro de RTT y el de prdida de paquetes. Se tomar el valor promedio de RTT de las 10 pruebas efectuadas; que corresponde a 0,34 ms. Ntese que es un valor muy bajo dado que no existen muchos equipos intermedios conectados. No se observ ninguna prdida de paquetes. Esto es esperable dado que a la red no se le ha inyectado ningn tipo de trfico (salvo el generado por la misma prueba). La Tabla 4.1 resume los resultados de NP obtenidos mediante esta prueba. Tabla 4.1. Mtricas obtenidas con PING
Parmetro de NP Latencia (RTT) Prdida de paquetes Resultado 0,34 ms 0%

86

4.2.

Prueba de implementacin: traceroute

Se utiliz la herramienta traceroute de las herramientas por defecto que incluye el sistema operativo Ubuntu 10.04. En la Figura 4.3 se observa el resultado de la prueba.

Figura 4.3. Prueba de implementacin del Traceroute Hay dos elementos muy importantes que se deben rescatar de esta prueba. El primero de ellos es que desde el punto de vista de la terminal (ProyectoElectricoNP) la otra terminal (ProyectoElectricoNP2) se encuentra directamente conectada; de ah que no se observe ningn otro salto. Es decir, se comprueba el correcto funcionamiento de la EPL implementada. Se debe rescatar la importancia de que los dispositivos piensen que estn directamente conectados a pesar de atravesar una nube MPLS/IP, en el sentido de que se tiene una VPN a nivel de capa 2 del modelo de referencia TCP/IP, lo cual es muy til para grandes compaas que quieren interconectar sus sitios alrededor de un rea geogrfica. El segundo elemento a rescatar es que se puede obtener un dato de las mtricas de NP evaluadas en el captulo anterior; dicho parmetro es el de latencia (RTT). En este caso se tomar el valor promedio de los tres tiempos de respuesta obtenidos que es 0,267 ms. La Tabla 4.2 resume los resultados obtenidos con la herramienta Traceroute. Tabla 4.2. Mtricas obtenidas con Traceroute
Parmetro de NP Latencia (RTT) Resultado 0,267 ms

87

4.3.

Prueba de implementacin: D-ITG

Tal y como se mencion en el Captulo 3, D-ITG es una herramienta para la generacin de trfico la cual permite evaluar activamente las caractersticas de desempeo de una red a travs de un analizador de resultados. Es una aplicacin gratuita y de cdigo abierto. Fue desarrollada por Stefano Avallone y Antonio Pescap del Departamento de Sistemas e Informtica de la Universidad Federico II de Napoli en Italia. El proyecto est actualmente vigente. (Botta, Dainotti, & Pescap, 2011) Una de las capacidades ms interesantes de esta aplicacin es que permite generar archivos tipo script en donde se indican los parmetros de la generacin de trfico que se quiere efectuar, pudiendo emular trfico de datos, VoIP, Telnet, etc. Es decir, trfico de la capa de aplicacin, de red o de transporte. Adems, se pueden emular procesos estocsticos y especificar distintas distribuciones de tamaos de paquetes en la generacin de trfico (exponencial, uniforme, normal, cauchy, pareto, etc.). Dichas atribuciones son las que permiten al final de cuentas generar trfico equivalente al de una llamada de VoIP por ejemplo. La herramienta es capaz de efectuar todas las mediciones relacionadas con la prueba EtherSAM (Y.1564 de la UIT) para Ethernet y Metro Ethernet. Especficamente los cuatro parmetros principales requeridos en dicho estndar: ancho de banda, FTD (RTT), FTV (jitter) y FL (prdida de paquetes).

88

Se podra disear un plan que se acoja a las disposiciones de la prueba EtherSAM para crear una plataforma de pruebas cuyo motor de generacin de trfico sea D-ITG. Sin embargo, dicha implementacin se sale de los alcances del presente proyecto. 4.3.1. Instalacin de D-ITG con D-ITG GUI Para las pruebas de implementacin de D-ITG se utiliz una interfaz grfica diseada en java por Volker Semken como complemento del motor de generacin D-ITG. (Semken, 2011). El motor generador bsicamente se compone de cuatro programas: ITGSend: Es el programa generador de trfico de la plataforma. ITGRecv: Es el programa receptor de trfico de la plataforma. ITGLog: Es el programa que inicia un servidor de logs para capturar todos los datos del trfico transportado. ITGDec: Permite decodificar toda la informacin generada en el log de ITGSend y en el log de ITGRecv. Adems de estos cuatro programas, existen dos complementos que son muy tiles y que cabe mencionarlos: ITGPlot: Con la ayuda de Octave (programa gratuito y de cdigo abierto para el procesamiento numrico con capacidad para graficar tablas de resultados o ecuaciones matemticas), toma los datos decodificados por ITGDec y los grafica.

89

ITGApi: Se trata de un API (de sus siglas en ingls Application Programming Interface) para C++ que permite automatizar el uso de D-ITG a travs de programas escritos en este lenguaje. Para la instalacin del motor de la generacin de trfico D-ITG se deben seguir los

siguientes pasos: 1. Descargar la versin ms reciente de D-ITG de: http://www.grid.unina.it/software/ITG/download.php 2. Abrir una terminal del sistema y pasarse a modo superusuario con sudo s 3. Crear una carpeta en /root/ llamada DITG. Copiar los archivos descomprimidos a /root/DITG/ 4. Moverse a la carpeta de archivos fuente: cd /root/DITG/src/ 5. Compilar los archivos fuente mediante: make 6. Si se quiere ejecutar alguno de los programas mencionados anteriormente simplemente se debe ir a la carpeta de binarios haciendo en la terminal del sistema cd /root/DITG/bin/. Una vez en la carpeta de binarios simplemente se ejecutan utilizando ./. Por ejemplo, para ejecutar el programa de recepcin de trfico se utiliza ./ITGRecv. Para la instalacin de la interfaz grfica se deben seguir los siguientes pasos: 1. Descargar la versin ms reciente de D-ITG GUI de: http://www.semken.com/projekte/index.html 2. Abrir una terminal del sistema y pasarse a modo superusuario con sudo s 90

3. Descomprimir los archivos en la carpeta /root/DITG/src/ 4. Instalar los siguientes paquetes mediante la terminal del sistema: apt-get install openjdk-6-jre g++ octave3.0 5. La ejecucin se debe hacer desde la carpeta en donde se descomprimi: cd /root/DITG/src/ y luego para ejecutarlo: java jar ITGGUI.jar 4.3.2. Ejecucin de pruebas en D-ITG con D-ITG GUI Para ejecutar las diferentes pruebas es necesario seguir los siguientes pasos (en modo superusuario haciendo sudo s): 1. Se ejecuta el programa que recibir el trfico generado a travs de la ejecucin de ITGRecv en uno de los equipos terminales de la EPL de pruebas. Para ello se escribe en la terminal cd /root/DITG/bin/ y luego ./ITGRecv. 2. En el equipo terminal del otro extremo se ejecuta la interfaz grfica escribiendo en la consola del sistema: cd /root/DITG/src/ y luego java jar ITGGUI.jar. 3. Colocar la configuracin mostrada en la Figura 4.4. Es importante que el directorio especificado en Logging directory tengan permisos de escritura. En este caso los archivos de log se escribirn en /root.

91

Figura 4.4. Configuracin de D-ITG GUI 4. Definir los flujos que se generarn utilizando la pestaa Define Flow. 5. Presionar el botn Send. Es muy importante que el programa ITGRecv se est ejecutando en el equipo terminal receptor. 6. Una vez terminada la corrida de la generacin de trfico, se debe configurar el analizador con las opciones mostradas en la Figura 4.5.

92

Figura 4.5. Configuracin del analizador de D-ITG GUI 7. Presionamos el botn Run Analyzer. Se crearn en /root/DITG/src/ los archivos bitrate.txt, jitter.txt, packetloss.txt y delay.txt. 8. Para graficar los resultados se modifica el archivo /root/DITG/src/ITGPlot (utilizando VIM u otro editor de texto) colocndole en la primer lnea la versin de Octave adecuada (en este caso Octave 3.0). Adems, se debe agregar un loop al final de este script para que la grfica desplegada no se cierre automticamente. Se pueden introducir las siguientes lneas al final del archivo: s=1, while(s), endwhile. 9. Darle permisos de ejecucin al archivo /root/DITG/src/ITGPlot 10. Ubicarse en la carpeta adecuada mediante cd /root/DITG/src/ITGPlot y ejecutar el programa para obtener la grfica deseada mediante ./ITGPlot

93

/directorio_donde_se_encuentra_el_archivo_a_graficar.txt. En este caso se trata de los archivos bitrate.txt, jitter.txt, packetloss.txt y delay.txt. 4.3.3. Pruebas de implementacin ejecutadas 4.3.3.1. Prueba UDP

Se efectu una prueba de trfico UDP simple. La configuracin utilizada para la prueba se observa en la Figura 4.6. Ntese la gran cantidad de opciones que se ofrecen para la generacin del trfico. En este caso se generaron paquetes con un tiempo de generacin uniformemente distribuido con 1000 paquetes por segundo como mnimo y 2000 como mximo. El tamao de los paquetes variar en una distribucin normal con una media de 1000 bytes.

Figura 4.6. Configuracin de la prueba UDP 94

La prueba se configur para 30 segundos y se medir el one-way-delay o la latencia en un solo sentido. El emisor es la terminal con la direccin IP 172.16.1.2 y el receptor la terminal con la direccin IP 172.16.1.3. Este direccionamiento se mantiene para todas las pruebas efectuadas. Una observacin importante es que el programa es capaz de calcular el ancho de banda mximo que se requerir para poder transportar los datos. En este caso 8224 kbps, que debera ser transportado sin problemas dado que el lmite de ancho de banda configurado en el escenario es de 10 Mbps. Luego de ejecutar la prueba se obtuvieron con ayuda de la herramienta Octave 3.0 las grficas de la Figura 4.7, la Figura 4.8, la Figura 4.9 y la Figura 4.10.

Figura 4.7. Grfica de bits transmitidos en funcin del tiempo en la prueba UDP de DITG

95

Figura 4.8. Grfica de jitter en prueba UDP de D-ITG

Figura 4.9. Grfica de prdida de paquetes en prueba UDP de D-ITG

96

Figura 4.10. Grfica de retardo en prueba UDP de D-ITG Ntese el efecto de la aplicacin de la distribucin normal para el tamao de las tramas en la grfica de bits. No se debe confundir la grfica de bits en funcin del tiempo con el ancho de banda. Se debe recordar que el ancho de banda se refiere a una razn de bits por una unidad de tiempo, normalmente un segundo. Se tomaron los datos de la tabla de la grfica de la Figura 4.7 y se calcul el ancho de banda promedio con un valor de 8254 bytes por segundo. Este resultado es muy similar al valor estimado por el programa. Naturalmente, no se present prdida de paquetes ni jitter. Adems el retardo de one-way-delay es tan pequeo que en la grfica es prcticamente imperceptible. Sin embargo, de acuerdo con los datos de la tabla correspondientes a la grfica de la Figura 4.10 la latencia en un solo sentido es de 0,127 ms.

97

En la Tabla 4.3 se resumen los resultados obtenidos mediante esta prueba y que se relacionan con parmetros de medicin de NP. Tabla 4.3. Mtricas obtenidas en prueba UDP de D-ITG
Parmetro de NP Latencia (One-way-delay) Ancho de banda utilizado Prdida de paquetes Jitter Resultado 0,127 ms 8254 bytes por segundo 0% 0%

En esta prueba se comprueba el gran potencial de la herramienta para la generacin y anlisis del trfico. Dada la posibilidad de generar scripts para estructurar distintos escenarios de trfico, la herramienta D-ITG es un candidato muy fuerte para automatizar el procedimiento de pruebas de medicin tanto del RFC 2544 como del Y.1564. Debe agregarse el potencial para emular trfico de VoIP y la posibilidad de generar mltiples flujos; lo cual permite evaluar el comportamiento de la red en pruebas out-ofservice. La comparacin posterior con la plataforma comercial permitir analizar ms a fondo los alcances de D-ITG. 4.3.3.2. Prueba TCP

Se efectu una prueba de TCP para comprobar algunas otras caractersticas de la herramienta D-ITG. En este caso se satur la capacidad mxima de ancho de banda de la red (10 Mbps); esperando de ese modo prdida de paquetes, jitter y un retardo ms elevado. De igual forma el throughput debe verse afectado.

98

Figura 4.11. Configuracin de la prueba TCP en D-ITG En la Figura 4.11 se muestra la configuracin implementada. En esta ocasin se medir el RTT en lugar del one-way-delay. Adems, se generar trfico en intervalos constantes y con tamaos constantes. Se generarn 200000 paquetes por segundo con un tamao de 10000 bytes. Se requerir un ancho de banda de 16064000 kbps; que evidentemente supera los 10 Mbps disponibles en la EPL. Luego de ejecutar la prueba y con la ayuda de la aplicacin de cdigo abierto Octave 3.0 fue posible obtener las grficas de la Figura 4.12, la Figura 4.13, la Figura 4.14 y la Figura 4.15. Los resultados de la presente prueba no fueron del todo satisfactorios. Segn se observa en la Figura 4.12 la densidad de bits generados no fue de 200000 paquetes por 99

segundo. Adems de este inconveniente, evidentemente se observa una limitacin fsica en relacin con el hardware de red implementado; es decir, la interfaz Fast Ethernet (100 Mbps) no soport tal generacin de paquetes, los cuales requeriran al menos 16 Gbps de ancho de banda. Es necesario contemplar este aspecto como una limitante a la hora de la comparacin analtica de las herramientas.

Figura 4.12. Grfica de bits en funcin del tiempo de la prueba TCP en D-ITG

100

Figura 4.13. Grfica de prdida de paquetes de la prueba TCP en D-ITG

Figura 4.14. Grfica de jitter de la prueba TCP en D-ITG

101

Figura 4.15. Grfica de retardo de la prueba TCP en D-ITG Ahora bien, en la grfica de la Figura 4.13 puede observar la gran cantidad de prdida de paquetes por cada envo de bits efectuado. Luego de efectuar un anlisis cuantitativo de la tabla de datos de la prdida de paquetes y la tabla de datos de los paquetes generados (en la misma tabla de bits enviados) se calcul un 87,45% de prdida de paquetes. Es notable que la prdida tan abundante de paquetes se debi a la alta tasa de transferencia configurada. La grfica de la Figura 4.14 muestra el jitter en razn del tiempo. Dada la saturacin de la red, el jitter lleg a valores de hasta 50 ms. Este valor es inaceptable si la red se destina al trfico de VoIP u otras aplicaciones sensibles al tiempo. El valor promedio de jitter obtenido fue de 31,23 ms. Por ltimo, la grfica de la Figura 4.15 de retardo muestra valores negativos ya que segn se consult en el sitio web de D-ITG, se obtuvieron valores tan altos que la 102

herramienta descarta al considerar absurdos, dando como resultado valores negativos. Esto demuestra que la saturacin de la red produjo prcticamente la cada de la misma al punto de tener retardos inmanejables. Se aprovech esta prueba para observar el comportamiento de la herramienta para monitoreo de las transferencias de red que por defecto incluyen las distribuciones de Ubuntu. Esta herramienta funciona bajo la misma premisa que la herramienta NetPerSec presentada en el Captulo 3 (por SNMP). En la Figura 4.16 se muestra el estado de la transferencia de red en la mquina receptora del trfico generado por D-ITG. Ntese que se obtuvo un pico de trfico de aproximadamente 10 Mbps; esto coincide con el ancho de banda limitado mediante la EPL de pruebas.

Figura 4.16. Grfica de transferencias de red del monitor del sistema por defecto de la distribucin Ubuntu 4.3.3.3. Prueba de flujos mltiples

Una de las ventajas ms importantes de D-ITG es que tiene la habilidad de generar mltiples tipos de trfico simultneamente. Esta caracterstica lo hace un buen candidato para la aplicacin de la metodologa de pruebas de la recomendacin Y.1564. 103

En la Figura 4.17 se muestra la configuracin global de la prueba de mltiples flujos efectuada. Se generarn paquetes Telnet 5 segundos despus de iniciada la prueba; paquetes de VoIP 10 segundos despus de iniciada la prueba con el CODEC G.711 (estndar de la UIT de compresin de audio) y 3 tres tipos distintos de flujo de datos UDP.

Figura 4.17. Configuracin de la prueba de mltiples flujos en D-ITG Ntese que el ancho de banda aproximado que requerir la prueba es de 10372 bps. Por lo tanto, la EPL est en condiciones de soportar este trfico. Luego de ejecutar las pruebas y con ayuda de la aplicacin Octave 3.0 se obtuvieron las grficas de la Figura 4.18, Figura 4.19, Figura 4.20 y Figura 4.21. En la Figura 4.18 se observa claramente la convergencia de los servicios. El flujo de bits ms alto corresponde a los paquetes de datos (generados en intervalos constantes y de tamao constante); por su parte, el flujo de bits denso que se observa en la parte inferior corresponde a la

104

combinacin del flujo Telnet, el de VoIP y los otros dos flujos de datos. El flujo de Telnet y el de VoIP son sumamente pequeos, por lo tanto son prcticamente imperceptibles.

Figura 4.18. Grfica de bits en funcin del tiempo para la prueba de flujos mltiples de D-ITG

Figura 4.19. Grfica de retardo para la prueba de flujos mltiples de D-ITG

105

Figura 4.20. Grfica de prdida de paquetes para la prueba de mltiples flujos de DITG

Figura 4.21. Grfica de jitter en la prueba de mltiples flujos de D-ITG

106

Es importante anotar que al ser D-ITG un generador que incluye un API para C++, entonces es posible escribir scripts para SHELL (lnea de comandos) o bien para C++ en el cual se simulen flujos de miles de llamadas de VoIP simultneamente. Dicha habilidad es sumamente importante si se pretende comprobar el alcance de la red para la implementacin del servicio de VoIP. Evidentemente no es necesario implementar la GUI para este tipo de pruebas. Los comandos necesarios para escribir los scripts se suministran en la documentacin de la herramienta de forma clara y extensa. Por ltimo, tal y como se calcul al inicio, la red es capaz de soportar el flujo de trfico inyectado, por lo tanto no se present prdida de paquetes ni jitter. El retardo nuevamente es tan pequeo que en la grfica no se percibe. El valor de latencia RTT obtenido fue de 0,254 ms.

4.4.

Prueba de implementacin: Netperf

Tal y como se expuso en el Captulo 3, Netperf es una herramienta de benchmarking que permite efectuar mediciones de desempeo para cualquier tipo de red. Utiliza el paradigma cliente-servidor y puede operar las pruebas sobre varios protocolos como UDP o TCP. 4.4.1. Instalacin de Netperf Adems de su gran potencial como una herramienta de medicin de desempeo de redes, Netperf es fcil de instalar. A continuacin se enumera dicho procedimiento: 107

1. Descargar

la

versin

ms

reciente

de

Netperf

del

siguiente

enlace:

ftp://ftp.netperf.org/netperf 2. Extraer el archivo. 3. Ingresar al directorio recin descomprimido mediante cd /direccin/del/directorio 4. Escribir los siguientes comandos: sudo ./configure, sudo make y sudo make install. 5. Para iniciar el servidor se debe escribir: netserver. El servidor debe iniciarse en una de las dos terminales. En el caso de la EPL de pruebas se inici en la terminal ProyectoElectricoNP. 4.4.2. Prueba throughput De acuerdo con el mismo creador de Netperf, Rick Jones, una prueba estndar de medicin de throughput en flujos TCP consiste en almacenar el nmero de bytes transmitidos completamente durante la longitud de la prueba y dividir ese resultado por el tiempo de la prueba (Jones, Netperf, 2011). A pesar de que esta definicin no se adapta a la definicin de throughput emitida en el RFC 2544, en la seccin dedicada a la comparacin final se observa cmo el valor de throughput obtenido mediante Netperf es prcticamente idntico al obtenido con la herramienta comercial adaptada al RFC 2544. Netperf simplemente coloca bytes en un socket, suponga que TCP es un protocolo de flujo de bytes. (Jones, Netperf, 2011). Es decir, se utilizar el MTU para la transmisin de datos y el tamao de las tramas ser el mayor posible. 108

Para la ejecucin de esta prueba se escribi un script que generara 10 pruebas de throughput. El cdigo implementado se escribi en script de Shell y se muestra en la Figura 4.22.

Figura 4.22. Script de Netperf para el clculo del throughput El comando netperf H 172.16.1.3 P 0 utilizado indica que el servidor se encuentra en 172.16.1.3 y la opcin -P indica que no se deben imprimir en consola los ttulos de los parmetros. Para ejecutar el script es necesario darle permisos de ejecucin al archivo y escribir en la terminal del sistema ./Nombre_del_script.sh. El resultado de la ejecucin se muestra en la Figura 4.23. La primera columna indica el tamao del socket receptor en bytes, la segunda columna el tamao en bytes del socket transmisor, la tercer columna indica el tamao en bytes del mensaje enviado, la cuarta columna indica el tiempo transcurrido de la prueba (se puede variar) y la ltima columna indica el throughput en Mbps.

109

Figura 4.23. Prueba de throughput con Netperf En promedio se obtuvo un throughput de 10,922 Mbps. Este resultado tiene mucho sentido, ya que en la EPL el ancho de banda se limit a aproximadamente 10 Mbps como ya se haba indicado. 4.4.3. Prueba throughput con omni test Adems de inspeccionar las ventajas de la escritura de scripts para la automatizacin de las pruebas, Netperf ofrece un conjunto de resultados mediante sus pruebas omni. Hay una lista que supera las cien opciones en el manual de Netperf (Jones, NETPERF, 2011) para las pruebas omni. Se efectu una prueba de throughput con la omni test; el resultado se observa en la Figura 4.24. El comando utilizado fue: netperf t omni I 99 H 172.16.1.3 --d send O

MEAN_LATENCY,LOCAL_SEND_SIZE,THROUGHPUT,THROUGHPUT_UNIT S T TCP H 172.16.1.3 m 1M. Donde, -t se refiere al tipo de prueba, en este caso omni; -I 99 se refiere a que se quiere un 99% de confianza en la prueba; -H 172.16.1.3 se refiere a la direccin IP donde se ubica el servidor; luego se utiliza el separador - - para desligar las opciones 110

globales de las especficas de la prueba; -d send indica que se trata de una prueba en un solo sentido; -O y todas las opciones en mayscula se refieren a los parmetros a medir; -T TCP se refiere a que se trata de una prueba TCP; -H 172.16.1.3 indica a las opciones especficas la ubicacin del servidor y por ltimo -m 1M indica que se quiere transmitir un megabyte de informacin.

Figura 4.24. Prueba de throughput con omni test de Netperf En este caso se obtuvo una media de latencia elevada ya que la prueba no es especficamente para la medicin de latencia; ms bien, el valor obtenido muestra la duracin de la prueba. Ntese la versatilidad de la aplicacin y remrquese la opcin de porcentaje de confianza de 99; la cual es una garanta segn Jones de que el valor de throughput real estar entre 2.5% del valor mostrado. Nuevamente se aprovech esta prueba para probar el monitor del sistema de la distribucin Ubuntu para el trfico de red. En este caso se obtuvo el resultado de la Figura 4.25. Nuevamente se observa la duracin de la prueba y un aproximado de 11 Mbps utilizados. Este resultado coincide con el obtenido analticamente.

111

Figura 4.25. Monitor de trfico de red en Ubuntu para prueba de Netperf 4.4.4. Prueba latencia (RTT) Se efectu una prueba de latencia RTT. Para ello se utiliz una prueba omni; con las siguientes opciones: netperf I 99 t omni H 172.16.1.3 -- -T TCP d rr O MEAN_LATENCY, P50_LATENCY, P99_LATENCY, STDDEV_LATENCY, CONFIDENCE_LEVEL Donde todas las opciones ya se estudiaron, a excepcin de -d rr que se refiere a que es una prueba de ida y vuelta o request-reply. Esto es necesario para llevar a cabo el clculo del RTT. La Figura 4.26 muestra el resultado obtenido.

Figura 4.26. Prueba de RTT en Netperf Ntese que el valor obtenido fue de 0,257 ms con una desviacin estndar de 95,59 ms. La medicin de la latencia se efecta segn Jones calculando los segundos por arribo en microsegundos por transaccin de un extremo a otro y luego de vuelta (Jones, Netperf, 2011). 112

Adems del valor promedio de latencia, se puede calcular el percentil 50, 90 y 99 de la misma. De acuerdo con los resultados obtenidos, se puede decir que Netperf es una herramienta sumamente poderosa para efectuar pruebas de desempeo sobre redes en produccin. La capacidad de poder ejecutar scripts con distintas pruebas de medicin de desempeo la convierten en una herramienta sumamente til para la medicin de los parmetros de desempeo solicitados por la SUTEL; ya que no se hace necesario aplicarlo sobre redes fuera de servicio. En otras palabras, se comprob la factibilidad de programacin mediante Netperf para efectuar pruebas en la periodicidad deseada mediante la herramienta Cron (programador peridico de tareas) en Linux. Si dichas mediciones se efectan en la hora cargada media entonces es posible recopilar datos de desempeo para reconocer el mbito de cumplimiento o incumplimiento en relacin con la norma internacional y nacional.

4.5.

Prueba de implementacin: Bing

Bing es una herramienta para la medicin del throughput entre dos puntos terminales de un enlace. La aplicacin viene por defecto incluida en los repositorios de Ubuntu; por lo tanto para la instalacin debe escribirse en lnea de comandos sudo apt-get install bing. Se efectu una prueba muy poco satisfactoria. Para ello se especific en lnea de comandos: sudo bing 172.16.1.2 172.16.1.3 113

Donde las dos direcciones IP indicadas representan los puntos extremos del enlace a medir. El resultado obtenido se muestra en la Figura 4.27. Se obtuvo un throughput de 29,257 Mbps; evidentemente hay un error en el resultado obtenido que se debe a que el Bing mide el throughput con base al retardo de transmisin; sin embargo, al ser un retardo tan pequeo la aplicacin no lo puede manejar y al efectuar la divisin para obtener la tasa de transferencia real se obtiene un nmero ms grande. Este defecto se comenta en el propio manual original de Bing (Beyssac, Bing Man Page, 1995)

Figura 4.27. Prueba de throughput mediante la herramienta Bing 114

Se descarta Bing como una opcin utilizable en el contexto del presente proyecto de investigacin, dado el problema presentado en el clculo.

4.6.

Prueba de implementacin: MGEN

MGEN es una herramienta muy compleja para la generacin de trfico. Fue desarrollada por el departamento Naval Research Laboratory de Washington DC en Estados Unidos. (U.S. Navy, 2011) Permite la emulacin de trficos de nivel de aplicacin como VoIP; adems, puede implementar protocolos de transporte como TCP y UDP y de red como IP. Al igual de D-ITG y Netperf, es una herramienta cuya generacin de trfico puede ser programada mediante scripts. Sin embargo, esta herramienta en particular posee su propia sintaxis de script (no es necesario implementar scripts de Shell como en el caso de Netperf). Adems de MGEN se implement una herramienta complementaria que permite graficar los resultados obtenidos en MGEN, esta aplicacin se llama TRPR (U.S. Navy, 2011). Nuevamente se trata de una herramienta para probar redes out-of-service. Tambin cabe mencionar que MGEN aprovecha el campo de payload de la trama Ethernet para comunicarse con el servidor MGEN (recordar que utiliza el paradigma cliente-servidor), por lo que no produce mayor cantidad de bytes innecesarios.

115

4.6.1. Instalacin de MGEN con TRPR La instalacin de la herramienta MGEN es muy simple. Se debe descargar el paquete (http://downloads.pf.itd.nrl.navy.mil/mgen/), se descomprime y se ejecuta desde el mismo directorio en el que se descomprimi con ./mgen opciones_de_la_prueba. De igual forma, para la instalacin de la herramienta para generar las grficas, se descarga el paquete (http://downloads.pf.itd.nrl.navy.mil/proteantools/), se descomprime y luego se compila el cdigo con g++ -o trpr trpr.cpp lm. Se debe instalar GNUplot con sudo apt-get install gnuplot. Ahora bien, para graficar los resultados se debe escribir en el mismo directorio en el que se compil: ./trpr mgen input <archivo_log_de_mgen> auto X output <nombre_de_la_grafica>. 4.6.2. Prueba TCP Se efectu una prueba sencilla de TCP. Se transmite un flujo de datos de 100 megabits en 10 segundos (es decir, se requerir 10 Mbps de ancho de banda que es aproximadamente el lmite impuesto a la EPL). Para la prueba simplemente se debe ejecutar en la lnea de comandos del receptor las siguientes instrucciones: ./mgen event "listen TCP 5000" output TCP_100Mbits.drc Donde event seala el tipo de evento que se debe ejecutar. En este caso escuchar por el puerto 5000 y utilizando TCP. Luego, la salida de los resultados se pasar al archivo

116

TCP_100Mbits.drc. La extensin .drc se trata de una nomenclatura histrica de MGEN, sin embargo, puede utilizarse cualquier otra extensin. Por su parte, en el emisor deben ejecutarse los siguientes comandos: ./mgen event "0.0 on 1 tcp dst 172.16.1.3/5000 periodic [1 12500000] count 1" Donde se declara el evento que es la generacin en el instante 0.0 encendiendo (on) el primer flujo de datos (1) en tcp cuyo destino es dst 172.16.1.3 en el puerto 5000 (/5000). Adems se generar un nico flujo peridico de 1 megabit de longitud (periodic [1 12500000] count 1). Ntense los rasgos intuitivos alrededor de la sintaxis utilizada para generar el evento. Luego de ejecutar la prueba se gener en la terminal receptora el archivo TCP_100Mbits.drc; entonces se procede a ejecutar en el directorio de TRPR: ./trpr mgen input TCP_100Mbits.drc auto X output TCP_100Mbits El resultado obtenido se muestra en la Figura 4.28. Ntese que el ancho de banda para los 10 segundos de prueba se mantuvo aproximadamente en 11 Mbps. Adems de la grfica obtenida, se obtuvo un throughput de 11,05 Mbps, una latencia RTT de 0,259 ms, un jitter de 0 ms y una prdida de paquetes del 0%. Todos estos datos son capturados por el archivo del receptor.

117

Figura 4.28. Grfica de ancho de banda en funcin del tiempo para MGEN Adems de las opciones mostradas en la presente prueba, la herramienta permite generar trfico de VoIP y cualquier otro patrn de trfico IP (peridico, Poisson, burst, etc.) mediante su herramienta de scripting. 4.6.3. Grfica del trfico en tiempo real Una capacidad muy interesante del MGEN es que al complementarse con la herramienta TRPR se pueden utilizar todas las aplicaciones de programacin en Linux para crear otras implementaciones de la herramienta. Por ejemplo, es posible monitorear el trfico generado por MGEN en tiempo real y de este modo estudiar las caractersticas del comportamiento de la red bajo los escenarios que se hayan programado. Se debe recordar que esta herramienta al igual que D-ITG es capaz generar mltiples flujos de trfico simultneamente. Para esta prueba se utiliz el siguiente conjunto de comandos del lado del receptor: 118

./mgen flush event "LISTEN TCP 5000" | trpr mgen window 5 history 300 real auto X multiplot rate | gnuplot -noraise persist Por su parte del lado del emisor se gener el mismo trfico que en la prueba

anterior, slo que esta vez no se limit la cuenta a 1, por lo que el trfico se generar sin lmite de tiempo: ./mgen event "0.0 on 1 tcp dst 172.16.1.3/5000 periodic [1 12500000]" Luego de ejecutar ambos conjuntos se obtiene una grfica que vara en tiempo real del trfico generado por MGEN, tal y como se muestra en la Figura 4.29.

Figura 4.29. Grfica en tiempo real del ancho de banda en funcin del tiempo para MGEN

4.7.

Prueba de implementacin: mdulo comercial

La plataforma comercial probada funciona sobre el sistema operativo Windows XP. Est constituida fsicamente por dos puertos Fast Ethernet (100 Mbps), 1 puerto Gigabit 119

Ethernet (1 Gbps) y un puerto Ten Gigabit Ethernet (10 Gbps). Tambin posee capacidad de conexin a redes inalmbricas, navegador web y todas las herramientas bsicas incluidas en un entorno de Windows XP. Mediante la incorporacin de un mdulo, es posible implementar la plataforma para la aplicacin de pruebas de desempeo de Ethernet y Metro Ethernet. Especficamente el RFC 2544 y la recomendacin Y.1564 de la UIT. Se aplicaron ambas metodologas de pruebas a la red EPL implementada. De este modo se tendr una visin en relacin con las herramientas comerciales ofrecidas. Bsicamente, el mdulo ofrece un software privado de generacin de trfico (similar a D-ITG y MGEN) con una serie de procesos automatizados que permiten obtener un reporte final de resultados para cada prueba efectuada. Al igual que D-ITG y MGEN, esta herramienta se dise para efectuar pruebas en redes out-of-service. Adems de tenerse las metodologas de pruebas Y.1564 y RFC 2544 se cuenta con otras herramientas adicionales como la prueba BERT (de sus siglas en ingls Bit Error Rate Test), un generador de trfico, la herramienta Ping, la herramienta Trace Route, entre otras. 4.7.1. Metodologa de pruebas La topologa de la prueba efectuada es anloga a la de las pruebas anteriores; salvo que se utilizan como terminales la plataforma comercial y un bucle (loopback) en el otro extremo de la EPL. Este ltimo dispositivo se utiliza simplemente como un reflector para 120

efectuar las pruebas de extremo a extremo que se incluyen en la validacin de las metodologas RFC 2544 y la recomendacin UIT Y.1564. Tambin es posible efectuar pruebas donde ambas terminales son plataformas. De este modo se pueden realizar pruebas llamadas Dual Test Set, en este tipo de pruebas es posible validar la red con resultados independientes en ambos sentidos. Se asign la direccin IP 192.168.1.2 al extremo de la plataforma y la direccin 192.168.1.1 al extremo del bucle. La programacin de la direccin IP del bucle se efecta ingresando al dispositivo mediante Telnet y utilizando los comandos indicados en el manual de usuario de este dispositivo; en este caso se ingresa a la opcin de configuracin global y se asigna la direccin IP (192.168.1.1) y la mscara de red (se utiliz 255.255.255.0). 4.7.2. Prueba Y.1564 Se configura el uso del puerto Fast Ethernet (100 Mbps) y la opcin de autonegociacin para la velocidad del puerto. Adems, en las opciones de red, simplemente se asigna a la plataforma la direccin IP 192.168.1.2 con la mscara de red 255.255.255.0. Se habilit el veredicto de Aprueba/Reprueba (Pass/Fail), mediante este veredicto la prueba dictaminar si la red satisface los parmetros de SLA definidos en la configuracin de servicios. Adems, es necesario efectuar el descubrimiento del dispositivo de bucle presionando el botn Discover Remote seguido de la opcin Loop Up.

121

Una vez configuradas las opciones globales y activado el bucle; es necesario seleccionar los parmetros de los servicios que se probarn en la red. Es posible configurar hasta 10 servicios segn tres categoras: video, VoIP y datos. Una vez seleccionado el servicio a emular, se deben configurar los parmetros de SLA; especficamente el CIR, el EIR, el Overshoot (capacidad sobre el EBS), el jitter mximo, el porcentaje de prdida de paquetes mximo y la latencia RTT mxima. Estos valores son los que definen si se aprueba o reprueba la prueba de validacin segn la metodologa de la UIT Y.1564. Por ltimo, se debe seleccionar la configuracin de la rampa. En el Captulo 3 se estudi la estructura de la metodologa de pruebas de la UIT Y.1564; ah se definieron los conceptos relacionados con la rampa. Se utiliz la configuracin por defecto de la rampa. 4.7.2.1. Prueba de datos de 5 Mbps

Se configur un servicio de datos de 5 Mbps. Tericamente la red es capaz de soportar todo ese trfico, por lo tanto, el veredicto final debera ser aprobado. Luego de efectuar todos los pasos de configuracin de la prueba, se presiona el botn Start. Primero se ejecuta la prueba de Service Configuration y luego la de Service Performance tal y como se anot en el Captulo 3. En ambos casos se muestra un signo de aprobacin verde con la palabra Pass indicando que todos los parmetros de SLA establecidos se cumplen; tal y como se esperaba.

122

Se obtuvo un jitter mximo insignificante (con respecto al mbito estipulado por la recomendacin UIT Y.1541 mostrado en el Captulo 2 para servicios de clase 0) de alrededor de 88 s. Se puede observar la obtencin de un throughput perfecto en relacin con la cantidad de datos transmitidos. El valor del overshoot configurado fue el mismo que el valor para el CIR, por lo tanto, si el CIR se cumple el overshoot tambin. En otras palabras la prueba no admite overshoot para los posibles suscriptores del servicio. Los resultados obtenidos en la prueba de desempeo del servicio se resumen en la Tabla 4.4. Tabla 4.4. Mtricas obtenidas en prueba Y.1564 de datos de 5 Mbps
Parmetro de NP Latencia (RTT) Ancho de banda utilizado Prdida de paquetes Jitter Resultado 0,18 ms 5 Mbps 0% Menos de 15 s

4.7.2.2.

Prueba de datos de 15 Mbps

Se configur un servicio de datos de 15 Mbps. Tericamente la red no es capaz de soportar todo ese trfico, por lo tanto, el veredicto final debera ser reprobado. Luego de ejecutar la prueba en ambos casos se observa una notificacin en rojo que dice Fail (reprobado); es decir, no es posible cumplir con los requerimientos de SLA para el trfico emulado; tal y como se esperaba ya que la EPL se limit a un ancho de banda de aproximadamente 10 Mbps. 123

En la prueba de configuracin de servicio se puede observar que la red soport los valores de SLA hasta el escaln del 90% del CIR, para un throughput de 13,5 Mbps; es decir, se super el rango de 10 Mbps en el que se haba limitado la EPL. Evidentemente el valor de throughput es calculado por la herramienta con algn mtodo que no necesariamente refleja el verdadero valor de la EPL. Al ser una herramienta comercial privada, los mtodos exactos con los que se efectan las pruebas son desconocidos. Adems, se debe tomar en cuenta que la prueba de datos se hace implementando UDP como protocolo de transporte; por lo tanto, no son requeridas las retransmisiones, esto podra generar que el clculo del throughput sea ms alto en relacin con el resultados de otras herramientas. A pesar de dicha situacin, se considera que la prueba no est diseada para la medicin del throughput sino ms bien para comprobar el desempeo de la red ante la transmisin de cierto tipo de trfico; en este caso se logr determinar que la red no podr dar garanta sobre los parmetros de desempeo. Otra anotacin importante es que el parmetro de jitter nunca incumpli el SLA establecido, pero s la latencia y la prdida de paquetes, que son parmetros determinantes para la transmisin de datos sobre redes Ethernet y Metro Ethernet. Por su parte, la prueba de desempeo de servicio arroja los resultados globales obtenidos para los KPI; los cuales se resumen en la

Tabla 4.5.

124

Tabla 4.5. Mtricas obtenidas en prueba Y.1564 de datos de 15 Mbps

Parmetro de NP Latencia (RTT) Ancho de banda utilizado Jitter Resultado 23,075 ms 14,582 Mbps 38 s

4.7.3. Prueba RFC 2544 La metodologa de pruebas del RFC 2544 se especific ampliamente en el Captulo 3. La configuracin de la interfaz utilizada (Fast Ethernet en el puerto 1) es la misma que la presentada en la prueba Y.1564. En las opciones de configuracin globales para la prueba del RFC 2544 se eligen las mtricas de desempeo que se desean probar. En este caso se probarn el throughput, la prdida de paquetes y la latencia; se excluye la prueba de Back-to-back por no ser un parmetro requerido por la SUTEL. Al igual que en la prueba Y.1564 se puede activar la opcin de veredicto que permite determinar si se cumplen o no los parmetros de SLA seleccionados para cada una de las mtricas. El conjunto de tamao de tramas seleccionado es el recomendado en el RFC 2544, tal y como se mencion en el Captulo 3. Adems, al igual que para la prueba de la metodologa Y.1564, es necesario reconocer el dispositivo de bucle mediante un Loop Up.

125

En las opciones de configuracin para el SLA de las mtricas seleccionadas en el men de configuracin global es posible seleccionar un umbral como lmite de calidad de desempeo para cada mtrica de forma independiente. 4.7.2.3. Prueba con throughput de 15 Mbps

Se efectu una prueba con un throughput de 15 Mbps. Luego de la ejecucin se obtuvieron ieron los resultados mostrados en la Figura 4.30 y la Figura 4.31. El formato de presentacin de los resultados se ajusta al sugerido en el RFC 2544; se expone tanto en tablas como en grficas para cada t tamao de trama bajo prueba. En el resumen de resultados de la Figura 4.30 se observa que los umbrales de SLA designados para prdida de paquetes y latencia fueron cumplidos satisfactoriamente. Sin embargo, tal y como se esperaba la la prueba de throughput no fue superada. En relacin con los resultados de throughput se puede analizar que su comportamiento est supeditado al tamao de trama implementado. En las pruebas efectuadas con las herramientas previa previamente analizadas se utiliz z el mayor tamao de trama posible (1518 bytes); este hecho debe tomarse en cuenta a la hora de efectuar el anlisis comparativo de las herramientas. herramientas

126

Figura 4.30. Resumen de resultados de la prueba prueba de 15 Mbps para el RFC 2544

Figura 4.31. Grficas de resultados de la prueba de 15 Mbps para el RFC 2544 Curiosamente se presenta un comportamiento tal que slo la trama de 128 bytes obtuvo un resultado cuyo throughput fue mayor a 15 Mbps. Segn este resultado, este tamao de trama sera el ideal si se pretende aprovechar al mximo el ancho de banda; ban sin embargo, se demorara ms tiempo para enviar la informacin; en otras palabras se hace evidente la dependencia entre el throughput y el tiempo de transmisin total de los datos. En relacin con los otros parmetros se puede observar que la latencia aument de manera prcticamente constante en cuanto se incrementaba el tamao de la trama; esto es esperable ya que el tiempo de transmisin de los bytes aumentar. Por otro lado, el valor porcentual de prdida de paquetes fue 0% en todo momento.

127

4.8.

Prueba de implementacin a nivel de suscriptor: Speedtest de

Ookla
En el Captulo 3 se expusieron todos los detalles relacionados con el procedimiento que segn Ookla efecta el Speedtest. El elemento ms rescatable es que se utiliza el protocolo http a nivel de aplicacin para transferir los datos y realizar las mediciones relacionadas con el throughput o ancho de banda disponible en la conexin. Se mencion la importancia del Speedtest como una herramienta ampliamente difundida para verificar consistentemente si el ISP est entregando la velocidad que prometi. (Ookla, 2010) Sin embargo, existen muchas variables en relacin con el uso de este sistema para medir eficientemente el throughput real con el que se cuenta. De hecho, en la documentacin de Ookla se menciona que los resultados de speedtest.net deben ser aproximadamente un 80% o superior en relacin con el throughput contratado. Se debe asegurar de utilizar las mismas unidades de ancho de banda para efectuar las comparaciones y permitir entre un 10% y un 20% de error por el overhead transmitido. (Ookla, 2010) 4.8.1. Metodologa de la prueba La metodologa diseada para la aplicacin de la prueba del Speedtest de Ookla consisti en utilizar una terminal de la topologa mostrada en la Figura 4.1, especficamente 128

en el llamado ProyectoElectricoNP e instalar la versin de prueba gratuita que ofrece por 30 das Ookla en un servidor web albergado en dicha terminal. La otra terminal de la topologa (ProyectoElectricoNPdos) se utiliz como cliente de la medicin, accediendo la direccin IP del servidor de Speedtest instalado mediante un buscador web convencional. Se efectan varias pruebas aumentando el trfico en un sentido y otro (generado mediante la herramienta D-ITG GUI); simulando la congestin de la interfaz del servidor de Speedtest ante consultas mltiples, o bien, por la utilizacin de otro recurso de red que lleve a cabo el servidor. 4.8.2. Instalacin del servidor de Speedtest de Ookla A continuacin se enumeran los pasos seguidos para la instalacin del servidor web y la aplicacin de Speedtest de Ookla: 1. Instalar el gestor del servidor web mediante: sudo apt-get install apache2 2. Descargar la versin de prueba del Speedtest de Ookla del siguiente enlace: http://www.ookla.com/trial 3. Para poder efectuar la descarga es necesario registrarse en el sitio de Ookla 4. Descomprimir el archivo como sper-usuario en el directorio /var/www 5. Editar el archivo /var/www/settings.xml e incluir en el espacio correspondiente la URL a utilizar para el servidor. En este caso se especific la direccin IP del servidor (172.16.1.3).

129

6. Instalar las libreras del lenguaje web utilizado. Para ello escribir: sudo apt-get install php5 php5-dev libapache2-mod-php5. Sin estos paquetes no funcionarn todas las pruebas del servidor de Speedtest. 4.8.3. Resultados de la prueba Una vez instalado el servidor, se efectu una prueba de velocidad procurando que nicamente se dedicara el procesamiento de ambas terminales para su ejecucin; es decir, se trata del mejor de los escenarios para evaluar el desempeo del Speedtest de Ookla. El resultado de la prueba se muestra en la Figura 4.32. Se obtuvo un valor de descarga de 11,07 Mbps y uno de subida de 10,77 Mbps. Ntese que el resultado de la herramienta ping incluida en la interfaz de resultados fue de 4 ms; sin embargo, cuando se prob la herramienta de Ping al inicio del presente captulo se constat que la latencia de RTT era de aproximadamente 0,34 ms; en otras palabras el Speedtest de Ookla no da buenos resultados de latencia cuando el valor es muy bajo. Tambin se debe observar que no existe simetra entre las pruebas de descarga y subida. Esto es una deficiencia del Speedtest de Ookla, ya que se est probando bajo el mejor de los escenarios.

130

Figura 4.32. Resultados de la prueba del Speedtest de Ookla en el mejor escenario Se efecta otra prueba modificando los parmetros del archivo

/var/www/settings.xml; especficamente se modific el valor de testlength (duracin de la prueba) de 10 segundos a 30 segundos para las tres pruebas: descarga, subida y latencia. El resultado obtenido se muestra en la Figura 4.33. Se mejor ligeramente el ancho de banda de subida.

131

Figura 4.33. Resultados de la prueba del Speedtest de Ookla en el mejor escenario con parmetros de configuracin modificados Se lleva a cabo otra prueba similar pero inyectando en la interfaz de red del servidor un trfico de datos UDP de 1024 kbps de ancho de banda (utilizando D-ITG); tal y como se muestra en la Figura 4.34. Ahora bien, luego de ejecutar el Speedtest en la terminal del cliente se obtuvo el resultado de la Figura 4.35. Ntese la afectacin visible del ancho de banda de descarga y subida; que pas de 11,06 Mbps a 10,10 Mbps y de 10,77 Mbps a 10,05 Mbps respectivamente. De inmediato se puede deducir que la ocupacin de la interfaz de red del servidor para cualquier otro tipo de trfico afectar el resultado de la prueba de Speedtest de Ookla.

132

Figura 4.34. Trfico generado de 1 Mbps de datos UDP para la prueba del Speedtest de Ookla

Figura 4.35. Resultados de la prueba del Speedtest de Ookla con trfico UDP de 1 Mbps generado desde la interfaz del servidor 133

Se repite el procedimiento de la prueba pero generando datos UDP de 5 Mbps desde la interfaz de red del servidor (utilizando D-ITG). En la Figura 4.36 se muestran los resultados obtenidos. En esta ocasin la velocidad de descarga se vio seriamente afectada por la ocupacin de la interfaz de red del servidor.

Figura 4.36. Resultados de la prueba del Speedtest de Ookla con trfico UDP de 5 Mbps generado desde la interfaz del servidor Para la siguiente prueba se genera trfico en ambos sentidos; utilizando la misma herramienta D-ITG GUI con la misma configuracin en ambas terminales. En este caso se generan 5 Mbps en cada interfaz de las terminales de la EPL (utilizando D-ITG). El resultado obtenido se muestra en la Figura 4.37. En esta ocasin ambos sentidos de la prueba se vieron seriamente afectados. Disminuyendo su throughput prcticamente 5 Mbps del resultado real.

134

Figura 4.37. Resultados de la prueba del Speedtest de Ookla con trfico UDP de 5 Mbps generado desde la interfaz de ambas terminales Por ltimo se llev a cabo una prueba en uno de los peores escenarios. Se genera trfico UDP de 10 Mbps desde cada terminal (utilizando D-IGT). El resultado obtenido se puede observar en la Figura 4.38. En esta ocasin el ancho de banda de descarga cay hasta un alarmante valor de 1,06 Mbps y el ancho de banda de subida hasta un valor de 4,15 Mbps; siendo igualmente muy alejado del valor que realmente provee la EPL.

135

Figura 4.38. Resultados de la prueba del Speedtest de Ookla con trfico UDP de 10 Mbps generado desde la interfaz de ambas terminales 4.8.4. Anlisis de los resultados de la prueba con el Speedtest de Ookla Se comprob la evidente dependencia de los resultados en relacin con la utilizacin de la interfaz de red. En la Tabla 4.6 se resumen los parmetros obtenidos mediante las pruebas efectuadas. Ntese que entre mayor es el trfico generado por las interfaces de red, peor es el resultado obtenido por el cliente del Speedtest de Ookla. Se concluye que para la ptima utilizacin del Speedtest de Ookla debe haber condiciones favorables de trfico en la red. No solamente en los enlaces de la capa de transporte de la red, sino que tambin en las interfaces de red tanto del cliente como del servidor. Esta conclusin coincide con la recomendacin que hacen los fabricantes de la aplicacin de utilizarla en varias horas del da, dada la susceptibilidad que tiene al trfico. 136

Tabla 4.6. Resumen de los resultados obtenidos en las pruebas del Speedtest de Ookla
Condiciones de la prueba Interfaces dedicadas a la prueba Interfaces dedicadas con parmetros de configuracin de Speedtest modificados Interfaz del servidor generando 1 Mbps de trfico UDP Interfaz del servidor generando 5 Mbps de trfico UDP Ambas interfaces generando 5 Mbps de trfico UDP Ambas interfaces generando 10 Mbps de trfico UDP (peor de los escenarios) Tasa de descarga (Mbps) 11,07 11,06 Tasa de subida (Mbps) 10,77 10,82

10,10

10,05

6,07 6,05 1,06

10,55 5,46 4,15

Tambin es posible deducir que el Speedtest de Ookla se puede ver afectado por la distancia al servidor, tal y como se justific en el Captulo 3, dado que la prueba efecta sus clculos basado tambin en el retardo del envo de los archivos de prueba de descarga y de subida. Por ltimo, se debe anotar que en las mejores condiciones se obtuvo un resultado asimtrico; por lo tanto, la herramienta tampoco es fiable en la comprobacin de la simetra de un enlace. Hay que recordar que las EPL normalmente se comercializan con velocidades simtricas entre los sitios (a diferencia de los servicios ordinarios de Internet).

137

4.9.

Prueba de implementacin a nivel de suscriptor: NetPerSec y

monitor del sistema de red de Linux

Tal y como se mencion en los atestados tericos del Captulo 3; ambas herramientas permiten medir el desempeo de las interfaces de red de una terminal mediante una observacin pasiva del trfico que las atraviesa en funcin del tiempo. Dicha observacin se efecta mediante peticiones SNMP. 4.9.1. Implementacin de NetPerSec Se obtuvo la versin 1.1 de NetPerSec; para ello es necesario registrarse en el sitio de PC Magazine o bien, comprar la herramienta. Ambas opciones en el siguiente enlace: http://www.pcmag.com/article2/0,2817,1735,00.asp Se trata de una aplicacin desarrollada en el 2000 por Mark Sweeney. No es necesario instalar la aplicacin, simplemente se debe ejecutar una vez descargado y descomprimido el archivo. Soporta hasta versiones de Windows XP, lo cual es una gran desventaja, dada la actual difusin de versiones ms recientes de este sistema operativo. Se tienen pocas opciones disponibles en este analizador de velocidad de trfico. La Figura 4.39 muestra la pantalla principal de la aplicacin. Simplemente exhibe una grfica del trfico de red en tiempo real, mostrando los valores mximos de descarga y subida. Permite seleccionar entre grfica de barras o lineal y entre bits o bytes por segundo.

138

Figura 4.39. Interfaz principal de NetPerSec La Figura 4.40 muestra las opciones con que se cuentan para graficar. Se puede modificar el intervalo de muestreo y el perodo en el que se calculan los valores promedio. Tambin se puede elegir cul interfaz monitorear. Es evidente que el clculo de ancho de banda se efecta tomando la cantidad de bytes o bits que han atravesado la interfaz de red en un cierto intervalo de tiempo (definido en el intervalo de muestreo) y dividindolo por ese tiempo.

139

Figura 4.40. Opciones de configuracin de NetPerSec La Figura 4.41 muestra las opciones de formato de los grficos de la Figura 4.39. Se pueden modificar los colores y elegir si arrancar con Windows y si la ventana siempre est encima de las dems. La ltima pestaa de About muestra informacin de la versin del software, su creador y los derechos reservados.

Figura 4.41. Opciones de configuracin de pantalla de NetPerSec 140

4.9.1.1.

Anlisis de la implementacin de NetPerSec

En el Captulo 3 se mencion que la aplicacin NetPerSec utiliza los objetos ifInOctets e ifOutOctets para obtener mediante sus OIDs la informacin de los bytes (octetos) recibidos y enviados por la interfaz. Ahora bien, a qu nivel del modelo TCP/IP se obtienen esos datos? La respuesta se encuentra en el RFC 1213. En l se definen las caractersticas de los objetos que conforman el MIB-II (que es la base de datos comn para la gestin de equipos de Internet). El RFC 1213 define el ifInOctets como el nmero total de octetos recibidos en la interfaz, incluyendo los campos de entramado. (McCloghrie, 1991) De manera anloga, el RFC 1213 define el ifOutOctets como el nmero total de octetos transmitidos por la interfaz, incluyendo los campos de entramado. (McCloghrie, 1991) De las definiciones anteriores se puede deducir que la aplicacin NetPerSec brinda el ancho de banda de todos los bytes transmitidos y recibidos por la interfaz de red; esto es, incluyendo los encabezados de todos los niveles TCP/IP; por lo tanto, no se trata de una medicin de la tasa de datos realmente transportados. Esta consideracin es inmensamente importante a la hora de efectuar un anlisis que implique la implementacin de NetPerSec. 4.9.2. Implementacin del monitor del sistema para Gnome en Ubuntu Para la instalacin de la herramienta de monitoreo del sistema para Gnome (manejador de ventanas para entornos Unix y similares) simplemente se debe instalar el 141

siguiente paquete de los repositorios de Linux: sudo apt-get install gnome-systemmonitor. Las distribuciones de Ubuntu actuales incluyen este paquete por defecto. No se especifica una documentacin consistente en relacin con la forma en la que el sistema de monitoreo para Gnome obtiene los datos por SNMP; especficamente la informacin del estado de las interfaces de red. Por lo tanto, no es posible conocer a qu nivel del modelo TCP/IP la herramienta despliega la tasa de transferencia de datos. Para ello se ejecutaron pruebas en paralelo a las pruebas de TCP de D-ITG y de throughput de Netperf. La Figura 4.16 y la Figura 4.25 muestran los resultados obtenidos. En la prueba de D-ITG el monitor del sistema para Gnome mostr un valor promedio de ancho de banda 11,23 Mbps; en este caso el valor no es comparable con el obtenido con D-ITG ya que en esta prueba se satur la capacidad de la EPL. Sin embargo, la cantidad obtenida es razonable en funcin del ancho de banda que limita la EPL. Por su parte, en la prueba de Netperf, el monitor del sistema arroj un valor promedio de 11,14 Mbps; mientras que el throughput obtenido mediante Netperf arroj un resultado de 11,06 Mbps. Ntese la gran cercana de los resultados. De las pruebas efectuadas, se puede concluir que el monitor del sistema para Gnome brinda un valor de ancho de banda ms apegado a la tasa real de datos transferidos. Es decir, a pesar de que no se conoce a qu nivel del modelo TCP/IP acta, se sabe al menos que sus resultados se acercan mucho al valor de throughput calculado por Netperf para un intervalo de confianza de 2,5%.

142

4.10. Anlisis global y comparacin de los resultados y las herramientas implementadas

Se parte de varios rubros para evaluar las condiciones de las herramientas de medicin de desempeo estudiadas. Para ello se divide el anlisis en dos grandes puntos de referencia, el primero es en relacin con las mtricas estudiadas en las metodologas RFC 2544 y la recomendacin de la UIT Y.1564. La segunda se relaciona con los parmetros que solicita la SUTEL, especficamente en el Captulo 7 del Reglamento de Prestacin y Calidad de los Servicios (transferencia de datos). 4.10.1. Evaluacin de las herramientas en relacin con las metodologas de pruebas RFC 2544 y la recomendacin de UIT Y.1564 La presente evaluacin se divide en una serie de criterios. El primero de ellos es el tipo de herramienta de medicin de desempeo, el segundo son las mtricas que es capaz de brindar de acuerdo con el RFC 2544 y la recomendacin Y.1564 para redes Ethernet y Metro Ethernet, el tercero es la versatilidad de la herramienta evaluada desde un punto de vista subjetivo y de acuerdo a la experiencia adquirida mediante las pruebas para personalizarlas, el cuarto es el precio y el quinto es la facilidad de implementacin e instalacin. Se deja un ltimo rubro para comentarios adicionales. La Tabla 4.7 resume los resultados de los criterios analizados en relacin con las pruebas RFC 2544 y Y.1564. En la tabla se comentan adems los aspectos globales ms importantes relacionados con cada herramienta. 143

Tabla 4.7. Comparacin de las herramientas de desempeo para pruebas RFC 2544 y Y.1564
Nombre Tipo RFC 2544
Throughput Latencia Prdida de paquetes Back to Back Throughput Latencia Prdida de paquetes Back to Back Throughput Latencia X O O X X O X X O O

Y.1564
Throughput Latencia Prdida de paquetes Jitter Throughput Latencia Prdida de paquetes Jitter Throughput Latencia Prdida de paquetes Jitter Throughput X O O X X O X X O O

Versatilidad
Poca. No ofrece muchas opciones en relacin con medicin del desempeo.

Precio

Instalacin e implementacin
Fcil. Viene por defecto en sistemas operativos Windows y Linux.

Comentarios
Se utiliza ms para comprobar la comunicacin entre dos equipos de red. Sin embargo, permite obtener algunas mtricas. Se utiliza ms para comprobar la ruta seguida para la comunicacin entre dos equipos de red. No es recomendable para mediciones de desempeo. Se trata de una herramienta muy poderosa. Una de las mayores ventajas es el precio y que se trata de un proyecto actualmente en desarrollo por lo que se seguir mejorando y actualizando la plataforma.

Ping

Activa

Sin costo

Traceroute

Activa

Poca. No ofrece muchas opciones en relacin con medicin del desempeo.

Sin costo

Fcil. Viene por defecto en sistemas Linux. En Windows se llama tracert.

D-ITG

Activa

Prdida de paquetes Back to Back Throughput

X O

O O

Mucha. Se puede generar trfico de todo tipo (VoIP, datos, video, etc.). Adems ofrece la opcin de scripting por lo que es posible programar todas las pruebas requeridas en las metodologas de pruebas estudiadas, excepto para la mtrica de Back to Back.

Sin costo

Complicado. Requiere conocimientos de instrucciones de terminal de Linux. Adems, la documentacin no presenta un buen manual de instalacin. Se demor bastante tiempo intentando instalar la aplicacin en conjunto con el GUI para la presente investigacin.

Latencia

Latencia

NetPerf

Activa Prdida de paquetes O Prdida de paquetes O

Mediana. Ofrece la opcin de scripting por lo que es posible programar todas las pruebas requeridas en los estndares (excepto la de Back to back y Jitter); sin embargo, no ofrece la posibilidad de efectuar pruebas en el nivel de aplicacin.

Sin costo

Mediana. Requiere conocimientos de instrucciones de terminal de Linux. Sin embargo, siguiendo las instrucciones de instalacin se logra sin mayor dificultad.

Back to Back

Ofrece la ventaja de ser un benchmark; por lo que se puede utilizar para comparar el desempeo de distintas configuraciones en una red. Adems, ofrece garantas estadsticas sobre los resultados que brinda. El proyecto actualmente sigue en desarrollo.

Jitter

144

Bing

Activa

Throughput Latencia Prdida de paquetes Back to Back Throughput

O X X X O

Throughput Latencia Prdida de paquetes Jitter Throughput

O X X X O

Mala. La forma de calcular el throughput hace que se produzcan resultados poco fidedignos.

Sin costo

Fcil. Se encuentra en los repositorios de Linux.

Esta herramienta no es recomendable para la medicin de ninguna mtrica.

Latencia

Latencia

MGEN

Activa Prdida de paquetes O Prdida de paquetes O

Back to Back Throughput

Mucha. Permite la posibilidad de un scripting especficamente desarrollado para la herramienta. De hecho, utiliza su propia biblioteca y su propia sintaxis de programacin. Se enlaza fcilmente con la herramienta de grficos, por lo que la presentacin de los datos se puede adaptar fcilmente.

Sin costo

Mediana. Se requieren conocimientos en Linux; sin embargo, el proceso de instalacin es sumamente sencillo.

Es una herramienta muy poderosa que permite emular cualquier tipo de trfico (VoIP, video, datos, etc.) y analizar el desempeo de la red a partir del anlisis de este trfico.

X O

Jitter Throughput

O O Mediana. Al ser una plataforma cuyo software es privado, no es posible efectuar experimentos de generacin de trfico; sino que los parmetros configurables estn ya muy bien definidos. A pesar de ello es una plataforma que incluye todos los aspectos estudiados en la metodologa de pruebas RFC 2544 y Y.1564. Es una herramienta muy poderosa enfocada a la medicin de desempeo de acuerdo con el RFC 2544 y el Y.1564. Las pruebas son muy fcilmente aplicadas y los reportes poseen toda la informacin necesaria para la validacin de ciertos servicios en una red.

Latencia

Latencia

Mdulo Comercial

Activa Prdida de paquetes O Prdida de paquetes O

Se debe comprar la plataforma, el mdulo y el bucle.

Fcil. La plataforma ya viene con el software necesario instalado.

Back to Back

Jitter

Nota: la X representa no aprueba y el O representa s aprueba.

145

4.11. Ejemplos de implementacin de herramientas de monitoreo de desempeo no intrusivas: Nagios

Tal y como se mencion en el Captulo 3, Nagios es una herramienta de monitoreo de redes de tipo pasivo y de cdigo abierto. En trminos generales permite vigilar tanto el hardware como el software de un dispositivo de red especfico. Para ello es posible utilizar peticiones SNMP de modo que el monitoreo se efecte remotamente. El proceso de instalacin requiere conocimientos en Linux, plataforma sobre la cual opera Nagios. Una vez llevado a cabo dicho proceso, se puede acceder a una interfaz web con el men principal de Nagios, tal y como se muestra en la Figura 4.42.

Figura 4.42. Men principal de Nagios 3 146

Ahora bien, luego de instalar Nagios, es muy recomendable instalar una extensin diseada especficamente para este sistema llamada PNP4Nagios. Esta aplicacin permite recolectar en bases de datos Round Robin los datos adquiridos por Nagios mediante SNMP. Adems de recolectar los datos, es capaz de graficarlos en tiempo real. Se efecta el proceso de instalacin en la terminal 172.168.1.2 (llamada ProyectoElectricoNPdos) y se pretende obtener un monitoreo del ancho de banda utilizado en la interfaz de entrada de la otra terminal. La configuracin de los dispositivos que se desean monitorear se debe escribir en el directorio /etc/nagios3/conf; para el ejemplo se cre un archivo llamado bw.cfg con los siguientes comandos: define host host_name ProyectoElectricoNP alias Prueba_BW address 172.16.1.3 contact_groups admins } define service{ use service-second,srv-pnp host_name ProyectoElectricoNP service_description ETH0 check_command check_iftraffic3!comunidad_prueba!0!100 }

Primero se definen las caractersticas del dispositivo que se va a monitorear. En esta definicin se escribe el nombre del equipo, el alias, la direccin IP y el grupo a contactar en caso de alerta. Por su parte, en la definicin del servicio se debe definir srv-pnp de modo que los datos sean graficados por PNP4Nagios, tambin se define el nombre del dispositivo, la descripcin del servicio y el comando que utilizar Nagios. En este caso se 147

utiliz un comando llamado check_iftraffic3 el cual es un script en Perl que permite calcular el ancho de banda de las interfaces de un dispositivo a partir de los datos de bytes entrantes y salientes en un intervalo de tiempo definido. Esta definicin es la forma sugerida de medir los niveles de ocupacin de un enlace en los parmetros requeridos por la SUTEL. En la Figura 4.43 se muestra el resultado de la implementacin de la herramienta de monitoreo Nagios. Ntese que la herramienta por s sola brinda los datos de ancho de banda mximo, mnimo y promedio. Estos resultados son modificables dado que todas las herramientas utilizadas son de cdigo abierto.

Figura 4.43. Grfica de ancho de banda obtenida mediante la herramienta de monitoreo Dado que los datos de la SUTEL para niveles de ocupacin de enlace se piden para la hora cargada media, entonces es muy factible monitorear el enlace durante esa hora y obtener como resultado el valor promedio que la misma grfica arroja. Debe mencionarse que Nagios se basa en el uso de scripts de Perl para ejecutar muchos de sus comandos. Esto es un factor absolutamente positivo ya que es posible

148

personalizar comandos y efectuar acciones de monitoreo sumamente especficas. Este tipo de cualidades no sera posible en herramientas de cdigo cerrado.

149

5. CAPTULO 5: Utilizacin de las herramientas de NP para la medicin de los parmetros establecidos por la SUTEL
En este captulo se efecta un anlisis de la utilidad de las herramientas de NP definidas en el captulo anterior para la medicin de los parmetros solicitados por la SUTEL en su Reglamento de Prestacin y Calidad de los Servicios, especficamente en el Captulo 7 sobre redes de transferencia de datos. La SUTEL en su Reglamento de Prestacin y Calidad de los Servicios no especifica los mtodos que deben emplearse para efectuar las distintas mediciones, por lo tanto, es de suma importancia utilizar las metodologas de pruebas estudiadas como un marco de referencia. La nica condicin que establece la SUTEL para todas las mtricas (a excepcin de la medicin del throughput contratado) es que se deben efectuar durante la hora cargada media (hora de mayor trfico en la red). Ntese que esta condicin implica que se debe monitorear la red mediante una herramienta pasiva como Nagios para determinar cul es esa hora.

5.1.

Mtodo de medicin segn la recomendacin de la UIT

Y.1541
Dado que la SUTEL no especifica el mtodo de medicin a implementar, se estudia el recomendado en el estndar referido por el Reglamento de Prestacin y Calidad de los Serivicios; es decir, la recomendacin de la UIT Y.1541. 150

En la Figura 5.1 se muestra el esquema general a partir del cual se deben efectuar las mediciones para las distintas mtricas. Ntese que este esquema es aplicable tanto para mtricas tomadas a nivel local e internacional, variando simplemente las redes ubicadas entre cada UNI. El esquema de conexin es de UNI a UNI; por lo tanto muchas de las aplicaciones con paradigma cliente-servidor analizadas en el captulo anterior pueden ser implementadas.

Figura 5.1. Trayecto de referencia UNI a UNI para los objetivos QoS de la red (UIT, 2006)

5.2.

Cumplimiento de niveles de retardo a nivel local e

internacional
En el Artculo 95 y 96 del Reglamento de Prestacin y Calidad de los Servicios de la SUTEL se exponen los umbrales de cumplimiento de retardo a nivel local e 151

internacional. Dichos artculos se basan en la recomendacin de la UIT G.1010 (categoras de calidad de servicio para los usuarios de extremo de servicios multimedios) y la Y.1541 (calidad de servicio y caractersticas de red), as como en el estndar IEEE 802.1p (calidad de servicio de capa de enlace de datos). Tabla 5.1. Umbral de retardo local permitido por la SUTEL (ARESEP, 2009)
Clase de calidad de servicio 0 1 2 3 4 5 Umbral de retardo local (ms) 10 20 25 30 40 50

Descripcin Tiempo real, alta interaccin, sensibles al retardo. (Voz y video en tiempo real) Tiempo real, interactivos, sensibles al retardo (Voz y video en tiempo real de menor calidad) Datos de alta prioridad (transaccionales, altamente interactivos) Datos de mediana prioridad (Datos transaccionales interactivos) Datos de baja prioridad (transacciones cortas, datos en grandes cantidades, flujo continuo de video streaming Datos de mejor esfuerzo

Tabla 5.2. Umbral de retardo internacional permitido por la SUTEL (ARESEP, 2009)
Clase de calidad de servicio 0 1 2 3 4 5 Umbral de retardo local (ms) 100 150 200 225 250 300

Descripcin Tiempo real, alta interaccin, sensibles al retardo. (Voz y video en tiempo real) Tiempo real, interactivos, sensibles al retardo (Voz y video en tiempo real de menor calidad) Datos de alta prioridad (transaccionales, altamente interactivos) Datos de mediana prioridad (Datos transaccionales interactivos) Datos de baja prioridad (transacciones cortas, datos en grandes cantidades, flujo continuo de video streaming Datos de mejor esfuerzo

152

En la Tabla 5.1 se encuentran los mbitos para el retardo a nivel local clasificado de acuerdo con la clase de calidad de servicio. De igual forma en la Tabla 5.2 se detallan los mbitos para el retardo a nivel internacional. Ntese que la SUTEL pone lmites a los valores de retardo de la clase 5; mientras que en las normas internacionales (tanto UIT G.1010 como Y.1541) no se especifica un lmite de retardo ni ningn otro parmetro de calidad para los datos de mejor esfuerzo.

5.3.

Cumplimiento de niveles de variaciones en el retardo a nivel

local e internacional
En el Artculo 97 y 98 del Reglamento de Prestacin y Calidad de los Servicios de la SUTEL se exponen los umbrales de cumplimiento de variaciones de retardo a nivel local e internacional. Dichos artculos se basan en la recomendacin de la UIT G.1010 (categoras de calidad de servicio para los usuarios de extremo de servicios multimedios) y la Y.1541 (calidad de servicio y caractersticas de red), as como en el estndar IEEE 802.1p (calidad de servicio de capa de enlace de datos). En la Tabla 5.3 se encuentran los mbitos para el retardo a nivel local clasificado de acuerdo con la clase de calidad de servicio. De igual forma en la Tabla 5.4 se detallan los mbitos para el retardo a nivel internacional.

153

Tabla 5.3. Umbral de variacin en el retardo local permitido por la SUTEL (ARESEP, 2009)
Clase de calidad de servicio 0 1 2 3 4 5 Umbral de jitter local (ms) 20 25 50 N/A N/A N/A

Descripcin Tiempo real, alta interaccin, sensibles al retardo. (Voz y video en tiempo real) Tiempo real, interactivos, sensibles al retardo (Voz y video en tiempo real de menor calidad) Datos de alta prioridad (transaccionales, altamente interactivos) Datos de mediana prioridad (Datos transaccionales interactivos) Datos de baja prioridad (transacciones cortas, datos en grandes cantidades, flujo continuo de video streaming Datos de mejor esfuerzo

Tabla 5.4. Umbral de variacin de retardo internacional permitido por la SUTEL (ARESEP, 2009)
Clase de calidad de servicio 0 1 2 3 4 5 Umbral de retardo local (ms) 45 50 55 N/A N/A N/A

Descripcin Tiempo real, alta interaccin, sensibles al retardo. (Voz y video en tiempo real) Tiempo real, interactivos, sensibles al retardo (Voz y video en tiempo real de menor calidad) Datos de alta prioridad (transaccionales, altamente interactivos) Datos de mediana prioridad (Datos transaccionales interactivos) Datos de baja prioridad (transacciones cortas, datos en grandes cantidades, flujo continuo de video streaming Datos de mejor esfuerzo

154

5.4.

Cumplimiento de niveles de prdida de paquetes a nivel local

e internacional
En el Artculo 99 y 100 del Reglamento de Prestacin y Calidad de los Servicios de la SUTEL se exponen los umbrales de cumplimiento de niveles de prdida de paquetes a nivel local e internacional. Dichos artculos se basan en la recomendacin de la UIT G.1010 (categoras de calidad de servicio para los usuarios de extremo de servicios multimedios) y la Y.1541 (calidad de servicio y caractersticas de red), as como en el estndar IEEE 802.1p (calidad de servicio de capa de enlace de datos). Tabla 5.5. Umbral de prdida de paquetes a nivel local permitido por la SUTEL (ARESEP, 2009)
Clase de calidad de servicio 0 1 2 3 4 5 Umbral de prdida de paquetes local (%) 1% 3% 3% 5% 5% 5%

Descripcin Tiempo real, alta interaccin, sensibles al retardo. (Voz y video en tiempo real) Tiempo real, interactivos, sensibles al retardo (Voz y video en tiempo real de menor calidad) Datos de alta prioridad (transaccionales, altamente interactivos) Datos de mediana prioridad (Datos transaccionales interactivos) Datos de baja prioridad (transacciones cortas, datos en grandes cantidades, flujo continuo de video streaming Datos de mejor esfuerzo

155

Tabla 5.6. Umbral de prdida de paquetes a nivel internacional permitido por la SUTEL (ARESEP, 2009)
Umbral de prdida de paquetes internacional (%) 1% 3% 3% 5% 5% 5%

Clase de calidad de servicio 0 1 2 3 4 5

Descripcin

Tiempo real, alta interaccin, sensibles al retardo. (Voz y video en tiempo real) Tiempo real, interactivos, sensibles al retardo (Voz y video en tiempo real de menor calidad) Datos de alta prioridad (transaccionales, altamente interactivos) Datos de mediana prioridad (Datos transaccionales interactivos) Datos de baja prioridad (transacciones cortas, datos en grandes cantidades, flujo continuo de video streaming Datos de mejor esfuerzo

En la Tabla 5.5 se encuentran los mbitos para el retardo a nivel local clasificado de acuerdo con la clase de calidad de servicio. De igual forma en la Tabla 5.6 se detallan los mbitos para el retardo a nivel internacional.

5.5.

Cumplimiento de niveles de ocupacin de enlaces locales e

internacionales
En el Artculo 101 se define el umbral mximo de cumplimiento en relacin con los niveles de ocupacin de los enlaces locales e internacionales que posea la red. Dicho umbral se define para un mximo de 80%.

156

5.6.

Cumplimiento del desempeo de la velocidad de transferencia

local e internacional respecto a la velocidad contratada

En el Artculo 102 la SUTEL define los umbrales de throughput mnimos clasificados por tipo de cliente. No se especifica el seguimiento de algn estndar o recomendacin para la evaluacin de estos parmetros. Adems, se establece una condicin importante para la medicin requerida: este parmetro (el throughput) debe cumplirse para la velocidad de envo y descarga de informacin, en condicin de uso bidireccional simultneo del enlace (ARESEP, 2009). Es decir, la medicin debe hacerse de forma simultnea en un sentido y en otro; por lo tanto, aplicaciones como el Speedtest de Ookla no clasificaran para esta medicin. En la Tabla 5.7 se muestran los umbrales asignados por la SUTEL para los diferentes tipos de servicio ofrecidos. Tabla 5.7. Umbrales de throughput (ARESEP, 2009)
Tipo de servicio Umbral de throughput Domiciliar 80% Pequeas y medianas empresas 85% Grandes empresas 90% Corporativo 95%

Es muy importante anotar que en el Reglamento de Prestacin y Calidad del Servicio no se brinda una definicin concreta del trmino throughput. En algunas bibliografas se refieren a l como sinnimo de ancho de banda total, mientras que en otras se refieren a l como la tasa de datos reales (sin tomar en cuenta los bytes de los 157

encabezados de los niveles de enlace, red y transporte). Por ende se considera una carencia del reglamento. Se recomienda apegarse a las definiciones del RFC 1242 estudiadas en el Captulo 4.

5.7.

Sanciones aplicadas para los proveedores de servicios en el

incumplimiento de las mtricas

Adems del estudio de las herramientas de medicin, se considera relevante dar a conocer la forma en que el ente regulador nacional de las telecomunicaciones castiga el incumplimiento de los mbitos establecidos. En cada uno de los artculos especificados anteriormente se utiliza la misma frmula para la medicin del incumplimiento porcentual de una mtrica: Si el resultado obtenido es menor o igual al umbral definido entonces el cumplimiento es del 100% Si el resultado obtenido es mayor que el umbral definido entonces se aplica la siguiente ecuacin: % 100 (5.1)

Donde k corresponde a la constante de rigurosidad que establece la SUTEL y depende del valor del parmetro; resultado corresponde al valor obtenido mediante la prueba de desempeo y umbral corresponde al valor establecido por la SUTEL. En los casos en los que un resultado mayor al umbral sea positivo se invierte el orden de estas variables; por ejemplo, en el retardo, la frmula tiene como exponente -k*(ResultadoUmbral). 158

En la Figura 5.2 se muestra la grfica de la Ecuacin 5.1. Se utiliz un barrido del parmetro resultado de 1 a 100 y un valor de constante de rigurosidad de 0,5. La grfica se realiz con ayuda de la herramienta Matlab, mediante los siguientes comandos: Resultado=1:0.001:100; k1=0.5; Cumplimiento=100*exp(-k1*(100-Resultado)); plot (Resultado,Cumplimiento);

Porcentaje de cumplimiento en funcin del resultado porcentual obtenido para k=0,5 100 90 80 70 Cumplimiento (%) 60 50 40 30 20 10 0

10

20

30

40 50 60 Resultado (%)

70

80

90

100

Figura 5.2. Grfica de frmula de cumplimiento de la SUTEL con k=0,5 Ntese la rigurosidad de la formula de porcentaje de cumplimiento. Se puede anotar que si por ejemplo se tiene un umbral de retardo de 100 ms y se incumple por 1 ms entonces se tendra un 60,65% de cumplimiento. Si se incumple por 5 ms se tendra un cumplimiento de 8,2%. Es decir, el castigo aplicado al incumplimiento de los umbrales es muy severo. 159

Por su parte, se grafic la Ecuacin 5.1 pero con un valor de k=50. En la Figura 5.3 se muestra la grfica obtenida bajo estas condiciones. Evidentemente si la constante de rigurosidad es de 50, entonces violar el umbral produce un porcentaje de cumplimiento de 0%. Es prcticamente una funcin de tipo escaln.
Porcentaje de cumpliento en funcin del resultado obtenido para k=50 100 90 80 70 Cumplimiento (%) 60 50 40 30 20 10 0

10

20

30

40 50 60 Resultado (%)

70

80

90

100

Figura 5.3. Grfica de frmula de cumplimiento de la SUTEL con k=50 En el Reglamento de Prestacin y Calidad de los Servicios no se menciona nunca el origen de la Ecuacin 5.1. Tampoco aparece en ninguna recomendacin de la UIT ni ningn RFC de la IETF. Se asume por lo tanto que la frmula fue diseada por la SUTEL.

5.8.

Evaluacin de las herramientas en relacin con los

parmetros solicitados por la SUTEL

160

Con la presente evaluacin se pretende reconocer cules son las herramientas de medicin de desempeo que se adaptan mejor a las mtricas solicitadas por la SUTEL, especficamente en el Captulo 7 del Reglamento de Prestacin y Calidad de los Servicios (transferencia de datos). Para ello se estructur la Tabla 5.8. Hay varios elementos que se deben tomar en cuenta al analizar la tabla mostrada. El primero de ellos es que se incluy Nagios (herramienta de monitoreo pasiva mediante peticiones SNMP) a pesar de no haberse efectuados pruebas sobre el EPL implementado. Sin embargo, se considera que para evaluar el nivel de ocupacin de un enlace, es imperiosamente necesario utilizar una herramienta pasiva de monitoreo ya que si se utiliza una herramienta intrusiva se agrega trfico a la red y por lo tanto el dato real de ocupacin se falsea. En el Captulo 4 se estudian algunos ejemplos de la implementacin de Nagios acompaado de Pnp4Nagios para generar grficas; sin embargo, no se profundiza en el estudio de esta herramienta por considerarse fuera de los objetivos del presente proyecto. Otra observacin importante es que a pesar de que herramientas como Ping permiten efectuar mediciones de mtricas de desempeo, es ms recomendable utilizar las otras opciones basados en el criterio de versatilidad estudiado en la Tabla 4.7.

161

Tabla 5.8. Comparacin de las herramientas de desempeo para verificar las mtricas solicitadas por la SUTEL
Herramientas de medicin de desempeo Mdulo NetPerf Bing MGEN NetPerSec comercial O X O O X X X O O X O X O O X X O X O X O X O X O

Mtrica solicitada por la SUTEL Latencia RTT Jitter Prdida de paquetes Nivel de ocupacin de un enlace Throughput

PING Traceroute O X O X X O X X X X

DITG O O O X O

Speedtest de Ookla X X X X O

Nagios O -

Nota: la X representa no aprueba y el O representa s aprueba.

162

6. Captulo 6: Conclusiones y Recomendaciones

6.1. Conclusiones

Es necesario evaluar el resultado final del presente proyecto a partir del anlisis del cumplimiento de los objetivos establecidos inicialmente. De esta forma no solamente podrn rescatarse los alcances del proyecto sino que tambin se evidenciarn las carencias del mismo. El primer objetivo planteado se refiere al estudio de las normativas y reglamentos que rigen actualmente los mtodos de medicin de desempeo de redes a nivel internacional. Se concluy que las metodologas de pruebas de desempeo de red utilizadas ampliamente como marco de referencia para las redes Ethernet y Metro Ethernet son la recomendacin de la UIT Y.1564 y la norma de la IETF RFC 2544. En relacin con las mtricas de desempeo, se determin que existe una amplia ambigedad en la definicin de los trminos a lo largo de la literatura; sin embargo, se rescatan las recomendaciones de la UIT Y.1540, Y.1541 y G.1010, as como la norma ETSI EG 202 057-4 y la norma de la IETF RFC 1242. El segundo objetivo establece la necesidad de investigar la normativa nacional en relacin con el desempeo de redes. Partiendo del estudio de la Ley General de Telecomunicaciones se estableci que el ente regulador de la calidad de las telecomunicaciones en Costa Rica desde el ao 2008 es 163

la Superintendencia de Telecomunicaciones (SUTEL). Adems, toda la legislacin referente a parmetros de calidad de servicio y por ende mtricas de desempeo se valora en el Reglamento de Prestacin y Calidad de los Servicios. En relacin con este reglamento de la SUTEL, se consider que proporciona definiciones muy vagas en relacin con las mtricas de medicin que solicita y se limita a referenciar la recomendacin de la UIT Y.1540 y la norma de la ETSI EG 202 057-4 en su seccin de definiciones. Tampoco especifica las metodologas de medicin que se deben utilizar, salvo que se deben efectuar en la hora cargada media (hora de mayor trfico en la red). A pesar de ello, la definicin de los umbrales y las tablas con su definicin para cada parmetro son muy intuitivas y claras. Adems de la definicin de las mtricas, el Reglamento de Prestacin y Calidad de los Servicios establece una frmula para el clculo del cumplimiento de los parmetros. Dicha frmula es absolutamente severa y prcticamente obliga a los proveedores de servicio a cumplir con los mbitos estipulados. Este hecho fortalece la importancia del presente proyecto ya que se concluye que la implementacin de las herramientas de medicin intrusivas son utilidades sumamente poderosas para la validacin de una red en relacin con los servicios que es capaz de ofrecer antes de entrar en produccin.

164

De igual forma, pueden ser utilizadas para determinar puntos de fallo de desempeo especficos, de modo que los proveedores de servicios puedan ejecutar las medidas correctivas correspondientes. En vista de la gran cantidad de servicios que una red Ethernet o Metro Ethernet es capaz de suplir, se limita el estudio de las mtricas solicitadas por la SUTEL para redes de transferencia de datos, especficamente en el Captulo 7 del Reglamento de Prestacin y Calidad de los Servicios. El tercer objetivo del proyecto define la necesidad de efectuar pruebas de implementacin de varias herramientas en la red de un proveedor de servicios de Metro Ethernet nacional. Lastimosamente no fue posible efectuar pruebas en una red real de un proveedor, ya que algunas de las herramientas bajo evaluacin eran activas, por lo que inyectan trfico a la red poniendo en riesgo la integridad del servicio de los clientes activos. Dadas estas circunstancias fue necesario estructurar una topologa de pruebas basado en un servicio de Metro Ethernet de EPL. Para ello se utilizan tres conmutadores Cisco 3750-ME ampliamente utilizados en este tipo de servicios a nivel de proveedores reales. En el Captulo 3 se exploran las cualidades tericas de diferentes herramientas de medicin de desempeo, concluyendo que existen muchos tipos de aplicaciones comerciales y no comerciales as como muchas clasificaciones. Se determin que la mejor clasificacin es la de herramienta intrusiva y herramienta no intrusiva.

165

Por su parte, en el Captulo 4 se ejecutan pruebas con algunas de las herramientas exploradas en el Captulo 3 y empezando desde las ms bsicas hasta las ms complejas. Se constat que es posible abarcar los requerimientos de la metodologa de pruebas Y.1564 y RFC 2544 mediante estas herramientas, adems de que brindan la posibilidad de efectuar todas las mediciones requeridas por la SUTEL en el Captulo 7 del Reglamento de Prestacin y Calidad de los Servicios. Para la herramienta comercial evaluada, se determin que satisface todos los requerimientos de la metodologa de pruebas Y.1564 y RFC 2544; sin embargo, presenta dos desventajas a nivel de su calificacin. Primero, se trata de una plataforma costosa y segundo no presenta mucha versatilidad en la generacin del trfico al utilizar software privativo. Entre sus puntos ms altos se encuentra la portabilidad. En relacin con las dems herramientas, se concluye que la capacidad de scripting para la generacin del trfico de prueba es sumamente til para evaluar el comportamiento de una red ante un determinado flujo de servicios. Especficamente sobresalen las herramientas D-ITG y MGEN, dada la posibilidad de graficar los resultados. Adems de estas ventajas, estas herramientas son gratuitas y se encuentran actualmente en desarrollo. Entre los puntos dbiles se encuentran las dificultades de instalacin y el requerimiento del manejo de plataformas Linux a nivel de terminal de comandos. Adems, las interfaces no son amigables con el usuario, de ah que no hayan tenido un auge mayor.

166

Adems de las herramientas para la medicin de desempeo a nivel de proveedor de servicios, se evaluaron herramientas a nivel de suscriptor y que generalmente son percibidas como herramientas de medicin de desempeo. En el caso del Speedtest de Ookla se concluye que es una herramienta muy precisa en la medicin del throughput bajo condiciones ideales; en las cuales ni la interfaz de red del servidor ni la del cliente se encuentran siendo utilizadas para otros procesos de red. Por esta razn se recomienda mantener un servidor dedicado a las pruebas de Speedtest de Ookla y con un gran ancho de banda disponible en su interfaz. Es evidente que no se puede considerar la prueba de Speedtest de Ookla como un parangn vlido en la medicin de la mtrica de throughput Por otro lado, en relacin con la herramienta NetPerSec para el monitoreo de la actividad de las interfaces de red de un dispositivo, se constat que no brinda el valor de throughput desde la concepcin de tasa real de informacin transmitida; ya que se utilizan peticiones SNMP a los objetos ifInOctets() e ifOutOctets() para obtener el nmero de bytes que entran por una interfaz, en este caso ambos objetos devuelven la informacin en bytes que incluye los encabezados de trama, de IP y de los dems protocolos de nivel superior. Adems de las herramientas activas y a nivel de suscriptor evaluadas, se consider la herramienta Nagios para el monitoreo pasivo de dispositivos de redes junto con la aplicacin PNP4Nagios para graficar los resultados. Se concluy que mediante esta

167

plataforma libre y gratuita es posible medir el parmetro de nivel de ocupacin de un enlace solicitado por la SUTEL sin falsear el resultado obtenido. El objetivo general del proyecto se ciment sobre la necesidad de evaluar cualitativa y cuantitativamente varias herramientas de desempeo de redes Ethernet y Metro Ethernet. Dicho objetivo se cumpli; siendo posible estructurar la Tabla 4.6 y la Tabla 5.8 donde se resumen los resultados obtenidos en relacin con la valoracin de las herramientas para las metodologas de pruebas Y.1564 y el RFC 2544 y para los parmetros establecidos por la SUTEL en el Captulo 7 del Reglamento de Prestacin y Calidad de los Servicios. Desde el punto de vista de la problemtica planteada en el Captulo 1, se constat que los mltiples conceptos relacionados con el desempeo de cualquier cosa (sea un procesador, un dispositivo de red, etc.) hacen que este tema sea punto de encuentro de mucha divergencia. Por ejemplo, en una norma internacional se puede encontrar la definicin de latencia como RTT y en otras como one-way-delay; del mismo modo ocurre con los mtodos de medicin de las mtricas. Es decir, no hay una correspondencia final y el ajuste de la legislacin de regulacin termina definindose a partir de alguna de las tantas normas internacionales. Es por eso que segn la problemtica planteada se puede concluir que la comprobacin e implementacin de herramientas de desempeo es un tema sumamente actual y que constantemente vara conforme se desarrollan nuevas tecnologas. De ah que el presente proyecto puede tomarse como un pequeo esfuerzo por esclarecer algunos de

168

los elementos bsicos de la medicin de desempeo de redes, especficamente de redes Ethernet y Metro Ethernet.

6.2.

Recomendaciones

Durante el desarrollo de la investigacin terica y la labor de implementacin de las herramientas de desempeo, surgen situaciones que permiten discernir mejores prcticas o mejores metodologas para la ejecucin del proyecto. Partiendo de estas situaciones, se formulan las siguientes recomendaciones para futuras incursiones en proyectos afines a la temtica estudiada: Es necesario utilizar las caractersticas intrnsecas de las herramientas de medicin de desempeo para la estructuracin de las pruebas a efectuar en la evaluacin de las mismas; sin embargo, debe elaborarse un marco de referencia para ser probado en cada una de las herramientas por igual. En otras palabras, se deben aprovechar los atributos especficos de las aplicaciones de medicin de desempeo para efectuar pruebas, pero llevando a cabo siempre un conjunto similar de pruebas para todas las herramientas. Esta mejora evidentemente acarrea el conocimiento previo de la aplicacin de la herramienta por lo que requiere mucho ms tiempo de trabajo. Se sugiere utilizar el mismo hardware y software para las terminales de la red Metro Ethernet de prueba. En el presente proyecto se intent, en la medida de lo posible, utilizar al menos interfaces de red similares para las terminales de prueba; sin embargo, si se tiene acceso a un auspicio econmico, sera muy valioso asegurarse de adquirir el mismo hardware. 169

Se recomienda utilizar las herramientas D-ITG y MGEN para efectuar cualquier valoracin a una red Ethernet o Metro Ethernet; incluso se podra extender a la evaluacin de servicios en redes de Cable o ADSL. Ambas herramientas proveen grandes atributos para la generacin de todo tipo de servicios (VoIP, datos, video, etc.)

Se debera utilizar una herramienta de monitoreo pasiva para la adquisicin del valor de ocupacin de un enlace (parmetro solicitado por la SUTEL).

Si se pretende ahondar en el tema de la regulacin nacional, se recomienda contactar directamente a personeros de la SUTEL para efectuar consultas relacionadas con aspectos ms profundos del Reglamento de Prestacin y Calidad de los Servicios y que no fueron abarcados en los alcances del presente proyecto.

Si se evala la posibilidad de dar continuidad al presente proyecto, se puede desarrollar una plataforma libre de medicin de desempeo basada en la metodologa de la UIT Y.1564 (que es la ms moderna) para redes Ethernet y Metro Ethernet. De esta forma, pequeas o medianas empresas que no tienen la capacidad de adquirir una herramienta comercial podran optar por esta solucin.

Se sugiere ampliar el estudio de las herramientas e idear un plan de pruebas para obtener los parmetros de red solicitados por la SUTEL no solamente para servicios de transferencia de datos, sino tambin para servicios como telefona IP. Adems, se puede extender la investigacin al estudio de medicin de desempeo en DOCSIS

170

(de sus siglas en ingls Data Over Cable Service Interface Specification) y en redes ADSL, por ser redes altamente difundidas.

171

BIBLIOGRAFA
[1] ARESEP. (13 de Agosto de 2008). ARESEP. Recuperado el 4 de Octubre de 2011, de http://www.aresep.go.cr/docs/Ley%207593%20con%20reformas%208660.pdf [2] ARESEP. (30 de Junio de 2008). ARESEP. Recuperado el 24 de Octubre de 2011, de http://www.aresep.go.cr/docs/8642%20Ley%20Gral%20de%20Telecomunicacione s.doc [3] ARESEP. (29 de Abril de 2009). ARESEP. Recuperado el 23 de Octubre de 2011, de http://www.aresep.go.cr/docs/Reglamento%20de%20Prestacion%20y%20Calidad% 20de%20Servicios.pdf [4] ARESEP. (14 de Agosto de 2011). ARESEP. Recuperado el 2 de Octubre de 2011, de http://www.aresep.go.cr/cgi-bin/index.fwx?area=90&cmd=nuestra_funcion [5] Banda Ancha. (13 de Septiembre de 2011). Banda Ancha. Recuperado el 13 de Octubre de 2011, de Aumentar la velocidad de la conexin en Windows 7: http://wiki.bandaancha.st/Aumentar_la_velocidad_de_la_conexi%C3%B3n_a_Inter net_en_Windows_7 [6] Banda Ancha. (16 de Enero de 2011). Banda Ancha ST. Recuperado el 24 de Octubre de 2011, de http://wiki.bandaancha.st/Modificando_RWIN_para_mejorar_la_velocidad

172

[7] Beyssac, P. (18 de Marzo de 2009). Bing. Recuperado el 29 de Octubre de 2011, de http://fgouget.free.fr/bing/bing_src-readme.shtml [8] Beyssac, P. (3 de Abril de 1995). Bing Man Page. Recuperado el 15 de Octubre de 2011, de Bing Man Page: http://linux.die.net/man/8/bing [9] Blandon, D., & Daz, Y. (26 de Abril de 2008). Interactic. Recuperado el 1 de Noviembre de 2011, de http://www.interactic.org.co/component/docman/doc_download/171-medicion-dela-calidad-del-servicio-en-redes-de-proxima-generacion-en-colombia [10] Botta, A., Dainotti, A., & Pescap, A. (15 de Agosto de 2011).

http://www.grid.unina.it/software/ITG/. Recuperado el 12 de Septiembre de 2011, de D-ITG: http://www.grid.unina.it/software/ITG/ [11] Bradner, S., & McQuaid, J. (24 de Marzo de 1999). RFC 2544. Recuperado

el 25 de Septiembre de 2011, de http://tools.ietf.org/html/rfc2544 [12] Davenhall, A., & Leese, M. (2005). An introduction to Computer Network

Monitoring and Performance. Edinburgh: National e-Science Centre. [13] Davies, J. (14 de Enero de 2007). Technet. Recuperado el 20 de Octubre de

2011, de http://technet.microsoft.com/es-cr/magazine/2007.01.cableguy.aspx [14] Diallo, T. (2011). EtherSAM: The new standard in Ethernet service testing.

EXFO Applicartion Notes , 4-6. [15] ETSI. (15 de Octubre de 1994). ETSI. Recuperado el 23 de Octubre de 2011,

de http://www.etsi.org/deliver/etsi_etr/001_099/003/02_60/etr_003e02p.pdf

173

[16]

EXFO. (13 de Diciembre de 2010). Rohde & Schwars Espaa. Recuperado

el 4 de Octubre de 2011, de EtherSAM, el nuevo estndar para testear Ethernet: http://www.redeweb.com/_txt/673/42.pdf [17] Giguer, B. (16 de Diciembre de 2008). EXFO. Recuperado el 11 de

Octubre de 2011, de RFC 2544: how it helps qualify a carrier Ethernet network: http://documents.exfo.com/appnotes/anote183-ang.pdf [18] IEEE. (28 de Diciembre de 2008). IEEE. Recuperado el 12 de Septiembre de

2011, de http://standards.ieee.org/getieee802/download/802.3-2008_section1.pdf [19] ITU. (14 de Agosto de 1994). ITU. Recuperado el 22 de Octubre de 2011, de

http://www.itu.int/rec/dologin_pub.asp?lang=e&id=T-REC-E.800-200809-I!!PDFS&type=items [20] ITU. (12 de Noviembre de 2001). ITU. Recuperado el 11 de Octubre de

2011, de http://www.itu.int/rec/dologin_pub.asp?lang=e&id=T-REC-G.1000200111-I!!PDF-S&type=items [21] ITU. (12 de Marzo de 2011). ITU. Recuperado el 1 de Noviembre de 2011,

de http://www.itu.int/rec/dologin_pub.asp?lang=e&id=T-REC-Y.1540-201103I!!PDF-E&type=items [22] ITU-T. (1 de Marzo de 2011). ITU. Recuperado el 11 de Octubre de 2011,

de Recomendacin Y.1564: http://www.itu.int/dms_pubrec/itu-t/rec/y/T-RECY.1564-201103-P!!SUM-HTM-E.htm

174

[23]

Jones, R. (20 de Abril de 2011). Netperf. Recuperado el 3 de Octubre de

2011, de Netperf-talk: http://www.netperf.org/pipermail/netperf-talk/2011April/000827.html [24] Jones, R. (15 de Abril de 2011). NETPERF. Recuperado el 1 de Noviembre

de 2011, de http://www.netperf.org/netperf/NetperfPage.html [25] Mrquez, L., & Ravelo, E. (11 de Octubre de 2010). Slide Share.

Recuperado el 1 de Noviembre de 2011, de http://www.slideshare.net/prestonj_jag/calidad-de-servicio-en-redes [26] Marshall, P. (1 de Marzo de 2011). Sunrise Telecom. Recuperado el 12 de

Octubre de 2011, de Y.1564 Ethernet Service Activation Testing Methodology: http://www.sunrisetelecom.com/products/Y1564_IntelliSam_20110928.pdf [27] Mattis, M. (14 de Abril de 2006). Advanced Networking Pittsburgh

Supercomputing Center. Recuperado el 1 de Octubre de 2011, de Enabling High Performance Data Transfers: http://www.psc.edu/networking/projects/tcptune/#Linux [28] McCloghrie, K. (16 de Marzo de 1991). IETF. Recuperado el 26 de Octubre

de 2011, de MIB for Network Management: http://www.ietf.org/rfc/rfc1213.txt [29] Ookla. (21 de Septiembre de 2010). Ookla Documentation. Recuperado el

13 de Noviembre de 2011, de http://wiki.ookla.com/test_flow [30] Schmidberg, E. (14 de Abril de 2009). IEEE. Recuperado el 24 de

Septiembre de 2011, de http://www.ieee.org.ar/downloads/metroethernet.pdf

175

[31]

Semken, V. (13 de Septiembre de 2011). D-ITG. Recuperado el 13 de

Septiembre de 2011, de http://www.semken.com/projekte/index.html [32] Sprint. (13 de Septiembre de 2011). Sprint Network Speed Test. Recuperado

el 15 de Noviembre de 2011, de http://www6.sprint.com/landings/speedtest/?ECID=vanity:speedtest [33] Sweeney, M. (3 de Enero de 2001). PC Magazine. Recuperado el 4 de

Noviembre de 2011, de http://www.pcmag.com/article2/0,2817,4878,00.asp#fbid=2VEK6rDhLtT [34] Tanenbaum, A. (2003). Redes de computadoras . Mxico: Pearson

Educacin. [35] U.S. Navy. (15 de Agosto de 2011). MGEN. Recuperado el 26 de

Septiembre de 2011, de http://cs.itd.nrl.navy.mil/work/mgen/ [36] UIT. (12 de Agosto de 1994). UIT. Recuperado el 14 de Octubre de 2011, de

http://www.itu.int/rec/dologin_pub.asp?lang=e&id=T-REC-E.800-199408-S!!PDFS&type=items [37] UIT. (16 de Febrero de 2006). UIT. Recuperado el 2 de Noviembre de 2011,

de http://www.itu.int/rec/dologin_pub.asp?lang=e&id=T-REC-Y.1541-200602I!!PDF-S&type=items [38] Velsquez, K., & Gamess, E. (24 de Agosto de 2009). Universidad Central

de Venezuela. Recuperado el 3 de Noviembre de 2011, de www.ciens.ucv.ve/escueladecomputacion/documentos/archivo/86

176

APNDICES
Apndice 1
Configuracin terminal ProyectoElectricoNP
# This file describes the network interfaces available on your system # and how to activate them. For more information, see interfaces(5). # The loopback network interface auto lo iface lo inet loopback # The primary network interface # Configuracin eth0 auto eth0 iface eth0 inet static address 172.16.1.3 netmask 255.255.255.0 broadcast 172.16.1.255 network 172.16.1.0

Configuracin terminal ProyectoElectricoNP2

# This file describes the network interfaces available on your system # and how to activate them. For more information, see interfaces(5). # The loopback network interface auto lo iface lo inet loopback # The primary network interface # Configuracin eth0 auto eth0 iface eth0 inet static address 172.16.1.2 netmask 255.255.255.0 broadcast 172.16.1.255 network 172.16.1.0

177