Universidad Central “Marta Abreu” de Las Villas Facultad de Ingeniería Eléctrica Departamento de Automática y Sistemas Computacionales

TRABAJO DE DIPLOMA Título: “Propuesta de Implementación Calidad de servicio en la red de la Universidad de Cienfuegos”. Autor: Héctor José Echevarria Rosquete

Tutor: MSc. Alexis Gómez Domínguez Lic. Ángel Tomás Expósito Romero

Santa Clara Curso:2008–2009 "Año del 50 Aniversario del Triunfo de la Revolución"

Universidad Central “Marta Abreu” de Las Villas Facultad de Ingeniería Eléctrica Departamento de Automática y Sistemas Computacionales

TRABAJO DE DIPLOMA Título: “Propuesta de Implementación Calidad de servicio en la red de la Universidad de Cienfuegos”.

Autor:

Héctor José Echevarria Rosquete ([email protected])

Tutores:

MSc. Alexis Gómez Domínguez ([email protected]) Lic. Ángel Tomás Expósito Romero ([email protected])

Santa Clara Curso:2008–2009

"Año del 50 Aniversario del Triunfo de la Revolución"

Hago constar que el presente trabajo de diploma fue realizado en la Universidad Central “Marta Abreu” de Las Villas como parte de la culminación de estudios de la especialidad de Ingeniería en Telecomunicaciones y Electrónica, autorizando a que el mismo sea utilizado por la Institución, para los fines que estime conveniente, tanto de forma parcial como total y que además no podrá ser presentado en eventos, ni publicados sin autorización de la Universidad.

Firma del Autor Los abajo firmantes certificamos que el presente trabajo ha sido realizado según acuerdo de la dirección de nuestro centro y el mismo cumple con los requisitos que debe tener un trabajo de esta envergadura referido a la temática señalada.

Firma del Autor

Firma del Jefe de Departamento donde se defiende el trabajo

Firma del Responsable de Información Científico-Técnica

i

PENSAMIENTO

“Toda hazaña implica esmero, sacrificio, sinsabores y hasta incomprensiones, sin duda cabe, pero eso mismo hace los triunfos más agradables. El orgullo de las personas estriba en esto mismo, precisa en saberse imponer y demostrar que se pudo lo que otros creyeron imposible”.

J. Segovia

ii

DEDICATORIA

Especialmente a mis padres por dedicarme su vida. A mis hijos por ser la luz de mi vida. A mi hermano por su cariño. A mi esposa por tanta paciencia y comprensión. A toda mi familia, por su apoyo incondicional. A mis amigos de verdad, los que están cerca, lejos o ya no están.

iii

AGRADECIMIENTOS

Agradezco de forma especial a mi madre Sonia, mi padre Ramón, mi hermano Jose Ramón, mis hijos Hectico y Deyanira y mi esposa Noemia, por su paciencia y comprensión. Sin olvidar a mis amigos Yasser, Orlandito y Richard, junto a sus familiares que con su apoyo e incondicionalidad me han ayudado siempre y que hicieron posible la realización de este trabajo, a mis tutores Alexis y Ángel, por el tiempo dedicado al trabajo. A mis profesores y compañeros de clases, por las experiencias vividas y todo lo que aprendimos juntos. A todo el que de una forma u otra ha contribuido al desarrollo de este trabajo y a mi vida como profesional , lleguen mis más sinceros agradecimientos. A todos Gracias.

iv

RESUMEN Las redes telemáticas son, sin duda alguna una de las herramientas de trabajo más empleadas en nuestras universidades, fundamentalmente debido a las posibilidades que ofrecen de intercambio académico, soporte a la investigación científica, trabajos colaborativos, educación e instrucción a distancia

y otras menos utilizadas por

las

dificultades técnicas existentes, ejemplo de ellas, los laboratorios virtuales en línea. Sin embargo, en la medida que estas posibilidades han ido en aumento los requerimientos de ancho de banda o capacidad de canal también lo han hecho, al igual que la aparición de nuevos servicios que demandan recursos. Muchos de estos servicios se pueden clasificar dentro de la categoría de ocio o entretenimiento que unido a las limitaciones existentes en los canales de comunicación con que cuentan los CES, se convierten en una amenaza a la disponibilidad y buen desempeño de los servicios telemáticos que en ellos se ofrecen a estudiantes, profesores e investigadores. Es por ello que en este trabajo se aborda el tema de la calidad de servicio en redes IP y se propone una implementación para la Red de la Universidad de Cienfuegos, a fin de disminuir o eliminar los efectos indeseables que provocan diferentes aplicaciones o servicios existentes en las redes externas que sobrecargan los canales de comunicación con flujos de informaciones no acordes a los objetivos de la red.

v

Índice PENSAMIENTO .....................................................................................................................i  DEDICATORIA .................................................................................................................... ii  AGRADECIMIENTOS ........................................................................................................ iii  RESUMEN ............................................................................................................................iv  INTRODUCCIÓN: ................................................................................................................. 1  Capitulo 1: Calidad de servicio en redes IP ............................................................................ 4  1.1.  Introducción a la Calidad de Servicios (QoS) .......................................................... 4  1.2.  Conceptos de QoS .................................................................................................... 5  1.3.  Tecnologías que se pueden emplear para implementar QoS. ................................. 7  1.4.  Parámetros para lograr Calidad de Servicios (QoS) ................................................ 8  1.4.1 

Modelos establecidos para garantizar QoS ....................................................... 9 

1.5.  Servicios Integrados (IntServ)................................................................................ 10  1.5.1 

Componentes de la arquitectura de Servicios Integrados ............................... 11 

1.5.2 

Descripción del mecanismo IntServ ............................................................... 11 

1.6.  Servicios Diferenciados (DiffServ) ........................................................................ 12  1.7.  Comparación entre los estándares .......................................................................... 14  1.8.  Implementación de QoS: ........................................................................................ 15  1.8.1 

Según la sensibilidad del tráfico de QoS: ....................................................... 15 

1.8.2 

Según quién solicite la QoS: ........................................................................... 16 

1.8.3 

Según las garantías de QoS ............................................................................. 16 

1.8.4 

Según el lugar de aplicación de QoS .............................................................. 17 

1.9.  Clasificación de información para aplicar QoS ..................................................... 17  1.9.1 

Clasificación de la información con Cisco NBAR ......................................... 19 

vi 1.10. 

Conclusiones....................................................................................................... 20 

Capitulo 2: Descripción de las metodologías de QoS seleccionadas.................................... 22  2.1 

Características de la Red UCf. ............................................................................... 22 

2.1.1  2.2 

Principales servicios empleados en la Red UCf. ............................................ 22 

Clasificación de información con Cisco NBAR .................................................... 23 

2.2.1 

Clasificación http ............................................................................................ 23 

2.3 

Usando NBAR and Policing to Protect Scare Bandwidth ..................................... 24 

2.4 

Protocolos soportados por NBAR .......................................................................... 24 

2.4.1 

Clasificaciones propias ................................................................................... 27 

2.5 

PDLM ..................................................................................................................... 28 

2.6 

Servicios de QoS apoyados por NBAR ................................................................. 28 

2.7 

Configuración Básica de NBAR ............................................................................ 29 

2.7.1 

Creando un mapa de clase NBAR .................................................................. 30 

2.7.2 

Creando una política (policy map).................................................................. 30 

2.7.3  2.8 

Aplicando la política de mapeo a una interface.................................................. 31  Integrando NBAR con CBWFQ ............................................................................ 31 

2.8.1 

Creando un Class map para identificar NBAR ............................................... 32 

2.8.2 

Configurando la política de clase en el mapa de política ............................... 32 

2.8.3 

Aplicando la política a la interface ................................................................. 33 

Capitulo 3: Implementación de QoS en la red telemática de la Universidad de Cienfuegos. .............................................................................................................................................. 34  3.1 

Análisis realizados ................................................................................................. 34 

3.2 

Implementación ...................................................................................................... 35 

3.2.1  3.3 

Configuraciones .............................................................................................. 36 

Validación de la propuesta. .................................................................................... 38 

vii 3.3.1 

Primera prueba. ............................................................................................... 38 

3.3.2 

Segunda prueba. .............................................................................................. 39 

3.3.3 

Tercera prueba. ............................................................................................... 39 

CONCLUSIONES ................................................................................................................ 40  RECOMENDACIONES....................................................................................................... 41  REFERENCIAS BIBLIOGRÁFICAS ................................................................................. 42  Glosario de Términos............................................................................................................ 43  ANEXO 1: Esquema topológico Red UCf. .......................................................................... 45 

INTRODUCCIÓN

1

INTRODUCCIÓN: Los servicios telemáticos al igual que las redes de datos han evolucionado rápidamente, eliminando las barreras geográficas y disminuyendo significativamente los retardos en las comunicaciones.

Esto

unido

al

desarrollo

de

los

equipos

de

cómputo,

de

telecomunicaciones y equipos comerciales ha influido en la migración a nuevas infraestructuras que soporten el creciente flujo de información que se genera a diario. Sin embargo no siempre existen las posibilidades de satisfacer estas necesidades con el incremento de los canales de comunicación, sobre todo teniendo en cuenta el costo de instalación y mantenimiento de los mismos. En nuestro país esto se ve más acentuado producto de las limitaciones impuestas por el bloqueo económico que repercuten directamente en la disponibilidad de la tecnología y en el elevado costo de las mismas. Ante situaciones como estas se hace necesaria la búsqueda de alternativas que permitan disminuir en alguna medida los problemas que se generan producto del congestionamiento de los enlaces tanto por la utilización necesaria de algunas aplicaciones como por el uso indiscriminado de otras menos importantes. Una de las soluciones mejor acogidas en la comunidad internacional es la llamada “Calidad de Servicio (QoS)” la cual se refiere a la capacidad de ofrecer un mejor servicio al tráfico seleccionado, soportando varias tecnologías como Frame Relay, ATM, Ethernet, 802.11, protocolo IP y redes de enrutamiento que puedan utilizar una o varias de estas tecnologías. Entre los objetivos de QoS están establecer prioridades, controlar y mejorar las pérdidas, además brinda beneficios como: • El control de los recursos – Se tiene el control sobre los recursos (ancho de banda, equipos) que se están utilizando. Por ejemplo, se puede limitar el ancho de banda consumido dándole más a las transferencias FTP o dar prioridad a una importante base de datos de acceso. • Un uso más eficiente de los recursos de la red - Utilizar la red de gestión y análisis de las herramientas, conociéndose en que está siendo utilizada la red, y determinando cuales servicios tienen prioridad. • Servicios a la medida - El control y la visibilidad proporcionada por QoS permite a los proveedores de servicios, ofrecer cuidadosamente grados de diferenciación de servicio a sus clientes.

