La actual demanda de aplicaciones relacionadas con información

multimedia, como son la video-conferencia, audio-conferencia, video bajo

demanda (VoD) o sistemas cooperativos (pizarras compartidas, teletrabajo,
telemedicina, etc.) y su coexistencia con aplicaciones más clásicas (bases de
datos, transferencias de ficheros, WWW, etc.), requieren tecnologías de
comunicaciones capaces de ofrecer elevadas prestaciones.

Hace pocos años, debido básicamente a la baja capacidad de las redes,

la posibilidad de llevar a cabo cualquiera de las aplicaciones referenciadas
anteriormente era prácticamente impensable, pero en estos momentos es una
realidad. Se ha avanzado mucho en compresión de audio y vídeo, y en
tecnologías de redes. Aún así, quizás el mayor avance haya sido el auge de
Internet y la capacidad de conectarse desde casa utilizando únicamente un
ordenador personal y un módem.

Afortunadamente, en la actualidad se están implantando nuevas

tecnologías de fibra óptica que proporcionan el gran ancho de banda requerido
por las aplicaciones anteriores, pero no basta solo con el aumento del mismo,
es necesario gestionarlo de manera eficiente: utilizarlo en un porcentaje
elevado asegurando una calidad determinada. Esto es lo que se conoce como
calidad de servicio (QoS).

Hasta hace poco este término no era importante en la mayoría de los

sistemas. Para comprobarlo tan solo tenemos que pensar en los algoritmos que
se usan actualmente en la transmisión de paquetes por la red (pensar en el
sistema Best Effort utilizado en Internet), estos algoritmos suelen garantizar la
llegada de todos los paquetes, pero no dan ninguna cota respecto al límite de
su llegada a destino. Esta forma de transmisión es buena para muchas
aplicaciones, como por ejemplo la transmisión de ficheros (FTP), la navegación
por el Web, el correo electrónico, donde lo importante es que los datos lleguen
correctamente. Para el tráfico en tiempo real, en cambio, los datos necesitan
llegar a su destino en un tiempo determinado, ya que tardar un poco más
implica que la aplicación se detendría por falta de datos, lo cual sería
inadmisible.

La mayoría de las redes de ordenadores, a excepción de ATM, no han

sido diseñadas para proporcionar implícitamente unos niveles de calidad de
servicio necesarios para la transmisión del tráfico multimedia, IP y Ethernet
ofrecen un servicio Best Effort (mejor esfuerzo) inadecuado para la excesiva
carga de las aplicaciones actuales, por lo tanto para poder soportar este tipo de
tráfico 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. En este proyecto
se van a estudiar las diferentes técnicas y políticas utilizadas, permitiendo
realizar una comparativa y la elección de la opción más conveniente a utilizar
para cada caso.
El objetivo principal del proyecto es, por lo tanto, el realizar un estudio de
las distintos protocolos, arquitecturas y mecanismos para la obtención de
calidad de servicio en redes.
Para conseguir dicho objetivo se va a realizar un análisis de cada una de
las tecnologías existentes, detallando cuál es el proceso y cómo es su
implementación para la obtención de tal requerimiento, analizando finalmente
en detalle los mecanismos existentes en tres de las tecnologías más utilizadas
en la actualidad: ATM, Frame Relay y Red Local IEEE 802.
Para lograr lo anterior se ha dividido el proyecto en las siguientes fases:
Recopilación de material bibliográfico: artículos de revistas, web,
monografías y normas oficiales.
Estudio y clasificación de los parámetros relacionados con la calidad de
servicio.
Estudio de los distintos protocolos y arquitecturas para la obtención de
QoS. Análisis de su funcionamiento.
Estudio de la obtención de QoS en diversas tecnologías de red.
Visualización de un ejemplo real de aplicación de diferentes técnicas
para la obtención de QoS.
En las siguientes páginas se describen con más detalle las distintas
fases del proyecto, realizándose en cada uno de los capítulos una explicación
más exhaustiva que a modo de resumen comentamos a continuación.
El Capítulo 2 presenta una introducción al término calidad de servicio,
estableciendo una visión inicial globalizada de su significado y lo que implica su
aplicación en la tecnologías de redes existentes, para conseguirlo se va a
realizar un estudio de todos aquellos parámetros implicados en su obtención,
permitiendo, a su vez, realizar una clasificación y comprender las ventajas de
su implementación.
En el Capítulo 3 se presentan los mecanismos y/o herramientas
utilizadas para la obtención de calidad de servicio como son las técnicas de
control y prevención de congestión, el priorizar el tráfico, clasificar paquetes,
marcarlos y el uso de mecanismos de señalización.
El Capítulo 4 describe la importancia de gestionar los diferentes recursos
de la red para la obtención de calidad de servicio. Es lo que comúnmente se
conoce como gestión de políticas, en la que las grandes empresas del mundo
del networking han estado trabajando durante los últimos años para poder
suministrarla.
El Capítulo 5 describe cada uno de los protocolos existentes para
proporcionar calidad de servicio, explicando si estos utilizan técnicas de
señalización, de priori-zación mediante etiquetas, así como otras técnicas allí
referenciadas. Será en este capítulo donde términos como RSVP, Diffserv,
MPLS, SBM, tan comunes dentro del estudio de QoS, quedarán aclarados.
En el Capítulo 6 se expone cómo es posible obtener calidad de servicio
en el Modo de Transferencia Asíncrono (ATM) de una forma genérica que nos
permita entender su obtención en esta tecnología.
En el Capítulo 7, análogamente que en el 6, se realiza una descripción
de cómo obtener QoS en Frame Relay. Es una descripción genérica que nos
permitirá entender cómo se consigue, pues introducirse más en su
funcionamiento, al igual que para el capítulo anterior, podría convertirse en otro
proyecto.
En el Capítulo 8 se explica detalladamente el funcionamiento del
estándar IEEE 802.1p que permite dar prioridad al tráfico y filtrar el tráfico
Multicast (grupos) de forma dinámica para redes 802. Puede diferenciar entre 8
tipos de clases de tráfico clasificados como “prioridades de usuario”
(user_priority) por cada puerto del puente, siendo el rango de valores de
prioridad de usuario del 0 al 7.
En el Capítulo 9, finalmente se expondrá un ejemplo práctico de
aplicación de algunas de las tecnologías y herramientas explicadas en los
capítulos anteriores, lo que permitirá entender mejor su funcionamiento y
visualizar cuál es la realidad de la calidad de servicio en una red de una
empresa cualquiera.
En el Capítulo 10 se presentan las conclusiones obtenidas y el posible
trabajo a realizar en un futuro.
Finalmente, se adjuntan los apartados de Bibliografía, Referencias y
listado de Acrónimos dentro del Capítulo 11, al que será necesario acudir para
la aclaración de algunas referencias citadas a lo largo del proyecto y para la
obtención de una mayor información sobre algunos apartados del mismo.
 A continuación se va a presentar una introducción al término calidad de
servicio (QoS) estableciendo una visión inicial de lo que implica su aplicación
en la tecnologías de redes existentes. Para conseguirlo se va a realizar un
estudio de todos aquellos parámetros implicados en su obtención, permitiendo,
a su vez, realizar una clasificación, comprender las ventajas de su
implementación y observar los avances propuestos por las empresas al
respecto.

1 Historia

Hubo que esperar a los felices 80 para el encuentro de inventos como la

Alto Alhoa Network de Bob Metcalfe y Boggs, luego convertida en Ethernet y
aplicada por la empresa 3Com en la primera LAN [1], con la informática personal
primero apuntada por Apple y luego remachada por el PC de IBM. A la cita también
acudió Novell con su primer producto, Sharenet. De esta manera empezaba a
tejerse la industria del networking (término que últimamente despierta pasiones
profesionales) y, con ello, su difusión como un ingrediente más de los sistemas de
información.

Pero sigamos mirando a los 80, la década de Novell y del binomio de

protocolos: el CSMA/CD de las redes Ethernet y del Token Pass, en las que se
basaban las Token Ring, respaldadas por IBM.

Sin embargo, no es hasta 1985 cuando aparecen los primeros routers, con
lo que se comienza la etapa de la interconexión de redes y los pasos que llevarían
a diluir las fronteras de los entornos locales para convertirlos en globales. Pero es
en 1988 cuando el emergente networking empieza a apuntar hacia lo que sería su
consolidación y formalización como mercado y como sector. La aparición de
OpenView, la plataforma de administración y gestión de redes de Hewlett-Packard;
y del Lan Manager, el sistema operativo de red de Microsoft que sustituía al MS-
Net, hoy se perciben como relevantes acontecimientos que contribuyeron a la
expansión de las redes.

La llegada de los 90 coincidió con los balbuceos del correo electrónico y

con la mayor evolución de la tecnología Token Ring. Pero hubo que esperar hasta
1992 para observar el siguiente hito en la historia de las redes: la entrada en
escena de ATM en un conmutador para redes privadas desarrollado por Network
Equipment. Justo un año después, National Semiconductor introduce la tecnología
Isonet que, por primera vez, permite la transmisión integrada de servicios
multimedia, además de que aportaba la capacidad de soportar protocolos Ethernet
y RDSI. Con él llegaría el anuncio de la primera tecnología de alta velocidad,
denominada 100VG-AnyLAN, respaldada por Hewlett-Packard e IVEM, que tenía
como indicador más sobresaliente el que alcanzaba los 100 Mbps. Casi
simultáneamente y como respuesta directa apareció Fast Ethernet, basada en la
norma 100BaseT y capaz de aportar prestaciones similares a las de AnyLAN.

Sin embargo, no es hasta finales de los 90 cuando se desencadena el uso

y disfrute de la red, naciendo un nuevo concepto conocido como calidad de servicio
(QoS), que se ve afianzado por la incorporación de funciones de voz en redes de
datos. Es esta explosión de voz sobre IP (VoIP) la que está marcando una
tendencia capaz de elevar el protagonismo del networking.

Los años 1997 y 1998 destacan por dos características: el carácter crítico
de la gestión de redes y el refuerzo de la oferta de entornos y tecnologías de alta
velocidad basados en la conmutación de nivel 3, hasta el punto de llegar a
superarse la frontera del Megabit para entrar en los terabits por segundo, sin
olvidar xDSL (Digital Suscribers Line), WDM (Wave Data Multiplexing), canal de
fibra y Token Ring también de alta velocidad.

Durante estos últimos años también han ido ganando peso las funciones
de seguridad, entre las que se encuentran la encriptación, la autenticación de
usuarios y los firewalls.

Todas estas características no hacen sino confirmar que dentro de cinco

años la voz no consumirá más que una pequeña parte del ancho de banda y todas
las problemáticas para operadoras y responsables de sistemas estará en gestionar
adecuadamente un flujo de datos cada vez más denso y relevante. De esta
manera, las redes públicas se convierten en el elemento principal del mercado de
las comunicaciones.

Volver arriba

2 Definición de QoS

Para establecer una correcta definición del término QoS, calidad de

servicio, debemos acudir primero a estudiar la asignada por el Diccionario de la
Lengua de la Real Academia Española. Según éste, la Calidad es el “Valor
intrínseco de una cosa y el valor relativo resultante de compararla con otras de su
misma categoría”. Así mismo Servicio es “La acción y el efecto de servir. Estar
hecho para algo concreto”. Ambas definiciones llevan contenidas de forma
inherente la propiedad de comparación; por lo tanto, para determinar si un servicio
ofrece mayor o menor calidad será necesario establecer una comparación con el
resto de servicios de ese nivel.

Al tratarse la anterior de una descripción demasiado genérica, son múltiples

las definiciones concretas que actualmente se realizan sobre el término QoS, si
bien difieren en significados dependiendo del ámbito de aplicación de tales siglas.
En el ámbito de las telecomunicaciones, desde la publicación en 1984 del
documento E-800 de la UIT, no debería existir discusión posible ante su definición :
“el efecto colectivo del rendimiento de un servicio que determina el grado de
satisfacción del usuario de dicho servicio”. Es una definición comúnmente
aceptada, que no deja ninguna duda de que se trata de una percepción del
usuario, pues es éste quién, al final, establece unos requerimientos mínimos para
cualificar.

En el ámbito de la telemática, QoS es la capacidad de un elemento de

red (bien una aplicación, un servidor, un encaminador, un conmutador, etc.) de
asegurar que su tráfico y los requisitos del servicio previamente establecidos
puedan ser satisfechos. Habilitarla requiere además la cooperación de todas
las capas de la red, así como de cada elemento de la misma. Desde este punto
de vista, la QoS también suele ser definida como un conjunto de tecnologías
que permiten a los administradores de red manejar los efectos de la congestión
del tráfico usando óptimamente los diferentes recursos de la red, en lugar de ir
aumentando continuamente capacidad. En este punto es necesario prestar una
atención especial al hecho de que la QoS no crea ancho de banda.

La QoS tiene, básicamente, cuatro variantes estrechamente relacionadas:

la QoS que el usuario desea, la que el proveedor ofrece, la que el proveedor
consigue realmente y la que, finalmente, percibe el usuario. En cualquiera de ellas
existen algunos parámetros que están muy condicionados por las características
técnicas de la red soporte, y por eso el primer Informe técnico que publicó, en
1994, el ETSI fue la ETR-003, “General Aspects of Quality of Service (QoS) and
Network Performance (NP)”, atendiendo a las inquietudes surgidas en el seno de
FITCE, que tuvieron su reflejo oficial en los acuerdos de la reunión de Estrasburgo,
de 1991, poniendo en marcha los estudios que permitiesen definir los parámetros
técnicos de la red, a partir de los requisitos de los usuarios. La metodología
resultante es la que se refleja en el documento de ETSI, antes citado.
 Volver arriba

3 QoS, CoS y ToS

Son varios los acrónimos terminados en “oS” que hacen referencia a la

obtención de calidad de servicio en redes, llevando en ocasiones a situaciones
equívocas por el mal uso de los mismos, si bien QoS es el único que refiere
completamente a la Calidad de Servicio, englobando todas las técnicas que se
encuentran en torno a ella, mientras que CoS (clase de servicio) y ToS (tipo de
servicio) son, sencillamente, dos de las técnicas utilizadas para su obtención.
Veamos pues, una diferenciación más exhaustiva.

QoS : CALIDAD DE SERVICIO

Ha sido definida en el apartado anterior. Recoge varios parámetros o

atributos que describen un servicio, tales como:

Reserva ancho banda

Retardo extremo a extremo

Jitter

Tasa de error

Un ejemplo de tecnología existente que utiliza QoS es IETF RSVP,

estudiada posteriormente en el capítulo de protocolos y arquitecturas de calidad de
servicio.

CoS: CLASE DE SERVICIO

Este término implica, a su vez, dos procedimientos: en primer lugar la

priorización de los distintos tipos de tráfico claramente definidos a través de la
red y, en segundo lugar, la definición de un pequeño número de clases de
servicio a las que aplicarla.

Priorizar es importante en las puntos de congestión de la red, donde las

decisiones de priorización pueden ser realizadas por puentes y encaminadores.

Las aplicaciones que requieren distinguir clases de servicio incluyen

procesos transacionales, el vídeo y cualquier otro tráfico sensible al tiempo.
 No se debe confundir CoS con QoS, pues, a diferencia de QoS, CoS no
garantiza ancho de banda o latencia, en cambio permite a los administradores de
red solicitar prioridad para el tráfico basándose en la importancia de éste.

Independientemente de la diferenciación, tanto CoS como QoS categorizan

el tráfico para asegurar que el tráfico considerado crítico siempre fluya por la red, a
pesar del ancho de banda demandado o de las aplicaciones de menor importancia.

Existen muchas posibles definiciones de tipos de calidad de servicio, pero la

mayoría de las empresas definen las clases de tráfico por tipo de aplicación, tipo de
dispositivo o por tipo de usuario. Hoy es además posible definir clases
separadamente en routers o puentes individuales, pero suele ser poco práctico.

Un ejemplo de tecnología que usa CoS es el estándar IEEE 802.1p,

representado en la siguiente figura. Esta norma será estudiada con mayor detalle
en un capítulo posterior, al que será necesario acudir para obtener más información
sobre su forma de actuación.

Figura 1. Campos de los estándares 802.1p/Q

Como vemos, la norma IEEE 802.1p incluye un campo donde especificar la

clase de servicio, definiendo las siguientes:

Combinación CoS Prioridad

111 Network Critical 7

110 Interactive Voice 6

101 Interactive Multimedia 6

100 Streaming Multimedia 4

011 Business Critical 3

 010 Standard 2

001 Background 1

000 Best Effort 0

La siguiente figura muestra gráficamente dónde aplicar la CoS :

Figura 2. Dónde aplicar CoS

Veamos ahora el significado del tercer término.

ToS: TIPO DE SERVICIO.

El tipo de servicio es equivalente a un carril destinado a coches de uso

compartido: se reserva ancho de banda con antelación y después se asigna el
tráfico que necesite preferencia, como el de voz o un CoS con prioridad, de modo
que este tráfico pueda utilizar el ancho de banda reservado. ToS no implica, por lo
tanto, ningún tipo de garantías.

ToS está incluido como uno de los campos en la tecnología de QoS

denominada Diffserv (servicios diferenciados), dónde también es conocido como
DiffServ codepoint (DSCP o punto de código Diffserv). Es un campo de 8 bits,
estando los dos últimos reservados. Con los otros 6 bits restantes es posible
obtener 64 combinaciones o ‘codepoint’, de ellas, 48 son utilizadas para direccionar
el espacio global y 16 son para uso local.

Parte del protocolo IP Versión 4 reserva un campo en el paquete IP para el

tipo de servicio (IP TOS). En este campo se pueden especificar los atributos de
fiabilidad, capacidad de procesamiento y retardos del servicio, tal y como se ve en
la siguiente figura:

Figura 3. Campo ToS en IPv4

Habiendo diferenciado ya lo que es calidad de servicio es necesario

realizar una clasificación de la misma según distintos parámetros. En el siguiente
apartado se realiza dicha clasificación.

Volver arriba

4 Clasificación de QoS

Es posible realizar una clasificación de QoS bajo distintas

especificaciones, así podríamos diferenciarla según el tipo de tráfico, dónde
aplicarla, la reserva de recursos de la red y otros parámetros, tal y como se
indica a continuación.

4.1 Según la sensibilidad del tráfico

Teniendo en cuenta la variedad de tráfico existente y los requerimientos de

retardo, latencia y ancho de banda para cada tipo, nos encontramos con :

1. QoS muy sensible al retardo. Un ejemplo de este tipo es para el tráfico de

vídeo comprimido. Para este caso es necesario garantizar la disponibilidad de una
determinada y gran cantidad de ancho de banda reservado para este tráfico y un
valor de retardo mínimo que asegure la correcta transmisión del mismo. Para
conseguirlo será necesario utilizar mecanismos de prioridad, definidos
posteriormente en el capítulo de protocolos y arquitecturas, así como encolar
adecuadamente los flujos de datos.

2. QoS algo sensible al retardo. Como la resultante de la aplicación de la

emulación de circuito. Al igual que en el caso anterior se garantiza hasta un cierto
nivel de ancho de banda, aunque en menor valor. De la misma manera, será
necesario asignar prioridades para la transmisión de los datos.

3. QoS muy sensible a pérdidas. Como sucede con el tráfico tradicional. Si

se garantiza un nivel de pérdidas de valor cero entonces nunca se descartarán
paquetes ni se desbordarán los buffers de almacenamiento del flujo, lo que
facilitará el control de transmisión, por otra parte, esta garantía se hace a nivel de
acceso al medio (MAC) o en capas superiores, pero nunca a nivel físico.

4. QoS nada sensible. Por ejemplo el tráfico de servicios de noticias.

La filosofía de este tipo de QoS es usar cualquier oportunidad de

transmisión restante y asumir que la capacidad de los buffers posteriores es
suficiente para llevarla a cabo, asignándole a este tipo de tráfico la prioridad más
baja. A este tipo responden los algoritmos Best Effort o al mejor esfuerzo, utilizado
en Internet.

En la siguiente figura es posible diferenciar de forma gráfica los tipos de

tráfico y sus exigencias de ancho de banda y de sensibilidad a la latencia.
 Figura 4.Representación gráfica relación QoS y aplicaciones

4.2 Según quién solicite el nivel de calidad de servicio

Teniendo en cuenta que la petición de QoS puede ser realizada por el

usuario final o por los conmutadores de la red, nos encontramos con :

1. QoS IMPLÍCITA

En este tipo el router o conmutador asigna automáticamente los niveles

de calidad servicio en función del criterio especificado por el administrador,
como el tipo de aplicación, protocolo o dirección de origen.

Hoy en día todos los routers, y algunos conmutadores, ofrecen este tipo
de QoS.

El proceso es el siguiente:

Estaciones finales: Las estaciones finales transmiten los paquetes.

 Conmutador o router: Le llegan los paquetes, realiza un estudio de los
datos entrantes y los prioriza, repartiéndolos en diferentes colas según la
prioridad asignada. Estos datos vuelven a ser transmitidos hacia el siguiente
conmutador o router, donde se repite el proceso.

Las funciones son :

Control de red: Lo tiene el administrador

Lugar: Centralmente

Técnicas: Se realiza según unos patrones de tráfico

2. QoS EXPLÍCITA

Este tipo de QoS permite al usuario o aplicación solicitar directamente un

determinado nivel de servicio que han de respetar los conmutadores y routers.
Así, el proceso es:

Estaciones finales: En este caso las estaciones finales transmiten una

petición RSVP, si ésta es aceptada, los paquetes A,C,B,D, (ver figura) son
transmitidos.

Conmutador o router: Los datos entrantes son priorizados de acuerdo a

instrucciones del nodo de destino, pasando al próximo conmutador o router,
donde se repetirá el proceso.

Figura 5. Ejemplo de visualización de QoS implícita y explícita

Las funciones son :

Control de red: Lo tiene el usuario o la aplicación. Es por lo tanto, más

difícil de gestionar.
 Técnicas: IP Type of Service (ToS), RSVP.

4.3 Según las garantías

En esta clasificación se va a tener en cuenta la reserva de recursos del

sistema para proporcionar los servicios.

1. QoS GARANTIZADA / Hard QoS

También conocida como “hard QoS” la calidad de servicio garantizada

es aquella en la que se produce una reserva absoluta de los recursos de la red
para un tráfico determinado, asegurándose así unos niveles máximos de
garantías para este tráfico.

2. QoS NO GARANTIZADA / Lack of QoS

En una calidad de servicio sin garantías. El tráfico es transmitido por la

red a expensas de lo que en ella pueda sucederle. Es el tipo de QoS
correspondiente a los servicios Best Effort(Mejor servicio).

3. QoS SERVICIOS DIFERENCIADOS/ Soft QoS

También conocida como “soft QoS” es el punto medio entre los dos tipos
anteriores. Para este tipo se realiza una diferenciación de tráfico, siendo
tratados algunos mejor que el resto (expedición más rápida, más ancho de
banda promedio, menos tasa de error promedio). Es el utilizado, como se
explicará más adelante, por DiffServ.

A continuación se muestra el espectro actual de la calidad de servicio,

donde se puede observar la relación entre los niveles de QoS y el tipo de
aplicación que esté transmitiéndose por la red.
 Figura 6. Espectro de la Calidad de Servicio.

4.4 Según el lugar de aplicación

Es posible aplicar calidad de servicio en los extremos y en los bordes de

la red, por lo tanto tenemos:

1. QoS EXTREMO A EXTREMO (end-to-end)

Es la aplicación de las políticas de calidad de servicio entre los extremos

de la red. Es viable gracias a productos como el software Dynamic Access de
3Com, pero está menos extendida que la QoS entre dos bordes de la red
(edge-to-edge). También se la conoce comúnmente como la QoS absoluta.

Con este tipo de QoS se simplifican, sin embargo, los puentes, cuya
función se reduce a observar la marca de los paquetes (en el caso de 802.1p),
sin tener que calcular la clase de servicio de cada paquete reducido. Otra
ventaja es que las aplicaciones podrían seleccionar dinámicamente el nivel de
QoS, almacenándose temporalmente en los directorios de red o en los puentes
una información estática de clases de servicio.
 Actualmente, la política de las empresas dedicadas al networking es
conseguir una calidad de servicio extremo a extremo, por lo que se están
estudiando y aplicando diferentes técnicas para conseguirlo. A lo largo de los
capítulos posteriores este tipo de QoS será referenciada en multitud de
ocasiones, especificando cómo conseguirla.

2. QoS BORDE A BORDE (edge-to-edge)

Es la aplicación de las políticas de calidad de servicio entre dos puntos

cualesquiera de la red. Por ejemplo en los puentes. Esto tiene varias ventajas:
en primer lugar no requiere que los administradores de red toquen ninguno de
los extremos, esto es una ventaja para el caso de las empresas en las que la
organización responsable de la infraestructura de red está separada del grupo
de los servidores y del resto de los puestos de trabajo. Otra ventaja es que son
menos los dispositivos que tienen que ser manejados para la obtención de la
QoS. Además, la accesibilidad por parte de un usuario cualquiera de la red o
de un hacker para cambiar las especificaciones de QoS es mucho menor. Por
último, utilizando edge-to-edge QoS no es necesario conocer cómo poner en
práctica las reglas de QoS de cada uno de los posibles sistemas operativos
que podrían tener los servidores en el caso de aplicar QoS extremo-a-extremo.

A este tipo también se le conoce como calidad de servicio relativa.

Para visualizar más claramente estos dos tipos de QoS acudir al estudio
de los diferentes protocolos y arquitecturas de QoS, tratados en el capítulo 5 de
este proyecto.

Volver arriba

5 Parámetros de QoS

Son muchos los términos manejados en el estudio de la calidad de servicio,

que, a su vez, son aplicables no sólo a éste área, sino a otros ámbitos de las
telecomunicaciones y de la informática, por lo que en este apartado se explicarán
aquellos considerados clave para el completo entendimiento de este tema. Para la
consulta de otros vocablos relacionados será necesario acudir a alguno de los
glosarios que las empresas ponen a disposición pública en sus páginas web,
figurando alguna de estas direcciones en las referencias al final de este proyecto.

a. TRÁFICO DE RED
 De forma simple, podríamos decir que tráfico de una red son los datos que
la atraviesan. Es pues dependiente del tipo de aplicación que por ella circulan. De
esta manera podríamos establecer una diferenciación del tráfico.

1. Según el tipo de aplicación

Tendremos: tráfico habitual, multimedia, multicast, broadcast, tiempo real,

etc.

2. Según la sensibilidad al retardo

En este caso tendremos:

Tráfico algo sensible al retardo. Ejemplos son los procesos de

transacción on-line, la entrada de datos remota y algunos protocolos como
SNA. Este tipo de aplicaciones requieren retardos de un segundo o, incluso,
menos. Retardos mayores supondrían hacer esperar a los usuarios por la
contestación a sus mensajes antes de que puedan continuar trabajando,
disminuyendo así la productividad de los negocios.

Tráfico muy sensible al retardo. El tráfico en tiempo real es de este tipo,

tal y como las conversaciones vocales, la videoconferencia y multimedia en
tiempo real. Todos ellos requieren un retraso de tránsito muy pequeño
(típicamente menos de una décima de segundo en un sentido, incluyendo el
procesamiento en las estaciones finales) y un nivel de variación (jitter) mínimo.

Tráfico muy sensible a las pérdidas. Ej. Datos tradicionales.

Tráfico nada sensible. Ej. Servicios de noticias.

Para cada uno de estos tipos de tráfico podríamos establecer un tipo de

QoS según la clasificación realizada en el apartado anterior y, en consecuencia, la
asignación de un nivel de prioridad según el esquema siguiente:
 Figura 7. Prioridades básicas de servicio

b. RETARDO

Indica la variación temporal y/o retraso en la llegada de los flujos de datos a

su destino. Es una característica que se hace muy evidente en aplicaciones como
la video-conferencia, donde todos hemos experimentado alguna vez el retraso en
la recepción de algún mensaje vocal enviado por nosotros y, por supuesto, el
retardo existente entre la señal de voz y la señal de vídeo. Teniendo en cuenta
hacia qué tipo de aplicaciones se están orientando las telecomunicaciones (es
evidente la llegada de la voz sobre IP), es necesario que en las políticas de QoS
definidas para nuestra red este parámetro sea reducido al mínimo.

c. LATENCIA

Es el tiempo entre el envío de un mensaje por parte de un nodo y la

recepción del mensaje por otro nodo. Abarca los retardos sufridos durante el
propio camino o en los dispositivos por los que pasa.

d. JITTER (inestabilidad o variabilidad en el retardo)

Es lo que ocurre cuando los paquetes transmitidos en una red no llegan

a su destino en debido orden o en la base de tiempo determinada, es decir,
varían en latencia. Algo semejante a la distorsión de una señal.

En redes de conmutación de paquetes, jitter es una distorsión de los

tiempos de llegada de los paquetes recibidos, comparados con los tiempos de
los paquetes transmitidos originalmente. Esta distorsión es particularmente
perjudicial para el tráfico multimedia.
 Una solución ante el jitter es la utilización de buffers en el receptor. Pero
esta es una medida poco eficaz, dado que sería necesario un gran tamaño
para los buffers, lo que implica un costo económico en los equipos, y porque
estos buffers incrementarían la latencia. El tamaño de uno de estos buffers
debería ser al menos dos veces el valor del jitter y la latencia adicional
introducida por el buffer podría superar el máximo de latencia permitido por la
aplicación.

e. ANCHO DE BANDA

Una medida de la capacidad de transmisión de datos, expresada

generalmente en Kilobits por segundo (kbps) o en Megabits por segundo (Mbps).
Indica la capacidad máxima teórica de una conexión, pero esta capacidad teórica
se ve disminuida por factores negativos tales como el retardo de transmisión, que
pueden causar un deterioro en la calidad.

Aumentar el ancho de banda significa poder transmitir más datos (algo así
como aumentar el número de carriles de una autopista), pero también implica un
incremento económico y, en ocasiones, resulta imposible su ampliación sin
cambiar de tecnología de red.

f. PÉRDIDA DE PAQUETES

Indica el número de paquetes perdidos durante la transmisión. Normalmente

se mide en tanto por ciento.

Por ejemplo: 1% o menos de media de pérdida de paquetes mensual de

ancho de red

g. DISPONIBILIDAD

Indica la utilización de los diferentes recursos. Suele especificarse en

tanto por ciento.

h. RENDIMIENTO

Mide el rendimiento de la red en relación a los servicios acordados (SLAs o

acuerdos de nivel de servicio). El rendimiento es definido también por algunos
profesionales como la velocidad teórica de transmisión de los paquetes por la red.
Esta depende directamente del ancho de banda y su variación de las posibles
situaciones de congestión de la red.

i. PRIORIZACIÓN

Priorizar consiste en la asignación de un determinado nivel de QoS al

tráfico que circula por una red, asegurando así que las aplicaciones de mayor
importancia sean atendidas con anterioridad a las de menor importancia, estando o
no ante una situación de congestión. Es necesaria únicamente cuando la red no
proporciona la suficiente capacidad para atender todo el tráfico presente en la
misma.

j. ENCOLADO

El encolado consiste en dividir y organizar el tráfico ante un determinado

dispositivo de red para su posterior retransmisión por la misma según un
determinado algoritmo que define a la cola y que permite que determinados
paquetes sean reexpedidos antes que otros. Es una de las herramientas más
utilizadas por la QoS. La idea es ofrecer un mejor servicio al tráfico de alta
prioridad al mismo tiempo que se asegura, en diferentes grados, el servicio
para los paquetes de menor prioridad.

Los sistemas de colas, sin embargo, no garantizan que los datos

importantes lleguen a su destino a tiempo cuando se produce congestión, lo
único que aseguran es que los paquetes de alta prioridad llegarán antes que
los de baja prioridad.

Las colas se suelen situar en los routers, siendo áreas de memoria

dentro del mismo. Son, por lo tanto, una solución costosa, económicamente
hablando, y complicadas de gestionar.

Para un mayor entendimiento ver la siguiente figura:

 Figura 8. Encolado de servicio

k. PLANIFICACIÓN

Es el proceso de decidir qué paquetes enviar primero en un sistema de

múltiples colas.

l. FLUJO

Es el conjunto de datos pertenecientes a una misma secuencia que,

debido a su gran tamaño, han de ser enviados mediante distintos paquetes.
Tienen la misma dirección IP fuente y destino, el mismo puerto de destino y el
mismo protocolo. El flujo, necesita, por tanto, llegar secuencialmente a su
destino con una frecuencia constante. Por lo tanto, el parámetro más
importante para caracterizar un flujo será su frecuencia constante de bit
(constant bit rate, CBR), que nos dará la frecuencia a la que debería ser
transmitido cada bit de datos.

m. ACUERDOS DE NIVELES DE SERVICIO

Un Service Level Agreement(SLA) o Acuerdo de Nivel de Servicio es un

contrato de servicios entre un proveedor de servicios y su cliente, el cual define las
responsabilidades del proveedor en términos del nivel de funcionamiento de la red
(rendimiento, tasa de pérdidas, retrasos, variaciones) y la disponibilidad temporal,
el método de medida, las consecuencias cuando los niveles de servicio no se
consiguen o si los niveles de tráfico definidos son superados por el cliente, así
como el precio de todos estos servicios. Evidentemente, y suele ser lo más común,
el SLA puede incluir reglas de condicionamiento del tráfico.

Los SLA suelen subdividirse en :

 SLS : Service Level Specifications o Especificaciones del Nivel de
Servicio.

El SLS lleva a cabo el estudio del rendimiento de la red, la probabilidad

de ‘drop’, la latencia, la espera en las entradas y/o salidas de los puntos
donde se proporciona el servicio, indicando el ‘scope’ del mismo, así
como de los perfiles del tráfico que se deben adherir para que el servicio
solicitado pueda ser proporcionado y de la disposición del tráfico.

SLO : Service Level Objetives u Objetivos del Nivel de Servicio

Un SLO divide un SLA en objetivos individuales, definiendo métricas

para hacer cumplir, para limpiar, y/o para vigilar el SLA. , para así
determinar en que SLA se están cumpliendo los servicios (ej. Up-time,
MTBF, tiempo de respuesta, MTTR).

Especificaciones del condicionamiento del tráfico

Aparte del acuerdo de nivel de servicios es necesario adjuntar unas

funciones de control de los requisitos del tráfico para estudiar su
comportamiento, observando el flujo de las aplicaciones, o cualquier otro
subgrupo de tráfico operativo (ej. actualizar tablas de encaminamiento).

Algunas de estas funciones de control son la medición del tráfico, las

políticas, el ‘shaping’ y el uso de marcas en los paquetes. Se suelen utilizar en
algunas de los protocolos utilizados para proporcionar QoS. En Diffserv, por
ejemplo, se usa para hacer cumplir acuerdos entre los dominios.

Un Traffic Conditioning Agreement (TCA) o Acuerdo de

Condicionamiento del Tráfico, es un acuerdo que especifica las reglas para
clasificar el tráfico bajo cualquier perfil. Abarca todas las reglas de
condicionamiento del tráfico especificadas explícitamente dentro de un SLA,
junto con todas las reglas implícitas de los requisitos del servicio.

Como ejemplo pongámonos en el caso de una red IP. Posibles medidas

de QoS serían :

MÉTRICA DE SERVICIOS IP NIVEL DE SERVICIO

Disponibilidad de la red 99’9 % premisas para POP

Latencia 80 ms o menos de media de retardo

 mensual de ancho de red

Latencia El tráfico ofrecido al nivel A de servicio

que será entregado con baja latencia

Pérdida de paquetes 1 % o menos de media de pérdida de

paquetes mensual de ancho de red

Pérdida de paquetes El tráfico ofrecido al nivel B de servicio

que será entregado con poco nivel de
pérdidas

Rendimiento 99.99% de entrega media de datos por

mes

Volver arriba

6 QoS Basic framework

En enero de 1995 se propuso como recomendación/estándar el documento

ISO/IEC JTC1/SC21 [2], con título “QoS Basic Framework” en el que se realiza una
descripción de los diversos conceptos, campos de aplicación, herramientas y todo
un conjunto de definiciones de la aplicación de QoS en redes inteligentes, para
proporcionar una base común a todos los posibles estándares nacientes sobre
calidad de servicio. Todas las definiciones y estándares de QoS comentados en
este proyecto lo utilizan como base.

Este documento realiza, en primer lugar, una definición de conceptos sin

hacer una referencia explícita al modelo OSI (Open System Interconnection),
dedicándole posteriormente un apartado. En el mismo se explican las bases para
la creación de una arquitectura de QoS para OSI, que, al contrario de tecnologías
como ATM, no fue creada para facilitar la entrega de calidad de servicio. Para
cualquier tipo de consulta sobre las bases de un sistema que proporcione QoS se
debe acudir al citado documento.

Volver arriba
7 Algoritmos para la obtención de QoS

Una vez introducidas las principales características del término calidad

de servicio es necesario exponer el tipo de algoritmos utilizados actualmente en
la transmisión de paquetes para comprobar cómo estos realizan un control de
la congestión y a qué nivel son capaces de proporcionar calidad.

Así, teniendo en cuenta la clase de servicio que son capaces de ofrecer

los algoritmos de transmisión de paquetes podemos hacer tres divisiones
principales:

a. ALGORITMOS DE MEJOR ESFUERZO (BEST EFFORT)

En este tipo de algoritmos se encuentran los algoritmos tradicionales,

que no ofrecen ningún tipo de garantías de transmisión, por lo que podría
decirse que el nivel de calidad de servicio ofrecido es nulo. Un ejemplo muy
representativo es el FIFO (First In First Out).

El principal problema de este tipo de algoritmos es que, si tenemos

varios flujos de datos, una ráfaga de paquetes en uno de ellos va a afectar a
todos los demás flujos, retardando su transmisión. Es decir, que el tiempo de
llegada de los paquetes de un flujo puede verse afectado por otros flujos.
Cuando esto ocurre decimos que el algoritmo utilizado no es capaz de aislar
flujos.

b. ALGORITMOS DETERMINISTAS

Son aquellos en los que, para evitar la posible congestión, antes de

aceptar la transmisión de un flujo, se asegura que podrá transmitirse sin
problemas incluso en las peores condiciones. Esto se hace reservando ancho
de banda. El ancho de banda reservado es el equivalente a lo que supondría
un pico de una transmisión en ráfaga de ese flujo, con lo que se asegura que el
flujo nunca se va a salir de su ancho de banda reservado. Si suponemos este
comportamiento en cada uno de los flujos de la red, podemos ver que la
congestión es imposible, puesto que incluso en el caso en el que todos los
flujos presentaran un pico al mismo tiempo, tendrían reservado el suficiente
ancho de banda para que no hubiera congestión.

En caso de que, por límites físicos de la red, no pudiera asegurarse ese

ancho de banda, el algoritmo rechazaría la transmisión del flujo.
 Este tipo de algoritmos fueron los primeros en aparecer cuando surgió la
