pb2011 030

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

ii

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. Ing. Andrs Castro Ulate
Profesor lector Profesor lector

iii

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.

iv

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.

v

NDICE GENERAL

1. CAPTULO 1: INTRODUCCIN ..................................................... 1
1.1 Objetivos .............................................................................................. 3
1.1.1 Objetivo general .......................................................................................................... 3
1.1.2 Objetivos especficos .................................................................................................. 3
1.2 Metodologa ......................................................................................... 4
2 CAPTULO 2: DESARROLLO TERICO ...................................... 5
2.1 Conceptos preliminares....................................................................... 5
2.1.1 Modelo de referencia OSI ........................................................................................... 5
2.1.2 Modelo de referencia TCP/IP ..................................................................................... 7
2.1.3 Telecomunicaciones .................................................................................................... 8
2.1.4 Red de telecomunicaciones ......................................................................................... 8
2.1.5 Red de computadores .................................................................................................. 9
2.1.6 Red de computadores Ethernet ................................................................................. 11
2.1.6.1 Protocolo IEEE 802.1Q................................................................................... 16
2.1.7 Red de computadores Metro Ethernet ...................................................................... 17
2.1.8 Desempeo de redes, calidad de servicio y desempeo de servicio ......................... 18
2.1.8.1 Calidad de servicio (QoS) ............................................................................... 19

vi

2.1.8.2 Desempeo de red .......................................................................................... 20
2.1.8.3 Desempeo de servicio ................................................................................... 21
2.1.8.4 Relacin entre desempeo de red, desempeo de servicio y calidad de servicio 22
2.2 Sistema de regulacin de las telecomunicaciones en Costa Rica .... 25
2.2.1 Superintendencia de Telecomunicaciones ................................................................ 27
2.2.2 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. CAPTULO 3: HERRAMIENTAS DE MEDICIN DE NP ......... 42
3.1. Introduccin a la medicin del desempeo de red (NP) .................. 42
3.1.1. Tipos de medicin de desempeo de red .......................................................... 43
3.1.2 Mtricas de desempeo de red .................................................................................. 44
3.2. Recomendacin Y.1564 de la UIT y RFC 2544 ................................ 50
3.2.1. RFC 2544 .......................................................................................................... 50
3.2.2. Recomendacin Y.1564 (o Y.156sam) de la UIT ............................................ 54
3.2.2.1. SCT (prueba de configuracin del servicio) ..................................................... 58
3.2.2.2. SPT (prueba de desempeo del servicio) ......................................................... 60

vii

3.3. Herramientas bsicas para la medicin de NP ................................ 61
3.3.1. PING ................................................................................................................. 61
3.3.2. Traceroute ......................................................................................................... 63
3.3.3. Pathchar, pchar e iperf ...................................................................................... 63
3.3.4. 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. Metodologa de funcionamiento de la prueba de descarga ............................... 72
3.5.2.2. 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

viii

3.6.1.2. Modificacin de la ventana de recepcin TCP en sistemas operativos basados en
Linux 81
4. CAPTULO 4: IMPLEMENTACIN Y COMPARACIN
ANALTICA DE LAS HERRAMIENTAS DE NP ................................... 83
4.1. Prueba de implementacin: PING ................................................... 85
4.2. Prueba de implementacin: traceroute ............................................ 87
4.3. Prueba de implementacin: D-ITG .................................................. 88
4.3.1. Instalacin de D-ITG con D-ITG GUI ............................................................. 89
4.3.2. Ejecucin de pruebas en D-ITG con D-ITG GUI ............................................. 91
4.3.3. Pruebas de implementacin ejecutadas ............................................................. 94
4.3.3.1. Prueba UDP .................................................................................................... 94
4.3.3.2. Prueba TCP .................................................................................................... 98
4.3.3.3. Prueba de flujos mltiples ............................................................................. 103
4.4. Prueba de implementacin: Netperf .............................................. 107
4.4.1. Instalacin de Netperf ..................................................................................... 107
4.4.2. Prueba throughput ....................................................................................... 108
4.4.3. Prueba throughput con omni test ............................................................. 110
4.4.4. Prueba latencia (RTT) ..................................................................................... 112
4.5. Prueba de implementacin: Bing ................................................... 113

ix