INTRODUCCIÓN

2

• Coexistencia de aplicaciones de misión crítica - Determinadas tecnologías hacen que la red se utilice de manera eficiente en aplicaciones de misión crítica para la entidad, brindar un ancho de banda mínimo requerido por demoras en aplicaciones de voz y multimedia, vincular y obtener un justo servicio sin interferir con la misión fundamental de tráfico. Situación del problema: La Universidad de Cienfuegos al igual que muchas instituciones de su tipo en el país cuenta con una infraestructura de red telemática que permite la interconexión de todos los dispositivos presentes en el campus, además de los ubicados en las SUMs1, ofreciéndole a todos, acceso a la red del Ministerio de Educación Superior y a Internet. Para ello cuenta con diferentes enlaces, los cuales no satisfacen la demanda de interconexión existente. Sin embargo no existe la posibilidad (a corto plazo) de un aumento del ancho de banda en los canales de comunicación que permita mejorar la calidad en el intercambio de información y utilización de los recursos de la red. Por otra parte no hay implementado ningún tipo de solución alternativa como QoS que mejore o solucione la situación existente. Problema: El principal problema encontrado es precisamente la carencia de una infraestructura de QoS que permita ofrecer los servicios telemáticos empleados en la Red UCf sin las deficiencias asociadas al poco ancho de banda disponible y al uso elevado de los canales de comunicación. Hipótesis: Si se implementan funcionalidades de QoS en la red telemática de la Universidad de Cienfuegos, entonces se podrán mejorar los servicios telemáticos empleados y lograr un uso elevado de los canales de comunicación en intercambio académico e investigación, por parte de los usuarios de la misma. Objetivo general: Implementar funciones de QoS en la red telemática de la universidad de Cienfuegos que permitan mejorar el desempeño de los servicios utilizados en el proceso docente e investigativo.

1

SUM: Sedes Universitarias Municipales

INTRODUCCIÓN

3

Tareas científicas: Para el desarrollo de la investigación se utilizarán diferentes métodos y técnicas que nos permitirán enfrentar el problema. Estos métodos y técnicas favorecerán el cumplimiento de las siguientes tareas: Se realizará una revisión de la bibliografía técnico-especializada para la construcción del marco teórico que nos permitirá conocer el estado del arte referente a la utilización de QoS en redes telemáticas, principio de funcionamiento, ventajas y desventajas asociadas. Analizar las diferentes metodologías existentes para la implementación de QoS en redes telemática. Elaboración de un diagnóstico para conocer la situación de la red en la UCf, infraestructuras actuales, servicios soportados en la red y servicios empleados para el proceso docente e investigativo. Se realizarán pruebas prácticas y se utilizarán aplicaciones que nos permitirán reunir elementos para la definición de las técnicas y mecanismos a emplear, así como la simulación de situaciones reales en escenarios de pruebas. Estructura del trabajo: El trabajo estará estructurado de la siguiente forma: Introducción, tres capítulos, conclusiones, recomendaciones, referencias bibliográficas, bibliografía, glosario de términos y anexos.

CAPÍTULO 1. REVISIÓN BIBLIOGRÁFICA

4

Capitulo 1: Calidad de servicio en redes IP Se determinarán los antecedentes y estado actual del empleo de QoS en redes IP, enfocándose fundamentalmente en las implementaciones en dispositivos de red con tecnología Cisco, se evalúa su implementación en diferentes casos de estudio, analizándolos con un enfoque crítico, a partir de los cuales se seleccionará la variante a utilizar en la red telemática de la universidad de Cienfuegos.

1.1. Introducción a la Calidad de Servicios (QoS) Afirmar que el aumento del ancho de banda para cierta aplicación garantizaría un servicio de calidad para sus operadores sería como decir que sólo practicando deportes se vive más y mejor. Y aunque la aplicación desarrollada en el trabajo, en un principio, se limitará a gestionar anchos de banda, existen varios parámetros que hay que tener en cuenta para lograr QoS [1]. Hace algunos años la calidad del servicio era un elemento regulado, tenia sentido entonces utilizar la disponibilidad media de la red como la principal estadística a la hora de determinar si un proveedor de telecomunicaciones estaba cumpliendo con el servicio prometido. Pero la competencia ha aumentado obligando a tener en cuenta otros parámetros que garanticen la mayor calidad posible del servicio ofrecido, ya que los operadores comienzan a instalar nuevos equipos de transmisión de altas prestaciones y a prometer servicios de gran calidad como criterio diferenciador de sus competidores [2]. En el mundo de las comunicaciones de datos, definir la calidad de servicio debería ser relativamente fácil, ya que cada bit y byte recibidos deben ser idénticos a los que son transmitidos, incluso cuando se utilizan tecnologías como compresión de datos, detección y corrección avanzada de errores, y protocolos de transmisión de bloques. Con todo, distintos factores contribuyen a dificultar la definición de calidad de servicio, como los protocolos basados en paquetes y en células frente a las líneas de servicio, dedicadas a la congestión de la red, los diferentes requerimientos de aplicación y usuario, la mediación del protocolo, las medidas de seguridad, y el tráfico en ráfagas frente a las corrientes de datos continuas. La concurrencia de estos factores evidencia que no basta con disponer de un conjunto de parámetros de gestión del rendimiento para medir todos los impactos en todos los clientes [2]. Dado que distintas aplicaciones como, por ejemplo, teléfono, correo electrónico y video vigilancia, pueden utilizar la misma red IP, es necesario controlar el uso compartido de los

CAPÍTULO 1. REVISIÓN BIBLIOGRÁFICA

5

recursos de la red para satisfacer los requisitos de cada servicio. Una solución es hacer que los enrutadores y los conmutadores de red funcionen de maneras distintas para cada tipo de servicio (voz, datos y vídeo) del tráfico de la red. Al utilizar la Calidad de servicio (QoS), distintas aplicaciones de red pueden coexistir en la misma red sin consumir cada una el ancho de banda de las otras [2]. 1.2.

Conceptos de QoS

El concepto de calidad de servicio o (QoS) en telecomunicaciones puede tener, al menos, dos interpretaciones habituales. En primer lugar, se refiere a la capacidad de determinadas redes y servicios para admitir que se fije de antemano las condiciones en que se desarrollarán las comunicaciones (dedicación de recursos, capacidades de transmisión, etc.). En segundo lugar, se habla calidad de servicio como una serie de cualidades medibles de las redes y servicios de telecomunicaciones, como el tiempo que se tarda en realizar una llamada telefónica (desde que el usuario marca hasta que suena el teléfono en el otro extremo). También se entiende por calidad de servicio la posibilidad de asegurar una tasa de datos en la red (ancho de banda), un retardo (latencia) y una variación de retardo (jitter), acotados a valores contratados con el cliente. En las redes Frame Relay o ATM la calidad de servicio se garantiza mediante un contrato de CIR (Commitated Information Rate) con el usuario. Para disponer de una calidad de servicio aceptable en redes soportadas en protocolo IP se han diseñado herramientas a medida como son los protocolos de tiempo-real RTP y de reservación RSVP. Por otro lado, un problema evidente es que cuando se soporta un servicio de voz sobre IP (VoIP) por ejemplo, los paquetes son cortos y el encabezado es largo comparativamente. En este caso se requiere un encabezado reducido y un proceso de fragmentación e intercalado LFI. Mediante QoS (Quality os Service) se tiende a preservar los datos con estas características [3]. Los servicios tradicionales de la red Internet (SMTP o FTP) disponen de una calidad denominada "best effort"; es decir que la red ofrece el mejor esfuerzo posible para satisfacer los retardos mínimos; lo cual no es mucho pero es suficiente para servicios que no requieren tiempo-real como el web. Para servicios del tipo "real-time" (voz y vídeo) se requiere una latencia mínima.

CAPÍTULO 1. REVISIÓN BIBLIOGRÁFICA

6

La calidad de Servicio (QoS) es el término usado para definir la habilidad de una red para proveer niveles diferentes de seguridades de servicio para las diversas formas de tráfico. Eso faculta a los administradores de la red a asignar cierta prioridad de tráfico sobre los otros o de los niveles reales de calidad con relación al ancho de banda de la red. La “calidad de servicio” es definida por la Unión Internacional de Telecomunicaciones (UIT) como el efecto global de la calidad de funcionamiento de un servicio que determina el grado de satisfacción de un usuario de dicho servicio. Desde el punto de vista técnico se podría enunciar el concepto de calidad de servicio como la capacidad de la red para reservar algunos de los recursos disponibles para un tráfico concreto, con la intención de proporcionar un determinado servicio. Se debe tener en cuenta que en la red se pueden utilizar diferentes tecnologías de transporte (X.25, Frame Relay, ATM, SDH, MPLS) de manera que la gestión de QoS implica la interacción con estas tecnologías y con los equipos conmutadores y enrutadores. La cantidad en que cada criterio contribuye a la QoS se definirá en valores que son conveníados y especificados con el Cliente. En este sentido, la QoS, posee dos partes o criterios principales: • Criterio operacional • Criterio de comportamiento de los servicios-intrínsecos La figura proporciona una vista conceptual de los principales criterios que contribuyen a la calidad de un servicio ofrecido.

CAPÍTULO 1. REVISIÓN BIBLIOGRÁFICA

7