necesidad de asegurar las velocidades de transmisión. Es obvio que consiguen
su objetivo, pero lo consiguen a un precio muy elevado, puesto que son muy
ineficientes respecto al uso de la red. Como ya hemos explicado antes, las
situaciones de ráfaga en un flujo son poco frecuentes y de muy corta duración,
con lo que en la mayoría de los casos las necesidades de ancho de banda del
flujo son mucho menores. Al reservar el equivalente al peor caso, la mayor
parte del tiempo estamos reservando una capacidad de transmisión que no
usamos, y si esto lo hacemos con varios flujos el resultado es que los
algoritmos rechazan flujos por no poder darles la reserva adecuada cuando en
realidad la red presenta una utilización muy por debajo de sus posibilidades.

Como podemos deducir, los algoritmos deterministas aíslan

completamente los flujos.

c. ALGORITMOS INTERMEDIOS

Aquellos algoritmos cuyo objetivo es ofrecer calidad de servicio y al

mismo tiempo hacer un uso eficiente de los recursos. Entre estos podemos
diferenciar entre los que ofrecen servicios estadísticos, servicios de
degradación limitada y servicios predictivos. Estos algoritmos no aseguran una
QoS tan estricta como los deterministas , pero en la mayoría de los casos
consiguen un buen comportamiento y aprovechan mucho más los recursos
disponibles. Como consecuencia, en estos algoritmos sí que es posible el
retraso ocasional de algún paquete, con lo que si el algoritmo en cuestión se da
cuenta de que un paquete ha superado su tiempo de expiración puede
descartarlo directamente.

1. SERVICIOS
ESTADÍSTICOS

Este tipo de servicios trabaja estadísticamente, asegurando una QoS

con una probabilidad determinada. Para ello, antes de aceptar la transmisión
de un flujo, obtienen los parámetros que lo modelan. Una vez obtenidos los
parámetros se calcula el porcentaje de QoS que se le puede asignar, y si es
mayor o igual al porcentaje requerido, se acepta el flujo.

Para entender sus ventajas podemos suponer por ejemplo una red con
un ancho de banda de 10 Mbps y flujos que requieren 1Mbps de frecuencia
constante y 2 Mbps en ráfagas. En un algoritmo determinista podríamos
transmitir como máximo cinco flujos. En cambio en uno estadístico podríamos
transmitir hasta nueve con una probabilidad bastante alta, puesto que
presentarían un comportamiento correcto exceptuando los casos en los que
dos o más flujos transmitieran en ráfaga al mismo tiempo.

No obstante hay que recordar que el tener una probabilidad no implica

que tenga que cumplirse necesariamente. Este es el principal inconveniente de
esta técnica, que garantiza una probabilidad y no un resultado. Aún así gran
cantidad de algoritmos de este tipo han resultado ser bastante exactos y
usados con probabilidades de fallos del orden 10 -5 presentan un
comportamiento casi determinista aprovechando mucho más la capacidad de la
red.

2. SERVICIOS DE
DEGRADACIÓN LIMITADA

Una característica de los flujos es que podemos permitirnos la pérdida

de algunos datos. Los algoritmos de degradación limitada aprovechan este
hecho en la gestión de los paquetes consiguiendo una capacidad de decisión
más alta. Por ejemplo, en una aplicación de comunicación por voz, podemos
permitirnos perder algunos paquetes, teniendo en cuenta que estas pérdidas
de paquetes están limitadas por la aplicación, puesto que una pérdida excesiva
provocaría que la voz fuera ininteligible.

Con este método, cuando un flujo entra en la red divide sus paquetes en
varios tipos, cada uno con una prioridad distinta y con un retardo máximo
diferente. Así, en caso de congestión, los paquetes importantes tendrán mayor
prioridad.

3. SERVICIOS PREDICTIVOS

Se caracterizan por utilizar datos obtenidos midiendo las características

de los flujos. En la admisión del flujo es necesario confiar en la información que
nos da el servidor del flujo, pero una vez dentro de la red se calculan
dinámicamente sus parámetros. Con esto nos aseguramos una información
fiable y real, puesto que proviene del compartimiento actual del flujo. Este
hecho ayuda a tomar decisiones más precisas sobre las necesidades del flujo
y, por tanto, nos lleva a un funcionamiento bastante correcto con una utilización
elevada de los recursos.
 Otra característica que tienen es organizar los flujos en grupos con
necesidades similares. La mayor ventaja reside en que es posible aplicar
políticas distintas en cada grupo. Así podemos establecer prioridades entre
grupos o limitar el uso de los recursos dependiendo del grupo al que
pertenezcan. Añaden con mucha facilidad comunicaciones sin calidad de
servicio simplemente añadiendo un grupo con prioridad mínima y sin reserva
de ancho de banda. Esto hace que la utilización de la red sea más alta.

Volver arriba

8 Beneficios al aplicar QoS

Centraremos este punto en el estudio de los beneficios para las

aplicaciones, para las empresas y para los proveedores de servicio.

a. Ventajas para las aplicaciones

Hoy en día, todas las empresas están considerando Internet como una
nueva vía para incrementar su negocio y, en consecuencia, las expectativas
que se tienen para garantizar una calidad son las mismas que si se tratase de
una red privada o controlada. Internet está siendo utilizada para la formación y
el crecimiento de intranets dentro de la empresa y extranets que permiten el
comercio electrónico con los socios del negocio. Es evidente, por tanto, que se
está incrementando el acercamiento de los negocios hacia la Web, siendo cada
vez más importante que los administradores de las redes aseguren que éstas
entreguen unos niveles apropiados de calidad. Es aquí donde las tecnologías
de QoS cobran especial importancia, proporcionando a los administradores las
utilidades para la entrega de datos críticos del negocio en los periodos y con
unas garantías determinadas.

b. Beneficios para las empresas

Las aplicaciones están consiguiendo ser cada vez más exigentes. Las
denominadas críticas requieren cada vez más calidad, confiabilidad, y asegurar
la puntualidad en la entrega. Un ejemplo claro son las aplicaciones de voz o
vídeo, éstas deben ser manejadas cuidadosamente dentro de una red del IP
para preservar su integridad. Además es necesario tener en cuenta que el
tráfico no es predecible, ni constante, si no que funciona a ráfagas,
produciéndose en ocasiones picos máximos de tráfico que son los causantes,
en parte, de la saturación de la red. Ejemplos clarificadores de este tipo de
tráfico es el producido por el mundo Web, el correo electrónico y las
transferencias de ficheros, que son virtualmente imposibles de predecir.

Las tecnologías de QoS permiten a los administradores de red :

Manejar las aplicaciones sensibles al jitter, como las que manejan audio
y vídeo.

Manejar el tráfico sensible al retardo, como la voz en tiempo real.

El control de pérdidas en los momentos en los que la congestión sea

inevitable.

c. Beneficios para los proveedores de servicio

Claramente, las empresas y las corporaciones se están convirtiendo en

negocios con requerimientos de “misión-crítica” sobre la red pública. Están
delegando los servicios de sus redes a proveedores de servicio (outsourcing),
lo que les permite centrarse más en el negocio interno y así reducir costosos
capitales. Esto significa que los proveedores de servicio son quienes podrán
ofrecer las garantías de calidad para el tráfico extremo-a-extremo (end-to-end)
de la empresa. Las tecnologías de QoS permitirán a los proveedores de
servicio ofrecer muchas más prestaciones, como el soporte del tráfico en
tiempo real, o como la asignación específica de ancho de banda, que se suele
especificar en los acuerdos de nivel de servicio (SLAs), definidos en el
apartado 5 del presente capítulo.

Volver arriba

9 Gestión del ancho de banda versus QoS

Es de todos los profesionales informáticos conocido el hecho de que la

capacidad de cualquier tipo de sistema siempre, o casi siempre, acaba por
agotarse; así, los discos duros se llenan o las líneas telefónicas de una centralita se
saturan. Pero donde este límite se suele alcanzar con particular rapidez es en la
capacidad de la línea que conecta una organización con Internet (o en general con
una red IP) ante el imparable crecimiento de las aplicaciones sobre este medio.
 Lo normal es que, cuando las conexiones van lentas, se contrate más
capacidad. Pero, aún así, las líneas vuelven a saturarse tras un breve período de
tiempo y es una solución costosa. Esta es la técnica conocida
como sobreingeniería o método de la fuerza bruta. Es necesario preguntarse
entonces si ésta es la solución correcta y al estudiar otras alternativas vemos que
con éstas se pueden obtener mayores capacidades por menos costes mediante
la optimización de la gestión del ancho de banda. También conocida
como gestión de políticas cuyo estudio más exhaustivo será realizado en el
capítulo 4.

Por lo tanto, el ampliar el ancho de banda debe utilizarse como una

solución puntual para resolver determinadas situaciones de congestión en
determinados puntos de la red y para determinados tipos de redes. Es
medianamente factible para redes LAN y prácticamente imposible para redes
WAN, mientras los precios sigan siendo tan elevados. Es por tanto, una solución
costosa, con durabilidad mínima debido al crecimiento del tráfico de la red y de las
necesidades de ancho de banda de determinados tipos de tráfico.

La QoS sin embargo, conlleva, entre otras cosas, una correcta gestión del ancho
de banda. Presentándose como la forma más eficiente, hoy en día, para la mejora
de toda red que se precie. Es, en definitiva, la solución por la que deberían apostar
todas las empresas para mejorar su red y, en consecuencia, su negocio.

Volver arriba

10 QoS ofrecida por algunos sistemas operativos

Para comprobar cómo se aplicarían las normas de QoS en los sistemas

operativos, vamos a estudiarlo en los dos sistemas más extendidos: Windows
2000, de Microsoft, e IOS, de Cisco.

a. CALIDAD DE SERVICIO EN WINDOWS 2000

Windows 2000 soporta distintas técnicas de QoS IP que garantizan la

transmisión de aplicaciones multimedia en tiempo real y la rápida entrega de
grandes volúmenes de datos.
 Los componentes QoS incluidos en el sistema operativo Windows 2000
son :

API GqoS (Generic Quality of Service).

Subconjunto de API Winsock que permite a las aplicaciones invocar

servicios QoS del sistema operativo sin necesidad de comprender sus
mecanismos subyacentes.

QoS Service Provider (SP)

Responde a las peticiones de API GqoS y proporciona señalización

RSVP y soporte de políticas QoS, con Kerberos. Además invoca los
mecanismos de control de tráfico.

Control de admisión ADS y protocolo SBM (Subnet Bandwidth Manager).

Para servicio de control de admisión sobre medios compartidos. ACS es

un servicio de políticas que corre por encima de Windows 2000 Server y
funciona en conjunción con SBM. ACS combina la funcionalidad de control
de admisión basada en recursos de un SBM con el control de admisión
basado en políticas que permite Active Directory.

Infraestructura de control de tráfico con soporte de DiffServ y 802.1p

El control de tráfico de Windows 2000 incluye además mecanismos

adicionales como AT M (modo de transferencia asíncrono).

En general Windows 2000 da soporte a los principales estándares QoS,

como RSVP, 802.1p y Diffserv.

b. CALIDAD DE SERVICIO EN IOS DE CISCO

El software de QoS IOS de Cisco permite controlar redes complejas y

predecir los servicios de una gran variedad de aplicaciones de red y de tipos de
tráfico. Este software proporciona los siguientes beneficios:

Control de recursos. Permite tener control sobre cualquier recurso que

está siendo utilizado, siendo posible, por ejemplo, limitar el ancho de banda
consumido por una unión backbone, por transferencias FTP o dar prioridad
al acceso de una importante base de datos.
 Uso más eficiente de los recursos de red. Será posible conocer qué
elementos está usando la red y cómo se están sirviendo al tráfico más
importante de mi negocio.

Servicios adaptados. El control y la visibilidad proporcionadas por la

QoS habilitan al proveedor de servicios de Internet a ofrecer diferentes tipos
de servicios adaptados a sus clientes.

Coexistencia de aplicaciones de misión-crítica. Las tecnologías de QoS

de Cisco permiten que la red sea usada eficientemente para este tipo de
aplicaciones, disponiéndose el ancho de banda y los retardos mínimos
requeridos por las aplicaciones sensibles al tiempo, así como su
coexistencia con otras aplicaciones menos críticas, sin interferir.

Preparar la red para el futuro. O eso indican las especificaciones de

Cisco.

El software de QoS IOS de Cisco utiliza, además, algoritmos de

encolado para ordenar el tráfico y determinar así algún método de priorización
para su retransmisión. Incluye los siguientes algoritmos:

FIFO : First in , first out (primero en entrar, primero en salir).

PQ : Priority Queuing (encolamiento por prioridad). Este tipo realiza

priorización de tráfico.

CQ : Custom queuing (encolamiento por costumbre). Garantizando

ancho de banda.

WFQ : Weighted fair queuing (encolamiento justo pesado). Es un

algoritmo de encolamiento inteligente para las nuevas tecnologías de redes.

Además, este sistema operativo dispone de utilidades para evitar y

solucionar la congestión, utilidades basadas en gestión de políticas y mecanismos
de eficiencia en las uniones, sin olvidar los mecanismos de señalización como el
IP-Precedence (utilizando el campo ToS), RSVP, 802.1p y Diffserv.

Una vez introducido el término calidad de servicio y comprendido su

significado y lo que éste implica estudiemos qué protocolos, herramientas y
arquitecturas existen para su obtención, técnicas que son descritas en los
siguientes capítulos.

MECANISMOS Y HERRAMIENTAS

En esta sección se van a exponer las características y el funcionamiento de los

principales Control de admisión (CAC)

El control de admisión determina si una petición de conexión puede ser

llevada a cabo por la red. Las principales consideraciones tras esta decisión
son la carga del tráfico actual, la QoS que se puede lograr, el perfil de tráfico
pedido, la QoS solicitada, el precio y otras consideraciones de política. Para
QoS sobre IP esta técnica podría aplicarse en la escena de intercambio de
flujos en RSVP [4] o en los caminos de MPLS [27].

Esta herramienta es, por lo tanto, aplicación de una política de calidad

de servicio definida en la empresa, tal y como se describe en el capítulo 4.
Requiere, a su vez, una correcta monitorización del sistema que nos permita
visualizar en cada momento el estado del mismo para poder aplicar esa política
de admisión.

Volver arriba

2 Conformado del tráfico (Traffic Shaping)

Estudiemos el algoritmo de conformado genérico (Generic traffic

Shaping o GTS) propuesto por Cisco [15], así como la aplicación del
conformado del tráfico en IP, ATM y Frame Relay.

2.1 GTS (Generic Traffic Shaping o Conformado del tráfico

genérico): Controlando el flujo del tráfico de salida
 GTS [15] es un mecanismo de control del flujo del tráfico en un interfaz
determinado. Reduce la circulación de salida para evitar la congestión obligando a
determinado tráfico a una tasa de bit particular mientras se encolan las ráfagas del
citado tráfico. Así, el tráfico adherido a una topología puede ser tratado para
configurarlo según los requisitos del tráfico saliente, eliminando los cuellos de
botella en topologías con tasa de datos desiguales.

Figura 17. GTS. EL conformado del tráfico se realiza por la base del interfaz.

GTS se aplica sobre cada base del interfaz, puede usar las listas de acceso
para seleccionar el tráfico para formar y trabaja con una variedad de tecnologías de
capa 2, incluyendo Frame Relay, ATM, SMDS y Ethernet.

En un subinterfaz Frame Relay, GTS puede ser utilizado para adaptarse

dinámicamente al ancho de banda disponible, integrando señales BCN. También
puede configurarse en una tarjeta de interfaz ATM para responder a la señalización
RSVP sobre los circuitos virtuales permanentes configurados estáticamente.

2.2 CONFORMADO EN FRAME RELAY : FRTS (Frame Relay Traffic

Shaping) : Gestión del tráfico Frame Relay

FRTS [16] proporciona parámetros útiles para la gestión de la congestión.

Incluye CIR, FECN, BECN y el bit DE. Las características de FRTS sobre Frame
Relay hacen que este soporte capacidades adicionales que mejoren la
escalabilidad y actuación de estas redes, aumentando el número de circuitos
virtuales y mejorando el tiempo de respuesta.

Permite configurar los valores de la tasa de tráfico, el CIR u otro valor, así
como la prioridad y el encolamiento, dando un mayor control sobre el flujo de tráfico
en cada circuito virtual individual. Combinando, además, CQ con FRTS se permite
el tratamiento de múltiples tipos de tráfico, como IP, SNA e IPS, garantizando un
ancho de banda para cada tipo.

FRTS puede eliminar los cuellos de botella en las redes Frame Relay con
conexiones de gran velocidad en los puntos centrales y conexiones de baja
velocidad en los extremos. El administrador podría configurar la tasa de tráfico
entre los distintos puntos de la red.

2.3 CONFORMADO EN REDES IP

En redes IP con QoS, es necesario especificar el perfil de tráfico para

una conexión para decidir cómo asignar los distintos recursos de la red. El
conformado o condicionado del tráfico asegura que el tráfico entrante en un
extremo o en un nodo central se adhiere al citado perfil. Típicamente este
mecanismo se usa para reducir las grandes ráfagas de tráfico entrantes. Esto
implica la toma de decisión entre los beneficios que puede dar el conformado
(por ejemplo la pérdidas de cadenas de la red) y el retardo que forma.

2.4 CONFORMADO DEL TRÁFICO EN ATM

Traffic shaping es un mecanismo que altera las características de tráfico

del flujo de celdas de una conexión para alcanzar una mejor eficiencia en la red
mientras se mantienen los objetivos QoS o con la finalidad de asegurar que el
flujo de celdas sea conforme con los parámetros de tráfico de acuerdo con la
configuración del algoritmo leaky bucket del contrato de tráfico. El traffic
shaping puede ser empleado en ATM, por ejemplo, para reducir la velocidad
pico, limitar la longitud de la ráfaga por medio del espaciamiento adecuado de
las celdas en el tiempo. El uso y ubicación de esta función es especifica de la
red.

Volver arriba

3 Clasificación y marcado de paquetes

Para proporcionar la QoS solicitada es crítico clasificar los paquetes para

permitir el tratamiento de diversos tipos de QoS. Esto se puede conseguir mediante
marcas en los paquetes, sumándolos a un tratamiento particular de obtención de
QoS en la red (por ejemplo una alta/baja prioridad o una pérdida/retraso de
prioridad) como resultado de una monitorización del tráfico o de una discriminación
del mismo. Así, en IP el marcar los paquetes se realiza utilizando el byte Tipo de
Servicio (ToS) e la cabecera para IP v4 y el byte Clase de Tráfico (CS) para Ipv6.

Realizar una clasificación de paquetes eficiente y consistente es, por tanto,

una herramienta que está en constante investigación.

Volver arriba

4 Mecanismos de prioridad y gestión

Para satisfacer las necesidades de QoS de las diferentes conexiones, los

nodos necesitan aplicar mecanismos de prioridad y gestión.

La prioridad hace referencia normalmente a la capacidad de proporcionar

diferentes tratamientos al retardo, por ejemplo, los paquetes de prioridad superior
son servidos siempre antes que los de menor prioridad, en el contexto de dar
salida a los paquetes. Los nodos también implementan diferentes técnicas, por
ejemplo para que se sufran menos pérdidas con los paquetes de mayor prioridad.

Por otro lado, los nodos también necesitan utilizar algún mecanismo de
gestión para asegurarse de que algunas conexiones obtengan los recursos
prometidos (en procesamiento y ancho de banda). Este mecanismo además
asegura que cualquier capacidad “de repuesto” esté distribuida de la manera más
justa. Algunos ejemplos son Generalized Processor Sharing (GPS), Weighted
Round robin (WRR), Weighted Fair Queueing (WFQ) y Class Based Queueing
(CBQ) [3], explicados algunos de ellos posteriormente en este capítulo.

Volver arriba

5 Protocolos de señalización

Para obtener la QoS requerida por una red, los sistemas extremos
necesitan indicárselo a la red, para ello se usan los protocolos de señalización.
Esto ha sido fundamental para redes orientadas a conexión (ATM). Sin
embargo, para otro tipos de redes (como IP) esto es prácticamente nuevo. Un
ejemplo de protocolo de señalización, como ya vimos, es RSVP (Resource
Reservation Protocol) [4], LDP (Label Distribution Protocol) [5] e IP Precedence
[6]. Su escalabilidad y las capacidades de la señalización es un tema que ha
estado y estará bajo estudio.

Hay que pensar en la señalización de QoS como una forma que tiene la
red de comunicarse. Proporciona una manera de que cada elemento de a red
pueda pedir algo a un vecino. Por ejemplo, una red IP puede usar parte de la
cabecera IP para solicitar un manejo especial de ala prioridad o del tráfico
sensible al tiempo. La señalización es útil para coordinar el tráfico que se ocupa
de cualquiera de las herramientas de QoS que se explican en este capítulo y es
muy importante para conseguir de forma exitosa la QoS extremo a extremo.

La verdadera QoS extremo a extremo requiere que cada elemento en el

camino del tráfico por la red (conmutadores, encaminadores, firewalls, host,
usuarios,etc) entreguen su parte de QoS y todo ello debe ser coordinado
mediante técnicas de señalización. Es ahí donde está el desafío, el encontrar
un protocolo robusto que pueda operar extremo a extremo sobre redes
heterogéneas. La figura siguiente muestra diferentes soluciones y cómo/dónde
se aplican.

Figura 9. Algunas soluciones de señalización de QoS se aplican solo en

algunos puntos de la infraestructura.

Volver arriba
6 Eficiencia del enlace

Existen algunos mecanismos que mediante el encolado y el conformado del

tráfico proporcionan eficiencia y predicción, tales como:

a) LFI (Fragmenting and Interleaving IP

Traffic) : Fragmentando y separando el tráfico IP.

b) RTP Header Compression (Real Time

Protocol Header Compression): Comprensión de la cabecera del
protocolo de transporte de tiempo real.

Realicemos un estudio más exhaustivo:

6.1 LFI (Fragmenting and Interleaving IP Traffic)

El tráfico interactivo, tal y como Telnet, voz sobre IP, es susceptible a

aumentos de latencia y jitter cuando la red tiene que procesar paquetes grandes
(por ejemplo un paquete de LAN a LAN vía FTP atravesando un enlace WAN),
sobre todo si necesitan ser encolados en enlaces de red menores. LFI reduce el
retardo y el jitter en los enlaces de menor velocidad rompiendo los paquetes
grandes y entrelazando los paquetes de menor retardo obteniendo así paquetes
más pequeños. La siguiente figura muestra cómo se realiza esa reducción.

Figura 10. Dividiendo grandes datagramas con LFI el retardo se reduce en las
uniones de menor velocidad.
 Esta herramienta fue diseñada especialmente para enlaces de poca
velocidad en los que el retardo al serializar es significativo. LFI es equivalente al
borrador del IETF denominado Multiclass Extensions to Multilink PPP (MCML) [7] .

6.2 RTP (Real Time Protocol): Aumentando la eficiencia del tráfico

en Tiempo Real.

El Protocolo de Transporte en Tiempo Real [8]es un protocolo host-to-host

usado para llevar las nuevas aplicaciones multimedia, incluyendo audio y vídeo,
sobre redes IP. RTP proporciona funciones de transporte de red extremo a
extremo para las aplicaciones citadas.

La siguiente figura muestra cómo se realiza la compresión en la cabecera

con RTP.

Figura 11. Muestra la compresión de la cabecera vía RTP

Para la carga útil comprimida de las aplicaciones de audio, el paquete

RTP tiene una cabecera de 40 bytes y típicamente para la carga útil de 20 a
150 bytes. Dado el tamaño de la cabecera de RTP y de IP/UDP, es ineficaz
transmitir una cabecera no comprimida. Esta compresión ayuda a RTP a
ejecutarse más rápidamente –sobre todo en enlaces de menor velocidad – al
comprimir la cabecera de RTP/IP/DP de 40 bytes al rando “de 2 a 5”. Esto es
muy beneficioso para los paquetes más pequeños (como el tráfico de voz sobre
IP) en uniones lentas (385 Kbps y menores), donde la compresión puede
reducir significativamente el retraso.

La compresión de la cabecera RTP es soportado en líneas series

usando Frame Relay, HDLC (High Livel Data Link Control) [9] o encapsulación
PPP. También es soportado sobre interfaces ISDN. Existe un borrador IETF
denominado RTP comprimido (CRTP), que define esencialmente la misma
funcionalidad que el protocolo aquí tratado.

Volver arriba

7 Herramientas de control de congestión

Los elementos de red unidireccionales deben poder manejar grandes tasas

de tráfico de llegada, para ello usan algoritmos de encolamiento que clasifiquen el
tráfico y aplicar después algún método de priorización para su expedición.

Algunos algoritmos de gestión de colas de espera son los siguientes:

1. FIFO (First-in, First-out) : Primero en entrar, primero en salir de la

cola.

2. PQ (Priority Queuing) : Prioridad encolamiento.

3. CQ (Custom Queuing) : Por costumbre.

4. WFQ (Weighted fair queuing) : Por peso.

Cada algoritmo de encolamiento ha sido diseñado para resolver un

problema específico del tráfico de la red, obteniendo así un determinado efecto en
el funcionamiento de la red, tal y como se describe en cada uno de ellos.

7.1 FIFO (First-in, First-out): Capacidades de almacenamiento y

envío.
 En su forma más simple, el algoritmo FIFO implica almacenar los paquetes
cuando se congestiona la red y expedirlos, teniendo en cuenta el orden de llegada,
cuando la red no está tan congestionada. FIFO es el algoritmo por defecto, por lo
que no requiere ninguna configuración, sin embargo tiene varios defectos. El más
importante es que no toma decisiones sobre la prioridad de los paquetes, es el
orden de llegada el que determina el ancho de banda y el buffer a asignar. No
proporciona protección contra aplicaciones (fuentes) corruptas. El tráfico a ráfagas
puede causar grandes retardos en la entrega del tráfico basado en aplicaciones
sensibles a l tiempo, así como al control de la red y a los mensajes de señalización
que circulan por la misma. FIFO fue, en definitiva, un primer paso necesario para el
control del tráfico de a red, pero hoy en día las redes inteligentes necesitan
algoritmos más sofisticados.

7.2 PQ(Priority Queuing) : Priorizando el tráfico.

PQ [10] asegura que el tráfico importante sea administrado más

rápidamente en cada punto donde se utilice. Fue, por lo tanto, diseñado para dar la
mayor prioridad al tráfico importante. Este algoritmo puede dar la prioridad de
forma flexible según el protocolo de red utilizado (por ejemplo IP, IPX, o AppleTalk),
el interfaz entrante, el tamaño del paquete, la dirección fuente y/o destino, y mucho
más. En PQ cada paquete es colocado en una de las cuatro colas de prioridad –
alta, media, normal, baja- basándose en la prioridad ya asignada, asignándose
prioridad normal para aquellos paquetes que no tengan ninguna prioridad
asignada, tal y como se puede ver en la figura posterior. Como vemos, durante la
transmisión el algoritmo concede un tratamiento preferencial a las colas de mayor
prioridad sobre las de menor prioridad.
 Figura 12. Algoritmo PQ. Encolamiento basado en prioridad de paquetes.

PQ es útil para cerciorarse de que el tráfico que atraviesa varias

conexiones WAN y es considerado crítico consiga un tratamiento prioritario.
Actualmente, además, este algoritmo usa una configuración estática, no
adaptándose así automáticamente a los requisitos cambiantes de las redes.

7.3 CQ(Custom Queuing) : Ancho de banda garantizado

CQ [11] fue diseñado para permitir que varias aplicaciones u organizaciones

compartan la red, entre aquellas aplicaciones que necesiten anchos de bandas o
requisitos de latencia mínimos. En estos entornos debe compartirse
proporcionalmente el ancho de banda entre las aplicaciones y los usuarios. CQ
puede utilizarse para proporcionar ancho de banda garantizado en aquellos puntos
donde se produzca congestión, asegurando a un tráfico específico una porción fija
de ancho de banda disponible y dejando el tráfico restante para cualquier otro tipo
de tráfico. Las colas clientes manejan el tráfico asignando una cantidad específica
del espacio de la cola a cada clase de paquete, aplicando posteriormente el
sistema Round-Robin.

Como ejemplo de uso, SNA encapsulado requiere la garantía de un nivel

mínimo de servicio. Se podría reservar la mitad del ancho de banda disponible para
los datos SNA, permitiendo que la otra mitad sea utilizada por otros protocolos
como IP e IPX.

Figura 13. Algoritmo CQ. Maneja el tráfico asignando una cantidad específica
de espacio de la cola a cada clase de paquetes y sirviéndolas hacia 17 colas
aplicando Round-Robin.

El algoritmo de encolamiento coloca los mensajes en una de las 17 colas (la

cola 0 se utilizada para almacenar mensajes de sistema como mantenimiento,
señalización, etc. ) y se vacía con prioridad pesada. Los servicios de
encaminamiento van desde la cola 1 a la 16 según el orden asignado por Round-
Robin, desencolando un byte de cada cola por cada ciclo. Esto asegura que
ninguna aplicación (o grupo de aplicaciones) logre una mayor proporción de
capacidad global cuando la línea se encuentre bajo presión. Como PQ, CQ se
configura estáticamente y no se adapta automáticamente a las condiciones
cambiantes de las redes.
7.4 WFQ (Weighted fair queuing): Algoritmo para redes
inteligentes

Para situaciones en las que es deseable proporcionar un tiempo de

respuesta consistente a cualquier tipo de usuarios sin necesidad de aumentar el
ancho de banda de forma excesiva, entonces la solución es WFQ. Es un algoritmo
de encolamiento basado en el flujo que realiza dos tareas simultáneamente: situa
el tráfico interactivo a principio de la cola para reducir el tiempo de respuesta y
permite así compartir el resto del ancho de banda entre flujos que requieren gran
ancho de banda.

WFQ [12] asegura que las colas no se quedarán sin ancho de banda,
proporcionando a ese tráfico un servicio predecible. Así mismo, las ráfagas de
tráfico de bajo volumen –la mayoría del tráfico- reciben servicio preferencial,
transmitiéndolas rápidamente. Las ráfagas de tráfico de gran volumen compartirán
la capacidad restante de forma proporcional entre ellos, como muestra la siguiente
figura.

Figura 14. WFQ. Si hay varias conversaciones de gran volumen activas, sus
velocidades de transferencia y periodos entre llegadas se hacen más predecibles.

WFQ ha sido diseñado para minimizar en esfuerzos al configurar,

adaptándose automáticamente a las condiciones cambiantes del tráfico de la red.
 WFQ es eficaz pues permite que se pueda asignar cualquier cantidad de
ancho de banda para flujos de tráfico de baja prioridad si no está presente ningún
flujo de alta prioridad. Esto es diferente del multiplexado por división en el tiempo
(TDM) que simplemente mide el ancho de banda y permite que este no se utilice si
no está presente un determinado tipo de tráfico. WFQ, además, trabaja con las
técnicas IP Precedence y RSVP para proporcionar QoS diferenciada así como
servicios garantizados.

Este algoritmo también trata el problema de la variabilidad del atraso

durante la transmisión. Si hay múltiples conversaciones de alto volumen activas,
sus tasas de transferencia, así como sus periodos de llegada se hacen más
predecibles. WFQ refuerza algoritmos como el SNA Control de Enlace Lógico
(LLC) y el control de congestión del Protocolo de Control de Transmisión (TCP),
obteniendo como resultado una expedición y un tiempo de respuesta más
predecible para cada uno de los flujos activos, tal y como muestran las siguientes
gráficas.

Figura 15. Ejemplo de retraso de tráfico interactivo.

Volver arriba
8 Herramientas de prevención de congestión

Las técnicas de prevención de congestión supervisan las cargas de tráfico

de la red en un esfuerzo por anticiparse y evitar la congestión de los comunes
cuellos de botella de la red, como opuesto a técnicas que operan para controlar la
congestión de la red después de que esta ocurre.

8.1 RED (Random Early Detection o detección temprana

aleatroria): Evitar congestión .

Los algoritmos de detección temprana al azar son diseñados para evitar la

congestión entre redes antes de que esta se vuelva un problema. RED supervisa la
carga de tráfico en diferentes puntos de la red y descarta paquetes de forma
estocástica si aumenta el nivel de congestión. El resultado es que la fuente detecta
esta situación, retardando su transmisión. RED se ha diseñado para trabajar en
entornos TCP e IP principalmente.

8.2 WRED (Weighted Random Early Detection o detección

temprana aleatoria pesada) : Cooperación con tecnologías de
señalización QoS

WRED [14] combina las capacidades de RED con IP Precedence. Esta

combinación mantiene tráfico preferencial que maneja como paquetes de prioridad
más altos. Puede selectivamente desechar el tráfico de menor prioridad cuando el
interfaz empieza a congestionarse y proporciona características de gestión distintas
para las diferentes clases de servicio. Pero WRED también permite RSVP,
ofreciendo servicios integrados de QoS de carga controlada.
Figura 16..WRED proporciona un método que descarta estocásticamente paquetes
si la congestión aumente.

mecanismos y/o herramientas utilizadas para la obtención de calidad de

servicio tanto en los nodos de la red, como las técnicas de coordinación de
QoS extremo a extremo entre los citados nodos.

Como se mostró en los capítulos anteriores, existen dos formas

fundamentales de proporcionar QoS en las redes. La más sencilla consiste en
incrementar el ancho de banda bruto de las infraestructuras (sobreingeniería de
red). La otra alternativa, sin embargo, es la que se basa en el empleo de funciones
como priorización de datos, colas, eliminación de la congestión y modelado de
tráfico. Ambas soluciones implican la realización de una buena gestión de los
recursos de las redes. Es aquí, donde aparece la QoS basada en políticas,
permitiendo al administrador de red asignar anchos de banda y priorizar tráficos en
la red en función de un conjunto de políticas administrativas y patrones de uso.
 En definitiva, la QoS basada en políticas consiste en la identificación de un
grupo de tráfico y en el establecimiento de un perfil de calidad de servicio para el
mismo. Estos grupos de tráfico pueden estar basados en criterios de topología o de
grupos de usuarios, estaciones individuales o sesiones de aplicaciones.

Estos grupos de tráfico son mapeados en múltiples colas asociadas a un

conmutador capacitado para QoS basado en políticas. Para cada cola, el perfil
QoS puede incluir factores como máximo y mínimo ancho de banda, ancho de
banda pico, prioridad relativa y retardo máximo. Dependiendo de las necesidades
de la red, el administrador puede elegir establecer todas estas variables o usar una
subred. También es posible que sólo sea necesario asignar perfiles QoS a uno o
dos grupos de tráfico, mientras que el resto del tráfico de la red se regula por la
técnica natural del “mejor esfuerzo”.

Cuando se fijan perfiles QoS a múltiples grupos de tráfico, el ancho de

banda es asignado equitativamente entre todas las colas, garantizándose siempre
a cada cola un valor mínimo.

1 Componentes de la gestión basada en políticas

Para poder realizar una buena elección y una buena administración de los
recursos de la red, decidir qué protocolo de QoS usar y dónde aplicarlo, existen, a
su vez, protocolos que pueden ser usados para la distribución de la política, que
serán estudiados a continuación. Además, es necesario que los diferentes
dispositivos de la red trabajen en la gestión de políticas. Pueden participar hosts,
routers, conmutadores, firewalls, los administradores de ancho de banda de la
subred, los servidores de acceso a la red, servidores de políticas (específicos) y los
“brokers” de ancho de banda.

1.1 IETF Policy Framework

Como se pueden aplicar distintos tipos de políticas y en dispositivos

diferentes, el IETF Policy Framework Working Group está trabajando en cómo
representar, administrar y compartir políticas y cómo representar las reglas de
políticas, para que sean independientes de los fabricantes y permitan una buena
administración del tráfico para proporcionar QoS.

En este documento, se define el término políticas, los distintos elementos y

protocolos requeridos para soportar políticas en la red, cómo escribir funciones de
políticas, reglas, acciones, etc., estableciendo así las bases para los posibles
programas de monitorización de gestión de políticas en los que trabajan las
empresas.

Definición de política

En un sentido general, política es una o más reglas que describen la acción

que se produce cuando se da una determinada condición, pudiendo existir reglas
y políticas concatenadas.

Condición Acción

Las funciones que debe comprender una política son :

a) Toma de decisiones.
Comparando el estado actual de la red con el estado deseado
(establecido en los SLAs entre cliente-proveedor) y estudia la forma de
cómo conseguirlo.

Se desarrolla en el Punto de Decisión de Políticas (PDP) (ver figura de

arquitectura general).

b) Aplicación. Permite
conseguir una política deseada utilizando comandos que, aplicados
sobre los distintos dispositivos de la red, permiten cambiar su
configuración para conseguir QoS.

Son las acciones que realiza el Punto de Aplicación de Políticas (PEP)

según las decisiones del Punto de Decisión (PDP).

c) Métrica. Estudio de la red

y sus dispositivos para comprobar si se han cumplido todas las
políticas establecidas.
 Una arquitectura general de políticas puede ser la representada a
continuación:
Prescripciones de política (Policy Prescriptions)
 Esta arquitectura contiene:

LDAP (Lightweight Directory Access Protocol) [17]: protocolo para

intercambiar información entre el punto de decisión de políticas(PDP) y el
suministrador de las reglas para su creacíon (una aplicación, servidores, etc.).

SNMP: al igual que LDAP, SNMP es utilizado en políticas como un

protocolo de intercambio de información.
 COPS(Common Open Policy Service Protocol) : es un protocolo creado
para la administración de políticas distribuidas. Puede ser utilizado incluido en
un dominio, para la distribución de políticas en un router. Permite, además,
traducir comandos de políticas en reglas que los protocolos RSVP, Diffserv,
802.1p y cualquier otro protocolo de QoS puedan entender para llevar a cabo
en la red.

1.2 Ejemplo de creación de reglas y políticas

Para visualizar cómo se realiza la especificación de una política,

supongamos la implementación de la siguiente regla :
Proporcionar el servicio de vídeo JitterFreeMPEG2 para usuarios
autorizados entre puntos autorizados y en los tiempos acordados.

La regla anterior se podría escribir como:

IF usario IN UsuariosAutorizados
AND servicio IN Servicios_de_vídeo
AND recursos IN Fuentes_de_vídeo
AND destino IN Destinos_de_vídeo
AND tiempo IN Periodos_de_tiempo_Permitidos
THEN proporcionar JitterFreeMPEG2

La condición sería:
IF el usuario es un miembro de un grupo autorizado
(UsuariosAutorizados) que son autorizados a tener este servicio
AND el servicio pedido es soportado (Servicios_de_video)
AND los recursos pedidos están permitidos (en el grupo de
Fuentes_de_video)
AND el tiempo solicitado está OK (dentro de
Periodos_de_Tiempo_Permitidos)

La acción se describiría:
IF las condiciones son satisfechas(usuario, servicio, fuente, destino,
tiempo)
THEN proporcionar al usuario solicitante de tráfico de vídeo la QoS
definida por el servicio JitterFreeMPEG2
Volver arriba
 2 Posición de los fabricantes

