Arquitectura de gestión de servicios en redes convergentes

(1)

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

(2)

(3)

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 [email protected]. Si el permiso se otorga, el usuario deberá dar el agradecimiento correspondiente y citar la fuente del mismo.

(4)

D E D I C A T O R I A

(5)

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.

(6)

Í 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

(7)

Í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. Prestaciones de 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

(8)

Í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

(9)

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

(10)

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 e IPv6 ... 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

(11)

Í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

(12)

Í 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

(13)

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.

(14)

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.

(15)

1

C

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

(16)

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.

(17)

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}

(18)

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.

(19)

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.

(20)

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

(21)

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.

(22)

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

(23)

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.

(24)

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.

(25)

11 servicio. Si el tráfico en retardo pertenece a 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

(26)

[image:26.612.170.447.102.304.2]

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.

(27)

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.

(28)

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

(29)

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:

(30)

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

(31)

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

(32)

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

(33)

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)

[image:33.612.165.426.427.654.2]

`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

(34)

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}

(35)

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 escalabilidad que 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.

(36)

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.

(37)

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

(38)

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

0-7 000xxx Best effort (default) 0

(39)

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”

(40)

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

(enrutamiento y control)

46 101110 EF (Premium)

44 101100 Config. Usuario

38 100110 AF43

36 100100 AF42

34 100010 AF41

30 011110 AF33

28 011100 AF32

26 011010 AF31

22 010110 AF23

20 010100 AF22

18 010010 AF21

14 001110 AF13

12 001100 AF12

10 001010 AF11

[image:40.612.176.436.217.677.2]

(41)

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

[image:41.612.154.478.171.412.2]

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.

(42)

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

[image:42.612.111.510.350.613.2]

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 dominios en el modelo de servicios diferenciados.

FIGURA 1.16. Funcionamiento de DiffServ en Internet.

(43)

[image:43.612.94.531.171.459.2]

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.

(44)

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

[image:44.612.87.525.264.468.2]

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

(45)

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₎ ₁₆ ₂ ₂

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.

(46)

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

[image:46.612.106.509.327.707.2]

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.

(47)

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

(48)

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

[image:48.612.90.522.236.447.2]

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:

(49)

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.

[image:49.612.93.524.222.541.2]

La figura 1.22 muestra la retroalimentación que aporta el monitoreo del rendimiento.

FIGURA 1.22. Tareas de la Gestión y Monitoreo del rendimiento.

1.9. Control de Tráfico.

(50)

36 El termino Calidad de Servicio (QoS) es frecuentemente usado como sinónimo de control de tráfico. El control de trafico abarca un conjunto de mecanismos y operaciones por los cuales, los paquetes son puestos en una cola para su transmisión o recepción en una interfaz de red. Las operaciones incluyen encolamiento (queuing), clasificación (classifying), planeación (scheduling), provisión de políticas (policing), conformación (shaping) y supresión (dropping).

1.9.1. Elementos de Control de Tráfico.

1.9.1.1.

Concepto de flujo.

Un flujo es una conexión o sesión de comunicación entre dos aplicaciones [1]. En un sistema los flujos se encuentran caracterizados, y llevan asociados requisitos de QoS de acuerdo con su naturaleza. Un flujo es la entidad más pequeña a la que los enrutadores pueden aplicar una determinada QoS. Un flujo es simplex (unidireccional).

Un flujo se identifica por los siguientes cinco parámetros: • Dirección IP de origen

• Puerto de origen

• Dirección IP de destino • Puerto de destino

• Protocolo de transporte utilizado (TCP o UDP)

(51)

37 FIGURA 1.23. Flujos en una videoconferencia

1.9.1.2.

Colas.

Las colas son los mecanismos básicos que se utilizan en la planificación y organización de los paquetes. Son los elementos en los que los paquetes se reordenan, reagrupan, retrasan descartan o priorizan.

1.9.1.2.1. Cola FIFO. Disciplina de encolamiento de cola simple sin clases

(52)

38 FIGURA 1.24. Cola FIFO.

1.9.1.2.2. Disciplina de cola FIFO-Fast

Es la cola utilizada por defecto en el kernel de Linux y como su nombre lo indica, el primero que entre es el primero que sale, ningún paquete recibe un tratamiento especial. Utiliza 3 bandas y dentro de cada banda se aplican las reglas (Prioridades) FIFO (0 más prioritaria, 1 y 2 menos prioritaria), sin embargo no procesara la banda 1 mientras haya paquetes esperando en la banda 0. Lo mismo aplica para las bandas 1 y 2.

• La distribución de los paquetes en las tres colas se realiza de acuerdo con el campo de servicios diferenciados del paquete y tiene cuidado de insertar los paquetes de mínimo retraso en la banda 0.

(53)

[image:53.612.209.403.135.374.2]

39 FIGURA 1.25. Cola FIFO-Fast.

Parámetros y forma de uso.

Priomap.- Determina las prioridades de los paquetes, esta correspondencia se basa en el octeto servicios diferenciados del paquete

1.9.1.2.3. Disciplina de encolamiento Token Bucket Filter (TBF)

(54)

[image:54.612.209.400.83.269.2]

40 FIGURA 1.26. Filtro de Tokens y Buckets

El algoritmo puede ser explicado como sigue: • Un token es añadido al bucket a una tasa.

• El bucket sólo puede contener un número limitado de tokens. Si un token llega cuando el bucket está lleno, se descarta.

• Cuando un paquete con n bytes llega de una aplicación, se retiran n tokens del bucket, y el paquete se envía por la red.

• Si hay menos de n tokens en el bucket, solo se extraen los tokens y el envío de paquete se retrasa hasta que se hayan acumulados suficientes tokens en el bucket.

Una variación de este algoritmo es el que usa la arquitectura (HTB), agrega jerarquización y préstamos en diferentes clases. Permite limitar el proceso de desencolado de la información utilizando el algoritmo Token Bucket Filter.

Parámetros configuración:

• limit: Nº de byte que pueden ser encolados a la espera de token. • burst: Tamaño del bucket.

• mpu: Tamaño mínimo del paquete • rate: Tasa de generación de token.

(55)

[image:55.612.153.451.93.445.2]

41 FIGURA 1.27. Filtro Token Bucket.

1.9.1.2.4. Disciplina de encolamiento estocástico justo SFQ (Stochastic Fairness Queuing).

Utiliza múltiples colas a fin de distribuir la capacidad de transmisión entre todas las conexiones que transmiten. Utiliza una tabla hash para distribuir conexiones con colas.Una tabla hash o tabla de dispersión es una estructura de datos que asocia llaves o claves con valores.

Parámetros de configuración:

• perturb: Tiempo entre reasignaciones de la tabla hash.

• quantum: Cantidad de bytes que se sacan de una cola antes de pasar a la siguiente.

(56)

42 FIGURA 1.28. Cola SFQ.

1.9.1.2.5. Disciplina de encolamiento con clases.

A una disciplina de encolamiento se le pueden definir clases. Cada una de ellas representa una división interna a la que se pueden redirigir paquetes.

[image:56.612.128.486.88.417.2]

Una clase a su vez puede contener otras clases. A la clase que no tiene definidas clases internas se denomina clase terminal. Las clases terminales tienen definida una disciplina de encolamiento interna.

(57)

43

1.9.1.2.6. Disciplina de encolamiento con priorización.

La disciplina de encolamiento con priorización no realiza ajustes. Cada paquete que recibe lo reenvía a una clase hija de acuerdo con la configuración de sus filtros. Cada cola tiene varias clases internas la x:1, la x:2 .... Cuando recibe una orden de desencolar, primero pregunta a la x:0, y si esta tiene paquete es el que se desencola. En caso contrario pregunta a las otras por orden. Las clases internas tienen por defecto una disciplina de encolamiento FIFO pero su disciplina se puede cambiar. Los filtros pueden basarse en diferentes características de los paquetes y no sólo de DSCP.

Parámetros de una disciplina de encolamiento PRIO:

• Bands: Numero de bandas a crear.

• Priomap: Si no hay filtros se define un mapa de prioridades para interpretar el octeto de servicios diferenciados.

[image:57.612.140.463.412.624.2]

La figura 1.30 muestra un ejemplo de configuración de una disciplina de encolamiento PRIO

(58)

44

1.9.1.3.

Paquetes y Datagramas.

En los sistemas de comunicación hay dos unidades de información:

• El paquete (packet) es una unidad de información del nivel del transporte (capa 3ª de la pila OSI). Su longitud es variable, aunque puede estar limitada.

• El datagrama (frame) es una unidad de información del nivel de enlace (capa 2º de la pila OSI). Su longitud es definida por la interfaz que se utiliza. En el caso de Ethernet, hay cabecera, y datos útiles entre 0 y 1500 bytes.

1.9.2. Operaciones básicas del control de tráfico.

1.9.2.1.

Ajuste (Shaping).

Es el mecanismo por el que un paquete es retrasado en la cola para ajustar el flujo de transmisión a la salida en una tasa establecida.

• Es la operación básica para limitar el ancho de banda que utiliza el flujo que se transmite.

• Es una operación no conservativa y por tanto requiere de un buffer (cola) para soportarlo.

• Conlleva el incremento de la latencia del flujo sobre el que opera, a cambio sirve para garantizar la latencia del resto de los flujos.

1.9.2.2.

Planificación (Scheduling).

Reorganiza los paquetes de la cola de acuerdo con una cierta política de planificación:

• FIFO: First Input first output.

• SFQ (Stochastic Fair Queuing): Planifica los paquetes de forma que se

transmitan equitativamente entre todos los flujos

• WRR (Wide Round-Robin): Asigna a los paquetes de cada flujo tiempos

iguales de transmisión.

• ESFQ: (Extended Stochastic Fair Queuing): Permite modificar las tablas