Figura 1. - Criterios que contribuyen a la Calidad de Servicio 1.3. Tecnologías que se pueden emplear para implementar QoS. El término Calidad de servicio hace referencia a una cantidad de tecnologías, como DSCP (Differentiated Service Codepoint), que pueden identificar el tipo de datos que contiene un paquete y dividir los paquetes en clases de tráfico para priorizar su reenvío. Las ventajas principales de una red sensible a la QoS son la priorización del tráfico, dado por la política a aplicar, para permitir que flujos importantes se gestionen antes que flujos con menor prioridad, y una mayor fiabilidad de la red, ya que se controla la cantidad de ancho de banda que puede utilizar cada aplicación y, por lo tanto, la competencia entre aplicaciones en el uso del ancho de banda. El tráfico de voz y video, que a menudo se considera crítico y requiere una latencia baja, es un caso típico en el que la QoS puede garantizar respuestas rápidas a solicitudes de movimiento. El requisito previo para utilizar QoS en una red de vídeo es que todos los conmutadores, enrutadores y productos de vídeo en red admitan QoS. La red típica puede tener uno o muchos enlaces de datos para el cuál la QoS posibilita las siguientes tecnologías que pueden ser: • Frame Relay • Ethernet • Token Ring • Point-to-Point Protocol (PPP) • HDLC • X.25 • ATM • SONET Cada una de estas tecnologías subyacentes tiene características diferentes que necesitan ser consideradas al implementar la QoS. La cual puede ser implementada para la administración de la congestión o para evitar las situaciones de congestión. La administración de congestión y las técnicas se usan para manejar y dar prioridad al tráfico en una red donde las aplicaciones pueden necesitar más ancho de banda que el disponible en la red. Estableciendo prioridades de ciertas clases de tráfico y las técnicas de la administración de congestión posibilitan la operatividad de negocios críticos o evitan el

CAPÍTULO 1. REVISIÓN BIBLIOGRÁFICA

8

retraso de las aplicaciones sensitivas a manejar en una red con el ambiente de verdad congestionado. Inversamente, las técnicas de evitación de colisión hacen uso de los mecanismos subyacente de las tecnologías para evitar situaciones de congestión. Por otro lado las aplicaciones actuales generan diversos tipos de tráficos a ritmos muy variables que requieren que las redes dispongan de los recursos necesarios para su transporte. Adicionalmente algunas aplicaciones son sensibles a las demoras y los recursos de la redes son finitos, por lo que hay partes de la red que pueden congestionarse y no responder de la manera deseada al cursar del tráfico. 1.4. Parámetros para lograr Calidad de Servicios (QoS) A continuación se resumen algunos de los parámetros a tener en cuenta para lograr QoS en los servicios de red . • Retardo • Jitter • Pérdida de paquetes • Ancho de banda • Disponibilidad El retardo es el tiempo entre el envío de un paquete por parte de un enrutador y la recepción de éste por parte de otro. Abarca los retrasos sufridos durante el propio camino y en los dispositivos de la red. De lo que se puede deducir que es un parámetro vital para muchas aplicaciones interactivas en las que el tiempo de respuesta es primordial. En el retardo influyen varios factores como son: • El retardo de propagación • La velocidad de transmisión • El procesamiento en los equipos. El Jitter es la variabilidad en el retardo de los paquetes (variabilidad del retardo). Es cuando los paquetes no llegan en orden a su destino o en la base de tiempo normada para el buen desempeño de la aplicación que los envía. La pérdida de paquetes indica el número de paquetes perdidos durante una transmisión. Estas pérdidas ocurren principalmente en función de factores tales como: • El descarte intencional de paquetes en los enrutadores y conmutadores de la red en situaciones de congestionamiento, etc.

CAPÍTULO 1. REVISIÓN BIBLIOGRÁFICA

9

• Pérdidas de paquetes debido a errores ocurridos en la capa de enlace Está muy claro que, por mucho ancho de banda que tenga una aplicación, este parámetro puede decidir sobre su calidad ya que hace variar la transferencia efectiva de información que no es más que el trámite de datos realmente útiles para el servicio y no de confirmaciones (ACKs) y retransmisiones de paquetes. El ancho de banda es una medida de la capacidad de transmisión de datos, expresada generalmente en Kbps o Mbps. Indica la capacidad máxima teórica de una conexión, que se puede ver disminuida por diferentes factores como el retardo de la transmisión. La disponibilidad es una medida de la garantía de ejecución de una aplicación a lo largo del tiempo y depende de factores tales como: • La disponibilidad de los elementos de red imbricados desde el cliente hasta el lugar donde radica la aplicación. • La disponibilidad del hardware que soporta el servicio. • El estado de la aplicación en sí. 1.4.1

Modelos establecidos para garantizar QoS

Existen dos estrategias básicas para otorgar QoS en una red: • Reservar capacidad para los usuarios (Entiéndase por usuarios las aplicaciones, las estaciones, etc.) • Otorgar prioridades a los usuarios La primera estrategia brinda una garantía casi total de QoS a costa de derrochar en ocasiones recursos de red (memorias, anchos de banda, etc.) y esto resulta costoso. La segunda se basa en optimizar los recursos existentes ofreciendo distintos niveles de prioridad a los usuarios. Organizaciones internacionales como la Fuerza de Trabajo de Ingeniería de Internet (IETF) se vieron en la necesidad de crear grupos de trabajo para desarrollar modelos basados en estas estrategias. A continuación se listan los modelos más importantes que emergieron de dichos esfuerzos: • Servicios Integrados (IntServ) • Servicios Diferenciados (DiffServ) El primero se basa en la estrategia de reservar y el segundo en la de priorizar. Éstos pueden implantarse de manera independiente o usando una combinación de ellos [9].

CAPÍTULO 1. REVISIÓN BIBLIOGRÁFICA

10

Basados en sus principios básicos para ofrecer QoS se han creado otros como el protocolo de intercambio de etiquetas (MPLS, por sus siglas en inglés) [5] y el IEEE 802.1p [6]. 1.5. Servicios Integrados (IntServ) El modelo IntServ basa su funcionamiento en la reservación de recursos, como anchos de banda y tamaños de buffers, para las aplicaciones que lo soliciten. La reservación se realiza a lo largo de todo el camino de la red, desde el enrutador donde radica la estación que origina la solicitud hasta el enrutador destino. Esto quiere decir que todos los enrutadores de dicho camino deben soportar este tipo de servicios para que se pueda obtener la QoS solicitada. Más adelante se explicará mejor el mecanismo. El modelo IntServ ofrece tres tipos de servicios a las aplicaciones que soliciten sus beneficios [2]: • Servicio garantizado • Servicio de carga controlada • Servicio del mejor esfuerzo El servicio garantizado se supone que lo utilicen aplicaciones con altos requerimientos de tiempo real, cuyos retardos de transmisión sean mínimos y constantes. El servicio de carga controlada ofrece un comportamiento similar al de una red con el protocolo Internet (IP) cuando trabaja con bajos niveles de utilización. Por último, el servicio del mejor esfuerzo no ofrece ningún tipo de garantías de QoS y es el ofrece por defecto la red IP. Antes de proseguir con la explicación del funcionamiento de IntServ es importante definir el concepto de flujo: Un flujo es un tráfico continuo de datagramas relacionados, que se produce como resultado de la acción de una aplicación, y que requiere la misma QoS. Un flujo es unidireccional y se identifica, en el protocolo TCP/IP, por las direcciones de origen y destino, el puerto de origen y destino (del nivel de transporte) y el protocolo de transporte utilizado (TCP o UDP) [7]. A continuación se describirán los componentes que conforman la arquitectura del modelo IntServ.

CAPÍTULO 1. REVISIÓN BIBLIOGRÁFICA

1.5.1

11

Componentes de la arquitectura de Servicios Integrados

La Arquitectura de Servicios Integrados (ISA, por sus siglas en inglés) se conforma de los siguientes componentes [8]. • Clasificador de Paquetes. • Planificador de Paquetes. • Control de Admisión. • Protocolo de Reserva. Clasificador de paquetes Clasifica en distintos tipos de servicios a los datagramas entrantes. La selección se basa en los flujos a los que pertenece cada datagrama. Un tipo de servicio puede corresponder a un conjunto de flujos, o ajustarse a un solo flujo. Planificador de paquetes Dirige el envío de diferentes paquetes utilizando un conjunto de colas de salida. Es el que determina cómo los paquetes se distribuyen por las colas y el orden de transmisión de los mismos. Control de Admisión Implementa el algoritmo de decisión que un enrutador utiliza para determinar si existen suficientes recursos para realizar la QoS solicitada por el flujo. Protocolo de reserva Es un protocolo de señalización que se encarga de establecer, de manera previa al tráfico de los flujos de una aplicación, una conexión entre los enrutadores extremos de la misma, para que gestione la reservación de los recursos necesarios en cada uno de ellos. El protocolo de reserva por excelencia es el Protocolo de Reserva de Recursos (RSVP, por sus siglas en inglés). 1.5.2

Descripción del mecanismo IntServ

El mecanismo que utiliza IntServ para ofrecer QoS es el siguiente: Cuando una aplicación requiere para sus flujos un determinado tipo de servicio, comienza haciendo una solicitud de recursos a través del protocolo RSVP. El protocolo se encarga de consultar en cada enrutador del camino hacia la estación remota, la disponibilidad de recursos para ofrecer el tipo de servicio requerido. Si, y sólo si, existen las capacidades en todos los enrutadores, regresa una señal de confirmación hacia la aplicación para que

CAPÍTULO 1. REVISIÓN BIBLIOGRÁFICA

12