Durante los dos últimos años los grandes nombres de empresas del
mundo del networking se han estado preparando para suministrar QoS
mediante gestión de políticas, acondicionando todos los dispositivos de
redes LAN/WANs para que éstos permitan algunas de las alternativas en
protocolos de QoS existentes, para proporcionar QoS extremo-a-extremo,
punto-a-punto y de arriba-a-abajo. Además, la mayoría de ellos, han
orientado sus estrategias en conseguir aplicaciones que permitan
monitorizar todos los recursos y acciones que se produzcan en la red para la
aplicación de políticas y facilitar la gestión al administrador del sistema,
basándose en el documento del IETF anteriormente descrito. Como esta es
una tecnología inmadura, durante todo este tiempo cada compañía ha ido
tomando su propio enfoque, por lo que, para tener un conocimiento de los
trabajos realizados por determinada empresa es necesario visitar su página
web.
Algunos ejemplos son : QoS Policy Manager 1.0 (QPM) de Cisco [20],
Optivity Polices Services 1.0 (OPS) de Nortel [21] y Spectrum Policy Aware
de Cabletron [22].

2.1 Política en perspectiva: comparaciones

Como se ha comentado, cada fabricante difiere en qué aplicar y

dónde aplicar políticas, en particular en el servidor de políticas. Para
comprobar estas diferencias es necesario estudiar qué técnicas utiliza cada
uno.
Las siguientes figuras muestran cómo aplican la gestión de políticas
algunas de las empresas de networking para la obtención de QoS [23].

Propuesta de 3Com :
Propuesta de Cabletron :

Propuesta de Cisco :
Propuesta de Extreme:

El significado es :
 Figura 18. Ejemplo de puesta en práctica por distintas empresas.

Volver arriba

3 Ejemplo de aplicación de políticas

Para comprender más el significado de la gestión de políticas y todo lo

que conlleva estudiaremos un ejemplo [24].

Supongamos el caso de la red cuya figura se muestra en la página 63.

Esta red está dividida en 5 LANs, todos ellos interconectados por un dispositivo
central. A su vez, cada LAN está gobernada por un dominio de políticas,
utilizando un programa administrador de políticas de un fabricante particular.

Los productos utilizados en el ejemplo son :

Aplicaciones :

3Com IP Pone & NBX 100, Microsoft Netmeeting, Real Networks

G2 Player, Misión Critical Application simulated by Netcom Systems,
Misión Critical application simulated by Ganymede, Optivision MPEG
Video Decoder.

Servidores de políticas :

IP Highway Open Policy System, Orchestream, Nortel Networks

Policy Server, Intel PBNM Server, Hewlett Packard PolicyXpert.
Generadores de tráfico y analizadores:

IXIA Communications 1600, Netcom Systems SmartBis

Dispositivos de red:

Windows 2000, Cabletron Ssytems SSR (Smart Switch Router),

Cisco System 7200, Cisco Systems 3600, Hewlett Packard ProCurve
2424M Switch, Intel Express 510T Switch, Intel Express 510T Switch,
Intel 8100 Router, Nortel Networks Accelar 1200 Switch, Nortel Networks
BLN Router, Nortel Networks ASN Router.
Figura 19. Ejemplo de aplicación de políticas
 3.1 Aplicaciones

Comprobemos la obtención de ciertos niveles de QoS para

determinados tipos de aplicaciones :

1) Mejorar la QoS para un tráfico de vídeo

Está formada por :

Aplicación Real Networks G2 Players. Una tiene prioridad y la otra

no.

Protocolos en DiffServ, 802.1p

acción

Administrador de LAN B (emisora), como IP Highway Policy Domain

políticas

Host(s) Microsoft Windows 2000

Host LAN LAN E

LAN emisora LAN B

Observar : La alta calidad de vídeo conseguida con la QoS basada

en políticas, entre la fuente del tráfico de vídeo y los
participantes.

En este ejemplo, la fuente es una trama de vídeo de Real Player

enviada desde un servidor RealServer con distintas velocidades de transmisión
(28.8 Kb<= x <=220Kb). Estos servidores están conectados dentro de una
VLAN de nivel 2 con Cabletron SSR2000. El tráfico desde el servidor fluye
hacia un Cisco 2500 donde el tráfico está marcado basándose en la política del
IPHighway’s Policy Server. El tráfico pasa después por una VLAN (capa 3)
donde se suma a oro tráfico, circulando por un línea congestionada de tamaño
máximo 10MB en el dispositivo Nortel Accelar 1200 Switch. Desde este nodo
central viaja hacia un Cisco 3600 router, a través de un conmutador Hewlett
Packard Procurve 2424M (Capa 2) y de ahí a una pareja de Real Networks G2
Players.

Esto demuestra los beneficios de la QoS basada en políticas en

momentos de congestión, aplicado en la aplicación Real Player.

2) Mejorar la QoS para telefonía/conferencia

Está formada por :

Aplicación 3Com NBX100 Communication System LAN

Telephony permitiendo aplicar prioridad

Protocolos en acción Diffserv, 802.1p

Administrador de Fuente LAN B – IP Highway Policy Domain

políticas

Host(s) 3 Com Ethernet, conectado a IP phone

Host LAN LAN B y E

LAN emisora LAN B

Observar : La alta calidad en transmisiones de voz al

proporcionar QoS entre los IPphone.

En este ejemplo, la llamada es iniciada por uno de los IP PHONES. La

señal es enviada a un NBX100 para procesar y encaminar. El NBX100 entrega
la llamada vocal al Ipphone destino en cualquiera de las subredes locales
conectadas al nodo central de la red. El tráfico de voz viaja a través de un
conmutador Hewlett Packard 2424, un router Cisco 3600, el nodo central Nortel
Accelar, Cabletron SSR y el router Cisco 2500 (Ver figura).

Esto demuestra los beneficios de la QoS aplicada a aplicaciones

interactivas de voz entre 3Com IpPHONES y el NBX100, estando en un estado
de saturación de la red.

3.2 Software de gestión

A continuación se muestran algunos de los programas de

monitorización de políticas utilizados en el ejemplo.

LAN A – Hewlett Packard Policy Domain

Figura 20. Software monitorización Hewlett Packard

LAN E – Orchestream Policy Domain

 Figura 21. Software monitorización Orchestream.

Figura 21. Software monitorización Orchestream.

PROTOCOLOS Y ARQUITECTURA DE QoS

El desarrollo de las normas suele ser un proceso largo y tedioso, no sólo

para los técnicos implicados directamente en su especificación, sino también, y
eso es lo peor, para los usuarios. Con algunas tecnologías sucede que, desde
su llegada por primera vez a los oídos de los usuarios, hasta su disponibilidad
definitiva y estandarizada, la furia del marketing acrecienta la ansiedad de la
espera. En el peor de los casos, incluso antes de que se conviertan en normas
oficiales y estables, la aparición de soluciones alternativas convierten la
promesa en poca más que una flor muerta. Tal podría haber sido el caso del
protocolo de reserva de recursos o RSVP (Resource Reservation Protocol)[25].

RSVP surgió en 1990 como el método definitivo para alcanzar el nirvana

QoS, pero el protocolo fue diseñado para una única arquitectura de red, y no
para el mundo heterogéneo que hoy cunde en el networking. En consecuencia,
no faltaron voces que solicitaban su sustitución por otras alternativas más
adaptadas a la realidad, pero la reunión del IETF del mes de agosto de 1998
permitió contemplar la posibilidad de que las diferentes tecnologías de QoS
trabajasen juntas para proporcionar los tan deseados niveles de QoS,
pensando en usar RSVP en los routers de extremo, DiffServ [26] en la parte
central para agregar tráfico, MPLS [27] para especificar la mejor ruta para el
tráfico a través de la red utilizando etiquetas y 802.1p/q [28] para redes 802.

Es evidente, que es posible proporcionar QoS a través de distintos

estándares, de los que en este capítulo se dará una visión general.

1 Clasificación de los distintos protocolos

Las aplicaciones, la topología de la red y la política de QoS dictan qué

tipo de QoS es más apropiado para un flujo individual o para varios. De entre
todas las opciones, los protocolos y algoritmos más utilizados son :

1.1 ReserVation Protocol (RSVP) : Protocolo de reserva de

recursos.

Proporciona la señalización para permitir la reserva de recursos de la

red (conocido también como Servicios Integrados o Integrated Services).
Aunque se usa típicamente para un solo flujo (per flow), RSVP también
se utiliza para flujos agregados (per aggregates). Hablaremos de flujos
agregados cuando circule más de un flujo por la red.

1.2 Differentiated Services (DiffServ) : Servicios Diferenciados.

Permite el dividir y el dar prioridad al tráfico de la red mediante el uso de

etiquetas en las cabeceras de los paquetes.

1.3 Multi Protocol Labeling Switching (MPLS): Conmutación de

etiquetas multiprotocolo

Proporciona la posibilidad de administrar el ancho de banda de la red a

través de etiquetas en las cabeceras de los paquetes (encapsulamiento)
y de encaminadores específicos capaces de reconocerlas.

1.4 Subnet Bandwidth Management (SBM) : Administración del

ancho de banda de la subred
 Es un protocolo de señalización que permite la comunicación y
coordinación entre los distintos nodos de la red, definiendo cómo
relacionar los distintos protocolos de QoS superiores con las diferentes
tecnologías de capa 2 (la capa de enlace en el modelo OSI). Ha sido
desarrollado para aplicarlo con LANs IEEE.

1.5 802.1p

Estándar integrado dentro de la norma 802.1D (LAN’s con puentes) que

permite dar prioridad al tráfico y filtrar el tráfico Multicast de forma
dinámica. Puede diferenciar entre 8 tipos de clases de tráfico
clasificados como “prioridades de usuario” por cada puerto (actuando a
nivel 2). Su estudio detallado se realizará en el Capítulo 8.

La siguiente tabla presenta una comparativa de los distintos algoritmos y

protocolos de QoS en términos del nivel de calidad que proporcionan y dónde
es implementado el control de dicho servicio, si en la aplicación (App) o en la
red (Net). Así tenemos :

QoS Net App Descripción

Mayor X Proporcionar recursos extremo a extremo ( ej. redes

privadas y de poco tráfico)

X X RSVP para IntServ garantizado (proporciona la

realimentación a la aplicación)

X X RSVP para servicio de carga controlada

(proporciona la realimentación a la app.)

X MPLS

X X DiffServ aplicado a la entrada de la red apropiado al

porcentaje de disponibilidad de la reservación de
RSVP para ese flujo.

Priorización usando SBM aplicado en LANs

X X Diffserv o SBM aplicado en flujos únicos de la

 aplicación origen

X Diffserv aplicado a la entrada de la red

X El encolado aplicado por los elementos de la red

Servicio Best Effort

- Tabla : Muestra los diferentes algoritmos y protocolos de gestión del ancho de

banda, sus relativos niveles de QoS y cuándo son activados por el elementos
de la red (Net) o por aplicaciones(App) o ambos-

Los protocolos de QoS aquí señalados son diferentes, pero no se

excluyen unos a otros, todo lo contrario, en la realidad se complementan a la
hora de su aplicación para obtener los niveles de calidad requeridos en una
determinada red (convergencia de redes). Esta complementación compone una
gran variedad de arquitecturas en las que los protocolos trabajan
conjuntamente para proporcionar QoS extremo a extremo a través de múltiples
proveedores de servicio.

Volver arriba

2 RSVP

El Protocolo de Reserva de Recursos [RFC2205, Versión 1 Functional

Specification] es un protocolo de señalización que proporciona un control para
la reserva, orientado fundamentalmente a redes IP. Es un componente clave de
la arquitectura de los Servicios Integrados en Internet IETF(IntServ) [29] en la
que se define el funcionamiento y la forma de petición e intercambio de
información entre y para cada elemento de la red y así realizar un control de la
calidad de servicio .

La reserva de recursos se realiza en los routers intermedios situados a lo

largo de toda la ruta de datos de la aplicación. Es, hasta el momento, la más
compleja de todas las tecnologías de QoS para las aplicaciones (hosts) y para
los distintos elementos de la red (encaminadores y puentes). Como resultado,
representa el mayor estándar creado desde el servicio best effort de las redes
IP, proporcionando el mayor nivel de QoS en términos de servicio garantizado,
granularidad de localización de recursos y el mayor detalle sobre la forma de
actuación de aplicaciones y usuarios que proporcionan QoS.

RSVP fue creado en 1990 por IETF, definiendo un modelo de

asignación de QoS en el que cada receptor (para una sesión) fuese
responsable de elegir su propio nivel de reserva de recursos, iniciando la
reserva y manteniéndola activa tanto tiempo como desee. Consistiendo, pues,
en una solución distribuida que permite a múltiples receptores heterogéneos
efectuar reservas específicamente dimensionadas según sus propias
necesidades. Además, para mantener el control el receptor puede enviar sus
especificaciones a la fuente encargada de solicitar las reservas de la red. En
definitiva, RSVP permite que las aplicaciones soliciten una calidad de
servicio específica a la red. En vez de un protocolo de encaminamiento es
más bien un protocolo de control de Internet. Su tarea consiste en establecer y
mantener las reservas de recursos en un árbol de distribución, con
independencia de cómo se hayan creado.

El grupo de trabajo Integrated Services del IETF ha considerado la

existencia de varias clases de QoS, si bien actualmente sólo dos de éstas han
sido formalmente especificadas para ser utilizadas con RSVP:

Servicios garantizados (Guaranteed Service) (service_number 2)

[RFC2211]:

Este servicio proporciona un nivel de ancho de banda y un límite en el

retardo, garantizando la no existencia de pérdidas en colas. Está
pensado para aplicaciones con requerimientos en tiempo real, tales
como ciertas aplicaciones de audio y vídeo. Cada router caracteriza el
SG para un flujo específico asignando un ancho de banda y un espacio
en buffer

Servicio de Carga Controlada (Controlled-Load Service)

(service_number 5)[RFC2212]:

A diferencia del SG este servicio no ofrece garantías en la entrega de los

paquetes. Así, será adecuado para aquellas aplicaciones que toleren
una cierta cantidad de pérdidas y un retardo mantenidos en un nivel
razonable. Los routers que implementen este servicio deben verificar
que el tráfico recibido siga las especificaciones dadas por el Tspec, y
 cualquier tráfico que no las cumpla será reenviado por la red, como
tráfico best-effort.

2.1 TOMA DE DECISIONES

Para la toma de decisiones de QoS asociadas a los paquetes de una

aplicación, RSVP interactúa con las entidades denominadas packet
classifier (clasificador de paquetes) y packet scheduler (programador de
paquetes) instaladas en el host. Primero consulta a los módulos las decisiones
locales para saber si la QoS deseada puede ser provista (bien mediante
decisiones basadas en recursos o bien mediante decisiones basadas en
políticas) y, en consecuencia, establece los parámetros requeridos en el
clasificador y en el programador del paquete.

El clasificar de paquetes determina la ruta del paquete y el programador

toma las decisiones de envío para alcanzar la QoS deseada, negociando, si es
necesario, con aquellos host que tengan capacidad propia de gestión de QoS,
para proporcional la calidad solicitada por RSVP.

Algunas características o aspectos fundamentales en el RSVP son:

Merging: En los diferentes nodos que se van atravesando en la red por

el camino de datos, se va realizando un proceso de concentración de los
diferentes mensajes de petición de reservas.

Estado de reserva en cada nodo: El estado soft RSVP se crea y

refresca periódicamente por mensajes Path y Resv. Permite observar el
estado en que se encuentran las reservas de recursos.

Estilos de reserva: Una petición de reserva incluye un conjunto de

opciones que se conocen como el estilo de reserva. Las distintas
combinaciones de estas opciones conforman los tres estilos de reserva en
uso, Wildcar-Filter (filtro libre) (WF), Fixed-Filter (filtro fijado) (FF) y Shared-
Explicit (explícito compartido) (SE).

2.2 TIPOS DE MENSAJES

 Existen dos tipos de mensajes en RSVP fundamentales, Resv y Path.
Una aplicación solicita participar en una sesión RSVP como emisor, enviando
un mensaje Path en el mismo sentido que el flujo de datos, por las rutas
uni/multicast proporcionadas por el protocolo de routing. A la recepción de este
mensaje, el receptor transmite un mensaje Resv, dirigido hacia el emisor de
los datos, siguiendo exactamente el camino inverso al de los mismos, en el
cual se especifica el tipo de reserva a realizar en todo el camino.

En la siguiente figura se pueden visualizar los mensajes descritos así

como su intercambio.
Figura 22. Intercambio de mensajes en RSVP.
MENSAJE PATH

En general, sin especificar tipos de QoS un mensaje Path, contiene:

Sender Template: Parámetro por el cual se describe el formato de los

paquetes que el emisor generará

Sender Tspec: Describe el tráfico que la aplicación estima que

generará.

Adspec: Información sobre la QoS y propiedades de la aplicación

Dirección del PHOP: Necesaria para poder encaminar los mensajes

Resv.

De entre estos, para la gestión de QoS, se utilizan los objetos :

Sender Tspec : Lista los servicios de control de QoS ofrecidos por el

remitente y el ancho de banda que requieren. Los encaminadores
intermedios anotan esta opción y reexpiden el mensaje sin modificarlo.

Adspec: Contiene información tal como la disponibilidad de un

determinado servicio de control QoS en el encaminador y los recursos
disponibles para cada uno de los servicios de control. Cada encaminador
intermedio introduce modificaciones en este objeto, para reflejar sus
posibilidades; cuando el mensaje PATH llega a un receptor, el ADSPEC
contiene un resumen de los servicios QoS disponibles en la ruta de datos.

En cada elemento de red, el ADSPEC se pasará al módulo de control

de tráfico, el cual determinará si el servicio QoS especificado está
implementado en el nodo. Por defecto se generará un objeto que
soportará todos los servicios QoS que admite el emisor. Cuando el
mensaje Path llega a un receptor, los datos
del SENDER_TSPEC yADSPEC se pasan a través de la API
(Aplication Programming Interface) a la aplicación, la cual interpretará
estos datos, y los utilizará para seleccionar parámetros de reserva de
recursos.
MENSAJE RESV

En el caso de los mensajes RESV nos encontramos con :

Especificaciones de flujo o FLOWSPEC

Las flowspec especifican los recursos a reservar para la sesión: los

requisitos de ancho de banda y los retardos que se precisan,
estableciendo los parámetros en elpacket scheduler del nodo.

Especificaciones de filtro o FILTERSPEC

Los filter spec que indican qué subconjunto de paquetes de la sesión

han de recibir la QoS definida por las flowspecs, para ello utilizan
cualquier campo de las cabeceras de protocolo o de las cabeceras de
aplicaciones (discriminar por dirección de origen, por aplicación de
destino, por el puerto, por el protocolo, etc.).

Existen distintos tipos de filtros:

a. Filtro comodín : el receptor reserva recursos que son

comunes a todos los emisores del grupo multienvío. (Usado
por ejemplo en audio conferencias, en las que solo hay un
emisor a la vez: los recursos se reservan para todo el grupo,
sea cual sea el emisor).

b. Filtro fijo: El receptor especifica una fuente concreta o una

lista de fuentes específicas. (Usado cuando el receptor se
suscribe a una película o a un “canal de TV de Internet”: los
recursos se reservan solo para ese canal ).

c. Filtro dinámico : El receptor especifica un conjunto de

canales a los que se aplica la reserva. (Usado en
videoconferencias, donde sólo hay un número máximo de
cámaras activas a la vez: por ejemplo, si sólo están activas la
cámara del que pregunta y la del que responde, se reservarían
recursos para dos canales).

Aun cuando las peticiones de reserva RSVP se originan en el

receptor final, es en la estación del emisor donde se produce el control
QoS.
 2.3 IMPLEMENTACIONES RSVP/QoS

A partir de las especificaciones publicadas en los diferentes RFCs

([2205], [2206], [2207], [2208], [2209]), más de 30 empresas del mundo de la
informática y las telecomunicaciones han decidido realizar diferentes
implementaciones del protocolo, tanto en su comportamiento como router como
en el de host, junto con la realización de diferentes herramientas de aplicación.

Vamos a analizar el estado actual de dichas implementaciones para

aquellas empresas más destacadas del sector, teniendo en cuenta el sistema
operativo utilizado, la tecnología de red, la capacidad de QoS, las aplicaciones,
qué características no son soportadas, la interoperabilidad y la disponibilidad
del producto. Así:

Los sistemas operativos utilizados están en función del sistema que

cada compañía utiliza en sus equipos, siendo los sistemas más
utilizados: Solaris, Linux, Windows 95 yFree-BSD, cada uno de ellos en sus
versiones actuales.

La tecnología de red utilizada es prácticamente común en casi todas

ellas: ATM, Frame Relay, Ethernet shared, Ethernet switched, Token
Ring y FDDI.

Respecto a la capacidad de QoS, todos los productos cumplen con las

especificaciones de RSVP y de Integrated Services ofreciendo
servicio Controlled Load. ElGuaranteed Service sólo está disponible en una
decena de implementaciones. La opción Differentiated Services es
minoritaria encontrándose en proceso de implantación en algún caso.

Los productos realizados se ofrecen para aplicaciones de telefonía y

videoconferencia esencialmente, y en algún caso se proponen para ser
utilizados en asignación de ancho de banda para usuarios preferentes
y Virtual Dedicated Network/VPN.

La disponibilidad está dividida entre productos en venta y productos

gratuitos disponibles al público. El resto son de uso interno, gratis sólo para
organizaciones o bien se encuentran incluidos en otros productos del mismo
fabricante.
 En las siguientes tablas se presentan el estado actual de las
implementaciones para distintas empresas:

COMPAÑÍA CISCO DEC FORE HP

PLATAFORMA Router Host Router, Host

host,
Toolkit

SISTEMA OPERATIVO IOS Digital Unix ---------- HP-UX

TECNO. DE RED ATM, Eth, T.Ring, ---------- Eth

FDDI
FRL,Eth,
T.Ring,
FDDI

DISPONIBILIDAD Venta Público y gratis Uso Gratis

interno empresas

QoS CL CL CL, GS CL

APLICACIONES Telefonía, Telefonia, Uso --------

Videocon router
Videoconferenc.

NO SOPORTA Ipv6, UDP Tunel, GS,

IPESEC diagnost.
encap., IPSEC IPSEC,

MIB

INTEROPERATIBILIDAD ISI, Intel, Sun Solaris, --------- Cisco

MS MS, W’NT Router
 COMPAÑÍA IBM INTEL MS SUN

PLATAFORMA Router Router, Host Host,

Host toolkit

SISTEMA OPERATIVO IBM W95, W95, W98, W’NT Solaris

W’NT

TECNO. DE RED ATM, ------- ATM, Eth, T.Ring, ---------

FDDI
FRL,Eth,

T.Ring,
FDDI

DISPONIBILIDAD Productos Venta Con W98 y W’NT Venta

IBM

QoS CL CL CL, GS CL

APLICACIONES VDN/VPN ------- Telefonía, videocon. ---------

NO SOPORTA Blockade --------- ------- Confirm,

state, MIB

MIB

INTEROPERATIBILIDAD Intel W’95 Cisco, Sun Cisco, Intel, Sun ---------

Solaris host

Es interesante conocer cuales son las características del protocolo que

todavía no están implementadas y que cada fabricante, en función del grado de
desarrollo que tenga su producto, indica como futuras realizaciones. Así, la
compatibilidad con el protocolo IPv6, el servicio Guaranteed y el IPSEC son las
referencias de no implementación más señaladas. Además, algunos productos
no contemplan encapsulación UDP, realización de túneles para el paso por
redes no-RSVP, mensajes de diagnóstico y autentificación.

Por último, algunos fabricantes han comprobado la interoperabilidad con

otras plataformas aunque no indican el grado de efectividad conseguido. Así,
26 de los 39 productos han sido testeados con otras implementaciones, de
entre las que destacan Cisco router, Windows 95 y Solaris.
 2.4 RSVP API (RAPI)

Estudiemos ahora el posible funcionamiento de la RSVP API (RSVP

Aplication Programming Interface) en un sistema UNÍS [30]. Esta va a
proporcionar a la aplicación los mecanismos necesarios para comunicarse con
el RSVP daemon de tal forma que se pueda realizar la reserva oportuna en
todo el camino de datos , tal y como se muestra en la siguiente figura.

Figura 23. Estructura de RSVP API. en UNIX

Un proceso RSVP se inicia a partir de la llamada SESSION definida por

la dirección destino, el identificador de protocolo y un puerto destino. Si la
llamada tiene éxito, retorna un identificador de sesión. Cuando una aplicación
desea iniciar el envío de un flujo de datos, activa la llamada SENDER que
define los atributos de dicho flujo, a partir de los siguientes parámetros:

Source_Address: dirección del interface desde el cual se enviarán los

datos. Este parámetro sólo en necesario en hosts multihomed.

Source_Port: puerto UDP/TCP .

Sender_Tspec: describe el flujo de datos que se desea enviar.

 Adspec: informa sobre el estado de la red para poder iniciar el cálculo
de las propiedades de QoS que se establecerán en el camino.

Los parámetros Data_TTL, Policy_data y Sender_Template son

opcionales en las versiones actuales de RAPI [31].

Una vez activada la llamada SENDER para la sesión registrada con el

identificador session_id, RSVP empieza a enviar mensajes Path hacia el
receptor a través de la red. Cuando un mensaje Path llega al receptor se activa
la función PATH_EVENT que entrega la información recibida a la aplicación
para que realice los cálculos de la QoS necesaria.

El receptor activa la llamada RESERVE y el RSVP daemon empieza a

enviar mensajes Resv que contienen los objetos necesarios
(Flowspec, Filterspec,...) para establecer la reserva a través del camino de
datos.

Tanto los mensajes Path como los mensajes Resv se van generando
periódicamente para refrescar el estado del camino, hasta que la sesión
finaliza.

Una vez realizada la transmisión de los datos, se activa la

llamada RELEASE que generará
mensajes Teardown (PATH_TEAR y RESV_TEAR) para que cese el envío de
mensajes de refresco finalizando, de esta forma, el estado RSVP para la actual
sesión.

2.5 EXPERIENCIAS [32]

Las pruebas realizadas para comprobar el funcionamiento del

protocolo RSVP se han hecho sobre diferentes plataformas pertenecientes a la
infraestructura del CCABA(Centre de Comunicacions Avançades de banda
Ampla) y enmarcadas en el proyecto SABA (Servicios para la red Académica
de Banda Ancha). A tal efecto se ha utilizado la versión RSVP Release 4.2a3,
generada por el Computer Science Department de la Columbia University para
la versión Linux, y la generada por el USC Information Sciences Institute para
la versión de Solaris, basada en un RSVP daemon o RSVPD y un RTAP, para
la realización de pruebas entre el daemon RSVP y la RAPI.
 Las pruebas han sido las siguientes (ver la Figura 24) :

sesión unicast entre dos equipos de la misma LAN bajo los mismos
sistemas operativos (SUN,SOLARIS). Los resultados obtenidos son,
correcto envío y recepción de mensajes Path y Resv.

sesión unicast entre dos equipos de la misma LAN bajos sistemas

operativos diferentes (LINUX[@IP:193.146.185.122] -
SOLARIS[@IP:193.146.185.121]). Los resultados obtenidos son: correcto
envío y recepción de mensajes Path y Resv de LINUX a SOLARIS.

sesión unicast entre dos equipos de la misma LAN con un router en

medio.

sesión unicast entre Windows95 y SOLARIS con un router en medio.

Entre PC y router existe una Ethernet, y entre router y SUN, LANE. Los
resultados obtenidos son la visualización de mensajes Path.

Figura 24. Ejemplo de funcionamiento.

1. Aplicación solicita una sesión RSVP. Tspec(M)¬ max(tam.paq.)

2. Mensaje Path. El parámetro PATH_MTU ¬ min(MTU) del path

3. Nodo: ADSPEC ® Control Tráfico: servicio QoS no

implementado Þ Break bit=1

SENDER_TSPEC ® parámetros flujo datos del emisor

4. Mensaje Path en receptor. Interpreta parámetro de ADSPEC y
SENDER_TSPEC

5. Aplicación entrega a RSVP:TSPEC(M) ¬ min(PATH_MTU) y

Nivel servicio (Rspec)

6. Mensaje Resv a emisor. Utiliza el parámetro M para el tamaño

de los paquetes

2.6 DESCRIPCIÓN DE PROBLEMAS

Describamos ahora los problemas sobre la experiencia realizada sobre

RSVP.

Hay tres problemas fundamentales que afectan al funcionamiento del

protocolo RSVP, la escalabilidad, el routing y el no poder trabajar sobre redes
no RSVP.

El problema de la escalabilidad existe, dada la gran cantidad de

señalización que aparecerá conforme la red vaya aumentando de tamaño,
tanto en cuanto a rutas como en cuanto a usuarios.

El routing conlleva un problema, dado que el proceso de

encaminamiento se realiza en el instante de establecer la sesión y enviar el
mensaje Path. En este punto, los algoritmos de encaminamiento utilizados
no tienen en cuenta cuales van a ser las características de reserva
solicitadas por el receptor, con lo cual puede que la decisión adoptada para
establecer la ruta, no sea la más adecuada teniendo en cuenta sólo los
parámetros de caracterización del tipo de QoS elegido.

La certeza de que la ruta establecida podrá contener dispositivos

intermedios que no implementen el protocolo RSVP, hará que la reserva
extremo a extremo esté condicionada por dichos sistemas.
Respecto a las experiencias realizadas, es preciso comentar que es
necesario conseguir una interoperabilidad completa entre los diferentes
sistemas tanto para sesiones unicast como para sesiones multicast junto con la
obtención de reservas correctas en los diferentes nodos en presencia de tráfico
interferente.

Volver arriba
3 DIFFSERV

Differentiated Services (DiffServ or DS) es un protocolo de QoS

propuesto por IETF [RFC 2475 y RFC 2474] que permite distinguir diferentes
clases de servicio marcando los paquetes. Permite a los proveedores de
servicios Internet y a usuarios de grandes redes IP corporativas desplegar
rápidamente diferentes niveles QoS en la troncal. A diferencia de RSVP no
especifica un sistema de señalización, consiste en un método para marcar
o etiquetar paquetes, permitiendo a los routers modificar su comportamiento
de envío. Cada tipo de etiqueta representa un determinado tipo de QoS y el
tráfico con la misma etiqueta se trata de la misma forma.

Para proporcionar los diferentes niveles de servicio utiliza el campo type

of service (TOS) o Diffserv Codepoint (DSCP) de la cabecera del estándar Ipv4
e Ipv6. Éste es un campo de 8 bits, estando los 2 últimos reservados. Con los 6
bits restantes se consiguen 64 combinaciones: 48 para el espacio global y 16
para uso local.

Figura 25. Datagrama Ipv4.

Este tipo de funcionamiento de QoS se ve sustentado con los Service

Level Agreement (SLA) o acuerdos de nivel de servicio entre el cliente y su
proveedor de servicios (por ejemplo, Internet Service Provider (ISP)). Como
vimos en el capítulo 1, un SLA básicamente especifica las clases de servicio
soportadas y la cantidad de tráfico permitida en cada clase. Los SLA pueden
ser estáticos o dinámicos, según si la negociación se hace de forma
cuasipermanente (ej. mensualmente) o de forma dinámica según las
necesidades de cada momento (en este caso los clientes deben usar
protocolos de señalización como RSVP).

A continuación vamos a explicar los componentes que forman parte de

este protocolo, así como su funcionamiento.

3.1 TIPOS DE MARCAS

Para clasificar el tráfico mediante DiffServ, se proponen básicamente

tres opciones de marcas:

a) None (Ninguna) : ofrece el servicio Best Effort convencional.

b) Assured and in profile (asegurado y definida dentro del perfil) :

definida en el SLA entre el cliente y el proveedor de servicio.

c) Assured and out of profile (asegurado y fuera de perfil): no

cumpliría lo definido en el SLA entre el cliente y el proveedor de
servicio.

3.2 CLASES DE SERVICIO

El protocolo Diffserv ha definido dos tipos de clases de servicio: el

servicio Premium y el servicio Asegurado (Assured Service), aunque soporta,
además, el convencional servicio Best Effort.

A) Premium Service
: proporciona bajo retardo y bajo nivel de jitter para aquellos clientes
que generen grandes picos tráfico. Este nivel de servicio está
especificado en el SLA que el cliente contrata con el ISP. El SLA
especifica la velocidad pico deseada y ofrecida y el ancho de banda
proporcionado. El ISP debe responsabilizarse de proporcionarla y el
cliente en no superar esa tasa.

Este tipo de servicio es el apropiado para la Telefonía por Internet,

la videoconferencia o, por ejemplo, para la creación de líneas virtuales
en redes privadas virtuales (VPNs).

Su precio es mayor que para el Assured Service.

 B) Assured
Services : Es escogido por aquellos clientes que necesitan un cierto
nivel de fiabilidad de sus ISPs incluso si existe congestión. Sus
especificaciones también vienen determinadas en los SLAs. En éste se
indica la cantidad de ancho de banda disponible para el cliente, pero
será el cliente el responsable de decidir cómo compartirán sus
aplicaciones el ancho de banda.

Las aplicaciones apropiadas son las mismas que las que utilizarían el
servicio Best Effort.

3.3 ENVÍO DE PAQUETES

El proceso de envío de los paquetes modificados por Diffserv desde un

router se conocen como PHB, Per Hop Behavior policies o “comportamiento
por salto”. El PHB indica qué tratamiento han recibido los paquetes a lo largo
de su transmisión para entregar Diffserv, tales como: tipos de políticas
aplicados, conformación del tráfico, posibles remarcados en el campo DS,
encolamientos y gestión del tráfico.

Existen varios tipos de PHBs:

B) Expedited Forwarding (EF) : Tiene un

solo valor de DiffServ (codpoint). Minimiza el retardo, el jitter y asegura
baja pérdida de paquetes, proporcionando el mayor nivel de QoS.

C) Assured Fordwarding (AF) : Define cuatro clases de

probabilidad de tráfico, con 3 variaciones en cada una. La probabilidad
de entrega no es tan alta como en EF, provocándose retardos.

D) Default (DE) : Funciona como el servicio Best Effort,

tradicional.
 Figura 26: Differentiated Services Code Points (DSCP) redefine el byte
Ipv4 ToS. Los bits IP Precedence son preservados en los puntos del selector
de clases y en los Pbs., pero los valores ToS no.

El borrador de Diffserv define además la implementación del protocolo

en dos tipos de routers: condicionadores de tráfico y capacitados para DS.

1. Clasificador de
tráfico (capacitados para DS)

El clasificador de tráfico selecciona los paquetes basándose en uno o

varios campos de cabecera. Aportan, por lo tanto, funciones de programación y
deben modificar su comportamiento de envío en función de las marcas o
etiquetas.

Como vimos, esta diferenciación se realiza utilizando el campo DS

(TOS), proporcionando un máximo de 64 clases de servicio. Cada router
ordena los paquetes en colas basándose en el citado campo, aplicando
diferentes políticas de priorización a las mismas.

Los routers capacitados para DS suelen ser los routers de troncal.

2. Condicionadores
de tráfico

Altera los paquetes para que cumplan las reglas de los servicios.
Rinden, por lo tanto, funciones sofisticadas de etiquetado, modelado y
monitorización. Normalmente se trata de los routers de acceso a la red.
 En la siguiente figura podemos comprobar el funcionamiento de los
PHBs. (comportamiento por salto ) en los encaminadores, visualizando cómo
se clasifica, marca y condiciona el tráfico en los mismos de acuerdo a unos
criterios de política predeterminados. El tráfico será marcado y encaminado de
acuerdo a las marcas.

Figura 27: Arquitectura de Diffserv. Esta funcionalidad está activada en cada

router habilitado para ofrecer Diffserv, aunque no todas las funciones se utilizan
 al mismo tiempo. Casi todos los routers extremos la utilizan, no tanto los
routers interiores.

3.4 CONCLUSIONES

Como hemos visto Diffserv es un protocolo simple, flexible y, hasta el

momento, bastante aceptado por los usuarios, fabricantes y los proveedores de
servicios, convirtiéndose, por lo tanto, como una de las mejores opciones para
la obtención de QoS extremo a extremo.

Volver arriba

4 MPLS (Multiprotocol Label Switching)

El Multiprotocolo de etiquetado de conmutación (MPLS) es un estándar

emergente del IETF que surgió para consensuar diferentes soluciones de
conmutación multinivel, propuestas por distintos fabricantes a mitad de los 90.
Cisco ha sido una empresa pionera al proporcionar una solución pre-
estandarizada MPLS a la conmutación por etiquetas.

Como concepto, MPLS es a veces un tanto difícil de explicar. Como

protocolo es bastante sencillo, pero las implicaciones que supone su
implementación real son enormemente complejas. Según el énfasis (o interés)
que se ponga a la hora de explicar sus características y utilidad, MPLS se
puede presentar como un sustituto de la conocida arquitectura IP sobre ATM.
También como un protocolo para hacer túneles (sustituyendo a las técnicas
habituales de "tunneling"). O bien, como una técnica para acelerar el
encaminamiento de paquetes... incluso, ¿para eliminar por completo el routing?
En realidad, MPLS hace un poco de todo eso, ya que integra sin
discontinuidades los niveles 2 (transporte) y 3 (red), combinando eficazmente
las funciones de control del routing con la simplicidad y rapidez de la
conmutación de nivel

Pero, ante todo y sobre todo, debemos considerar MPLS como el

avance más reciente en la evolución de las tecnologías
de routing y forwarding en las redes IP, lo que implica una evolución en la
manera de construir y gestionar estas redes, las redes IP que queremos ver en
el próximo milenio. Los problemas que presentan las soluciones actuales de IP
sobre ATM, tales como la expansión sobre una topología virtual superpuesta,
así como la complejidad de gestión de dos redes separadas y
tecnológicamente diferentes, quedan resueltos con MPLS. Al combinar en uno
solo lo mejor de cada nivel (la inteligencia del routing con la rapidez
del switching), MPLS ofrece nuevas posibilidades en la gestión debackbones,
así como en la provisión de nuevos servicios de valor añadido.

MPLS usa, básicamente, un esquema de etiquetado del tráfico hacia

delante : el tráfico es marcado en su entrada a la red pero no en los puntos de
salida. Reside únicamente en los routers y es independiente del protocolo
utilizado (de ahí lo de “multi-protocol”), lo que permite que pueda ser utilizado
sobre otros protocolos distintos a IP, como IPX, ATME, PPP, Ethernet, Frame
Relay, sobre SONET y Token ring.

Este protocolo combina algunas de las prestaciones de las redes

orientadas a la conexión con las de las redes sin conexión. Permite a un router
o a un conmutador asignar una etiqueta a cada una de las entradas de la tabla
de routing y comunicar esa etiqueta a los routers y conmutadores vecinos.
Cuando uno de estos dispositivos pasa un paquete al más próximo, el router o
el conmutador añade a ese paquete una etiqueta asociada con la entrada de
tabla de routing. La etiqueta permite al router o conmutador identificar el
próximo salto o saltos sin mirar la dirección. La idea es, por tanto, posibilitar
que los paquetes etiquetados fluyan de extremo a extremo sin forzar a los
routers o conmutadores a mirar las direcciones.

