Arquitectura-de-gestion-de-servicios-en-redes-convergentes

Vista previa del material en texto

InstItuto PolItécnIco nacIonal. 
 EscuEla suPErIor dE IngEnIEría mEcánIca y EléctrIca. 
maEstría En cIEncIas En IngEnIEría dE tElEcomunIcacIonEs. 
 
“ARQUITECTURA DE GESTIÓN 
DE SERVICIOS EN REDES 
CONVERGENTES” 
 
TESIS 
QUE PARA OBTENER EL GRADO DE 
MAESTRO EN CIENCIAS EN INGENIERIA DE 
TELECOMUNICACIONES 
 
PRESENTA 
ING. CARLOS MAURICIO GÓMEZ SANDOVAL. 
 
DIRECTORES DE TESIS 
DR. SALVADOR ÁLVAREZ BALLESTEROS 
M. EN C. CHADWICK CARRETO ARELLANO 
 
 
México, DF. Junio del 2012 
 
 
INSTITUTO POLITÉCNICO NACIONAL 
SECRETARÍA DE INVESTIGACIÓN Y POSGRADO 
 
CARTA CESIÓN DE DERECHOS 
 
En la Ciudad de México el día 6 del mes Junio del año 2012, el (la) que suscribe 
Lic. Carlos Mauricio Gómez Sandoval, alumno del Programa de Maestría en 
Ciencias en Ingeniería en Telecomunicaciones con número de registro A100486, 
adscrito a la Escuela Superior de Ingeniería Mecánica y Eléctrica, Unidad 
Zacatenco, manifiesta que es autor (a) intelectual del presente trabajo de Tesis bajo 
la dirección de la Dr. Salvador Álvarez Ballesteros y el M. en C. Chadwick Carreto 
Arellano y cede los derechos del trabajo intitulado “ARQUITECTURA DE 
GESTIÓN DE SERVICIOS EN REDES CONVERGENTES”, al Instituto 
Politécnico Nacional para su difusión, con fines académicos y de investigación. 
Los usuarios de la información no deben reproducir el contenido textual, gráficas o 
datos del trabajo sin el permiso expreso del autor y/o director del trabajo. Este 
puede ser obtenido escribiendo a la siguiente dirección 
cmgomez.sandoval@gmail.com. Si el permiso se otorga, el usuario deberá dar el 
agradecimiento correspondiente y citar la fuente del mismo. 
 
 
 
 
LIC. CARLOS MAURICIO GÓMEZ SANDOVAL 
 
 
 
 
D E D I C A T O R I A 
 
 
 
 
Dedico este trabajo de tesis a mi familia, en especial a mi madre que siempre apoya todos 
mis proyectos y me ha dado las fuerzas para seguir levantándome de los tropiezos u 
obstáculos que se han presentado en mi camino a encontrar el éxito, a mi hermana por su 
amistad y cariño que siempre he percibido, y a mi abuelita por la sabiduría que me ha 
compartido a lo largo de mi vida. 
 
 
 
 
 
 
 
 
 
 
 
A G R A D E C I M I E N T O S 
 
 
Agradezco. 
A mi madre, que como mi mejor amiga, me ha enseñado a ser una persona de bien y es 
ella quien me aconseja ver la opción de tomar un posgrado, y así estar mas preparado para 
el mercado profesional que cada vez es mas competido. Gracias madre por todos tus 
consejos, por el amor que me das y por apoyar mi plan de vida. 
Al Instituto Politécnico Nacional y sus maestros por brindarme los medios y conocimientos 
para formarme como un profesionista de calidad. 
A mi asesores de tesis, Salvador por compartir su experiencia tanto de vida como 
profesional, a Chadwick por el apoyo que me brindo para realizar este proyecto, por la fe 
que tuvo en mi trabajo y por su ánimo que a todo mundo contagia. 
A mis amigos Gustavo y Luis Enrique que mas bien son mis hermanos que siempre 
estuvieron al pendiente mio, por su aliento que me dieron durante este tiempo. 
A mi amigo Luis Eduardo por los consejos que me dio para la redacción de esta tesis. 
A Víctor y Norma por darme su amistad y por compartir esas fiestas, las cuales hicieron 
que la maestría fuera divertida. 
 
 
 
 
 
 
 
Í N D I C E G E N E R A L 
 
Lista de Figuras. 
Lista de Tablas. 
Resumen .................................................................................................................................................. i 
Abstract ................................................................................................................................................... ii 
 
CAPITULO I. 
1. INTRODUCCIÓN. 
1.1. Introducción .................................................................................................................................. 1 
1.2. Justificación ................................................................................................................................... 2 
1.3. Objetivo ......................................................................................................................................... 3 
1.3.1. Objetivos específicos .................................................................................................................. 3 
1.4. Virtualización. ................................................................................................................................ 4 
1.4.1. ¿Por qué la virtualización es útil?. .............................................................................................. 5 
1.4.2. Terminología .............................................................................................................................. 6 
1.5. La Nube.......................................................................................................................................... 7 
1.5.1. Capas del cómputo en la nube. .................................................................................................. 7 
1.5.2. Tipos de nubes. ........................................................................................................................... 9 
1.6. Calidad del Servicio. .................................................................................................................... 10 
1.6.1. Reducción del Jitter. ................................................................................................................. 12 
1.6.2. Requerimientos de las Aplicaciones para Calidad del Servicio... ............................................. 12 
1.7. Evolución de las estrategias para aprovisionar la Calidad del Servicio ....................................... 14 
1.7.1. Historia de la Calidad del Servicio en Internet. ........................................................................ 15 
1.8. Ingeniería de Tráfico. .................................................................................................................. 32 
1.8.1. Caracterización de la demanda de tráfico. ............................................................................... 33 
 
 
ÍNDICE GENERAL 
 
1.8.2. Objetivos de Grado de Servicio (GoS). ...................................................................................... 33 
1.8.3. Controles de tráfico y dimensionamiento. ............................................................................... 33 
1.8.4. Monitoreo del rendimiento. .................................................................................................... 34 
1.9. Control de tráfico. ....................................................................................................................... 35 
1.9.1. Elementos de Control de tráfico. .............................................................................................. 36 
1.9.2. Operaciones básicas del control de tráfico. ............................................................................. 44 
1.10. Resumen del capítulo. ................................................................................................................. 46 
 
CAPITULO II. 
2. PRESENTACION DEL PROBLEMA Y SOLUCIÓN PROPUESTA. 
2.1. Presentación del problema. .......................................................................................................... 47 
2.2. Soluciones existentes. ................................................................................................................... 48 
2.2.1. Citrix NetScaler. ........................................................................................................................... 49 
2.3. Descripción de las características principales de la Solución ........................................................ 51 
2.3.1. Prestaciones para la manipulación del tráfico. ........................................................................... 51 
2.3.2. Prestacionesde la virtualización. ................................................................................................ 52 
2.3.3. Prestaciones de servicios de nube privada. ................................................................................ 55 
2.4. Resumen del capítulo. ................................................................................................................... 57 
 
CAPITULO III. 
3. DISEÑO DE LA SOLUCIÓN. 
3.1. Introducción. ................................................................................................................................. 59 
3.2. Arquitectura Propuesta. ............................................................................................................... 59 
3.2.1. Hipervisor VirtualBox. ................................................................................................................. 61 
3.2.2. Iproute ......................................................................................................................................... 62 
3.2.3. HTB (Hierarchical Token Bucket). ................................................................................................ 63 
3.2.4. OpenVPN. .................................................................................................................................... 63 
 
 
ÍNDICE GENERAL 
 
3.2.5. Servidor ISC DHCP3.. ................................................................................................................... 64 
3.2.6. Squid. ........................................................................................................................................... 64 
3.2.7. Quagga. ....................................................................................................................................... 65 
3.2.8. BIND. ............................................................................................................................................ 66 
3.2.9. Netfilter. ...................................................................................................................................... 66 
3.2.10. Freeradius. .............................................................................................................................. 67 
3.2.11. Hostapd. ................................................................................................................................. 67 
3.2.12. Wireshark. .............................................................................................................................. 68 
3.2.13. LAMPP. ................................................................................................................................... 69 
3.3. Control de Tráfico con Linux. ......................................................................................................... 70 
 
CAPITULO IV. 
4. CASO DE ESTUDIO. 
4.1. Introducción. ................................................................................................................................. 72 
4.2. ¿Por qué no funciona bien por defecto?. ..................................................................................... 73 
4.3. Descripción de los componentes de la red de prueba. ................................................................. 76 
4.3.1. BlackIaaS. ..................................................................................................................................... 76 
4.3.2. BlackProxy. .................................................................................................................................. 77 
4.3.3. BlackBox. ..................................................................................................................................... 77 
4.3.4. BlackLamp. .................................................................................................................................. 78 
4.3.5. BlackSar. ...................................................................................................................................... 78 
4.3.6. Clientes. ....................................................................................................................................... 79 
4.4. Pruebas y mediciones. ................................................................................................................... 80 
4.4.1. Cache transparente de web usando Netfilter, iproute2 y Squid. ............................................... 81 
4.4.2. Caracterización del tráfico a controlar. ....................................................................................... 83 
4.4.3. Control de tráfico. ....................................................................................................................... 86 
 
 
 
ÍNDICE GENERAL 
 
CAPITULO V. 
5. Resultados, conclusiones y trabajo a futuro. 
5.1. Introducción. ................................................................................................................................. 93 
5.2. Mediciones. .................................................................................................................................. 95 
5.3. Conclusiones. ................................................................................................................................. 99 
5.3.1. Trabajo a Futuro. ....................................................................................................................... 101 
 
REFERENCIAS BIBLIOGRÁFICAS ......................................................................................................... 103 
 
