Proyecciones para la implementación de Servicios ...

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


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


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


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


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


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


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


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


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


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.


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.


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.


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,


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


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.


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


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


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.


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


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.


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.


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


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


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


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.


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


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


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.


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


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:


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


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.


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.


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


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.


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


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


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


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.


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


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


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.


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.


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.


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


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.


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


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


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


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.


Página 52


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


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


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.


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.


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


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


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


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


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


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:


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:


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

Proyecciones para la implementación de Servicios ...

Documents

Transcript of Proyecciones para la implementación de Servicios ...