4.1 FORMATO DE LAS ETIQUETAS

Cada paquete MPLS tiene una cabecera que contiene 20 bits para
etiquetato, un campo de 3 bits para especificar la Clase de Servicio (CoS), 1 bit
que funciona como indicador de etiquetas y un campo de 8 bits que indica el
tiempo de vida (Time-to-live (TTL)). Ver la siguiente figura:
 Figura 28 : Etiquetado de MPLS.

Estudiemos ahora el funcionamiento de este protocolo.

4.2 ELEMENTOS DE MPLS Y FUNCIONAMIENTO

Dentro de la terminología de las redes MPLS vamos a oír hablar mucho

del LSP y del LSR.

1) Label
Switched Paths (LSP) : es el protocolo que utiliza MPLS para la distribución de
etiquetas. Está incluido dentro de un protocolo genérico denominado Label
Distribution Protocol (LDP). Un LSP es similar a un circuito virtual en ATM y es,
además unidireccional, desde el emisor hasta el receptor.

2) Label
Switched Router (LSR) : es el tipo de routers que permiten MPLS. Los MPLSs
miran la escritura de la etiqueta asociada a un paquete entrante, y la utilizan
como índice en un vector para determinar la conexión de salida a la cual el
paquete debe ser remitido. El LSR entonces asignará típicamente una nueva
escritura de la etiqueta y remitirá el paquete en la conexión de salida. Cada
paquete es remitido salto a salto a través de la red de MPLS, tan solo con
escribir en la etiqueta en cada nodo LSR.
 Figura 29. Detalle de la tabla de envío de un LSR

Mientras que cada escritura de la etiqueta tiene significación local

solamente (es decir, puede ser diferente en cada conexión), el efecto es crear
un camino extremo a extremo a través de la red de MPLS. Observe que la red
de MPLS no encamina el tráfico basado en los direccionamientos IP del
paquete, ni encamina basándose en la información del ATM VCI/VPI
(identificador del circuito virtual o del camino). Así una red abarcada de nodos
de LSR no es una red IP o una red ATM -- es una nueva y diversa red de
MPLS.

Figura 30. Esquema funcional del MPLS

 Una de las capacidades que hace MPLS especial es que el primer MPLS
LSR en la red (es decir, el nodo del ingreso de MPLS) puede establecer una
ruta explícita a través de la red de MPLS; el nodo del ingreso puede especificar
exactamente qué secuencia de MPLS LSRs y conexiones se debe utilizar para
diversos tipos de tráfico para alcanzar cada destino.

Las rutas explícitas de MPLS se pueden elegir en respuesta a muchos y

diversos criterios, incluyendo cargas del tráfico de la red, anchura de banda
disponible, costes administrativos, retardo del camino, la variación del retardo
(inquietud), la cuenta del salto, la relación de transformación de la pérdida de la
célula, etc. Esta capacidad, a veces llamado "constraint-based routing" (un
sobreconjunto del encaminamiento de QoS), es inexistente en los routers IP, la
mayoría de los cuales utilizan solamente la métrica del camino más corto para
calcular las rutas y su comportamiento está limitado al salto-a-salto.

Con este tipo de encaminamiento (constraint based routing) y las rutas

explícitas, las redes de MPLS se pueden diseñar para resolver muchas
métricas de calidad del servicio, haciéndolas ideales para las redes troncales
de los ISPs. El nodo del ingreso de la red de MPLS tiene que ser bastante
inteligente para clasificar el tráfico y determinar el camino apropiado (LSP) para
cada flujo; este nodo de ingreso aplica la misma escritura de la etiqueta a todos
los paquetes con el mismo nivel de QoS y los envía al mismo nodo de salida
de MPLS. Sin embargo, esta opción no tiene por qué ser realizada por todos
los nodos de la red MPLS; algunos sencillamente marcan las etiquetas y las
reexpiden al siguiente nodo.

Figura 31. Ejemplo de envío de un paquete por un LSP

 4.3 PRINCIPALES APLICACIONES DE MPLS

Las principales aplicaciones que hoy en día tiene MPLS son:

Ingeniería de tráfico

Diferenciación de niveles de servicio mediante clases (CoS)

Servicio de redes privadas virtuales (VPN)

Veamos brevemente las características de estas aplicaciones y las

ventajas que MPLS supone para ello frente a otras soluciones tradicionales.

1 Ingeniería de tráfico

El objetivo básico de la ingeniería de tráfico es adaptar los flujos de

tráfico a los recursos físicos de la red. La idea es equilibrar de forma óptima la
utilización de esos recursos, de manera que no haya algunos que estén
suprautilizados, con posibles puntos calientes y cuellos de botella, mientras
otros puedan estar infrautilizados. A comienzos de los 90 los esquemas para
adaptar de forma efectiva los flujos de tráfico a la topología física de las redes
IP eran bastante rudimentarios. Los flujos de tráfico siguen el camino más corto
calculado por el algoritmo IGP correspondiente. En casos de congestión de
algunos enlaces, el problema se resolvía a base de añadir más capacidad a los
enlaces. La ingeniería de tráfico consiste en trasladar determinados flujos
seleccionados por el algoritmo IGP sobre enlaces más congestionados, a otros
enlaces más descargados, aunque estén fuera de la ruta más corta (con menos
saltos).
 Figura 32 . Comparación entre camino más corto con ingeniería del tráfico

El camino más corto entre A y B según la métrica normal IGP es el que

tiene sólo dos saltos, pero puede que el exceso de tráfico sobre esos enlaces o
el esfuerzo de los routers correspondientes hagan aconsejable la utilización del
camino alternativo indicado con un salto más. MPLS es una herramienta
efectiva para esta aplicación en grandesbackbones, ya que:

Permite al administrador de la red el establecimiento de rutas explícitas,

especificando el camino físico exacto de un LSP.

Permite obtener estadísticas de uso LSP, que se pueden utilizar en la

planificación de la red y como herramientas de análisis de cuellos de botella
y carga de los enlaces, lo que resulta bastante útil para planes de expansión
futura.

Permite hacer "encaminamiento restringido" (Constraint-based Routing,

CBR), de modo que el administrador de la red pueda seleccionar
determinadas rutas para servicios especiales (distintos niveles de calidad).
Por ejemplo, con garantías explícitas de retardo, ancho de banda,
fluctuación, pérdida de paquetes, etc.

La ventaja de la ingeniería de tráfico MPLS es que se puede hacer

directamente sobre una red IP, al margen de que haya o no una infraestructura
ATM por debajo, todo ello de manera más flexible y con menores costes de
planificación y gestión para el administrador, y con mayor calidad de servicio
para los clientes.

2 Clases de servicio

MPLS está diseñado para poder cursar servicios diferenciados, según el

Modelo DiffServ del IETF. Este modelo define una variedad de mecanismos
para poder clasificar el tráfico en un reducido número de clases de servicio, con
diferentes prioridades. Según los requisitos de los usuarios, DiffServ permite
diferenciar servicios tradicionales tales como el WWW, el correo electrónico o
la transferencia de ficheros (para los que el retardo no es crítico), de otras
aplicaciones mucho más dependientes del retardo y de la variación del mismo,
como son las de vídeo y voz interactiva. Para ello se emplea el campo ToS
(Type of Service), rebautizado en DiffServ como el octeto DS. (Véase más
información sobre el modelo DiffServ en las referencias correspondientes a
QoS). Esta es la técnica QoS de marcar los paquetes que se envían a la red.

MPLS se adapta perfectamente a ese modelo, ya que las etiquetas

MPLS tienen el campo EXP para poder propagar la clase de servicio CoS en el
correspondiente LSP. De es te modo, una red MPLS puede transportar
distintas clases de tráfico, ya que:

el tráfico que fluye a través de un determinado LSP se puede asignar a

diferentes colas de salida en los diferentes saltos LSR, de acuerdo con la
información contenida en los bits del campo EXP

entre cada par de LSR exteriores se pueden provisionar múltiples LSPs,

cada uno de ellos con distintas prestaciones y con diferentes garantías de
ancho de banda. P. ej., un LSP puede ser para tráfico de máxima prioridad,
otro para una prioridad media y un tercero para tráfico best-effort, tres
niveles de servicio, primera, preferente y turista, que, lógicamente, tendrán
distintos precios.

3 Redes privadas virtuales

Una red privada virtual (VPN) se construye a base de conexiones

realizadas sobre una infraestructura compartida, con funcionalidades de red y
de seguridad equivalentes a las que se obtienen con una red privada. El
objetivo de las VPNs es el soporte de aplicaciones intra/extranet, integrando
aplicaciones multimedia de voz, datos y vídeo sobre infraestructuras de
comunicaciones eficaces y rentables. La seguridad supone aislamiento, y
"privada" indica que el usuario "cree" que posee los enlaces. Las IP VPNs son
soluciones de comunicación VPN basada en el protocolo de red IP de la
Internet. En esta sección se va a describir brevemente las ventajas que MPLS
ofrece para este tipo de redes frente a otras soluciones tradicionales.

Las VPNs tradicionales se han venido construyendo sobre

infraestructuras de transmisión compartidas con características implícitas de
seguridad y respuesta predeterminada. Tal es el caso de las redes de datos
Frame Relay, que permiten establecer PCVs entre los diversos nodos que
conforman la VPN. La seguridad y las garantías las proporcionan la separación
de tráficos por PVC y el caudal asegurado (CIR). Algo similar se puede hacer
con ATM, con diversas clases de garantías. Los inconvenientes de este tipo de
solución es que la configuración de las rutas se basa en procedimientos más
bien artesanales, al tener que establecer cada PVC entre nodos, con la
complejidad que esto supone al proveedor en la gestión (y los mayores costes
asociados). Si se quiere tener conectados a todos con todos, en una topología
lógica totalmente mallada, añadir un nuevo emplazamiento supone retocar
todos los CPEs del cliente y restablecer todos los PVCs. (Algo similar a lo que
se vio en la solución IP sobre ATM de la sección 2).

Además, la popularización de las aplicaciones TCP/IP, así como la

expansión de las redes de los NSPs, ha llevado a tratar de utilizar estas
infraestructuras IP para el soporte de VPNs, tratando de conseguir una mayor
flexibilidad en el diseño e implantación y unos menores costes de gestión y
provisión de servicio. La forma de utilizar las infraestructuras IP para servicio
VPN (IP VPN) ha sido la de construir túneles IP de diversos modos.

El objetivo de un túnel sobre IP es crear una asociación permanente

entre dos extremos, de modo que funcionalmente aparezcan conectados. Lo
que se hace es utilizar una estructura no conectiva como IP para simular esas
conexiones: una especie de tuberías privadas por las que no puede entrar
nadie que no sea miembro de esa IP VPN. No es el objetivo de esta sección
una exposición completa de IP VPNs sobre túneles; se pretende tan sólo
resumir sus características para poder apreciar luego las ventajas que ofrece
MPLS frente a esas soluciones. Se puede obtener más información sobre IP
VPN con túneles en las referencias correspondientes a VPNs con MPLS.

Los túneles IP en conexiones dedicadas (no se va a tratar aquí de las

conexiones conmutadas de acceso) se pueden establecer de dos maneras:

En el nivel 3, mediante el protocolo IPSec del IETF

En el nivel 2, mediante el encapsulamiento de paquetes privados (IP u

otros) sobre una red IP pública de un NSP

En las VPNs basadas en tuneles IPSec, la seguridad requerida se

garantiza mediante el cifrado de la información de los datos y de la cabecera de
los paquetes IP, que se encapsulan con una nueva cabecera IP para su
transporte por la red del proveedor. Es relativamente sencillo de implementar,
bien sea en dispositivos especializados, tales como cortafuegos, como en los
propios routers de acceso del NSP. Además, como es un estándar, IPSec
permite crear VPNs a través de redes de distintos NSPs que sigan el estándar
IPSec. Pero como el cifrado IPSec oculta las cabeceras de los paquetes
originales, las opciones QoS son bastante limitadas, ya que la red no puede
distinguir flujos por aplicaciones para asignarles diferentes niveles de servicio.
Además, sólo vale para paquetes IP nativos, IPSec no admite otros protocolos.

En los túneles de nivel 2 se encapsulan paquetes multiprotocolo (no

necesariamente IP), sobre los datagramas IP de la red del NSP. De este modo,
la red del proveedor no pierde la visibilidad IP, por lo que hay mayores
posibilidades de QoS para priorizar el tráfico por tipo de aplicación IP. Los
clientes VPN pueden mantener su esquema privado de direcciones,
estableciendo grupos cerrados de usuarios, si así lo desean. (Además de
encapsular los paquetes, se puede cifrar la información por mayor seguridad,
pero en este caso limitando las opciones QoS). A diferencia de la opción
anterior, la operación de túneles de nivel 2 está condicionada a un único
proveedor.

A pesar de las ventajas de los túneles IP sobre los PVCs, ambos

enfoques tienen unas características comunes que las hacen menos eficientes
frente a la solución MPLS:

Están basadas en conexiones punto a punto (PVCs o túneles).

La configuración es manual.

La provisión y gestión son complicadas; una nueva conexión supone

alterar todas las configuraciones.

Plantean problemas de crecimiento al añadir nuevos túneles o circuitos

virtuales.

La gestión de QoS es posible en cierta medida, pero no se puede

mantener extremo a extremo a lo largo de la red, ya que no existen
mecanismos que sustenten los parámetros de calidad durante el transporte.

Realmente, el problema que plantean estas IP VPNs es que están

basadas en un modelo topológico superpuesto sobre la topología física
existente, a base de túneles extremos a extremo (o circuitos virtuales) entre
cada par de routers de cliente en cada VPN. De ahí las desventajas en cuanto
a la poca flexibilidad en la provisión y gestión del servicio, así como en el
crecimiento cuando se quieren añadir nuevos emplazamientos. Con una
arquitectura MPLS se obvian estos inconvenientes ya que el modelo topológico
no se superpone sino que se acopla a la red del proveedor. En
el modelo acoplado MPLS, en lugar de conexiones extremo a extremo entre
los distintos emplazamientos de una VPN, lo que hay son conexiones IP a una
"nube común" en las que solamente pueden entrar los miembros de la misma
VPN. Las "nubes" que representan las distintas VPNs se implementan
mediante los caminos LSPs creados por el mecanismo de intercambio de
etiquetas MPLS. Los LSPs son similares a los túneles en cuanto a que la red
transporta los paquetes del usuario (incluyendo las cabeceras) sin examinar el
contenido, a base de encapsularlos sobre otro protocolo. Aquí está la
diferencia: en los túneles se utiliza el encaminamiento convencional IP para
transportar la información del usuario, mientras que en MPLS esta información
se transporta sobre el mecanismo de intercambio de etiquetas, que no ve para
nada el proceso de routing IP. Sin embargo, sí se mantiene en todo momento
la visibilidad IP hacia el usuario, que no sabe nada rutas MPLS sino que ve una
internet privada (intranet) entre los miembros de su VPN. De este modo, se
pueden aplicar técnicas QoS basadas en el examen de la cabecera IP, que la
red MPLS podrá propagar hasta el destino, pudiendo así reservar ancho de
banda, priorizar aplicaciones, establecer CoS y optimizar los recursos de la red
con técnicas de ingeniería de tráfico.

Figura 33. Modelo “superpuesto” (túneles/PVCx) vs. Modelo “acoplado” (MPLS)

En la figura 10 se representa una comparación entre ambos modelos. La

diferencia entre los túneles IP convencionales (o los circuitos virtuales) y los
"túneles MPLS" (LSPs) está en que éstos se crean dentro de la red, a base de
LSPs, y no de extremo a extremo a través de la red.

Como resumen, las ventajas que MPLS ofrece para IP VPNs son:

Proporcionan un modelo "acoplado" o "inteligente", ya que la red MPLS

"sabe" de la existencia de VPNs (lo que no ocurre con túneles ni PVCs).

Evita la complejidad de los túneles y PVCs,

La provisión de servicio es sencilla: una nueva conexión afecta a un

solo router.

Tiene mayores opciones de crecimiento modular.

Permiten mantener garantías QoS extremo a extremo, pudiendo

separar flujos de tráfico por aplicaciones en diferentes clases, gracias al
vívculo que mantienen el campo EXP de las etiquetas MPLS con las clases
definidas a la entrada.

Permite aprovechar las posibilidades de ingeniería de tráfico para las

poder garantizar los parámetros críticos y la respuesta global de la red
(ancho banda, retardo, fluctuación...), lo que es necesario para un servicio
completo VPN.

4.4 CONCLUSIONES DE MPLS

Podrían resumirse las características más importantes de MPLS en las

siguientes:

MPLS es la manera más eficaz de integrar redes IP y ATM en la misma

red .

MPLS reduce los gastos indirectos de proceso en los routers IP,

mejorando el funcionamiento de la expedición de paquete.

MPLS es otra manera de proporcionar QoS en las espinas dorsales de

la red (backbone), compitiendo con otros protocolos tales como DiffServ,
IntServ/RSVP y ATM QoS.
 MPLS es superior a IP en la manera en que encamina tráfico, basando
decisiones de encaminamiento en algo más que calcular el camino más
corto.

MPLS será la mejor manera para que los proveedores de servicio

ofrezcan VPNs (redes privadas virtuales) que permitan medir la calidad de
servicio del cliente.

MPLS permitirá a los ISPs escalar sus redes y que resuelvan requisitos
de la ingeniería del tráfico sin tener que recurrir a redes ATM.

Su aplicación es mayoritariamente en redes WAN.

MPLS es, por tanto, una técnica con futuro, pues se trata una técnica
prometedora para integrar las redes ATM e IP, siguiendo las tendencias
generales de convergencia de redes que se suceden en la industria de hoy.

Volver arriba

5 SBM (Subnet Bandwidth Management)

Hasta ahora hemos estudiado cómo obtener QoS extremo a extremo

entre el emisor y el receptor, esto significa que cada router a lo largo de la ruta
debe soportar la tecnología de QoS que se esté usando, tal y como se vio en la
descripción de los anteriores protocolos de QoS, pero también hay que tener
en cuenta la posibilidad de conseguir QoS en los nodos finales (top-to-bottom).
Para ello es necesario que :

1. Los host emisor y receptor deben permitir la obtención de QoS,

siendo necesario que las aplicaciones la permitan explícitamente o,
en su nombre, que lo permita el sistema implícitamente. Cada capa
OSI, desde la de aplicación a capas inferiores, deben utilizar también
QoS para asegurar que las peticiones de alta prioridad sean tratadas
desde el host.
 2. Suponiendo que los sistemas finales se conecten a una red de
área local (LAN), éstas deben permitir QoS, de forma que las tramas
de alta prioridad sean tratadas primeramente mientras circulan por la
red (ej. de host-a-host, host-a-router, router-a-router). De esta forma
estamos proporcionando QoS en la capa 2 de OSI, capa de enlace,
mientras que los protocolos anteriores ofrecían QoS en otras capas:
Diffserv en la capa 3 y RSVP y MPLS en capas superiores.

Existen algunas tecnologías creadas para proporcionar QoS en la capa

de enlace, como ATM, pero ésta es una tecnología imposible de implementar
por algunas empresas, debido a su coste económico y a su complejidad. Todas
estas empresas, por el contrario, utilizan otras tecnologías más comunes para
sus LANs, tales como Ethernet, que originalmente no fueron diseñadas para
ofrecer QoS. Ethernet proporciona, simplemente, un servicio análogo al
prestado por IP, el servicio Best Effort, en el que existe la posibilidad de que se
produzcan retardos y variaciones (jitter) que pueden afectar a aplicaciones de
tiempo real. Por todas estas cosas, IEEE ha redefinido el estándar Ethernet y
otras tecnologías de la capa de enlace para proporcionar QoS, mediante
diferenciación de tráfico.

Los estándares de IEEE 802.1p, 802.1q y 802.1D definen cómo los

conmutadores Ethernet pueden clasificar las tramas para poder entregar en
primer lugar el tráfico considerado crítico. El grupo de trabajo del IETF para la
especificación de las capas de conexión (ISSL) se encarga de definir cómo
relacionar los distintos protocolos de QoS de capas superiores con las
diferentes tecnologías de la capa 2, como Ethernet. Entre otras cosas, el ISSL
ha desarrollado el protocolo Subnet Bandwidth Manager (SBM) o “Gestión del
ancho de banda de la subred” [33] para aplicarlo con LANs 802. SBM es un
protocolo de señalización que permite la comunicación y coordinación entre
nodos de la red y su relación con protocolos de QoS de capas superiores [34].

Un requisito fundamental en SBM es que todo el tráfico debe pasar por

lo menos por un conmutador que utilice SBM.

5.1 COMPONENTES DE SBM

Los principales componentes de SBM son:

 A) Distribuidor
de ancho de banda (Bandwidth Allocator, BA) : gestiona la
asignación de los recursos y realiza el control de admisión de acuerdo
a su disponibilidad y al resto de criterios definidos en la política de
servicio.

B) Módulo del
cliente (Requestor Module, RM) : reside en cada estación final. La
relación entre el RM y los parámetros de protocolos de QoS superiores
son definidas de acuerdo a una política determinada.

En la siguiente figura es posible observar cómo la localización del BA

determina el tipo de configuración de SBM en uso: centralizado o distribuido.
Además, cuando existe más de un BA por segmento de red, uno de ellos será
elegido como SBM (Designated SBM o DSBM).

Figura 34. Componentes de SBM

5.2 FUNCIONAMIENTO

Este protocolo utiliza un mecanismo de señalización entre RM y BA para

iniciar las reservas, consultar al BA los recursos disponibles y cambiar las
reservas. Este mecanismo suele ser RSVP. Para comprobarlo, tomaremos
como ejemplo cómo se realiza (de forma genérica) el procedimiento del control
de admisión en SBM:

1. El DSBM inicializa: consigue la disponibilidad de los recursos.

2. El cliente DSBM (cualquier host o router RSVP) busca el DSBM.

(Esta tarea esta monitorizada con el campo “AllSBMAddress”,
estando reservada como dirección IP multidifusión la 224.0.0.17).

3. El cliente envia un mensaje PATH con el campo

“DSBMLogicalAddress”.

4. Una vez recibido el PATH, el DSBM indica su estado en el

conmutador, almacenando la dirección de origen de capa 2 y capa 3
(L2/L3) y la pone en el mensaje, encaminándolo al próximo
conmutador.

5. Cuando el mensaje es un RSVP RESV, éste se envía hasta llegar

al primer encaminador.

6. DSBM evalúa la petición y si los recursos solicitados están

disponibles se lo indica al emisor.

Es, como vemos, un proceso muy parecido al ocurrido en los routers

RSVP.

Por otro lado, cualquier DSBM puede añadir un objeto denominado

TCLASS a los mensajes Resv o Path del protocolo RSVP. Este objeto contiene
información de prioridad basada en la norma 802.1p. De esta manera la
información de clase de servicio de las redes IEEE 802 puede ser transmitida
por la red.

Volver arriba

6 Arquitecturas de QoS

A continuación, vamos a exponer varias de las posibles arquitecturas

que se pueden dar de calidad de servicio mediante la utilización simultánea de
varios de los protocolos mencionados en el presente capítulo.
 6.1 INTRODUCCIÓN

Excepto para el caso de SBM que utiliza RSVP para la señalización,

para el resto de protocolos se estudió cómo actuaban de forma independiente
extremo a extremo; sin embargo, en la realidad se utilizan varios de estos
protocolos para la obtención de QoS extremo-a-extremo y en los nodos finales,
conformándose varias arquitecturas de QoS de las que se van a describir las
más utilizadas.

La figura siguiente muestra una vista general de cómo es posible

mezclar los distintos protocolos.

Figura 35 . Ejemplo de arquitectura de QoS.

Para comprender aún mejor las arquitecturas descritas a continuación

observar la figura 36 de la página 109. Esta proporciona un ejemplo completo
de cómo pueden trabajar juntas las distintas tecnologías de QoS para
proporcionar calidad de servicio extremo a extremo.

6.2 RSVP Y DIFFSERV EXTREMO A EXTREMO

 RSVP proporciona recursos para el tráfico de la red, mientras que
Diffserv simplemente marca y prioriza el tráfico. RSVP es más complejo y
demanda más actividad a los routers que Diffserv, por eso, normalmente se
utiliza DiffServ en el backbone.

A pesar de todo, Diffserv y RSVP se complementan perfectamente para

ofrecer QoS extremo a extremo. Los hosts finales pueden utilizar peticiones
RSVP con alta granularidad. Los routers situados a la entrada de la espina
dorsal de la red pueden asociar esas reservas RSVP a una determinada clase
de servicio, indicada por un byte DS y acordada en los acuerdos de servicios
(SLAs).

6.3 MPLS PARA RSVP

Existe una propuesta del IETF de usar un objeto en RSVP [35],

denominado, EXPLICIT_ROUTE, para predeterminar caminos que puedan ser
usados por flujos de RSVP. Estos flujos usan tuberías virtuales establecidos a
través de routers MPLS. Incluso sin el citado objeto, es posible para MPLS
asignar etiquetas de acuerdo al campoflowsepc de RSVP.

6.4 MPLS PARA DIFFSERV

Al ser DiffServ y MPLS similares, asociar el tráfico DiffServ sobre

tuberías MPLS (LSPs) es bastante sencillo.

Para soportar el modelo de DiffServ, un operador de red MPLS necesita

asignar una serie de recursos para cada clase Diffserv transmitida en cada
router MPLS y asignar, a su vez, etiquetas.
Figura 36: ilustra el posible uso de diferentes tecnologías de QoS trabajando
conjuntamente para proporcionar QoS extremo a extremo.
Qos EN ATM

El Modo de Transferencia Asíncrono (ATM) es una técnica de

transmisión y de conmutación de información digital de cualquier naturaleza
(voz, datos, imágenes) por paquetes de longitud fija denominados celdas.
Funciona en modo orientado a conexión, ya que todas las celdas siguen un
mismo camino que define una conexión virtual entre un emisor y uno o varios
receptores.

ATM ha sido concebido como una tecnología multiservicio capaz de

consolidar diversos servicios de red en una única red de banda ancha. Las
redes ATM transportan tráfico generado por una variedad de aplicaciones
debido a que su uso se extiende tanto en redes de área local (LAN) como en
redes de larga distancia (WAN). Por un lado, estas aplicaciones poseen
diferentes características de tráfico, y por el otro lado, también poseen
diferentes requerimientos de desempeño en la red. Por ejemplo, servicios de
voz y video requieren un retardo y jitter mínimo. Por el contrario, la
transferencia de datos pueden tolerar un retardo, pero deben ser capaces de
manejar datos por ráfagas y optimizar el uso del ancho de banda.

Con la finalidad de soportar este ambiente de múltiples aplicaciones, el

ATM Forum y la ITU han definido en la capa ATM una serie de categorías de
servicio. Cada una de estas categorías está especificada por una serie de
parámetros que describen el tráfico presente en la red y la Calidad de Servicio
(QoS) que debe suministrar la red. Con la finalidad de satisfacer los objetivos
de desempeño y QoS, han sido definidos una serie de mecanismos que
constituyen la esencia de la gestión del tráfico (traffic management). Las
categorías de servicio se extienden desde servicios Constant Bit Rate para
servicios sensibles al retardo, tales como voz y video, hasta servicios
Unspecified Bit Rate para servicios que pueden ofrecer una calidad best effort.
Cada categoría de servicio ha sido definida para satisfacer las necesidades del
los servicios existentes, y optimizar al mismo tiempo el uso de los recursos de
la red. Los principales objetivos del control de tráfico y congestión son proteger
a la red y al usuario con la finalidad de alcanzar objetivos predefinidos de
desempeño en la red, evitar congestión y optimizar el uso de los recursos de la
red con la finalidad de alcanzar una eficiencia adecuada en la red.
 A continuación vamos a exponer cómo es posible obtener la calidad de
servi-cio mencionada anteriormente. Evidentemente se va a tratar de una
forma genérica, pues este tema es de por sí lo suficientemente complejo
como para realizar un proyecto sobre el, tan solo hay que ver el gran número
de investigaciones que se están desarrollando, siendo un punto de encuentro
sobre las mismas el Foro de ATM, disponible en la página
web http://www.atmforum.com, referenciado al final de este proyecto.

1 Características de ATM

Para poder definir todas las funcionalidades del modo de transferencia

asíncrono para el soporte de distintos tipos de tráfico ofreciendo unas
garantías de calidad y un control de congestión, así como otras herramientas
mencionadas anteriormente es necesario estudiar cómo funciona esta
tecnología y qué servicios ofrece.

Empecemos con el direccionamiento.

1.1 Direccionamiento
Cada celda ATM enviada a través de la red contiene una información de
direccionamiento, la cual le permite establecer una conexión virtual desde el
origen hasta el destino. De esta manera, todas las celdas pertenecientes a esta
conexión son enviadas en secuencia a través de esta conexión virtual. ATM
Provee conexiones virtuales tanto permanentes (Permanent Virtual
Connections, PVCs) como conmutadas (Switched Virtual Connections, SVCs) .

1.2 Multiplexación

ATM posee la habilidad de multiplexar diversos tipos de servicios (voz,

video, datos, etc.) en una única red física no canalizada (unchannelized). Este
método de multiplexaje de las celdas ATM define el concepto de modo de
transferencia asíncrono, en donde el término asíncrono se refiere a la
capacidad de la red ATM de enviar datos asociados a una conexión sólo
cuando realmente hay datos que transmitir. En contraste con las redes
canalizadas (channelized), en donde aún cuando el canal está libre, es
necesario enviar un patrón especial en cada ranura de tiempo (time slot) que
representa a un canal libre. De lo contrario, el receptor no sería capaz de
recuperar la información presente en el resto de los time slots. Esta es la
esencia de las redes que emplean modos de transferencia síncronos, en
donde, a cada fuente se le asigna un ancho de banda fijo basada en una
posición, por ejemplo, una banda de frecuencia en FDM o un time slot en TDM.
El tráfico en ATM, por el contrario:

No está basado en una posición fija en el flujo de datos, ya que un

encabezamiento en la información ATM identifica hacia donde debe ser
dirigido el tráfico.

Es bajo demanda, en otras palabras, si no hay tráfico no se emplea

ancho de banda, por lo cual el ancho de banda disponible puede ser
empleado para otras conexiones. Esto, evidentemente, supone una gran
ventaja frente a otros sistemas.

1.3 Arquitectura

Los estándares de ATM han definido una celda de tamaño fijo con una
longitud de 53 octetos [36]. Consta de dos partes: la carga útil o payload de 48
octetos que transporta la información generada por un emisor o transmisor, y el
encabezamiento o header de 5 octetos que contiene la información necesaria
para la transferencia de la celda. Las celdas son enviadas sobre una estructura
de transmisión física, como por ejemplo el DS1, DS3 o SONET de Norte
América; el E1, E3, E4 o STM de Europa y Venezuela.

Figura 37. Celda ATM

La carga útil transporta la información generada por una fuente. Esta

información debe estar adaptada a los exigencias de la transferencia ATM.
Para que la información emitida alcance al destinatario con la calidad de
servicio requerida y pueda ser utilizada por éste, se requiere de otras
funciones. Estas funciones incluyen no sólo la detección de pérdidas de celdas,
la detección y corrección de errores, sino también, ciertas funciones de
adaptación tales como extracción de la temporización, etc. Estas funciones de
adaptación son implementadas en los equipos terminales, transmisores y
receptores, por capas de adaptación hacia ATM, denominadas AALs (ATM
Adaptation Layer), en donde el resultado de esta adaptación es transportado
dentro de un campo de la carga útil. Así pues, el número de octetos asignados
a la información del usuario es inferior a 48. La información es inyectada en
forma dinámica en las cargas útiles, en función de los tráficos generados
efectivamente por las fuentes. El resultado de este comportamiento es que los
recursos de la red sólo se utilizan cuando es necesario.

1.4 Conmutación

Una red ATM consiste de la interconexión de una serie de switches

(conmutadores) ATM por medio de enlaces punto a punto o interfaces ATM.
Los switches ATM permiten dos clases de interfaces:

UNI (User-Network Interface)

NNI (Network-Node Interface, también conocida como Network-Network

Interface)

La interfaz UNI conecta sistemas finales ATM (hosts, routers, etc) a un

switch ATM, mientras que la NNI puede ser definida como la interfaz que
conecta a dos switches ATM que intercambian el protocolo NNI, es por esto
que la conexión entre un switch ATM privado y un switch ATM público es una
UNI (conocida como UNI Pública), debido a que estos switches típicamente no
intercambian información NNI. En la Figura siguiente se muestran las interfaces
de una red ATM definidas por el ATM Forum.
 Figura 38 . Interfaces en una red ATM según el ATM Forum

El ATM Forum prevé que la mayoría de los servicios ATM sobre una
área amplia serán provistos por una red ATM pública, entendiéndose por red
pública aquella red que posee la habilidad de conectar cualquier usuario con
cualquier otro usuario.

En la figura anterior se observa el empleo de dos formas distintas de la

ATM UNI:

UNI Pública: la cual es típicamente usada para interconectar a un

usuario ATM con un switch ATM ubicado en la red de un proveedor de
servicio público, o para conectar a un switch ATM ubicado en una red
privada con un switch ATM ubicado en una red pública.

UNI Privada: la cual se usa típicamente para interconectar a un usuario

ATM con un switch ATM que es controlado por la misma red corporativa
que es responsable del dispositivo del usuario.

La principal diferencia entre ambas UNI es el alcance físico. Existen

también algunas diferencias funcionales entre las mismas debido a los
requerimientos asociados con cada una de estas interfaces. Ambas UNI
comparten la especificación de la capa ATM, pero pueden emplear diferentes
medios físicos.
 Dentro de la red pública o privada ATM, los switches intercambian
celdas e información de control por medio de la interfaz Pública NNI o Privada
NNI, respectivamente.

En el lado del cliente, algunos equipos del usuario realizan la adaptación

ATM, en otras palabras, por un lado hacen interfaz con equipos no basados en
celdas y por el otro lado hacen interfaz con el nodo de la red local ATM
mediante la UNI.

Las redes públicas basadas en ATM pertenecientes a diferentes

operadores también deben ser interconectadas con la finalidad de facilitar
servicios ATM de extremo a extremo, tanto a nivel nacional como internacional.
Para lograr estos objetivos se requieren métodos adicionales que soporten la
multiplexación de servicios entre los operadores de una forma eficiente y
controlable. De aquí, la conexión entre dos diferentes proveedores de redes
públicas puede ser realizada mediante la interfaz B-ICI (BISDN Inter carrier
Interface).

Volver arriba

2 TRÁFICO Y QoS

Una vez explicadas las características más esenciales de esta

tecnología, así como su funcionamiento, entremos ya a definir cómo
proporciona calidad de servicio el modo de transferencia asíncrono.

2.1 Control del retardo

El retardo en una red ATM es determinado por diferentes partes en la
red, las cuales individualmente contribuyen al retardo total. En la Figura
siguiente se muestra una red puramente ATM.
 Figura 39 . Retardo en un red ATM

La información es ensamblada en celdas en el equipo terminal emisor y

es desensamblada en el equipo terminal receptor. Internamente en la red, sólo
existen celdas. De aquí, los parámetros que contribuyen al retardo total en la
red son:

1. Retardo de transmisión (TD), denominado comúnmente retardo de

propagación. Este retardo depende de la distancia entre los dos puntos y de la
velocidad de pro- pagación. Dependiendo del medio de transmisión empleado,
el TD varía típicamente entre 4 y 5 ms por km. Este retardo es independiente
del tipo de tecnología o modo de transferencia empleado.

2. Retardo de paquetización (PD). Este retardo es introducido cada vez que

un servicio en tiempo real (tal como voz y video) es convertido en celdas y
depende de la longitud del paquete y de la velocidad a la cual la fuente genera
los bits.

3. Retardo de conmutación. En un switch ATM, el retardo de conmutación

está compuesto de dos partes:

Retardo de conmutación fijo ( FD, Fixed Switching Delay), que como

su nombre lo indica, es un retardo fijo. Este retardo es dependiente de la
implemen-tación, y es determinado por la transferencia interna de la celda a
través del hardware del switch. Este retardo es el encontrado cuando el
switch se encuentra con cero carga.

Retardo de la cola (QD, Queuing Delay), el cual es una parte variable

determinada por las colas en el switch.
 Como ya se explicó anteriormente, debido a que los switches ATM
realizan la conmutación y el multiplexaje estadísticamente, es necesario el
empleo de colas con la finalidad de evitar una excesiva pérdida de celdas.
Dependiendo de la arquitectura del switch es posible que estas colas estén
distribuidas en varias partes del switch. Estas colas introducen una fluctuación
de fase en las conexiones que la atraviesan, ya que el tiempo de travesía de
las celdas (duración de espera más tiempo de servicio) es aleatorio y depende
de la ocupación de la cola (ésta es a su vez es dependiente del tráfico en la
red). Este retardo es determinado por medio del comportamiento de las colas,
el cual es caracterizado por una función pdf (probability density function) de la
longitud de la cola.

Las aplicaciones interactivas en tiempo real (tal como la

videoconferencia) son sensitivas a un retardo acumulativo, denominado latency
en inglés. Por ejemplo, las redes telefónicas han sido construidas de tal manera
que introduzcan hasta 400 ms de latencia ida y vuelta (round-trip) cuando se
emplean canceladores de eco (sin canceladores de eco, es menos de 24 ms).
De aquí, las redes que proveen aplicaciones multimedia que soportan audio y
videoconferencia, deben ser también diseñadas con los mismos valores de
demora.

Cuando la red provee un retardo variable para diferentes paquetes o

celdas, entonces se habla de jitter.

2.2 Parámetros del tráfico

Enumeremos ahora los parámetros del tráfico, que permiten describir las
características del tráfico de una fuente, de los que proporcionaremos
posteriormente una descripción más detallada . Así tenemos:

Velocidad pico o de cresta (peak cell rate, PCR)

Velocidad media o sostenida (sustainable cell rate, SCR)

Longitud máxima de la ráfaga (maximum burst size, MBS)

Velocidad mínima (minimum cell rate, MCR)

2.3 Calidad de servicio o descriptores de tráfico

Uno de los principales beneficios de las redes ATM es que pueden
proveer a los usuarios con una Calidad de Servicio (QoS) garantizada. Para
poder realizar esto, el usuario debe informar a la red, durante el
establecimiento de la conexión, de la clase de tráfico esperada que será
transmitido en la conexión y del tipo de calidad de servicio que la conexión
requiere. La clase esperada de tráfico es descrita por medio de una serie de
parámetros de tráfico, mientras que la calidad de servicio de la conexión es
especificada por una serie de parámetros QoS. El nodo origen debe informar a
la red, durante el establecimiento de la conexión, de los parámetros de tráfico y
de la deseada QoS para cada dirección de la conexión solicitada, ya que los
mismos pueden ser diferentes en cada dirección de la conexión.