ANEXO A: Articulo: Virtualización de dispositivos de Capa 3 y 4 utilizando Linux. Vigesimosegunda 
reunión internacional de otoño de comunicaciones, computación, electrónica, automatización, 
robótica y exposición industrial ROC&C’2011, celebrada del 29 de noviembre al 3 de diciembre del 
2011 en Acapulco, Gro. 
ANEXO B: Código para implementación de la solución. 
 
I N D I C E D E F I G U R A S 
 
 
 
 
FIGURA 1.1. Capas del cómputo en la nube. ............................................................................................................... 8 
FIGURA 1.2. Relación entre la probabilidad de llegada de los datagramas y los parámetros de QoS ...................... 11 
FIGURA 1.3. Fluctuación del retardo “Jitter” ............................................................................................................... 12 
FIGURA 1.4. Efectos de la congestión en el tiempo de servicio y el rendimiento. ..................................................... 13 
FIGURA 1.5. Cabecera IPv4. ..................................................................................................................................... 16 
FIGURA 1.6. Funcionamiento de RSVP en Multicast. ................................................................................................ 18 
FIGURA 1.7. Reparto de recursos en IntServ ............................................................................................................ 19 
FIGURA 1.8. Problema de escalabilidad de RSVP .................................................................................................... 20 
FIGURA 1.9. Cabecera IPv6 ...................................................................................................................................... 21 
FIGURA 1.10. Campo DS (RFC 2474) ....................................................................................................................... 22 
FIGURA 1.11. Cabecera IPv4 con DiffServ ................................................................................................................ 22 
FIGURA 1.12. Cabecera IPv6 con DiffServ ................................................................................................................ 23 
FIGURA 1.13. Aparición del campo DS en IPv4 eIPv6 ............................................................................................. 23 
FIGURA 1.14. Políticas de Tráfico en el Servicio AF .................................................................................................. 27 
FIGURA 1.15. Reparto de recursos en DiffServ ......................................................................................................... 27 
FIGURA 1.16. Funcionamiento de DiffServ en Internet .............................................................................................. 28 
FIGURA 1.17. Funciones QoS desempeñadas por los enrutadores .......................................................................... 29 
FIGURA 1.18. Etiquetado de tramas según 802.1Q. ................................................................................................. 30 
FIGURA 1.19. Encolamiento de paquetes en enrutadores y conmutadores (nivel 2 y 3). .......................................... 31 
FIGURA 1.20. Clasificación de la Ingeniería de tráfico en 4 categorías. .................................................................... 32 
FIGURA 1.21. Escalas de tiempo para las tareas de Gestión y operación de redes. ................................................. 34 
FIGURA 1.22. Tareas de la Gestión y operación de Redes ....................................................................................... 35 
FIGURA 1.23. Flujos en una videoconferencia. .......................................................................................................... 37 
FIGURA 1.24. Cola FIFO............................................................................................................................................ 38 
FIGURA 1.25. Cola FIFO-Fast. .................................................................................................................................. 39 
FIGURA 1.26. Filtro de Tokens y Buckets. ................................................................................................................. 40 
FIGURA 1.27. Filtro de Token Bucket. ....................................................................................................................... 41 
FIGURA 1.28. Cola SFQ. ........................................................................................................................................... 42 
FIGURA 1.29. Encolamiento con clases. ................................................................................................................... 42 
FIGURA 1.30. Encolamiento con priorización ............................................................................................................ 43 
 
 
 
 
 
ÍNDICE DE FIGURAS 
 
FIGURA 2.1. Escenarios del pasado vs. Arquitectura Propuesta. .............................................................................. 51 
 
FIGURA 3.1. Descripción arquitectura Nivel 1. ........................................................................................................... 60 
FIGURA 3.2. Descripción Arquitectura Nivel 2. .......................................................................................................... 60 
FIGURA 3.3. Descripción Arquitectura Nivel 3A. ........................................................................................................ 61 
FIGURA 3.4. Descripción Arquitectura Nivel 3B. ........................................................................................................ 61 
FIGURA 3.5. Interfaz grafica de VirtualBox. ............................................................................................................... 62 
 
FIGURA 4.1. Esquema sencillo del montaje de la red de prueba. .............................................................................. 74 
FIGURA 4.2 Esquema general para control de tratico. .............................................................................................. 75 
FIGURA 4.3 Diagrama de flujo del tráfico................................................................................................................... 83 
FIGURA 4.4. Caracterización tráfico debido al Cliente Remoto 1. Protocolo FTP. ..................................................... 84 
FIGURA 4.5. Caracterización tráfico debido al Cliente Remoto 1. Protocolo HTTP. .................................................. 85 
FIGURA 4.6. Caracterización tráfico debido al Cliente Remoto 1. Protocolo SSH. .................................................... 85 
FIGURA 4.7. Árbol de clases para HTB. .................................................................................................................... 89 
FIGURA 4.8. Diagrama de flujo sencillo para los filtros en iptables. ........................................................................... 90 
 
FIGURA 5.1. Representación Grafica del Script Para Control de Ancho de Banda a Nivel de 
Protocolos. .................................................................................................................................................................. 94 
FIGURA 5.2. Curva de tendencia para el tráfico debido al Cliente Remoto 1. (Protocolo SSH)................................. 95 
FIGURA 5.3. Curva de tendencia para el tráfico debido al Cliente Remoto 1. (Protocolo HTTP)............................... 96 
FIGURA 5.4. Curva de tendencia para el tráfico debido al Cliente Remoto 1. (Protocolo FTP) ................................. 97 
FIGURA 5.5. Control de trafico por hosts en nivel 1 y 2, usando el protocolo ssh. .................................................. 98 
FIGURA 5.6. Distribución del tráfico global por protocolos de los Clientes 1 y 2........................................................ 99 
 
 
 
 
Í N D I C E D E T A B L A S 
 
TABLA 1.1. Parámetros de Calidad de Servicio .......................................................................................................... 11 
TABLA 1.2. Requerimientos de Calidad de Servicio de las aplicaciones ..................................................................... 14 
TABLA 1.3. ¿Reserva o Prioridad? .............................................................................................................................. 15 
TABLA 1.4. Significado del campo precedencia .......................................................................................................... 16 
TABLA 1.5. Clasificación de las aplicaciones en IntServ ............................................................................................ 17 
TABLA 1.6. Tipos de servicio en IntServ .................................................................................................................... 19 
TABLA 1.7. Campo DSCP .......................................................................................................................................... 24 
TABLA 1.8. Tipos de Servicio en DiffServ ................................................................................................................... 24 
TABLA 1.9. Significado de las clases del DSCP .......................................................................................................... 24 
TABLA 1.10. Códigos del Servicio AF. ........................................................................................................................ 25 
TABLA 1.11. Valores del campo DSCP. ...................................................................................................................... 26 
TABLA 1.12. Configuración QoS recomendada en conmutadores Catalyst 3560 para VoIP. ..................................... 31 
TABLA 1.13. Mecanismos de Control de Congestión en Internet. ............................................................................... 38 
TABLA 2.1. Comparativa Arquitectura Vs. Solución existente. .................................................................................... 50 
TABLA 3.1.Relaciones entre Elementos de TC y Operaciones de control. ................................................................ 71 
 
i 
 
 
R E S U M E N 
 
 
 
En el presente trabajo se propone, describe e implementa una infraestructura 
complementaria que asegura y controla que usuarios obtienen la mejor calidad en los 
servicios sobre una red convergente y quiénes no. El caso de estudio se realiza en un 
ambiente de una pequeña empresa, la cual cuenta con un enlace ADSL para su salida a 
Internet con tasas de transferencias regularmente bajas. Aunado a esto el tráfico sin control 
generado por los usuarios conlleva a un rendimiento pobre de la red. Este escenario no 
solamente es propio del ambiente de las PYMES, si no por el contrario es muy común, así 
esta solución podría aplicarse a diferentes ambientes como lo son el educativo, 
gubernamental, etc. 
A lo largo del trabajo se detallan el diseño e implementación de la arquitectura propuesta, 
además se especifican las características del control de tráfico y las herramientas que se 
han utilizado. Cabe mencionar que el desarrollo de la solución esta basado en 
herramientas de código libre, como el sistema Operativo Ubuntu 11.10, el cual posee gran 
compatibilidad con el hardware actual, iproute2 soporta varios métodos de clasificación, 
priorizado, compartición y limitación tanto de trafico entrante como saliente, y Squid para 
complementar las brechas del anterior. 
La solución propuesta se puede implementar en cualquier PC de escritorio, sin tener que 
desembolsar una cantidad significativa de dinero, lo cual es uno de los objetivos 
primordiales en las PYMES, que es la reducción de costes de operación. 
El caso práctico fue puesto en marcha en un segmento de la red de la ESCOM, que a su 
vez es un segmento de la red institucional del Instituto Politécnico Nacional (IPN), 
simulando la red de una PYME donde usuarios y equipos requieren de diferentes servicios. 
Esta red convergente contempla servicios ofrecidos por una nube privada, servicios de 
video, voz y datos. 
Se hace hincapié en el analisis de las ventajas y desventajas de la infraestructura 
propuesta, asi como una comparación con plataformas desarrolladas en ambientes de 
grandes empresas donde los requerimientos son mayores, haciendo la observación que se 
podría optar por la solución que se propone. Además se describen los objetivos que se 
pretenden alcanzar al tener la arquitectura en estado operativo. 
ii 
 
 
A B S T R A C T 
 
 
 