comience a transmitir sus flujos de datos. Cuando en lo adelante arribe un datagrama (o paquete) a cada uno de esos enrutadores, es clasificado en el tipo de servicio adecuado y se ubica en una cola de salida que corresponda con el tipo de servicio al que pertenece, para que el planificador de paquetes le de salida cuando estime oportuno. Una vez concluida la sesión de la aplicación, el protocolo RSVP libera las asignaciones de tipos de servicio hechas a estos flujos para que los recursos queden a disposición de otros flujos. Por la forma en que está concebido el mecanismo, cada enrutador ha de mantener el detalle de todas las conexiones activas que pasan por él, y los recursos que cada una ha reservado. También ha de poseer reservas de los recursos mencionados para poder brindar QoS en su momento. 1.6. Servicios Diferenciados (DiffServ) Los Servicios Diferenciados permiten hacer una clasificación y tratamiento diferenciado al tráfico de la red mediante el marcado con etiquetas en las cabeceras de los paquetes IP, específicamente en el campo Tipo de Servicio (TOS) ahora renombrado como “Servicios Diferenciados” (DS), que luego interpretan y manipulan convenientemente los distintos enrutadores en el recorrido de los paquetes dentro de un mismo ámbito administrativo denominado “Dominio de Servicios Diferenciados” o Dominio DS, donde se rigen iguales políticas en el reenvío de los paquetes [4]. También varios Dominios que comparten una misma política de QoS conforman lo que se denomina una “Región” El campo DS o DSCP en este caso, consiste en los seis bits más significativos de los ocho del antiguo campo TOS como se muestra en la figura 1.2.

Fig. 1.2 Campo DS en IPv4. Para la arquitectura de DiffServ existen dos tipos de enrutadores en la red: • Enrutadores exteriores • Enrutadores interiores

CAPÍTULO 1. REVISIÓN BIBLIOGRÁFICA

13

Los primeros pueden ser, por ejemplo, los enrutadores de salida de una red local hacia una red de mayor alcance o la estación extremo de una aplicación. Los segundos pueden ser los enrutadores intermedios de la red de mayor alcance. Cuando llega un paquete a un enrutador exterior, entrando a un Dominio DS, el enrutador controla, ajusta o marca estos paquetes (el marcado se refiere a asignar un valor al campo DS) Ésta será la marca que usarán para ejercer la clasificación los enrutadores internos del Dominio, para determinar qué comportamiento o nivel de QoS aplicar. El marcado en el enrutador exterior se puede realizar usando diferentes criterios: • Dirección IP fuente del paquete • Dirección IP destino del paquete • Número de puerto fuente (del nivel de transporte) • Número de puerto destino • Protocolo del nivel de transporte • Otros campos del datagrama Por ejemplo, al flujo que tiene como dirección IP fuente 172.16.14.25, y como dirección IP destino 127.30.2.5, se le marca con el DSCP 8. Luego, en el interior del dominio, el tratamiento del tráfico no se realiza sobre paquetes que forman flujos individuales, como lo hace IntServ, sino sobre agrupaciones de ellos denominadas “Agregados de Comportamiento” o simplemente “Agregados”. A los enrutadores se les configura una tabla que relaciona uno o varios valores de DSCP con un Agregado. Existe un conjunto predefinido por la IETF de Agregados menor al número de valores de DSCP posibles, y por ello es que pueden hacerse asociaciones varios a uno en estas tablas. Por tanto, los enrutadores darán un determinado tratamiento al tráfico en dependencia del Agregado en el que se clasifique. Es importante señalar que para lograr QoS con DiffServ, es preciso que los paquetes siempre atraviesen redes y enrutadores que practiquen una misma política de servicios (que estén en un mismo Dominio o Región). De lo contrario los paquetes que pasen por al menos un enrutador de política ajena, pudieran ser retardados, otros priorizados y otros hasta descartados y los servicios no estarán entonces a tono con la política deseada.

CAPÍTULO 1. REVISIÓN BIBLIOGRÁFICA

14

1.7. Comparación entre los estándares La arquitectura de servicios integrados tiene la virtud de poder ofrecer garantías casi totales de QoS, pero bajo una infraestructura con recursos suficientes de red, en la que se puedan hacer reservaciones de éstos. Por otra parte, IntServ hace estas reservaciones por flujo de datos, y por consiguiente, cada enrutador debe mantener el estatus de cada flujo clasificado como información vital para el proceso de reservación. Esto hace que el modelo sea poco escalable a nivel global, porque dicha información crece en demasía a medida que se acercan los enrutadores del núcleo de Internet, y sería muy costoso mantenerla. El modelo IntServ es también algo complejo por el hecho de utilizar todo un protocolo de señalización como preámbulo al servicio. A partir de las limitaciones de IntServ es que surge diffServ. Primeramente, el principio de priorizar se ajusta más a las infraestructuras existentes optimizando su utilización. Aunque, como consecuencia, las garantías de QoS son más estadísticas que determinísticas (como ocurre con IntServ). Por ejemplo, si en el mismo intervalo de tiempo, y por una misma interfaz de un enrutador, tratan de encaminarse muchos flujos que pertenecen a un mismo agregado de alta prioridad, difícilmente cuenten todos con una apropiada QoS. También se debe concebir el servicio para que este caso sea poco probable. Por otra parte, DiffServ resuelve los problemas de escalabilidad de IntServ, porque la clasificación no se basa más (al menos en el interior del dominio DS) en los flujos de datos, sino en agregaciones de flujos (que tengan uno o varios DSCP en común) y esto reduce drásticamente la cantidad de datos en memoria que tenían que almacenar y mantener los enrutadores de IntServ. Otra ventaja de DiffServ radica en que es un modelo más simple, ya que se abstiene de incluir un protocolo de señalización para hacer reservas de recursos en cada enrutador. Ahora cada enrutador sabrá qué tratamiento ofrecerle a cada paquete entrante en dependencia del Agregado de comportamiento al que pertenezca. Ambos modelos se concibieron para que fueran estándares que proporcionaran QoS en grandes redes IP, como Internet, con la premisa de que todos y cada uno de los enrutadores involucrados en dichas redes los implementaran. De manera un usuario disfrutaría de QoS siempre que sus tráficos se destinen al entorno de redes que implementan el mismo estándar, y dentro de éste, las mismas políticas.

CAPÍTULO 1. REVISIÓN BIBLIOGRÁFICA

15

Existen diferentes motivos por los cuales no se ha generalizado y organizado el uso de estos estándares, algunos de los cuales se listan a continuación: • Los Proveedores de Servicios de Internet (ISP, por sus siglas en inglés), por lo general, se mantienen ocupados incrementando sus ventas de acceso a Internet y no les interesa crear estos servicios. • Existen diferentes ISP en el mundo de Internet, y éstos no se ponen de acuerdo ni en los estándares, ni en las políticas a aplicar. • Las tarifas constituyen otro problema, ya que por los mecanismos que emplean estos modelos, alcanzar los destinos más lejanos implica incurrir en un mayor costo (pago a distintos ISPs, etc.) 1.8. Implementación de QoS: Las formas de implementación de la QoS se clasifican en dependencia del tipo de tráfico, lugar de aplicación, reserva de recursos de la red, así como otros parámetros los cuales serán descritos a continuación. 1.8.1

Según la sensibilidad del tráfico de QoS: • QoS muy sensible al retardo: Ejemplo de este tipo es el tráfico de video comprimido. Se necesita garantizar disponibilidad de una gran cantidad de ancho de banda reservado para este tipo de tráfico y un valor de retardo mínimo que asegure la correcta transmisión del mismo. Para conseguirlo será necesario utilizar mecanismos de priorización, así como organizar en colas adecuadamente los flujos de datos. • QoS algo sensible al retardo: Al igual que en el caso anterior se garantiza hasta un cierto nivel de ancho de banda, aunque en menor valor y de la misma manera, será necesario asignar prioridades para la transmisión de los datos. • QoS muy sensible a pérdidas: Como sucede con el tráfico tradicional. Si se garantiza un nivel de pérdidas de valor cero entonces nunca se descartarán paquetes ni se desbordarán los buffers de almacenamiento, lo que facilitará el control de la transmisión, por otra parte, esta garantía se hace a nivel de acceso al medio o en capas superiores, pero nunca a nivel físico. • QoS nada sensible: La filosofía de este tipo de QoS es usar cualquier oportunidad de transmisión restante y asumir que la capacidad de los buffer posteriores es

CAPÍTULO 1. REVISIÓN BIBLIOGRÁFICA

16

suficiente para llevarla a cabo, asignándole a este tipo de tráfico la prioridad más baja. A este tipo de tráfico responden los algoritmos conocidos como del mejor esfuerzo (Best Effort), utilizado en Internet. 1.8.2

Según quién solicite la QoS:

Teniendo en cuenta que la petición de QoS puede ser realizada por el usuario final o por los conmutadores de la red, nos encontramos con estas dos variantes: • QoS implícita: En este tipo de metodología, el enrutador o conmutador asigna automáticamente los niveles de QoS en función del criterio especificado por el administrador, como por ejemplo, el tipo de aplicación, protocolo o dirección de origen. Se realiza de la siguiente forma, las estaciones finales transmiten los paquetes y el conmutador o enrutador los recibe, analiza los datos entrantes y los prioriza, organizándolos en diferentes colas según la prioridad asignada. Estos datos vuelven a ser transmitidos hacia el siguiente conmutador o enrutador, donde se repite el proceso. • QoS explícita: Este tipo de metodología permite al usuario o aplicación solicitar directamente un determinado nivel de servicio que han de respetar los conmutadores y enrutadores. Se realiza de la siguiente manera, las estaciones finales transmiten una petición, si ésta es aceptada, los paquetes son transmitidos. Luego en el conmutador o enrutador los datos entrantes son priorizados de acuerdo a las instrucciones del nodo destino. 1.8.3

Según las garantías de QoS

Tiene en cuenta la reserva de recursos en la red para proporcionar los servicios. • QoS garantizada (Hard QoS): Es aquella en la que se hace una reserva absoluta de los recursos en la red para un tráfico determinado, asegurándose así unos niveles máximos de garantías para este tráfico. • QoS no garantizada (Lack of QoS): En una QoS sin garantías, el tráfico es transmitido por la red a expensas de lo que en ella pueda sucederle. • QoS servicios diferenciados (Soft QoS): Es el punto medio entre los dos tipos anteriores y se realiza una diferenciación de tráfico, siendo tratados algunos mejor

CAPÍTULO 1. REVISIÓN BIBLIOGRÁFICA

17

que el resto de diferentes formas, tales como expedición más rápida, más ancho de banda promedio, menos tasa de error promedio. 1.8.4

Según el lugar de aplicación de QoS