Para una conexión dada, los parámetros de tráfico de una fuente son
agrupados en lo que se denomina descriptor del tráfico de la fuente, el cual
a su vez es un componente del descriptor de tráfico de una conexión. Las
redes ATM, por otro lado, también ofrecen un serie específica de categorías de
servicio. El usuario debe solicitar a la red, durante el establecimiento de la
conexión, una clase de servicio para esta conexión. Las categorías de servicio
son empleadas para diferenciar entre diferentes tipos específicos de
conexiones, en donde cada una de las mismas posee unas características de
tráfico y de parámetros QoS particulares. Como resultado, se obtienen las
características negociadas de una conexión, la cual constituye el contrato de
tráfico.

Un descriptor del tráfico de una fuente es una agrupación de parámetros

de tráfico para una conexión dada pertenecientes a una fuente ATM. Este
descriptor es empleado durante el establecimiento de una conexión para
capturar las características de tráfico intrínsecas de la conexión solicitada por la
fuente particular.

El descriptor de tráfico de una conexión especifica las características de

tráfico de una conexión. Este descriptor incluye el descriptor del tráfico de una
fuente, la CDVT y la definición de conformidad, la cual es empleada para
especificar las celdas conformes de una conexión. El descriptor del tráfico de la
conexión contiene la informa- ción necesaria requerida para las pruebas de
conformidad de las celdas de la conexión en la UNI.

En la Figura siguiente se muestra el proceso de control del tráfico junto

con la serie de funciones asociadas a éste.
 Figura 40. Funciones asociadas con el control del tráfico

Durante el establecimiento de la conexión, el nodo solicitante informa a

la red del tipo de servicio requerido, de los parámetros de tráfico del flujo de
datos en cada dirección, la CDVT (cell delay variation tolerance) y de la QoS
solicitados para cada dirección. En resumen, los descriptores del tráfico de una
conexión según el ATM Forum son:

Descriptor del tráfico de la fuente:

Velocidad pico o de cresta (peak cell rate, PCR)

Velocidad media o sostenida (sustainable cell rate, SCR)

Longitud máxima de la ráfaga (maximum burst size, MBS)

Velocidad mínima (minimum cell rate, MCR)

La CDVT (cell delay variation tolerance) o tolerancia de variación del

retardo de células.

Definición de conformidad, basada en una o más aplicaciones del

algoritmo de tasa de células genéricas o GCRA (generic cell rate algorithm).
 CDVT es un parámetro de la función de vigilancia (UPC) e indica cómo
de tolerante puede ser la función de vigilancia al fenómeno de cell clumping. Es
utilizado en conjunto con el monitoreo de la PCR y de la SCR para asegurar
que las celdas que fueron generadas en el intervalo apropiado, pero que han
sufrido de una CDV positiva, también sean vistas como conformes a los
descriptores de tráfico.

Volver arriba

3 Categorías de servicio

ATM ha sido concebido como una tecnología multiservicio. Debido a la

presencia de una variedad de tipos de tráfico y a la necesidad de asignar
adecuadamente los recursos de la red para cada componente de tráfico, es
que han sido definidas las categorías de servicio dentro de la capa ATM.

La introducción de nuevas categorías de servicio ATM tiene como

finalidad el incrementar los beneficios de ATM, permitiendo que ésta tecnología
sea adecuada para una gama de aplicaciones ilimitada. Una red ATM puede
proveer VPCs y VCCs con diferentes niveles de servicio. La idea de negociar,
para cada conexión, el comportamiento esperado por la capa ATM en términos
de tráfico y desempeño, permite a los usuarios optimizar los requerimientos de
la aplicación versus las capacidades de la red. En otras palabras,
las Categorías de Servicio permiten al usuario el seleccionar combinaciones
específicas de parámetros de tráfico y de desempeño.

Funciones tales como CAC, UPC, Controles de Feedback, Asignación

de Recursos, etc., disponibles dentro de los equipos ATM, son generalmente
estructurados de forma diferente de acuerdo con cada Categoría de Servicio.

Las categorías de servicio ATM han sido definidas por las

organizaciones de estandarización ITU-T y por el ATM Forum. La arquitectura
de servicios provista en la capa ATM consiste de cinco categorías de servicios,
en donde cada categoría de servicio está designada para un grupo particular
de aplicaciones:

Constant Bit Rate (CBR)

 Variable Bit Rate (VBR)

Variable Bit Rate-Real Time (rt-VBR)

Variable Bit Rate-Non Real Time (nrt-VBR)

(rt-VBR y nrt-VBR son definidas en el ATM Forum Traffic Management

Specification versión 4)

Available Bit Rate (ABR)

Unspecified Bit Rate (UBR)

Guaranteed Frame Rate (GFR)

Estas categorías se empleadas para diferenciar entre diferentes tipos

específicos de conexiones, en donde cada una de las mismas posee unas
características de tráfico y de parámetros QoS particulares. En otras palabras,
para conexiones CBR solo PCR y CDVT están definidos.

En la Tabla siguiente se muestra la relación entre las categorías de

servicio, las clases QoS y las clases ITU-T.

Categorías de Clases QoS Clases ITU-T Aplicaciones Típicas

servicio

Emulación de circuito, video

CBR 1 A con velocidad constante,
ejemplo: E1, T1

VBR Audio y video con

2 B compresión y velocidad
(equivalente a rt-
variable, ejemplo: JPEG
VBR)

VBR Transferencia de datos

3 C orientado a conexión,
(equivalente a
ejemplo: Frame Relay
nrt-VBR)

ABR 4 D Tráfico LAN, IP y Emulacion

LAN Transferencia de datos
 sin conexión, ejemplo: SMDS

Transferencia
0 Sin
UBR X no garantizada / con baja
especificar
calidad

GFR X X TCP/IP

Tabla. Relación entre categorías de servicio, clases QoS y clases ITU-T

3.1 Servicio CBR

La categoría de servicio CBR es empleada por conexiones que
requieren de una cantidad de ancho de banda constante (estática), la cual está
continuamente disponible durante el tiempo de vida de la conexión. Esta
cantidad de ancho de banda está caracterizada por el valor PCR. La red
garantiza una velocidad de celda de cresta (PCR), la cual es la máxima
velocidad de datos que la conexión ATM puede soportar sin riesgos de pérdida
de celdas. La fuente puede emitir celdas a una PCR negociada, igual o menor
que la misma, durante cualquier período de tiempo y duración, teniéndose el
compromiso de la QoS.

Cuando una aplicación negocia la clase de servicio CBR, la misma

solicita un límite en la tolerancia de la variación del retardo de la celda (CDV),
la cual especifica el máximo jitter que la transmisión puede soportar y todavía
mantener los datos intactos.

El servicio CBR soporta aplicaciones en tiempo real que requieren una

determinada variación de retardo CTD y CDV (tales como, voz, video,
emulación de circuitos), pero no necesariamente están restringidos a estas
aplicaciones.

El principal compromiso que la red debe mantener es que una vez que la
conexión ha sido establecida, la QoS negociada debe ser asegurada para
todas las celdas conformes. Se asume que las celdas que son retardadas más
allá del valor especificado por la CTD deben ser de valor muy poco significativo
para la aplicación.

3.2 Servicio rt-VBR

Esta categoría de servicio soporta aplicaciones en tiempo real, que
requieren un determinado retardo (CDT) y variación de retardo (CDV).
 Las conexiones rt-VBR están caracterizadas en términos de una PCR,
SCR y MBS. Se espera que las fuentes transmitan a una velocidad que puede
variar con el tiempo. Asimismo, la fuente puede ser descrita como “bursty“.

Esta clase de servicio puede ser empleada en aplicaciones de

compresión de video con velocidad variable.

Se asume que las celdas que son retardadas más allá del valor
especificado por la CTD deben ser de valor muy poco significativo para la
aplicación. El servicio VBR-rt puede soportar el multiplexaje estadístico de
fuentes de tiempo real.

3.3 Servicio nrt-VBR

La categoría nrt-VBR soporta aplicaciones que no son en tiempo real y
cuyas características de tráfico son en ráfagas. Es caracterizada por una PCR,
SCR y MBS.

Para aquellas celdas que son transferidas de acuerdo al contrato de

tráfico, se espera una pérdida de celdas (CLR) muy baja, pero no posee un
límite de retardo asociado (CTD o CDV). El servicio VBR-nrt puede soportar el
multiplexaje estadístico de conexiones.

Esta clase de servicio puede ser utilizada para el internetworking con

Frame Relay, en donde la CIR (committed information rate) de las conexiones
es mapeada dentro de un ancho de banda garantizado por la red ATM.

3.4 Servicio ABR

Está diseñada para soportar aplicaciones que no pueden caracterizar
efectivamente su comportamiento de tráfico durante el establecimiento de la
conexión, pero que pueden adaptar su tráfico, bien sea incrementando o
reduciendo su velocidad de transmisión. Para esto ABR emplea un mecanismo
de control de flujo el cual soporta diversos tipos de feedback para controlar la
velocidad de la fuente en respuesta a cambios en las características de
transferencia de la capa ATM. Este feedback es transmitido hacia la fuente a
través de celdas de control específicas llamadas Resource Management Cells
(RM-cells). Aunque ningún parámetro QoS especifico es negociado, se espera
que los sistemas finales, los cuales adaptan su tráfico de acuerdo con el
feedback, experimentarán una relación de pérdidas de celdas (CLR) baja y
podrán compartir equita- tivamente el ancho de banda disponible de acuerdo
con normas o criterios de asignación específicos de la red. La categoría de
servicio ABR no está planificada para soportar aplicaciones en tiempo real, por
lo tanto, no requieren un determinado retardo (CTD) o variación de retardo
(CDV). A pesar de que Cell Delay Variation (CDV) no es controlado en este
servicio, las celdas admitidas no son retardadas innecesariamente.

El sistema final, durante el establecimiento de la conexión ABR, debe

especificar a la red dos valores:

El máximo ancho de banda requerido, denominado PCR.

El mínimo ancho de banda a utilizar, denominado MCR. MCR puede ser

cero.

ABR esta diseñado para mapear los protocolos LAN existentes, los
cuales emplean tanto ancho de banda como sea disponible desde la red, el
cual puede ser retrocedido o almacenado en buffer en presencia de congestión.
Debido a esto ABR es ideal para el tráfico LAN a través de redes ATM.

3.5 Servicio UBR

La categoría de servicio UBR soporta aplicaciones que no son críticas,
que no son en tiempo real, y que por lo tanto, no requieren un determinado
retardo o variación de retardo. Ejemplo de tales aplicaciones son aplicaciones
tradicionales de comunicación entre computadores, tales como file transfer o e-
mail. El servicio UBR soporta un alto grado de multiplexaje estadístico entre
fuentes.

UBR no ofrece ningún servicio garantizado. No existe ningún

compromiso numérico en cuanto a garantía en pérdida de celdas (CLR) o la
existencia de un límite superior de retardo (CTD), por lo tanto, no requiere de
ningún conocimiento previo sobre las características del tráfico. Una red puedo
o no aplicar la PCR a las funciones CAC y UPC. En el caso en que la red no
haga cumplir la PCR, el valor PCR es sólo para información. Cuando la PCR no
se hace cumplir, es todavía de ayuda el negociar la PCR, ya que esto le
permite a la fuente el descubrir la limitación de ancho de banda más pequeña
en el camino de la conexión. El control de congestión en UBR puede ser
realizado en capas superiores o empleando una base extremo a extremo.
 El servicio UBR es indicado por el Indicador “Best Effort“ en el elemento
de información “ATM user cell rate“.

El usuario tiene la libertad de enviar cualquier cantidad de datos hasta

un cierto máximo especificado. La red, por el otro lado, no hace ninguna
garantía en relación con la velocidad de pérdida de celdas, retardo y variación
de retardo que los datos puedan experimentar.

UBR no dispone de ningún mecanismo de control de flujo para controlar

o limitar la congestión y sólo está presente la notificación de congestión, la cual
puede ser empleada por los sistemas finales para adaptarse al estado de
congestión de la red. Es por esto que es conveniente que los switches ATM
soporten tamaños de buffers adecuados para minimizar la probabilidad de
pérdida de celda cuando múltiples ráfagas prolongadas de datos son recibidas
al mismo tiempo en el switch o implementen mecanismos de control, tales
como el uso del EFCI bit (explicit forward congestion indication bit). Sin
embargo, tal y como está especificado en el ATM Forum, el uso del bit EFCI es
opcional para los sistemas finales, por lo tanto, la red no debe confiar en este
mecanismo de control de congestión.

3.6 Servicio GFR

El servicio de Trama Garantizada (ATM Guaranteed Frame Rate (GFR))
ha sido creado para mejorar el tráfico best effort (mejor servicio) en un mínimo
de garantías de rendimiento. Los dispositivos de los bordes de la red que
conectan redes LANs con una red ATM pueden usar este servicio GFR para
transportas múltiples conexiones TCP/IP sobre un simple circuito virtual GFR.
Estos dispositivos multiplexarán normalmente los circuitos virtuales dentro de
una sola cola FIFO. Se ha demostrado que este tipo de cola no es suficiente
para proporcionar unas mínimas garantías, por lo que el encolado vía circuito
virtual con GFR es necesario.

Este servicio ha sido propuesto recientemente por ATM para mejorar el

servicio UBR GFR, tal y como se ha mencionado, proporciona un mínimo de
tasa de garantías al circuito virtual a nivel de trama, permitiendo además el uso
de ancho de banda extra de la red y es usado por aquellas aplicaciones que no
pueden cumplir los requerimientos de VBR ni tienen la capacidad de ABR.
 La Tabla siguiente provee una lista de los atributos ATM (parámetros de
tráfico, parámetros QoS y características de feedback) para algunas de las
categorías de servicio expuestas e indica si éstos son soportados o no para
cada una de las categorías de servicio.

Tabla. Categorías de servicio y los parámetros aplicables

En donde: n.a.: no aplicable y n.e.: no especificado

En las siguientes tablas se muestran valores típicos de los parámetros

de desempeño que han sido definidos en estándares, tales como Bellcore, así
como el tipo de garantías proporcionadas por las categorías de servicio.

Tabla. Objetivos QoS para las categorías de servicio de la capa ATM

Clase de Garantía de Garantía de Garantía de caudal

variación de de tráfico
servicio ancho de banda
 retardo (throughput)

CBR Si Si Si

VBR Si Si Si

UBR No No No

ABR Si No Si

Tabla. Clases de Servicio ATM Forum

En la siguiente gráfica, además, se muestra la relación entre el ancho

de banda y las categorías de servicio definidas anteriormente.

Figura 41. Relación ancho banda – categorías de servicio

Volver arriba

4 Mecanismos de control

Como vimos en capítulos anteriores, para proporcionar un sistema de

calidad es necesario utilizar una serie de mecanismos que permitan controlar la
red. Así pues, estudiemos los mecanismos que se aplican en ATM.
4.1 Control de admisión de conexión (CAC)
El control de admisión de conexión o CAC representa una serie de
acciones tomadas por la red durante la fase de establecimiento (call set-up) de
un SVC, durante el establecimiento de un PVC o durante la fase de
renegociación de alguno de éstos con la finalidad de:

1. Aceptar o rechazar una nueva conexión VCC (PVC o SVC)

2. Cambiar la categoría de servicio o descriptores de tráfico de un VCC

existente.

La aceptación de la solicitud de una conexión para una nueva llamada

se realiza sólo cuando están disponibles suficientes recursos para llevar esta
conexión a través de toda la red con la calidad de servicio (QoS) solicitada por
la misma y cuando al mismo tiempo es posible mantener las QoS de las
conexiones ya existentes en la red (esto se aplica también durante la
renegociación de los parámetros dentro de una llamada). Si no es posible que
la conexión reciba estos recursos, la red ATM no aceptará dicha conexión.
CAC debe tomar en cuenta cada recurso compartido de todos los componentes
de la red, en donde un recurso compartido puede ser, por ejemplo, la cola de
celdas (cell queue) y su enlace de transmisión correspondiente. En otras
palabras, CAC al rechazar conexiones o cambios en configuraciones que
pueden producir congestión, asegura que la garantía de la pérdida de celdas
(CLR) y el retardo de celdas (CTD) fijados para una conexión sean cumplidos.

Durante el establecimiento de la llamada una serie de informaciones,

establecidas en un contrato de tráfico, deben ser negociadas y acordadas
entre el usuario y la red para permitir que el CAC tome las decisiones
adecuadas en cuanto a la aceptación/rechazo de la conexión.

Para cada solicitud (request) de un VCC, CAC emplea la siguiente

información para poder tomar la decisión de admisión/rechazo:

La QoS solicitada.

Los valores de los parámetros en el descriptor de tráfico del VCC.

La definición de conformidad UPC solicitada.

Las rutas.

El factor de reservación (booking), de existir.

 La función CAC es responsable de la asignación de recursos de red para
una conexión dada. Según los estándares, estos esquemas son específicos del
operador de
la red.

La función CAC asigna una ancho de banda a cada conexión y limita la

asignación del ancho de banda total a la capacidad de cada recurso (por
ejemplo a la velocidad del enlace).

La cantidad de recursos de red que una conexión requiere puede ser

representada en términos de un Ancho de Banda Virtual Vbw (también
denominado ancho de banda equivalente) mediante el empleo de los
descriptores de tráfico específicos de específicos de la conexión. El ancho de
banda virtual representa la cantidad de ancho de banda empleada por la
conexión una vez incluido los requerimientos de la QoS (principalmente CLR) y
el tamaño del buffer.

La función CAC más simple asigna un ancho de banda virtual

equivalente a la PCR para cada conexión. En el caso VBR, puede existir una
asignación estadística del ancho de banda en el caso en que el parámetro SCR
sea tomado en consideración.

El cálculo del ancho de banda virtual es muy complejo y requiere de

grandes suposiciones del comportamiento del tráfico. Continuas
investigaciones son realizadas en este aspecto con la finalidad de encontrar el
modelo con la mayor precisión que refleje los requerimientos de ancho de
banda de cada tipo de comportamiento de tráfico. En la Tabla siguiente se
muestra una estrategia comúnmente empleada para la asignación del ancho de
banda para cada una de las categorías de servicio.
 Tabla. Asignación del ancho de banda según la categoría de servicio

4.2 Conformado del tráfico (TRAFFIC SHAPING)

Traffic shaping es un mecanismo que altera las características de tráfico
del flujo de celdas de una conexión para alcanzar una mejor eficiencia en la red
mientras se mantienen los objetivos QoS o con la finalidad de asegurar que el
flujo de celdas sea conforme con los parámetros de tráfico de acuerdo con la
configuración del algoritmo leaky bucket del contrato de tráfico. El traffic
shaping puede ser empleado, por ejemplo, para reducir la velocidad pico,
limitar la longitud de la ráfaga o reducir la CDV por medio del espaciamiento
adecuado de las celdas en el tiempo. El uso y ubicación de esta función es
específica de la red.

El contrato de tráfico entre el cliente y la red especifica las

características negociadas de una conexión. Este contrato puede consistir de:

El descriptor de tráfico de una conexión

Una serie de parámetros QoS para cada dirección de la conexión

La definición de cumplimiento de la conexión

La definición exacta del cumplimiento no está definida en los estándares,

es decir, es dependiente de la red. La red, basada en acciones de la función
UPC, puede decidir si una conexión es conforme o no. En el caso de que la
conexión es conforme, la red debe soportar la QoS para todas las conexiones
conformes.

4.3 Control de prioridad de pérdida de celda

Cuando las celdas son conmutadas a través de una red ATM, se van
formando colas como una consecuencia natural de los retardos de propagación
(demasiadas celdas a ser transmitidas por un enlace de salida) y de los retardos de
procesamiento en los nodos de la red. Las celdas en las colas deben ser colocadas
en buffers hasta que puedan ser atendidas. Las redes ATM, bajo cualquier tipo de
condición, deben poseer mecanismos adecuados para el servicio de los buffers en
los nodos ATM. Bajo condiciones de congestión (es decir, demasiadas celdas en la
red), debe existir un mecanismo de prioridad que permita remediar la situación de
congestión, como por ejemplo el descarte de ciertas celdas, con la finalidad de
poder servir al resto de las celdas con los adecuados parámetros QoS. Para esto
se requiere de un método que permita a los nodos ATM identificar rápidamente
celdas que puedan ser descartadas de aquellas celdas que no pueden ser
descartadas, a excepción de condiciones ex- tremas de congestión. El control de
prioridad es realizado a través de un bit localizado en el encabezamiento de la
celda denominado bit de prioridad de la celda (CLP).

Volver arriba

5 Conclusión

ATM es una tecnología que soporta con altos niveles de garantía

la tendencia actual de generación de tráfico multimedia, pues ha sido
concebida desde su nacimiento como una tecnología capaz de proporcionar
altos niveles de calidad de servicio, a diferencia, por ejemplo, de las redes IP y
las 802, que tienen que ser adaptadas (hay que buscar la manera) para poder
proporcionar un nivel aceptable de calidad. Esto, evidentemente es una gran
ventaja con respecto al resto de tecnologías.

Uno de los principales beneficios de las redes ATM es que pueden

proveer a los usuarios con una Calidad de Servicio (QoS)
garantizada, informando el usuario a la red, durante el establecimiento de la
conexión, de la clase de tráfico esperada que será transmitido en la conexión y
del tipo de calidad de servicio que la conexión requiere. Esto se logra mediante
el uso de descriptores del tráfico y categorías de servicio, designándose estas
últimas designada para un grupo particular de aplicaciones (todos hemos oído
hablar de Constant Bit Rate (CBR) o de Available Bit Rate (ABR), entre otras ).

Además de estas características ATM incluye en su concepción diversos

mecanismos de control o herramientas, análogas a las descritas anteriormente
que permiten gestionar su funcionamiento para la obtención de calidad de
servicio.

Teniendo en cuenta todas las eficaces ventajas descritas para ATM es

necesario destacar que el principal inconveniente en escoger esta tecnología
como la más adecuada para nuestra red es su elevado coste. Si bien, si su
empresa lo puede permitir, no dude en implantarla.
QoS en FRAME RELAY.

Frame Relay surgió como un estándar de facto (1990), producido por un

grupo de varios fabricantes de equipos nombrados a continuación. Nació para
cubrir necesidades del mercado no satisfechas hasta el momento en el sector
de las comunicaciones (eran numerosas las restricciones de X.25). Se trataba
de una solución transitoria, pero que ha logrado una gran aceptación, y su
papel en la actualidad es importante.

El estándar de facto evolucionó hacia varios estándares oficiales, como

son:

FR Forum (Asociación de Fabricantes): Cisco, DEC, Stratacom y

Nortel.

ANSI: fuente de normativas Frame-Relay.

ITU-T: también dispone de normativa técnica de la tecnología Frame-

Relay.

Sin embargo, estas tres fuentes de normas no siempre coinciden

(ambigüedad), cosa que no pasaba en X.25, tecnología que vamos a explicar
en el próximo apartado.

1. LIMITACIONES DE X.25

Las principales carencias y limitaciones que presenta X.25 son:

X.25 es un estándar que impone una sobrecarga de procesamiento muy

grande. Esta complejidad tan elevada impide operar a velocidades de línea
altas. Un ejemplo es que, en la práctica, la ventana del nivel 3 impone
limitaciones en velocidad.

Hay que tener en cuenta que una red de conmutación tiene recursos
compartidos, y su funcionamiento depende de la carga de la red (a mayor
carga el retardo se incrementa y el rendimiento disminuye). Como no resulta
posible predecir el estado de la red, no sabemos cuanto tardará en
transmitirse un paquete, ni podemos garantizar un caudal mínimo. Es
decir: X.25 no garantiza Calidad de Servicio (QoS). Este problema se ha
resuelto en Frame Relay, y existen garantías respecto al caudal.
 El rango de caudales en acceso en que X.25 opera normalmente va
desde 1.2Kb/s hasta 64 Kb/s. Existen equipos que permitirían operar a una
velocidad mucho mayor en la línea de acceso. Pero eso implicaría una
congestión mayor en las líneas troncales (que conectan sistemas
intermedios) de la red. Y precisamente lo que resultaría muy costoso
económicamente es aumentar las velocidades a las que operan estos
sistemas intermedios.

Una aplicación muy importante de X.25 es el teleproceso o acceso a un

mainframe desde terminales remotos. La velocidad de 64 Kbps sí puede
resultar suficiente para cualquier terminal, pero es una cifra escasa para la
línea que conecta al superordenador con la red.

Otras aplicaciones que no satisface X.25 son una rápida y efectiva

interconexión de LANS, así como aplicaciones multimedia con audio y vídeo
en tiempo real.

Otra diferencia de Frame Relay respecto a X.25 es la separación entre

el plano de usuario y el plano de control. Existen dos arquitecturas de
protocolos diferentes para los datos de usuario y los datos de control. En
X.25 los procedimientos de control y los datos de usuario utilizaban los
mismos medios, y eso daba lugar a problemas en casos de congestión.

Algo más a tener en cuenta es que la mejora de los medios de

transmisión (Pe baja) ha convertido en innecesario el complejo control de
errores que proporcionaba X.25.

Estudiemos ahora las características de Frame Relay que han supuesto

una visible ventaja sobre X.25, posibilitando, entre otras cosas, calidad de
servicio.

Volver arriba

2. Tecnología Frame Relay

Las principales características de Frame-Relay [38] son las siguientes:

Es un protocolo de Acceso a Subred (regula interfaz usuario-red)

 El funcionamiento interno no está normalizado (igual que en X.25), por
lo que sólo lo está el interfaz usuario-red.

En la siguiente figura se muestra el funcionamiento interno de Frame

Relay.

Figura 42. Funcionamiento interno Frame Relay

Frame-Relay posibilita tráfico impulsivo, así como múltiples terminales

de usuario.

Frame-Relay ofrece una simplificación de los servicios que ofrece. Para

comprender mejor el por qué de las simplificaciones que ofrece Frame-
Relay, pasemos al siguiente ejemplo:

Supongamos una línea de 2 Mbps por la que se quieren transmitir

paquetes de aproximadamente 1000 bits. El nodo asociado a esta línea

debería procesar paquetes cada , y el hecho de tener varias

líneas accediendo a cada nodo, así como saliendo de el, encarecería
demasiado los equipos:
 Figura 43. Ejemplo Frame Relay

Por lo tanto, para reducir este coste en Frame-Relay se realizan las

siguientes simplificaciones de protocolo:

Separación (funcional) del Plano de Usuario y Plano de Control :

(NOTA: Plano de Usuario: parte de la arquitectura de protocolo por la

que circulan los datos del usuario. Plano de Control: parte de la
arquitectura de protocolo por la que circulan datos entre el usuario y la
red para supervisar la red)

En X.25, estos planos no estaban separados, lo que complicaba el

diseño de los equipos. La separación en Frame-Relay se debe a que se
tiende a diseñar en el equipo una parte distinta para procesar cada
plano, ya que la característica deseada para el usuario es conseguir
MAS CAUDAL, y para el de control, tener FLEXIBILIDAD (se tiende a la
implementación software de los equipos en el plano de control y
hardware en el plano de usuario).

Simplificaciones en el Plano de Usuario:

Suprime el Nivel 3 del plano de usuario. Pero como Frame Relay ofrece
un servicio orientado a conexión, nos surge la siguiente pregunta: ¿Qué
ocurre con el establecimiento y liberación de las llamadas? Pues que se
lleva al plano de control del nivel 3. ¿ Y con la función de multiplexión de
conexiones ? La función de multiplexión se pasa al nivel 2 en FR.

Suprime funciones del Nivel 2 en el plano de usuario.

En consecuencia obtenemos varias diferencias entre ambos a distintos

niveles, como se puede ver en las siguientes tablas :

X.25 (Nivel 2) Frame-Relay (Nivel 2)

Generación / Reconocimiento de Flags Generación / Reconocimiento de Flags

Transparencia Transparencia

Código de redundancia Código de redundancia

 Descarte de Tramas (con CRC Descarte de Tramas (con CRC
inválido) inválido)

Retransmisiones ---

Almacenamiento de tramas pendientes ---

de ACK

Asentimiento de tramas ---

Generación de tramas REJ ---

Tratamiento de RR/RNR ---

Reinicio ---

Cuenta de retransmisión ---

Tabla . Diferencias FR-X.25 a nivel 2

X.25 (Nivel 3) Frame-Relay (Nivel 3)

---
Multiplexación
(se lleva al nivel 2)

Control de Flujo (RR/RNR) ---

Control de Interrupciones ---

Numeros de Secuencia ---

---
Establecimiento / liberación de llamadas
(se hace en el plano de control)

(... y mas funciones ...) ---

Tabla . Diferencias FR-X.25 a nivel 3

 Así pues, los equipos que procesan las tramas deben realizar un
procesamiento menor.

Volver arriba

3. Servicio Frame Relay

Definamos ahora las características del servicio proporcionado por esta

tecnología:

Es orientación a conexión(CO).

Es no fiable, con garantías de caudal mínimo, por lo que se acepta que

el proveedor pierda datos (PDUs). Con fiable nos referimos a que tramas
errores pueden ser detectadas y descartadas en los nodos de la red
(comprobando el CRC) sin avisar a los sistemas finales. Esta no fiabilidad
es, por supuesto, fruto de las simplificaciones en el protocolo comentadas
anteriormente.

Las perdidas de datos en Frame-Relay no son preocupantes si

disponemos de un protocolo de Nivel Superior que resuelva el problema para
las aplicaciones que no toleren perdidas de datos. A pesar de esto, la no
fiabilidad es muy baja, ya que los medios de transmisión tienen una
probabilidad de error (Pe) pequeña.

QoS: El cliente tiene garantizadas (por contrato) las prestaciones que

obtendrá de la red.

Además, hemos de tener en cuenta que Frame-Relay ofrece dos tipos

de conexiones:

Circuitos Virtuales Permanentes(PVC): están definidos en todos los

estándares. Es un enlace Frame Relay lógico, cuyos puntos finales y clase
de servicio están definidos por el administrador de la red. Es análogo al
circuito virtual permanente de X.25. Un PVC consta de una dirección origen
de red Frame Relay, una dirección destino de tipo red Frame Relay, un
identificador de control de enlace de datos origen, y un identificador de
control de enlace de datos destino. Origen se refiere a la interfase de
acceso desde donde se inicia una conexión Frame Relay. Destino se refiere
 a un punto donde termina el PVC. Muchos clientes de red de datos
requieren un PVC entre dos puntos.

Circuitos Virtuales Conmutados (CVC): Éstos solo han sido definidos

en el estándar propuesto por la ITU-T y no por el estándar de facto.

El servicio que suelen ofrecer los operadores de redes FR sólo incluye

PVC´s, y es utilizado típicamente para dar servicios de comunicaciones dentro
de una corporación.

Volver arriba

4. Arquitectura de protocolos

Ahora debemos definir cómo es la arquitectura de esta tecnología para

saber dónde situar el funcionamiento, los distintos servicios y aplicaciones de la
misma.

4.1 INTRODUCCIÓN

En cada sistema final y sistema intermedio, tenemos dos arquitecturas

distintas y separadas: la correspondiente al plano de usuario y la
correspondiente al plano de control.

Plano de Usuario : Información que fluye desde la aplicación hasta el

nivel físico (cables, aire...). Por el fluyen los datos del usuario. Compuesto
por:

(a) Nivel Físico (dos opciones):

Línea de Serie (interfaces físicas: V.35, G.703)

RDSI (BRI, PRI)

(b) Nivel de Enlace: en la recomendación de ITU-T, el protocolo

utilizado es LAP-F.

Plano de Control (en la práctica no se utilizan) Información para la

utilización de los servicios de la red, entre organos de la red. Se conoce
 como información de señalización. La genera y la destruye la propia red. En
este caso:

Se instala sobre el mismo plano de usuario, utilizando el mismo nivel

físico, excepto en RDSI, que se utiliza el Canal D para el plano de Control.
Nivel 2: el mismo que RDSI, es decir, LAP-D.

Nivel 3: Se usa el protocolo Q.933 (similar al Q.931 usado en

establecimiento y liberación de llamadas en RDSI).

NOTA: a nivel físico, existirá una separación de los flujos de información de

usuario y de control.

Plano de Gestión: Información necesaria para la operación y

administración de los servicios. Por ejemplo la información de tarificación, o,
si se produce algún error, lo que se comunica a los administradores de la
red para que pongan una solución.

Se identifican dos protocolos: ILMI (Interin Local Management Interface)

y CLLM (Consolidated Link Layer Management).

4.2 FORMATO DE TRAMA

Nos referimos al formato existente en el plano de usuario. En este

formato no se establece una longitud máxima de trama, pero debe ser un
múltiplo entero de octetos (es decir, la trama está alineada a octeto), lo cual se
puede observar en la figura. Conviene destacar que el protocolo define también
el orden de transmisión de los bits de la trama por línea. Este orden es, según
se ha querido dar a entender con la figura, de derecha a izquierda. La
transmisión es en serie por la línea y un bit va detrás de otro. Un sistema final o
intermedio que reciba una trama debe saber el significado de cada bit que le
llega, y este significado depende del orden de ese bit dentro de su trama.

Figura 44. Formato de trama en el plano de usuario en FR.

 El significado de cada uno de los campos es el siguiente:

CRC (también llamado FCS): Código de detección de errores. Es un

código cíclico. Es necesario, ya que cuando se detecta una trama con error,
se descarta.

DATOS: . En este campo es donde van los datos del Nivel superior, es
decir, esta información se mete en la trama y, en recepción, se pasa
directamente al nivel superior. Su longitud máxima no está definida en el
estándar de facto (no está normalizada), pues no se pudo llegar a un
acuerdo. Normalmente los operadores de redes FR la sitúan alrededor de
1600 bytes. Esta gran diferencia con X.25 (128 octetos) es debida a la
escasa Pe. El Nivel superior entrega los datos, y estos son encapsulados en
una trama. Por último, añadir que este campo está alineado a octeto, es
decir se exige al usuario del servicio que entregue un número entero de
octetos.

FLAG: Tiene el mismo formato que en LAB-B (01111110), y también se

utiliza para separar tramas consecutivas. Cuando no hay tramas que
transmitir, se generan guiones continuamente.

CAMPO DE CONTROL: Llamamos campo de control a los bytes que

siguen al Flag y que están por delante de los Datos de usuario. Puede tener
varios formatos (como en X.25), pero normalmente suele tener 16 bits de
longitud (2 octetos):

Figura 45: Campos incluidos dentro del campo de control

Para el campo de control tenemos los siguientes subcampos :

DLCI: Data Link Circuit Identifier. Estos diez bits son el identificador de
conexión de enlace de datos. Permite definir hasta 1024 circuitos virtuales.
Ya habíamos avanzado que la función de multiplexión se realiza en el nivel
2, y con el DLCI se identifica al canal lógico al que pertenece cada trama.
Los números de canal lógico se asignan por contratación. Equivale
al NCL de X.25.
 E A: Extended Address. Campo de extensión de dirección. Puesto que
se permiten más de dos octetos en el campo de control, este primer bit de
cada octeto indica (cuando está marcado con un '0') si detrás siguen más
octetos o bien (cuando está marcado con un '1') si se trata del último del
campo de control. Emplear más de dos bytes resulta bastante infrecuente y
se utiliza en el caso de que la dirección de multiplexión (en el campo DLCI)
supere los 10 bits.

C R: Bit de Comando / Respuesta. Es parecido al bit "Q" de X.25, y al

igual que ocurría con éste, no es un bit utilizado por la red. Se introduce por
compatibilidad con protocolos anteriores, como los del tipo HDLC. Cuando
el protocolo de enlace es fiable, utilizan este bit.

F C, B C y F C: Bits para control de congestión y se verán más

adelante en este tema.

Los sistemas pueden almacenar las tramas de formas diferentes. No

olvidemos que la representación interna de la información dentro de un sistema
puede tener diferentes significados, según el convenio que haya adoptado la
implementación de esa máquina. Existen los convenios extremista mayor y
extremista menor (Big-Endian y Little- Endian en inglés), y éstos, a su vez
pueden estar referidos a bits, bytes o palabras. El sistema debe tener esto en
cuenta para operar adecuadamente con los bits que tiene almacenados, y al
transmitir o recibir bits de tramas, hacerlo en el orden que establece el
protocolo.

(NOTA: La velocidad de llegada de tramas al nodo depende de la longitud de

las tramas y del caudal. El nodo a de ser capaz de procesar las tramas según
llegan. Luego, el que se queden en el nodo y tarden en salir es otra cosa, y
depende del tráfico)
 Figura 46. Significado del campo circuito de enlace de datos (DLCI)

Vemos como, a diferencia de X.25, en Frame-Relay tendremos DLCIs

diferentes en el UNI para datos entrantes y salientes de la red. Además, cada
circuito se trata de unCVP, y no de un CVC.

4.3 CONTROL DE CONGESTIÓN

Una de las características de Frame Relay reside en su gran sensibilidad

respecto a las situaciones de congestión. A diferencia de la conmutación de
datos X.25, Frame Relay no posee mecanismos de control local del flujo.
Cuando la congestión aumenta hasta alcanzar niveles considerables, el retraso
de la red se incrementa en gran medida. Este inconveniente conlleva, sin
embargo, una de las principales ventajas de esta tecnología, ya que agiliza y
simplifica la transferencia de las tramas Frame Relay: las tramas desechables
son descartadas y las válidas sólo son procesadas en orden a asegurar que el
destino consiste en un identificador DLCI (Data Link Connection Identfier).

El control de congestión, por tanto, no es una función local, sino global

(participan todos los sistemas). Veamos algunos conceptos:
 Figura 47. Supuestas transmisiones

Relacionado con la figura anterior podríamos distinguir entre :

1. Tráfico ofrecido: . Evidentemente su propio nombre indica

la funcionalidad del mismo.

2. Tráfico cursado:

Si ahora nos fijamos en la gráfica siguiente, queda claro que el objetivo

de la tecnología de redes será evitar entrar en la zona de congestión. Es
evidente que una red congestionada es una red incapaz de proporcionar los
servicios de una manera eficiente.
 Figura 48. Zona de congestión.

Pero, ¿ por qué tiene esta forma la gráfica?

En redes de medio compartido, la red pierde tiempo en solucionar las

colisiones.

En redes sin medio compartido, esta gráfica se debe a la limitación de la

capacidad de conmutación de los nodos. Cuando a un nodo le llegan datos
que no puede cursar, los descarta, quedándose sin llegar a su destino
(la curva cae).

El intentar no llegar a esta Zona de Congestión, es decir, procurar que

se curse la mayor cantidad de tráfico ofrecido, significa utilizar técnicas de
control de congestión.

Los controles de congestión consisten en técnicas estadísticas,

nunca deterministas. En Frame-Relay, esta función está implementada en parte
en el Plano de Usuario.

En X.25 el control de congestión se realizaba mediante el Control de

Flujo (se detienen fuentes cuando se detecta tráfico excesivo en algún punto
del circuito virtual). En Frame-Relay se usa el mecanismo de NOTIFICACIÓN Y
DESCARTE, cuyo comportamiento podría ser la siguiente:

"Cuando se detecta una zona congestionada, se notifica al usuario que envía