4.6. Prueba de implementacin: MGEN ............................................... 115
4.6.1. Instalacin de MGEN con TRPR .................................................................... 116
4.6.2. Prueba TCP ..................................................................................................... 116
4.6.3. Grfica del trfico en tiempo real ................................................................... 118
4.7. Prueba de implementacin: mdulo comercial ............................. 119
4.7.1. Metodologa de pruebas .................................................................................. 120
4.7.2. Prueba Y.1564 ................................................................................................ 121
4.7.2.1. Prueba de datos de 5 Mbps ............................................................................ 122
4.7.2.2. 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. Metodologa de la prueba ............................................................................... 128
4.8.2. Instalacin del servidor de Speedtest de Ookla .............................................. 129
4.8.3. Resultados de la prueba .................................................................................. 130
4.8.4. 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

x

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. Mtodo de medicin segn la recomendacin de la UIT Y.1541 .. 150
5.2. Cumplimiento de niveles de retardo a nivel local e internacional 151
5.3. 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

xi

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. CAPTULO 6: CONCLUSIONES Y RECOMENDACIONES .... 163
6.1. Conclusiones .................................................................................... 163
6.2. Recomendaciones ............................................................................ 169
BIBLIOGRAFA ....................................................................................... 172
APNDICES ............................................................................................. 177
Apndice 1 ................................................................................................. 177
Configuracin terminal ProyectoElectricoNP .................................................................... 177
Configuracin terminal ProyectoElectricoNP2 .................................................................. 177

xii

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

xiii

Figura 3.5. Fase 1 de la SCT (Diallo, 2011) ......................................................................... 59
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

xiv

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 D-
ITG ...................................................................................................................................... 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-ITG 106
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

xv

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
generado desde la interfaz del servidor ............................................................................... 134
generado desde la interfaz de ambas terminales ................................................................. 135
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

xvi

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

xvii

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

xviii

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

xix

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

xx

IETF Internet Engineering Task Force
IP Internet Protocol
IS-IS Intermediate System to Intermediate System
ISO International Standard Organization
ISP Internet Service Provider
ITU International Telecommunication Union
KPI Key Performance Indicator
LAN Local Area Network
MAN Metropolitan Area Network
MEF Metro Ethernet Forum
MIB Management Information Base
MPLS Multiprotocol Level Switching
NGN Next Generation Network
NP Network Performance
NPM Network Performance Monitor
OSI Open System Interconnection
OWD One Way Delay
QoS Quality of Service

xxi

RFC Request for Comments
RTT Round Trip Time
RWIN Receive Window
SAC Service Acceptance Criteria
SCT Service Configuration Test
SDH Synchronous Digital Hierarchy
SLA Service Level Agreement
SPT Service Performance Test
SUTEL Superintendencia de Telecomunicaciones
TCP Transmission Control Protocol
UDP User Datagram Protocol
UIT Unin Internacional de Telecomunicaciones
UNI User-Network Interface
VLAN Virtual LAN
WAN Wide Area Network

xxii

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

xxiii

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

2

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.

3

1.1 Objetivos
1.1.1 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 recomendaciones, normas,
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.

4

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.

5
2 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.

6

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,

7

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

8

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

9

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.

10

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

11

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

12

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:

13

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.

14

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

15

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

16

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

17

(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

18

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

19

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

20

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)

21

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)

22

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

23

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

24

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)

25

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)

26

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.

27

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.

28

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.

29

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)

30

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.

31

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)

32

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.

33

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

34

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.

35

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.

36

Tabla 2.1. Estndares requeridos por tecnologa (ARESEP, 2008)
Tecnologa Estndar
ADSL UIT-T G992.1, G992.2 y ANSI TI.413.2
ADSL2 UIT-T G992.3 y G992.4
ADSL2+ UIT-T G992.5
HDSL UIT-T G991.1, ANSI T1.418, ETSI ETR 152
RDSI (ISDN, ISDL) BRI y PRI
UIT-T I.430, UIT-T I.431, UIT-T Q.931 ETSI ETS
300 012-1, ETSI ETS 300 102
SHDSL/G-HDSL
UIT-T G991.2, ANSI T1E1.4/2001-174, ETSI TS
101524
VDSL UIT-T G993.1
VDSL2 UIT-T G993.2
Cable modem
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,
J.143, UIT-T J.144, UIT-T J.145, UIT-T J.146,
J.163
Fibra ptica (OC-3.OC-12, OC-48,
OC192, STM-1, STM-4, STM-16 y
STM-64)
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
E1
UIT-T G.703, UIT-T G.704, UIT-T G.706, UIT-T
G.732 y UIT-T G.823
T1
UIT-T G.703, UIT-T G.704, UIT-T G.706, UIT-T
G.733, UIT-T G.824 y ANSI T1.403
Ethernet
Estndares de la serie IEEE 802.1, 802.1q,
802.1p

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

