Upload
others
View
10
Download
0
Embed Size (px)
Citation preview
Universidad Central “Marta Abreu” de Las Villas Facultad de Ingeniería Eléctrica
Dpto. Telecomunicaciones y Electrónica
Proyecciones para la implementación de Servicios
Diferenciados en la Red Pública de Transmisión
de Datos, CUBADATA.
Tesis presentada en opción al Título Académico de Máster en Telemática
Maestría de Telemática
Autor: Pável Cabezas Lorenzo Tutores: Dr. Félix Álvarez Paliza
2004
Solo para ti.
Resumen
Resumen
Nada ha cambiado el mundo tan rápidamente como Internet. Hoy, Internet se ha
convertido en uno de los soportes más importantes de información, así como la
utilización del protocolo IP se ha afianzado como estándar para todo tipo de servicios
y aplicaciones. Las personas usan Internet para recibir educación a distancia, realizar
compras, realizar acciones bancarias, y establecer video conferencias y muchas otras
variadas aplicaciones que hoy conviven en Internet. Como esta se hace cada vez
más importante, los requisitos son también más elevados. Guiado por la necesidad
de más ancho de banda, calidad de servicio (QoS) y seguridad, Internet ha
evolucionado rápidamente. En este trabajo, se discute las tendencias en Internet
para brindar Calidad de Servicio y los problemas asociados a la misma. Analizamos
también algunos de los modelos desarrollados por la IETF para dar solución a la mas
amplia demanda de servicios con requerimientos de calidad como son Servicios
Integrados (Intserv), Servicios Diferenciados (Diffserv) y MPLS, centrando nuestro
trabajo en Diffserv y las posibles proyecciones de la Red CUBADATA para la
implementación de este modelo como base para soluciones de QoS en nuestro país.
Tabla de Contenido
Tabla de Contenido: Introducción................................................................................................................ 1
Capítulo 1: Calidad de servicios y principales modelos propuestos para garantizarla. ............................................................................................ 6
1.1 Calidad de Servicio (QoS). ............................................................................... 6
1.2 Calidad de Servicio en ATM............................................................................ 8 1.2.1 Categorías de servicio................................................................................................................9
1.3 Modelos para garantizar Calidad de Servicio en Redes IPv4......................... 12 1.3.1 Servicios Integrados .................................................................................................................12 1.3.2 Servicios Diferenciados ...........................................................................................................14 1.3.3 MPLS ..........................................................................................................................................16
1.4 Conclusiones parciales................................................................................... 17
Capítulo 2: Servicios Diferenciados como una solución a la provisión de QoS. . 19 2.1 Introducción a los Servicios Diferenciados..................................................... 19
2.2 Introducción a la Arquitectura de Servicios Diferenciados............................ 19
2.3 Modelo de Arquitectura de Servicios Diferenciados....................................... 21 2.3.1 Elementos básicos en la Arquitectura DiffServ...................................................................21
2.4 Región de los Servicios Diferenciados............................................................ 24
2.5 Clasificación y acondicionamiento de tráfico. ................................................ 24 2.5.1 Clasificadores............................................................................................................................25 2.5.2 Perfiles de tráfico. .....................................................................................................................25 2.5.3 Acondicionamiento de tráfico. ...............................................................................................26 2.5.4 Comportamiento por Salto (PHB). ........................................................................................28 2.5.5 Protocolo de gestión de políticas (COPS). ...........................................................................34 2.5.6 Localización de los recursos en la red..................................................................................36
2.6 Limitaciones de la aplicación de Servicios Diferenciados. .............................. 36
2.8 Conclusiones parciales................................................................................... 37
Capítulo 3: Proyecciones para la implementación de la arquitectura de Servicios Diferenciados en CUBADATA. .......................................................... 39
3.1 Introducción al análisis del escenario de la Red Pública de Transmisión de Datos............................................................................................................. 39 3.1.1 Evolución del Ancho de Banda..............................................................................................40 3.1.2 Arquitectura actual de CUBADATA....................................................................................42 3.1.3 Dominio Diffserv CUBADATA............................................................................................44
3.2 Clases y diferenciación de servicios en los nodos de la Red Pública de Transmisión de Datos.................................................................................... 46 3.2.1 Diferenciación de servicios.....................................................................................................46 3.2.2 Clasificación de los paquetes..................................................................................................47 3.2.3 IP DSCP. ....................................................................................................................................48 3.2.4 Remarcación de salida del campo DSCP..............................................................................49 3.2.5 CoS NULO. ...............................................................................................................................49 3.2.6 Servicio de cola de salida a nivel de paquete.......................................................................50 3.2.7 Reenvío de CoS.........................................................................................................................50
Tabla de Contenido
3.3 Proyecciones e inversiones futuras de CUBADATA....................................... 50
3.4 Conclusiones parciales................................................................................... 52
Conclusiones.............................................................................................................. 53
Recomendaciones...................................................................................................... 54
Referencias Bibliográficas ....................................................................................... 55
Glosario de Términos ............................................................................................... 59
Anexo I. ALCATEL 7670 RSP................................................................................ 63
Anexo II. ALCATEL 7470 MSP y ALCATEL 7270 MSC ................................... 64
Anexo III. ALCATEL 7301 ASAM ........................................................................ 65
Anexo IV. HUAWEI Quidway A8010 Mini-Expert. ............................................. 66
Introducción
Página 1
Introducción
Para proporcionar la gama de servicios demandada hoy en Internet es necesario
ofrecer una serie de características de calidad de servicio que suponen un problema
para las redes IP.
En la práctica, las opciones de calidad de servicio no están muy extendidas en
Internet, si bien algunas de ellas comienzan a entreverse en redes IP privadas y
redes universitarias. Sin embargo, no existe en nuestro país experiencia alguna que
permita a los clientes de redes de datos disfrutar de una QoS superior.
En este trabajo se abordan los problemas fundamentales que deben ser controlados
por redes que soporten garantía de calidad de servicio, se explica la necesidad actual
de que los paquetes que circulan por la red de forma aleatoria, sean identificados y
clasificado a fin de darles un tratamiento diferenciado. Al mismo tiempo, se describen
las categorías, modelos y clases de calidad de servicio que se pueden ofrecerse en
las redes dentro de un entorno controlado.
Hoy en día pueden utilizarse básicamente dos métodos para mejorar la calidad de
servicio en Internet; a saber:
1) Reservar capacidad en las conexiones entre las cuales se requiere una
QoS superior.
2) Establecer un dispositivo que permita marcar los paquetes (etiquetas)
convenientemente para que éstos puedan recibir un trato prioritario.
La IETF, Internet Engineering Task Force, ha propuesto varios modelos de servicio
que cumplen con los métodos antes mencionados. Los más conocidos son: modelo
de Servicios Integrados (Intserv), modelo de Servicios Diferenciados (Diffserv) y la
técnica conocida como MPLS (Multiprotocol Label Switching).
Tendrá que transcurrir algún tiempo. Antes de que los usuarios de Internet
dispongan de un acceso generalizado a distintas opciones de calidad de servicio, esto
obedece en lo fundamental a motivos técnicos, principalmente a los problemas de
Introducción
Página 2
soporte físico y lógico que existen entre los proveedores de servicio de Internet
(ISP), debido a que la interoperabilidad entre tales proveedores dista de ser perfecta.
ETECSA, desde su fundación trabajó en crear una red de transmisión de datos que
fuera capaz de soportar el desarrollo acelerado de la tecnología informática elemento
fundamental para el desarrollo del país, ya en 1997 surge la primera red con alcance
nacional e internacional soportada en nodos basados en protocolo X.25, en 1999 se
terminó la instalación de una red ATM/FR, con enlaces internodales a 2 Mbps y
puntos de presencia en la mayoría de las provincias de forma paralela a la anterior
red, ambas se interconectaron y permitieron brindar servicios Frame Relay.
Los trabajos en la fibra óptica nacional (FON) posibilitaron elevar los enlaces
internodales a 622 Mbps, 155 Mbps y 34 Mbps permitiendo aumentar la fiabilidad del
servicio que CUBADATA venia ofreciendo a sus clientes.
En la actualidad CUBADATA cuenta con la capacidad tecnológica para desarrollar y
garantizar la QoS, pero no existe una base teórica sólida que permita su introducción
de forma efectiva.
El enfoque adoptado en el trabajo de tesis es bastante ambicioso, ya que se exponen
los elementos estructurales y técnicos que explican una posible introducción de
Servicios Diferenciados como método para garantizar calidad de servicio en la Red
Pública de Transmisión de Datos, CUBADATA. Para ello se deberá dar respuestas a
las siguientes interrogantes:
1) ¿Cuáles son los modelos de trabajo para garantizar calidad de servicio en
redes IP actuales?
2) ¿Cuáles son las normas internacionales sobre el modelo de Servicios
Diferenciados para garantizar la calidad de servicios?
3) ¿Posee CUBADATA la tecnología capaz de garantizar tráficos con QoS?
4) ¿Cómo será implementado en la Red Pública de transmisión de datos,
CUBADATA, el modelo de Servicios Diferenciados para garantizar QoS?
5) ¿Cuáles son las proyecciones y plataformas futuras de CUBADATA?
Introducción
Página 3
De las interrogantes planteadas se derivaron los siguientes objetivos:
• Realizar el estudio de los modelos que garantizan QoS en Redes IP.
• Caracterizar el modelo de Servicios Diferenciados.
• Caracterizar la tecnología instalada por ETECSA y valorar si la misma resulta
suficiente para brindar QoS.
• Evaluar la posible implementación del modelo de Servicios Diferenciados en la red
publica de Transmisión de Datos, CUBADATA.
• Evaluar la plataforma tecnológica futura de la red CUBADATA.
Para el cumplimiento de los objetivos trazados se realizaron las tareas que se
enumeran a continuación:
1. Revisión de la bibliografía técnico-especializada para la construcción del marco
teórico de referencia general del entorno mundial, así como realizar la pesquisa y
caracterización del sistema de introducción de los servicios que se brindan en la
Empresa de Telecomunicaciones de Cuba, así como en el entorno mundial.
2. Revisión bibliográfica del estado del arte en cuanto a calidad de servicio en las
redes de datos.
3. Elaboración de un diagnóstico para conocer la situación actual de la Red
CUBADATA para brindar calidad de servicio.
4. Crear una base teórica sólida que coadyuve a la implementación de la calidad de
servicio en la red CUBADATA, basadas en el modelo de Servicios Diferenciados.
5. Proponer el modelo analizado y trazar las proyecciones de implementación.
El trabajo pretende obtener los siguientes resultados:
1) Crear una base teórica sólida sobre el modelo de Servicios Diferenciados para la
implementación de calidad de servicio en CUBADATA.
2) Se obtendrán elementos que podrán contribuir en los estudios que se realizan
en ETECSA sobre temas de tarifas para la implementación de nuevos servicios
en las redes de datos del país
3) Se actualizará la información sobre el estado de las redes de datos en el país.
Introducción
Página 4
El trabajo ofrece una solución teórico-práctica dada por la falta de información sobre
los modelos de obtención de calidad de servicio. Enfatiza en las posibilidades de
implementar el modelo de Servicios Diferenciados para garantizar las demandas de
calidad de servicio, y permitiría aumentar la satisfacción del cliente con el servicio
que se le ofrece.
Económicamente, la implementación de este modelo representará para ETECSA una
nueva fuente de ingresos, ya que no se incurrirían en nuevos gastos, al contar la
tecnología actual de CUBADATA con soporte de calidad de servicio.
El trabajo también posee un impacto social, ya que puede servir de base a las
proyecciones de nuestro país en cuanto a la informatización de la sociedad y el
desarrollo de la cultura general integral de todo nuestro pueblo.
Pudiera servir también como referencia docente al presentarse un análisis de
tecnología actual y futura de la red pública de transmisión de datos, así como
argumentos teóricos sobre los temas de calidad de servicio en redes IP.
En relación con este tema se publicó un artículo denominado “Servicios Diferenciados
una solución para la Calidad de Servicio en redes IP”, registrado en la memoria del
evento SIE 2003 correspondiente al XI Simposio de Ingeniería Eléctrica en la
Universidad Central Martha Abreu de Las Villas con el ISBN: 959-250-099-1.
El trabajo de tesis esta estructurado de la siguiente forma:
• Introducción
• Capítulo 1: Se abordan las tendencias actuales de la Calidad de Servicio en
redes IP, se enumeran los modelos y técnicas fundamentales para proveerlo,
así como se muestra el estado del arte de la QoS.
• Capítulo 2: Se plantea como poder ofrecer QoS en redes IP enfatizando en el
modelo de Servicios Diferenciados como solución viable.
• Capítulo 3: Proyección para la implementación del modelo de Servicios
Diferenciados en la Red Pública de Transmisión de Datos, CUBADATA, así
como estado actual y plataforma futura en cuanto a tecnología.
Introducción
Página 5
• Conclusiones y Recomendaciones
• Referencias Bibliografías
• Glosario de Términos
• Anexos
Capítulo 1: Calidad de servicios y principales modelos propuestos para garantizarla.
Página 6
Capítulo 1: Calidad de servicios y principales modelos propuestos para garantizarla.
Tradicionalmente en Internet sólo se proporciona el servicio del “Mejor Esfuerzo”
(Best Effort). El tráfico se procesa tan rápido como sea posible, por lo que no hay
ninguna garantía acerca de la puntualidad o la entrega real de dicho tráfico. Con el
florecimiento del comercio electrónico y el cúmulo de nuevas aplicaciones surgidas
para Internet, la calidad del servicio (QoS) se ha hecho mucho más necesaria. Hay
dos fuerzas fundamentales que inciden muy fuerte sobre los temas de QoS [60] [4]:
1. Las compañías que hacen negocios en la red, necesitan calidad de
servicio para mejorar la entrega de su contenido y/o servicios para
atraer más clientes.
2. Los proveedores de servicios de Internet (ISPs), necesitan los servicios
de valor agregado en sus redes para aumentar sus ingresos.
La mayoría de las redes de computadoras, a excepción de las basadas en tecnología
ATM, no han sido diseñadas para proporcionar implícitamente los niveles de calidad
de servicio necesarios para la transmisión de diferentes tipos de tráficos con
diferentes tratamientos, IP sólo ofrece un servicio inadecuado para la excesiva carga
de las aplicaciones actuales, por lo tanto para poder soportar la amplia gama de
tráficos en Internet es necesario crear diferentes protocolos, así como una serie de
políticas para la gestión de los diferentes recursos de la red, intentando obtener una
calidad de servicio extremo a extremo y garantizando la compatibilidad de las
distintas técnicas a causa de la heterogeneidad de las redes.
1.1 Calidad de Servicio (QoS).
La calidad de servicio consiste en 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 [28]. Debemos tener en cuenta que en la red se pueden utilizar
diferentes tecnologías de transporte (como pueden ser Frame Relay, X.25, SDH,
ATM) de manera que la gestión de QoS implica la interacción con estas tecnologías y
con los equipos conmutadores y enrutadores. Estos dispositivos intercambian tráfico
Capítulo 1: Calidad de servicios y principales modelos propuestos para garantizarla.
Página 7
entre ellos mediante interfases. Si la velocidad en la que el tráfico llega a una
interfase es superior a la velocidad con la que la misma puede enviar tráfico al
siguiente dispositivo, se produce una congestión. De esta forma, la capacidad de una
interfase para enviar tráfico constituye un recurso de red fundamental. Los
mecanismos de QoS funcionan al establecer preferencias en la asignación de este
recurso a favor de cierto tráfico.
Las aplicaciones actuales generan tráfico a ritmos variables y requieren normalmente
que la red pueda transportar tráfico al ritmo que las aplicaciones lo demanden.
Asimismo, las aplicaciones son más o menos tolerantes a retrasos de tráfico en la red
y a variaciones de los mismos. Algunas aplicaciones pueden tolerar cierto grado de
pérdida de tráfico, mientras que otras no. Si dispusiéramos de recursos de red
infinitos, todo el tráfico de las aplicaciones podría transportarse al ritmo requerido,
sin latencia y sin pérdida de paquete. Sin embargo, los recursos de red no son
infinitos. Como consecuencia, hay partes de la red en las que los recursos no pueden
responder a la demanda [40].
Existen cuatro parámetros fundamentales que intervienen en la caracterización de la
Calidad de Servicio en una Red:
• Retardo: Conocido como latencia; se refiere al intervalo entre transmisión y
la recepción de los paquetes entre dos puntos de referencia.
• Variación de retardo: Llamado Jitter, se refiere a la variación en la
duración de tiempo entre todos los paquetes de un flujo, que toman la misma
ruta.
• Fiabilidad: Llamado pérdida de paquetes, es la velocidad máxima a la que
los paquetes pueden ser descartados durante la transferencia a través de la
red. Normalmente se origina como resultado de la congestión.
• Ancho de banda: Es la máxima velocidad de transferencia de datos entre
dos extremos de la red, el límite lo impone la infraestructura física de los
enlaces.
En la siguiente tabla se muestran los parámetros de calidad necesitados por
diferentes aplicaciones que se manejan hoy en Internet [23] [15] [18].
Capítulo 1: Calidad de servicios y principales modelos propuestos para garantizarla.
Página 8
Aplicación Retardo (Delay)
Variación de Retardo (Jitter) Fiabilidad (Pérdidas)
Mensajería Bajo Bajo Alto FTP Bajo Bajo Alto Base de Datos Bajo/Medio Bajo Alto Video (MPG) Alto Medio Bajo Telefonía Alto Alto Bajo Videoconferencia Alto Alto Bajo
Tabla 1.1.1 Variación de parámetros de QoS entre aplicaciones.
Para poder responder a las demandas de tráfico de todas estas aplicaciones, es
necesario, en primer lugar, identificar tráficos diferentes. El tráfico que llega a los
dispositivos de red se separa en distintos flujos mediante el proceso de clasificación
de paquetes. El tráfico de cada flujo se envía a una cola en la interfaz de reenvío.
Las colas de cada interfaz se gestionan de acuerdo con algunos algoritmos. El
algoritmo de administración de cola determina la velocidad a la que se reenvía el
tráfico de cada cola. De este modo, se determinan los recursos que se asignan a
cada cola y a los flujos correspondientes.
Los mecanismos para proporcionar Calidad de Servicio (QoS) son problemas
debatidos, para los existen opiniones que plantean que la fibra y las tecnologías de
multiplexado por división de onda tienen un ancho de banda tan abundante y barato
que donde la QoS esta implícita, otra opinión plantea que no importa cuanto ancho
de banda se tenga para que en Internet se pueda proporcionar QoS, las nuevas
aplicaciones se crearán para ser consumidas. Por consiguiente, todavía se
necesitarán los mecanismos para proporcionar QoS sobre las redes actuales. Aun
cuando los anchos de banda se volvieran finalmente abundantes y baratos en el
futuro, no es la realidad en estos momentos. Por lo que algunos mecanismos
simples son definitivamente necesarios para proporcionar QoS en Internet. Todos los
vendedores importantes de enrutadores/conmutadores (router/switch) apoyan este
punto de vista proporcionando algunos mecanismos de QoS en sus productos [61].
1.2 Calidad de Servicio en ATM.
El estándar ATM está diseñado para soportar una amplia variedad de servicios y
aplicaciones, el control de tráfico está fundamentalmente enfocado en la habilidad de
Capítulo 1: Calidad de servicios y principales modelos propuestos para garantizarla.
Página 9
la red de proporcionar una QoS apropiada y diferenciada para las aplicaciones de
red. De este modo, los dispositivos de interconexión manejan una serie de
procedimientos y parámetros diferentes que permiten establecer ciertas normas de
QoS de forma dinámica. Todo esto, con el fin de proteger la red y los sistemas
finales contra la congestión para lograr un alto rendimiento, a la vez que promueve
el uso eficiente de los recursos existentes.
1.2.1 Categorías de servicio.
La tecnología ATM usa seis Categorías para clasificar el servicio de red. De hecho las
conexiones ATM están asociadas a una categoría de servicio en particular, la cual
sirve para definir los límites en la demora de transmisión y la pérdida de celdas
dentro de la red. Por lo que ATM define un número de parámetros de QoS, los cuales
caracterizan el rendimiento de una conexión en términos de QoS que se proporciona
[33].
1.2.1.1 CBR (Tasa de Bit Constante - Constant Bit Rate).
Esta categoría de servicio fue diseñada para conexiones que requieren un ancho de
banda estático que debe estar disponible siempre durante toda la conexión. La red
dispone que una vez que una conexión CBR es establecida, la QoS negociada en la
capa ATM asegura que todas las celdas se transmitan correctamente siempre y
cuando estas cumplan con el contrato de conformidad. Para llevar el control del
tráfico, ATM establece una tasa máxima y una tasa mínima de transmisión de celdas.
La categoría de servicio CBR puede usarse tanto para VCC como VPC [33].
1.2.1.2 RT-VBR (Tasa de Bit Variable-Tiempo Real – Real-Time Variable
Bit Rate).
Esta categoría de servicio fue diseñada para aplicaciones que operan en tiempo real,
o sea, que requieren de una baja demora en la transmisión manteniendo una
variación pequeña. Este tipo de conexión establece una tasa máxima de transmisión
de celdas, una tasa de celda sostenida y un máximo tamaño de ráfaga con el fin de
poner límites a las variaciones en el flujo de las celdas. Esto es necesario pues la
Capítulo 1: Calidad de servicios y principales modelos propuestos para garantizarla.
Página 10
fuente puede transmitir a velocidades que varían en el tiempo, por lo que se puede
decir que transmiten la información de manera aleatoria (Ej. La transmisión estándar
de video comprimido resulta en una secuencia de tramas de imágenes de tamaño
variable). La red está capacitada para multiplexar estadísticamente un número de
conexiones sobre la misma capacidad dedicada y aun así proporcionar el servicio
requerido para cada conexión [33].
1.2.1.3 NRT-VBR (Tasa de Bit Variable-Tiempo no Real – Non-Real-Time
Variable Bit Rate).
Esta categoría de servicio fue diseñada para aplicaciones que no trabajan en tiempo
real y que poseen características de tráfico aleatorio, pero para las cuales se
establece igualmente una tasa máxima de transmisión de celdas, una tasa de celda
sostenida y un máximo tamaño de ráfaga con el fin de obtener una calidad de
servicio sustancialmente mejorada. En este tipo de categoría, el tráfico que es
generado cumpliendo con el contrato de conformidad, tendrá una relación de pérdida
de celda baja. El servicio NRT-VBR puede ser usado para la transferencia de datos
que tienen requerimientos de respuesta a tiempo crítico [33].
1.2.1.4 ABR (Tasa de Bit Disponible – Available Variable Bit Rate).
Las aplicaciones que usan un protocolo extremo-extremo confiable como TCP,
pueden detectar congestiones en la red, al experimentar demoras reiteradas y
pérdidas de paquetes. Sin embargo, este protocolo no posee mecanismos para lograr
que los recursos dentro de la red, sean compartidos cabalmente entre muchas
conexiones TCP. Además, TCP no minimiza la congestión de manera eficiente, pues
no usa información explícita de los nodos congestionados dentro de la red. Para
mejorar el servicio sobre este tipo de conexiones se definió ABR.
ABR es una categoría de servicio, para la cual las características de transmisión de
celdas proporcionadas por la red, pueden cambiar dinámicamente durante una
conexión. Para ello se proporciona un mecanismo de control de flujo de manera tal
que cuando se inicia una conexión, se establece un flujo de datos en una dirección y
un flujo de información de los recursos de red en la otra. Este flujo porta un tipo de
Capítulo 1: Calidad de servicios y principales modelos propuestos para garantizarla.
Página 11
celda de control llamada RM-cell (Celda de Gestión de Recursos – Resource
Management Cell). Estas celdas cumplen con el objetivo de informar a la fuente,
sobre los recursos que se encuentran disponibles en la red para esa conexión en
específico. De esta manera, los sistemas finales adaptan su tráfico, de acuerdo a los
recursos disponibles, con lo que experimentan una relación de pérdida de celda baja
y obtienen una repartición justa del ancho de banda, de acuerdo con la política de
distribución de recursos específica de la red.
En el establecimiento de una conexión, el sistema final especifica a la red una tasa
máxima de transmisión de celda que podrá usarse y una tasa mínima de transmisión
de celda que se requiere. El ancho de banda puede variar dinámicamente, pero
nunca es menor que el mínimo establecido [33].
1.2.1.5 UBR (Tasa de Bit No Específica – Unspecified Variable Bit Rate).
Esta categoría de servicio, fue diseñada para aplicaciones que no trabajan en tiempo
real y que además no requieren de una baja demora en la transmisión e incluso
toleran variaciones en el arribo de celdas y algunas pérdidas en el trayecto, pues las
aplicaciones finales utilizan protocolos que están preparados para recuperar los datos
perdidos. UBR, por tanto, no especifica garantías de servicio de ningún tipo. Con esta
categoría, las celdas son enviadas hacia adelante en una FIFO (Primero que entra-
Primero que sale – Firs in-First out) usando la capacidad no consumida por otros
servicios. Esta categoría es semejante en sus servicios al brindado por una red IP
(protocolo ampliamente difundido y que usa la técnica del mejor esfuerzo) [33].
1.2.1.6 GFR (Tasa de Trama Garantizada – Guaranteed Frame Rate).
Esta categoría pretende soportar el tráfico de aplicaciones en tiempo no real y que
pueden requerir un mínimo de garantías de velocidad y se pueden beneficiar con el
acceso de ancho de banda adicional, el cual está disponible dinámicamente en la red.
GFR no requiere adherencia a protocolos de control de flujo. Las garantías de
servicio están basadas en el tipo AAL5. Bajo condiciones de congestión, la red
intenta descartar tramas de celdas completas en vez de descartar celdas sin
referencia a límites de tramas. En el establecimiento de una conexión GFR, el
Capítulo 1: Calidad de servicios y principales modelos propuestos para garantizarla.
Página 12
sistema final especifica una tasa máxima y una tasa mínima de transmisión de celda
que se puede acompañar también de una tasa de celda sostenida. El usuario puede
mandar siempre celdas a una tasa igual a la máxima, pero la red sólo se
compromete a llevar celdas en tramas completas a nivel de la tasa mínima. El tráfico
que se encuentra más allá de la tasa mínima será entregado dentro de los límites de
los recursos disponibles. No existen demoras asociadas con esta categoría de servicio
[33].
1.3 Modelos para garantizar Calidad de Servicio en Redes IPv4.
La IETF, Internet Engineering Task Force, ha propuesto varios modelos de servicio y
mecanismos para satisfacer la demanda de QoS [59]. Los más conocidos son el
modelo de servicios integrados/RSVP (Resource Reservation Protocol), el modelo DS
de Servicios Diferenciados y la arquitectura conocida como MPLS (Multiprotocol Label
Switching) [49].
1.3.1 Servicios Integrados
El grupo de trabajo Servicios Integrados del IETF desarrolló el modelo de servicios
integrados (Intserv) [37]. Este modelo requiere que los recursos, tales como el
ancho de banda y los buffers, sean reservados a priori para un flujo de tráfico
determinado para asegurar que sea satisfecha la calidad de servicio requerido por el
flujo de tráfico. El modelo de servicios integrados incluye componentes adicionales
además de los usados en el modelo sin garantías tales como, los clasificadores de
paquetes, los programadores de paquetes y el control de admisión. Se usa un
clasificador de paquetes para identificar los flujos que va a recibir un determinado
nivel de servicio. Un programador de paquetes, maneja la programación del servicio
a los distintos flujos de paquetes, para asegurar que se cumplan los compromisos de
QoS. Se usa el control de admisión para determinar si un enrutador tiene los
recursos necesarios para aceptar un nuevo flujo.
Se han definido dos servicios bajo el modelo de Servicios Integrados: el servicio
garantizado y el servicio de carga controlada.
Capítulo 1: Calidad de servicios y principales modelos propuestos para garantizarla.
Página 13
El servicio garantizado se puede usar para las aplicaciones que requieren un tiempo
limitado de entrega del paquete. Para este tipo de aplicación, los datos que son
entregados a la aplicación después de una cantidad predefinida de tiempo
transcurrido, se considera normalmente sin valor. Por tanto, el servicio garantizado
intenta suministrar un límite firmemente cuantificado en cuanto al retardo extremo a
extremo del paquete para un flujo. Esto se cumple controlando el retardo de las
colas de espera de los elementos de la red a lo largo del camino del flujo de datos.
Sin embargo el modelo de servicio garantizado no suministra límites en cuanto a
jitter (tiempos entre llegadas de paquetes consecutivos).
El servicio de carga controlada se puede usar para las aplicaciones adaptables que
pueden tolerar algún retardo, pero que son sensibles a las condiciones de sobrecarga
de tráfico. Este tipo de aplicación normalmente funciona satisfactoriamente cuando
la red esta poco cargada, pero su rendimiento se degrada significativamente cuando
la red esta muy cargada. El servicio de carga controlada, por tanto, ha sido diseñado
para proveer aproximadamente el mismo servicio que el servicio sin garantías en una
red ligeramente cargada sin reparar en las condiciones actuales de la red. El servicio
de carga controlada se describe cualitativamente en que no hay valores especificados
de retardo o pérdidas.
La principal cuestión con el modelo de Servicios Integrados ha sido la escalabilidad
[10], especialmente en las grandes redes públicas IP que potencialmente pueden
tener millones de microflujos activos concurrentemente en tránsito.
Una característica notable del modelo de Servicios Integrados es que requiere
señalización explícita de los requerimientos de QoS de los sistemas finales a los
enrutadores. El Resource Reservation Protocol (RSVP) realiza la función de
señalización y es el componente crítico del modelo de Servicios Integrados.
1.3.1.1 RSVP
RSVP es un protocolo de señalización de estado [14]. Soporta el establecimiento
iniciado en el receptor de la reserva de recursos tanto para los flujos multidifusión
como unidifusión.
Capítulo 1: Calidad de servicios y principales modelos propuestos para garantizarla.
Página 14
Originalmente el RSVP fue desarrollado dentro de un marco de servicios integrados
para las aplicaciones con el fin de comunicar los requerimientos de QoS a la red.
Este protocolo se basa en la realización de solicitudes de reserva, si la solicitud es
rechazada, el enrutador que la rechaza enviará un mensaje de error al receptor y
terminará el proceso de señalización. Si la solicitud es aceptada, el ancho de banda
del enlace y el espacio de buffer son asignados al flujo y la información de estado del
flujo relacionado se instala en el enrutador.
Una de las cuestiones con las especificaciones originales del RSVP fue la
escalabilidad. Esto es porque fueron solicitadas reservas para los microflujos, así que
la información de estado mantenida por los elementos de la red tiende a aumentar
linealmente con el número de microflujos [9].
Recientemente, RSVP ha sido modificado y ampliado en varias direcciones para
mitigar los problemas de escalabilidad. Como resultado de ello, está llegando a ser
un protocolo de señalización versátil en Internet. Por ejemplo, RSVP se ha ampliado
para reservar recursos para la agregación de flujos [3], establecer caminos explícitos
de conmutación de etiquetas en MPLS, y realizar otras funciones de señalización
dentro de Internet. También hay varias propuestas para reducir la cantidad de
mensajes de actualización solicitados para mantener las sesiones de RSVP
establecidas [9].
1.3.2 Servicios Diferenciados
La meta del esfuerzo de los Servicios Diferenciados (Diffserv) dentro del IETF es
establecer mecanismos escalables para la categorización del tráfico en agregados de
comportamiento, que últimamente permite que cada agregado de comportamiento
sea tratado diferentemente, especialmente cuando hay una falta de recursos tales
como ancho de banda del enlace o espacio de buffer [11]. Uno de los motivos
primarios del esfuerzo Diffserv fue buscar mecanismos alternativos para la
diferenciación del servicio en Internet que mitigue las cuestiones de escalabilidad
encontradas dentro del modelo Intserv.
Capítulo 1: Calidad de servicios y principales modelos propuestos para garantizarla.
Página 15
El grupo de trabajo Diffserv del IETF ha definido un campo de Servicios
Diferenciados en la cabecera IP (campo DS). El campo DS consiste de seis bits de la
antigua cabecera IP conocida como el octeto TOS [2].
Figura 1.3.2.1 Campo Tipo de Servicio en IPv4.
El campo DS se usa para indicar el tratamiento de envío que un paquete recibiría en
un nodo [42]. El grupo de trabajo Diffserv también ha estandarizado un número de
grupos Per-Hop Behavior (PHB). Usando los PHBs, se pueden definir varias clases de
servicios usando distintas clasificaciones, reglas de políticas, modulación y
programación.
Figura 1.3.2.2 Campo DS.
Para que un usuario final de servicios de red pueda recibir Servicios Diferenciados de
su ISP (Internet Service Provider), debe ser necesario tener un Acuerdo de nivel de
Servicio (SLA, Service Level Agreement) con el ISP. Un SLA puede especificar
explícitamente o implícitamente un Acuerdo de Acondicionamiento de Tráfico (TCA,
Capítulo 1: Calidad de servicios y principales modelos propuestos para garantizarla.
Página 16
Traffic Conditioning Agreement) que define las reglas del clasificador así como las
reglas de medición, marcado, descarte y modulación.
Los paquetes se clasifican, y posiblemente se les aplican políticas y modulación en la
entrada de la red Diffserv. Cuando un paquete atraviesa la frontera entre distintos
dominios Diffserv, el campo DS del paquete puede ser marcado de nuevo según los
acuerdos existentes entre los dominios.
Los Servicios Diferenciados sólo permiten la indicación de un número finito de clases
de servicio en el campo DS. La principal ventaja de la propuesta Diffserv respecto al
modelo Intserv es la escalabilidad. Los recursos son asignados en una base por clase
y la cantidad de información de estado es proporcional al número de clases más que
del número de flujos de aplicación.
Otras capacidades de ingeniería de tráfico, tales como la gestión de la capacidad
(incluido el control del encaminamiento), también son requeridas con el fin de
entregar una calidad de servicio aceptable en las redes Diffserv. El concepto de Per
Domain Behaviors ha sido introducido para capturar mejor la noción de Servicios
Diferenciados a través de un dominio completo [45].
1.3.3 MPLS
La Conmutación de Etiquetas sobre Múltiples Protocolos (MPLS, MultiProtocol Label
Switching) es una arquitectura creada para mejorar muchos de los temas asociados
con el transporte tradicional de paquetes y las interconexiones en Internet. MPLS
integra los niveles de 2 y 3, combinando las funciones de control del enrutamiento
con la rapidez y simplicidad de la conmutación de nivel 2 [25] [34].
Capítulo 1: Calidad de servicios y principales modelos propuestos para garantizarla.
Página 17
Figura 1.3.3.1 Capas de red
MPLS proporciona otros beneficios como son [17]:
• Permite una gran interoperabilidad. No hay necesidad de superponer IP sobre
ATM y por tanto se eliminan las dificultades asociadas con su administración y la
gestión, además de desocupar a los enrutadores.
• Facilita los medios para el mapeo de direcciones IP a simples etiquetas de
longitud fija, utilizadas por diferentes tecnologías de envío de paquetes y
conmutación de paquetes.
• Permite el uso de diferentes protocolos existentes como son RSVP (Protocolo de
Reservación de Recursos) y OSPF (Open Shortest Path First).
• Permite proporcionar Servicios Diferenciados (Differentiated Services), Ingeniería
de tráfico y crear Redes Virtuales Privadas (VPN).
1.4 Conclusiones parciales.
Los principales parámetros a tener en cuenta para dar calidad en el servicio son el
retardo, la variación de retardo (Jitter), la fiabilidad o pérdida de paquetes y el ancho
de banda, determinándose que con el desarrollo actual de las redes es mas factible y
económico accionar sobre los tres primeros parámetros de QoS, accionar sobre el
ancho de banda redundaría en un aumento excesivo de gastos y además los
recursos de la red son hasta ahora finitos.
Capítulo 1: Calidad de servicios y principales modelos propuestos para garantizarla.
Página 18
Aunque existen varios modelos para garantizar QoS, orientamos nuestro trabajo
hacia la tecnología Diffserv teniendo en cuenta que se encuentra en una fase de
desarrollo lo suficientemente madura, como para plantearnos su posible implantación
a gran escala. La funcionalidad que nos aporta este modelo puede permitir el
despegue definitivo de determinados servicios con ciertos requisitos de calidad de
servicio.
Capítulo 2: Servicios Diferenciados como una solución a la provisión de QoS.
Página 19
Capítulo 2: Servicios Diferenciados como una solución a la provisión de QoS.
En el primer capítulo se ofreció una visión general de QoS, se describieron también
los términos QoS en las redes ATM, así como un resumen de los principales modelos
propuestos por IETF para garantizar QoS.
En el presente capítulo se analiza en lo particular el modelo de Servicios
Diferenciados (Diffserv) como solución a las demandas de QoS en las redes IP.
2.1 Introducción a los Servicios Diferenciados.
La arquitectura de Servic ios Diferenciados es diferente a la de servicios integrados
donde hay que realizar una reserva previa del canal. En la arquitectura de Servicios
Diferenciados los paquetes se clasifican sólo en el dispositivo de acceso a la red y
cuando estos están dentro de la red, es en este momento cuando recibirán un trato
distinto dependiendo del contenido del encabezado. Este tipo de servicios sólo
entiende a cerca de agregaciones no de flujos, esto quiere decir que se van a aplicar
diferentes comportamientos dependiendo de a que agregación pertenezca dicho
paquete.
En los siguientes aspectos que se abordan se verá con más detenimiento el
funcionamiento de esta arquitectura de Servicios Diferenciados, señalando las
funciones tanto de los nodos comentados con anterioridad como del resto de
elementos de esta arquitectura.
2.2 Introducción a la Arquitectura de Servicios Diferenciados.
A continuación se dará una introducción de lo que es la arquitectura para
implementar los diferentes servicios escalares en Internet. Un “Servicio” define
algunas características de la transmisión de paquetes en una dirección a lo largo de
un conjunto de una o más rutas dentro de una red. Estas características pueden ser
especificadas en términos cuantitativos o términos estadísticos de productividad,
retardo, y/o pérdida, o pueden ser especificados en términos de alguna prioridad
Capítulo 2: Servicios Diferenciados como una solución a la provisión de QoS.
Página 20
relativa de acceder a los recursos de la red. Esta diferenciación de servicios es
interesante para poder adecuar los requerimientos de distintas aplicaciones y las
expectativas de los usuarios, así como para permitir diferentes precios de servicios
en Internet.
Esta arquitectura se compone de un número de elementos funcionales
implementados en los diferentes nodos de las redes, incluyendo además un pequeño
conjunto de comportamientos adelantados por-salto-“per-hop-behaviour”-
(comportamiento adelantado externamente observable, aplicado a un nodo capaz de
soportar las funciones de los Servicios Diferenciados para los agregados de
comportamiento, PHB), funciones de clasificación de paquetes y funciones de
acondicionamiento del tráfico incluyendo medición, marcación, ordenación y políticas
establecidas.
Esta arquitectura logra la escalabilidad implementando complejas clasificaciones y
funciones de acondicionamiento sólo para los nodos en el límite de las redes, y
aplicando comportamientos por-salto para agregados de comportamiento (colección
de paquetes con el mismo valor específico de la parte DSCP de un campo DS [44],
cruzando un determinado enlace en una dirección particular) que han sido
adecuadamente señalados usando los campos DS (differentiated Services) en las
cabeceras Ipv4. Los comportamientos por-salto (Per Hop Behavior, PHB) [44] se
definen para poder tener los medios razonables para localizar recursos de memoria y
ancho de banda en cada nodo, entre las cadenas de tráfico que compiten por ellos.
Hay que mantener una distinción entre:
• El servicio proporcionado a un agregado de tráfico.
• Las funciones de acondicionamiento y PHB usados para realizar servicios.
• El valor del campo DSCP usado para marcar paquetes y para seleccionar un
PHB.
• Los mecanismos de implementación particular en un nodo que se encarga de
realiza el PHB.
Capítulo 2: Servicios Diferenciados como una solución a la provisión de QoS.
Página 21
Esta arquitectura sólo proporciona diferenciación de servicios en una dirección del
flujo de tráfico y es por esta razón asimétrica. El desarrollo de una arquitectura
simétrica es un tópico que se busca en la actualidad pero está fuera del alcance de lo
que se desea mostrar en este trabajo.
2.3 Modelo de Arquitectura de Servicios Diferenciados.
La arquitectura de Servicios Diferenciados se basa en un modelo simple donde el
tráfico entrante en una red es clasificado y posiblemente condicionado por los límites
de la misma al igual que asignado a los diferentes agregados de comportamiento.
Cada agregado de comportamiento (BA) se identifica por un simple “codepoint” DS
(un valor específico de la parte DSCP del campo DS usado para seleccionar un PHB).
Dentro del núcleo de la red, los paquetes son adelantados de acuerdo al PHB
asociado con el “codepoint” DS. Los elementos clave dentro de una región de
Servicios Diferenciados, la clasificación del tráfico, las funciones de
acondicionamiento, y el cómo lograr los Servicios Diferenciados a través de la
combinación del tráfico acondicionado así como del PHB basado en adelantamientos,
se verán brevemente a continuación para conocer algo más a cerca de esta
arquitectura [44] [11].
2.3.1 Elementos básicos en la Arquitectura DiffServ.
Los elementos básicos del modelo arquitectónico [11] y están representados en la
figura 2.3.1: dominio DS, nodo frontera, nodo interno, nodo de entrada y nodo de
salida.
Los conceptos de Acuerdo de Nivel de Servicio (Service Level Agreement, SLA) y
Acuerdo de acondicionamiento de tráfico (Traffic Condicioning Agreement, TCA)
pueden aplicarse entre el proveedor de servicio y el cliente, que puede ser otro
dominio. SLA es un acuerdo entre cliente y proveedor de servicio que especifica el
servicio que recibirá el cliente. Puede incluir las reglas que constituyen el TCA, el cual
consiste en un acuerdo que define las reglas, aplicables a los flujos de tráfico, para
realizar el servicio, tales como marcado, medición, descarte, adaptación (shaping).
Capítulo 2: Servicios Diferenciados como una solución a la provisión de QoS.
Página 22
Figura 2.3.1 Elementos de la Arquitectura de Servicios Diferenciados.
2.3.1.1 Dominio de los Servicios Diferenciados.
Un dominio es un conjunto contiguo de nodos DS que operan con una política de
disposición de servicios común y un conjunto de grupos PHB implementados en cada
nodo. Un dominio DS tiene un límite bien definido consistente en nodos DS limítrofes
(nodo que conecta un dominio DS a otro nodo DS que esta o en otro dominio DS o
en un dominio que no es apto para los DS) que clasifican y condicionan el ingreso de
tráfico para asegurar que los paquetes que circulan por el dominio están
correctamente marcados para seleccionar un PHB de uno de los grupos PHB que hay
dentro del dominio. Los nodos dentro del dominio DS seleccionan el comportamiento
adelantado para paquetes basándose en su ”codepoint” DS, mapean ese valor a uno
de los PHBs mantenidos. La inclusión de nodos DS no adecuados dentro de un
dominio DS puede provocar actuaciones impredecibles y puede impedir la capacidad
para satisfacer el nivel de servicios adecuados (SLAs), que son contratos entre una
organización, que es normalmente el dominio origen, y un proveedor de servicios
que especifica el servicio adelantado que esa organización debe recibir, normalmente
incluye las reglas de condicionamiento de tráfico que constituyen un TCA en parte o
en su totalidad.
Capítulo 2: Servicios Diferenciados como una solución a la provisión de QoS.
Página 23
Un dominio DS normalmente consiste en una o más redes bajo la misma
administración; por ejemplo una Intranet o un ISP (Proveedor de Servicios de
Internet).
La administración del dominio es la responsable de asegurar que los recursos
apropiados están disponibles y reservados para soportar los SLAs ofrecidos por el
dominio.
2.3.1.2 Nodos en la arquitectura de Servicios Diferenciados
Un dominio DS consiste en varios nodos limítrofes DS y nodos interiores DS. Los
nodos limítrofes DS interconectan el dominio DS a otros dominios aptos ya sean o no
DS, mientras que los nodos interiores DS sólo conectan a otros nodos interiores o
limítrofes pero dentro del mismo dominio.
• Nodos extremos DS: Clasifica y establece las condiciones de ingresos de
los flujos de tráfico en función de dirección IP y puerto tanto origen
como destino, protocolo de transporte y campo DSCP.
o Los Nodos DS de entrada: Aseguran el tráfico de entrada
cumpliendo con los requisitos del TCA (Traffic Conditioning
Agreement), derivado del SLA entre dominios interconectados.
o Los Nodos DS de salida: Realizan el acondicionamiento de
tráfico TC (Traffic Conformation) sobre el tráfico transferido
del dominio DS colindante.
• Nodos Internos DS: Realizan limitadas funciones de TC como
remarcado de DSCP, sólo se conectan a nodos internos o a nodos
externos de su propio dominio y seleccionan el PHB teniendo en cuenta
sólo el campo DSCP.
Ambos nodos tanto los exteriores como los interiores deben ser capaces de aplicar el
PHB adecuado a los paquetes basándose en el “codepoint” DS; de otra forma se
producirían comportamientos impredecibles.
Capítulo 2: Servicios Diferenciados como una solución a la provisión de QoS.
Página 24
Además, a los nodos en los límites se les puede pedir que actúen con el tráfico según
algunas funciones como las definidas por un acuerdo de acondicionamiento del
tráfico (TCA), que no es sino un acuerdo que especifica las reglas de clasificación y
cualquier perfil de correspondencia de tráfico así como las reglas de medida,
marcado, descarte y/u ordenado que son aplicadas a las cadenas de tráfico
seleccionadas por el clasificador, entre su dominio y el dominio al que ellos están
conectados. Posteriormente, en la parte de acondicionadores de tráfico se verá esto
mismo con mayor detalle.
2.4 Región de los Servicios Diferenciados.
Una región de Servicios Diferenciados (DS Region) es un conjunto de uno o más
dominios contiguos. Las regiones DS son capaces de soportar Servicios Diferenciados
a lo largo de caminos que se extienden por los dominios dentro de la misma como se
muestra en la figura 2.3.1.
2.5 Clasificación y acondicionamiento de tráfico.
Los Servicios Diferenciados se extienden a lo largo de dominios DS limítrofes
estableciendo un SLA entre una red superior y un dominio DS inferior. El SLA puede
especificar reglas de clasificación y remarcado, y puede además especificar perfiles
de tráfico y acciones a flujos de tráfico que estén o no en ese perfil, esta parte se
verá mejor cuando se analicen los perfiles de tráfico más adelante.
La política de clasificación de paquetes identifica el subconjunto de tráfico que puede
recibir un servicio diferenciado siendo acondicionado y/o mapeado a uno o más
agregados de tráfico con el mismo “codepoint” DS utilizando un enlace en una
dirección particular (DS behaviour aggregates, BAs) , remarcando su “codepoint” DS
dentro del dominio del DS.
El acondicionamiento del tráfico actúa midiendo, modelando, estableciendo una
política y/o remarcando para asegurarse de que el tráfico entra al dominio conforme
a las reglas especificadas en el TCA de acuerdo con la política de suministro del
servicio. El alcance del acondicionamiento del tráfico requerido depende de las
Capítulo 2: Servicios Diferenciados como una solución a la provisión de QoS.
Página 25
especificaciones del servicio que han sido ofertadas, y puede regularse desde simples
remarcados de “codepoints” a complejas políticas y operaciones de modelado.
2.5.1 Clasificadores.
Los clasificadores de paquetes seleccionan paquetes en flujos de tráfico basándose
en el contenido de alguna porción de la cabecera del paquete.
Se definen dos tipos de clasificadores. El clasificador de agregados de
comportamiento (BA) que clasifica paquetes basándose sólo en el “codepoint” DS. El
clasificador multicampo (MF) selecciona paquetes basándose en el valor de una
combinación de uno o más campos de la cabecera, como dirección origen, dirección
destino, campo DS, identificador de protocolo, números de los puertos origen y
destino, y otra información [7].
Los clasificadores se usan para “dirigir” paquetes emparejando algunas reglas
específicas para un elemento de un acondicionador de tráfico (entidad que ejecuta
funciones de acondicionamiento de tráfico y que se suelen desarrollar solamente en
los nodos limítrofes DS) para realizar un procesamiento más a fondo. Los
clasificadores deben ser configurados por algún procedimiento de administración de
acuerdo con el TCA establecido.
2.5.2 Perfiles de tráfico.
Un perfil del tráfico especifica las propiedades temporales de un flujo de tráfico
seleccionado por un clasificador. Proporciona reglas para determinar sí un paquete
en particular esta en un determinado perfil o fuera de él.
Se pueden aplicar diferentes funciones de acondicionamiento tanto a los paquetes
que están fuera como dentro del perfil. A los paquetes dentro del perfil se les puede
permitir entrar en el dominio sin más condiciones; o de otra forma, se les puede
cambiar su “codepoint” DS. Lo último ocurre cuando el paquete entra en un dominio
que usa un PHB de grupo o una política de mapeo “codepoint” diferente para ese
flujo de tráfico. Los paquetes que están fuera de ese perfil pueden ser encolados
Capítulo 2: Servicios Diferenciados como una solución a la provisión de QoS.
Página 26
hasta que estén dentro de un perfil, descartados, remarcados, o quedar inalterado
mientras se disparan algunos procesos de contabilidad.
El perfil del tráfico es un componente opcional de un TCA y su uso depende de las
especificaciones de servicio ofrecidas y de la política de disposición del servicio en un
dominio.
2.5.3 Acondicionamiento de tráfico.
Un acondicionador del tráfico puede contener los siguientes elementos: medidor,
marcador, limador o modelador (“shaper”), y un desconectador (“dropper”) [12]. Un
flujo de tráfico es seleccionado por un clasificador, que conduce el paquete a una
instancia lógica de un acondicionador del tráfico, donde se aplicarán las funciones de
acondicionamiento. Un medidor se usa para medir el flujo de tráfico comparándolo
con algún perfil de tráfico. El estado del medidor con respecto a un paquete en
particular, es decir, si pertenece o no a un determinado perfil, puede ser usado para
encadenar una acción de marcado, modelado o desconectado.
Los acondicionadores de tráfico están a menudo localizados dentro de los nodos
limítrofes de ingreso y regreso, pero pueden además estar localizados en nodos
dentro del interior de un dominio DS.
Las fuentes que originan el tráfico y los nodos intermedios dentro de un dominio
origen, pueden realizar la clasificación del tráfico y las funciones de
acondicionamiento. El tráfico originado por el dominio origen o fuente, a lo largo del
límite del mismo puede ser marcado directamente por el mismo origen o por nodos
intermedios antes de abandonar dicho dominio. A esto se le conoce como marca
inicial o “premarca”.
Hay algunas ventajas de marcar los paquetes que están cercanos al origen del
tráfico. Primero, una fuente del tráfico puede tener en cuenta las preferencias de las
aplicaciones más fácilmente cuando decide, que paquetes deben recibir un mejor
trato. Además, la clasificación de paquetes es mucho más simple antes de que el
Capítulo 2: Servicios Diferenciados como una solución a la provisión de QoS.
Página 27
tráfico haya sido agregado a paquetes de otras fuentes, puesto que el número de
reglas de clasificación que necesitan aplicarse dentro de un nodo se reduce.
Ya que el marcado de paquetes puede ser distribuido a lo largo de múltiples nodos,
el dominio DS origen es responsable de asegurar que el agregado de tráfico que se
dirige hacia su proveedor de servicio sea conforme al TCA apropiado.
Los nodos limítrofes de un dominio origen deben además monitorizar conforme al
TCA, y deben establecer la política, ordenado, o remarcado de paquetes conforme
sea necesario.
La figura 2.5.3 muestra el diagrama de bloques de un acondicionador de tráfico y de
un clasificador.
Figura 2.5.3 Vista lógica de un clasificador de paquetes y un acondicionador de tráfico.
2.5.3.1 Medidores (Meter).
Miden las propiedades temporales de un flujo de paquetes seleccionado por un
clasificador, comparándolo con un perfil de tráfico especificado en un TCA. El
medidor pasa información de estado a otras funciones de acondicionamiento para
disparar una acción particular para cada paquete que este o bien dentro o fuera de
un perfil.
Capítulo 2: Servicios Diferenciados como una solución a la provisión de QoS.
Página 28
2.5.3.2 Marcadores (Marker).
Los marcadores de paquetes establecen el campo DS de un paquete a un
determinado “codepoint”, añadiendo el paquete marcado a un agregado de
comportamiento DS particular. El marcador puede ser configurado para marcar todos
los paquetes que están dirigidos a él con un “codepoint” singular, o pueden ser
configurados para marcar un paquete para uno de los conjuntos de “codepoints”
usados para seleccionar un PHB dentro de un grupo de PHB, de acuerdo con el
estado del medidor. Cuando el marcador cambia el “codepoint” en un paquete se
dice que ha “re-marcado” el paquete.
2.5.3.2 Limadores o Modeladores (Shapers).
Retrasan algunos de todos los paquetes de un flujo de tráfico para introducir un flujo
de acuerdo a un perfil de tráfico. Un Limador a menudo tiene un tamaño de buffer
finito, y los paquetes pueden ser descartados si no hay suficiente espacio de buffer
para mantener los paquetes retrasados.
2.5.3.3 Desconectadores (Droppers).
Descartan algunos de entre todos los paquetes en un flujo de tráfico para introducir
un flujo de acuerdo a un perfil de tráfico. Puede ser implementado como un caso
especial de limador si se pone como tamaño del buffer del limador a 0, o en su
defecto a un número pequeño de paquetes.
2.5.4 Comportamiento por Salto (PHB).
Básicamente un PHB (Per Hob Behavior) es una descripción del comportamiento
observable externamente de un conjunto de paquetes denominado Behavior
Aggregate (BA), y debe permitir la construcción de servicios predecibles. Los BA son
conjuntos de paquetes mostrados con un mismo DSCP [13] y enviados en la misma
dirección, pudiendo pertenecer a un mismo agregado de paquetes procedentes de
múltiples fuentes o aplicaciones. Técnicamente hablando, un PHB denota una
combinación de comportamientos de reenvío, clasificación, planificación y descarte
Capítulo 2: Servicios Diferenciados como una solución a la provisión de QoS.
Página 29
en cada salto de los paquetes pertenecientes a un mismo BA. El DSCP del paquete
define el PHB de forma no ambigua y se utiliza para informar a los nodos internos de
la red del PHB del paquete
El ejemplo más simple de PHB es uno que garantice una asignación mínima de un
ancho de banda de un enlace para un agregado de comportamiento. En general, el
comportamiento observable de un PHB puede depender de ciertas restricciones en
las características del tráfico del agregado de comportamiento asociado, o de las
características de otros agregados.
2.5.4.1 Grupos de PHB.
Los PHBs pueden ser especificados en términos de la prioridad de sus recursos
(buffer, ancho de banda) con respecto a otros PHBs, o en términos de sus
características relativas de tráfico observables (retraso, pérdida). Estos PHBs pueden
ser usados como bloques de construcción para localizar recursos y deben ser
especificados como un grupo (PHB groups) para darles más consistencia. Los grupos
PHB a menudo compartirán unas restricciones comunes que serán aplicadas a cada
PHB dentro del grupo, tales como planificación del paquete o políticas de
administración de buffer.
2.5.4.1.1 PHB por defecto.
El PHB por defecto tiene que estar disponible en todos los nodos de Servicios
Diferenciados. Este es el comportamiento de reenvío conocido como mejor esfuerzo
comúnmente disponible en los routers existentes y estandarizado en [6]. Cuando no
exista otro consenso, se asume que los paquetes pertenecen a este agregado. Tales
paquetes pueden ser enviados dentro de la red sin cumplir ninguna regla particular y
la red procesará estos paquetes tan pronto como sea posible, sujetos a restricciones
y políticas de otros recursos. Una implementación razonable para esta PHB sería una
disciplina de colas que envíe paquetes de este agregado cuando el vínculo de salida
no es requerido para satisfacer otro PHB. Una política razonable para servicios
constructivos aseguraría que el conjunto no se “muera de hambre”. Esto puede ser
forzado por un mecanismo en cada nodo que reserva algún mínimo de recursos
Capítulo 2: Servicios Diferenciados como una solución a la provisión de QoS.
Página 30
(buffers, ancho de banda) para agregados de comportamiento por defecto. Esto
permite a los emisores que no utilizan Servicios Diferenciados, continuar usando la
red de la misma manera que antes. El codepoint recomendado para el PHB por
defecto es el patrón de bit ‘000000’; el valor ‘000000’ tiene que mapear al PHB que
cumple estas especificaciones. El codepoint escogido para el comportamiento por
defecto es compatible con las prácticas existentes. Donde un codepoint no es
mapeado para el uso de un PHB Standard o local, este debe mapearse al PHB por
defecto [56].
Un paquete inicialmente marcado para un comportamiento por defecto puede ser
remarcado con otro codepoint para que este pase la frontera en un dominio DS tal
que este será reenviado usando un PHB diferente con ese dominio, posiblemente
sometido a algún acuerdo negociado entre los dominios involucrados.
2.5.4.1.2 PHB selector de clase.
El grupo de PHBs mapeados al selector de 8 clases tienen que cumplir al menos dos
clases de tráfico reenviadas independientemente, y los PHBs seleccionados por un
codepoint selector de clase deben brindar a los paquetes una probabilidad de reenvío
oportuna que no sea menor que la de los paquetes marcados con un codepoint de
orden menor, bajo condiciones de operación y carga de tráfico normales. Un paquete
se descarta en el caso extremo de un reenvío fuera de tiempo. En adición los PHBs
seleccionados por codepoints ‘11x000’ tienen que dar a los paquetes un tratamiento
de reenvío preferencial en comparación con los PHBs seleccionados por codepoints
‘000000’ para preservar el uso común de los valores de precedencia IP “110’ y ‘111’
para el ruteo de tráfico [44] [35].
Por otro lado, los PHBs seleccionados por distintos codepoint deben ser reenviados
independientemente, por lo que pueden ser reordenados. Un nodo de red puede
limitar la cantidad de recursos que pueden ser utilizados por cada PHB.
Capítulo 2: Servicios Diferenciados como una solución a la provisión de QoS.
Página 31
2.5.4.1.3 PHB de reenvió expedito (EF PHB).
El objetivo principal del PHB de reenvío Expedito (Expedited Forwarding PHB, EF
PHB) [35] [38], es proporcionar servicios con pérdidas, latencia y variación de
retardo de valores bajos, y ancho de banda garantizado. En otras palabras,
equivalentes a los de una línea dedicada virtual o bien a los servicios de calidad
garantizada del modelo de Servicios Integrados. El EF PHB se define como un
tratamiento de reenvío en el que la velocidad de salida de cada nodo debe ser
superior o igual a una velocidad configurable. El tráfico EF debe recibir esta velocidad
independientemente de la intensidad de cualquier otro tráfico en la red. Su valor
medio, medido en un intervalo de tiempo igual o superior al tiempo de transmisión
del mayor paquete (MTU, Maximum Transmisión Unit) debe ser igual o superior a la
velocidad configurada. Este servicio se denomina también Premium y sólo tiene un
nivel de calidad (un DSCP único). Ejemplos de posibles aplicaciones son las
aplicaciones en tiempo real, como videoconferencia o voz sobre IP o bien
aplicaciones críticas interactivas.
Un escenario posible para la implementación del servicio EF PHB es que el usuario
solicite al proveedor del servicio, que los paquetes de una determinada aplicación,
identificados por los números de puerto de origen y destino, se clasifiquen en el
nodo frontera de entrada como EF PHB. El clasificador controla que estos paquetes
se dirijan al acondicionador para su tratamiento. En el nodo frontera debe haber un
control sobre las colas y, en consecuencia sobre la latencia, jitter y pérdidas. Los
paquetes en exceso se deben descartar de una forma inmediata, para que no
afecten a los restantes flujos. También se puede utilizar un mecanismo de
adaptación para mejorar la característica de pérdidas. En los nodos internos los
paquetes que llegan antes de tiempo deben reenviarse de forma inmediata.
La alternativa de una opción de remarcado para reenviar el paquete a su debido
tiempo afectaría a los paquetes que llegasen a continuación, que serían denotados,
aunque llegasen en tiempo correcto. Los mecanismos de colas mencionados en la
especificación, son: cola de prioridad simple (una cola dentro de un grupo de colas
servida por un planificador cíclico ponderado en el que la proporción de ancho de
Capítulo 2: Servicios Diferenciados como una solución a la provisión de QoS.
Página 32
banda de salida asignado al tráfico EF PHB sea igual a la velocidad configurada) y
cola basada en clases CBQ (Class Based Quering) que proporcione prioridad al tráfico
EF PHB hasta la velocidad configurada. CBQ también conocido como Custom
Quering, es un método cuyo objetivo primordial es tratar de impedir un bloqueo
total de las clases de servicio de nivel inferior. Los flujos se asignan a diferentes
niveles de colas con distinta prioridad, que se sirven cíclicamente. En cada cola se
fija un tamaño máximo de bytes que puede ser servido en cada ciclo. De esta forma
se asegura que ninguna aplicación obtiene más que una determinada proporción de
la capacidad total, en caso de saturación.
2.5.4.1.4 PHB de reenvío asegurado (AF PHB).
El PHB de Reenvío Asegurado (Assured Forwarding PHB) está propuesto en [35]
[37], su objetivo primordial es satisfacer la demanda de que el reenvío de los
paquetes IP pueda asegurarse en Internet e Intranets. Una aplicación típica puede
ser una organización con varias sedes que requiera que los paquetes IP en su
Intranet o Red Privada Virtual tengan una alta probabilidad de reenvío siempre que
el tráfico agregado de cada sede no exceda el perfil de tráfico, es decir, la velocidad
suscrita. Permite también que un proveedor de un dominio DS pueda ofrecer
diferentes niveles de seguridad de reenvío a los paquetes IP recibidos de un cliente.
En esencia, este PHB está relacionado fundamentalmente con la importancia de los
paquetes, en el sentido de que los paquetes más importantes son los que deben
tener una probabilidad más baja de descarte.
En principio, el AF PHB puede tener N clases con M niveles de prioridad de descarte
cada una. En la especificación actual, N=4 y M=3. Ahora bien, no es obligatorio
implementar las 4 clases y, así mismo, una implementación con 2 prioridades de
descarte puede ser aceptable, especialmente en los casos en que las situaciones de
congestión no sean frecuentes.
Las características más significativas del modelo podrían resumirse en las siguientes:
Capítulo 2: Servicios Diferenciados como una solución a la provisión de QoS.
Página 33
• No debe asignar una capacidad (ancho de banda y buffers) configurada
a cada clase, de acuerdo con el SLA con el proveedor del servicio. Las
clases de numeración más alta recibirán más recursos.
• No se pueden agregar dos o más clases.
• No se pueden reordenar los paquetes de un mismo flujo, cuando
pertenecen a la misma clase, independientemente de su prioridad de
descarte.
• En líneas generales, el servicio asegurado simula una red con baja
carga, equivalente al Servicio de Carga Controlada del modelo de
servicios Integrados.
Las clases definidas en el AF PHB son AF1, AF2, AF3 y AF4.
AFxy representa el nivel de prioridad de descarte “y” dentro de la clase “x”. Si se
denomina PD (AFxy) a la prioridad de descarte del nivel “y” de la clase “x”, debe
verificarse que PD (AFx1)<=PD (AFx2)<=PD (AFx3). Es decir, los paquetes AFx3
deben descartarse antes que los paquetes AFx2 y, éstos, antes que los de clase
AFx1. Los flujos de tráfico, dentro de un determinado BA, que exceden el ancho de
banda asignado deben ser penalizados. Esta función puede realizarse remarcando los
paquetes en exceso con un mayor valor de precedencia, es decir con una mayor
probabilidad de descarte [35].
Es difícil poder analizar en términos generales la implementación de los AF PHB,
dada su versatilidad. De hecho, la especificación no menciona mecanismos
particulares, salvo las propiedades del algoritmo RED para gestión de colas. En
principio, el usuario puede enviar los paquetes que desee del nivel de importancia
más bajo, siendo marcados los paquetes del nivel más bajo. De esta forma el perfil
de tráfico puede caracterizarse por un cubo de fichas y una especificación de la
velocidad.
Tomando un ejemplo de la especificación, en el caso de que las acciones de
acondicionamiento proporcionen una carga moderada para los paquetes más
importantes (con precedencia de descarte más baja) y que no haya sobrecarga para
el tráfico de los otros dos niveles, la clase AF PHB puede ofrecer un alto nivel de
Capítulo 2: Servicios Diferenciados como una solución a la provisión de QoS.
Página 34
reenvío asegurado para los paquetes dentro del perfil (marcados con precedencia de
descarte más baja) y hasta dos niveles de reenvío asegurado para el restante tráfico.
Otro ejemplo ilustrativo, es asignar en una clase dos velocidades a los dos niveles de
importancia más elevados, mientras que el más bajo se asocia a un comportamiento
de mejor esfuerzo. Si no se hace premarcado por el usuario, los nodos frontera
marcarían tantos paquetes como fueran posibles en el nivel de mayor importancia. Si
los paquetes no pueden obtener este nivel, se marcarían con el nivel medio, y
cuando esto tampoco fuera posible, se marcarían con el nivel más bajo de
importancia.
2.5.5 Protocolo de gestión de políticas (COPS).
Dentro de este escenario que define Diffserv necesitamos algún modo de
comunicación para distribuir las políticas de calidad de servicio entre los elementos
de red que las necesiten. Existe un protocolo creado al efecto que nos permitirá
resolver este problema de comunicación.
El protocolo COPS (Common Open Policy Service) [28], define un modelo sencillo de
cliente-servidor que proporciona control de políticas para protocolos con señalización
de calidad de servicio. El modelo descrito no hace ninguna suposición acerca de los
procedimientos utilizados en el servidor de políticas, sino que se basa en un servidor
que devuelve decisiones a las peticiones realizadas por los clientes. La definición del
protocolo es bastante abierta para que sea extensible y poder soportar los distintos
tipos de clientes que pudieran aparecer en el futuro.
El protocolo COPS se basa en sencillos mensajes de petición y respuesta utilizados
para intercambiar información acerca de políticas de tráfico entre un servidor de
políticas (PDP, Policy Decision Point) y distintos tipos de clientes (PEPs, Policy
Enforcement Points). Un ejemplo de cliente COPS podría ser un router RSVP o
Diffserv que deba realizar funciones de control de admisión en base a determinada
política. Por otro lado, el modelo supone que existe al menos un servidor de políticas
en cada dominio administrativo.
Capítulo 2: Servicios Diferenciados como una solución a la provisión de QoS.
Página 35
Uno de los objetivos principales del protocolo es proporcionar un modelo sencillo
pero fácilmente extensible. Las características principales del protocolo COPS son las
siguientes:
• Emplea un modelo cliente/servidor en el que el PEP envía peticiones y
actualizaciones al PDP, y el PDP responde con las decisiones tomadas.
• Utiliza TCP como protocolo de transporte para asegurar así fiabilidad en el
intercambio de mensajes entre los clientes y el servidor.
• Es extensible en el sentido de que está diseñado para permitir el uso de
objetos auto-identificativos y soporta distintos tipos de información específica
de clientes, sin tener que realizar ningún tipo de modificación sobre el
protocolo. COPS se creó para la administración general, configuración y
aplicación de políticas en una red.
• COPS proporciona seguridad a nivel de mensaje mediante autenticación,
protección frente al reenvío (replay) e integridad de mensaje. COPS permite
además reutilizar otros protocolos de seguridad existentes para proporcionar
autenticación y proteger el canal entre el PEP y el PDP.
Figura 2.5.5 El modelo COPS.
La figura anterior muestra la disposición de diferentes componentes en un ejemplo
COPS típico. En este modelo, el protocolo COPS se utiliza para comunicar la
información sobre las políticas de la red entre los puntos de aplicación de políticas
(PEPs) y un servidor de políticas remoto (PDP), conocido también como Bandwidth
Broker (BB) que centraliza la asignación de códigos.
Capítulo 2: Servicios Diferenciados como una solución a la provisión de QoS.
Página 36
Dentro del nodo de red puede existir un PDP local que puede ser utilizado para
tomar decisiones locales en ausencia de un PDP.
El PEP puede tener también la capacidad de tomar decisiones de política localmente,
a través de su LPDP (Local Policy Decision Point), aunque el PDP sigue manteniendo
la autoridad en cuanto a las decisiones. Esto quiere decir que cualquier decisión local
relevante debe enviarse al PDP. Asimismo, el PDP debe tener acceso a toda la
información para poder tomar una decisión final. Para ello, el PEP debe enviar las
decisiones locales al PDP a través de un objeto “LPDP Decisión”, y posteriormente
atener la decisión que tome el PDP.
2.5.6 Localización de los recursos en la red.
La implementación, configuración, operación y administración de los grupos PHB en
los nodos de un dominio DS deben de repartirse de forma efectiva los recursos de
esos nodos y los enlaces a través de nodos entre agregados de comportamiento, de
acuerdo a la política que proporciona el servicio en el domin io. Los acondicionadores
de tráfico pueden además controlar el uso de esos recursos a través de la ejecución
de TCAs. Aunque se puede desplegar un rango de servicios en ausencia de
complejas funciones de acondicionamiento de tráfico (por ejemplo usando simples
políticas de marcado), funciones como el establecimiento de políticas, modelado
(shaping), y remarcado permiten el desarrollo de servicios que proporcionan diversas
métricas.
La configuración de la interacción entre acondicionadores de tráfico y nodos internos
debe ser gestionada por el controlador administrativo de un dominio y puede
requerir control operacional a través de protocolos y un control de entidad. Hay
varios modelos de control posibles.
2.6 Limitaciones de la aplicación de Servicios Diferenciados.
Existen ciertas limitaciones a la hora de implantar Diffserv que son inherentes al
modelo Diffserv, las cuales impiden en cierta manera la implementación a gran
escala de este sistema. Directamente relacionado con este tema, se encuentra el
Capítulo 2: Servicios Diferenciados como una solución a la provisión de QoS.
Página 37
estudio del modelo de negocio que presenta Diffserv en la actualidad. Los problemas
de implantación son los siguientes:
• Resulta interesante estudiar la situación en la que se encuentra actualmente
Internet, donde se debe de atravesar diferentes ISPs para alcanzar nuestro
destino. En este caso el valor del Byte DS puede ser modificado en cualquier
equipo intermedio según las políticas de tráfico y diferentes contratos SLA
tengan entre esos ISPs. De esta forma, una calidad extremo a extremo sólo
será alcanzable cuando todos los elementos involucrados en la cadena
(dominios Diffserv) actúen según las mismas políticas [31].
• Analizando el modelo Diffserv parece lógico que alcanzar un destino más
lejano resulte más caro que otro más cercano donde se necesiten atravesar
menos ISPs. En consecuencia el costo de enviar un paquete sería diferente en
función del camino que deba atravesar. Esto puede suponer una complicación
a la hora de ofrecer el servicio y tarificarlo, este mismo problema aparecía en
el nacimiento de Internet, donde también resultaba más caro enviar un
paquete cuantos más ISPs tuviese que atravesar, y sin embargo, por el
momento los proveedores de acceso han decidido ofrecer una tarifa fija
independientemente del destino de los paquetes.
2.8 Conclusiones parciales.
En este capítulo se han presentado los Servicios Diferenciados como una de las
técnicas a la hora de proporcionar calidad de servicio (QoS). Se han planteado
algunos inconvenientes, discutiendo también los tipos de aplicaciones y servicios que
usan o pueden usar la arquitectura de los Servicios Diferenciados para proporcionar
una calidad de servicio que, en muchos casos, es un requisito indispensable de dicha
aplicación o servicio.
A partir del estudio de Diffserv y sus limitaciones podemos distinguir algunas
ventajas y aplicaciones o servicios aplicables a este modelo.
En primer lugar los servicios basados en suscripción cobran especial importancia.
Debido al hecho de ser el origen el encargado de realizar la reserva, servicios Pay Per
Capítulo 2: Servicios Diferenciados como una solución a la provisión de QoS.
Página 38
View, canales de radio, canales de televisión, podrían aparecer en el modelo de
negocio Diffserv.
Siguiendo el mismo razonamiento puede verse que el principal problema es poner de
acuerdo a origen y destino para alcanzar la QoS deseada. Este problema desaparecía
en el caso de las VPNs (redes virtuales privadas) donde el origen y el destino
pertenecen a la misma organización, de manera que comparten los mismos criterios
sobre QoS. De esta manera, el desarrollo de Dif fserv podría presentar un especial
interés de cara a la creación de VPNs sobre una red IP [24].
Resulta de especial interés en las videoconferencias donde se incluye cualquier tipo
de escenario VoIP (Voice over IP). Este servicio podría representar una buena fuente
de ingresos en el modelo Diffserv. El desarrollo de este tipo de comunicaciones no ha
tenido éxito hasta ahora por lo falta de provisión de QoS, pero la llegada de Diffserv
podría suponer el despegue de este tipo de servicios.
Otro caso interesante podrían ser los juegos online. Suele tratarse de aplicaciones
que no tienen un gran ancho de banda, pero si importantes requisitos de retardo. La
existencia de una gran plataforma de videojuegos esta supeditada a la provisión de
QoS.
Capítulo 3: Proyecciones para la implementación de la arquitectura de Servicios Diferenciados en CUBADATA.
Página 39
Capítulo 3: Proyecciones para la implementación de la arquitectura de Servicios Diferenciados en CUBADATA.
En los anteriores capítulos se han analizado los principales términos de Calidad de
Servicio, así como las diferentes características de la arquitectura de Servicios
Diferenciados, en lo adelante analizaremos la posible implementación de esta
arquitectura en el escenario real de la Red Pública de Transmisión de Datos,
CUBADATA.
3.1 Introducción al análisis del escenario de la Red Pública de
Transmisión de Datos.
En el año 1994 surge ETECSA, Empresa de Telecomunicaciones de Cuba, SA, con la
concesión administrativa para la prestación de los servicios públicos de
telecomunicaciones en todo el territorio nacional, dentro de los alcances de esta
concesión esta el Servicio de transmisión de Datos Nacional e Internacional, y se
determinó como una de las obligaciones de ETECSA, crear una red de datos de la
capacidad necesaria con cobertura nacional [21].
Para ese año se encuentra que existía un panorama muy deprimido en las
telecomunicaciones, con una pobre infraestructura telefónica y una casi nula
infraestructura de transmisión de datos. Hasta ese momento los esfuerzos se
limitaban a un pequeño Backbone Nacional, conformado por pequeños nodos X.25
que conformaban la red CUBAPAC, Junto a esta se desarrolló también un esfuerzo
del grupo GET (Grupo de la Electrónica para el Turismo) TELEDATOS de llevar
algunos enlaces X.25 a los principales polos turísticos del país. En ese momento, con
la baja calidad de los enlaces interprovinciales, no se podía lograr una gran red de
datos.
Ya para finales de 1997 surge la Red Pública de Transmisión de Datos CUBADATA,
con lo que se materializa el proyecto iniciado por el Ministerio de Comunicaciones
para la creación de una red pública capaz de impulsar el desarrollo del país
propiciando la conectividad necesaria para el desarrollo social. Se comienza así la
Capítulo 3: Proyecciones para la implementación de la arquitectura de Servicios Diferenciados en CUBADATA.
Página 40
explotación de una red que permitía la conexión a nivel nacional utilizando los
protocolos X.25 y Frame Relay, a velocidades hasta 2 Mbps.
A mediados de 1999 se inicia la primera etapa del actual BACKBONE ATM, la cual le
permite a CUBADATA lograr la mayor distribución geográfica de todas las redes de
datos de Cuba.
Con el proceso constante de cambio y transformación que tiene ETECSA, para agosto
del 2002 se asume una nueva estructura empresarial por negocios, creándose
CUBADATA como Unidad de Negocios con un objeto social de proveer servicios
públicos de transporte y conectividad de transmisión de datos nacional e
internacional.
3.1.1 Evolución del Ancho de Banda
Desde sus inicios la red pública de transmisión de datos venía realizando ingentes
esfuerzos en brindar cada vez más servicios y de mejor calidad, todo esto aparejado
al propio desarrollo de la infraestructura de transporte que ETECSA estaba
desarrollando en todo el país. Los primeros pasos transcurrieron sobre la naciente
red nacional de microonda digital, la permitió conectar a los diferentes nodos del país
a través de enlace E1, luego se comenzó el montaje de la primera fase de la red de
Fibra Óptica Nacional (FON), la que permitió elevar los anchos de banda de los
enlaces internodales hasta enlaces 155 Mbps y de 34 Mbps, comenzando entonces a
pensar en aumentar la gama de servicios que hasta ahora CUBADATA ofrecía. A su
ves el ancho de banda para acceso internacional contratado por Cubadata se
incrementó de 29/29 Mbps a 87/31 (entrada/salida); de diciembre del 2001 a
diciembre del 2003.
La red CUBADATA distribuye sus servicios entre clientes con redes corporativas y las
redes de los Proveedores de Servicio de Internet, los que han ido introduciendo en
sus redes muchos y variados servicios como pueden ser:
• Voz sobre IP (VoIP).
• Sistemas contables con bases de datos centralizadas y distribuidas.
Capítulo 3: Proyecciones para la implementación de la arquitectura de Servicios Diferenciados en CUBADATA.
Página 41
• Voz sobre Frame Relay.
• Telemedicina.
• Educación a distancia.
• Y los muy conocidos email, WWW y FTP [8].
Todos estos servicios fluyen sobre la misma red y como se hace evidente el cliente,
sea corporativo o un ISP, necesita dar un tratamiento diferente a cada uno de estos
servic ios, por lo que se ha recurrido al método mas lógico y único que brinda nuestra
red hasta el momento, el aumento de ancho de banda de sus enlaces. Un ejemplo es
que los ISP incrementaron sus anchos de banda de 19/19 Mbps a 51/32 Mbps en el
período de diciembre del 2001 a diciembre del 2003.
Esta forma de resolver la necesidad de recursos, tiene algunas limitaciones como
pueden ser:
• Las propias de la red de transporte que hasta ahora cumple las expectativas
para los enlaces actuales y futuros, pero que es finita.
• Los análisis de costo [54] y hasta ahora es la limitación mas importante:
o Costo en el cambio o mejora de la tecnología del cliente para soportar
estos nuevos tipos de enlaces.
o Costo de los enlaces [30].
En la actualidad los anchos de banda de los enlace son agotables y costosos. En la
tabla 3.1.1.1 se muestra la distribución actual, por tipos de enlaces y velocidades
contratadas a CUBADATA en todo el territorio nacional, donde se pueden observar
las configuraciones de servicio establecidas por los clientes, derivándose tres
velocidades con la mayor concentración de clientes:
o 19.2 Kbps
o 64 Kbps
o 128 Kbps
Capítulo 3: Proyecciones para la implementación de la arquitectura de Servicios Diferenciados en CUBADATA.
Página 42
Servicios X.25- Frame Relay Servicios Punto a Punto Servicios Velocidades % Servicios Velocidades %
1005 19.2 Kbps 54,8% 12 9.6 Kbps 0,53% 464 64 Kbps 25,3% 3 14.4 Kbps 0,13% 180 128 Kbps 9,8% 136 19.2 Kbps 6,09% 65 256 Kbps 3,5% 105 28.8 Kbps 4,70% 5 384 Kbps 0,3% 19 33.6 Kbps 0,85%
34 512 Kbps 1,9% 1400 64 Kbps 62,70% 20 1Mbps 1,1% 416 128 Kbps 18,63% 61 2 Mbps 3,3% 57 256 Kbps 2,55% 1 10 Mbps 0,1% 21 512 Kbps 0,94% 1 34 Mbps 0,1% 14 1 Mbps 0,63%
50 2 Mbps 2,24% 1834 100% 2233 100%
Tabla 3.1.1.1 Distribución de servicios por velocidades.
Y como forma más clara le mostramos el gráfico 3.1.1.2 donde se representan tanto
los enlaces a la red de transporte de datos como a la red de los ISP y demás redes
privadas de datos.
Gráfico 3.1.1.2 Distribución de servicios por velocidades.
3.1.2 Arquitectura actual de CUBADATA.
La red pública de transmisión de datos, CUBADATA cuenta con un total de 53 puntos
de presencia en todas las capitales de provincias del país y en 20 municipios fueras
de estas, con una capacidad instalada de 3646 puertas distribuidas entre varios
nodos de tecnología ALCATEL como son:
• ALCATEL 7670 Routing Switch Platform
Capítulo 3: Proyecciones para la implementación de la arquitectura de Servicios Diferenciados en CUBADATA.
Página 43
• ALCATEL 7470 Multiservice Platform
• ALCATEL 7270 Multiservice Concentrador
• 3600 MainStreet Multiservice Bandwidth Manager
• ALCATEL 3630 MainStreet Primary Rate Multiplexer
• ALCATEL 2902 MainStreet Network Termination Unit
Hasta ahora dentro de este grupo sólo los nodos ALCATEL 7670 RSP, ALCATEL 7470
MSP y ALCATEL 7270 MSC [1], permiten la implementación de QoS por si mismo, o
sea son capaces de brindar esos recursos directamente, los demás nodos se
comportan como nodos de acceso, nivel 1 y 2 del modelos OSI.
En el caso que nos ocupa la arquitectura actual que presenta CUBADATA en el dorsal
ATM/Frame Relay, ver figura 3.1.2.1, favorece técnicamente la implementación de
Servicios Diferenciados en el “Dominio DiffServ CUBADATA”.
Figura 3.1.2.1 Arquitectura actual del dorsal ATM/Frame Relay de CUBADATA.
Capítulo 3: Proyecciones para la implementación de la arquitectura de Servicios Diferenciados en CUBADATA.
Página 44
3.1.3 Dominio Diffserv CUBADATA.
El dominio Diffserv CUBADATA, cumple la arquitectura actual y futura, con un único
dominio de alcance nacional, por ser CUBADATA el único proveedor de transporte de
datos del país y tener conectado a él la mayoría de las redes corporativas [16] del
país y a los ISP nacionales.
Como toda arquitectura de Servicios Diferenciados cuenta con nodos de red que
desempeñas funciones de:
• Nodos extremos DS que clasifican y establecen las condiciones de
ingresos de los flujos de tráfico.
• Nodos Internos DS que realizan limitadas funciones de
acondicionamiento de tráfico, como remarcado de DSCP.
• Servidor de Políticas (PDP), ver figura 2.5.5 del capítulo 2, este se
encarga de la distribución de las políticas de la red, determinadas en los
acuerdos de nivel de servicios (SLA) concertados entre proveedor y
cliente.
Estas funciones de nodos internos DS pueden ser realizadas en la actualidad por los
nodos ALCATEL 7470 MSP (Anexo II) y ALCATEL 7270 MSC (Anexo II) también
pueden realizar funciones de Nodo extremos de acuerdo a la tecnología de
transporte usada y a su vez el ALCATEL 7670 RSP (Anexo I) que puede realizar tanto
funciones de nodo interno DS, extremo DS como las de PDP del dominio, que es el
único capaz de administrar políticas remotas.
3.1.3.1 El Cliente como elemento fundamental del escenario de Servicios
Diferenciados de CUBADATA.
El cliente desempeña un papel fundamental en este escenario:
• Es fuente origen y destino del servicio.
• Es quien paga el servicio.
• Establece junto al proveedor el acuerdo de nivel de servicio, SLA.
Capítulo 3: Proyecciones para la implementación de la arquitectura de Servicios Diferenciados en CUBADATA.
Página 45
Dada la importancia del cliente en la cadena de un escenario Diffserv de CUBADATA,
es lógico que se deba de estar estrechamente vinculado con las necesidades y
proyecciones técnicas de este, para que exista la mayor compatibilidad posible entre
las tecnologías que interactúan en la red.
Como principales clientes de CUBADATA y posibles necesitados de garantía de QoS
están:
• ISPs Nacionales
o ENET
o TDATA
o CITMATEL
o COPEXTEL COLOMBUS
• Redes Corporativas
o CIMEX
o BFI
o CUBALSE
• ISP del Sector de la Salud
o INFOMED
Todos estos clientes exceptuando COPEXTEL COLOMBUS trabajan sobre plataforma
CISCO en sus routers, líder mundial en este equipamiento, y el cambio en su
tecnología para soportar QoS, específicamente Servicios Diferenciados, sería poco
costoso ya que tendrían que migrar solamente el sistema operativo de los routers
hacia una versión igual o superior a la Cisco IOS Software Release 12.0 [19], sin
tener que realizar grandes cambios en sus hardware, sólo cambios de memoria que
soporten las nuevas versiones del sistema operativo.
Esto es importante ya que el cliente puede desempeñar funciones de Nodo DS
extremo en el dominio DS CUBADATA, o sea puede realizar funciones de clasificación
de paquetes IP, utilizando el campo DSCP de acuerdo al SLA establecido con la red.
Capítulo 3: Proyecciones para la implementación de la arquitectura de Servicios Diferenciados en CUBADATA.
Página 46
3.2 Clases y diferenciación de servicios en los nodos de la Red Pública
de Transmisión de Datos.
La clasificación de los paquetes de calidad de servicio IP en los nodos ALCATEL 7670
RSP, ALCATEL 7470 MSP y ALCATEL 7270 MSC por medio de la tarjeta de servicios
IP, permite ofrecer Servicios Diferenciados.
La clasificación de los paquetes de clases de servicio (CoS) en los nodos antes
mencionado, permite proveer Servicios Diferenciados. La diferenciación de servicios
se brinda a través de la clasificación de los servicios en las colas de salida para cada
clase de servicio, utilizando un circuito virtual independiente para cada interfase,
cada circuito virtual se asocia con uno o más Clases CoS.
Existen ocho niveles de CoS los cuales se enumeran del 1 al 8 de mayor a menor
prioridad, del 1-8 son usados para tráfico de datos y el CoS 2 para el control de
tráfico [43].
3.2.1 Diferenciación de servicios.
El Cos asociado con cada paquete es obtenido por la clasificación de paquetes. El
método de clasificación de paquetes determina el CoS en el ingreso del tráfico.
Cuando es determinado el CoS del paquete, este es colocado en la cola de salida CoS
correspondiente y estas colas de salida serán serviciadas en forma justa.
Existen en la red de nodos ALCATEL tres niveles de clasificación de paquetes para
brindar diferenciación de servicio:
• Circuitos virtuales
• Clasificación de interfase
• Clasificación DSCP
Capítulo 3: Proyecciones para la implementación de la arquitectura de Servicios Diferenciados en CUBADATA.
Página 47
3.2.2 Clasificación de los paquetes.
Toda la clasificación de paquetes ocurre al ingreso de la interfase de servicio en la
red. Los circuitos virtuales en las interfases de servicios son asociados con los valores
CoS.
La clasificación de los paquetes es aplicada a las cadenas de paquetes IP. El método
de lo clasificación de paquetes es configurable en cada interfase de servicio a través
de tres métodos de clasificación de paquetes:
• Clasificación de circuito virtual de ingreso: Este es el método de clasificación
por defecto. Al paquete se le asigna el menor CoS asociada con el circuito
virtual de ingreso.
Esta usa hasta un máximo de 4 circuitos virtuales en cada interfase. Cada
circuito virtual se asocia con uno o más CoS. En el ingreso por defecto los
paquetes son clasificados con la menor prioridad de CoS asociada con el
circuito virtual de ingreso y se debe configurar diferentes parámetros de
tráficos en cada circuito virtual de forma independiente.
• Clasificación de la interfase de servicio: En la clasificación de la interfase de
servicio todos los paquetes que arriban a una interfase le son asignados el
valor del CoS de la interfase. El valor de clase de servicio por defecto es ocho.
• Clasificación de la interfase de servicio DSCP: La clasificación de los paquetes
es basada en los bits de cabecera IP, DSCP. La clasificación de los paquetes
ocurre en el ingreso solamente, en la salida se soporta la remarcación de los
paquetes DSCP el que se puede habilitar o deshabilitar en cada interfase. Por
defecto esta deshabilitado.
La clasificación de paquetes ocurre sólo al ingreso de estos en la salida ocurre la
remarcación del campo DSCP, la remarcación puede o no habilitarse en cada
interfase.
Capítulo 3: Proyecciones para la implementación de la arquitectura de Servicios Diferenciados en CUBADATA.
Página 48
Se pueden configurar en la ISC diferentes parámetros de tráfico para permitir la
diferenciación de servicios por cada circuito virtual, por lo que cada CoS es asociado
a una categoría de servicio en tráfico ATM [43], ver tabla 3.1.3.2.1.
CoS for virtual circuit Service category
CoS 1 and CoS 2 rt-VBR
Cos 3 and CoS 4 nrt-VBR
CoS 5, 6 and 7
CoS 8 UBR
Tabla 3.1.3.2.1 Asociación de CoS a categoría de servicio ATM.
3.2.3 IP DSCP.
El campo DSCP en la cabecera IP es usado por el módulo de clasificación de
paquetes para mapear el DSCP por clase de servicio, con un grupo de PHB selector
de clases.
Si se elige usar el método de clasificación de paquetes, todos los paquetes IP son
clasificados de acuerdo al campo DSCP. Si al contrario no es elegida el campo de
diferenciación de servicios es ignorado y la CoS asociada con el paquete es tratada
utilizando los métodos de clasificación de la interfase de servicio o la clasificación de
circuito virtual de ingreso.
Cada interfase de servicio está asociada a uno de los 16 perfiles de Servicios
Diferenciados (16 SLA permitidos), distribuido en 8 grupos de PHB asociados a cada
DSCP, que además pueden ser configurados en la tarjeta de servicios IP (IP Service
Card, ISC). Esta distribución es usada por la interfase para determinar cual CoS
asignar al paquete, si el método de clasificación es por IP DSCP. Por defecto el perfil
de Servicios Diferenciados 1 no es configurable.
Los 16 perfiles de Servicios Diferenciados se pueden utilizar tanto para la clasificación
como para el remarcado de DSCP. Cuando los paquetes son recibidos en una
interfase de servicio con DSCP habilitado, los paquetes son mapeados a un CoS
Capítulo 3: Proyecciones para la implementación de la arquitectura de Servicios Diferenciados en CUBADATA.
Página 49
basado en los codepoint de Servicios Diferenciados y colocados en la cola de salida
correspondiente.
3.2.4 Remarcación de salida del campo DSCP.
Se puede cambiar o remarcar el valor del DSCP de un paquete para reflejar la
relación entre los valores del CoS y el DSCP sobre la salida de la interfase de
servicio. Son 16 perfiles de remarcación. Cada interfaz de servicio en el ISC está
asociada con un perfil. Los perfiles de remarcación consisten en un mapeo entre el
CoS y los valores de DSCP. Cuando el paquete es reenviado en una interfase de
salida, los valores de DSCP se sobrescriben con un nuevo valor desde el perfil de
remarcación de Servicios Diferenciados. Esta funcionalidad asegura compatibilidad
entre los productos IP con diferentes asociaciones DSCP a CoS.
El perfil de remarcación de Servicios Diferenciados por defecto está asignado al
perfil 1 de remarcación de Servicios Diferenciados y no es configurable. La tabla
3.2.4.1 lista este perfil:
DSCP IP precedence field Cos
000xxx Routine 8
001xxx Priority 7
010xxx Immediate 6
011xxx Flash 5
100xxx Flash Override 4
101110 CRITIC/ECP 1
101xxx - 1
11x000 Internetwork Control 1
11xxxx Network Control 1
Tabla 3.2.4.1 Perfil de remarcación por defecto.
3.2.5 CoS NULO.
La tarjeta de servicios IP soporta un CoS extra para ser usado en un perfil de
Servicios Diferenciados. Cuando existen tipos de tráfico con un valor particular de
Capítulo 3: Proyecciones para la implementación de la arquitectura de Servicios Diferenciados en CUBADATA.
Página 50
DSCP que pudieran ser descartados, se le aplica el CoS NULO que no es más que
aplicarle el PHB por defecto a la interfase del perfil de Servicios Diferenciados,
comportamiento “Best Effort”. Los paquetes clasificados con un CoS NULO pueden
ser descartados y no retornan mensajes a la dirección fuente. El CoS NULO es
solamente aplicable si la clasificación del DSCP es realizada por el método de
clasificación de una interfase de servicio.
3.2.6 Servicio de cola de salida a nivel de paquete.
Todos los paquetes clasificados que requieren reenvío son colocados en una de las 8
colas de salida. Cuando una interfase en el ISC tiene un paquete clasificado que
necesita ser reenviado, este es colocado en cola CoS apropiada.
La cola CoS 1 es atendida primero y ningún otro paquete CoS es atendido hasta
tanto la cola CoS 1 reenvíe sus paquetes. Las otras colas CoS (2 a 8) son atendidas
de forma justa e intercalada. Las colas de mayor prioridad tienen más paquetes
atendidos que las de menor prioridad.
3.2.7 Reenvío de CoS.
Para que una interfase sea considerada operacionalmente en alta, los 8 CoS deben
tener un circuito virtual conectado a la interfase, si un circuito virtual no está
conectado y la interfaz está declarada en baja, el paquete es descartado. Cada
interfase puede tener un máximo de 4 circuitos virtuales. Los 8 CoS deben ser
distribuidos entre los 4 circuitos virtuales. No se pueden configurar múltiples circuitos
virtuales para un solo CoS.
3.3 Proyecciones e inversiones futuras de CUBADATA.
CUBADATA como red pública de transmisión de datos perteneciente a ETECSA, rige
su planificación estratégica e inversionista teniendo en cuenta las líneas trazadas por
el Ministerio de la Informática y las Comunicaciones, MIC, la cual esta encaminada
hacia una estructura donde convivan:
• Las Redes Corporativas
Capítulo 3: Proyecciones para la implementación de la arquitectura de Servicios Diferenciados en CUBADATA.
Página 51
• Un ISP Comercial
• Un ISP Social
Y como funciones principales ETECSA debe proveer acceso y transporte de datos a
estos 3 tipos de clientes y los que se deriven de ellos, como se muestra en la figura
3.3.1.
Para dar respuesta a todas las futuras demandas de servicio, la mayoría de estos con
fuentes de tráficos necesitados de tratamientos de QoS, se prevé un despliegue
hacia algunas cabeceras provinciales de equipamiento ALCATEL 7670 RSP y tanto en
las cabeceras municipales como en algunas localidades de una infraestructura a base
de tecnología ALCATEL 7301 Advanced Services Access Manager (Anexo III) y
HUAWEI Quidway A8010 Mini-Expert (Anexo IV) y de un Datacenter con funciones
de ASP y de Web Hosting.
Figura 3.3.1 Plataforma futura de CUBADATA.
Todo el equipamiento proyectado a instalarse soporta funciones de garantía de QoS.
Capítulo 3: Proyecciones para la implementación de la arquitectura de Servicios Diferenciados en CUBADATA.
Página 52
3.4 Conclusiones parciales.
Se pudo determinar que CUBADATA puede ofertar calidad de servicio y en especial
Servicios Diferenciados con mínimas inversiones dado que se proyecta hacia la
implementación de muchos y variados nuevos servicios que no entran en
contraposición con la propuesta realizada y que los clientes principales de la red,
realizando pequeñas inversiones pudieran insertase en la plataforma de Servicios
Diferenciados propuesta.
Conclusiones
Página 53
Conclusiones
La gran popularidad de Internet ha hecho que las redes IP se conviertan en la vía
más utilizada de transporte de información. Esto, a su vez, ha favorecido el rápido
crecimiento de la red en cuanto a número de usuarios, número de enlaces y ancho
de banda, dispositivos que la forman, velocidad de conmutación, y otros etc. Por otra
parte, este mayor uso de la red, junto a las mejoras tecnológicas que aparecen
constantemente, hace posible el planteamiento de nuevos servicios y aplicaciones,
que requieren mayores niveles de calidad de servicio (Quality of Service, QoS) que
los ofrecidos actualmente.
En el trabajo se han analizado las capacidades del modelo de Servicios Diferenciados
y las posibilidades para su implementación en la Red Pública de Transmisión de
Datos. De este análisis se determina que los Servicios Diferenciados constituyen un
modelo que brinda varias ventajas en cuanto a la facilidad y bajos costos en su
posible implementación en CUBADATA, pues solo se requeriría establecer el tipo de
tarifa a aplicar para este tipo de servicios y negociar los Acuerdos de Nivel de
Servicio con los clientes.
Dado las características actuales de la red en cuanto a escalabilidad, flexibilidad y
robustez, basada en tecnología de última generación como son ALCATEL 7670 RSP,
ALCATEL 7470 MSP y ALCATEL 7270 MSC, se facilitaría establecer un dominio común
Diffserv para todo tipo de aplicaciones y clientes, permitiendo establecer niveles de
QoS extremo a extremo, dado a que CUBADATA es la única red con la concesión de
la transmisión da datos publicas en el país.
Se pudo determinar que aunque algunas redes de usuarios de CUBADATA no
cumplen con los requisitos de equipamiento para la implementación de QoS, los
principales clientes han establecido una plataforma tecnológica a base de routers
CISCO que le s permite, con pequeñas inversiones, encontrarse en condiciones de
explotar las ventajas de una red IP con QoS.
Recomendaciones
Página 54
Recomendaciones
Para dar continuidad a los objetivos del trabajo, se recomienda:
• Desarrollar un futuro trabajo que de continuidad a los temas de QoS en
CUBADATA, donde se trate con mayor amplitud el tema de las diferentes tarifas
para el futuro servicio IP con QoS.
• Aplicar el modelo de Servicios Diferenciados como solución a la provisión de
calidad de servicio en la red CUBADATA, lo que permitiría un mejor
aprovechamiento de los recursos de la misma, redundando en mayores
posibilidades de incremento de clientes y de servicios en la propia red.
Referencias Bibliográficas
Página 55
Referencias Bibliográficas
[1]. ALCATEL, “7470, 7670, 7270-ETECSA training”, ALCATEL; 2000.
[2]. Almquist P., “Type of Service in the Internet Protocol Suite”, RFC-1349, July 1992.
[3]. Awduche D., Hannan A., Xiao X., “Applicability Statement for Extensions to RSVP for LSP-Tunnels”, RFC-3210, December 2001.
[4]. Awduche D., Chiu A., Elwalid A., Widjaja I., Xiao X., "A Framework for Internet Traffic Engineering", RFC-3272, May 2002.
[5]. Azcorra E., Hernández-Valencia J., J. Berrocal, D. Larrabeiti, “IP/ATM Integrated services over Broadband Access Copper Technologies”, IEEE Communications Magazine, vol. 37, May 1999, pp. 90-97.
[6]. Baker F., “Requirements for IP Version 4 Routers”, RFC-1812, June 1995
[7]. Baker F., Chan, K. and Smith, A. “Management Information Base for the Differentiated Services Architecture”, RFC-3289, May 2002.
[8]. Barford P., Crovella M., “Generating Representative Web Workloads for Network and Server Performance Evaluation”, in Joint International Conference on Measurement and Modeling of Computer Systems - Performance Evaluation Review, 1998, pp. 151-160.
[9]. Berger L., Gan D., Swallow G., P. Pan, F. Tomáis, S. Molendini, “RSVP Refresh Overhead Reduction Extensions”, RFC-2961, April 2001.
[10]. Bernet Y. , “A Framework for Integrated Services over DiffServ Networks”, RFC-2998, November 2000.
[11]. Blake S., Black D., Carlson M., E. Davies, Z. Wang, W. Weiss, “An Architecture for Differentiated Service”, RFC-2475, December 1998.
[12]. Black D., “Differentiated Services and Tunnels “, RFC-2983, October 2000.
[13]. Black D., Brim S., Carpenter B., F. Le Faucheur, “Per Hop Behavior Identification Codes”, RFC-3140, June 2001.
[14]. Braden R, E., L. Zhang, S. Berson, S. Herzog, S. Jamin, “Resource ReSerVation Protocol (RSVP) – version 1 functional specification,” RFC-2205, September 1997.
[15]. Borden M., Crawley E., Davie B., Batsell S., "Integration of Real-time Services in an IP/ATM Network Architecture", RFC-1821, August 1995.
[16]. Céspedes L., “Metodologías de diseño de Redes Corporativas Frame Relay”; Tesis de maestría, ISPJAE; 2001.
Referencias Bibliográficas
Página 56
[17]. Chagnot G. and Lynge M., ”VPN is anything but virtual” Spirent Communications Magazine ; 2000.
[18]. Chen Z., S. M. Tan, R. H. Campbell, and Y. Li. “Real Time Video and Audio in the World Wide Web”. World Wide Web Journal, vol. 1, 1996.
[19]. Cisco IOS Software Release. “Cisco IOS Software Release 12.0 Mainline”, Cisco System; 2004.
[20]. Comer, Douglas E. "Internetworking with TCP/IP - Principles, Protocols and Architecture". Prentice Hall, 1995. ISBN 0-13-018380-6.
[21]. Consejo de Ministros, ”Decreto 275 – Concesión a ETECSA”, Cuba: La Gaceta Oficial Nº 21, 2003, ISSN 1682-7511; Diciembre 2003. http://www.gacetaoficial.cu/pdf/GO_X_21_2003.zip
[22]. Crovella M., Bestavros A., “Explaining World Wide Web traffic selfsimilarity”, Computer Science Dept., Boston Univ., Tech Rep. TR-95-015. October 1995.
[23]. Cruz R., “Redes de comunicación de banda ancha”, Maestría en Teleinformática, Trabajo Extraclase, Universidad Autónoma de Nuevo Leon (UANL), Julio 2003.
[24]. Davis B., ”IP-VPN Transport over a Multiservice Network”; 2001. http://www.securitytechnet.com/resource/rsc-center/presentation/webtorial/ recent/ipvpn.pdf
[25]. Davie B., Lawrence J., McCloghrie K., E. Rosen, G. Swallow, Y. Rekhter, P. Doolan, “MPLS using LDP and ATM VC Switching”, RFC-3035, January 2001.
[26]. Davie B., Charny A., Bennett J.C.R., K. Benson, J.Y. Le Boudec, W. Courtney, S. Davari, V. Firoiu, D. Stiliadis , “An Expedited Forwarding PHB (Per-Hop Behavior)”, RFC-3246, March 2002.
[27]. Downing R.A., ”Frame Relay + MPLS”, Security Tech; 2001. http://www.securitytechnet.com/resource/networking/qos/downing-mpls.pdf
[28]. Durham D., Boyle J., R. Cohen, S. Herzog, R. Rajan, Sastry A. “The COPS (Common Open Policy Service) Protocol”, RFC-2748, January 2000.
[29]. Escribano J., ”Diseño e implementación de un entorno Diffserv”; Proyecto de fin de carrera, Universidad Carlos III Madrid; Diciembre 2001.
[30]. ETECSA. ”Guía de los Servicios de Infocomunicaciones, Transmisión de Datos e Internet”, ETECSA; 2002. http://www.infocom.etecsa.cu
[31]. Fineberg V., “A Practical Architecture for Implementing End-to-End QoS in an IP Network”, IEEE Communications Magazine, pp. 122-130, January 2002.
Referencias Bibliográficas
Página 57
[32]. Giordano S., Salsano S., Van den Berghe S., G. Ventre and D. Giannakopoulos, “Advanced QoS Provisioning in IP Networks: The European Premium IP Projects”, IEEE Communications Magazine, pp. 30-36, January 2003.
[33]. Guijarro L., “Redes ATM, principios de interconexión y su aplicación”, Alfaomega, pp- 118- 121, 2000.
[34]. Gray E.W., “Multi-Protocol Label Switching: Implementing the technology”. Addison-Wesley ISBN 0-201-65762-7; Marzo 2001.
[35]. Grossman D., “New Terminology and Clarifications for Diffserv”, RFC-3260, April 2002.
[36]. Heinanen J., “Multiprotocol Encapsulation over ATM Adaptation Layer 5”, RFC-1483, July 1993.
[37]. Heinanen J., Baker F., Weiss W., J. Wroclawski, “Assured Forwarding PHB Group”, RFC-2597, June 1999.
[38]. Jacobson B., Nichols K., K. Poduri, “An Expedited Forwarding PHB”, RFC-2598, June 1999.
[39]. Laubach M., "Classical IP and ARP over ATM", RFC-1577, January 1994.
[40]. Mañas J., “Introducción a los secretos de internet y las redes de datos”, Mundo IP, pp- 103- 120, Marzo 2004.
[41]. McGuire R.E., ”Frame Relay VPNs & IP VPNs”, PraDyne; 2000. http://paradyne.com
[42]. McDysan D., “QoS and Traffic Management in IP and ATM Networks”, McGraw-Hill, 2000.
[43]. Newbridge Network Corporation, “MainstreetXpress 36170, Multiservicies Switch- Release 4.2 Generic A21214, IP Service Card Technical Reference”, Newbridge; 2000.
[44]. Nichols K. et al., “Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers”, RFC-2474, December 1998.
[45]. Nichols K., Carpenter B., “Definition of Differentiated Services Per Domain Behaviors and Rules for their Specification”, RFC-3086, April 2001.
[46]. Perez M., Liaw F., Grossman D., A. Mankin, E. Hoffman, A. Malis, “ATM Signaling Support for IP over ATM”, RFC-1755, February 1995.
[47]. Postigo-Boix M., García-Haro J., M. Aguilar-Igartua, “Cost Minimization Study of Semi-Elastic Flows Using Internet”, en Proceedings of the IEEE International Conference on Communications 2002, New York, USA, Abril 2002, pp. 2237-41.
Referencias Bibliográficas
Página 58
[48]. Roberts J., “Quality of Service Guarantees and Charging in Multi-service Networks”, IEICE Transactions on Communications, May 1998.
[49]. Rosen E., Viswanathan A., Callon R., “Multiprotocol Label Switching Architecture”, RFC-3031, January 2001.
[50]. Shenker S., Wroclawski J., "General characterization parameters for integrated service network elements". RFC-2210, 1997.
[51]. Shenker S., Wroclawski J., “General Characterization Parameters for Integrated Service Network Elements”, RFC-2215, 1997.
[52]. Shenker S., Partridge C., Guerin R. "Specification of Guaranteed Quality of Service". RFC-2212, 1997.
[53]. Stardust. White Paper – The Need for QoS. July 1999. http://www.stardust.com
[54]. UIT, “Redes basadas en el protocolo Internet: Tarificación de los servicios de telecomunicaciones”, Enero 2003.
[55]. Van de Meent R. Prototyping the DiffServ MIB. Internet NG Work Unit 2 Deliverable D2.15.pags 18,45.
[56]. Walsh M., “Examining the Opportunities for Frame Relay and IP Internetworking”; 2002. http://www.fatpipeinc.com/mpfr/mpfrwp.pdf
[57]. Wang X., Schulzrinne H., “An Integrated Resource Negotiation, Pricing, and QoS Adaptation Framework for Multimedia Applications”, Journal of Selected Areas in Communications, Vol. 18, Num. 12, pp. 2514- 29, December 2000.
[58]. Wroclawski J., "Specification of controlled-load network element service". RFC-2211, 1997.
[59]. Xedia Corporation. “QVPN: Quality of Service in Virtual Private IP Network”, Internetwk; 2002. http://www.internetwk.com/VPN/Xediapaper.htm
[60]. Xiao X., Ni L. "Internet QoS: A Big Picture", IEEE Network Magazine, Marzo/Abril, pp. 8-18, 1999.
[61]. Xiao X., “Providing quality of service in the internet”, Philosophy Doctor Degree Thesis, 2000.
[62]. Xiao X., Telkamp T., Fineberg V., C. Chen, and L. M. Ni, “A Practical Approach for Providing QoS in the Internet Backbone”, IEEE Communications Magazine, pp. 56-62, December 2002.
Glosario de Términos
Página 59
Glosario de Términos
A
ABR Available Variable Bit Rate
AF PHB Assured Forwarding PHB
ASAM Advanced Services Access Manager
ASP Aplication Service Provider
ATM Asynchronous Transfer Mode
B
BA behaviour aggregates
BB Bandwidth Broker
BPS Bit per seconds
C
CBQ Class Based Quering
CBR Constant Bit Rate
COPS Common Open Policy Service
COS Class of Service
D
Diffserv Differentiated Services
DS Differentiated Services
DSCP Differentiated Services Code Point
DSL Digital Subscriber Line
E
Glosario de Términos
Página 60
E1 2Mbps
E3 34Mbps
EF PHB Expedited Forwarding PHB
ETECSA Empresa de Telecomunicaciones de Cuba, SA
F
FON Fibra Óptica Nacional
FR Frame Relay
H
HDLC High-level Data Link Control
I
IETF Internet Engineering Task Force
Intserv Integrated Services
IP Internet Protocol
ISC IP Service Card
ISP Internet Service Provider
L
LAN Local Area Network
LPDP Local PDP
M
MF Multifield
MIC Ministerio de la Informática y las Comunicaciones.
MPLS Multiprotocol Label Switching
Glosario de Términos
Página 61
MSC Multiservice Concentrador
MSP Multiservice Platform
MTU Maximum Transmisión Unit
N
NRT-VBR Non-Real-Time Variable Bit Rate
P
PDP Policy Decision Point
PEP Policy Enforcement Points
PHB Per-Hop Behavior
PPP Point-to-Point Protocol
Q
QoS Quality of Service
R
RFC Request for Comments
RSP Routing Switch Platform
RSVP Resource Reservation Protocol
RT-VBR Real-Time Variable Bit Rate
S
SLA Service Level Agreement
STM1 155Mbps
STM4 622Mbps
T
TC Traffic Conformation
Glosario de Términos
Página 62
TCA Traffic Condicioning Agreement
TOS Tipe of Service
V
VoIP Voice over IP
VPN Virtual Private Network
W
WAN Wide Area Network
Anexo I: ALCATEL 7670 Plataforma de Enrutamiento y Conmutación
Página 63
Anexo I. ALCATEL 7670 RSP
Optimizado para las nuevas generaciones de redes
multiprotocolos y multiservicios, en un sistema donde
han sido integrados los planos de control IP/MPLS y
ATM.
Características principales del equipamiento ALCATEL 7670 RSP [1]:
Característica Beneficio
Escalabilidad en servicio de 2,4 Gb/s y cerca de 450 Gb/s en el núcleo.
Alta densidad de interfases de línea
Inigualable portador de
clases de funcionamiento y
escalabilidad Prestaciones de envíos de datos a 610 Mbps.
Conjunto de procesadores redundantes especializados para una serie
completa de funciones del plano de control, incluyendo:
-Protocolos de ruteo BGP-4, IS-IS, OSPFv2
-Señalización LDP-DU y RSVP-TE
-Ampliaciones TE para IS-IS y OSPF
Ocho clases de servicio (CoS) de nivel de sistema IP definidas por el
usuario con correspondiente calidad de servicio (QoS)
Conjunto superior de
facilidades IP
Soporte de Diffserv
IP
PPP
Ethernet
Frame Relay
Cell Relay
g.SHDSL
Voz
Soporte para interfases de
datos multiservicio de baja
velocidad
Líneas Privadas
Ocho categorías de servicios, con múltiples clases QoS por categoría
de servicio
Garantía absoluta de CoS y QoS para todas las conexiones
Acuerdos de nivel de
servicio (SLAs) basados en
QoS asegurados Habilitación de diferenciación de servicios basada en categoría de
servicios y CoS o QoS.
Anexo II: ALCATEL 7470 Plataforma Multiservicio y ALCATEL 7270 Concentrador Multiservicio
Página 64
Anexo II. ALCATEL 7470 MSP y ALCATEL 7270 MSC
Tanto el ALCATEL 7470 MSP como el
ALCATEL 7270 MSC son parte de la
carpeta de productos ALCATEL para la
plataforma de red multiprotocolo y
multiservicio.
Características principales del equipamiento ALCATEL 7470 MSP y ALCATEL 7270
MSC [1]:
Característica Beneficio
Su plataforma puede ir desde un único bastidor a un sistema multiservicio y
multibastidor
Escalabilidad y
flexibilidad
Las ranuras universales para placas, permiten instalar una mezcla de
interfases o tarjetas de servicio basadas en las necesidades de negocio
Proporciona una evolución sencilla hacia los nuevos servicios de banda
ancha
Nuevas capacidades
de servicio
Ofrece servicios IP que aprovechan las probadas capacidades de gestión de
tráfico de los productos ALCATEL.
Frame Relay
Líneas Privadas
Cell Relay
IP
Ethernet
Servicios y
aplicaciones
Agregación de accesos de banda ancha
Proporciona diferenciación de servicio a través de capacidades de QoS
mejoradas Direccionamiento de
tráfico Garantiza el cumplimiento de los SLA, proporcionado satisfacción al cliente
Fiabilidad Reduce la posibilidad de interrupción del servicio en la red
Conformidad e
interoperatibilidad
estandarizadas
Presenta soluciones abiertas hechas para ser integradas fácilmente con las
redes existentes
Anexo III: ALCATEL 7301 Administrador de Acceso de Servicios Avanzados
Página 65
Anexo III. ALCATEL 7301 ASAM
El ALCATEL 7301 ASAM es la respuesta para el despliegue de la
banda ancha sobre las redes de cobre, ofreciendo múltiples clases
de servicio de DSL.
El ALCATEL 7301 ASAM usa Tecnología de DSL para entregar
accesos y servicios de banda ancha sobre el cableado telefónico
actual y/o terminaciones de fibra.
Características principales del equipamiento ALCATEL 7301 ASAM:
Característica Beneficio
ADSL
G.lite
G.shdsl
VDSL
READSL2
ADSL2
Variados tipos de
interfases DSL
ADSL2+
STM4-622 Mbps
STM1-155 Mbps
4xSTM1
E3
E1
Soporta gran
variedad de
interfases
Gigabit Ethernet
ATM
-Soporte de agregación de circuito virtual (VC)
-Circuitos virtuales conmutados (SVCs)
IP Multicast
Redes privadas virtuales (VPNs)
MPLS
Características
avanzadas
Múltiples niveles de QoS
Anexo IV: Huawei Quidway A8010 Mini-Expert
Página 66
Anexo IV. HUAWEI Quidway A8010 Mini-Expert.
Huawei Quidway A8010 Mini-Expert esta
diseñado expresamente para proveedores de
servicio de Internet (ISPs), proveedores de
transporte de datos y redes privadas,
ayudando a estructurar rápidamente mediante
costos efectivos, redes de VoIP o redes de acceso remoto.
Características principales del equipamiento Huawei Quidway A8010 Mini-
Expert:
Característica Beneficio
Accesos Dial-up (ISDN/Modem/WAP)
Voz sobre IP (VoIP)
Fax sobre IP (FoIP)
Redes privadas virtuales (VPN)
Multienlaces PPP
Llamada en espera
Call Back
Servicios
RADIUS PROXY
Hacia la central:
Interfases E1/T1
Hacia la red:
10/100 Base-T Ethernet
E3 ATM
E1 FR/PPP/HDLC
Variedad de
interfases
V.35 FR/PPP/HDLC