los datos que pasan por esa parte de la red, el cual disminuye la tasa de tráfico
inyectado. Si el usuario no lo hace, la red descartará los datos que considere
oportuno (aceptable, ya que F-R es un servicio no fiable). Esta pérdida, si es de
porcentaje elevado, provoca el cese del funcionamiento a las entidades de nivel
superior, por lo que el usuario intentará evitar este tipo de situaciones".

Debemos recordar que en Frame-Relay, este descarte de tramas tiene

lugar a Nivel 2.

La implementación de la técnica de NOTIFICACIÓN Y DESCARTE se

realiza mediante los campos FECN, BECN y DE en el campo de control de la
trama que ya fueron introducidos anteriormente:

FECN (Forward Explicit Congestion Notification): Notificación de

congestión en el sentido de la transmisión.

BECN (Backward Explicit Congestion Notification): Notificación de

congestión en el sentido contrario a la transmisión.

DE (Discard Eligibility): Las tramas que tienen este bit a "1" son
susceptibles de descarte en situaciones de congestión.

El bit BECN y el FECN se usan para avisar que hay congestión (la red
los cambia de 0 a 1 y viceversa):

Figura 49. Muestra de los campos FECN y BECN para control de congestión.
 Hay que señalar que la congestión es unidireccional, pues puede haber
caminos distintos para los dos sentidos de la transmisión y mientras uno puede
estar sufriendo problemas de tráfico (congestión), el otro puede no tenerlos.
Los bits FECN y BECN notifican congestión a los dos extremos de una
conexión de la siguiente forma: a una trama que atraviesa una zona
congestionada se le pone su bit FECN a '1'. La red identifica las tramas de esa
conexión que circulan en sentido contrario y en ellas marca el bit BECN
también a '1'.

Es decir, la red F-R sólo notifica la congestión al origen y al destino,

y del N. Superior dependerá seguir estas indicaciones (indicando al N. Superior
del origen que reduzca la tasa, etc.) o no hacerlo, en cuyo caso, F-R procederá
a descartar tramas.

4.4 QoS

Estudiemos ahora cómo es capaz FR de proporcionar calidad de

servicio, que es lo que se estudia en este proyecto.

En FR es posible contratar para cada conexión una calidad de servicio

distinta. Dicha calidad está definida mediante ciertos parámetros:

CIR (Committed Information Rate) (bits/s): Es la tasa de información

comprometida, es decir, el caudal medio garantizado que la red se
compremete a dar en una conexión durante un intervalo de tiempo definido
(Tc). Es un parámetro asociado a cada sentido de la transmisión de cada
circuito virtual.

Por lo tanto se define una relación entre el tiempo real y el volumen de

información transferida:
 Figura 50. Diagrama QoS en FR.

Tc (Commited rate measurement interval): Intervalo de observación (es

el tiempo hasta el cual ha sido representado la gráfica anterior). Parámetro
del algoritmo para calcular el CIR).

C·Tc : Máximo volumen de información que se podría cursar en T c (es lo

que posibilita el canal).

El caudal físico (C) de la línea de acceso también se contrata. Así el

operador dimensiona la red en función de los parámetros contratados por sus
abonados.

En el interfaz usuario-red se controla, para cada circuito virtual, que los

usuarios se ajusten a los parámetros Bc, y Be que han negociado. En
consecuencia, si la red está bien diseñada no debe perder datos que no
superen el tráfico comprometido.

Definimos dos zonas en el diagrama anterior:

Bc (Committed burst size): Es el volumen de información comprometida:

durante el intervalo Tc la compañía se compromete a transmitir un volumen
Bc.
 Be : Volumen de información en exceso: la información cursada durante
el intervalo Tc que exceda de Bc + Be no se sabe si llegará o no a su
destino (la compañía no lo garantiza). El volumen de información que
exceda de Bc + Be seguro que no llegará.

Este método se aplicará para cada circuito virtual de ingreso a la red.

Existe un bit en la trama (bit DE) que es activado por la red en tramas
que superen Bc (es decir aquellas que pertenezcan a Be) para indicar que esas
tramas deberían ser descartadas en preferencia a otras, si es necesario. El
servicio permite que el propio usuario también pueda marcar este bit para
indicar la importancia relativa de una trama respecto a otras (en este caso,
estas tramas no se contabilizan como pertenecientes a la zona bajo B c, sino
como perteneciente a la zona sobre B c y bajo Bc + Be, no contando para el
CIR).

(NOTA: La mayoría de las compañías operadoras sólo definen el parámetro

Be.)

El parámetro C·Tc está asociado a la capacidad física de las líneas, y es

lo primero que contrata el abonado. Luego, sobre esa línea física, se definen
mallas de circuitos virtuales , cada uno con su CIR asociado.

Bc = CIR·Tc

El CIR no es la capacidad física a la que se transmite. Esa velocidad es

la de la capacidad del canal. El CIR sólo es el caudal medio (estadístico).

Si el Tc se toma grande, existe la posibilidad de transmitir grandes picos

de información en algunos momentos y nada de información en otros. Por
tanto, un Tc pequeño nos garantiza el que la transmisión sea más homogénea
(esto interesa a la empresa, ya que así se evita sobredimensionar las redes).

Volver arriba

5. Frame Relay frente a otras tecnologías

La siguiente tabla muestra las principales diferencias de FR frente a

otras tecnologías, lo que nos permite realizar una pequeña comparación entre
las mismas.
 TDM X.25 FRAME ATM
RELAY

Facilidades Muy pocas Muchas Pocas Pocas

Velocidad Alta Media Alta Muy Alta

Retardo Muy bajo Alto Bajo Muy bajo

Throughput Alto Bajo Alto Muy alto

Coste CPE Bajo Bajo Bajo Alto

Overhead Bajo Bajo Bajo Alto

Puerto Comp. No Sí Sí Sí

Tipo tráfico Cualquiera Datos Datos/voz Multimedia

Tabla comparativa FR-otras tecnologías

Volver arriba

6. Conclusión

Frame Relay no es un protocolo especialmente diseñado para soportar

tráfico multimedia, audio y vídeo en tiempo real. No hay garantías sobre el
retardo de tránsito, pero en la práctica las redes suelen estar bien
dimensionadas y el retardo de tránsito es pequeño y no varía apreciablemente.
Además la disponibilidad de estas redes es muy alta, y por todo ello muchas
compañías usan redes FR para cursar este tipo de tráfico. En general se
considera que son suficientemente buenas para cursar tráfico telefónico, en el
que lo más importante (más que la probabilidad de error) es tener una elevada
disponibilidad.

En cuanto a QoS, en FR el cliente va a tener garantizadas las

prestaciones que obtendrá de la red, siempre por contrato, pudiendo contratar
un nivel de calidad de servicio distinto para cada conexión, lo que la convierte
en una posibilidad tan buena como ATM y más barata.
 Mediante la asignación de valores para el caudal medio garantizado
(CIR : Commited Information Rate), el intervalo de observación (Tc: Commited
rate measurement interval) y el caudal físico de la línea de acceso (C), será
posible controlar, para cada circuito virtual, que los usuarios se ajusten a
transmitir el volumen de información comprometida y en exceso (Bc :
Commited Burst Size y Be, respectivamente), lo que permitirá el no perder
datos que no superen el tráfico comprometido.

Por otro lado también existe la posibilidad de marcar tramas para indicar
la importancia de unas respecto a otras, a través de la activación del bit DE
existente en la trama Frame Relay.

Todas estas características, así como su elevado rendimiento y

velocidad convierten Frame Relay en otra posibilidad de tecnología de red a
implementar para la obtención de unos niveles apropiados de calidad de
servicio. Si bien, sigue siendo inferior a la tecnología en ATM y soporta peor el
tráfico multimedia que esta, pero para su implantación se requiere de un menor
coste económico.

NORMA 802.1P

En esta sección vamos a estudiar cómo se obtiene calidad de servicio en redes

802 para la transmisión de tráfico multimedia en la mayoría de las redes LANs
a través del estándar 802.1p, aceptado e incluido dentro del 802.1D en 1997.
Esta norma va a permitir clasificar el tráfico, asignarle una “prioridad de
usuario” y filtrar dinámicamente el tráfico multicast.

1 Norma 802.1D

802.1D es el estándar para puentes de Control de Acceso al Medio

(Media Access Control Bridges), que incluye en su última acepción las normas:
802.1p (priorización de tráfico y filtraje dinámico de Multicast), 802.1Q(filtrado y
priorización a través de VLANs), 802.1 j (Administración de objetos para
puentes MAC), 802.6k (soporte para DQDB), 802.11c (soporte para LANs vía
radio) y 802.12 e(soporte para prioridad bajo demanda). Ha sido aprobado por
ISO/IEC JTC1/SC6 como 15802-3.
La norma define una arquitectura y un protocolo para la interconexión de
redes LAN IEEE 802 por debajo de la frontera del servicio MAC. Además
introduce el concepto de filtrado en redes LANs con puentes y los mecanismos
para almacenar la información del filtrado y su gestión en una base de datos.
Estos servicios de filtrado pretenden :
1. Proporcionar capacidades para soportar la transmisión de
información crítica al tiempo en un entorno LAN.

2. Soportar multicast dinámico y el establecimiento de grupos en un

entorno LAN, así como el filtrado de tramas en los puentes dirigiéndolas a
un determinado grupo y enviándolas solamente a determinados segmentos
de la red LAN para que lleguen a los miembros de ese grupo.

La última actualización de la norma, con la inclusión de las anteriormente

mencionadas, contempla:

Cómo filtrar el tráfico con puentes.

Introduce el concepto de clases de tráfico y su efecto en el envío de

tramas, soportando los puentes múltiples clases de tráfico.

Indica cómo es la estructura de la Base de Datos del Filtrado que se

necesita para soportar servicios de filtrado dinámico Multicast.

El protocolo de registro que se necesita para proporcionar ese filtrado

dinámico para grupos.

Muestra, además, toda la gestión y operaciones necesarias para

soportar los anteriores servicios .

1.1 RELACIÓN IEEE802.1D E IEEE802.1Q

IEEE 802.1Q extiende los conceptos de servicio de filtrado y LAN con

puentes para proporcionar un conjunto de capacidades que permitan a los
puentes soportar la definición y administración de LANs Virtuales. Estas
capacidades incluyen la definición de un formato de trama VLAN que permita
llevar una identificación VLAN y una información de la prioridad del usuario
sobre tecnologías LAN, como CSMA/CD, que inherentemente no tienen la
capacidad de señalizar la prioridad. Esta información se lleva en una cabecera
especial llamada TAG HEADER, que se inserta tras la dirección MAC destino y
la dirección MAC fuente de la trama original.

Las especificaciones de VLAN con puentes de 802.1Q son

independientes de lo aparecido en IEEE 802.1D, aunque 802.1Q se basa en
los siguientes conceptos aparecidos en 802.1D :

1. En el esquema de arquitectura de los puentes.

2. En el servicio de subcapa interna y cómo proporcionarla por 802 LAN

MACs

3. Las principales características de la operación del proceso de envío.

4. El algoritmo y el protocolo de Árbol de Expansión.

5. El protocolo GARP (Protocolo de registro de atributos genéricos).

6. El protocolo GARP MULTICAST (GMRP).

1.2 RELACIÓN 802 E ISO/CCITT

Para asegurar la compatibilidad entre el modelo de red ISA

(Interconexión de Sistemas Abiertos) y los estándares 802, se ha dividido el
nivel de enlace de datos en dos subniveles: el control de acceso al medio
(MAC) y el control lógico del enlace (LLC). Las funciones fundamentales
realizadas por el subnivel MAC son : agrupación de los bits (que implica
delimitación de tramas y direccionamiento) y la gestión de acceso al medio.
La siguiente figura muestra los estándares IEEE 802 y su situación en
comparativa con el modelo de capas ISO.
 Figura 51 : Estándares IEEE 802 – modelo ISO

También es necesario tener en cuenta el formato de las unidades de

datos de protocolo (PDU) utilizados por los subniveles LLC y MAC para
comunicarse. Sus formatos son :

Figura 52. Unidad de datos de LLC y MAC.

Volver arriba
2 Características de los puentes

Los puentes aparecen en el nivel de conexión de datos del modelo OSI,

tal y como indica la siguiente figura. En este nivel se controla que las tramas de
información lleguen correcta-mente a su destino, así como se asegura el
control de acceso al medio para la compartición simultánea del mismo. En este
nivel se definen los métodos de acceso utilizados por la red, tales
como Ethernet (CSMA/CD), Token-Ring, FDDI, Local Tolk. En las redes
locales, como se comentó anteriormente, este segundo nivel se divide en dos:
El nivel MAC (Media Acces Control) y el nivel LLC (Logical Link Control).

Figura 53 : Modelo OSI

Los puentes (bridges) son dispositivos que permiten la interconexión de

dos redes y constituyen una alternativa a los repetidores, solventando los
problemas que estos presentan. A diferencia de los repetidores, las tramas que
recibe de un segmento son almacenadas en su buffer interno y son
chequeadas (filtradas) antes de su reexpedición para compro-bar que están
libres de errores. El puente trabaja en el nivel de la capa de enlace, nivel 2 del
modelo de referencia OSI(nivel MAC), y por lo general son específicos del
hardware; es decir : Ethernet a Ethernet, Token-Ring a Token-Ring, …(por
ejemplo : un bridge Ethernet permitirá a dos o más redes Ethernet ser
conectadas e interoperar juntas, independientemente de los protocolos de red
usados). Como hemos dicho anteriormente el puente es un equipo que llega al
nivel común que tienen las LAN que es el LLC (nivel de enlace lógico), y es
precisamente donde radica una de sus ventajas que es el poder conectar
distintas tipos de LANs. El funcionamiento es el siguiente : cuando un
segmento manda información a otro esta información se reconvierte al nivel
LLC y de ahí volverá a bajar al MAC y al Físico correspondientte a la normativa
del segundo segmento.

Figura 54. Conexión con puentes.

2.1 FUNCIONAMIENTO

A diferencia de los repetidores que transmiten las tramas tal y como le

llegan, los puentes almacenan y reexpiden la información. El puente, al
conectar dos segmentos de red realiza funciones de filtro de las tramas de
información que transitan a su través. Los puentes son capaces de introducir
modificaciones en las tramas antes de que sean reexpedidas. Además un
puente puede lograr aumentar la longitud de una red; de modo que unos
usuarios pueden alcanzar a otros como si todos estuvieran situados en el
mismo segmento de red.

La siguiente figura muestra la estructura interna de un puente:

 Figura 55: Estructura interna de un puente

Hay que destacar tres ventajas fundamentales que presenta el uso de

puentes :

1. El número de estaciones conectadas y el de segmentos de la red puede

incrementarse progresivamente. Esto resulta de gran importancia para la
construcción de grandes redes LAN distribuidas en amplias zonas
geográficas.
2. El almacenamiento de las tramas recibidas de un segmento antes de su
envío, significa que dos segmentos interconectados pueden
comunicarse utilizando diferentes medios de acceso al medio; es decir,
por medio de diferentes protocolos(aunque como se explica
posteriormente, este característica presenta una serie de inconvenientes
dependiendo de los protocolos usados).
3. La separación de una red LAN en varias de menor tamaño mediante
puentes, puede lograr una mejor eficacia de la misma, proporcionando
un mejor rendimiento para toda la red.
TABLAS DE RUTA

Los puentes se sirven de las denominadas tablas de ruta para

determinar el tráfico a reexpedir a los demás dispositivos a través de él. Este
hecho se traduce en que el tráfico local de una red, permanece local; no
afectando al funcionamiento en otra red conectada por medio de un puente.
 Figura 56: Tabla de rutas

Para que el puente funcione correctamente, es preciso que conozca las

direcciones de todos los dispositivos a los cuales puede reexpedir tramas de
información. En los inicios tecnológicos de los puentes, el administrador de la
red se encargaba de elaborar las tablas de ruta para así informar al puente de
las direcciones disponibles y su ubicación. En la actualidad, la mayoría de los
puentes están dotados de la tecnología adecuada que les permite construir
ellos mismos sus propias tablas de ruta.

RENDIMIENTO DE UN PUENTE

El modo más habitual de evaluar el rendimiento de un puente es por

medio de dos parámetros :

El número de paquetes que puede filtrar o examinar.

En los productos actuales, el nivel de filtraje se sitúa entre los 2000 y

25000 paquetes examinados por segundo.

El número de paquetes que puede reexpedir o pasar a otra red.

El rango más usual de paquetes reexpedidos es entre 1500 y 15000

paquetes por segundo.

Estos dispositivos de interconexión de redes pueden ser utilizados para

incrementar el funcionamiento medio de una red, mediante la subdivisión de
una gran red en otras menores es posible gestionar más adecuadamente los
volúmenes de tráfico iniciales. Por otra parte, un puente mal utilizado puede
provocar la aparición de cuellos de botella, impidiendo el deseable flujo de
datos en la red.
2.2 TIPOS

En función de las características que posean, nos podemos encontrar

con las siguientes clases de puentes :

2.2.1 Puentes transparentes

Los puentes transparentes, también conocidos como spanning tree, se

caracterizan principalmente porque son capaces de aceptar todas las tramas
transmitidas a todas las LAN a las que se encuentre conectado. La presencia
de estos puentes en la comunicación entre dos estaciones resulta trans-
parente para ambas, puesto que son ellos quienes se encargan de elaborar las
rutas para expedir las tramas, o sea para las estaciones es indiferente conocer
las existencia del puente o no, ellas trans-miten de una estación a otra. Un
segmento de una red LAN se conecta física-mente a través de lo que se
conoce como puerto del puente; los puentes básicos tienen dos puertos
mientras que los puentes multipuerto tienen una mayor número de puertos para
la conexión múltiple de varios segmentos de red. El chip asociado a cada
puerto es el que contiene la información relacionada con el subnivel MAC. El
puente transparente también dispone de una memoria que se utiliza para
almacenar los datos hasta que se proceda a su retransmisión . Como norma
general, una topología basada en el uso de puentes multipuerto ofrece un
rendimiento más elevado que con el uso de puentes de dos puertos. En la
figura siguiente se aprecia una típica topología de red empleado puertos
simples y multipuerto.

Figura 57: Ejemplo de puentes transparentes

 Para la retransmisión de los datos, el puente se ayuda de una tabla de
rutas o de direcciones, a través de la cual es posible determinar para cada
dirección asociada a un DTE el puerto por el que se puede acceder.

Mediante esta tabla de rutas, el puente puede conocer en qué

red LAN se encuentra cada estación, como se puede observar en la siguiente
figura :

Figura 58: ejemplo configuración automática

La mayor dificultad que presentan los puentes transparentes es la

creación de la tabla de rutas. Tenemos dos posibilidades, una de ellas aunque
no la mejor es la creación de la tabla implementándola en una PROM, la gran
desventaja de este método es su poca flexibilidad, ya que no permite recoger
cambios de DTEs de un segmento a otro o posibles incorporaciones de nuevos
DTEs a un segmento.

El otro método consiste en generar y mantener las tablas de forma

dinámica. A continuación explicamos el funcionamiento de esta técnica.

Cuando un puente transparente inicia su tarea, las direcciones físicas de

las estaciones y sus puertos asociados no se encuentran localizadas en la
tabla de direcciones, la tabla de direcciones está vacía. Para obtenerlas, el
puente utiliza la técnica conocida como inundación : envía las tramas a todas
lasLAN a las que esté conectado, excepto la emisora de la trama. El proceso
de inundación lógicamente el puente siempre lo llevará a cabo cuando la
dirección destino de la trama no la tenga localizada en su tabla, por otra parte
el puente que recibe una trama de un segmento aprende que el nodo que
emitió la trama está situado en ese mismo segmento, cualquiera que sea el
destino final de la trama, y hace la correspondiente anotación de la dirección de
la estación y su puerto asociado. Con el paso del tiempo, el puente conoce los
destinos, y las tramas que le llegan son dirigidas solamente a
la LAN correspondiente, y no las difunde por inundación. De manera
esquemática, su funcionamiento es el siguiente :

Cuando ambas LAN origen y destino son las mismas: el puente

desecha la trama.

Cuando ambas son distintas : reexpide la trama.

Si son distintas y no conoce a la estación destino : envía la trama a

todas las LAN, mecanismo conocido como inundación(flooding).

La tabla de direcciones es actualizada regularmente, debido a que la

topología de la interconexión de la red puede cambiar a lo largo del tiempo, o
según se activen/desactiven puentes de la red. Por este motivo, en las tramas
se incluye el tiempo de llegada : cuando llega una trama que ya figura en la
tabla, su tiempo se actualiza respecto al anterior, así el tiempo asociado a cada
anotación refleja la última vez que se vio una trama procedente de la máquina
en cuestión. Periódicamente, los puentes dialogan entre si y revisan las tablas,
borrando todas las anotaciones que tienen una antigüedad superior a unos
minutos.

La principal ventaja de este tipo de puentes, es que permiten una

sencilla conexión a cualquier estación ubicada en cualquier red y no trastocan
el funcionamiento o estructura de una red, pues tan sólo deben conectarse
para empezar a funcionar.

Esta técnica(Transparent Bridging) es la técnica básica utilizada con

estos dispositivos, y es conocida más comúnmente como la técnica del auto-
aprendizaje por los motivos que acabamos de ver. Por otra parte, una
consecuencia directa de esta técnica es que el puente evita las colisiones que
están situadas en el segmento, de modo que no afecten a otro segmento de la
red. Por este motivo, el puente posibilita las comunicaciones simultáneas en
segmentos distintos pero interconectados. Sin embargo, cuando la conexión es
de carácter intersegmento, sólo es posible realizar la transmisión de una trama
de un segmento hacia otro.
ALGORITMO SPANNING TREE

En el caso anterior acabamos de comprobar el correcto funcionamiento

de una red local con la técnica de auto-aprendizaje, pero ahora bien; no hemos
hecho mención de la posible aparición de bucles entre los segmentos que
conforman una red. En redes relativamente grandes o importantes, podemos
encontrar una tipología o estructura sumamente compleja, donde la
coexistencia de varios puentes y múltiples segmentos puede dar lugar a la
formación de bucles en la emisión de tramas. En este caso, la técnica del auto-
aprendizaje se ve seriamente limitada y no puede gestionar adecuadamente la
red.

Figura 59: Configuración con cuatro redes y dos puentes

El Spanning Tree Algorithm o STA, es una técnica que establece un

protocolo de comunicación entre los puentes para evitar las conexiones
redundantes y almacenar tan sólo aquellas conexiones más importantes, de
acuerdo a criterios de rapidez, economía, etc. y conseguir redes sin bucles.

En la comunicación que se establece entre los puentes propios de una

red, estos establecen cuáles son las conexiones más interesantes y las menos;
reservando estas últimas para ciertas ocasiones especiales como fácilmente
podemos comprobar. El caso más evidente se nos plantea cuando se produce
un fallo en un enlace de la interconexión seleccionada; este caso el algoritmo
se encarga de restablecer la interconexión por vías alternativas, siendo estas
abandonadas cuando la línea habitual puede reestablecerse.

Esta técnica persigue construir el llamado árbol de expansión, donde se

reflejan una única trayectoria entre todos los nodos de la red. Cuando este
árbol está configurado, todos los puentes de la red lo siguen para la expedición
de las tramas que les llegan. Para la construcción del árbol, cada cierto tiempo
los puentes difunden en la red su identidad y la lista de los demás puentes que
reconoce sobre la LAN. Cada puente tiene una prioridad y un identificador
único. Después, el algoritmo selecciona uno de los puentes como raíz del
árbol(root bridge, el cual será el puente con mayor prioridad y el número de
identificación mas bajo) y posteriormente se confecciona el resto del árbol al
forzar que cada puente tome la trayectoria más corta(path cost) hacia el puente
raíz. Si dos puentes cualesquiera tienen el mismo valor de trayectoria hacia el
raíz, será elegido entre ellos el de menor número identificativo. Este proceso
descrito se determina en la red a intervalos regulares de tiempo. Además, este
algoritmo presenta la gran ventaja de liberar al arquitecto de la red de analizar
la posible existencia de bucles, además una vez elaborado el árbol de
expansión, el algoritmo continúa funcionando en previsión de modificaciones en
la tipología de la red. A continuación detallamos el proceso enumerando los
pasos del algoritmo. Partimos de la base, como hemos mencionado
anteriormente, de que los puentes poseen un determinado valor de prioridad y
un identificador único y de que cada segmento tendrá un identificador único y
sus correspondientes características de velocidad en función del medio físico.

1. Determinar puente raíz. Lo definimos como aquel que posee más alta
prioridad y en caso de empate menor valor de identificador.
2. Determinar puerto raíz de cada puente activo. Se trata de determinar
uno de los puertos de los dos o más que tiene un puente. Este puerto
raíz se determina según las velocidades de transmisión de los
segmentos a los que se conecta cada puente. Es decir, si tenemos un
puente con dos puertos y uno de ellos conectado a un segmento de
velocidad X y el otro puerto a un segmento de velocidad 2X, el puerto
raíz será el de mayor velocidad(en caso de empate; el de menor valor de
identificador). El puerto raíz de cada puente lo que viene a representar
es el puerto por donde se van a transmitir datos desde ese puente hacia
el puente raíz. Podríamos decir que el puerto raíz es aquel que nos da el
mínimo tiempo posible para ir al puente raíz, con lo que parece lógico
quedarse con aquel camino de menor coste.
3. Determinar puerto designado de cada segmento. Físicamente el puente
tiene dos o más puertos, el puente se comunica a través del puerto a
otro segmento. El puerto designado de un segmento será de todos los
puertos que se encuentran conectados a ese segmento aquel que dé un
valor menor en una función de coste, si coincide elegimos el puerto del
puente de menor valor de identificador. De este modo, designamos un
único puente para transmitir o recibir datos desde o hacia el puente raíz
 y designamos un único segmento para transmitir o recibir datos desde o
hacia el puente raíz; todo esto con la intención de determinar un único
camino para llegar a este puente raíz.
En este paso se establece el estado de cada puerto de cada uno de los
puentes en transmisión o bloqueo. Inicialmente, la totalidad de los puertos del
puente raíz son puertos designados y por tanto, se establecen en estado de
transmisión. Para el resto de los puentes, sólo los puertos raíces y los
designados se configuran en estado de transmisión, y el resto en bloqueo.

Figura 60: Algoritmo Spanning Tree

Para realizar este algoritmo o protocolo las entidades del protocolo de

los puentes se intercambian unidades de datos, denominadas BPDUs, cuyo
formato se muestra en la siguiente figura :

Figura 61 : Formato y configuración de BPDU

 Cuyos campos han sido utilizados anteriormente para la explicación del
funcionamiento de este algoritmo.

2.2.2 Puentes de encaminamiento fuente

Esta técnica apareció debido a que los puentes transparentes no hacen

un uso óptimo del ancho de banda, al utilizar solo un subconjunto de la
topología(el árbol de expansión). Aunque pueden ser usados para conectar
cualquier tipo de LANs, se suele utilizar principalmente para la conexión de
segmentos de LAN de tipo Token-Ring(normativa 802.5).

En la técnica de los puentes de encaminamiento fuente, el emisor de

tramas debe conocer la ubicación del nodo receptor, es decir, si se encuentra
situado en la misma LAN. Estos puentes no resultan transparentes a las
estaciones, pues estas insertan una información adicional a la cabecera de las
tramas donde se indica la dirección de destino como veremos más
detalladamente.

El proceso de funcionamiento de esta técnica consiste en: si un nodo

emisor envía tramas a un nodo situado en una LAN diferente, coloca a uno el
bit de mayor orden de la dirección de destino, además incluye en la cabecera
de la trama la ruta exacta que la trama debe seguir. Esta trayectoria se
confecciona teniendo en cuenta que cada LAN tiene un número de 12 bits y
cada puente está definido por un número identificativo(para su propia red) de 4
bits, de modo que dos puentes pueden tener el mismo número siempre y
cuando pertenezcan a segmentos distintos. El campo de la información del
camino a seguir se inserta en la cabecera, tras la dirección de la estación
emisora. Lógicamente este campo será de longitud variable y puede ocurrir que
el campo de información de encaminamiento no exista si va dirigida la trama al
mismo segmento. Para saber si hay información de encaminamiento o no se
utiliza el primer bit de la dirección fuente I/G : cuando esté a uno indicará que
existe información de encaminamiento y lo contrario cuando valga cero. En la
figura podemos observar además como el campo de información de
encaminamiento se desglosa a su vez en nuevos campos: un campo de control
y N campos designadores de encaminamiento.
 Figura 62: estructura de la trama con información de ruta

Donde :

Com : Delimitador de comienzo

C.A. : Control de acceso

C.T. : Control de trama

D.F. : Delimitador final

E.T. : Estado de la trama

Cada designador de encaminamiento va a estar compuesto de un

identificador de segmento y un identificador de puente. Por otra parte, en el
campo de control se identifica el tipo de trama, su tamaño máximo y la longitud
del campo de ruta. El algoritmo de puentes con fuente de encaminamiento
utiliza dos tramas : la primera trama es conocida como radiado de ruta
simple(Single Route Broadcast) y la segunda el radiado de todas las rutas
posibles(All Routes Broadcast). Inicialmente cada estación emisora no sabe
cuál es la mejor ruta y para ello transmite una trama de radiado de ruta simple
que llegue a todas las demás estaciones(por un único camino, para ello se
utiliza un algoritmo para que aunque haya distintos caminos, se seleccione uno
sólo). Posteriormente, cada una de las estaciones que ha recibido una trama
de radiado de ruta simple envía una trama conocida como radiado de todas las
rutas posibles, donde le indica a la estación emisora todas las rutas posibles y
esta seleccionará con la ruta que considere más corta o de menor coste.

La trayectoria es una secuencia de números correspondientes a un

puente, una LAN, un puente, una LAN, etc. El puente de encaminamiento
fuente sólo está interesado en las tramas que tienen el bit del nodo destino de
mayor orden colocado a uno. Luego, para cada trama detectada el puente
examina la trayectoria para comprobar el número de la red LAN por la que llegó
la trama; si a este número le sigue su propio número de puente, el puente
reexpide la trama por la LAN cuyo número sigue su número de puente en la
trayectoria. Si el número de LAN de la trama es seguido por el número de algún
otro puente, la trama no es reexpedida.

Para la siguiente figura, podríamos determinar las siguientes trayectorias

:

Figura 63 : Ejemplo de trayectorias

Origen A Destino B = Segmento 1

C = Segmento 1, B1, Segmento 2, B2, Segmento 3

E = Segmento 1, B1, Segmento 2, B4, Segmento 5

Origen B Destino A = Segmento 1

D = Segmento 1, B1, Segmento 2, B3, Segmento 4

Origen E Destino A = Segmento 5, B4, Segmento 2, B1, Segmento 1

C = Segmento 5, B4, Segmento 2, B2, Segmento 3

Este algoritmo de encaminamiento presenta diferentes versiones de

funcionamiento atendiendo a diferentes criterios :

Software.
 El puente copia todas y cada una de las tramas en su memoria interna,
comprobando el valor del bit de mayor orden. Sólo cuando este bit tiene el valor
uno se realiza una mayor análisis de la trama.

Híbrido.

En este caso se encarga de analizar el bit de mayor orden, la interfaz del

puente de la LAN correspondiente y sólo reexpide la trama cuando el bit vale
uno. El mencionado interfaz

Hardware.

Además del bit de mayor orden, el interfaz examina la trayectoria para

comprobar si se debe reexpedir. Cada puente tan sólo recibe las tramas que
debe reexpedir. En esta versión, se requiere un hardware muy específico.

Estas tres distintas versiones presentan cada una de ellas una serie de
ventajas e inconvenientes con respecto a las demás. En la primera se necesita
un procesador muy rápido para el adecuado tratamiento de todas las tramas.
La última, al requerir un hardware especial, puede utilizar un procesador más
lento, o bien, el puente puede tratar un número mayor de redes LAN.

2.2.3 Puentes en paralelo

En ocasiones y para aumentar la fiabilidad, en algunos puntos se utiliza

una configuración de puentes en paralelo, como podemos observar en la
siguiente figura.

Figura 64: ejemplo de dos puentes transparentes en paralelo

La configuración de dos o más puentes en paralelo requiere un

tratamiento especial, al establecer bucles en la red; donde podemos encontrar
más de una trayectoria para el envío de tramas de información. En la figura
podemos constatar este problema : el Puente1 envía la trama F a la LAN2,
poco después, el Puente1 ve f2(trama con destino desconocido) y la envía a la
LAN1. Del mismo modo, el Puente2 copia f1 a la LAN1. Esta dificultad se ve
superada mediante la elaboración de árboles de expansión, donde los puentes
toman conocimiento de la topología de la red y la coexistencia de varios
puentes.

2.3 COMPARATIVA ENTRE LOS TIPOS

La principal diferencia ente los dos tipos de puentes reside en la

distinción entre las redes sin conexión y las orientadas a conexión.

Los puentes transparentes reexpiden cada una de las tramas de modo

independiente a la reexpedición de otras tramas. Este tipo de puente es
ignorado por las estaciones host, siendo además compatibles totalmente con
todos los productos 802 existentes. La utilización de puentes transparentes no
exige la administración manual de la red, pues los puentes se configuran
automáticamente y se adecuan a la tipología que presente la red.

Los puentes de encaminamiento fuente determinan la trayectoria a

seguir por las tramas de acuerdo a las tramas de descubrimiento, añadiendo la
dirección en la cabecera de las tramas. Este tipo de puentes no resulta
transparente a las estaciones host, por lo que estos deben ser informados de la
configuración de puentes existente en una red. Por otra parte, al no
configurarse automáticamente ni ser completamente compatibles; el uso de los
puentes de encaminamiento fuente requieren una configuración manual de la
red. Este último comentario representa una seria desventaja frente a los
puentes transparentes, pues cuando se conectan dos redes separadas
mediante puentes transparentes el funcionamiento es inmediato. En cambio,
con el encaminamiento fuente será necesario modificar los números
identificativos de las redes LAN, para así convertirlos en únicos en la nueva red
interconectada.

En lo referente al método de localización empleado, podemos añadir que

el auto-aprendizaje empleado por los puentes transparentes presenta el
inconveniente de que los puentes deben esperar a que llegue una trama de un
nodo en particular para aprender su localización. En las tramas de
descubrimiento empleadas por los puentes de encaminamiento fuente, el
inconveniente principal se produce en redes de gran tamaño, donde elaborar
las trayectorias puede adquirir complejidades de orden exponencial.
 En cuanto al tratamiento de fallos, ambos esquemas presentan serias
diferencias. En los puentes transparentes, son ellos quienes detectan los fallos
de puentes y redes, actualizando automáticamente su configuración de
acuerdo con la anomalía detectada. En el método de encaminamiento fuente,
cuando se produce un fallo el puente emisor no sabe si es debido a la estación
receptora o a la trayectoria seleccionada; reemitiendo constantemente las
tramas. Sólo cuando se emite otra trama de descubrimiento se sabe si la
estación de destino está disponible.

Volver arriba

3 Obtención de QoS CON 802.1P

En esta cláusula vamos a estudiar cómo es posible conseguir calidad de

servicio en redes 802 a través de esta norma, para ello revisaremos los
parámetros de QoS que proporcionan estas redes y la división en varias clases
de servicio y su asociación a los distintos tipos de tráfico para asegurar niveles
de prioridad.

3.1 PARÁMETROS DE QOS

Las redes de área local no garantizan la mayoría de los parámetros

necesarios para la obtención de QoS, tal y como se definen a continuación:

a) DISPONIBILIDAD

La disponibilidad del servicio se mide como esa fracción de un cierto

tiempo total durante el cual se proporciona un servicio MAC. Las
operaciones que realice el puente puede aumentar o bajar la disponibilidad
del servicio. Aumenta evitando en el camino de datos aquellos componentes
de la red que estén fallando. Disminuye si falla el puente, si el puente
deniega el servicio o debido al filtrado de tramas de los puentes.
 b) PÉRDIDA DE TRAMAS

MAC no garantiza la entrega de las tramas. Éstas pueden no alcanzar

las estaciones finales como resultado de :
Corrupción de la trama durante su transmisión/recepción a través de la
capa física.
Que la trama sea descartada por el puente debido a :
1. No pueda transmitirla en el
período máximo determinado, desechándola antes de que ésta
supere su período de vida máximo.
2. Los buffers donde se almacenan
las mismas estén llenos sin darles tiempo a vaciarse.
3. El tamaño de la unidad de datos
de servicio sea mayor que el tamaño máximo soportado por el
procedimiento MAC empleado en la LAN.
4. En ocasiones es necesario
descartar tramas para mantener otras opciones de QoS.

c) REORDENACIÓN DE TRAMAS

No se permite la reordenación de tramas según una prioridad de

usuario para una determinada combinación dirección fuente – dirección
destino. Las primitivas MA_UNITDATA.indication que se corresponde a
MA_UNITDATA.request, con la misma prioridad y para la misma
combinación dirección fuente y destino, son recibidas en el mismo orden que
las .request.

d) DUPLICACIÓN DE TRAMA

MAC no permite duplicar tramas. Los puentes no introducen la

duplicación de tramas de datos de usuario. Las posibilidades de duplicar se
reducen al envío a través de distintos caminos entre fuente-destino.

e) RETARDO DE TRÁNSITO
 MAC introduce retardo dependiendo del tipo de medio utilizado.

El retardo de tránsito de trama es el tiempo transcurrido entre una

primitiva MA_UNITDATA.request y la correspondiente
MA_UNITDATA.indication. Su valor se calcula sobre las unidades de datos
transmitidas con éxito.
También existe el retardo introducido por un determinado puente: es
el tiempo transcurrido entre la recepción de la trama más el tiempo en
acceder al medio por el que va a ser transmitido.

f) TIEMPO DE VIDA DE LA TRAMA

Es un límite superior al retardo de tránsito. El máximo tiempo de vida

de una trama es necesario para asegurar las operaciones correctas de los
protocolos de capas superiores. Para asegurar este valor máximo los
puentes pueden optar por descartar tramas, asegurando así un retardo
máximo en cada puente.

g) TASA DE ERROR DE TRAMA NO

DETECTADA

MAC introduce un nivel muy bajo de tasa de error de trama no

detectado en las tramas ya transmitidas. Para protegerse ante estos errores
se utiliza un secuencia de chequeo de trama (FCS) dependiente del método
MAC utilizado. El valor de FCS se recalcula cuando estamos ante distintos
métodos.

h) TAMAÑO MÁXIMO DE LA UNIDAD DE

DATOS DE SERVICIO

El tamaño máximo de esta unidad de datos varia con el método MAC

utilizado. Hay que tener en cuenta que el valor máximo soportado por dos
LANs es el más pequeño del soportado independientemente por cada una
de ellas.
 i) PRIORIDAD

Un parámetro de QoS permitido e incluido por MAC es la prioridad de