This paper proposes, describes and implements a complementary infrastructure that 
secures and controls what users get the best quality services on a converged network and 
who does not. The case study is conducted in an atmosphere of a small company, which 
has an ADSL connection for output to the Internet with low transfer rates regularly. Added to 
this, uncontrolled traffic generated by users leads to poor network performance. This 
scenario not only is proper environment for SMEs (Small and Medium Enterprises), unless 
the contrary is very common, so this solution could be applied to different environments 
such as educational, government, etc. 
Throughout the work describes the design and implementation of the proposed architecture 
also specifies the traffic control features and tools that have been used. It is worth 
mentioning that the development of the solution is based on open source tools, such as 
Operating system Ubuntu 11.10, which has great compatibility with existing hardware, 
iproute2 supports several methods for classifying, prioritizing, sharing, and limiting both 
traffic incoming and outgoing, and Squid to complement previous gaps that has iproute2. 
The proposed solution can be deployed on any desktop without having to spend a 
significant amount of money, which is one of the primary objectives in SMEs. 
The case study was launched on a network segment of the ESCOM, which in turn is a 
segment of the institutional network of the IPN, simulating an SME network users and 
devices require different services. This includes converged network services offered by a 
private cloud services, video, voice and data. 
Emphasis is placed on the analysis of the advantages and disadvantages of the proposed 
infrastructure, and in turn makes a comparison with platforms developed in environments of 
large enterprises where the requirements are higher; making the observation that one could 
choose the solution proposed. It also describes the objectives to be achieved by having the 
architecture in working order. 
1 
 
 
 
 
CAPITULO I. 
 
1. INTRODUCCIÓN. 
 
 
El capitulo presenta una breve introducción, justificación, y los objetivos del 
trabajo de tesis, así como los conceptos básicos que conforman la arquitectura 
propuesta. 
 
 
1.1. Introducción. 
 
La popularidad y el continuo crecimiento del uso de la World Wide Web han 
causado que el acceso a Internet sea un recurso imprescindible para las 
Pequeñas y Medianas Empresas (PYMES). Sin embargo, el aumento del 
tráfico de manera exponencial y la incapacidad de la infraestructura de 
Internet para hacer frente a estas exigencias da pie a inconformidades en el grado 
de servicio (GoS) percibido por los usuarios de la red. 
 
El término calidad de servicio se refiere al desempeño observado por un usuario 
final a través de una red conectada a la Internet. Este desempeño se puede medir 
en una variedad de formas: tiempo necesario para descargar una página Web, la 
calidad de audio de una llamada telefónica a través de Internet, o la calidad de una 
presentación de video en tiempo real. En una Internet que ofrece una buena 
calidad de servicio, un usuario deberá recibir de forma consistente un nivel 
razonable de rendimiento, independientemente de la cantidad de tráfico en 
Internet. En las Pymes, este nivel de rendimiento muchas veces no puede ser 
apreciado por los usuarios con mayores requerimientos de disponibilidad, ya que 
en este panorama y en otros existen usuarios que dan uso incorrecto al recurso, 
de ahí la necesidad de identificarlos y gestionarlos. 
 
 
 
 
CAPÍTULO I. INTRODUCCIÓN. 
2 
 
 
 
Tradicionalmente, la Internet sólo soporta Calidad de Servicio (QoS) del tipo 
“mejor-esfuerzo” (best-effort). Idealmente, un paquete cualquiera que inyectado a 
la Internet es tratado como cualquier otro. Tal equidad funciona para el transporte 
simple de datos. Sin embargo, lo que es bueno para un tipo de aplicación es 
potencialmente inaceptable para otras. 
 
El control del tráfico es una parte importante para garantizar que la calidad de un 
servicio solicitado es entregada por la infraestructura de red. La infraestructura de 
la Internet se compone de diversas tecnologías de capa de enlace y topologías 
que cuentan con recursos limitados para los flujos de servicio QoS. Debido a que 
los recursos de red son finitos, se requieren mecanismos para garantizar que el 
tráfico pueda ser controlado de modo que la QoS pueda ser correctamente 
aprovisionada. En el trabajo propuesto se diseña e implementa una infraestructura 
complementaria para cubrir esta necesidad. 
 
 
1.2. Justificación. 
 
En las PYMES, el acceso a Internet se da por medio de enlaces de velocidad 
moderada. Algunas veces la tasa de transferencia de estos enlaces se percibe 
como baja debido al incremento en el uso de este recurso. La integración de 
nuevas herramientas de trabajo en las redes convergentes, y en particular la nube 
privada, requiere que se garanticen los servicios ofrecidos por estas. 
En el ambiente empresarial tenemos diferentes niveles dentro de la estructura de 
sus recursos humanos, así como también tenemos diferentes niveles o perfiles de 
usuario de Internet; de ahí surge la necesidad de identificar y gestionar para así 
poder controlarlos. Por ejemplo el perfil correspondiente al comprador tiene mayor 
requerimiento de servicios y de tasa de trasferencia mayores que el contador que 
solamente necesita checar su correo. En el ambiente educativo tambiénpodemos 
introducir este concepto donde se puede crear un tabulador y a cada nodo o 
equipo se le asignen los recursos según se requiera. 
 
 
CAPÍTULO I. INTRODUCCIÓN. 
3 
 
 
El control de tráfico es el mecanismo del cual se dispone en las redes basadas en 
paquetes para regular el tráfico de información en la red, asegurando que los 
diferentes flujos dispongan de los recursos que necesitan para garantizar sus 
respectivas calidades de servicio: Latencia, tasa de transferencia, fiabilidad, y 
costo. 
El control de tráfico en Linux es uno de los mecanismos para implementar la 
estrategia de servicios diferenciados1. Conviene recordar que el control del tráfico 
no resuelve todos los problemas, a veces el problema se resuelve simplemente 
incrementando el ancho de banda. 
 
1.3. Objetivo. 
 
El objetivo del presente trabajo de tesis es diseñar e implementar una arquitectura 
dentro de un entorno de red convergente que gestione y asegure la prestación de 
un conjunto definido de servicios por medio del control de tráfico. 
 
1.3.1. Objetivos Específicos. 
 
Gestionar el ancho de banda de descarga mediante un proxy transparente, que 
limite el recurso por niveles de servicio. 
Gestionar el ancho de banda de carga mediante control de tráfico en Linux para 
asegurar la disponibilidad de los servicios de la red, por priorización de unos 
paquetes respectos de otros. 
Demostrar la mejora del desempeño de la red mediante la gestión eficiente del 
ancho de banda sobrante gracias a las herramientas de código libre para el control 
de tráfico. 
 
 
 
1 Servicios diferenciados (DiffServ): es un mecanismo de gestión de QoS basada en limitar los flujos que 
acceden a la red, y con ello garantizar la disponibilidad de recursos que requiere cada flujo. 
 
CAPÍTULO I. INTRODUCCIÓN. 
4 
 
 
 
 
 
1.4. Virtualización 
 
Como pilar de la arquitectura se hace uso de la virtualización la cual trae ventajas 
a la solución. La virtualización es la emulación a través de software de algún 
recurso como: plataformas de hardware, sistemas operativos, dispositivos de 
almacenamiento y otros recursos de red. [20] 
Dicho de otra manera, se refiere a la abstracción de los recursos de una 
computadora, llamada comúnmente Hipervisor que crea una capa de abstracción 
entre el hardware de la máquina física (anfitrión) y el sistema operativo de la 
máquina virtual (máquina virtual, invitado), dividiéndose el recurso en uno o más 
entornos de ejecución. En esta capa de software se manejan y gestionan los 
cuatro recursos principales de una computadora (CPU, Memoria, Almacenamiento 
y Conexiones de Red) y de esta manera reparte dinámicamente dichos recursos 
entre todas las máquinas virtuales. 
 
Existen diferentes formas de virtualización, es posible virtualizar: el hardware de 
servidor, el software de servidor, sesiones de usuario, aplicaciones y también se 
pueden crear máquinas virtuales en una computadora de escritorio. 
 
Entre los principales proveedores de software que han desarrollado tecnologías de 
virtualización integrales (que abarcan todas las instancias: servidor, aplicaciones, 
escritorio) se encuentran VMware y Microsoft. Estas compañías han diseñado 
soluciones específicas para virtualización, como VMware vSphere y Windows 
Server 2008 Hyper-V para la virtualización de servidores. 
 
Dentro del desarrollo del trabajo se escogió el Hipervisor de Oracle llamado 
VirtualBox ya que en general su utilización es más sencilla y sólo se requiere para 
la implementación de la nube privada en nuestra red de prueba. Si bien la 
virtualización no es un invento reciente, con la consolidación del modelo del 
cómputo en la nube, la virtualización ha pasado a ser uno de los componentes 
fundamentales, especialmente en lo que se denomina infraestructura de nube 
privada. 
 
 
 
 
CAPÍTULO I. INTRODUCCIÓN. 
5 
 
1.4.1. ¿Por qué la virtualización es útil? 
 
Las características que la virtualización ofrece son útiles para varios escenarios: 
 
• Ejecutar múltiples sistemas operativos simultáneamente. Permitiendo 
ejecutar más de un sistema operativo a la vez. De esta forma puede 
ejecutar el software escrito para un sistema operativo en otro (por ejemplo 
el software de Windows en Linux o Mac) sin tener que reiniciar el equipo 
para usarlo. 
 
• Fácil instalación de software. Los proveedores de software pueden 
utilizar máquinas virtuales para enviar configuraciones completas de 
software. Por ejemplo la instalación de una solución completa de servidor 
de correo en una máquina real puede ser una tarea tediosa; esta 
configuración puede ser empacada en una máquina virtual y posteriormente 
implementada en el hipervisor (a esto se le llama "appliance"). 
 