Puede aplicarse QoS en los extremos y/o en los bordes de la red, de esta forma puede clasificarse como: • QoS extremo a extremo (end-to-end): Es la aplicación de las políticas de QoS entre los extremos de la red, también se conoce comúnmente como QoS absoluta. Una ventaja es que las aplicaciones podrían seleccionar dinámicamente el nivel de QoS requerido o demandado. • QoS borde a borde (edge-to-edge): Es la aplicación de las políticas de QoS entre dos puntos cualesquiera de la red. Tiene como ventaja que son menos los dispositivos que tienen que ser manejados para la obtención de QoS, también conocida como QoS relativa. En la tabla siguiente se muestran los parámetros de calidad necesitados por diferentes aplicaciones y metodología que se manejan en Internet. REQUERIMIENTOS TIPO DE TRAFICO

Ancho de banda

Voz

Muy bajo

Pérdida

Demora

Jitter

Medio

Alto

Alto

Comercio Electrónico

Bajo

Alto

Alto

Bajo

Transacciones

Bajo

Alto

Alto

Bajo

Correo electrónico

Bajo

Alto

Bajo

Bajo

Telnet

Bajo

Alto

Bajo

Bajo

Transferencia de Ficheros

Bajo

Alto

Medio

Bajo

Videoconferencias

Alto

Medio

Bajo

Bajo

Multicasting

Alto

Medio

Alto

Alto

Tabla 1.1 - Aplicaciones y requerimientos de QoS.

1.9. Clasificación de información para aplicar QoS QoS es un requerimiento en las redes multiservicio de hoy en día. QoS puede ser visto como un enforced set de potencialidad que permite diferenciar los tipos de tráfico en una red y asignar prioridad a los servicios según lo requiera la alta demanda y aplicaciones de altos valores o flujo de datos. Con la integración de hoy en día de la Voz y el Video, junto

CAPÍTULO 1. REVISIÓN BIBLIOGRÁFICA

18

con el resurgimiento de las aplicaciones Cliente / Servidor el ancho de banda se restringe y llega a tornarse critico. Es de gran importancia que las empresas permitan tráfico que requiera prioridad de servicio de ancho de banda dedicado y son necesarias características de un bajo retardo. El estándar de entrega por mejor-esfuerzo de las redes IP no es capaz de mantenerse con estos requerimientos. Para encontrar estos requerimientos varios niveles de arquitectura de servicio han sido creados que permiten la creación de clase de servicio en las redes IP sin conexión. Los servicios integrados representan el más alto nivel de QoS dedicado. Por el uso de RSVP este nivel de servicio emula con la conexión orientada a los circuitos end-to-end basados en la calidad de las líneas privadas dedicadas para cada flujo de datos. Entre tanto esto puede proveer el nivel más alto de servicio, no tiene un peso significativo y no es recomendado para velocidades de enlace menores de T1 o E1. Fíjese que RSVP, que es originalmente diseñado para los servicios integrados, es el único protocolo disponible en esta oportunidad que es capaz de reservar

a través de la red IP.

Para aplicaciones

especificas tales como tráfico de Voz, Intserv (servicios integrados) con RSVP puede ser una arquitectura de elección. En contraste y como una respuesta a las limitadas capacidades de ancho de banda de los servicios integrados, fueron creados los modelos de servicios diferenciados. Estos modelos no tratan de proveer la misma dedicación de recursos por flujo de datos como se ve en el modelo Intserv. Como en el modelo integrado. Más bien, Diffserv primeramente actúa como un tosco esquema de clasificación. El tráfico es agregado hacia el interior de uno de los “flujos toscos” y entonces cada flujo recibe un comportamiento por salto. Definiciones exactas de “cola”, caída de funcionamiento, y comportamiento por punto de conexión no están definidas por la arquitectura Diffserv y están pendientes a los proveedores de servicio individual para definir basado en los acuerdos de servicio negociados con el cliente. Clasificando y agregando flujos de datos en el borde de la red, Diffserv da resultado en redes que pueden escalar a un tamaño considerablemente grande que el flujo de datos fijos de las redes de Intserv. Como no es requerida una clasificación para ser ejecutada en los paquetes por la intervención de los routers, los requerimientos del hardware son significativamente reducidos y por latencia de salto puede ser significativamente inferior.

CAPÍTULO 1. REVISIÓN BIBLIOGRÁFICA

19

Diffserv no provee el mismo nivel de servicio dedicado que está disponible con Intserv y, como tal, puede sufrir si un significativo tráfico de voz u otro tipo de tráfico de baja latencia es enviado a través de una red Diffserv. Además, como el comportamiento por salto y la clasificación son definidos por cada proveedor de servicio, no hay forma para garantizar el servicio a través proveedores de servicio de redes discrepantes 1.9.1

Clasificación de la información con Cisco NBAR

Con el crecimiento actual de proveedores de servicio de aplicaciones y la propagación de las aplicaciones de “paga según su uso” las corporaciones están buscando una forma de clasificar y priorizar el trafico en la red basado en la información de la capa 4 a la 7. Los sistemas de redes facilitan esto mirando dentro de un paquete y extrayendo la información de la aplicación. En el 2000 Cisco anunció Network Based Application Recognition (NBAR), para detectar aplicaciones que necesitaban ser clasificadas para que las herramientas de calidad de servicio pudiesen hacer su trabajo. NBAR se implementa en cualquier router Cisco (y algunos de sus switches de alto rendimiento), y en algunos casos, se puede distribuir o paralelizar su trabajo si el router cuenta con capacidad distribuida. Cuáles son los usos de NBAR?, Ejemplos: 1. Un administrador desea detectar FTP, y limitar la transferencia de archivos a 5 Mbps.

Puede pedirle a NBAR que clasifique la ocurrencia de FTP, y que ésta información sea cedida a una rutina del router que limita el ancho de banda de FTP al valor mencionado. 2. Un administrador desea poner un límite a la navegación Web en horarios

comerciales, pero si un empleado se queda fuera de horario comercial, tiene derecho a navegar en forma ilimitada. Entonces le pide a NBAR que detecte el protocolo HTTP, y luego combina una política de calidad de servicio que limita el uso HTTP al umbral deseado, en conjunto con una lista de acceso temporal, que hace efecto en los horarios de días hábiles entre las 9AM y las 5PM. 3. Un administrador desea detectar al virus CodeRed, y eliminarlo cuando ingresa a la

red. CodeRed tiene particularidades: viaja en el protocolo HTTP, dentro del campo URL, y tiene un fingerprint constante. Entonces es posible pedirle ésta combinación a NBAR: que esté atento al protocolo HTTP, que mire solamente el campo URL de

CAPÍTULO 1. REVISIÓN BIBLIOGRÁFICA

20

un pedido HTTP, y que vea si dentro de éste campo aparece un patrón regular que lo identifique. Hecho esto, le entrega ésta información a una rutina de filtrado de paquetes, que descartará todo flujo donde se haya detectado ésta ocurrencia. 4. Una universidad no quiere o no puede prohibir a los estudiantes a usar KaZaA para

bajar contenidos de Internet, pero quiere que no agoten el canal cuando usan KaZaA. El administrador puede entonces solicitarle al router de salida Internet que controle la ocurrencia de las diferentes formas del KaZaA, y que en presencia de detección, limite la velocidad de transferencia a 1 kbps. El estudiante no tiene prohibido el uso, pero el administrador desalienta a los usuarios de KaZaA a través de un mal desempeño de acceso. 5. Un administrador desea regular el uso de video sobre IP. Permite el uso de MPEG4,

que en general es económico, pero prohíbe el uso de MPEG1 o MPEG2, que consumen demasiado ancho de banda. Entonces ordena a NBAR que lea la señalización de aplicaciones H.323, o muchas otras, y detecte la intención de usar uno u otro estándar de compresión de video, y hacer lo que corresponda en base a la política deseada. Existen otros fabricantes enfocados en vender equipos dedicados que hacen tecnología del estilo NBAR. En algunos casos, ésta tecnología es más sofisticada, pero NBAR tiene una ventaja objetiva para usuarios Cisco: está ahí, al alcance de la mano, en el software IOS del router. No hay que pagar por separado, y soluciona el típico 80/20 de la ecuación de calidad de servicio. 1.10. Conclusiones Con el uso de herramientas de clasificación inteligente como Cisco NBAR, los administradores de red pueden precisamente controlar cuales aplicaciones obtienen el servicio requerido. Sin embargo, este grado de control tiene un costo. Significativos recursos son usados en routers de clasificación de fronteras para asumir esta tarea y el análisis de la red debe ser ejecutado para garantizar que la respuesta de la red no esté comprometida. Se han presentado distintos tipos de arquitecturas en una visión general. QoS no es un requerimiento uniforme en cada red.

CAPÍTULO 1. REVISIÓN BIBLIOGRÁFICA

21

Por otro lado existe una fuerza muy grande en el argumento que plantea que si las redes fueran construidas con suficiente capacidad de transferencia de paquetes no sería necesario implementar ningún mecanismo de QoS, asumiendo que QoS nunca reemplazará un apropiado y meticuloso diseño de red. Hasta que el uso de la fibra óptica con su extraordinario ancho de banda no se vuelva económico y se encuentre disponible con facilidad para cada sitio en los sistemas de redes del mundo, los ingenieros de redes y administradores continuaran luchando por proveer un servicio de calidad a un número limitado de aplicaciones y servicios. Muchas arquitecturas diferentes pueden existir para satisfacer las necesidades de calidad de servicio. Ningún tipo de arquitectura puede proveer el mecanismo ideal para cada necesidad. Solamente después de una cuidadosa y completa evaluación de las necesidades de QoS de la red y de los recursos existentes, se toma una decisión sobre cual arquitectura o combinación de arquitecturas pueda satisfacer las necesidades individuales de desempeño.

Capitulo 2: Descripción de las metodologías de QoS seleccionadas.

22

Capitulo 2: Descripción de las metodologías de QoS seleccionadas. A partir de lo analizado en el Capítulo 1, se describen los elementos de la red UCf, que de una forma u otra se relacionan con el uso de QoS y se exponen los aspectos teóricos y conceptos asociados con la metodología a utilizar.