usuario. Una primitiva de request con mayor prioridad tendrá preferencia
sobre otra realizada desde la misma estación o desde cualquier otra
estación de la misma LAN.
La subcapa MAC mapea las prioridades de usuario solicitadas sobre
las prioridades de acceso soportadas por cada una de las métodos
individuales MAC utilizados.
Una utilidad es la posibilidad de gestionar el retardo de transmisión de
una trama en un puente, asociándole una user_priority (prioridad de usuario)
a la misma. Este tipo de retardo comprende:
Retardo en la cola de almacenamiento hasta que la trama logra situarse
en primera línea de transmisión sobre el puerto. Este tipo de retardos se
gestionan utilizando user_priority.
Retardo de acceso, para la transmisión de la trama. Se
usará user_priority en aquellas tecnologías que soporten más de una
prioridad de acceso.
La prioridad va a poder ser asignada por el usuario en base a la
dirección destino, el puerto de entrada, el puerto de salida, la prioridad de
acceso o por VLAN.

j) RENDIMIENTO

Una red LAN construida con puentes incrementa significativamente el

rendimiento en comparación con cualquier simple red de área local, debido a
las características de estos elementos anteriormente citadas, entre ellas
porque los puentes pueden localizar el tráfico dentro de las redes LANs a
través del filtrado de tramas.
3.2 PRIMITIVAS DE SERVICIO
Hemos hablado anteriormente de varios campos necesarios para
asociar prioridades, veamos pues su significado y ubicación.

1) Primitiva
M_UNITDATA.indication {
frame_type,
mac_action,
destination_address,
source_address,
mac_service_data_unit,
user_priority,
frame_check_sequence
}

El significado de los campos es:

Frame_type : tipo de trama ( de usuario, mac o reservada)
Mac_action : la acción a ejecutar tras el tipo de trama. Ej. si el tipo de
trama es de datos de usuario, las acciones que se podrían realizar son
petición de respuesta o sin respuesta.
Destination_address: dirección destino individual o de grupo.
Source_address: dirección MAC origen.
Mac_service_data_unit : datos de usuario.
User_priority: prioridad solicitada por el usuario de servicio. Su valor
está en el rango de 0 a 7, siendo el 7 el valor máximo. Los puentes tienen
la capacidad de cambiar su valor, almacenado en una tabla de prioridades
por cada uno de los puertos. Posteriormente veremos las clases de servicio
existentes y cómo asociarlas según el tipo de tráfico que circula por la red.
Frame_check_sequence (FCS): para controlar la emisión de parejas
de primitivas .indication - .request., protegiéndose así de posibles errores no
detectados para tramas que ya han sido transmitidas.

2) Primitiva
M_UNITDATA.request {
frame_type,
mac_action,
 destination_address,
source_address,
mac_service_data_unit,
user_priority,
access_priority,
frame_check_sequence
}

Esta primitiva introduce , respecto a la anterior, el

campo access_priority para indicar la prioridad de salida de la
trama. Depende del tipo de método MAC utilizado y su valor debe estar
basado en el valor user_priority.
La siguiente tabla muestra las relaciones para algunas redes LAN :

Prioridad de acceso de salida según método MAC

utilizado
User_priorit 802.3 8802-4 8802-5 8802-6 FDI
y (Ethernet) (Token (Token (DQBD)
b.) R.)
0 0 0 0 0 0
1 0 1 1 1 1
2 0 2 2 2 2
3 0 3 3 3 3
4 0 4 4 4 4
5 0 5 5 5 5
6 0 6 6 6 6
7 0 7 6 7 6

Como vemos, para el caso de una Ethernet la prioridad de salida de la

trama basada en el campo access_priority va a ser siempre la mínima (0),
independientemente de que la prioridad de usuario sea mayor.

3.3 PRIORIDADES DE USUARIO Y CLASES DE TRÁFICO

 La norma 802.1p permite 8 tipos de clases de tráfico clasificados como
“prioridades de usuario” (user_priority) por cada puerto del puente, siendo el
rango de valores de prioridad de usuario del 0 al 7. Para conseguirlo se
necesitan 3 bits, en los que será necesarios aumentar el formato básico de
Ethernet (para visualizar este campo acudir a la cláusula 7 de este capítulo
donde se presenta de forma general la norma 802.1Q).
En la siguiente tabla se pueden observar las prioridades:

PRIORIDAD DE PRIORIDAD RANGO

USUARIO DE USUARIO
POR DEFECTO
0 0 0-7
1 1 0-7
2 2 0-7
3 3 0-7
4 4 0-7
5 5 0-7
6 6 0-7
7 7 0-7

La prioridad del tráfico en redes LAN va a depender también del número

de colas existentes en cada puerto. El almacenamiento de las tramas en estas
colas se realiza en base al campo user_priority y a la dirección origen y destino
para el tráfico unicast y en base al campo user_priority y la dirección destino
para tramas multicast.
Una vez determinadas las clases de tráfico por puente, será necesario
mapearlas (asociarlas) con el tipo de tráfico que circule por la red para
asegurar que el tráfico en tiempo real (por ejemplo) sea atendido antes que el
tráfico para el que un servicio best effort es más que suficiente.
El tráfico podría subdividirse en los siguientes grupos:
a) Control de red (máxima importancia)

b) Voice : retardo < 10 msg

c) Vídeo : retardo < 100 msg

d) Carga Controlada (algunas

aplicaciones importantes)
 e) Excellent Effort (como best effort
para usuarios importantes)

f) Best Effort (prioridad por defecto en

la LAN)

g) Background (juegos, etc.)

La siguiente tabla muestra cómo se podría asociar el campo

user_priority al tráfico:

PRIORIDAD DE USUARIO TIPO DE TRÁFICO

0 Excellent Effort (or Business Critical)
1 Background
2 Spare
3 Best Effort
4 Aplicaciones de carga controlada
5 Vídeo interactivo < 100 ms latencia y jitter
6 Voz interactiva < 10 ms latencia y jitter
7 Control de red

Teniendo en cuenta los distintos tipos de tráfico y el número de colas

existentes, el tráfico se subdivirá en grupos, de forma que, en el caso de que
solo existieran dos colas por puerto se recomienda que a los tráficos de las
clases 4 al 7 se les asigne la cola de alta prioridad y que a los tráficos de las
clases 0 al 3 se les asigne la cola de baja prioridad, si existen 3 colas se hará
una tercera subdivisión del tráfico y así consecutivamente, tal y como muestra
la siguiente tabla :

NÚMERO DE
COLAS TIPOS DE TRÁFICO

1 {a, b, c, d, e, f ,g}

{a, b, c, d }
2
{e, f , g}

3 {a, b}
{c , d }
 {e, f , g}

{a , b}
{c, d }
4
{e , f }
{g}

{a , b}
{c}
5 {d }
{e, f}
{g}

{a ,b}
{c}
{d}
6
{e}
{f }
{g}

a
b
c
7 d
e
f
g

Tabla: Mapeado tipo de tráfico a Clase de tráfico

Una vez establecidas todas estas asociaciones nos preguntamos cómo

utiliza esta información del puente. El puente, para transmitir las tramas, mira
por cada uno de los puertos la clase de tráfico que estos soportan, escogiendo
de entre ese tipo de tráfico aquellas tramas que se encuentren en las colas de
mayor prioridad (y si hay colas de un nivel mayor deben estar vacías),
habiéndose realizado previamente una asignación de colas según la tabla
antes descrita, enviando así el tráfico considerado más prioritario.

Volver arriba
4 Filtrado del tráfico Multicast

Tal y como se explicó en el apartado de características de los

puentes, las redes LANs con estos elementos permiten filtrar el práctico,
proporcionando :

1. Funciones de control: Es posible realizar un control sobre el uso

de direcciones fuente y destino en determinadas partes de la red. Esto
permite a los administradores de red realizar una gestión individual
sobre determinados segmentos de la misma o sobre grupos de
usuario.
2. El filtrado aumenta el rendimiento de la red y reduce la carga en
las estaciones finales debida a las tramas recibidas que estaban
destinadas a otras estaciones. Esto es :
a) Para tramas enviadas hacia una dirección destino específica
intentar que sean enviadas a través de la ruta adecuada.
b) Que las tramas enviadas hacia grupos sean enviadas a
aquellas partes de la red donde se encuentren los miembros de
ese grupo.
3. Permite aprendizaje dinámico.

Los servicios de filtrado proporcionados por los puentes y

relacionados con la calidad de servicio son el retardo de tránsito, la prioridad
y el rendimiento. Estos están disponibles tanto para administradores de red
(para realizar control de la red) como para las estaciones finales (controlar
las direcciones finales). A su vez, todos estos servicios de filtrado se basan
en las direcciones MAC fuente y destino.

4.1 TIPOS
Los tipos de filtrado existentes son :
 a) Filtrado Básico. Soportados por el proceso de envío de tramas y por
las entradas de filtrado estáticas y dinámicas existentes en lo que se
denomina base de datos de filtrado.

b) Filtrado Extendido. Soportados por el proceso de eenvío de tramas y

por las entradas de filtrado estáticas y de grupo existentes en la base de
datos de filtrado. Esta información de grupo se mantiene a través del
protocolo de registro multicast GARP (GMRP).

Todos los puentes deben soportar al menos los servicios de filtrado

básicos. El resto de servicios es opcional.

4.2 OBJETIVOS DEL FILTRADO

Los puentes filtran tramas por diferentes causas :

1. Para prevenir la duplicación de las tramas, esto es, calculando y

configurando correctamente la topología de la red.
2. Para reducir la carga de tráfico en diversos segmentos de la red. Para
conseguirlo se utilizan distintas técnicas:
a. Direcciones permanentes
b. Configuración explícita de información de filtrado estática.
c. Aprendizaje automático de la información de filtrado para tráfico
unicast, utilizando el campo dirección origen.
d. Eliminar la información de filtrado que ya ha sido aprendida.
e. Aplicación del protocolo GMRP para actualizar la información
dinámica de filtrado.

4.3 PROCESO DE APRENDIZAJE

Una de las ventajas de los puentes es que observan el camino que
siguen las tramas en la red para establecer rutas. Es lo que se llama el proceso
de aprendizaje. Este proceso puede deducir el camino seguido por una trama a
través de la red observando el campo source_address de las tramas recibidas
en cada puerto. Por cada valor obtenido crea o actualiza una entrada dinámica
(su valor cambia) en la base de datos de filtrado si el puerto lo permite, si se
trata de una dirección específica y no de un grupo, si para ese puerto no existe
una entrada estática y si el número de entradas en la base de datos no excede
su capacidad de almacenamiento.
4.4 BASE DE DATOS DE FILTRADO
En una tabla que almacena información de la transmisión de las tramas
a través de los puertos de los distintos puentes de la red. La información se
almacena en forma de entradas :

a) Estáticas : su valor permanece constante. Mantienen toda la

información estática en la base de datos ya sea de direcciones
individuales o de grupo. Esto permite llevar un control del envío de
tramas a una dirección particular e incluir información del filtrado
dinámico asociada con servicios de filtrado extendido para su uso por
este.

Están compuestas por una dirección MAC individual o de grupo y un

puerto que indique para cada dirección si estas trama va a ser enviada o
filtrada o ambas. Todos estos valores se añaden/modifican/eliminan
mediante un control explícito (no se realizad automáticamente).

b) Dinámicas: Existen dos tipos de entradas :

I. Entradas de filtrado dinámicas: para aprender por

qué puertos se han enviado las tramas. Se actualizan mediante el
proceso de aprendizaje.

II. Entradas de Registro de Grupo: registran direcciones

MAC de grupos. usan el protocolo GMRP y son soportadas por los
servicios de filtrado extendidos (por lo tanto, solo por los puentes
que lo permitan).

Cada entrada en la tabla está compuestas por una dirección MAC

individual y un puerto que indique por dónde va a ser enviada esa trama,
además debe existir tan solo 1 entrada por cada dirección MAC.

Las entradas dinámicas son eliminadas después de un tiempo

denominado “Ageing Time”, que debe ser mayor que la diferencia entre el
momento en que se creo la entrada hasta su última actualización.

Un ejemplo de tabla de filtrado comprendería :

 PUERTO ENTRADA DIRECCIÓN DESTINO PUERTO SALIDA
1 AA-01-03-44-56-78 2
2 09-12-34-56-78-88 Filtrar

4.5 COMPORTAMIENTO POR DEFECTO DEL FILTRADO DE

GRUPOS
Puesto que el filtrado dinámico se realiza automáticamente en los
puentes existen varias opciones de funcionamiento por defecto:

1. Enviar a todos los grupos. Se envía la trama a no ser que una

entrada de filtrado estática indique otra acción a realizar.

2. Enviar a grupos no registrados en la tabla. Se envía la trama a no

ser que:

a. Exista una entrada de filtrado estática que especifique otra

opción a realizar.

b. Exista una entrada de filtrado estática que indique que hay

que enviar o filtrar y una dinámica, sin embargo, que indique
que hay que filtrar.

c. No exista una entrada de filtrado estática pero sí una de

registro de grupo que sí lo indique.

3. Filtrar a grupos no registrados. En este caso la trama se filtra, a no

ser que :

a. Exista una entrada

estática que indique otra opción a realizar.

b. Exista una entrada

estática de filtrado que indique filtrar pero exista una entrada
de grupo que, sin embargo, indique enviar.

c. No exista una entrada

estática de filtrado y exista una entrada de registro de grupos
que indique enviar.

Por ejemplo, una dirección MAC individual y un puerto de salida

específico.
 ENTRADA ENTRADA DINÁMICA O NO EXISTE
ESTÁTICA ENTRADA ESTÁTICA
INFORMACIÓN Enviar Filtrar Enviar Filtrar No existe entrada de
DE FILTRADO filtrado dinámica
ACCIÓN Enviar Filtrar Enviar Filtrar Enviar

Hay que tener en cuenta que para aquellos puentes que solo soporten
servicios básicos de filtrado el funcionamiento será enviar las tramas a todos
los grupos para todos los puertos del puente.

4.6 BASE DE DATOS PERMANENTE

Almacena un número de entradas de filtrado estáticas fijas que se
utilizan en el momento de inicialización, para inicializar la base de datos de
filtrado.

Volver arriba

5 GARP

El protocolo de registro de atributos genéricos (Generic Attibute

Registration Protocol ) o GARP proporciona una forma genérica de distribuir,
registrar y eliminar atributos entre miembros de una LAN con puentes
(denominados participantes GARP, por ejemplo las estaciones finales). Un
ejemplo de uso de este protocolo es GMRP para el que se usan como atributos
direcciones MAC de grupos y servicios de grupos. Otro uso es el protocolo
GARP VLANs (GVRP) utilizado para registrar VLANs.

5.1 FUNCIONAMIENTO
En el funcionamiento del protocolo GARP es necesario tener en cuenta
varios elementos: la aplicación GARP, los participantes GARP y las
declaraciones de atributos. Cuya nomenclatura ya deja entrever sus funciones.
El primero define el ámbito de aplicación del protocolo (como por ejemplo
GMRP). En el segundo caso nos estaremos refiriendo a los miembros que
participan en el intercambio de valores dentro de una aplicación (ejemplo, un
grupo). Por último, las declaraciones de atributos son los valores que se van a
intercambiar entre sí los miembros.

Por otro lado, dentro de los participantes GARP existen dos tipos
especiales por la función específica que realizan. Así tenemos :

b. El funcionario o secretario (Registrar) : cuya función es grabar

la presencia de otros miembros (participantes) en el segmento.
No envía ningún mensaje.

c. El solicitante o aspirante (Applicant) : se encarga de enviar

solicitudes y consultas de registros a los miembros de la
aplicación.

Para comprender la actuación de todos estos elementos veamos en la

siguiente figura cómo se realiza el registro y la propagación del valor de un
atributo hacia el resto de componentes de la red, para el caso de que el origen
de la declaración del atributo sea una sola estación. Este diagrama muestra
qué puertos de los puentes declaran el valor del atributo para su propagación
por la red para que llegue a su destino/s. Las flechas muestran el camino a
recorrer. Se puede observar que el valor del atributo se envía a todos los
segmentos de la LAN, sin embargo se registra solamente en aquellos puertos
que lo reciben (no en los que trasmiten).
 Figura 65 : Ejemplo de funcionamiento de GARP teniendo como origen una
estación individual

Pongámonos ahora en el caso del registro y propagación del valor de un

atributo hacia el resto de componentes de la red desde dos estaciones finales
situadas en distintos segmentos LAN que declaran el mismo valor de atributo.
Como consecuencia de esto (como muestra la figura posterior) el valor del
atributo se registra en todas las estaciones finales y en más de un puerto de
algunos puentes.
 Figura 66: Propagación del valor de un atributo desde dos estaciones

De esta manera se forma una topología de árbol de expansión que

contiene a todos los miembros que han declarado un atributo.

GARP opera únicamente en puentes que están preparados para su

uso, esto es, aquellos que permiten el modo de filtrado extendido. Para
aquellos otros puentes que no funcionen en este modo, el protocolo GARP es
transparente para ellos, de forma que todas las GARP PDUs que atraviesen
sus puertos serán enviados sin tener conciencia de su significado. De la misma
manera, para aquellos puentes que estén preparados para el uso de GARP
pero no participen en la aplicación GARP en uso, el intercambio de mensajes
será transparente.

5.2 ARQUITECTURA GARP

En los apartados anteriores, en concreto en el de funcionamiento, se ha
hablado de algunos componentes del protocolo GARP, definamos aún más su
significado para clarificar el funcionamiento de este protocolo. Para ello
fijémonos en la siguiente figura que muestra la composición de un puente o una
estación final.
 Figura 67: Arquitectura GARP

En ella nos encontramos con :

5.1 Un participante GARP : es un miembro de la aplicación.

5.2 Una aplicación GARP: indica de qué forma se está poniendo en

práctica el protocolo. Para cada aplicación es necesario definir unos
tipos de atributos, los valores de los mismos, la semántica de éstos, la
dirección MAC de grupo para intercambiar GARP PDUs entre los
participantes de una misma aplicación y la estructura y codificación de
esta unidad de datos.

5.3 GID : es el componente de declaración de información. Define el

estado actual de todas los valores de atributos declarados y registrados
asociados con cada participante. Para obtener esta información utiliza
las tablas de transición de estado del secretario (registrar) y del
solicitante (register). Un ejemplo de tabla de transición del secretario
donde se registran los participantes en un determinado segmento es el
siguiente :
 ESTADO

IN (Dentro) LV (Dejando) MT (vacío)

EVENTO

rJoinIn IN IN IN

rjoinEmpty IN IN IN

rEmpty IN LV MT

rLeaveIn SV LV MT

rLeaveEmpty LV LV MT

LeaveAll LV LV MT

Leavetimer! X MT X

Donde la “r” en los eventos indica que se ha recibido ese tipo de

mensaje, por ejemplo rJoinIn, indica que se ha recibido el mensaje
JoinIn. El evento Leavetimer! Indica que ha terminado el periodo de
Leave (salir).

Del mismo se construiría una tabla entre los eventos y los estados
de las aplicaciones, que aquí no se va a reflejar, tan solo citar que los
posibles estados son : VA (miembro activo muy ansioso), AA (miembro
activo ansioso), QA (miembro activo tranquilo), LA (miembro activo
saliendo), VP( miembro pasivo muy ansioso), VO (observador muy
ansioso), etc.

5.4 GIP: es el componente GARP para propagar la información entre los

participantes de la misma aplicación en un puente.

Una vez estudiada la arquitectura de GARP y su funcionamiento veamos

a continuación el intercambio de mensajes en este protocolo.
5.3 MENSAJES
El protocolo GARP se basa en que los participantes deben comunicarse
entre sí su estado actual antes de enviar las direcciones MAC de grupos. Para
realizar esa comunicación se utilizan lo que se conoce como mensajes. Existen
los siguientes tipos de mensajes:

a. Empty : Se utiliza para consultar si existen más miembros que vayan a

declarar el mismo atributo.
b. JoinEmpty : Cuando se quiere declarar un atributo y antes de registrarlo
se observa que no existen más miembros que vayan a declarar el mismo
atributo, por lo que seré el primero.
c. JoinIn: Se usa para comprobar que existen otras estaciones
escuchando para unirse al grupo al que yo también me quiero unir.
d. Leave: Indica que el participante quiere retirarse.
e. LeaveAll: Este mensaje se usa para retirarse cuando se produce
pérdidas de mensajes, indicando que el atributo será eliminado a menos
que algún miembro tenga interés en que permanezca registrado,
uniéndose de nuevo con el mensaje Join.
Dos de las características más importantes de GARP es el hecho de que
si otras estaciones se han unido a un grupo en tu segmento, tu no vas a
necesitar unirte y, en segundo lugar, este protocolo trabaja incluso si se ha
perdido un mensaje, lo que asegura eficiencia y escalabilidad.

5.4 ESTRUCTURA DE LA UNIDAD DE DATOS DE GARP

Esta cláusula explica por qué campos está formada la unidad de datos
de este protocolo que se intercambian entre sí los participantes del mismo,
quienes los procesan según el orden en que reciben las PDUs.

Cada GARP PDU identifica la aplicación que la generó y el destino al

que es transmitida. Además lleva uno o más mensajes GARP, cada uno de
ellos identificando un evento (por ejemplo, Join, Leave, LeaveAll, etc.) y la
clase/s de atributos y sus valores a los que aplicar los eventos.

La siguiente figura muestra el formato de la unidad de datos :

 Figura 68: Formato de GARP PDU

Cada campo básico del formato representa a un octeto. El significado de

los mismos es :

5.5 Identificador de protocolo: contiene los dos primeros octetos. Su valor

es 0x0001, que identifica a GARP.

5.6 Mensajes: formado por el tipo de atributo y la lista de atributos. En el

primer campo se especifica el tipo que se está utilizando, existiendo
valores de 1 a 255, ya asignados.

5.7 La lista de atributos: contiene a uno o más atributos de los que indica la
longitud, el evento y el valor del mismo. La longitud está entre 2 y 255.
La codificación de los eventos está asignada, así nos encontramos con
que el valor 1 identifica a JoinEmpty, 4 a LeaveIn, etc. En último lugar el
valor del atributo puede ocupar hasta N octetos.

Los mensajes GARP se empaquetan en GARP PDUs, junto con los

atributos hasta llegar a la marca de fin de mensaje o no existan más atributos
que empaquetar. Intercambiándose posteriormente entre los participantes
GARP de la aplicación.
5.5 VALORES TEMPORALES
Los valores de tiempo por defecto (relojes) utilizados en este protocolo
son los que se indican en la siguiente tabla y son independientes del método
MAC utilizado y de la tasa de datos. Pueden ser modificados por puerto cuando
sea necesario.

PARÁMETRO VALOR
(centisegundos)

JoinTime 20

LeaveTime 60

LeaveAllTime 100

GARP no depende críticamente de que se cumplan estos valores, pero

sí se asegura un correcto funcionamiento en el intercambio de GARP PDUs
entre máquinas del mismo segmento LAN. Para ello se debe cumplir:

1. JoinTime debe ser tal que al menos transcurran dos JoinTimes

mientras en la LAN se usa un LeaveTime, lo que asegura que
después de los mensajes Leave o LeaveAll las aplicaciones podrán
volver a unirse (Join) antes de que se cumpla su significado.

2. LeaveAllTime debe ser mayor que el valor de LeaveTime.

En la siguiente figura se muestra la duración de estas variables

temporales. Los valores A y B son diferencias de los otros valores y su
resultado debe ser positivo y nunca cero para asegurar un correcto
funcionamiento del protocolo.
 Figura 69: Relación entre las variables temporales de GARP

Veamos ahora un ejemplo de aplicación de este protocolo genérico para

el intercambio dinámico de información para tráfico multicast, esto es GMRP.

Volver arriba

6 GMRP

El Protocolo de registro Multicast GARP (GARP Multicast registration

protocol), también conocido como GMRP, es un mecanismo que permite a los
puentes y a las estaciones finales registrar/eliminar dinámicamente información
de miembros de grupos entre aquellos puentes que están conectados al mismo
segmento LAN, haciendo que esa información sea repartida entre todos esos
puentes (si estos permiten servicios de filtrado extendidos).

GMRP, igualmente, permite que los puentes envíen aquellas tramas que
van dirigidas a un determinado grupo solo a los miembros de ese grupo y que
cualquier puente por el que estas tramas pasen modifiquen su comportamiento
para lograrlo.

6.1 MODELO DE OPERACIÓN

GMRP define una “aplicación GARP” que va a proporcionar los servicios
de filtrado extendidos necesarios. Para lograrlo utiliza :

a) La forma en que se propaga y distribuye la información en el

protocolo GARP para declarar y propagar información de
miembros de grupos (GID : GARP information distribution y GIP:
GARP information propagation).
 b) La forma de registro para permitir controlar el comportamiento
de filtrado de tramas de los dispositivos que participan para
aquellas tramas destinadas a direcciones MAC de grupos.

En el caso de que aparezca información nueva en un puente

determinado esta será propagada utilizando GARP a lo largo de la red hacia el
resto de puentes que estén presentes, actualizándose las entradas de registro
de grupos en la base de datos de filtrado de los puentes y las estaciones
finales.

6.2 PROPAGACIÓN DE LA INFORMACIÓN CON GMRP

En el proceso de envío se usa la información almacenada en la entrada
de registro de grupos de la base de datos de filtrado para asegurarnos de que
las tramas solo son transmitidas a los segmentos LANs donde se encuentran
los miembros de ese grupo, tal y como se muestra en la figura siguiente para
un determinado grupo, denominado M:

Figura 70: propagación de la información con GMRP para un solo grupo

 De esta manera los puentes recibirán tramas desde todos los puertos y
las transmitirán solamente a través de los puertos para los que GMRP ha
creado entradas de registro de grupo.

Este tipo de funcionamiento va a permitir crear un subárbol del árbol de

expansión por cada grupo, como resultado de la creación de entradas de
registro de grupos en las bases de datos de filtrado de los puentes, de esta
forma las tramas multicast serán enviadas a través del grafo dirigido.

6.3 SOURCE PRUNING (recorte de fuente)

Las estaciones finales, al igual que los puentes, van a poder tener
conocimiento del conjunto de grupos existentes y de los miembros activos de
estos utilizando el protocolo GMRP. Esto es de gran utilidad, pues las
estaciones finales son las emisoras de tramas hacia los grupos, de forma que,
por ejemplo, pueden no enviar una trama si el grupo al que se quería enviar o
sus miembros no están activos.

Este tipo de comportamiento va a permitir la innecesaria inundación de

tráfico en segmentos LAN cuando los miembros de un grupo no estén activos
para recibirlo. Su implementación es opcional.

6.4 CODIFICACIÓN DE ATRIBUTOS GMRP

GMRP define dos tipos de atributos, el atributo de grupo y el de
requerimientos de servicio. El primero se utiliza para identificar valores de
direcciones MAC de grupo. Su valor (se lleva dentro de unidades de datos
“GARP PDUs”, dirección GMRP de valor 01-80-C2-00-00-20) debe de ser 1. De
la misma manera, para el segundo tipo su valor será 2.

La codificación para atributos de grupo está formada por seis octetos

( dirección MAC de 48 bits), mientras que para los requerimientos de servicio
se utiliza un simple octeto que permite definir dos valores :

6.1 Todos los grupos. Codificados con el valor 0

6.2 Todos los grupos no registrados. Codificados con 1.

 Para poner en práctica todo lo visto anteriormente, los puentes deben
ser puentes GMRP, es decir, deben permitir su funcionamiento, aunque este
protocolo también funciona (de forma transparente) con los puentes que utilizan
inundación para transmisión de tráfico multicast. De esta manera GMRP se
puede poner en práctica en cualquier red, permitiendo escalabilidad. Es,
además, un protocolo utilizado por la mayoría de los equipos de fabricantes de
dispositivos de red y si además permite controlar de forma eficiente el tráfico
multimedia se convierte en una tecnología importante en el presente y en el
futuro de la calidad de servicio.

Volver arriba

7 802.1Q

Un método más práctico para asignar la prioridad a los paquetes es por

un sistema final que asigna la prioridad dependiendo de la información del
usuario o de la aplicación (por ejemplo videoconferencia). El estándar definido
por la IEEE para el manejo de redes virtuales (VLANs) 802.1Q extiende la
capacidad del manejo de las prioridades en los puentes (nivel 2), utilizando
para ello un campo de prioridad dentro del encabezamiento del VLAN tag, es
decir, añade algunos bits dentro de cada paquete que identifican la VLAN a la
que pertenece el paquete y la prioridad del mismo. Este tag (marca o etiqueta)
es mostrado en la siguiente figura :
 Figura 71: Marca en el paquete según 802.1Q

Como se observa en la figura, se han añadido cuatro octetos a la trama

Ethernet aumentando la longitud máxima de la misma de 1518 a 1522 octetos.
En estos 4 octetos, 3 dígitos binarios van a permitir asignar hasta ocho niveles
de la prioridad (similares a IP Precedence) basándose en 802.1P y otros 12
dígitos binarios van a permitir identificar la VLAN de las 4.094 posibles
(802.1Q).

Además de en el nivel 2, los encaminadores y los conmutadores de

nivel 3 también pueden definir el campo de protocolo de las tramas 802.1Q
basados en la información de nivel 3, como la dirección IP destino, tipo de
tráfico (unicast, multicast, broadcast), o dependiendo de las capacidades del
conmutador de nivel 3, basados en la información de nivel 4, como el número
del puerto o socket de TCP, lo que va a permitir obtener un mayor rendimiento.

7.1 TIPOS DE VLAN

Los miembros de una VLAN pueden clasificarse por puerto, dirección
MAC y tipo de protocolo.

1) VLAN capa 1 : Miembros por puerto

Los miembros pueden ser definidos basándose en los puertos que

pertenecen a la VLAN. La siguiente tabla muestra un ejemplo, en el que los
puertos 1,2 y 4 pertenecen a una VLAN 1 y el 3 a una VLAN 2.
 Puerto VLAN

1 1

2 1

3 2

4 1

La principal desventaja de este método es que no permite la movilidad

de usuario. Si un usuario se mueve a una nueva localización lejos del puente
asignado el administrador de la red tendrá que reconfigurar la VLAN.

2) VLAN capa 2 : Miembros por

dirección MAC

Para configurar la VLAN se basa en la dirección MAC de las estaciones

de trabajo. El conmutador anota las direcciones MAC pertenecientes a cada
VLAN, tal y como muestra la siguiente tabla. Como la dirección MAC es
proporcionada por la tarjeta de red, si un puesto es movido, no es necesaria la
reconfiguración si este puesto se vuelve unir a la misma VLAN.

Dirección MAC VLAN

1212354145121 1

2389234873743 2

3045834758445 2

5483573475843 1
 El principal problema de este método es que los miembros deben
asignarse inicialmente. En redes formadas por miles de usuarios esta no es
una tarea fácil. Además en entornos donde se utilizan portátiles la dirección se
asocia a la estación donde éste se conecta. De esta forma, cuando un portátil
se conecta desde otro lugar la VLAN debe reconfigurarse.

3) VLAN capa 2 : Miembros por tipo de

protocolo

Para la capa 2 la VLAN también se puede basar en el campo tipo de

protocolo de la cabecera, por ejemplo para IP una VLAN distinta que para IPX.

4) VLAN capa 3 : Miembros por

dirección IP

Se basa en la cabecera de capa 3, utilizando la dirección de subred IP

para clasificar a los posible miembros de la VLAN. La siguiente tabla muestra
un ejemplo de formación :

IP Subnet VLAN

23.2.24 1

26.21.35 2

En este caso los usuarios pueden mover sus estaciones de trabajo sin
tener que reconfigurar su dirección de red. El único problema es que
generalmente se tarda más en enviar paquetes basándose en la información de
la capa 3 que usando direcciones MAC.

5) VLAN’s de capas superiores

Es posible definir también miembros de VLAN basándonos en

aplicaciones. Por ejemplo, podría aplicarse FTP en una red VLAN y TELNET
en otra.
 Hay que tener en cuenta que el estándar 802.1Q define tan solo redes
privadas virtuales de capas 1 y 2. No contempla las basadas en el tipo de
protocolo y en capas superiores.

7.2 TIPOS DE CONEXIONES

Los dispositivos de una VLAN pueden conectarse de tres maneras,

teniendo en cuenta que existen dispositivos que habilitan VLAN (que son
conscientes de esta) y otros que no la reconocen.

1) Conexión troncal

Todos los dispositivos conectados al tronco, incluidas las estaciones de

trabajo, deben ser VLAN-conscientes. En este caso, las tramas incluyen en su
cabecera una etiqueta que permite referenciar la VLAN.

Figura 72 : Conexión troncal entre dos puentes VLAN-conscientes.

2) Enlace de acceso

Este tipo conecta dispositivos que no habilitados para VLAN con el

puerto de un puente que sí la permite. Todas las tramas no están etiquetadas
implícitamente. Un ejemplo de dispositivo no habilitado para VLAN puede ser
un segmento LAN con estaciones de trabajo o dispositivos que no están
habilitados para redes virtuales. LA siguiente figura muestra este caso:
 Figure 73: Conexión de acceso entre un puente que permite VLAN y un
dispositivo que no la permite.

3) Conexión híbrida

Es una combinación entre las dos anteriores. En este caso las tramas
podrán estar etiquetadas o no.

Figura 74 : Conexión híbrida

7.3 PROCESADO DE TRAMAS

Un puente recibiendo datos determina a qué VLAN pertenece los datos

estén las tramas etiquetadas de forma implícita o explícita. En la explícita se
añade una cabecera de etiqueta a los datos. El puente además mantiene la
información de los miembros de la VLAN a través de una base de datos de
filtrado, necesaria para determinar dónde se van a enviar los datos.

A continuación se explica el contenido de la base de datos de filtrado y el

formato de la etiqueta en la cabecera.

1. Base de datos de filtrado

Al igual que pasaba en 802.1p, en VLAN se utiliza una base de datos

para almacenar información de los miembros de la VLAN. De la misma
manera, esta base está formada por varias entradas :

a) Entradas estáticas . Su información no se cambia de

manera automática. Existen dos tipos : entradas de filtrado
estáticas y entradas de registro estáticas. Las primeras
especifican para cada puerto que tramas son enviadas a una
 dirección MAC o VLAN específica y cuales deben ser
descartadas. El segundo tipo indica que tramas deben
etiquetarse o no y que puertos pertenecen a qué VLANs.

b) Entradas dinámicas : Se crean gracias al proceso de

aprendizaje del puente, éste observa el puerto desde el que se
recibe una trama con una determinada dirección fuente y un
identificador VLAN (VID) y actualiza su valor en la base de
datos. Existen tres tipos de entradas dinámicas: las entradas
de filtrado dinámicas, las entradas de registro de grupos y las
entradas de registro dinámicas. Para añadir y/o borrar
entradas en el segundo grupo se utiliza el protocolo GRMP,
permitiendo que el tráfico multicast sea enviado tan solo a una
VLAN particular. Para el tercer grupo se utiliza el protocolo
GARP VLAN (GVRP), anteriormente mencionado.

El protocolo GVRP no se utiliza únicamente para las entradas de registro

dinámicas, también se utiliza para intercambiar información entre puentes que
permiten VLAN.

Para enviar información al destino correcto todos los puentes deberían

contener la misma información en sus respectivas bases de datos de filtrado.
GVRP va a ser el protocolo que lo permita. Los puentes habilitados para VLAN
registrarán y propagarán los miembros hacia todos los puertos que sean parte
de la topología activa de la VLAN. Esta topología se determina en el momento
en que los puentes se conectan o cuando se percibe un cambio en el estado de
la topología actual. Para especificarla se utiliza el algoritmo del árbol en
expansión que evita la formación de lazos en la red al desactivar puertos. Una
vez que se tiene la topología de la red los puentes lo que harán será determinar
una topología activa para cada VLAN, de esta manera se obtendrá una
topología distinta para cada una de ellas o una común para todas. En cualquier
caso, la topología VLAN será un subconjunto de la topología activa de la red.
Para comprender mejor este funcionamiento ver la figura siguiente.
 Figura 75 :Topología activa de toda la red y de la VLAN A utilizando “árbol de
expansión”

2. Etiquetado

Cuando se envían las tramas a lo largo de la red es necesario indicar a

que VLAN pertenece la trama para que el puente envíe las tramas únicamente
a aquellos puertos que pertenezcan a la citada VLAN, en lugar de enviarla a
todos los puertos (inundación). Para conseguirlo se añade una etiqueta en la
cabecera, que permite especificar información de la prioridad de usuario e
indicar el formato de las direcciones MAC. Aquellas tramas donde es añadida
esta etiqueta se las conoce como “etiquetadas” y se envían a través de
conexiones troncales e híbridas.

En el etiquetado es necesario tener en cuenta el formato de las tramas.

Para el caso de 802.1Q sobre Ethernet, tal y como se indico al principio de esta
cláusula, nos encontramos con los siguientes campos :

Figura76 :Formato etiquetado

 Para identificar la VLAN a la que pertenece la trama existe el campo
VID, existiendo como máximo (212 - 1) posibles VLAN's .

Todas estas características mencionadas de forma genérica han de ser

tenidas en cuenta si queremos aplicar el estándar 802.1Q en nuestra red. Para
obtener una mayor información es necesario acudir a su borrador original
proporcionado por el Instituto de Ingenieros Eléctricos y Electrónicos (IEEE).

Volver arriba

8 Conclusión

A diferencia de ATM y FR, las redes de área local no garantizan la

mayoría de los parámetros necesarios para la obtención de QoS, pues no
fueron concebidas inicialmente para proporcionarla, por tanto ha sido necesario
la creación de algún protocolo que permita conseguirla trabajando con los
requirimientos de este tipo de redes. Así nos encontramos con el estándar
802.1p.

Esta norma va a permitir diferenciar entre 8 tipos de clases de tráfico

clasificados como “prioridades de usuario” (user_priority) por cada puerto del
puente, siendo el rango de valores de prioridad de usuario del 0 al 7. Para
conseguirlo se necesitan 3 bits, en los que será necesarios aumentar el formato
básico de las tecnologías de 802, tal y como Ethernet. Una vez determinadas
las clases de tráfico por puente, será necesario mapearlas (asociarlas) con el
tipo de tráfico que circule por la red para asegurar que el tráfico en tiempo real
(por ejemplo) sea atendido antes que otro tipo de tráfico considerado menos
importante.
Se trata por tanto de una técnica más de marcado de paquetes mediante
la clasificación de Clases de Servicio. Esta diferenciación de clases y el
almacenamiento de las tramas en las distintas colas del puerto van a ser
suficientes para proporcionar unos niveles de calidad de servicio adecuados,
aunque, a diferencia de las tecnologías anteriores, no se garantiza la QoS, ni
tan siquiera por contrato.
EJEMPLO PRACTICO:

En el presente capítulo se va a exponer la aplicación de QoS en una red real

de una empresa, semejante a la existente en la nuestra, lo que nos va a
permitir comprobar el verdadero alcance de la calidad de servicio, el tipo de
protocolos, herramientas y tecnologías para el ejemplo descrito, el coste de su
realización, así como un acercamiento a algunos de los equipos y programas
de monitorización puestos a la venta actualmente por los fabricantes.

1 Presentación del sistema

El ejemplo que se va a mostrar a continuación está sacado del