37

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.

38

Tabla 2.2. Parmetros de calidad de los servicios de transferencia de datos
Parmetro Peso relativo asignado
1. Oportunidad en la prestacin de servicios. 5%
2. Atencin y reporte de incidencias. 5%
3. Oportunidad en la facturacin de servicios. 3%
4. Reclamaciones sobre facturaciones. 2%
5. Cumplimiento del tiempo de respuesta en el centro de telegestin. 5%
6. Grado de satisfaccin y percepcin de la calidad. 5%
7. Cumplimiento de los niveles de sobresuscripcin a nivel local de los
servicios de transferencia de datos.
10%
8. Cumplimiento de los niveles de sobresuscripcin a nivel internacional
de los servicios de transferencia de datos.
10%
9. Cumplimiento de niveles de retardo a nivel local. 5%
10. Cumplimiento de niveles de retardo a nivel internacional. 5%
11. Cumplimiento de niveles de variaciones en el retardo a nivel local. 5%
12. Cumplimiento de niveles de variaciones en el retardo a nivel
internacional.
5%
13. Cumplimiento de niveles de prdida de paquetes a nivel local. 5%
14. Cumplimiento de niveles de prdida de paquetes a nivel internacional. 5%
15. Cumplimiento de niveles de ocupacin de los enlaces local e
internacional.
10%
16. Cumplimiento del desempeo de la velocidad de transferencia local e
internacional respecto a la velocidad contratada.
10%
17. Completacin de llamadas de los servidores de acceso conmutado. 10%

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.

39

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.

40

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

41

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)

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

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

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

45
Tabla 3.1. Mtricas fundamentales de NP (Davenhall & Leese, 2005)
Mtrica Definicin
Latencia o
retardo
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.
Jitter
(trmino en
ingls)
Es una variacin en cortos perodos de la posicin ideal en el tiempo de una
seal digital a travs de una red.
Prdida de
paquetes
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.
Throughput
(trmino en
ingls)
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.
Utilizacin
del enlace
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.

46
Tabla 3.2. Mtricas fundamentales para IP segn la ITU Y-1540
Mtrica Definicin
IPTD (de sus siglas en
ingls IP Packet
Time Delay)
Tiempo que toma el paquete en atravesar un elemento de la red
(host, enrutador, seccin de red, etc.).
IPDV (de sus siglas
en ingls IP Packet
Delay Variation)
Variacin en el tiempo de retardo en el arribo de cada paquete;
tambin conocido como jitter.
IPRL (IP Packet Loss
Ratio)
Es una razn de prdida de paquetes. Es la proporcin de paquetes
perdidos y el total de paquetes transmitidos, en un flujo de datos.
IPER (se sus siglas en
ingls IP Packet
Error Ratio)
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)

47
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)
Mecanismos de nodo Tcnicas de red
0
Tiempo real, sensibles
a la fluctuacin de
fase, alta interaccin
(VoIP, VTC)
Cola separada con
servicio preferencial,
preparacin del
trfico
Encaminamiento y
distancia limitados
1
Tiempo real, sensibles
a la fluctuacin de
fase, alta interaccin
(VoIP, VTC)
Encaminamiento y
distancia menos
limitados
2
Datos transaccionales,
altamente interactivas
(sealizacin)
Cola separada,
prioridad por
supresin
Encaminamiento y
distancia limitados
3
Datos transaccionales,
interactivas
Encaminamiento y
distancia menos
limitados
4
Slo prdida baja
(transacciones cortas,
datos en grandes
cantidades, flujo
continuo de video)
Cola larga, prioridad
por supresin
Cualquier
ruta/trayecto
5
Aplicaciones
tradicionales de redes
IP por defecto
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.

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

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

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

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

Figura 3.3. Topologa de prueba recomendada por el RFC 2544
Emisor DUT Receptor