• Pruebas y recuperación de desastres. Una vez instalada, una máquina 
virtual y sus discos duros virtuales pueden ser considerados como un 
contenedor que puede ser arbitrariamente congelado, restablecido, 
copiado, respaldado y transportado entre los anfitriones. Además de eso, 
con el uso de otra de las características de Virtualización llamada 
snapshots (tomas instantáneas), se puede guardar un estado particular de 
una máquina virtual y volver a ese estado, si es necesario. De esta manera, 
se puede experimentar libremente con un entorno informático y si algo sale 
mal, se puede fácilmente volver a un estado anterior y evitar la necesidad 
de copias de seguridad frecuentes y restauraciones. 
 
• Consolidación de la infraestructura. La virtualización puede reducir 
significativamente los costos de hardware y la electricidad. La mayor parte 
del tiempo, las computadoras hoy en día sólo utilizan una fracción de su 
poder potencial y corren con baja carga computacional promedio del 
sistema. Una gran cantidad de recursos de hardware así como la 
electricidad se desperdician. Así, en lugar de correr muchos equipos físicos 
que utilizan parcialmente estos recursos, se pueden empacar muchas 
máquinas virtuales en pocos anfitriones de gran capacidad y equilibrar las 
cargas entre ellos. 
 
 
 
 
CAPÍTULO I. INTRODUCCIÓN. 
6 
 
 
 
1.4.2. Terminología. 
 
Para hablar de virtualización y nube es necesario conocer algunos términos, los 
cuales se comentan a continuación: 
 
• Sistema operativo anfitrión (OS host). Este es el sistema operativo del 
equipo físico en el que se ha instalado el Hipervisor. Hay diferentes 
Hipervisores para anfitriones Windows, Mac OS X, Linux y Solaris. 
• Sistema operativo invitado (guest OS). Éste es el sistema operativo que 
se ejecuta en la máquina virtual. En teoría el Hipervisor se puede ejecutar 
en cualquier sistema operativo compatible x86 (DOS, Windows, OS/2, 
FreeBSD, OpenBSD, Mac OS X), pero para lograr un rendimiento casi 
nativo del código de invitado en el equipo, se tiene que pasar por un varios 
procesos de optimización que son específicos para cada sistema operativo. 
• Máquina virtual (VM). Este es el ambiente especial que crea el Hipervisor 
para su sistema operativo invitado, mientras que se está ejecutando. En 
otras palabras, el sistema operativo anfitrión ejecuta el sistema operativo 
invitado mediante una máquina virtual. Normalmente, una máquina virtual 
aparecerá como una ventana en el escritorio de la computadora, pero 
dependiendo de las diversas interfaces del Hipervisor con que se trabaje, el 
sistema invitado puede ser visualizado en modo de pantalla completa o de 
forma remota en otro equipo. 
De una manera más abstracta, a nivel interno, el Hipervisor piensa en una 
máquina virtual como un conjunto de parámetros que determinan su 
comportamiento. Estos incluyen la configuración de hardware (la cantidad 
de memoria de la máquina virtual debe tener, los discos duros que debe 
virtualizar, los CD montados, etc.) así como la información de estado (si la 
máquina virtual está en ejecución, guardada, o si se tienen tomas 
instantáneas, etc.). 
• Características adicionales del invitado. Esto se refiere a paquetes de 
softwareespeciales que envía el Hipervisor, pero diseñados para ser 
instalados dentro de una máquina virtual para mejorar el rendimiento del 
sistema operativo invitado y añadir características extra. 
 
 
 
 
 
CAPÍTULO I. INTRODUCCIÓN. 
7 
 
 
 
1.5. La Nube. 
 
En este tipo de computación todo lo que un sistema informático puede ofrecer es 
ofrecido como servicio, de modo que los usuarios puedan acceder a los servicios 
disponibles en la Internet sin conocimientos en la gestión de los recursos que usan 
o al menos sin ser expertos en este tema. 
"El cómputo en la nube" es un nuevo modelo de prestación de servicios de 
negocio y tecnología, que permite al usuario acceder a un catálogo de servicios 
estandarizados y responder a las necesidades especificas, de forma flexible y 
adaptativa, en caso de demandas no previsibles. [20] 
 
El cambio paradigmático que ofrece el cómputo en nube es que permite aumentar 
el número de servicios basados en la red. Esto genera beneficios tanto para los 
proveedores, que pueden ofrecer de forma más rápida y eficiente un mayor 
número de servicios, como para los usuarios que tienen la posibilidad de acceder 
a ellos, disfrutando de la transparencia y de la disponibilidad inmediata del 
sistema. 
 
El cómputo en nube consigue aportar estas ventajas, apoyándose sobre una 
infraestructura tecnológica dinámica que se caracteriza, entre otros factores, por 
un alto grado de automatización, una rápida movilización de los recursos, una 
elevada capacidad de adaptación para atender a una demanda variable así como 
virtualización avanzada. 
 
El concepto de la computación en la nube empezó en proveedores de servicio de 
Internet a gran escala como Google, Amazon AWS, Microsoft y otros que 
construyeron su propia infraestructura. De entre todos ellos emergió una 
arquitectura: un sistema de recursos distribuidos horizontalmente, introducidos 
como servicios virtuales de TI escalados masivamente y manejados como 
recursos configurados y mancomunados de manera continua. 
 
1.5.1. Capas del cómputo en la nube. 
 
Existen varias capas que conforman el concepto del computo en la nube sin 
embargo para contar con una explicación clara y sencilla estas capas se 
concentran en solo tres. 
 
 
CAPÍTULO I. INTRODUCCIÓN. 
8 
 
En la figura 1.1 se muestra como se conforman las capas, y cuales son sus bases. 
 
 
Figura 1.1. Capas del cómputo en la nube 
 
 
1.5.1.1. Software como Servicio. 
 
El software como servicio (en inglés Software as a Service, SaaS) se encuentra en 
la capa más alta y caracteriza una aplicación completa ofrecida como un servicio, 
en demanda, vía multi-hilos que significa una sola instancia del software que corre 
en la infraestructura propia y sirve a múltiples clientes. 
El ejemplo de SaaS conocido más ampliamente es Google Apps que ofrece 
servicios básicos de negocio como el correo electrónico. Por otro lado, está 
Microsoft, con su plataforma MS Office como servicio SaaS con su denominación 
de Office 365, que incluye versiones online de la mayoría de las aplicaciones de 
esta suite ofimática de Microsoft. 
 
1.5.1.2. Plataforma como servicio. 
 
La capa intermedia, es llamada plataforma como servicio (en inglés Platform as a 
Service, PaaS), y es la abstracción de un ambiente de desarrollo. 
La carga arquetipo es una imagen Xen2 (parte de Servicios Web Amazon) 
conteniendo una pila básica Red (por ejemplo, una distribución de Linux, un 
servidor Red, y un ambiente de programación como Perl o Ruby). Las ofertas de 
PaaS pueden dar servicio a todas las fases del ciclo de desarrollo y pruebas del 
software, o pueden estar especializadas en cualquier área en particular, tal como 
la administración del contenido. 
 
2 Xen es un monitor de máquina virtual de código abierto desarrollado por la Universidad de Cambridge. 
http://www.cloud-america.com/ca/wp-content/uploads/2009/12/capas-cc.jpg
 
CAPÍTULO I. INTRODUCCIÓN. 
9 
 
 
Los ejemplos comerciales incluyen Google App Engine, que sirve aplicaciones de 
la infraestructura Google, y también Windows Azure, de Microsoft, una plataforma 
en la nube que permite el desarrollo y ejecución de aplicaciones codificadas en 
varios lenguajes y tecnologías como .NET, Java y PHP. Servicios PaaS tales 
como éstos permiten gran flexibilidad, pero puede ser restringida por las 
capacidades que están disponibles a través del proveedor. 
 
 
1.5.1.3. Infraestructura como servicio. 
 
La infraestructura como servicio (Infrastructure as a Service, IaaS) se encuentra 
en la capa inferior y es un medio de entregar almacenamiento básico y 
capacidades de cómputo como servicios estandarizados en la red. Servidores, 
sistemas de almacenamiento, conexiones, enrutadores, y otros sistemas se 
concentran (por ejemplo a través de la tecnología de virtualización) para manejar 
tipos específicos de cargas de trabajo. El ejemplo comercial mejor conocido es 
Amazon Web Services, cuyos servicios EC2 y S3 ofrecen cómputo y servicios de 
almacenamiento esenciales (respectivamente). 
 
 
 
1.5.2. Tipos de nubes. 
 
Existen diversos tipos de nube dependiendo de las necesidades de cada empresa, 
el modelo de servicio ofrecido y la implementación de la misma, pero básicamente 
existen tres grandes grupos. 
 
 
1.5.2.1. Nube Pública. 
 
Las nubes públicas se manejan por terceras partes, y los trabajos de muchos 
clientes diferentes pueden estar mezclados en los servidores, los sistemas de 
almacenamiento y otras infraestructuras de la nube. Los usuarios finales no 
conocen qué trabajos de otros clientes pueden estar corriendo en el mismo 
servidor, red o discos duros. 
 
 
 
 
CAPÍTULO I. INTRODUCCIÓN. 
10 
 
 
1.5.2.2. Nube Privada. 
 
Las nubes privadas son una buena opción para las compañías que necesitan alta 
protección de datos y ediciones a nivel de servicio. Las nubes privadas están en 
una infraestructura en demanda manejada por un sólo cliente que controla las 
aplicaciones que debe correr y dónde debe correrlas. Son propietarios del 
servidor, red, y discos y pueden decidir qué usuarios están autorizados a utilizar la 
infraestructura. Dentro del desarrollo de la solución se trabaja sobre una nube 
privada descrita en el Capitulo IV del Caso de Estudio. 
 
1.5.2.3. Nube Híbrida. 
 