artículo “Special Report: Policy – Based Networking”, aparecido en el mes de
mayo de 1999 en la revista Data Communications y editado en su página
web. En el citado reportaje, además de hacer un estudio de la obtención de
calidad de servicio mediante políticas, se propone un ejercicio a las
empresas para que muestren cómo implementarían QoS en una
determinada red.

La propuesta es la siguiente:
“Acme Industrias está instalando un LAN en un nuevo edificio. El
edificio tiene cinco plantas. Cada planta soporta 100 usuarios. Cada grupo
de usuario está conectado a un armario de cableado (uno por planta) con
cable de cobre de categoría 5 UTP. A su vez, los distintos armarios de cada
piso están conectados entre sí a través de un cable de fibra. Por otra parte,
el armario del primer piso se encuentra en el centro de datos”.

Sobre esta propuesta se solicitan dos respuestas:

1 ) Bajo coste, Alta velocidad

“ La primera respuesta debería describir un red Ethernet conmutada,
de capa 2, alta capacidad y alta velocidad. Pudiéndose utilizar cualquier
combinación de tarjetas de 10,100 y 1000 Mbit/s, siendo la velocidad mínima
para las conexiones centrales (conmutadas) de 10 Mbit/s. Se pide, además,
que la red realice encaminamiento inteligente, utilizando equipos de nivel 3
solo en el centro de datos. Realizar el diseño consiguiendo intentando
conseguir la mejor combinación precio-velocidad”.
 2 ) Alta velocidad, Red basada en políticas
“ La segunda respuesta debe describir un red Ethernet conmutada (de
nivel 3) que soporte QoS y gestión de políticas. Se permite utilizar routers,
conmutadores y servidores de políticas donde sea necesario. Las tarjetas
pueden ser de 10, 100 y 1000 Mbit/s. La primera consideración en el diseño,
en este caso, debe ser conseguir una red de alto rendimiento que permita al
administrador de la red conseguir QoS usando políticas”.
A continuación se van a mostrar algunas de las soluciones aportadas
a ambas cuestiones, en las que poder comprobar las ventajas y desventajas
(en coste-velocidad) de aplicar QoS basada en políticas, así como su diseño
por parte de las empresas, aplicando todos los protocolos y mecanismos
explicados en capítulos anteriores del proyecto. Para tener conocimiento de
todas las respuestas realizadas acudir al citado artículo, a través de la
dirección :
http://www.data.com/issue/990507/policy_rfp.html
Volver arriba

2 Solución de CISCO

En las dos respuestas aportadas por Cisco se observa la similitud en

el diseño de la arquitectura de la red. La principal diferencia es la aplicación
de QoS, realizando clasificación en los armarios de cableado de cada planta,
vía IP ToS (tipo de servicio), proporcionando QoS extremo a extremo. Esta
QoS se obtiene gracias a la tarjeta NetFlow Feature Card II (NFFC II) en
cada conmutador Catalyst 5505. Este componente clasifica el tráfico IP de
acuerdo a una política de QoS. Así, por ejemplo, el tráfico en tiempo real,
como voz sobre IP (VoIP) puede ser clasificado con IP ToS. Después será el
nodo central (Catalyst 6506) el encargado de colocar todo el tráfico de
tiempo real en una cola de bajo retardo.

2.1 Solución 1: Red de bajo coste, alta velocidad

En la figura posterior se muestra la configuración de la red, en la que

tenemos:
 Los armarios de cada planta están formados por el equipo conmutador
Catalyst 5505, que proporciona conmutación 10/100 Ethernet a cada
equipo. El Supervisor Engine II (FSX) permite construir conexiones Gigabit
Ethernet con el nodo central (backbone).
Como nodo central se utiliza un equipo conmutador Catalyst 6506 Multi-
capa. Este equipo proporciona conmutación gigabit de capa 3.
El coste total para la solución asciende a $230,070 (unos 37 millones de
pesetas).

Figura 77. Solución de Cisco. Red bajo coste, alta velocidad.

El presupuesto refleja lo siguiente:

Figura 78. Presupuesto para la primera solución
2.2 Solución 2: Red de alta velocidad con QoS basada en políticas

En la figura posterior se muestra la configuración de la red, en la que

tenemos:
Los armarios de cada planta están formados por el equipo conmutador
Catalyst 5505, que proporciona clasificación IP a través del campo ToS.
Como nodos centrales se utilizan dos equipos conmutadores Catalyst
6056, que proporcionan QoS multicapa. Entre estos dos equipos funciona el
Hot Standby Router Protocol (HSRP), así en el caso de que se produjese un
fallo de conexión o de alimentación eléctrica, el tráfico procedente de los los
PCs y servidores será administrado por el otro conmutador (de backup). El
tiempo de recuperación puede ser menor de un segundo, lo que permite la
continuación de llamadas VoIP (sin interrumpirlas) en el caso de fallos en la
red. Además, en el caso de no existir fallos en la red, es posible utilizar
ambos equipos para repartir la carga y balancear el tráfico.
El coste total para esta solución es de $318,520 (sobre los 50 millones
de pesetas).

Se consiguen políticas de QoS usando información de las capas L2,

L3 y L4. Además, el campo IP ToS permite QoS extremo a extremo. El flujo
del tráfico es diferenciado por información de la L4, tal como el número de
puerto TCP. El ToS de la L3 es mapeado hacia la Ethernet (L2) mediante
encapsulación, con Inter. Switch Link (ISL) o el protocolo 802.1p.
La familia de conmutadores Catalyst 6000 incluyen múltiples colas
configurables mediante el algoritmo Weighted Round Robin (WRR) y
Weighted Random early Detection (WRED). Además, los Catalyst 5505
clasifican también el tráfico entrante a través del campo ToS.
Para proporcionar una buena calidad de voz (VoIP) se usan dos
utilidades de QoS.
a) El problema de la pérdida de paquetes es resuelto con el
algoritmo WRED, que permite evitar la congestión. Éste ante grandes
ráfagas de tráfico asegura que las colas nunca se llenen, permitiendo así
que el tráfico en tiempo real nunca deje de circular.
b) El problema del retardo es, a la vez, resuelto por el algoritmo
WRR, proporcionando distintas colas para el flujo en tiempo real, lo que
permite que los paquetes experimenten siempre muy poco retardo.
 La siguiente figura muestra la red implementada por Cisco para este
caso.

Figura 79. Solución de Cisco. Red basada en políticas, alta velocidad.

El presupuesto refleja lo siguiente:

Figura 80. Presupuesto para la primera solución
 Volver arriba

3 Solución de Lucent

Estudiemos ahora las propuestas de Lucent para las dos opciones

planteadas.

3.1 Solución 1 : red de bajo coste, alta velocidad

La solución de Lucent está compuesta por :

En los cuatro armarios de cableado (uno por piso) Lucent propone
conmutadores Cajun P550 de capa 2. Cada 7 slots están configurados
como un módulo supervisor, un módulo de 2 puertos para gigabit (conexión
con el centro de datos) y 5 de 20 puertos para la conexión de los diferentes
módulos Ethernet 10/100.
El centro de datos está configurado con un módulo supervisor de capa
3, un módulo de cuatro puertos Gigabit para proporcionar conexiones a los
distintos armarios de cada piso y 5 de 20 puertos 10/100 TX módulos
Ethernet para las conexiones, en cada piso, con las estaciones finales. Para
conseguirlo utiliza un Cajun P550 con encamina-miento integrado. Este
equipo proporciona una gran capacidad de encaminamiento, de hasta 1.5
millones de paquetes por segundo; encaminamiento vía hardware (IP/IPX);
clasificación de paquetes; prioridad de bit utilizando 802.1p y soporte de
“encaminamiento blando” para protocolos como AppleTalk.
El total de la implementación asciende a $180.375 (equivale a unos 28
millones de pesetas ).

Otros beneficios de esta solución son :

Tráfico de multidifusión usando VLANs: porque el módulo P550 soporta
etiquetado en, de esta manera es posible entregar tantas subredes como
sea necesario (utilizando una VLAN para cada subred).

Tecnología de malla abierta. Las opciones de etiquetado de VLANs

incluyen los estándares 802.1Q, la compatibilidad con Cisco, con 3Com y
con SUN.

Gestión basada en Web. Todo lo anterior puede ser controlado

mediante unas utilidades (software) basado en tecnología Web.
El presupuesto presentado es :

Figura 81. Presupuesto de Lucent

3.2 Solución 2: Red de alta velocidad con QoS basada en políticas

La solución de Lucent para la red basada en políticas incluye la

infraestructura y los servicios suficientes para entregar calidad extremo a
extremo y la administración de todos los recursos, aplicaciones y usuarios de
forma automática, de acuerdo a los objetivos explícitos de ACME Industrias.
El diseño de la red se basa en la utilización de conmutación a nivel 3
proporcionado por el equipo Cajun P550 que integra encaminamiento, en la
utilización del servidor de políticas de Lucent, en el software de
administración de direcciones IP denominado QIP v5.0, el programa
administrador del P550 y en el servidor de directorios de Novel (NDS) para el
almacenamiento de datos comunes para enlazar los distintos usuarios con
los recursos de la red.
La solución de Lucent incluye la utilización de DEN (Directory Enabled
Networks), que permite utilizar aplicaciones externas a la configuración de la
red, permitiéndolas compartir recursos y entrar a formar parte de políticas de
prioridad. Por tanto, Lucent permite enlazar aplicaciones, servicios de la red,
utilidades de gestión y dispositivos utilizando estándares existentes y
esquemas como LDAPv3 y DEN.
El software de monitorización QIP 5.0 permite, por lo tanto, la
identificación de usuarios, su clasificación utilizando reglas, visualización de
los recursos de la red y su reparto a los usuarios automáticamente.
La siguiente es la composición de la segunda repuesta:
Los cuatro armarios de cableado (uno por planta) están compuesto por
el equipo Cajun P550 que permiten encaminamiento. Cada conjunto de 7
slots están configurados como un módulo supervisor de capa 3, un módulo
de 2 puertos Gigabit Ethernet (para unirlos con el centro de datos) y 5
módulos de 20 puertos 10/100 TX Ethernet.
Esta configuración ofrece los requerimientos que la red de alta velocidad
necesita, alta velocidad de paquetes, mediante su clasificación por
control de acceso, y la QoS necesaria para conseguir una red basada en
políticas. Cada conmutador además contendrá de forma embebida un
cliente LDAPv3 para acceder al directorio NDS y una configuración
basada en el esquema DEN.
El centro de datos está configurado con un módulo supervisor de capa
3, un módulo de 4 puertos Gigabit (para la conexión con los distintos
armarios de capa piso) y 5 módulos de 20 puertos 10/100TX Ethernet para
las conexiones en cada piso con los PCs finales.
 Este encaminamiento se consigue utilizando el equipo Cajun P550 como
módulo supervisor en el centro de datos. Este módulo proporciona:
encaminamiento de alta capacidad de hasta 1.5 millones de paquetes
por segundo, encaminamiento basado en hardware (IP o IPX),
clasificación de paquetes, prioridad mediante 802.1p y soporte de
encaminamiento blando para protocolos como AppleTalk.
- El total del presupuesto asciende a $224,125 (unos 35 millones de
pesetas).

Figura 82. Red de respuesta.

El presupuesto presentado es :
Figura 83. Presupuesto para la segunda propuesta.
 Los servicios de gestión y de políticas son los siguientes:

1. QIP Enterprise 5.0 con gestión de

registro

El software QIP junto con DHCP y DDNS y las función de gestión de

registro permite al administración una fácil gestión de las direcciones IP,
incluyendo multitud de utilidades. Los servidores de DNS y DHCP
(Dynamic Host Configuration Protocol) pueden acceder y almacenar
información en un servicio de directorio. Existe la posibilidad, además,
de definir un directorio secundario, para que, en el caso de fallo, los
servicios no se vean interrumpidos. Además de estas utilidades, QIP
junto con el servidor de políticas, abajo definido, puede identificar a los
usuarios y sus necesidades, asignándoles recursos, niveles de QoS y
controlando su acceso.

El servicio de gestión del registro permite aumentar la seguridad de la

red. Será necesario que el usuario se identifique mediante un login y una
password antes de asignarle ninguna dirección IP y, por lo tanto, ningún
recurso ni nivel de QoS. Esto permite, además, la existencia de usuarios
móviles en la empresa, que podrán acceder desde cualquier lugar
obteniendo la misma gestión que si se encontrasen en su puesto físico
habitual de trabajo.

2. Enterprise Policy Server

Permite al administrador de la red su configuración, con una interfaz

sencilla (GUI) basada en web. De esta manera, el administrador puede
definir aplicaciones de red y asignarles parámetros de QoS en el
momento de su utilización por los usuarios. La información de los
usuarios y/o grupos de usuarios es uno de los servicios ofrecidos por
QIP 5.0, permitiendo que el administrador pueda configurar accesos
individualiza-dos y distintos niveles de QoS a aplicaciones específicas de
la red.

El Servidor de políticas convierte la información recibida desde la

configuración del GUI y la transforma en un esquema DEN que es
almacenado en el directorio NDS. Este almacenamiento es dinámico,
 estudiándose en cada momento el estado de la red ya almacenándolo.
Es posible, además, incluir segundos directorios de almacenamiento,
donde mantener una información redundante por si se produce algún
fallo.

3. P550 Device Manager

Este administrador proporciona al administrador las utilidades de

monitorización necesarias para visualizar el comportamiento de la red y
cómo están siendo implementadas las políticas a lo largo de ésta. Para
ello utiliza estándares como RMON y MIB II.

Volver arriba

4 Solución de Extreme

La solución aportada por Extreme contempla un solo diseño físico para

ambas preguntas, mostrando la forma de entregar todos los requerimientos que
necesita una aplicación crítica con una red simple y eficiente. La idea de
Extreme es proporcionar una red escalable y eficiente que soporte conectividad
de alta velocidad; proporcionar una óptima gestión basada en políticas, que
asegure la atención adecuada a aplicaciones críticas, y permitir a ACME
Industrias el crecimiento de su negocio, con una red que soporte nuevas
aplicaciones en el futuro, sin limitaciones.

El diseño físico de la red contempla los siguientes elementos:

En los armarios de cableado: un equipo Summit24 y dos Summit48

Enterprise Desktop Switches que proporcionan 120 conexiones Ethernet
10/100 Mbps que cumples con los requisitos de las 100 conexiones por
piso, permitiendo, incluso, más usuarios.

El Summit 48 dispone de 48 Ethernet de 10/100 Mbps y dos

(compartidos) para Gigabit Ethernet. Este equipo es capaz de
expedir 10.1 millones de paquetes de capa 2 y 3 por segundo.
 El Summit 24 dispone de 24 puertos Ethernet de 10/100 Mbps y un
puerto para Gigabit Ethernet. Para manejar el tráfico actual y futuro
este equipo es capaz de entregar 5.1 millones de paquetes de capa
2 y 3 por segundo.

El centro de datos está soportado por el equipo Black Diamond que

proporciona conectividad para los 20 puertos Gigabit Ethernet procedentes
de los distintos pisos. Este equipo entrega encamina-miento rápido y ancho
para las distintas subredes de cada uno de los cinco pisos. Es capaz de
expedir 48 millones de paquetes de capa 2 y 3 por segundo,
proporcionando 5 Gbps de capacidad Ethernet full-dúplex directamente
entre cada piso y el centro de datos. Con la carga citada en el enunciado
este equipo permite un crecimiento adicional de 12 puertos Gigabit Ethernet
no bloqueantes.

Figura 84. Red de respuesta.

4.1 Solución 1 : Red de bajo coste, alta velocidad

Este diseño entrega gran velocidad y simplicidad con un coste

adecuado. Los Summmit 48 y los Summit 24 Enterprise Desktop, situados
en los armarios de cableado de cada planta, entregan una velocidad de
10/100 Mbps a cada usuario. Por otra parte, el Black Diamond del centro de
datos proporciona encaminamiento IP de gran velocidad, sin bloqueos,
soportando las distintas subredes de los cinco pisos, utilizando para ello las
20 conexiones Gigabit Ethernet full-dúplex.
La administración de la red ACME se realiza de dos maneras. Por un
lado, cada conmutador de la red soporta administración basada en web a
través del conjunto de utilidades ExtremeWare Vista. Este software está
incluido en cada conmutador y permite la configuración de puertos,
aplicación de protocolos y calidad de servicio basada en políticas, así como
la realización de estadísticas de tráfico y, por lo tanto, toda la monitorización
del estado del conmutador.
Como consola central de administración de la red se proporciona el
ExtremeWare Enterprise Manager. Al igual que la aplicación anterior,
proporciona un interfaz web de fácil uso que soporta todos los aspectos
relacionados con la gestión de la red, incluida la administración de las VLAN,
la configuración de protocolos de encaminamiento, monitorización de los
recursos y del estado de la red y la realización de estadísticas del sistema.
Las características principales son :
Alto rendimiento, con capacidad para 156 millones de paquetes por
segundo.
Capacidad full-dúplex de 10 Gigabits en la conexión con cada planta.
Gran velocidad de encaminamiento IP entre subredes de los distintos
pisos.
64 Gigabit de capacidad full-dúplex en el centro de datos.
Coste total : $205,370 (alrededor de los 33 millones de pesetas)

La siguiente figura es el presupuesto para esta red:

 Figura 85. Primer presupuesto.

4.2 Solución 2: Red de alta velocidad con QoS basada en políticas

Esta red se eleva en potencia y velocidad sobre la solución anterior,

debido a la aplicación de políticas, soportadas en los conmutadores Summit
y BlackDiamond. Para este segundo diseño, además, los conmutadores
Summit, situados en los armarios de cableado de cada planta, soportan
servicios de capa 3 y 4 de alta velocidad.
Utilizando, además, el nuevo sistema de políticas, su configuración es
aún más sencilla y permite una mayor garantía para aplicaciones de misión
crítica. La combinación de unos equipos habilitados para la aplicación de
políticas y el servidor Enterprise Policy Server, que es parte de la plataforma
ExtremeWare Enterprise Manager, permite a la empresa ACME Industrias la
entrega de políticas sin necesidad de reconstruir la red original o realizar una
actualización de la misma. Permite, además, entregar QoS a los usuarios,
aplicaciones, voz sobre IP y aplicaciones de vídeo basadas en la capa 1
(puerto físico), a través de información de clasificación de la capa 4 (puerto
UTP/TCP).
El servidor de políticas, Enterprise Policy Server, para la entrega de
QoS utiliza tanto clasificación y encolamiento con prioridad, como control del
ancho de banda (por ejemplo: ancho de banda mínimo y máximo). Uno de
los protocolos utilizados para el encolamiento es el WFQ, que protege el
tráfico de las aplicaciones de misión crítica en la red.
Las características principales son :
Tanto sobre el usuario final como sobre las aplicaciones se aplican
políticas.
La consola de políticas está concebida para una fácil uso por el
administrador, incluyendo diversas utilidades.
Posibilidad de instalar una política de QoS extremo a extremo
independiente de las capas, desde los PCs de los usuarios al núcleo de la
red.
Servidor de políticas de QoS inteligente para la entrega de un amplio
número de políticas.
Capacidad de la red de 156 paquetes por segundo.
Capacidad de 10 Gigabits de conexión (full-dúplex) entre el centro de
datos y los distintos armarios de cada planta.
Gran velocidad de encaminamiento IP entre las subredes de los
distintos pisos.
Capacidad de 64 Gigabits (full-dúples) en el centro de datos.
Coste total: $265,370 (unos 43 millones de pesetas).

El presupuesto es el siguiente:
 Figura 86. Segundo presupuesto

CÓMO IMPLEMENTA EXTREME LA GESTIÓN DE POLÍTICAS

El sistema de políticas de Extreme combina el software ExtremeWare,

situado en los conmutadores, y la plataforma de gestión central ExtremeWare
Enterprise Manager. Dentro de este último se encuentra el servidor de políticas
(Enterprise Policy Server), que proporciona políticas de QoS a la red que son
fácilas de gestionar mediante una consola central o desde cualquier estación
de la red con un buscador web.

El sistema de políticas de Extreme (Extreme Networks Enterprise

Policy System) entrega:

Una forma de identificar los recursos de la red utilizados en funciones

críticas del negocio.

Utilidades de administración sencillas que facilitan la entrega de

políticas llevando un control del uso de los recursos de la red.

Una infraestructura de red que puede garantizar la entrega del tráfico.

Por otro lado, el servidor de políticas (Enterprise Policy

Server) soporta políticas que :
Protejan y den prioridad a las aplicaciones de misión crítica.

Políticas basadas en el usuario para asegurar ancho de banda.

Servicios de provisión de voz sobre IP.

Control de los tipos de tráfico (multidifusión).

El servidor de políticas proporciona:

Una consola basada en web
Servicios de protección a los usuarios y aplicaciones (seguridad).
Utilidades para facilitar la entrega de políticas complejas de calidad de
servicio.
 Mantenimiento y edición de las políticas existentes.
Resolución de conflictos de políticas (al alma-cenar estados anteriores).
Alcance de las políticas, definiendo dónde éstas han sido instaladas.
Implementación basada en estándares abiertos, con el protocolo COPS.
Configuración de políticas para múltiples fabri-cantes de equipos, como
Xedia y Cisco.

El sistema de políticas de empresa de Extreme contempla en

concepto de backbone virtual. Éste permite entregar servicios a aplicaciones
y a usuarios protegidas. Los servicios de aplicaciones protegidas permiten
asignar a cada aplicación una prioridad y una cantidad de ancho de banda.

Figura 87: Ejemplo de backbone Virtual.

Una de las principales características de la aplicación de políticas por

Extreme en ACME Industrias permite diseñar políticas independientemente
de la forma de funcionamiento de los conmutadores (conmutando o
encaminando), es, por tanto, independiente de la capa; de esta manera, el
diseño de la red no determina cómo se deben aplicar las políticas,
permitiendo, además, clasificar el tráfico de aplicaciones críticas utilizando
capacidades de clasificación de capa 1 a 4 en cualquier punto de la red.
Por otro lado, Extreme soporta el sistema de conexiones dinámico
(Dynamic Link Context System), que es una solución que permite administrar
y especificar políticas utilizando parámetros de alto nivel, como el usuario, la
máquina o nombres de aplicaciones. Es compatible con los protocolos
Windows Internet Naming Servicio (WINS) y el Dynamic Host Configuration
Protocol (DHCP), eliminando su instalación por separado y reduciendo la
complejidad, al permitir la no reestructuración de direcciones IP.
APLICACIÓN DE LA GESTIÓN DE POLÍTICAS DE EXTREME EN ACME
INDUSTRIAS

El sistema de políticas de empresa permite, en este caso:

Una consola de políticas de fácil uso y un servidor de políticas para la
creación y la administración de políticas.
Generación de políticas independientes de la capa de aplicación.
Servicios de aplicaciones protegidas utilizando la capacidad del
backbone virtual.
Entrega de políticas para redes con equipos de múltiples fabricantes
extremo a extremo.
Capacidades de administrador de direcciones dcon el sistema Dynamic
Link Context System.

CONCLUSIONES

Vamos a exponer a continuación las conclusiones obtenidas en el estudio de

calidad de servicio desarrollado, proponiendo finalmente posibles caminos
futuros a seguir sobre el mismo.

1 Conclusiones

Las fases en las que se ha dividido el proyecto han sido las siguientes:
 Recopilación de material bibliográfico: artículos de revistas, web,
monografías y normas oficiales.

Estudio y clasificación de los parámetros relacionados con la calidad de

servicio.

Estudio de los distintos protocolos y arquitecturas para la obtención de

QoS. Análisis de su funcionamiento.

Estudio de la obtención de QoS en diversas tecnologías de red.

Visualización de un ejemplo real de aplicación de diferentes técnicas

para la obtención de QoS.

Como vemos, para poder realizar un estudio sobre un tema tan complejo
y de tanta actualidad como es calidad de servicio en primer lugar ha sido
necesario realizar la recopilación de toda aquella información que nos permita
llevarlo a cabo, seleccionando entre toda ella al tratarse de un término que
engloba muchísima documentación. Ha sido a partir de ese momento cuando
ha comenzado el verdadero trabajo que nos ha permitido desarrollar el resto de
fases.

En la segunda fase, de estudio y clasificación de los parámetros

relacionados con QoS, correspondiente con el Capítulo 2, se ha realizado una
definición del término y la exposición de todos aquellos parámetros
relacionados con el mismo, lo que nos ha permitido comprender de una forma
aún global su significado.

Es evidente que para determinadas aplicaciones, como las de tiempo

real, valores bajos de retardo y de variabilidad en el mismo (jitter) asegurarán
un tiempo de llegada de los paquetes al usuario final adecuado, aumentando la
productividad del negocio, mientras que si estos valores resultan elevados no
se va a conseguir un nivel de calidad correcto para este tipo de
transacciones. Además, hay que tener en cuenta que por la red van a circular
simultáneamente distintos tipos de tráfico que necesitan llegar a su destino
para su uso y para ello se van a necesitar los diferentes recursos de la red, por
lo que, por lo general, la capacidad de la mayoría de los sistemas va a acabar
por agotarse. En ocasiones es posible ampliar esta capacidad, aumentando el
ancho de banda, sin embargo en otras es sumamente costoso o la tecnología
de red, sencillamente, no lo permite. Ante este hecho la actuación correcta es
el utilizar distintas herramientas y protocolos de calidad de servicio, entre las
que se encuentran una correcta gestión del ancho de banda y de los diferentes
recursos de la red, la necesidad de dar prioridad a distintos tipos de tráfico, la
señalización para la transmisión de información de clases de servicio, el uso de
algoritmos de encolamiento que permitan almacenar el tráfico antes de su
expedición, etc., que van a implicar la creación de políticas de QoS que
permitirán decidir qué aplicar y cómo conseguir QoS extremo a extremo, punto
a punto y de arriba abajo para nuestro sistema.

Estas políticas están basadas en el Acuerdo de Nivel de Servicio (SLA)

contratado entre un proveedor de servicios (tal como un ISP) y un cliente (por
ejemplo una empresa). En el mismo se van a definir los valores de rendimiento,
tasa de pérdidas, retrasos y variaciones en el intercambio de datos, en
consecuencia, qué nivel de calidad de servicio va a proporcional el proveedor al
cliente, así como las consecuencias cuando éste no se consigue y el precio de
todos estos servicios.

En el estudio de la calidad de servicio es necesario llevar a cabo un

control de congestión en la red, para ello se han propuesto diferentes
algoritmos, estudiados en el Capítulo 3.

Inicialmente se estudió el algoritmo FIFO (primero en entrar , primero en

salir) que es el algoritmo utilizado por defecto en la transmisión. Debido a que
no toma decisiones sobre la prioridad de los paquetes, el tráfico multimedia va
a ser tratado de la misma forma que el tráfico de datos tradicionales, lo que no
proporciona ningún nivel de calidad. En consecuencia será necesario utilizar
otros algoritmos más sofisticados para las redes inteligentes actuales.

Así, cuando necesitemos dar el mayor nivel de prioridad al tráfico que

consideremos más importante según el protocolo de red utilizado, el algoritmo
más adecuado será PQ (Priority Queuing) que dispone de cuatro colas
teniendo asignada cada una de ellas una prioridad de mayor a menor.

CQ (Custom Queuing) por su parte tiene la ventaja de que permite

garantizar la asignación de un ancho de banda en aquellos puntos donde se
produce la congestión, dejando el resto para cualquier otro tipo de tráfico. Sin
embargo, y pese a la mejora, estos dos últimos algoritmos utilizan una
configuración estática y no se adaptan a los requisitos cambiantes de las redes,
de ahí la utilización de WFQ ( Weighted fair queuing). Este es el más
adecuado para situaciones en las que se necesita proporcionar un tiempo de
respuesta consistente a cualquier tipo de usuarios sin necesidad de aumentar
de forma excesiva el ancho de banda, asegurándose siempre la existencia del
mismo, proporcionando así un servicio predecible. De esta manera, el tráfico
interactivo será situado al principio de la cola, reduciendo así el tiempo de
respuesta y pudiendo compartir después el resto de ancho de banda entre
flujos de tráfico de baja prioridad.

Dentro de los protocolos de calidad de servicio existentes nos

encontramos con el protocolo de reserva de recursos o RSVP que permite a las
aplicaciones solicitar una calidad de servicio específica a la red lo que va a
garantizar un nivel de QoS para las mismos. Esto le convierte actualmente en
el protocolo que proporciona un mayor nivel de calidad de servicio,
implementándose el control tanto en las aplicaciones como en la misma red.
Sin embargo, para conseguirlo, es necesario utilizar técnicas de señalización
que conllevan decisiones de encaminamiento y que cargarán aún más la red,
término a tener en cuenta, sobre todo cuando este protocolo se aplique sobre
IP. Además, la dificultad en la escalabilidad y el hecho de no poder trabajar
sobre redes no RSVP, han provocado la aparición de otras alternativas.

Así nos encontramos con MPLS (Multi Protocol Label Switching o

conmutación de etiquetas multiprocolo). Este es un protocolo que va a
proporcionar la posibilidad de administrar el ancho de banda de la red mediante
el uso de etiquetas en las cabecera de los paquetes en lugar de señalización y
a través de encaminadores específicos que sean capaces de reconocerlas, lo
que constituye una gran inconveniencia. Sin embargo, esta técnica proporciona
varias ventajas, tales como la reducción de los gastos indirectos de
encaminamiento en los routers IP mejorando el funcionamiento de la
expedición de paquete, basando sus decisiones de encaminamiento en algo
más inteligente que mediante la técnica del camino más corto.

Por otra parte, MPLS va a permitir a los proveedores de servicio de

Internet escalar de forma adecuada sus redes sin tener que recurrir al modo de
transferencia asíncrono (ATM). Además, es una técnica que permite integrar
las redes ATM e IP, característica muy importante para la tendencia actual de
convergencia de redes.

Otro mecanismo que utiliza etiquetas para la obtención de

QoS es Diffserv (Servicios Diferenciados), utilizado en IP. Mediante el
marcado de paquetes se va a conseguir que los routers modifiquen su
comportamiento de envío, teniendo en cuenta que cada etiqueta representará
un determinado tipo de QoS. Requiere, por lo tanto, el tratamiento de la
cabecera de los paquetes soportándose el servicio Premium para aplicaciones
que requieran un nivel de retardo y de jitter bajo, el servicio Asegurado que
asigna un nivel determinado de ancho de banda para el cliente y, por último, el
servicio de Mejor Esfuerzo (Best effort) que es un servicio sin ningún tipo de
garantías.

La existencia de los diferentes tipos de protocolos no es por separado,

es decir, no se excluyen unos a otros, si bien, para la obtención de los niveles
de calidad requeridos en una determinada red va a ser necesaria su
complementación (esto es evidente debido a la convergencia de redes). Esas
combinaciones van a dar lugar a una gran variedad de arquitecturas, estando
presente para cada una de ellas la obtención de calidad de servicio extremo a
extremo.

En este proyecto, además, se ha analizado con detalle cómo es posible

conseguir QoS y las herramientas utilizadas para ello en tres de las tecnologías
más utilizadas en la actualidad : ATM, Frame Relay y Red Local IEEE 802.
Cada una de ellas ha sido tratada en los capítulos 6, 7 y 8, respectivamente,
correspondiendo, a su vez, con la fase cuarta de este trabajo fin de carrera.

En primer lugar, cabe destacar el modo de transferencia asíncrono. ATM

es una tecnología que soporta con altos niveles de garantía la tendencia actual
de generación de tráfico multimedia, pues ha sido concebida desde su
nacimiento como una tecnología capaz de proporcionar altos niveles de calidad
de servicio, a diferencia, por ejemplo, de las redes IP y las 802, que tienen que
ser adaptadas (hay que buscar la manera) para poder proporcionar un nivel
aceptable de calidad. Esto, evidentemente es una gran ventaja con respecto al
resto de tecnologías.

Uno de los principales beneficios de las redes ATM es que pueden

proveer a los usuarios con una Calidad de Servicio (QoS)
garantizada, informando el usuario a la red, durante el establecimiento de la
conexión, de la clase de tráfico esperada que será transmitido en la conexión y
del tipo de calidad de servicio que la conexión requiere. Esto se logra mediante
el uso de descriptores del tráfico y categorías de servicio, designándose estas
últimas designada para un grupo particular de aplicaciones (todos hemos oído
hablar de Constant Bit Rate (CBR) o de Available Bit Rate (ABR), entre otras ).

Además de estas características ATM incluye en su concepción diversos

mecanismos de control o herramientas, análogas a las descritas anteriormente
que permiten gestionar su funcionamiento para la obtención de calidad de
servicio.

Teniendo en cuenta todas las eficaces ventajas descritas para ATM es

necesario destacar que el principal inconveniente en escoger esta tecnología
como la más adecuada para nuestra red es su elevado coste. Si bien, si su
empresa lo puede permitir, no dude en implantarla.

Por otro lado nos encontramos con Frame Relay. Esta no es una
tecnología protocolo especialmente diseñada para soportar tráfico multimedia,
audio y vídeo en tiempo real. No hay garantías sobre el retardo de tránsito,
pero en la práctica las redes suelen estar bien dimensionadas y el retardo de
tránsito es pequeño y no varía apreciablemente.

En cuanto a QoS en FR, el cliente va a tener garantizadas las

prestaciones que obtendrá de la red, siempre por contrato, pudiendo contratar
un nivel de calidad de servicio distinto para cada conexión, lo que la convierte
en una posibilidad tan buena como ATM y más barata.

Mediante la asignación de valores para el caudal medio garantizado

(CIR : Commited Information Rate), el intervalo de observación (Tc: Commited
rate measurement interval) y el caudal físico de la línea de acceso (C), será
posible controlar, para cada circuito virtual, que los usuarios se ajusten a
transmitir el volumen de información comprometida y en exceso (Bc :
Commited Burst Size y Be, respectivamente), lo que permitirá el no perder
datos que no superen el tráfico comprometido. Por otra lado también existe la
posibilidad de marcar tramas para indicar la importancia de unas respecto a
otras, a través de la activación del bit DE existente en la trama Frame Relay.

Todas estas características, así como su elevado rendimiento y

velocidad convierten Frame Relay en otra posibilidad de tecnología de red a
implementar para la obtención de unos niveles apropiados de calidad de
servicio. Si bien, sigue siendo inferior a la tecnología en ATM y soporta peor el
tráfico multimedia que esta, pero para su implantación se requiere de un menor
coste económico.

A diferencia de ATM y FR, las redes de área local no garantizan la

mayoría de los parámetros necesarios para la obtención de QoS, pues no
fueron concebidas inicialmente para proporcionarla, así pues ha sido necesario
la creación de algún protocolo que permita conseguirla trabajando con los
requirimientos de este tipo de redes. Así nos encontramos con el estándar
802.1p, integrado dentro de la norma 802.1D, que va a permitirnos asignar
prioridades al tráfico y filtrar el tráfico Multicast (grupos) de forma dinámica, lo
que va a permitir que el tráfico dirigido a un determinado grupo sea enviado
solamente a determinados segmentos de la red LAN para que llegue tan solo a
los miembros de ese grupo, evitando así el costoso proceso de transmisión al
utilizar el algoritmo de inundación, tan conocido.

Esta norma, tal y como se estudió en el capítulo 8, va a permitir

diferenciar entre 8 tipos de clases de tráfico clasificados como “prioridades de
usuario” (user_priority) por cada puerto del puente, siendo el rango de valores
de prioridad de usuario del 0 al 7. Para conseguirlo se necesitan 3 bits, en los
que será necesarios aumentar el formato básico de las tecnologías de 802, tal
y como Ethernet. Una vez determinadas las clases de tráfico por puente, será
necesario mapearlas (asociarlas) con el tipo de tráfico que circule por la red
para asegurar que el tráfico en tiempo real (por ejemplo) sea atendido antes
que otro tipo de tráfico considerado menos importante.
Se trata por tanto de una técnica más de marcado de paquetes mediante
la clasificación de Clases de Servicio. Esta diferenciación de clases y el
almacenamiento de las tramas en las distintas colas del puerto van a ser
suficientes para proporcionar unos niveles de calidad de servicio adecuados,
aunque, a diferencia de las tecnologías anteriores, no se garantiza la QoS, ni
tan siquiera por contrato.
En último lugar y correspondiendo a la última fase del proyecto nos
encontramos con el capítulo 9 en el que es posible visualizar un ejemplo real
de aplicación de algunas de las diferentes técnicas para la obtención de QoS
mencionadas a lo largo de esta conclusión, comprendiendo así la importancia
de la gestión de políticas entre los vendedores y la necesidad de aplicación de
algunas tecnologías y herramientas frente a otras según las especificaciones
de la red ejemplo, extendiendo esto para los sistemas con los nos encontremos
cada uno de nosotros.
Volver arriba
2 Trabajo futuro

El estudio de la calidad de servicio es un trabajo que engloba, como

hemos visto, multitud de parámetros, ya sean herramientas, protocolos,
arquitecturas y/o técnicas de QoS en diferentes tecnologías de red y al que se
le está otorgando cada vez más importancia, sobre todo durante los dos
últimos años, por lo que, evidentemente, el primer camino a realizar en el futuro
es el seguimiento de todas y cada una de las técnicas nuevas que están siendo
desarrolladas e implementadas por las empresas y por los organismos de
estandarización, así como su compatibilidad y sus ventajas, si estas existen,
sobre las estudiadas a lo largo de este proyecto. Se trataría pues de realizar un
seguimiento de los avances en calidad de servicio para lo que se recomienda
estar en contacto con cada uno de los foros existentes al respecto,
consultándolos a través de sus páginas web, referenciadas en el apartado de
Bibliografía.

Un camino distinto al anterior y orientado a la implementación práctica,

consistiría en la realización de algoritmos, simuladores y aplicaciones de
pruebas para algunos de los protocolos estudiados en el Capítulo 5, así como
para las herramientas descritas en el Capítulo 3. En este último caso se
podría implementar un algoritmo que proporcionase eficiencia del enlace, tal
como RTP (Real-Time Transport Protocol), o alguno de los que realizan un
control de congestión, como PQ (Priority Queuing), o los que permiten prevenir
congestión, como RED (Random Early Detection), en definitiva cualquiera de
los detallados en el citado capítulo.

En el caso del Capítulo 5 sería de gran utilidad realizar un código que

permitiese comprobar el funcionamiento y el intercambio de mensajes en una
técnica de señalización como es el Protocolo de Reserva de Recursos o RSVP,
que es uno de los más extendidos, de manera análoga a la experiencia que se
explica en el citado subapartado del capítulo.

En último lugar, para el estudio de la norma 802.1p sería interesante

comprobar el funcionamiento del protocolo de registro Multicast GARP o
GMRP, analizando cómo se registra/elimina dinámicamente información de
miembros de grupos entre aquellos puentes que están conectados al mismo
segmento LAN y observando cómo realmente aquellas tramas que van
dirigidas a un determinado grupo son recibidas solo por los miembros de ese
grupo. Este desarrollo podría realizarse en lenguaje C, alentando desde aquí a
su realización como complemento práctico del Capítulo 8 de este proyecto.