51
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 Procedimiento
Presentacin de los
datos
Throughput
Determinar el
throughput
del DUT.
Donde
throughput
se entiende
como la
mnima tasa de
transferencia
en la cual
ningn
paquete se
pierde.
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)
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
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
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
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.

52
latencia en un
solo sentido).
resultado de latencia el promedio de
las 20 o ms pruebas.
Cuando la latencia vara de trama
en trama provocar problemas con
servicios de tiempo real. (Giguer,
2008)
Tasa de
prdida de
tramas
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 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.
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.
Tramas back-
to-back
Caracterizar la
habilidad del
DUT para
procesar
tramas back-
to-back.
Permite
conocer el
nmero de
tramas que se
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-to-
back 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.

53
Recuperacin
de sistema
Se pretende
caracterizar la
velocidad con
la que el DUT
se recupera de
una condicin
de sobrecarga.
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 debe presentar en
forma de tabla,
incluyendo el tamao
de trama, el
throughput y el
resultado obtenido.
Reinicio
Se pretende
caracterizar la
velocidad a la
cual el DUT se
recupera de
una condicin
de reinicio.
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.
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

54
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 out-
of-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

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

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

57

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 Descripcin
Ancho de banda
Es la tasa de la cantidad total de trfico enviada
durante durante una ventana de medicin de 1
segundo.
Frame delay (latencia)
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.
Prdida de tramas
Se aplica la misma definicin que para RFC
2544
Frame Delay Variation (jitter)
Se aplica la misma definicin que para
recomendacin Y.1540 expuesta
anteriormente.

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.

58
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

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

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.

60

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.


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

62
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

63
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

64
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

65
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 Descripcin Plataforma Licencia
Tipo de
medicin
D-ITG (de sus
siglas en
ingls
Distributed
Internet
Traffic
Generator)
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.
Linux y
Windows
Freeware Activa
Nagios 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.
Linux GPL Pasiva

66
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).
Netperf 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 Hewlett-
Packard. 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.
Linux Freeware Activa
Bing Permite obtener la medicin cruda o
real del ancho de banda de un enlace
de
Linux y
Windows
Freeware Activa