La nube híbrida combina los modelos de nube pública y privada. El usuario es 
propietario de unas partes y comparte otras aunque de una manera controlada. La 
nube híbrida aprovisionada externamente ofrece la promesa del escalado en 
demanda, pero añade la complejidad de determinar cómo distribuir las 
aplicaciones a través de estos ambientes diferentes. 
 
 
1.6. Calidad del Servicio. 
 
La calidad del servicio (QoS) es un concepto algo obvio. Cuando una página web 
tarda bastante tiempo (alrededor de 20 segundos dependiendo del tipo de 
contenido) en terminar de cargar completamente, es debido a la calidad de 
servicio o falta de ello. Actualmente la Internet no brinda la diferenciación de QoS. 
Sin embargo la industria de la Internet está en desarrollo de nuevos protocolos 
que permitirán estos servicios, es decir las bondades que ofrece IPv6. Mientras 
tanto es necesario adaptarse a las prestaciones actuales y una buena opción es 
controlar los recursos internos. 
 
En términos simples, la calidad de servicio en las redes de datos se puede medir 
con respecto a la tasa a la cual los datos son transmitidos constantemente a 
través de la red. Esta medición refleja muchas características importantes de la 
red como su tamaño (distancia y nodos que necesita atravesar) y la capacidad de 
los enlaces de comunicación. Estas medidas también deben tomar en cuenta los 
retardos encontrados en varios componentes a lo largo del camino del tráfico de 
los datos. La habilidad de una red de proveer constantemente una tasa de 
transmisión de datos mínima y retardos máximos puede determinar su calidad de 
 
CAPÍTULO I. INTRODUCCIÓN. 
11 
 
servicio. Si el tráfico en retardo pertenecea una llamada de voz sobre IP, los 
participantes de la llamada pueden experimentar huecos intermitentes e 
interrupciones. Lo que se requiere es una manera de regular el tráfico para que así 
los paquetes encolados puedan ser enviados con un retardo imperceptible al 
usuario. A continuación se muestra la tabla 1.1 presentando los parámetros 
utilizados en la calidad de servicio [RFC 3393, Recomendación ITU-T Y.1541]. 
 
 
TABLA 1.1. Parámetros de Calidad de Servicio 
 
En la figura 1.2 se muestra la densidad de probabilidad de llegada de los 
datagramas estableciendo los parámetros usados para la medición de la Calidad 
de Servicio [21]. 
 
FIGURA 1.2. Relación entre la probabilidad de llegada de los datagramas y los parámetros de QoS. 
 
La congestión y la falta de QoS son los principales problemas de Internet 
actualmente. IP fue diseñado para dar un servicio best-effort (de mejor esfuerzo). 
Sin embargo hoy en día se utiliza para aplicaciones sensibles que no toleran redes 
sin QoS como videoconferencia, telefonía IP, VoIP (Voz sobre IP), etc. Estas 
aplicaciones no pueden funcionar en una red best-effort congestionada. Se han 
hecho modificaciones al protocolo de Internet (IP) para que pueda ofrecer QoS a 
las aplicaciones. En la figura 1.3 se muestra que cuando existe congestión se 
presenta una fluctuación del retardo (Jitter). 
Parámetro Unidades Significado 
Ancho de Banda (bandwidth) Kb/s Indica el caudal máximo que se puede 
transmitir 
Retardo (delay) o latencia (latency) ms El tiempo medio que tardan en llegar los 
paquetes 
Jitter (fluctuación del retardo) ms La fluctuación que se puede producir en el retardo 
Tasa de pérdidas (loss rate) % Proporción de paquetes perdidos respecto de los 
enviados 
 
CAPÍTULO I. INTRODUCCIÓN. 
12 
 
 
 
FIGURA 1.3. Fluctuación del retardo (Jitter) 
Retardo: 70 ms ± 20 ms (retardo: 70 ms, jitter: 40 ms) 
 
 
1.6.1. Reducción del Jitter. 
 
El jitter puede reducirse si el receptor retrasa la reproducción (buffer “anti-jitter”). 
Por ejemplo en VoIP lo habitual es enviar un paquete de voz cada 20 ms. Si el 
receptor reproduce los paquetes tal cual le llegan cualquier fluctuación en la 
entrega afectará la calidad. Si en vez de eso retrasa 40 ms la reproducción podrá 
compensar fluctuaciones de hasta 40 ms en el tiempo de entrega. En algunas 
aplicaciones (video o audio unidireccional) se llegan a introducir retardos de hasta 
30 segundos. Pero en estos casos no existe interacción receptor-emisor. 
 
 
1.6.2. Requerimientos de las Aplicaciones para 
Calidad del Servicio. 
 
El mayor impedimento para implementar ciertas aplicaciones es la falta de QoS en 
las redes de computadoras. El tráfico de las aplicaciones de video y audio en 
tiempo real como las videoconferencias y la radio por internet por ejemplo, 
requiere de un servicio predecible en términos de ancho de banda dedicado y 
límites en la cantidad de retrasos experimentados en la comunicación de los 
datos. 
 
 
 
CAPÍTULO I. INTRODUCCIÓN. 
13 
 
 
 
En adición aplicaciones de misión crítica como lo es la Planeación de recursos 
empresariales (ERP, de la sigla del término en inglés Enterprise Resource 
Planning), la administración basada en la relación con los clientes (CRM, de la 
sigla del término en inglés Customer Relationship Management), y el comercio 
electrónico en las Pymes necesitan una calidad de servicio garantizado para 
asegurar el tiempo de respuesta y proceso de las transacciones del negocio. 
Teniendo en cuenta el tamaño, el alcance, y la utilidad de la Internet, no se puede 
esperar cubrir los niveles individuales de QoS necesitados por el conjunto diverso 
de consumidores y aplicaciones. Sin embargo, la Internet debe evolucionar más 
allá de su paradigma actual de "atender todo, pero no garantizar nada" a un nuevo 
paradigma que puede distinguir entre sus usuarios y aplicaciones para proveer un 
conjunto de servicios diferenciados diseñados para complacer las demandas de 
las diferentes clases de tráfico. 
 
En particular, los protocolos y mecanismos de la Internet deben ser llevados a un 
nivel donde puedan proveer un rendimiento predecible. Esto resultará en una red 
integrada que puede permitir nuevas clases de aplicaciones de tiempo real e 
interactivo. En la figura 1.4 se muestran los efectos de la congestión sobre el 
rendimiento y tiempo de servicio [21]. De esta manera se identifica cuando es que 
la diferenciación de los servicios es útil o no. 
 
 
FIGURA 1.4. Efectos de la congestión en el tiempo de servicio y el rendimiento 
 
 
 
 
 
 
CAPÍTULO I. INTRODUCCIÓN. 
14 
 
 
Para diferenciar el tráfico de la diversidad de aplicaciones se establecen 
requerimientos de calidad de servicio para cada una de estas. A continuación la 
tabla 1.2 muestra tales requerimientos [21, ITU-T Y.1541]: 
 
 
Tipo de aplicación Ancho de 
Banda 
Retardo Jitter Tasa de 
Pérdidas 
Interactivo (telnet, www) Bajo Bajo Medio/alto Media 
Batch (e-mail, ftp) Alto Alto Alto Alta3 
Telefonía Bajo Bajo Bajo Baja 
Vídeo interactivo Alto Bajo Bajo Baja 
Vídeo unidireccional (streaming) Alto Medio/alto Bajo Baja 
Frágil (ej.: emulación de circuitos) Bajo Bajo Medio/alto Nula 
TABLA 1.2. Requerimientos de Calidad de Servicio de las aplicaciones. 
 
 
Antes de pasar a la ingeniería de tráfico se va a tomar una pequeña reseña de los 
intentos que se han hecho por cubrir las brechas que por diseño tiene el protocolo 
TCP/IP. 
 
 
 
1.7. Evolución de las estrategias para aprovisionar 
la calidad de servicio. 
 
Existen dos posibles estrategias para dar trato preferente a un usuario o una 
aplicación en una red: 
 
• Carril BUS: reservar capacidad para su uso exclusivo. A veces se 
denomina QoS hard. 
• Ambulancia: darle mayor prioridad que a otros usuarios. A veces se 
denomina QoS soft. 
 
La tabla 1.3 muestra las ventajas e inconvenientes que tienen las estrategias de 
reserva (Carril BUS) y prioridad (Ambulancia). 
 
 
 
 
3 En realidad la aplicación requiere pérdida nula, pero esto lo garantiza el protocolo de transporte TCP. 
 
CAPÍTULO I. INTRODUCCIÓN. 
15 
 
 Ventajas Inconvenientes 
Reserva • Da una garantía casi total 
• Los paquetes no necesitan llevar 
ninguna marca que indique como 
han de ser tratados, la información la 
tienen los enrutadores. 
• Requiere mantener información de estado 
sobre cada comunicación en todos los 
enrutadores por lo que pasa. 
• Se requiere un protocolo de señalización 
para informar a los enrutadores y efectuar la 
reserva en todo el trayecto. 
Prioridad • Los enrutadores no necesitan 
conservar información de estado. 
 
• Los paquetes han de ir marcados con la 
prioridad que les corresponde. 
• La garantía se basa en factores 
estadísticos, es menos segura que la 
reserva de recursos. 
TABLA 1.3. ¿Reserva o Prioridad? 
 
 
1.7.1. Historia de la Calidad del Servicio en Internet. 
 
1981: Octeto ToS (Type of Service) en IPv4 (RFC 791) 
1994: Modelo IntServ (Integrated Services RFC 1633 y el protocolo RSVP) 
1995: Campos prioridad y etiqueta de flujo en IPv6 (RFC 1883) 
1998: Modelo DiffServ (Differentiated Services RFC 2474) 
 
En paralelo se desarrollaron otras estrategias como: 
• Control de congestión en Internet 
• Calidad de servicio en redes de área local. 
 