2.1 Características de la Red UCf. La red de la Universidad de Cienfuegos abarca la totalidad de los edificios que componen el campus universitario, además de los enlaces dedicados (vía Frame Relay) con las Sedes Universitarias Municipales (SUM), para ello existe una estructura de backbone concentrado (internamente), empleando un Switch Cisco Catalyst 3550 y una distribución basada en VLANs, los enlaces internos son sobre la base de fibra óptica a 100 Mbps. Así mismo los enlaces externos se basan en el uso del protocolo Frame Relay y para ello se emplean enrutadores Cisco, ver anexo 1. Existen los siguientes enlaces externos. Enlace al ISP ENET: 512 Kbps Enlace a REDUNIV (MES): 1,5 Mbps Enlace con las SUM: 256 Kbps (32 Kbps * 8 SUMs) Enlace para la PAP: 1 Mbps (16 abonados) Los enrutadores empleados son en su totalidad tecnología Cisco. Empleándose un Router Cisco 2811 para la conexión a ENET y REDUNIV, un Router Cisco 2611 para la conexión con las SUMs y un Router Cisco 2509 para la conexión a la PAP. 2.1.1 Principales servicios empleados en la Red UCf. Los principales servicios telemáticos empleados en la red UCf para la conexión con redes externas (incluidas las SUMs) se basan en el empleo de los siguientes protocolos de nivel de aplicación: DNS, HTTP, HTTPS y SMTP, que corresponden a la navegación web y el servicio de correo electrónico respectivamente. No obstante existen otros servicios necesarios que son empleados en menor medida, ejemplo: JABBER, FTP, NTP, POP3S, IMAPS, etc.

Capitulo 2: Descripción de las metodologías de QoS seleccionadas.

23

2.2 Clasificación de información con Cisco NBAR Como se menciono en el capitulo 1, una forma de controlar el uso de los canales en las redes, es la habilidad de clasificar el tráfico basado en una información más detallada que números de puertos estáticos o direcciones. Así mismo se planteó que Cisco aborda este requisito a través de un mecanismo de clasificación llamado: Network Based Application Recognition (NBAR) o Reconocimiento de Aplicaciones Basado en la Red. NBAR es un mecanismo de clasificación que mira dentro de un paquete y desarrolla un análisis de la información contenida dentro del paquete. Mientras que NBAR puede clasificar los protocolos de puertos estáticos, su utilidad es mucho mayor al reconocer las aplicaciones que usan números de puertos asignados dinámicamente, realizar una detallada clasificación del trafico http, y una clasificación del trafico CITRIX ICA por aplicaciones publicadas. Debe resaltarse que hay 2 asuntos significativos con la clasificación del NBAR. Primero, el NBAR solo funciona con trafico IP por lo tanto si se tiene cualquier SNA o tráfico heredado, otras clasificaciones y esquemas de cola deben ser usados. El segundo tema es que el NBAR solamente funcionará con tráfico que pueda ser conmutado mediante Cisco Express Forwarding (CEF). 2.2.1 Clasificación http NBAR puede clasificar tráfico no solo por direcciones o números de puertos sino que puede clasificar cualquier información detallada dentro del URL arriba y a una profundidad de 400 bytes. El código está actualmente escrito de tal forma que NBAR mirará un total de 512 bytes. La clasificación de subpuerto http es realmente el único mecanismo de clasificación de subpuerto en estos momentos con NBAR que es empleado para penetrar en la profundidad del paquete. NBAR puede clasificar todo el tráfico http por tipo de MIME, o obteniendo los paquetes de solicitud de destino. NBAR presenta limitaciones en relación al tráfico de la Web, estas son: • No puede haber más de 24 coincidencias de clasificaciones de URL simultáneos o tipo MIME. • Un enlace http persistente no puede ser clasificado si el tráfico está protegido por el usos de HTTP seguro (HTTPS).

Capitulo 2: Descripción de las metodologías de QoS seleccionadas.

24

2.3 Usando NBAR y Clasificaciones para Proteger el Ancho de Banda. Normalmente no pensaríamos de una herramienta de clasificación como una forma de seguridad. De hecho, seguridad es un mal término, el abuso de ancho de banda podría ser un mejor término. La habilidad de NBAR de mirar 400 bytes dentro de una cabecera URL y la habilidad para clasificar tipos de MIME puede hacer de NBAR una herramienta poderosa para prevenir el abuso de la red. Una alta utilización de la capacidad de la red puede ocurrir en un número de casos, debido a la transferencia de grandes archivos .mp3 o .mov y .mpeg entre los usuarios. Para enfrentar esta situación podríamos filtrar los protocolos P2P (por ejemplo), pero eso no prevendría a los usuarios de intercambiar simplemente estos archivos en sus locales privados LAN o directamente en circuitos privados WAN. No es usual tener cortafuegos en circuitos privados WAN para actuar en el control de algunos tráficos. Es exactamente aquí, donde la aplicación de clasificación de NBAR se vuelve útil, permitiendo filtrar para clasificar cualquier trafico que pueda involucrar a los archivos no autorizados de multimedia tales como mp3 u otras. Una vez que estos paquetes son clasificados ellos pueden ser asignados a una prioridad muy baja de “cola” o eliminados. De esta manera, prevenimos estos usos recreacionales de nuestra red o minimizamos su empleo. 2.4 Protocolos soportados por NBAR NBAR es capaz de clasificar los protocolos TCP y UDP que usan números de puertos bien conocidos, así como protocolos que no sean UDP y TCP. Las tablas 2.1, 2.2 y 2.3 enumeran algunos de los protocolos soportados, así como números de puertos asociados, que pueden ser clasificados por NBAR.

Capitulo 2: Descripción de las metodologías de QoS seleccionadas.

Tabla 2.1 Protocolos soportados no TCP y no UDP.

25

Capitulo 2: Descripción de las metodologías de QoS seleccionadas.

26

Capitulo 2: Descripción de las metodologías de QoS seleccionadas.

27

2.2 Protocolos estáticos TCP y UDP soportados.

2.3 Protocolos dinámicos TCP y UDP soportados.

2.4.1 Clasificaciones propias También es posible crear clasificaciones propias para puertos que no estén soportados (no estén en las tablas), ejemplo puertos que no estén clasificados por la IANA como “bien conocidos”. En este caso NBAR permite la creación de hasta 16 nuevas clasificaciones, permitiendo la asignación de números de puertos entre 0 y 65535.

Capitulo 2: Descripción de las metodologías de QoS seleccionadas.

28

2.5 PDLM Uno de los aspectos principales de NBAR es que la plantilla de clasificación puede ser cargada en cualquier momento sin interferir en la operación del router. Esto es logrado con el uso de un Modulo de Lenguaje de Descripción de Paquete (PDLM). El PDLM es copiado hacia una memoria flash y cargado desde la consola del router o una configuración existente hacia un protocolo adicional soportado por NBAR. No es necesario apagar o reiniciar el router para actualizar la lista de clasificaciones. Actualmente PDLMs están disponibles para clasificar varios protocolos, esta lista es actualizada frecuentemente y debe ser chequeada regularmente. 2.6 Servicios de QoS apoyados por NBAR Un concepto clave a tener en cuenta es que NBAR es solamente para clasificación. NBAR no aplica QoS sino que provee un medio para definir las clases para la aplicación de QoS basadas en la aplicación de la información y no solamente en el puerto fijo normal o la información de la red. Una vez que el tráfico ha sido clasificado por NBAR existen varios mecanismos de QoS que pueden utilizarse para hacer cumplir los niveles de servicios requeridos, estos servicios disponibles pueden incluir: •

Ancho de Banda mínimo garantizado usando Class based Weighted Farir Queuing (CBWFQ)

•

Baja Latencia de cola (LLQ)

•

Política de tráfico para limitar rates

•

Modelación del tráfico para evitar la congestión

•

Evitar la congestion usando Weighted Random Early Detection (WRED)

•

Marcado de paquetes para el uso en las arquitecturas DiffServ o IntServ.

•

Flow-Based Weighted Fair Queuing (tradicionalmente conocido como WFQ)