67
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.
Windows Freeware Activa
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 cliente-
servidor.
Linux y
Windows
GPL Activa
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.
Linux y
Windows
Licencia
privativa
Simulacin
Rude & Crude Es una aplicacin dividida en dos
componentes fundamentales; por un
lado RUDE (de sus siglas en ingls Real-
time 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
Linux GPL Activa

68
recibidos, paquetes recibidos fuera de
secuencia, paquetes perdidos, bytes
recibidos, retardo promedio, jittery
throughput.
Network
Traffic
Generator
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.

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

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

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

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

73
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

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

75
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

76
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

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

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

79
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

80
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

81
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

82
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

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

84

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

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

86

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 Resultado
Latencia (RTT) 0,34 ms
Prdida de paquetes 0%

87
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

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

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

90
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

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

92

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.

93

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

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

95
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 D-
ITG

96

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

97

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.

98
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
Latencia (One-way-delay) 0,127 ms
Ancho de banda utilizado 8254 bytes por segundo
Jitter 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-of-
service. 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.

99

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

100
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

101

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

102

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

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

104
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

105
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

106

Figura 4.20. Grfica de prdida de paquetes para la prueba de mltiples flujos de D-
ITG

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

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

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

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

110

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

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

112

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

113
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

114
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

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

116
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

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

118

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:

119
./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

120
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

121
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 auto-
negociacin 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.

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

123
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
Ancho de banda utilizado 5 Mbps
Jitter 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.

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

125

Tabla 4.5. Mtricas obtenidas en prueba Y.1564 de datos de 15 Mbps
Ancho de banda utilizado 14,582 Mbps
Jitter 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.

En las opciones de configuracin para el SLA de las mtricas seleccionadas en el
men de configuracin global
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.
obtuvieron los resultados mostrados en la
presentacin de los resultados se ajusta al sugerido en el RFC 2544; se expone tanto en
tablas como en grficas para cada t
En el resumen de resultados de la
designados para prdida de paquetes y latencia fueron cumplidos satisfactoriamente. Sin
embargo, tal y como se esperaba l
En relacin con los resultados de throughput
comportamiento est supeditado al tamao de trama implementado. En las pruebas
efectuadas con las herramientas previa
trama posible (1518 bytes); este hecho debe tomarse en cuenta a la hora de efectuar el
anlisis comparativo de las herramientas
las opciones de configuracin para el SLA de las mtricas seleccionadas en el
configuracin global es posible seleccionar un umbral como lmite de calidad de
desempeo para cada mtrica de forma independiente.
Prueba con throughput de 15 Mbps
Se efectu una prueba con un throughput de 15 Mbps. Luego de la ejecucin se
ieron los resultados mostrados en la Figura 4.30 y la Figura
tablas como en grficas para cada tamao de trama bajo prueba.
En el resumen de resultados de la Figura 4.30 se observa que los umbrales de SLA
embargo, tal y como se esperaba la prueba de throughput no fue superada.
En relacin con los resultados de throughput se puede analizar que su
est supeditado al tamao de trama implementado. En las pruebas
efectuadas con las herramientas previamente analizadas se utiliz el mayor tamao de
anlisis comparativo de las herramientas.
126
las opciones de configuracin para el SLA de las mtricas seleccionadas en el
es posible seleccionar un umbral como lmite de calidad de
Luego de la ejecucin se
Figura 4.31. El formato de
se observa que los umbrales de SLA
a prueba de throughput no fue superada.
se puede analizar que su
est supeditado al tamao de trama implementado. En las pruebas
z el mayor tamao de

Figura 4.30. Resumen de resultados de la pru
Figura 4.31. Grficas de resultados de la prueba de 15 Mbps para el RFC
Curiosamente se presenta un comportamiento tal que slo la trama de 128 bytes
obtuvo un resultado cuyo throughput fue mayor a 15 Mbps.
tamao de trama sera el ideal si se pretende aprovechar al mximo el ancho de ban
embargo, se demorara ms tiempo
evidente la dependencia entre el throughput y el tiempo de transmisin
En relacin con los otros parmetros se puede observar que la latencia
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.

Resumen de resultados de la prueba de 15 Mbps para el RFC 2544

Grficas de resultados de la prueba de 15 Mbps para el RFC
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 ban
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
En relacin con los otros parmetros se puede observar que la latencia
porcentual de prdida de paquetes fue 0% en todo momento.
127
eba de 15 Mbps para el RFC 2544

Grficas de resultados de la prueba de 15 Mbps para el RFC 2544
Segn este resultado, este
tamao de trama sera el ideal si se pretende aprovechar al mximo el ancho de banda; sin
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

128

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

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

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

131

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.

132

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.

133

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

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

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.

135

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.

136

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.

137
Tabla 4.6. Resumen de los resultados obtenidos en las pruebas del Speedtest de Ookla
Condiciones de la prueba Tasa de descarga (Mbps) Tasa de subida (Mbps)
Interfaces dedicadas a la
prueba
11,07 10,77
Interfaces dedicadas con
parmetros de configuracin
de Speedtest modificados
11,06 10,82
Interfaz del servidor
generando 1 Mbps de trfico
UDP
10,10 10,05
Interfaz del servidor
generando 5 Mbps de trfico
UDP
6,07 10,55
Ambas interfaces generando
5 Mbps de trfico UDP
6,05 5,46
Ambas interfaces generando
10 Mbps de trfico UDP (peor
de los escenarios)
1,06 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).

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

139

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.

140

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

141
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

142
siguiente paquete de los repositorios de Linux: sudo apt-get install gnome-system-
monitor. 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%.

143
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.
144
Tabla 4.7. Comparacin de las herramientas de desempeo para pruebas RFC 2544 y Y.1564
Nombre Tipo RFC 2544 Y.1564 Versatilidad Precio
Instalacin e
implementacin
Comentarios
Ping Activa
Throughput X Throughput X
Poca. No ofrece muchas
opciones en relacin con
medicin del desempeo.
Sin costo
Fcil. Viene por defecto en
sistemas operativos Windows y
Linux.
Se utiliza ms para
comprobar la
comunicacin entre dos
equipos de red. Sin
embargo, permite
obtener algunas mtricas.
Latencia O Latencia O
Prdida de
paquetes
O
Prdida de
paquetes
O
Back to
Back
X Jitter X
Traceroute Activa
Throughput X Throughput X
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.
Se utiliza ms para
comprobar la ruta seguida
para la comunicacin
entre dos equipos de red.
No es recomendable para
mediciones de
desempeo.
Prdida de
paquetes
X
Prdida de
paquetes
X
Back to
Back
X Jitter X
D-ITG Activa
Throughput O Throughput 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.
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.
Prdida de
paquetes
O
Prdida de
paquetes
O
Back to
Back
X Jitter O
NetPerf Activa
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.
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.
Prdida de
paquetes
O
Prdida de
paquetes
O
Back to
Back
X Jitter X