1.7.1.1. Octeto ToS. 
 
En la definición original de la cabecera IPv4 se incluye un octeto que tenía dos 
partes: 
 
• Tres bits para indicar una prioridad (llamada precedencia). Los enrutadores 
debían enviar antes los paquetes con mayor precedencia. 
• Varios bits que actuaban de indicadores bandera o ‘flags’ para indicar que tipo 
de ruta prefiere el paquete: 
 
• Mínimo retardo. 
• Máximo rendimiento. 
• Máxima fiabilidad. 
• Mínimo costo. 
 
 
 
CAPÍTULO I. INTRODUCCIÓN. 
16 
 
 
La figura 1.5 muestra la estructura de la cabecera IPv4 con el octeto ToS. 
 
 
 
 
FIGURA 1.5. Cabecera IPv4 (RFC 791, 1981) 
 
Precedencia:prioridad (ocho niveles). Mayor es mejor. 
D, T, R, C: flags para indicar la ruta que se quiere utilizar: 
• D: Delay (mínimo retardo) 
• T: Throughput (máximo rendimiento) 
• R: Reliability (máxima fiabilidad) 
• C: Cost (mínimo costo), RFC 1349 
• X: bit reservado 
 
La tabla 1.4 muestra el significado para los bits asignados al campo de 
precedencia 
 
 Precedencia 
(decimal) 
Precedencia 
(binario) 
Nombre 
Reservados para 
tráfico de control 
7 111 Control de red 
6 110 Control de interred 
Disponibles para 
usuario 
 
5 101 Crítico / ECP 
4 100 Flash Override 
3 011 Flash 
2 010 Inmediato 
1 001 Prioridad 
0 000 Rutina 
TABLA 1.4. Significado del campo precedencia 
 
1.7.1.1.1. Inconvenientes del campo TOS 
 
Los seis niveles de prioridad disponibles para la configuración del usuario a veces 
son insuficientes. 
 
CAPÍTULO I. INTRODUCCIÓN. 
17 
 
Solo es posible indicar prioridad de envió, no otros aspectos como prioridad de 
descarte. Los fabricantes han implementado de forma no consistente el campo 
precedencia y los flags DTRC. La interoperabilidad entre fabricantes e ISPs es 
muy limitada por ello la precedencia y los flags DTRC se han usado poco. 
 
 
1.7.1.2. Modelo IntServ (Servicios Integrados). 
 
Se han desarrollado y estandarizado dos modelos de QoS en Internet. Ambos 
modelos son compatibles y coexisten. 
 
• En el modelo de Servicios Integrados el usuario solicita de antemano los 
recursos que necesita; cada enrutador del trayecto ha de tomar nota y 
efectuar la reserva solicitada (modelo carril bus). 
• En el modelo de Servicios Diferenciados el usuario marca los paquetes 
con una determinada etiqueta que marca la prioridad y el trato que deben 
recibir por parte de los enrutadores; estos no son conscientes de los flujos 
activos (modelo ambulancia). Este último es en el que esta soportado por la 
arquitectura propuesta. 
 
 Tolerantes a pérdidas Intolerantes a 
pérdidas 
Tolerantes a retardos 
(Elásticas) 
Datos UDP: DNS, 
SNMP, NTP, etc. 
Datos sobre TCP: FTP, 
Web, e-mail, etc. 
No tolerantes a 
retardos (Tiempo 
Real) 
Flujos Multimedia de 
todo tipo: video 
‘streaming’, 
videoconferencia, 
telefonía sobre Internet, 
etc. 
Emulación de circuitos 
(simulación de líneas 
dedicadas) 
TABLA 1.5. Clasificación de las aplicaciones en IntServ (Integrated Services) 
 
 
1.7.1.2.1. IntServ y RSVP 
 
Para ofrecer QoS IntServ se basa en la reserva previa de recursos en todo el 
trayecto. Para esa reserva se emplea el protocolo RSVP (Resource reSerVation 
Protocol), parte esencial del modelo IntServ. La reserva garantiza la QoS 
solicitada. Si no quedan recursos suficientes se rechaza la petición, es decir se 
ejerce control de admisión o CAC (Connection Admission Control). 
Normalmente la reserva se realiza para una secuencia de datagramas 
relacionados entre sí, que es lo que llamamos un flujo. 
 
 
CAPÍTULO I. INTRODUCCIÓN. 
18 
 
1.7.1.2.2. RSVP 
 
RSVP es un protocolo que reserva la capacidad solicitada por un flujo en todos los 
enrutadores del camino. Realmente es un protocolo de señalización pues crea 
información de estado en los enrutadores. Aunque se utilice en IP es un servicio 
orientado a conexión. Está pensado principalmente para trafico multicast. 
RSVP no es un protocolo de enrutamiento (de eso se ocuparía OSPF, BGP, PIM-
SM, etc.). RSVP reserva la capacidad solicitada en todos los enrutadores del 
camino. 
Cada enrutador ha de mantener el detalle de todas las conexiones activas que 
pasan por él y los recursos que cada una ha reservado. El enrutador mantiene 
información de estado sobre cada flujo que pasa por él. Si no se pueden asegurar 
las condiciones pedidas se rechaza la llamada (control de admisión). 
 
La Figura 1.6 muestra un ejemplo sencillo del funcionamiento en Multicast. 
 
FIGURA 1.6. Funcionamiento de RSVP en Multicast 
 
Las reservas se agregan a medida que ascienden en el árbol multicast. Así se 
optimiza el uso de la red (solo se hace la reserva una vez en cada tramo). 
 
1. F pide a C que reserve 1,5 Mb/s del caudal descendente para el flujo que le 
va a enviar A. C propaga la petición a B quien a su vez la propaga a A. 
2. Cuando más tarde E y D realizan sus peticiones no son propagadas hacia 
arriba por C o B, pues ya no es necesario. 
 
CAPÍTULO I. INTRODUCCIÓN. 
19 
 
 
A continuación la tabla 1.6 muestra las características asociadas a cada nivel de 
servicio ofrecido por RSVP y su equivalencia con ATM4 (Asynchronous 
Transference Mode). 
 