Para una mayor profundización en estos servicios se pueden ver los materiales proporcionados por Cisco en su sitio de Internet [http://www.cisco.com].

Capitulo 2: Descripción de las metodologías de QoS seleccionadas.

29

2.7 Configuración Básica de NBAR Se analizará la configuración de NBAR, y su interacción con el Ramdom Early Detection (RED) y Class-based Weighted Fair Queuing (CBWFQ) para proveer QoS dentro de la red. Se debe recordar que NBAR es solamente una herramienta de identificación y clasificación de protocolo. Mientras pueda proporcionar la inteligencia de mirar dentro de la red para discernir que es lo que está ocurriendo en el contenido del paquete, requiere de otras herramientas para crear e imponer una política de QoS. El 1er paso en la configuración de NBAR es habilitar el protocolo de descubrimiento NBAR en una o varias de las interfaces que serán usadas para monitorear el tráfico. Lo cierto es que el uso del NBAR incrementará el uso del CPU en un 15%, por lo que no deberá ser usado en enrutadores muy cargados. Es necesario asegurarse de chequear La utilización del CPU usando el comando show proc antes de implementar NBAR y la características de descubrimiento de protocolos para ver los protocolos soportados. Para habilitar NBAR en un puerto: router(config)#int faste0/0 router(config-if)#ip nbar protocol-discovery Para ver los resultados de NBAR discovery en una interfase especifica: router# show ip nbar protocol-discovery int Fast0/0. A continuación se muestra la salida parcial de este comando por la interface: router#show ip nbar protocol-discovery int Fast0/0 ! FastEthernet0/0 Input Output Protocol Packet Count Packet Count Byte Count Byte Count 5 minute bit rate (bps) 5 minute bit rate (bps) ------------------------ -------------------------- -------------http 1765473 0 18739887 0 9832477 0 .

Capitulo 2: Descripción de las metodologías de QoS seleccionadas.

30

. . Total 9875462282 989836234 7465873457 768236287 6726362252 8876545

Tres tareas básicas deben ser secuencialmente diseñadas para aplicar NBAR a una interface. Primero, un mapa de clase de comando debe ser usado para definir una o más clases de tráfico mediante la especificación del criterio de en cual interface será aplicada. El segundo paso es crear una política (policy map) para definir la aplicación de QoS a la clase de tráfico. El paso final es usar un comando de servicio para asignar la política a una interface específica en el enrutador. Cada uno de estos pasos es requerido para el funcionamiento básico de NBAR.

2.7.1 Creando un mapa de clase NBAR El comando class-map es usado para definir una clase del tráfico a chequear y define todos los identificadores que serán usados para clasificar el tráfico perteneciente a la clase. Para la clasificación de NBAR, el parámetro de coincidencia debe ser un protocolo soportado por NBAR. A continuación se ilustra la estructura de este comando aplicado a un router para la coincidencia en el trafico PcAnywhere.

router(config)#class-map PCanywhere router(config-cmap)#match protocol pcanywhere

2.7.2 Creando una política (policy map) El comando de configuración policy-map es usado para definir que QoS será aplicado a la clase de tráfico que fue definido por el parámetro class-map. Para llevar a cabo esto, primero se le crea un nombre de política, entonces se define la clase para la cual esta política es aplicada, y finalmente, se definen las características de QoS que serán usadas.

Capitulo 2: Descripción de las metodologías de QoS seleccionadas.

31

Los comandos exactos son mostrados posteriormente. En este comando, se define nuestra política para permitir al tráfico PCAnywhere el 50 % del ancho de banda disponible.

router(config)#policy-map traffic router(config-pmap)#class PCanywhere router(config-pmap-c)#bandwidth percent 50 2.7.3 Aplicando la política de mapeo a una interface El paso final es aplicar la política de mapeo definida a una interface específica para que se pueda controlar el tráfico marcado. Esto puede realizarse usando el comando service-policy para aplicar una política a una interface especifica y especificar la dirección del control del tráfico. A continuación se muestra la política de servicio aplicada en la dirección de entrada de datos. router(config)#int faste0/0 router(config-if)#service-policy input PCAnywhere router(config-if)#exit

NBAR permite al administrador de la red detectar y configurar en un amplio rango de protocolos definidos basados y no basados en IP con el uso de una simple definición de trabajo. Esta característica alivia la necesidad de caras y complejas pruebas, y permite flexibilidad e inteligencia para ser desarrollado dentro de cada dispositivo de ruteo de red.

2.8 Integrando NBAR con CBWFQ Class-based Weighted Fair Queuing (CBWFQ) es una extensión del Weighted Fair Queuing para permitir definir clases de protocolos. En esta funcionalidad, la integración de NBAR, lo cual es un mecanismo de clasificación, con CBWFQ proporciona un extremadamente flexible y configurable mecanismo de QoS. NBAR proporciona los pasos de clasificación que normalmente usarían ACLs, puertos o direcciones IP. Sin embargo, estos procedimientos de clasificación no son exclusivos. Se puede aún usar NBAR con ACLs o interfaces de clasificación si lo necesita. Mediante el

Capitulo 2: Descripción de las metodologías de QoS seleccionadas.

32

uso de los mecanismos de Weighted Fair Queuing, es posible acomodar la razón de transferencia o el tráfico de red, mientras todavía provee de recursos adecuados de red y respuesta para los servicios requeridos. La configuración de CBWFQ con NBAR es muy similar a la configuración normal de cola, con la diferencia de que NBAR está realizando la clasificación en vez de la entrada manual de las clasificaciones requeridas. 2.8.1 Creando un Class map para identificar NBAR Se muestra un ejemplo de la configuración para definir un class map que identificará el protocolo específico de NBAR o los protocolos que controlarán a CBWFQ. Esto se hace con el comando class-map. En un CBWFQ normal, se usarían las interfaces ACL o los puertos de protocolos para realizar el reconocimiento. Con NBAR, se usa las configuraciones de protocolos definidas para establecer el criterio de coincidencia

router(config)#class-map match-any Priority router (config-cmap)#match protocol FTP router (config-cmap)#match protocol Telnet router (config)#class-map match-all Citrix router (config-cmap)#match protocol Citrix

2.8.2 Configurando la política de clase en el mapa de política Este paso de configuración define la política de servicio que será usada para servir a las clases que fueron definidas en el primer paso. Una combinación de cola y limitación de ancho de banda puede ser usada aquí para definir niveles de servicios esperados. El número máximo de políticas que pueden ser configuradas en un router es equivalente al número de mapas de clase que fueron definidos, hasta un máximo nivel de 64. En la siguiente configuración de un mapa de política, el mapa de política ha sido nombrado “Calidad” La clase Citrix es asignada a un ancho de banda de 6000 Kbps (6Mbps) con una profundidad de cola de 100 paquetes. La clase de prioridad tiene asignado un ancho de banda de 3000Kbps (3Mbps). Hay que aclarar que CBFWQ tiene una funcionabilidad de que cualquier tráfico que no machee un mapa de clase y una correspondiente política es

Capitulo 2: Descripción de las metodologías de QoS seleccionadas.

33

tratado como una entrega de “mejor esfuerzo” por el router y es requerido para usar solamente el ancho de banda disponible no controlado.

router (config)#policy-map Calidad router (config-pmap)#class Citrix router (config-pmap-c)#bandwidth 6000 router (config-pmap-c)#queue-limit 100 router (config-pmap)#exit router (config-pmap)#class priority router (config-pmap-c)#bandwidth 3000 router (config-pmap)#exit

2.8.3 Aplicando la política a la interface El paso final involucra aplicar la política a la interface. Este proceso activa CBWFQ para el tráfico entrante o saliente, según como se defina para esa interface. Mientras que se puede asignar la misma política a múltiples interfaces, cada interface puede tener solamente una política asignada a las direcciones entrantes y salientes.

router (config)#interface s0/1 router (config-if)#service input Calidad router (config-if)#exit router (config)#interface s0/2 router (config-if)#service output Calidad router (config-if)#exit

Capitulo 3: Implementación de QoS en la red telemática de la Universidad 34 de Cienfuegos. Capitulo 3: Implementación de QoS en la red telemática de la Universidad de Cienfuegos. Se realiza la descripción de la implementación propuesta, empleando para ello el diagrama topológico de la red, las políticas establecidas en la universidad, los ejemplos de configuración de los equipos de red y las implementaciones de control y monitoreo asociadas. También, se describen las comprobaciones desarrolladas en escenarios de pruebas.

Una vez analizadas en el capitulo anterior las características de la Red UCf, se hace necesario determinar la forma en que se implementará las funciones de QoS y en que puntos de la red se configuraran. Atendiendo al diagrama topológico de la red que se muestra en el anexo 1 y al equipamiento de red existente se considera comenzar con las implementaciones en el enrutador Cisco 2821 que conecta a la red UCf con el ISP ENET para el acceso a Internet y con REDUNIV para la conexión con los CES. Igualmente se propone actualizar el IOS del enrutador Cisco 2611 a la versión XXX para un mejor aprovechamiento de las posibilidades que brinda el sistema operativo en la implementación de QoS. 3.1 Análisis realizados Primeramente se realiza el análisis de los tipos de tráficos existentes y las regulaciones propias de la Red UCf para determinar los criterios de configuración requeridos para la implementación. Para ello se realizan las siguientes acciones:

1. Se habilita la función NBAR en las interfaces del enrutador Cisco 2811.

Router(config)#interface serial 0/0/0 Router(config-if)#ip nbar protocol-discovery 2. Se chequea con la función NBAR en las interfaces del enrutador Cisco 2811 para

ver el uso del canal por cada protocolo. Router#show ip nbar protocol-discovery stats bit-rate top-n 10

Capitulo 3: Implementación de QoS en la red telemática de la Universidad 35 de Cienfuegos. 3. Se analiza el comportamiento del tráfico en las interfaces de salida, empleando para

ello la aplicación MRTG. Max In:498.3 kb/s

Average In:478.3 kb/s

Max Out:511.2 kb/s Average Out:316.2 kb/s

Max In:1497.3 kb/s

Average In:1397.3 kb/s

Max Out:1411.2 kb/s Average Out:1026.2 kb/s

4. Se determinan los protocolos que requieren especial atención en materia de trafico y

teniendo en cuenta los soportados por NBAR. • Priorizar: HTTP, HTTPS, SMTP • Bloquear o controlar: FTP, P2P, Cu-SeeMe, IRC, PCAnywhere, H.323, SIP, Skype, BitTorrent, Direct Connect, eDonkey, eMule, FastTrack, Gnutella, KaZaA 5. Se determinan patrones o tipos de ficheros no deseados en los URLs, que se

bloquearán total o parcialmente. Para ello se utilizan los reportes brindados por CuCERT, SANS, UNAM-CERT y otros. • Tipos de ficheros: AVI, MPEG1, MPEG2 (Permitir MPEG4) • Cadenas (ejemplos): confiker.exe, blaster.exe, etc

3.2 Implementación Se decide emplear NBAR para clasificar y marcar diferentes tipos de tráficos, bloqueando o eliminando los que se consideran no indispensables para el funcionamiento de la Red UCf en aras de lograr un mejor aprovechamiento del limitado ancho de banda existente. Igualmente se decide restringir el protocolo FTP a un 10% del uso del canal y bloquear completamente algunos servicios en el horario diurno.

Capitulo 3: Implementación de QoS en la red telemática de la Universidad 36 de Cienfuegos. 3.2.1 Configuraciones Se verifica que se encuentra habilitado CEF. Router(config)#ip cef

Trafico que se desea bloquear. Posteriormente se crea una clase para identificar el tráfico que se desea clasificar y marcar. Router(config)#class-map bloquear Router(config-cmap)#match protocol cu-seeme Router(config-cmap)#match protocol irc Router(config-cmap)#match protocol pcanywhere Router(config-cmap)#match protocol sip Router(config-cmap)#match protocol h323 Router(config-cmap)#match protocol skype Router(config-cmap)#match protocol bittorrent Router(config-cmap)#match protocol emule Router(config-cmap)#match protocol edonkey Router(config-cmap)#match protocol kazaa Router(config-cmap)#match protocol http url "*.avi*" Router(config-cmap)#match protocol http url "*.mpeg*" Router(config-cmap)#match protocol http url "*.mp3*"

Los asteriscos indican que se desea detectar cualquier URL que contenga el texto *entre ellos* sin importar lo que lo precede o siga. Se genera una política para marcar el tráfico que se ha clasificado en el paso anterior. Para esto lo marcaremos con un valor de DSCP igual a 1: Router(config)#policy-map trafico_bloquear Router(config-pmap)#class bloquear Router(config-pmap-c)#set ip dscp 1

Se configura NBAR para que inicie el proceso de descubrimiento de tráfico para todos los protocolos conocidos en una interfaz en particular.

Capitulo 3: Implementación de QoS en la red telemática de la Universidad 37 de Cienfuegos. Router(config)#interface serial 0/0/0 Router(config-if)#ip nbar protocol-discovery

Se aplica la política que se ha definido antes, a la interfaz en la que ingresa el tráfico que se desea marcar. Router(config-if)#service-policy input trafico_bloquear

De este modo se define un procedimiento de monitoreo y marcación de tráfico indeseable. Este tipo de tráfico será marcado con un valor de DSCP igual a 1. Ahora se procede a filtrarlo sobre el enlace que se desea preservar, utilizando una ACL. Se crea una lista de control de acceso que deniegue el tráfico marcado, ejemplo: Router(config)#access-list 110 deny ip any any dscp 1 Router(config)#access-list 110 permit ip any any En una variante más flexible se puede especificar un rango de tiempo, de manera que se bloqueen todos los días laborables pero solamente en el horario comprendido entre 7:30 horas y las 18:00 horas. Router(config)#access-list 110 deny ip any any dscp 1time-range todos-los-dias Router(config)#access-list 110 permit ip any any Para fijar el rango de tiempo desde el modo config: time-range todos-los-dias periodic Monday Tuesday Wednesday Thursday Friday Saturday 7:30 to 18:00

Posteriormente se aplica esa lista de acceso a la interfaz elegida para filtrar el tráfico: Router(config)#interface fastethernet 0/0 Router(config-if)#ip access-group 110 out Router(config-if)#exit

El procedimiento anterior se puede repetir con diferente valor de marcado para patrones específicos que se deseen eliminar, ejemplo virus, u otro tipo de tráfico. El ejemplo muestra la cadena de coincidencia para un supuesto virus vía http. Router(config-cmap)#match protocol http url "*confiker.exe*"

Capitulo 3: Implementación de QoS en la red telemática de la Universidad 38 de Cienfuegos. De igual forma se procede con otros protocolos que se quieren permitir pero con un control sobre el uso del canal. Router(config)#class-map controlar Router(config-cmap)#match protocol ftp Router(config)#policy-map trafico_controlar Router(config-pmap)#class controlar Router(config-pmap-c)# bandwidth percent 10

Así se regula a un uso del 10% del canal. En este comando, se define la política para permitir al tráfico FTP el 10 % del ancho de banda disponible. Posteriormente se aplica a la interfaz elegida para filtrar el tráfico: Router(config)#int fastethernet 0/0 Router(config-if)#service-policy input controlar Router(config-if)#exit 3.3 Validación de la propuesta. Para validar la propuesta de implementación se utilizó un enrutador Cisco 2811 con IOS actualizado 12.4, el cual se conecto mediante cable UTP a la Red UCf conectándose a una interface de 10 Mbps (aunque el canal es mucho mayor que los canales externos reales de la red ucf, se bajo a 10Mbps para tratar de acercar la prueba) y se configuró en la otra interface una pequeña LAN formada por un switch L2 y dos PC. 3.3.1 Primera prueba. Se ubico en un servidor web un directorio que contenía archivos del tipo: avi, mpeg, mp3, además de un fichero de nombre confiker.exe. Se procedió a intentar acceder a los ficheros comprobándose que el sistema los bloqueó y se variaron las configuraciones de rango de tiempo, para comprobar el funcionamiento adecuado para diferentes horarios.

Capitulo 3: Implementación de QoS en la red telemática de la Universidad 39 de Cienfuegos. 3.3.2 Segunda prueba. Se realizo un procedimiento similar a la primera prueba pero intentando acceder a servidores Torrents, Skype, KaZaa y otros similares que estaban restringidos. Obteniéndose resultados similares.

3.3.3 Tercera prueba. Se ubico un servidor ftp con un directorio que contenía varios archivos de gran tamaño. Posteriormente se estableció un flujo de información desde las dos PC de la LAN del escenario de prueba, copiando desde ambas varios ficheros con tamaños entre 1 y 4 GBytes. Paralelamente se empleó un equipo portátil conectado a la LAN del escenario de prueba y se realizaron solicitudes a un servidor web de la Red UCf. Se repitió la prueba empleando las configuraciones antes mencionadas de limitación del ancho de banda para el protocolo FTP comprobándose la mejora de la transferencia con el empleo de las políticas de QoS.

En estos momentos se trabaja en la implementación de pruebas en los escenarios reales con el objetivo de graficar los resultados y determinar los beneficios reales en las condiciones de operación actuales de la Red UCf.

40 CONCLUSIONES

Se realizó una revisión de la bibliografía técnico-especializada que permitió la construcción del marco teórico y así como, conocer el estado del arte referente a la utilización de QoS en redes telemáticas y sus principios de funcionamiento. Se implementaron funciones de QoS en la red telemática de la universidad de Cienfuegos que permiten mejorar el desempeño de los servicios utilizados en el proceso docente e investigativo. Se analizaron diferentes metodologías existentes para la implementación de QoS en redes telemática. Se elaboró un diagnostico de las principales características de la Red UCf en lo referente a los enlaces externos y su utilización. Se realizaron pruebas prácticas y se utilizaron aplicaciones que nos permitieron comprobar la implementación mediante la simulación de situaciones reales en escenarios de pruebas.

41 RECOMENDACIONES

Continuar con las pruebas de las implementaciones presentadas, a fin de verificar su comportamiento en la Red UCf, logrando acumular los reportes de tráficos de varios meses y proceder a su comparación con los resultados anteriores a la implementación, para tener una idea más exacta de las mejoras en el servicio. Continuar trabajando en perfeccionar la implementaciones e incorporar nuevas variantes que se acerquen más al comportamiento deseado.

42 REFERENCIAS BIBLIOGRÁFICAS [1]. “Internet QoS: A Big Picture”, Xiao, X., Ni, L., IEEE Network Magazine, Marzo/Abril 1999. [2]. “IETF Intserv Working Group”, http://www.ietf.org/html.charters/intserv-charter.html [3]. “Resource ReSerVation Protocol (RSVP) – Version 1, Functional Specification”. RFC2205, Braden, R., Zhang, L., Berson, S., Herzog, S., Jamin, S., 1997. [4]. “Providing quality of service in the Internet”, Philosophy doctor degree thesis, Xiao, X., 2000. [5]. “MPLS: Visión general de esta arquitectura”, Trabajo de diploma en telemática, Ing. Peña de la Torre, Dennys L., Ciudad de la Habana, 2003. [6]. “IEEE 802.1 P,Q - QoS on the MAC level”, http://www.tml.hut.fi/Opinnot/Tik110.551/1999/papers/08IEEE802.1QosInMAC/qos.html, Helsinki University of Technology, Ek, Niclas., Abril 1999. [7]. “Internet 2”, Montañana, Rogelio., Universidad de Valencia, Enero 2000. [8]. “Integrated Services in the Internet Architecture: an Overview”, RFC 1633, Braden, R., Junio 1994. [9]. “Applicability Statement for Extensions to RSVP for LSP-Tunnels”, Awduche, D., Hannan, A., Xiao, X., RFC 3210, Diciembre 2001.

43

Glosario de Términos Ancho de banda: Técnicamente es la diferencia en hertzios (Hz) entre la frecuencia más alta y la más baja de un canal de transmisión. Sin embargo, este término se usa mucho más a menudo para definir la cantidad de datos que puede ser enviada en un periodo de tiempo determinado a través de un circuito de comunicación dado, por ejemplo, 33.6 Kbps (miles de bits por segundo). Base de datos: Conjunto de información que se almacena de forma persistente para el uso de varios usuarios. Bit: Unidad mínima de almacenamiento de la información. Su valor puede ser 0 ó 1 (verdadero o falso). Byte: Conjunto de 8 bit. CIR (Commitated Information Rate) DiffServ: Servicios Diferenciados. Es un estándar de la IETF para garantizar Calidad de servicios en Internet. Flujos de tráfico: Son el conjunto de paquetes que viajan por la red y tienen un grupo de campos comunes, como número IP origen y número IP destino. FTP: (Protocolo Transferencias de Archivos) Http:(Protocolo de Transmisión Hipertexto).

44 ICMP: Protocolo Control de Mensajes Internet. IP: Internet Protocol (Protocolo Internet). LAN: Local área Network ó red de área local. Paquete: Una parte de un mensaje transmitido a través de la red. Por ejemplo, el protocolo de red IP, divide los mensajes que se transmiten en pequeños paquetes que viajan de forma independiente a través de los posibles trayectos hasta alcanzar su destino, donde son ensamblados para obtener el mensaje original. QoS: Quality of service ó calidad de servicios. Es el término que se refiere a las garantías que puede ofrecer una red para mantener los parámetros de calidad que necesita cada servicio o aplicación en una red. RTP: (Real-Team-Protocol) Protocolo Tiempo Real SMTP:(Protocolo Transferencia de Correo electrónico Simple) TCP/IP: Conjunto de protocolos que utiliza Internet para comunicar a los ordenadores. TCP: Protocolo de Control de Transferencia. Telnet, rlogin: Conexión a otras máquinas. TOS: Type of service ó tipo de servicio. Es un campo del paquete IP que se compone de 8 bits UDP: Protocolo Datagrama de Usuario UIT: (Unión Internacional de Telecomunicaciones) World Wide Web Server - Http, Servidor de información multimedia.

ANEXOS

ANEXO 1: Esquema topológico Red UCf.

45