145
Bing Activa
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 X Latencia X
Prdida de
paquetes
X
Prdida de
paquetes
X
Back to
Back
X Jitter X
MGEN Activa
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.
Prdida de
paquetes
O
Prdida de
paquetes
O
Back to
Back
X Jitter O
Mdulo
Comercial
Activa
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.
Se debe
comprar la
plataforma,
el mdulo y
el bucle.
Fcil. La plataforma ya viene
con el software necesario
instalado.
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.
Prdida de
paquetes
O
Prdida de
paquetes
O
Back to
Back
O Jitter O
Nota: la X representa no aprueba y el O representa s aprueba.
146
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

147
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

148
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

149
personalizar comandos y efectuar acciones de monitoreo sumamente especficas. Este tipo
de cualidades no sera posible en herramientas de cdigo cerrado.
150
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.

151
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

152
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
Descripcin
Umbral de
retardo local
(ms)
0
Tiempo real, alta interaccin, sensibles al retardo. (Voz y
video en tiempo real)
10
1
Tiempo real, interactivos, sensibles al retardo (Voz y video
en tiempo real de menor calidad)
20
2
Datos de alta prioridad (transaccionales, altamente
interactivos)
25
3
Datos de mediana prioridad (Datos transaccionales
interactivos)
30
4
Datos de baja prioridad (transacciones cortas, datos en
grandes cantidades, flujo continuo de video streaming
40
5 Datos de mejor esfuerzo 50

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

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

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

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

155
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
Descripcin
Umbral de
prdida de
paquetes local
(%)
0
1%
1
3%
2
interactivos)
3%
3
interactivos)
5%
4
5%
5 Datos de mejor esfuerzo 5%

156
Tabla 5.6. Umbral de prdida de paquetes a nivel internacional permitido por la
SUTEL (ARESEP, 2009)
Clase de
calidad de
servicio
Descripcin
Umbral de
prdida de
paquetes
internacional
(%)
0
1%
1
3%
2
interactivos)
3%
3
interactivos)
5%
4
5%
5 Datos de mejor esfuerzo 5%

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

157
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

158
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*(Resultado-
Umbral).

159
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);

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.
0 10 20 30 40 50 60 70 80 90 100
0
10
20
30
40
50
60
70
80
90
100
Resultado (%)
C
u
m
p
l
i
m
i
e
n
t
o

(
%
)
Porcentaje de cumplimiento en funcin del resultado porcentual obtenido para k=0,5

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

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
0 10 20 30 40 50 60 70 80 90 100
0
10
20
30
40
50
60
70
80
90
100
Resultado (%)
C
u
m
p
l
i
m
i
e
n
t
o

(
%
)
Porcentaje de cumpliento en funcin del resultado obtenido para k=50

161
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.
162

Tabla 5.8. Comparacin de las herramientas de desempeo para verificar las mtricas solicitadas por la SUTEL
Herramientas de medicin de desempeo
Mtrica solicitada por
la SUTEL
PING Traceroute
D-
ITG
NetPerf Bing MGEN
Mdulo
comercial
NetPerSec
Speedtest de
Ookla
Nagios
Latencia RTT O O O O X O O X X -
Jitter X X O X X O O X X -
Prdida de paquetes O X O O X O O X X -
Nivel de ocupacin de
un enlace
X X X X X X X X X O
Throughput X X O O O O O O O -
Nota: la X representa no aprueba y el O representa s aprueba.

163
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

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

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

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

167
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

168
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

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

170
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

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

172
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

173
[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-de-
la-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

174
[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!!PDF-
S&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.1000-
200111-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-201103-
I!!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-REC-
Y.1564-201103-P!!SUM-HTM-E.htm

175
[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/2011-
April/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

176
[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!!PDF-
S&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-200602-
I!!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
177
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

pb2011 030

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

pb2011 030

Cargado por

Copyright:

Formatos disponibles

Universidad de Costa Rica

También podría gustarte