Servicio Características Equivalencia en ATM 
Garantizado 
• Garantiza un caudal mínimo y un retardo 
máximo 
• Cada enrutador del trayecto debe dar 
garantías 
• A veces no puede implementarse por 
limitaciones del medio físico. Ej. Ethernet 
compartida 
CBR (Constant Bit Rate), 
VBR-rt (Variable Bit Rate in 
real time) 
Carga Controlada 
('Controlled Load') 
• Calidad similar a la de una red de 
datagramas poco cargada 
• Se supone que el retardo es bajo, pero no 
se dan garantías 
VBR-nrt (Non-Real-Time 
Variable Bit Rate) 
`Best Effort' • Ninguna garantía (como antes sin QoS) UBR (Unspecified Bit Rate) 
TABLA 1.6. Tipos de servicio en IntServ. 
 
La figura 1.7 muestra como es el reparto de los recursos en el modelo de servicios 
integrados [21], mientras aumenta la demanda se da prioridad a cierto tráfico de 
información. 
 
FIGURA 1.7. Reparto de recursos en IntServ 
 
4 ATM es una tecnología de telecomunicación desarrollada en los años 60 para hacer frente a la gran 
demanda de capacidad de transmisión para servicios y aplicaciones (ATM simulaba los estados ofrecidos 
por la conmutación de circuitos). 
 
CAPÍTULO I. INTRODUCCIÓN. 
20 
 
 
 
1.7.1.2.3. Problemas de IntServ/RSVP 
 
RSVP produjo una euforia inicial (1996-1997) que luego dio paso a la decepción. 
La razón principal fueron problemas de escalabilidad debidos a la necesidad de 
mantener información de estado en cada enrutador. Esto hace inviable usar RSVP 
en grandes redes, por ejemplo en el core de Internet como se muestra a 
continuación en la figura 1.8. 
 
 
FIGURA 1.8. Problema de escalabilidad de RSVP. 
 
Los fabricantes de enrutadores no han desarrollado implementaciones eficientes 
de RSVP, debido al elevado costo que tiene implementar en hardware los 
algoritmos necesarios para mantener gran cantidad de información de estado. Sin 
embargo recientemente se han desarrollado mejoras en RSVP que resuelven 
algunos de estos inconvenientes. Además también ha resurgido el interés por 
RSVP para aplicarlo en MPLS (Multi-Protocol Label Switching). En estos casos el 
número de flujos no suele ser muy grande [RFC 51515 en Febrero 2008]. 
 
 
 
5 Inter-Domain MPLS and GMPLS Traffic Engineering --Resource Reservation Protocol-Traffic Engineering 
(RSVP-TE). 
 
CAPÍTULO I. INTRODUCCIÓN. 
21 
 
1.7.1.3. Campos de prioridad y etiqueta de flujo en IPv6. 
 
Al desarrollar IPv6 estaba claro que los flags del octeto ToS no eran útiles. En 
cambio la precedencia sí que tenía cierta aceptación entre los fabricantes y 
usuarios. Por otro lado la aparición del modelo IntServ por las mismas fechas llevo 
a diseñar en IPv6 algún mecanismo que simplificara la identificación de los flujos. 
La figura 1.9 muestra la incorporación de los campos de prioridad y etiqueta de 
flujo en la cabecera de IPv6. 
 
 
FIGURA 1.9. Cabecera IPv6 [RFC 1883, 1995]. 
 
• Prioridad (4 bits): hasta 16 niveles posibles. Mayor es mejor. 
• Etiqueta de flujo (24 bits): el host emisor incluye aquí una etiqueta que 
identifica de forma única cada flujo que genera. Esto permite a los 
enrutadores distinguir más fácilmente los paquetes que pertenecen al 
mismo flujo (no tienen que inspeccionar tantos campos). Aun no se han 
desarrollado aplicaciones que hagan uso del campo etiqueta de flujo. 
 
 
1.7.1.4. Modelo DiffServ (Servicios Diferenciados). 
 
Intenta evitar los problemas de escalabilidadque plantea IntServ/RSVP. 
Consiste en marcar los paquetes con una etiqueta y acordar con todos los 
enrutadores un tratamiento según la etiqueta: 
• No hay reserva de recursos por flujo (los enrutadores no “ven” los flujos). 
• No hay protocolo de señalización. 
• No hay información de estado en los enrutadores. 
 
 
CAPÍTULO I. INTRODUCCIÓN. 
22 
 
Las garantías de calidad de servicio no son tan estrictas como en IntServ, pero en 
muchos casos son suficientes. Puesto que los paquetes se clasifican en clases a 
veces a esto se le denomina CoS (Class of Service). A cada clase le corresponde 
un Nivel de Servicio Acordado SLA (Service Level Agreement). Los usuarios 
pueden contratar unos determinados valores de los parámetros QoS para cada 
clase. El número de clases posibles es limitado e independiente del número de 
flujos o usuarios; por tanto la complejidades constante, no proporcional al número 
de usuarios. La arquitectura es escalable. 
La información de QoS viaja montada en los datagramas en un campo nuevo de 
Servicios Diferenciados llamado DS (Differentiated Services). Los enrutadores solo 
han de saber qué tratamiento deben dar a cada clase. Esto lo saben por 
configuración (no es información de estado). 
 
La figura 1.10 muestra a continuación la estructura del octeto DS. 
 
 
FIGURA 1.10. Campo DS [RFC 2474] 
 
DSCP: Código de servicios diferenciados (Differentiated Services CodePoint). Seis 
bits que indican el tratamiento que debe recibir este paquete en los enrutadores. 
CU: Actualmente sin uso (Currently Unused). Este campo se utiliza actualmente 
para control de congestión [ECN, RFC 3168]. 
 
La figura 1.11 muestra el campo DS en la cabecera IPv4 con la implementación 
del modelo de Servicios Diferenciados. 
 
 
FIGURA 1.11. Cabecera IPv4 con DiffServ. 
 
CAPÍTULO I. INTRODUCCIÓN. 
23 
 
 
La figura 1.12 muestra el campo DS en la cabecera IPv6 con la implementación 
del modelo de Servicios Diferenciados. 
 
 
FIGURA 1.12. Cabecera IPv6 con DiffServ. 
 
La figura 1.13 muestra la compatibilidad de los tres primeros bits en IPv4 y IPv6 
 
FIGURA 1.13. Aparición del campo DS en IPv4 e IPv6 
 
CAPÍTULO I. INTRODUCCIÓN. 
24 
 
 
1.7.1.4.1. Campo DSCP 
 
Los 6 bits equivalen a 64 categorías de tráfico posibles. De momento se han 
dividido en 3 grupos como se muestra en la tabla 1.7: 
Codepoint Valores Uso 
cccyy0 32 Estándar 
xxxx11 16 Local/experimental 
xxxx01 16 Reservado 
TABLA 1.7. Campo DSCP 
 
La tabla 1.8 muestra los tres primeros bits (ccc) del grupo estándar que indican la 
clase. 
 
Servicio Características 
Equivalencia en 
ATM 
“Expedited Forwarding” o 
“Premium” 
• Es el que da más garantías. Equivale a una 
línea dedicada. 
• Lo garantiza todo: Caudal, tasa de pérdidas, 
retardo y jitter. 
CBR 
VBR-rt 
“Assured Forwarding” 
• Asegura un trato preferente, pero sin fijar 
garantías (no hay SLA) 
• Se definen cuatro clases y en cada una tres 
niveles de descarte de paquetes 
VBR-nrt 
“Best Effort” • Ninguna garantía, obtiene solo las migajas UBR 
TABLA 1.8. Tipos de Servicio en DiffServ 
 
La tabla 1.9 muestra el significado de las clases DSCP y su equivalente con los 
bits de precedencia del octeto ToS. 
 
Rango 
(decimal) 
Valor 
(binario) 
Significado Equivalente 
precedencia 
56-63 111xxx Control de la red 7 
48-55 110xxx Control de la red 6 
40-47 101xxx Expedited Forwarding 5 
32-39 100xxx Assured Forwarding clase 4 4 
24-31 011xxx Assured Forwarding clase 3 3 
16-23 010xxx Assured Forwarding clase 2 2 
8-15 001xxx Assured Forwarding clase 1 1 
0-7 000xxx Best effort (default) 0 
TABLA 1.9. Significado de las clases del DSCP 
 
 
 
 
CAPÍTULO I. INTRODUCCIÓN. 
25 
 
1.7.1.4.2. Servicio EF (Expedited Forwarding) o Premium. 
 
Es el que proporciona mayor seguridad al servicio. Ofrece un SLA (Service Level 
Agreement) que lo garantiza todo: 
 
• Ancho de banda mínimo 
• Tasa máxima de pérdida de paquetes 
• Retardo máximo 
• Jitter máximo 
 
Se garantiza el caudal, pero no se toleran excesos. Le corresponde el DSCP “10 
1110” (46 en decimal). 
 
 
1.7.1.4.3. Servicio AF (Assured Forwarding). 
 
El nombre es engañoso pues no asegura el envío sino que asegura un trato 
preferente (respecto al Best Effort y los AF de clase inferior), pero no garantiza 
parámetros (no hay SLAs).Se definen cuatro clases: 4, 3, 2, 1 (más es mejor). En 
los enrutadores se puede asignar recursos (ancho debanda y espacio en buffers) 
independientemente para cada clase. En cada clase se definen tres categorías de 
descarte de paquetes: alta, media y baja. Le corresponden 12 diferentes DSCP: 
“cccdd0” (ccc =clase, dd = descarte). 
 
 Mayor probabilidad de descarte. Menor probabilidad de descarte. 
Precedencia de descarte “dd” 
Mayor 
prioridad. 
 
 
 
 
 
 
 
 
 
 
Menor 
prioridad. 
Clase 
“ccc” 
Alta 
“11” 
Media 
“10” 
Baja 
“01” 
 
4 
“100” 
100110 
AF43 
38 
100100 
AF42 
36 
100010 
AF41 
34 
Binario 
Nombre 
Decimal 
3 
“011” 
011110 
AF33 
30 
011100 
AF32 
28 
011010 
AF31 
26 
 
2 
“010” 
010110 
AF23 
22 
010100 
AF22 
20 
010010 
AF21 
18 
 
1 
“001” 
 
001110 
AF13 
14 
001100 
AF12 
12 
001010 
AF11 
10 
 
TABLA 1.10. Códigos del Servicio AF. 
 
 
CAPÍTULO I. INTRODUCCIÓN. 
26 
 
Mientras que en la clase más es mejor en la probabilidad de descarte más es 
peor. 
En el servicio AF el usuario puede contratar con el ISP un caudal para cada clase. 
El ISP puede aplicar políticas sobre el tráfico del usuario y si se excede jugar con 
los bits de precedencia de descarte, usándolos de forma parecida al bit DE de 
Frame Relay o al CLP de ATM. 
La tabla 1.11 muestra el significado del campo DSCP. 
 
Decimal Binario Significado 
62 111110 Reservado 
60 111100 Reservado 
58 111010 Reservado 
56 111000 Precedencia 7 
(enrutamiento y control) 
54 110110 Reservado 
52 110100 Reservado 
50 110010 Reservado 
48 110000 Precedencia 6 
(enrutamiento y control) 
46 101110 EF (Premium) 
44 101100 Config. Usuario 
42 101010 Config. Usuario 
40 101000 Precedencia 5 
38 100110 AF43 
36 100100 AF42 
34 100010 AF41 
32 100000 Precedencia 4 
30 011110 AF33 
28 011100 AF32 
26 011010 AF31 
24 011000 Precedencia 3 
22 010110 AF23 
20 010100 AF22 
18 010010 AF21 
16 010000 Precedencia 2 
14 001110 AF13 
12 001100 AF12 
10 001010 AF11 
8 001000 Precedencia 1 
6 000110 Config. Usuario 
4 000100 Config. Usuario 
2 000010 Config. Usuario 
0 000000 Precedencia 0 
(Best Effort, default) 
TABLA 1.11. Valores del campo DSCP 
 
 
 
CAPÍTULO I. INTRODUCCIÓN. 
27 
 
Existen tres niveles de prioridad de descarte, el ISP puede utilizar uno u otro en 
función de lo grave que sea la infracción. Normalmente se utiliza el algoritmo del 
pozal agujereado (leaky bucket). La figura 1.14 muestra el manejo de los paquetes 
cuando se rebasan los niveles de servicio contratados con el proveedor de 
servicios de Internet [1]. 
 
FIGURA 1.14. Políticas de Trafico en el Servicio AF 
 
La figura 1.15 muestra como es el reparto de los recursos en el modelo de 
servicios diferenciados, mientras aumenta la demanda se da prioridad a cierto 
tráfico de información. 
 
FIGURA 1.15. Reparto de recursos en DiffServ. 
 
 
CAPÍTULO I. INTRODUCCIÓN. 
28 
 
 
 
1.7.1.4.4. Implementación del Modelo de Servicios 
Diferenciados. 
 
El DSCP (la clase) se asigna según alguna característica del paquete: IP 
origen/destino o puerto origen/destino. Se puede incluso identificar y clasificar 
paquetes que pertenecen a protocolos que utilizan puertos dinámicos por el patrón 
de tráfico que generan (p. ej. peer-to-peer). 
 
Las políticas de tráfico solo se ejercen en los enrutadores de entrada a la red del 
ISP y en los que atraviesan fronteras entre ISPs (normalmente en las fronteras 
entre sistemas autónomos). El enrutador de ingreso al dominio DiffServ se 
encarga de marcar el campo DSCP (de acuerdo con la política de QoS). Los 
siguientes sólo han de realizar el tratamiento que corresponde según el DSCP. La 
figura 1.16 muestra los llamados dominiosen el modelo de servicios diferenciados. 
 
 
FIGURA 1.16. Funcionamiento de DiffServ en Internet. 
 
El acuerdo entre los dominios de dos ISPs (peering) puede, o no, incluir QoS. Si 
dos ISP acuerdan intercambiar tráfico manteniendo la QoS han de establecer si 
los DSCP se mantienen inalterados, o si se realiza una conversión de acuerdo con 
determinada equivalencia, para mantener la semántica. 
 
 
CAPÍTULO I. INTRODUCCIÓN. 
29 
 
En la entrada de cada “Dominio de Servicios diferenciados” un enrutador frontera 
se encargará del marcado o remarcado de los paquetes, de acuerdo con la política 
de QoS. La figura 1.17 muestra la cronología que siguen los enrutadores en el 
manejo de los paquetes. 
 
 
FIGURA 1.17. Funciones QoS desempeñadas por los enrutadores. 
 
Todas las funciones mostradas en la figura 1.17 se describirán a detalle más 
adelante, y son parte fundamental de la arquitectura propuesta. 
 
1.7.1.5. IntServ vs DiffServ. 
 
IntServ fue desarrollado con anterioridad a DiffServ. Sin embargo DiffServ se ha 
extendido más que IntServ. DiffServ permite agregar flujos, el modelo es 
escalable. Debido a estas diferencias muchos fabricantes de enrutadores 
implementan versiones eficientes de DiffServ, pero no de IntServ. 
Actualmente muchos ISP implementan DiffServ. Qbone (red experimental de QoS 
en Internet 2) utiliza el modelo DiffServ. 
 
 
 
 
CAPÍTULO I. INTRODUCCIÓN. 
30 
 
1.7.1.6. Calidad del Servicio en las Redes de Área Local. 
 
Desarrollada en 802.1p y 802.1Q. Campo prioridad de tres bits. Hasta ocho 
niveles o clases posibles (modelo sin información de estado, similar a DiffServ). La 
prioridad va anotada en la etiqueta de VLAN, como consecuencia sólo puede 
utilizarse QoS en enlaces trunk6. 
El interés es limitado dada la posibilidad en la LAN de sobredimensionar a bajo 
costo. Normalmente la QoS de LAN va asociada a la QoS a nivel de red, haciendo 
una equivalencia de prioridades 802.1p a tipos de servicio IntServ o DiffServ (más 
fácil con DiffServ). 
 
 
FIGURA 1.18. Etiquetado de tramas según 802.1Q 
 
 
Pri: Prioridad (8 niveles posibles) 
CFI: El Indicador de formato canónico (Canonical Format Indicator) revela el 
formato de direcciones MAC. 
VLAN Ident.: Identificador VLAN (máximo 4096 en una misma red) 
 
 
1.7.1.6.1. QoS: Implementación 
 
Normalmente los conmutadores y enrutadores que soportan QoS tienen varias 
colas de salida por interfaz (a veces también de entrada) en las que pueden usar 
diferentes algoritmos. 
 
6 Los enlaces troncales (trunk) pertenecen a más de una VLAN. 
 
CAPÍTULO I. INTRODUCCIÓN. 
31 
 
 
Las colas pueden implementarse por software o por hardware. Cuando son por 
hardware el número suele estar entre dos y cinco. Los mecanismos hardware son 
los mismos para nivel 2 (802.1 q) que para nivel 3 (DiffServ). No hay reservas 
estrictas si no asignaciones aproximadas. 
La tabla 1.12 muestra la configuración QoS para diferentes tipos de tráfico, se les 
asigna una etiqueta DSCP, prioridad y tipo de encolamiento recomendado. 
 
Tipo de tráfico Etiqueta 
DSCP 
Clase Prior. 802.1 
p/Q 
Cola salida Caudal 
salida 
Tamaño 
buffer 
Datos VoIP 46 (EF) 5 5 1(Priority) 10% 10% 
Control Voz y video 26 (AF31) 3 3 2 (WRR) 10 % 10% 
Prot. Enrutamiento 48 6 6 
Spanning Tree 56 7 7 
Video tiempo real 34 (AF41) 4 4 3 (WRR) 60% 26% 
Datos oro (1a) 16 2 2 
Datos plata (2a) 8 1 1 4 (WRR) 20% 54% 
Datos resto (3a) 0 (BE) 0 0 
WRR: Weighted Round Robin 
TABLA 1.12. Configuración QoS recomendada en conmutadores Catalyst 3560 para VoIP 
 
La figura 1.19 muestra el caudal de salida asignado a cada cola y se muestran los 
algoritmos de encolamiento recomendados en la tabla 1.12. 
 
FIGURA 1.19. Encolamiento de paquetes en enrutadores y conmutadores (nivel 2 y 3) 
 
PQ: Priority Queue. Siempre va la primera, pero no recibe más de lo asignado. 
WRR: Weighted Round Robin. Cada cola obtendrá al menos su parte, y si hay 
caudal libre obtendrá más. 
 
 
 
 
 
CAPÍTULO I. INTRODUCCIÓN. 
32 
 
 
1.8. Ingeniería de Trafico. 
 
Las recomendaciones de la ITU-T con respecto a los componentes de la 
ingeniería de tráfico se clasifican en 4 categorías [21]: 
• Caracterización de la demanda de tráfico 
• Objetivos de Grado de Servicio (GoS) 
• Controles de tráfico y dimensionamiento 
• Monitoreo del rendimiento 
 
La figura 1.20 muestra la clasificación para la ingeniería de tráfico. Aquí es donde 
se puede ubicar el trabajo que se realizó en la tesis atendiendo el área de control 
de tráfico. Observemos que el control de tráfico implementado en el trabajo de 
tesis solo es parte del conjunto de la ingeniería de tráfico. 
 
 
FIGURA 1.20. Clasificación de la Ingeniería de tráfico en 4 categorías. [21] 
 
CAPÍTULO I. INTRODUCCIÓN. 
33 
 
 
1.8.1. Caracterización de la demanda de tráfico. 
 
El objetivo es obtener modelos matemáticos que describan aproximadamente el 
comportamiento aleatorio del tráfico de los usuarios. 
• Se requiere hacer supuestos que simplifican los complicados procesos de 
tráfico. 
• Parámetros de los modelos: media, mediana, varianza, desviación 
estándar, etc. 
 
 
1.8.2. Objetivos de Grado de Servicio (GoS). 
 
El Grado de Servicio es un conjunto de parámetros de ingeniería de tráfico usados 
para proveer una medida de la adecuación de la red a las condiciones 
especificadas en el diseño. Ejemplos: 
• Probabilidad de bloqueo 
• Probabilidad de retardo 
 
Estas probabilidades expresan la posibilidad de que ocurra el bloqueo o el retardo 
(o ambas) debido a que los recursos de la red son finitos (y por tanto la 
capacidad), mientras que la demanda de tráfico de los usuarios es aleatoria por 
naturaleza y puede exceder las capacidades de la red en algún momento. 
 
 
1.8.3. Controles de tráfico y dimensionamiento. 
 
Son herramientas de la ingeniería de tráfico, dentro de las cuales se emplean 
métodos de diseño y mecanismos de gestión para la operación de la red. 
El diseño requiere de herramientas de dimensionamiento. El dimensionamiento 
busca que la red tenga suficientes recursos para cumplir con la demanda de 
tráfico de los usuarios (recursos físicos y lógicos). 
La gestión y operación requiere de métodos de control de tráfico. Los mecanismos 
de control de tráfico se requieren para asegurar que se cumplan los objetivos de 
GoS. Y es aquí donde precisamente se encuentra todo el desarrollo para el 
aprovisionamiento de los servicios dentro de la arquitectura propuesta. Se 
retomará el control de tráfico más adelante. 
 
 
CAPÍTULO I. INTRODUCCIÓN. 
34 
 
Los controles de tráfico posibles son: 
 Enrutamiento de tráfico 
 Controles de gestión de tráfico de red 
 Métodos de protección del servicio 
 Controles de tráfico a nivel de paquetes 
 
La figura 1.21 muestra las escalas de tiempo relacionadas con la ingeniería de 
tráfico y sus categorías, las secciones marcadas por los círculos rojos son 
atendidas por el control de tráfico implementado en el presente trabajo. 
 
FIGURA 1.21. Escalas de tiempo para las tareas de Gestión y operación de redes 
 
 
1.8.4. Monitoreo del rendimiento. 
 
Mientras la red esté operando, se requiere el monitoreo del GoS. 
Soluciona posibles problemas: 
• A pesar de que la red esté dimensionada correctamente, hay situaciones 
de sobrecarga y fallos no considerados en el dimensionamiento. 
• Se requiere tomar acciones de corta duración (minutos, horas) para atacar 
tales situaciones. 
• También podría haber errores en el dimensionamiento debidos a supuestos 
incorrectos en los modelos, lo que llevaría a un GoS diferente del esperado. 
Otras situaciones que requieren monitoreo: 
• Caracterización del tráfico. 
• Diseño de la red. 
 
 
CAPÍTULO I. INTRODUCCIÓN. 
35 
 
Consecuencias del monitoreo (término de semanas, meses): 
• Reconfiguración de elementos de la red. 
• Reconfiguración del enrutamiento. 
• Ajuste en los parámetros de control de tráfico. 
 
La figura 1.22 muestra la