Simulador de Tráfico ATM con Garantía de Servicio

Simulador de Tráfico ATM con Garantía de Servicio
SIMULADOR DE TRÁFICO ATM
CON GARANTÍA DE SERVICIO
I. PRELIMINARES.......................................................................................................................................3
1. INTRODUCCIÓN .............................................................................................................................................3
1.1. Antecedentes de la simulación...........................................................................................................4
2. ASPECTOS GENERALES DE ATM....................................................................................................................5
2.1. Conmutación de paquetes a alta velocidad.......................................................................................5
2.2. Arquitectura de un nodo ATM...........................................................................................................6
2.2.1. Modelo de referencia ATM........................................................................................................7
2.2.2. Categorías de Servicio ATM......................................................................................................9
2.2.3. Parámetros de la Calidad de Servicio.......................................................................................10
2.2.4. Control de Congestión .............................................................................................................11
2.2.5. Redes ATM...............................................................................................................................11
3. MOTIVACIONES..........................................................................................................................................13
3.1. Fiabilidad.......................................................................................................................................13
3.2. Garantía de servicio........................................................................................................................15
3.3. Funcionamiento de TCP..................................................................................................................15
3.3.1. Funcionamiento de TCP...........................................................................................................16
3.3.2. TCP sobre ATM........................................................................................................................17
3.4. Beneficios aportados por TAP........................................................................................................18
3.5. Limitaciones de ATM frente a la GoS............................................................................................19
II. LA PROPUESTA TAP..........................................................................................................................20
4. INTRODUCCIÓN...........................................................................................................................................20
4.1. Conceptos fundamentales sobre agentes.........................................................................................20
4.2. Sistemas multiagentes (SMA).........................................................................................................21
5. ARQUITECTURA TAP.................................................................................................................................22
5.1. El SMA-TAP...................................................................................................................................22
5.2. Arquitectura del SMA-TAP..............................................................................................................23
5.3. Conmutadores AcTMs...................................................................................................................25
5.3.1. Colas de entrada........................................................................................................................25
6. GESTIÓN JUSTA DE COLAS............................................................................................................................29
6.1. Fair Queuing..................................................................................................................................30
6.2. GPS, PGPS (WFQ) y PFQ..............................................................................................................31
6.3. Propuesta QPWFQ para TAP.........................................................................................................34
6.3.1. QLWFQ....................................................................................................................................34
6.3.2. QPWFQ....................................................................................................................................34
7. MECANISMOS DE CONTROL DE CONGESTIÓN....................................................................................................37
7.1. Antecedentes, mecanismo EPD .....................................................................................................37
7.2. Propuesta EPDR.............................................................................................................................39
BASES DE LA SIMULACIÓN.................................................................................................................42
8. INTRODUCCIÓN...........................................................................................................................................42
1
Simulador de Tráfico ATM con Garantía de Servicio
9. FUNCIONES Y ALGORITMOS DE GESTIÓN DE CONEXIONES...................................................................................42
9.1. Funciones y algoritmos de gestión de conexiones en las redes ATM reales...................................42
9.1.1. Señalización..............................................................................................................................42
9.1.2. Direccionamiento.....................................................................................................................45
9.1.3. Enrutamiento............................................................................................................................45
9.1.4. CAC “Connection Admission Control”....................................................................................48
9.1.5. Tablas de enrutamiento de VCCs.............................................................................................49
9.2. Funciones y algoritmos de gestión de conexiones de “simSwitch”................................................50
9.2.1. Señalización en la simulación...................................................................................................50
9.2.2. Direccionamiento en la simulación..........................................................................................61
9.2.3. Enrutamiento en la simulación.................................................................................................61
9.2.4. El algoritmo CAC en la simulación.........................................................................................63
9.2.5. Tablas de enrutamiento de VCCs en la simulación.................................................................64
10. FUNCIONES Y PROCEDIMIENTOS PARA LA GESTIÓN DEL TRÁFICO........................................................................68
10.1. Introducción.................................................................................................................................68
10.2. Connection Admisión Control.......................................................................................................69
10.3. Usage Parameter Control.............................................................................................................69
10.4. Selective Cell Discard...................................................................................................................70
10.5. Traffic Shaping..............................................................................................................................70
10.6. Explicit Forward Congestion Indication.......................................................................................70
10.7. Resource Management using Virtual Paths..................................................................................71
10.8. Frame Discard..............................................................................................................................71
10.9. Generic Flow Control...................................................................................................................72
10.10. ABR Flow Control.......................................................................................................................72
11. CATEGORÍAS DE SERVICIO IMPLEMENTADAS...................................................................................................72
11.1. Las categorías de servicio ABR y UBR........................................................................................73
11.2. ABR-l............................................................................................................................................73
11.2.1. Modelo de servicio detallado para ABR-l.............................................................................73
11.2.2. Modelo de control de flujo para ABR-l..................................................................................74
11.2.3. Parámetros de servicio ABR-l................................................................................................75
11.2.4. Estructura de las células RM..................................................................................................75
11.2.5. Comportamiento de la fuente.................................................................................................76
11.2.6. Comportamiento del sumidero...............................................................................................77
11.2.7. Comportamiento de los conmutadores..................................................................................77
11.2.8. Algoritmos en pseudocódigo.................................................................................................77
11.3. UBR-l.............................................................................................................................................78
SIMULACIONES.......................................................................................................................................79
12. SIMULACIONES.........................................................................................................................................79
12.1. La Topología Base.........................................................................................................................80
12.2. Comportamiento del tráfico de tramas con relación al umbral....................................................82
12.3. Influencia del EPDR en la fragmentación.....................................................................................88
12.4. Influencia del tamaño del búfer del conmutador congestionado..................................................91
12.5. Influencia del grado de GoS de las conexiones privilegiadas......................................................92
12.6. Influencia del tamaño de la memoria DMTE................................................................................97
12.7. Influencia de la velocidad de salida de las fuentes EAAL ............................................................98
13. Conclusiones..................................................................................................................................101
13.1. Trabajos futuros..........................................................................................................................101
BIBLIOGRAFÍA......................................................................................................................................103
2
Simulador de Tráfico ATM con Garantía de Servicio
I.PRELIMINARES
1. Introducción
El proyecto “Simulador de tráfico ATM con GoS” tiene como objetivo fundamental la
creación de una herramienta multiplataforma específica y dedicada a comprobar las
consecuencias e implicaciones de implantar la arquitectura TAP (Trusted and Active Protocol
PDU transfer) en una red de tecnología ATM. Esta arquitectura aparece propuesta por D. José
Luis González Sánchez en detalle en su tesis doctoral “Protocolo activo para transmisiones
garantizadas sobre una arquitectura distribuida y multiagente en redes ATM”. Actualmente, tal y
como se plantea la realización de este simulador, no conocemos una alternativa equivalente a la
recogida en este proyecto ya que, aunque en la propia tesis se propone un simulador, el
“SSAcTM”, partiendo desde cero, intenta ir más allá permitiendo el diseño de topologías
diferentes y aumentando el nivel de realismo de simulación de tráfico en la medida de nuestras
capacidades.
La arquitectura TAP es novedosa por sus características: distribuida, activa y multiagente. El protocolo creado para la arquitectura ofrece transferencias garantizadas a un conjunto
de privilegiado de conexiones VPI/VCI. Se propone también una extensión de la capa AAL-5 de
ATM denominada EAAL-5 (Extended AAL type 5) usadas para la gestión de conexiones
privilegiadas extremo-extremo. TAP ofrece garantía de servicio (GoS) cuando la red está
perdiendo células pertenecientes a las conexiones privilegiadas y aprovecha los períodos de
inactividad de los enlaces para hacer retransmisiones de las CPCS-PDU-EAAL-5 mediante el uso
de mecanismos NACK. TAP es soportado por conmutadores ATM activos (denominados AcTM)
que presentan una arquitectura diseñada específicamente para estos propósitos. Además, mediante
técnicas software, intenta disminuir de forma justa la carga de los conmutadores; optimizar las
retransmisiones de PDU; aliviar la implosión sobre las fuentes; evitar la fragmentación de las
PDU y disminuir el interleaving de células, optimizando el goodput.
El software de simulación de tráfico ATM con GoS que hemos desarrollado está formado
por cuatro aplicaciones independientes pero relacionadas. Cada una de ellas dispone de un
interfaz gráfico potente para permitir un entorno amigable de usuario. La programación de cada
uno de los módulos que componen este programa está realizado en Java y la ejecución de los
procesos requeridos puede realizarse de forma centralizada en PC’s mono y multiprocesador
gracias a su implementación multi-hilo. El simulador dispone de tres niveles de operación: el
primero trata del diseño y análisis del comportamiento de los distintos dispositivos ATM (nivel
de dispositivo), el segundo considera la construcción de una red ATM con conmutadores AcTM
integrados (nivel de red), y el tercero se encarga de evaluar cualitativa y cuantitativamente el
grado de servicio ofrecido por la red bajo estudio de extremo a extremo (nivel de usuario o
servicio).
3
Simulador de Tráfico ATM con Garantía de Servicio
1.1. Antecedentes de la simulación
Existe una tentación subyacente al proponer un nuevo simulador, que sería la de reformar
o ampliar algunos de los ya existentes. Los paquetes de simulación que actualmente se usan y que
se conocen ampliamente surgieron hace algún tiempo como herramientas de simulación de las
redes ya existentes (Ethernet, Token-ring, FDDI, interconexión a través de redes WAN,...) Como
ejemplo de éstos, se pueden citar el BONes DESIGNER, NS, GPSS/H, MODSIM,
SES/Workbench, SIMAN, SIMSCRIPT, SLAMSYSTEM y OPNET. De todos ellos, sólo BONes
DESIGNER, SES/Workbench y OPNET tienen módulos de comunicaciones y este último,
dispone de un pequeño módulo de ATM completamente diferente a lo que se pretende hacer en
este proyecto. Por tanto, no están pensados para la simulación de arquitecturas de conmutación
como las que aquí se van a simular, con lo que si se quisiera reutilizar alguno de ellos al menos
surgirían dos graves problemas. En primer lugar, su reconstrucción para la utilización en entornos
ATM se prevé muy costosa y puede consumir demasiado tiempo. En segundo lugar, el tiempo
necesario para la simulación de cualquier red sería excesivamente alto, haciendo altamente
ineficaz su uso. Es pues necesario desarrollar un simulador específico para nuestro entorno y huir
en lo posible de simuladores de propósito general.
4
Simulador de Tráfico ATM con Garantía de Servicio
2. Aspectos generales de ATM
El Modo de Transferencia Asíncrono (ATM) es la base de un estándar internacional
propuesto como un sistema de conmutación de paquetes para el transporte de datos basado en
células de longitud fija y de pequeño tamaño (53 octetos). ATM se caracteriza también por
ofrecer funciones de gestión de tráfico para la transferencia óptima de información en tiempo real
(tráfico multimedia) y tiempo no-real (datos o imágenes estáticas), aportando la atractiva ventaja
de diferentes flujos de información. Ha sido elegida por la ITU-T como base para la
implementación de la RDSI-BA (Red Digital de Servicios Integrados de Banda Ancha) Sin
embargo, debido a que ATM se trata de una tecnología muy novedosa y aún en proceso de
implantación, a pesar de que muchos aspectos de la misma están resueltos, aún quedan muchos
otros que son foco de atención de la comunidad investigadora que realiza propuestas para mejorar
la tecnología. La arquitectura TAP es un ejemplo de ello.
Debido a que aspiramos a movernos dentro del ámbito de las arquitecturas, protocolos,
tráfico nativo ATM, etc., en el presente capítulo realizaremos una descripción de los aspectos
básicos de la tecnología ATM. Esto ayudará al lector a familiarizarse con el entorno en el que se
desarrollará nuestro simulador así como para situarse en un punto donde podamos presentarle
más claramente la problemática que conlleva ofrecer garantía de servicio en conexiones extremoextremo, aspecto base de la tecnología TAP.
2.1. Conmutación de paquetes a alta
velocidad
Como ya hemos apuntado antes, ATM es la tecnología subyacente que hace posible la
RDSI-BA como red integrada para todos los tipos de transferencia de información que se preveía
que reemplazase en el futuro a todo el sistema telefónico y a todas las redes especializadas. Esta
nueva red tendrá una velocidad de transmisión muy elevada, en comparación con todos los
servicios y redes existentes, y hará posible ofrecer una gran variedad de servicios nuevos. Las
nuevas necesidades de la RDSI-BA orientaron las comunicaciones hacia la conmutación de
paquetes en alta velocidad para contar simultáneamente con las ventajas de las redes de circuitos
y las redes de paquetes. Esta nueva tecnología debería ser capaz de proporcionar anchos de banda
variables, ser transparente a los protocolos utilizados y soportar una gama amplia de servicios con
soluciones específicas de velocidad, sincronización y latencia.
La idea en la que se basa ATM consiste en transmitir toda la información en paquetes
pequeños de tamaño fijo, llamados células o celdas (Cells). El uso de una tecnología de
conmutación de células es una ruptura drástica con respecto a la conmutación de circuitos dentro
de un sistema telefónico. Son muchas las razones por las que se escogió la conmutación de
células, entre ellas están las siguientes. Primero, la conmutación de células es altamente flexible y
puede manejar con facilidad tanto tráfico de velocidad constante como variable. Segundo, a las
velocidades tan altas que se contemplan, la conmutación digital de las células es más fácil que el
empleo de las técnicas tradicionales de multiplexación, en especial si se utiliza fibra óptica.
Tercero, tan solo la conmutación de células, no la de circuitos, puede proporcionar la difusión,
5
Simulador de Tráfico ATM con Garantía de Servicio
esencial para diversos servicios como por ejemplo la distribución de televisión. En resumen, las
ventajas obtenidas con la conmutación de celdas son una baja latencia que permite soportar datos
isócronos y una eficiente conmutación hardware gracias al tamaño constante de los paquetes.
2.2. Arquitectura de un nodo ATM
ATM puede considerarse como una tecnología de conmutación de paquetes de alta
velocidad con unas características particulares:
- Los paquetes son pequeños y de tamaño constante.
- Es una tecnología de naturaleza conmutada y orientada a conexión.
- Los nodos que componen una red no tienen mecanismos para el control de errores o
control de flujo.
- La cabecera de las células tiene una funcionalidad limitada.
Simplificando al máximo podemos ver que una red ATM está compuesta por nodos de
conmutación, elementos de transmisión y equipos terminales de usuarios. Los nodos son capaces
de encaminar la información empaquetada en células a través de unos caminos conocidos como
Conexiones de Canal Virtual. El encaminamiento, en los nodos conmutadores de células, es un
proceso
hardware,
mientras
que
el
establecimiento
de
conexiones
y
el
empaquetamiento/desempaquetamiento de las células son procesos software.
Figura 2.1 Esquema de comunicación con ATM
Las células constituyen la unidad de transferencia en las redes ATM que, como hemos
dicho antes son de tamaño fijo y relativamente pequeñas. De los 53 octetos totales, 5 bytes se
emplean en las cabeceras y los 48 restantes se emplean para la carga útil de datos. En la figura 1.2
se puede observar los dos formatos de células ATM con sus correspondientes campos y tamaños.
6
Simulador de Tráfico ATM con Garantía de Servicio
El hecho de que haya dos formatos distintos se debe a que uno es usado en el interfaz entre el
usuario y la red (UNI) y el otro es el que utilizan los conmutadores de la red entre si (NNI).
Figura 2.2 Formato de células ATM
Cada célula presenta un campo VPI y otro VCI. El conjunto de ambos especifica a un
Canal Virtual (VC) que es una representación de una conexión unidireccional entre dos usuarios.
El primero identifica la Ruta Virtual (Virtual Path) y el segundo un Canal Virtual (Virtual
Channel) específico dentro de cada VP. El campo PT (Payload Type) se usa para indicar el tipo
de información contenida en el campo de carga de datos de la célula. El bit CLP (Cell Loss
Priority) lo emplea el emisor para especificar la prioridad deseada de descarte de células en el
caso de congestión en la red. Un CLP=1 indica que la célula es de baja prioridad y por lo tanto
descartable. El campo HEC (Header Error Control) es un código de redundancia cíclico usado
para detectar errores en la cabecera. A continuación de la cabecera vienen 48 bytes de carga útil.
Sin embargo, y como veremos en el módulo II no todos los 48 bytes están disponibles para el
usuario, pues algunos de los protocolos AAL ponen sus cabeceras y sus terminaciones dentro de
la carga.
2.2.1. Modelo de referencia ATM
Ya que la arquitectura TAP realiza aportaciones al modelo arquitectónico de ATM
debemos entender cómo se estructura éste para poder comprender así las aportaciones de TAP a
su funcionamiento. El modelo ATM se apoya en las capas Física, ATM y de Adaptación ATM,
cada una de ellas con una serie de funciones específicas para permitir la transferencia de células.
En la arquitectura TAP la capa física permanece intacta y se centra sobre todo en la capa de
adaptación ATM. Las uniones de cada una de las capas se presentan en el siguiente cuadro:
7
Simulador de Tráfico ATM con Garantía de Servicio
Figura 2.3 Modelo de referencia de ATM respecto al RM-OSI
En la figura 2.3 se presenta un esquema del modelo ATM atendiendo a las capas que
implementa cada elemento de la red. Puede observarse como los conmutadores de red tan solo
implementan las dos primeras capas ya que el tráfico entre ellos es ATM nativo. Sin embargo los
nodos o conmutadores locales sí que necesitan de la capa AAL para ajustar el tráfico no ATM que
pudiera generar un nodo terminal de usuario que, como podemos observar, pueden hacerlo a
través de cualquier protocolo de comunicación como TCP/IP.
La arquitectura ATM usa un modelo lógico para describir su funcionalidad. La
funcionalidad de ATM corresponde a la capa física y parte de la capa de enlace del modelo de
referencia OSI.
El modelo de referencia ATM está compuesto por los siguientes planos :
-
Control: Este plano es responsable de generar y gestionar las demandas de señalización.
Usuario: Responsable de gestionar la transferencia de datos.
Gestión: Contiene dos componentes
o Gestión de capas: Gestiona funciones específicas de las capas, como detección de
fallos y problemas del protocolo.
o Gestión de planos: Gestiona y coordina funciones relacionadas con el sistema
completo.
El modelo de refencia ATM se compone de las siguientes capas:
-
Capa física: Análoga a la capa física del RM-OSI, gestiona la transmisión dependiente
del medio.
8
Simulador de Tráfico ATM con Garantía de Servicio
-
-
Capa ATM: Junto con la capa de adaptación ATM, la capa ATM es análoga a la capa de
enlace del RM-OSI. La capa ATM es responsable de establecer conexiones y de transferir
células a través de la red ATM. Para esto, usa la información que se encuentra en la
cabecera del las células ATM.
Capa de adaptación ATM (AAL, Adaptation ATM Layer): Junto con la capa ATM, es
análoga a la capa de enlace RM-OSI. AAL es responsable de aislar los protocolos de las
capas superiores de los detalles de los procesos ATM.
Finalmente, las capas superiores a AAL recogen los datos de usuario, los coloca en paquetes
y los transfiere a la capa AAL.
2.2.2. Categorías de Servicio ATM
La tecnología ATM fue diseñada y desarrollada para soportar e integrar varias clases de
servicio. Cada cliente, en la fase de establecimiento de la conexión, negociará con la red la clase
de servicio que requiere su comunicación. Estos servicios genéricos son proporcionados por
cuatro tipos de AAL, que introducen niveles específicos de protocolo, para proporcionar la
Calidad de Servicio (QoS) adecuada para cada tipo de tráfico. Las clases de servicio que
normalizadas por la ITU-T son cuatro: DBR (Deterministic Bit Rate) SBR (Statistic Bit Rate)
ABR (Avaliable Bit Rate) y ABT (ATM Block Transfer) Además de las clases de servicio
recomendadas por la ITU-T el ATM Forum especifica un conjunto de Categorías de Servicio
(CoS), algunas de ellas equivalentes a las capacidades de servicio mencionadas anteriormente.
Las categorías de servicios comúnmente usadas por los proveedores son las siguientes:
- La clase CBR (Constant bit Rate) proporciona una velocidad de acceso constante y una
relación sincronizada entre los usuarios; en otras palabras es un servicio que emula las
prestaciones de un circuito. Es equivalente a la DBR de la ITU-T.
- La clase VBR (Variable Bit Rate) se divide en dos subclases, la de tiempo real (RTVBR) y la de tiempo no real (NRT-VBR), respectivamente. La RT-VBR es para servicios que
tienen una tasa de bits variables en combinación con requisitos estrictos de tiempo real. La otra
subclase de VBR es para tráfico en el que la entrega a tiempo es importante pero la aplicación
puede tolerar una cierta cantidad de fluctuación. Equivalente a la SBR de la ITU-T.
- La clase ABR (Avaliable Bit Rate) se diseñó para tráfico a ráfagas cuya gama de ancho
de banda se conoce aproximadamente. Permite a los usuarios finales pedir a la red cuánto ancho
de banda es necesario para una conexión dada pero evita tener que comprometerse con un ancho
de banda fijo. La ABR es la única categoría de servicio en la que la red proporciona tasa de
retroalimentación al transmisor solicitándole que disminuya la velocidad al ocurrir
congestionamientos mediante las denominadas células RM.
- Por último la UBR (Unespecified Bit Rate) No garantiza ni el caudal de tráfico ni el
retardo. Esta categoría se adapta bien al envío de paquetes IP, puesto que IP tampoco hace
promesas respecto a la entrega.
9
Simulador de Tráfico ATM con Garantía de Servicio
2.2.3. Parámetros de la Calidad de Servicio
Tanto en el caso del tráfico de datos como en el de las aplicaciones multimedia, la noción
de QoS o calidad de servicio es muy importante y está definida como un conjunto de parámetros
que representan las propiedades del tráfico. Desde una perspectiva formal y estándar, existen
consideraciones diferentes para el punto de vista del usuario y del proveedor de la red a la hora de
establecer los parámetros de la QoS. En nuestro caso vamos a tratar de forma genérica la QoS sin
entrar en consideraciones formales, por lo que podemos decir que para nosotros la QoS es "la
habilidad para definir o predecir el rendimiento de una red y ofrecer mejores servicios a una
CoS específica".
En general existen los siguientes cuatro parámetros básicos de QoS: el rendimiento
(throughput), el retardo (delay), la variabilidad de retardo (jitter) y por otro lado la fiabilidad
(reliability) Además de estos cuatro parámetros, que ya aportan grandes ventajas con respecto a
otras tecnologías, existen una extensa serie de parámetros directamente relacionados con la QoS.
En la tabla 2.1 se muestran algunos de estos parámetros que se usan para caracterizar el tráfico
que genera cada una de las fuentes, los cuáles están directamente con cada una de las CoS ya
comentadas.
Parámetro
PCR
SCR
MCR
CDVT
CLR
CTD
CDV
CER
SECBR
CMR
MBS
MFS
IBT
ECR
BCR
Descripción
Peak Cell Rate
Significado
Máxima velocidad a la que se envían
células
Sustained Cell Rate
Velocidad media de células a largo plazo
Minimun Cell Rate
Velocidad de células mínima
Cell Delay Variation Tolerance
Máxima fluctuación de retardo de células
Cell Loss Ratio
Tasa de células perdidas o entregadas con
retardo
Cell Transfer Delay
Tiempo que tarda una célula en llegar
extremo-extremo
Cell Delay Variation
Variación entre los retardos de llegada de
células.
Cell Error Ratio
Porcentaje de células erróneas que llegan al
destino
Severely-Errored Cell Block Ratio Porcentaje de tramas que contienen células
erróneas
Cell Missinsertion Rate
Células entregadas a destino erróneo por
errores en cabecera
Maximum Burst Size
Máximo tamaños de ráfaga permitido
Maximum Frame Size
Máximo tamaño de trama permitido
Intrinsic Burst Tolerance
Tolerancia a la aparición de ráfagas
Explicit Cell Rate
Velocidad máxima de células explícitas
autorizada a la fuente
Block Cell Rate
Velocidad pico de célula de bloque
Tabla 2.1 Parámetros de QoS
10
Simulador de Tráfico ATM con Garantía de Servicio
2.2.4. Control de Congestión
Hemos visto que uno de los aspectos principales en la transmisión de células en ATM es
la falta de comprobación de errores del payload. Por tanto un error en una célula puede pasar
inadvertido hasta que ésta llega al extremo destino de su VP. Sin embargo, a pesar de la gravedad
de estos errores de transmisión, no son el principal problema que pueden experimentar las células
ya que son relativamente poco frecuentes (la fibra óptica tiene una tasa de errores de 10EXP-12)
Un problema más grave y menos predecible es el de la congestión, provocado en los
conmutadores cuando se les exige un rendimiento superior al que son capaces de ofrecer.
Nos encontramos con dos tipos de congestión principales: a largo plazo provocada por la
generación de un tráfico superior al que puede manejar la red y, por otro lado, la congestión
producida a corto plazo que es causada por fuentes que generan tráfico a ráfagas que no
mantienen un comportamiento estable en sus parámetros. Para solventar estos dos problemas se
han propuesto múltiples:
•
•
•
Control de admisión. Si la red no puede encontrar un circuito virtual que garantice las
necesidades que el usuario expresa en el transcurso del procedimiento de establecimiento de
la conexión, no permitirá que ésta se lleve a cabo para evitar que su entrada pueda perturbar
el buen estado de la red y de las conexiones que ya han sido admitidas. Esta labor la realiza la
función CAC (Connection Admission Control)
Reserva de recursos. Como complemento al CAC en cada conmutador se reservan recursos
para cada conexión establecida con el fin de que no sean tomados por otra conexión. La
reserva de recursos puede hacerse respecto a cualquiera de los parámetros de QoS que hemos
descrito anteriormente.
Control basado en velocidad explícita. Como ya dijimos anteriormente la CoS ABR utiliza
células RM generadas con una frecuencia fija. Cuando un conmutador detecta la falta de
alguna célula RM prevista lo interpreta como la existencia de congestión en algún punto entre
el destino y el conmutador que lo detecta. Mediante este mecanismo el emisor tiene la
posibilidad de rebajar su tasa de transferencia cuando ocurre esto ante la posibilidad de
congestiones. El protocolo TAP utiliza un mecanismo parecido para ofrecer garantía de
servicio a las conexiones privilegiadas.
Aunque, como hemos visto, existen mecanismos de control de congestión, las
congestiones pueden aparecer de forma indeterminista y en estos momentos es cuando tendrá
sentido el protocolo de recuperación de células (PDUs) punto-a-punto propuesto en TAP en lugar
del mecanismo extremo-a-extremo usado por los protocolos AAL y superiores de los terminales
ATM.
2.2.5. Redes ATM
Las redes ATM están orientadas a conexión, por lo que antes de empezar cualquier
transmisión de información se ha de proceder al establecimiento del enlace. Los dos
identificadores en la cabecera de la célula (VPI y VCI) permiten distinguir dos tipos distintos de
11
Simulador de Tráfico ATM con Garantía de Servicio
conexión: el campo VPI (Virtual Path Identifier) identifica un trayecto virtual y el VCI (Virtual
Channel Identifier) un canal virtual, pudiendo existir varios VCs por VPs y varios VPs por cada
canal físico.
Las redes ATM se muestran adecuadas para tratar cualquier tipo de información
basándose en señales digitales. Las 5 capas de adaptación ATM (las AALs) son las encargadas de
adaptar el flujo de señales binarias generadas por los terminales para poder ser tratadas por los
conmutadores ATM, segmentándolos en bloques de 48 bytes y reagrupándolos después.
ATM resulta particularmente interesante para proporcionar instantáneamente un gran
ancho de banda en aquellas aplicaciones con un alto nivel de impulsividad, como son las propias
de las redes locales; así, pues, esta técnica de multiplexación encuentra una de sus principales
aplicaciones en la interconexión de LANs dentro de entornos privados (HUBs ATM).
Su introducción en la red pública, al requerir elevadas inversiones y largos procesos de
aceptación, se realizará progresivamente y en función de la existencia de aplicaciones multimedia
y de equipos de acceso ATM suficientemente flexibles y económicos para ser utilizados
masivamente, sirviendo, por ejemplo, para la interconexión de las islas ATM privadas.
Por otra parte, el servicio de vídeo bajo demanda permite el transporte de imágenes
digitales, comprimidas o no, a alta velocidad. En este caso la velocidad binaria puede variar
(VBR).
Figura 2.4 Interconexión ATM en LAN-MAN-WAN
12
Simulador de Tráfico ATM con Garantía de Servicio
3. Motivaciones
En este capítulo vamos a profundizar sobre los motivos que impulsaron la creación de la
arquitectura TAP que, como ya hemos apuntado con anterioridad, tiene unos objetivos específicos
y bien definidos. Hemos dicho que TAP ofrece Garantía de Servicio (GoS) a un conjunto de
privilegiado de conexiones pero ¿qué se entiende por garantía de servicio? ¿Qué relación tiene
con respecto a la fiabilidad? ¿Cuáles son los antecedentes y alicientes que provocaron la creación
de este servicio? ¿Qué ventajas podríamos obtener si lo implantáramos en una red ATM? En los
siguientes apartados pretendemos contestar a todas estas preguntas. Con estos objetivos presentes,
primeramente nos centraremos en el concepto de fiabilidad que, como ya dijimos en el anterior
capítulo, es un parámetro básico de la QoS, y prestaremos especial atención a las circunstancias
que hacen una conexión más o menos fiable y a los mecanismos de que dispone la red para
proporcionan el grado de fiabilidad deseado. Seguidamente introduciremos el concepto de
garantía de servicio y veremos qué relación tiene con la fiabilidad. En los dos siguientes
apartados estudiaremos someramente el protocolo TCP y su funcionamiento sobre ATM para
mostrar cómo los protocolos superiores intentan resolver las deficiencias que en este sentido
presentan las redes ATM. Por último, y una vez ya tenemos claro los anteriores conceptos,
centraremos nuestra atención en los procesos que intervienen a la hora de aportar GoS a las
conexiones y poner de relieve los problemas y carencias a los que se enfrenta una red ATM actual
a la hora de proporcionar este servicio a un conjunto de conexiones privilegiadas.
3.1. Fiabilidad
La tecnología ATM se caracteriza por su flexibilidad a la hora de proporcionar distintos
grados de servicio a las conexiones según el tipo de tráfico que generen. Esta flexibilidad nace de
la posibilidad de negociar diversos parámetros de QoS como througput, delay, jitter y reliability
(fiabilidad) Por lo tanto una fuente ATM tiene la posibilidad de exigir un cierto grado de
fiabilidad a la red para las conexiones que quiera establecer.
Antes de proseguir es necesario dar una definición al concepto de fiabilidad según se
entiende en el ámbito de las redes ATM. En comunicaciones el concepto de fiabilidad está
claramente aceptado como "la forma de aportar a las conexiones extremo-extremo garantía
plena de que la información que transfieren llega sin ningún error o, si aparecen errores, todos
puedan ser detectados y corregidos". De esta definición podemos extraer tres deducciones
inmediatas: la primera y más obvia, en una comunicación puede haber errores; en segundo lugar,
es posible detectar y solventar esos errores; en tercer y último lugar, ya que la fiabilidad es un
parámetro negociable, deducimos que según el grado requerido de fiabilidad puede no ser
necesario corregir un error.
Vayamos por partes; según el primer aspecto vemos que los errores en las transmisiones
son posibles pero ¿qué es un error? Un error puede considerarse como la manifestación de un
fallo. En las redes ATM los posibles fallos en su funcionamiento pueden provocar tres tipos de
errores que afectan directamente a la información que transportan: bits erróneos en el payload de
una célula, errores de conmutación debido a bits erróneos no detectados en la cabecera de una
célula y bits perdidos en congestiones. Según las investigaciones realizadas se demuestra que las
13
Simulador de Tráfico ATM con Garantía de Servicio
pérdidas por congestión son la forma predominante de error. Esto es así ya que los otros dos tipos
de errores son predominantemente consecuencia del ruido inducido por la línea de comunicación.
Como ya sabemos ATM fue diseñado para usarse en fibra óptica y la fibra es altamente fiable con
una tasa de error de 10EXP-8 a 10EXP-12, o sea, que por cada billón de bits que pasa por un
tramo de cable tan solo uno de ellos sufre alteración. Por lo tanto el principal problema al que se
enfrenta una red a la hora de proporcionar conexiones fiables es el de la pérdida de células por el
agotamiento de recursos cuando muchas compiten con ellos, esto es, la congestión.
Llegados a este punto nos vamos a centrar sobre el segundo aspecto deducido de la
definición de fiabilidad: la detección y resolución de errores. En cuanto a la detección de
errores, ATM nos proporciona varios mecanismos. El de más bajo nivel consiste en un código de
redundancia cíclico de 8 bits presente en el capo HEC de las células (ver capítulo 2 figura 2.2)
utilizado para detectar errores en la cabecera. Por las características de CRC y del medio de
transmisión se calcula que, a velocidad OC-3, pasará un encabezado de célula errónea cada
90.000 años. Así vemos que, aunque posible, es casi nula la probabilidad de que una célula con
cabecera errónea pase desapercibida. Sin embargo para el cuerpo de una célula, a este nivel, no
existe ningún mecanismo que nos permita saber si un bit es erróneo o no. Esto se resuelve con un
segundo nivel de control de errores mediante varios y diversos mecanismos aplicados a paquetes
de células. Así pues, en el nivel AAL se realiza una comprobación de la integridad de las células
que componen un PDU-AAL (ya sea AAL-1, AAL-2, AAL-3/4 ó AAL-5) Es importante destacar
que las tramas AAL sólo tienen sentido en los terminales de la comunicación por lo que este
control es únicamente extremo-extremo. Por lo tanto, si una célula perteneciente a una trama
AAL se pierde o presenta bits erróneos por algún motivo en el transcurso de una transmisión, el
suceso solo será detectado cuando se intente reensamblar la trama y se compruebe, mediante el
mecanismo de detección de errores específico de cada tipo, que la trama no es correcta. Mientras
tanto el resto de las células de la trama corrupta habrán estado circulando por la red ocupando
recursos inútilmente. Esto afecta muy negativamente al rendimiento de la red de muy diversas
formas dependiendo de la técnica utilizada para la corrección del error. Efectivamente la
resolución de errores en una red ATM puede realizarse mediante retransmisiones extremo-aextremo, lo que se denominan técnicas ARQ (Automatic Repear Request) Según esta técnica el
anterior error provocará una petición de retransmisión y la consecuente retransmisión de la PDU
completa por parte del extremo emisor. Si nos ponemos en la situación en la que la célula se ha
perdido como consecuencia de una congestión, el hecho de pedir retransmisiones extremo-aextremo de tramas enteras para subsanar el error podría acarrear un empeoramiento de la
situación. Al pedir estas retransmisiones en vez de disminuir el tráfico para minimizar riesgos de
congestión lo que hacemos es todo lo contrario. Es la situación del perro que se muerde la cola,
cuanta más congestión hay más células se pierden y más retransmisiones se solicitan; cuantas más
retransmisiones se solicitan más células se han de transmitir y más congestiones se provocan.
Un problema más grave es el de la implosión y se produce por peticiones de
retransmisiones en conexiones punto-multipunto donde cada destino realizará su propia petición
de retransmisión al origen estando éste obligado a responder a todas ellas. La otra técnica
alternativa es el FEC (Forward Error Correction) y se trata de corregir errores gracias la
codificación de información redundante junto con los datos con el fin de reconstruir los datos
originales en caso de error. FEC permite por tanto la recuperación sin necesidad de
retransmisiones sin embargo añade sobrecarga por cabeceras y también código redundante
cuando la red está experimentando congestiones. Cabe señalar que existen propuestas de técnicas
híbridas ARQ-FEC pero la aplicación de éstas a tráfico multipunto es una labor muy compleja y
problemática.
14
Simulador de Tráfico ATM con Garantía de Servicio
Ya hemos visto cómo los errores en las transmisiones son posibles, detectables y
solventables. Sin embargo como hemos dejado entrever anteriormente, la reparación de un error
puede no ser necesaria e incluso puede resultar perjudicial. Pongámonos en la situación de estar
escuchando una cadena de radio digital mediante una conexión ATM en nuestro computador.
Puede resultar aceptable en esta situación el error en un bit o la pérdida una célula de vez en
cuando ya que el oído humano, al tener una sensibilidad limitada, no detectaría este error. Sin
embargo sería inaceptable la petición de retransmisión de toda una trama AAL para recuperar una
posible célula perdida ya que, aparte de que podría provocar un desorden en la recepción de
PDUs, las aplicaciones en tiempo real, como la del ejemplo, no toleran un elevado retardo por lo
que la información de la emisora podría resultar ininteligible. Por lo tanto el grado de fiabilidad
requerido por una conexión está relacionado directamente con el tipo de información que
transporta y sus exigencias particulares.
3.2. Garantía de servicio
La propuesta de arquitectura TAP introduce el concepto de Garantía de Servicio (GoS)
En su caso, no se pretende centrarse plenamente en el ámbito de la fiabilidad sino "encontrar un
mecanismo que aporte a las transferencias ATM su garantía de servicio en el caso de que
aparezcan congestiones en los conmutadores y, además que, cuando esto se produce, pueda ser
solventado de forma local a los conmutadores congestionados sin implicar a toda la red para
optimizar el goodput". El protocolo propuesto no se considera fiable en el estricto sentido de la
palabra ya que no se comporta como tal, sino que lo que aporta es un elevado grado de confianza
de servicio a las conexiones que lo utilizan. El objetivo de TAP no es por tanto la búsqueda de
una fiabilidad completa en las conexiones, cosa que ATM ofrece por muy diversos métodos a
costa de sobredimensionar las cabeceras de las células o PDU ATM, y con retransmisiones
extremo-a-extremo. La GoS va un paso más allá de la fiabilidad en el sentido de que aporta
mecanismos que intentan atajar el problema de la pérdida de células desde su raíz, esto es,
proponiendo un mecanismo de retransmisiones al mismo tiempo que intenta evitar las
congestiones en los conmutadores. Para el protocolo TAP la GoS se deriva directamente del
parámetro fiabilidad y puede verse como un nuevo parámetro de QoS.
3.3. Funcionamiento de TCP
El protocolo TCP se ha convertido en el estándar de comunicaciones de datos. Se trata de
un protocolo fiable de la capa de transporte de la arquitectura TCP/IP que usa un control de error
y un control de flujo basados en ventana y se encarga del enrutamiento de paquetes en internet
con el control extremo-a-extremo. En la actualidad las redes ATM se están usando como la
tecnología para soportar todo tipo de tráfico, pero con destacable predominio de los protocolos
TCP/IP. Las diferencias entre ambas tecnologías se muestra como un serio obstáculo a la hora de
mandar segmentos TCP a través de una red ATM y pretender mantener el throughput a niveles
óptimos. En este apartado veremos brevemente cómo funciona TCP/IP y cómo reacciona ante las
congestiones para poder entender mejor cómo puede degenerar el goodput de una red ATM que
transporta tráfico TCP.
15
Simulador de Tráfico ATM con Garantía de Servicio
3.3.1. Funcionamiento de TCP
La unidad de datos de protocolo en TCP se denomina segmento. Un segmento consiste
en una cabecera de 20 bytes (más una parte opcional) seguida una parte de datos. En conjunto, el
tamaño máximo de un segmento TCP no puede sobrepasar los 65,535 bytes. Un segmento
demasiado grande para transitar por una red puede dividirse en varios segmenteos mediante un
enrutador. Cada segmento nuevo recibe sus propias cabeceras TCP e IP, por lo que la
fragmentación en los enrutadores aumenta la carga extra total.
El protocolo básico usado por las entidades TCP es el protocolo de ventana corrediza de
tamaño variable. El protocolo TCP es en la actualidad un conjunto de algoritmos que envían
paquetes a la red sin ningún tipo de reserva previa, pero que son capaces de reaccionar ante
determinados eventos de la misma. Entre estos algoritmos destaca el Control de Congestión y el
de Recuperación de Segementos Perdidos. Para poder llevar esto a cabo, cada emisor mantiene
dos ventanas: RWND (Receiver Window) y CWND (Congestion Window). Cuando se envían
paquetes se usa la ventana más pequeña de estas dos.
Al establecerse una conexión, el transmisor asigna a la ventana de congestionamiento el
tamaño de segmento máximo usado por la conexión; entonces envía un segmento máximo. Por
cada asentimiento positivo recibido antes de terminar el temporizador, la ventana de congestión
es aumentada al doble de su valor. La ventana de congestionamiento sigue creciendo
exponencialmente hasta ocurrir una terminación de temporización o alcanzar el tamaño de
ventana receptora. Este algoritmo se llama Slow Start. El control de congestiones utiliza un
parámetro, el umbral, inicialmente de 64 Kbytes. Cuando aparece congestión, por ejemplo
detectada por un timeout, el valor del umbral es puesto a la mitad del valor actual de la ventana de
congestión, la ventana de congestión es puesta a 1 segmento y la fase Slow Start es reiniciada de
nuevo. Si no ocurren más terminaciones de temporización, la ventana de congestionamiento
continuará creciendo hasta el tamaño de ventana del receptor. Un transmisor que llegue al umbral
en su ventana de congestión entrará en la fase de Congestion Advoidance en la que la ventana de
congestión aumentará de forma lineal al contrario de su crecimiento exponencial durante la fase
de Slow Start. En realidad, en última instancia, la velocidad de transmisión de TCP viene
determinada por el RTT (round tip time), ya que el emisor envía cada RTT el tamaño de datos
determinado por la ventana de congestión.
Por tanto, como se puede ver, TCP ajusta su ventana para reflejar las condiciones de la
red de forma reactiva, esto es, cuantas más congestiones se produzcan más pequeña será la
ventana al mismo tiempo que crecerá más lentamente. De esto se deduce que a medida que se
incremente la pérdida de paquetes, la eficiencia de TCP cae sustancialmente.
En [*] se realiza un estudio para comprobar el comportamiento del ancho de banda en
una red TCP con respecto a la porbabilidad de errores. En él se comprueba algo que
intuitivamente se observa a partir del propio funcionamiento de TCP y es cómo la probabilidad
de perdida acaba determinando el ancho de banda de una fuente TCP. En la gráfica 3.1
obtenida a partir de una simulación en ns se puede observar cómo a medida que se aumenta la
probabilidad de pérdida en un enlace disminuye el ancho de banda logarítmicamente hasta
acercarse a una evolución lineal cuando la probabilidad de pérdida desciende, que es lo que
intenta TAP.
16
Simulador de Tráfico ATM con Garantía de Servicio
Figura 3.1 Probabilidad de pérdida respecto al Ancho de Banda
En este mismo estudio también se ha considerado el efecto de N fuentes TCP
compartiendo un enlace partiendo de la posibilidad de que ese enlace pueda convertirse en un
posible cuello de botella determinado por el tamaño de la cola del router (B). Realiza una
aproximación a la predicción de probabilidad de pérdida de paquetes: ((FORMULA P=0,75 N^2/
B^2))
Puede deducirse por esta fórmula que en la probabilidad de pérdida influye
directamente la capacidad de almacenamiento de paquetes en las colas de los routers
comportándose éstas como un punto de congestión para el tráfico. Como ya veremos en el
módulo II en la arquitectura TAP se ha incluido un módulo de memoria adicional para propósitos
específicos denominada DMTE. Esto contribuye de forma directa a aumentar el tamaño del buffer
y en vista de la fórmula anterior a conseguir disminuir la probabilidad de pérdida P.
3.3.2. TCP sobre ATM
Debido a sus características, las CoS ABR y UBR son la propuesta estándar para soportar
el tráfico de datos. Sin embargo diversos estudios demuestran que TCP sobre UBR experimenta
una apreciable degradación en el funcionamiento en cuanto a la justicia, requiriendo además de
un tamaño de buffer relativamente grande, incluso con pocas conexiones. Sin embargo cuando se
emplea la CoS ABR con esquemas de realimentación de velocidad explícita ofrecen a TCP mejor
comportamiento en cuanto a justicia y aprovechamiento de los enlaces, y todo ello, con tamaños
de buffer menores que con UBR.
Uno de los principales problemas que experimentan las fuentes de tráfico TCP cuyos
segmentos son transferidos sobre ATM es que, al usarse como indicación de congestión la propia
pérdida de paquetes, esto provoca que la gestión de las congestiones se realice cuando ya es
demasiado tarde. Es decir, cuando el buffer se llena, el conmutador descarta los paquetes, el
receptor detecta la pérdida y éste avisa al emisor que acaba reaccionando con la retransmisión de
los paquetes perdidos. Se impone por tanto la necesidad de aportar mecanismos más ágiles para la
17
Simulador de Tráfico ATM con Garantía de Servicio
resolución de las congestiones de tráfico TCP que es transferido sobre tecnología ATM. Además
existen muchas otras características diferenciadoras requiriéndose en consecuencia soluciones que
resuelvan los problemas de rendimiento provocados por la integración de ambas tecnologías.
Parece lógico que estas soluciones estén en la línea de realizar cambios en los conmutadores
ATM dentro de la red. En el caso de TAP se enfrenta a estos problemas actuando dentro de la
misma red con mecanismos hardware (conmutadores AcTMs) y también software (SMA con
protocolo TAP).
3.4. Beneficios aportados por TAP
A parte de los beneficios, llamémosles secundarios, apuntados en los anteriores
apartados, la motivación de TAP se centra en encontrar soluciones para evitar el negativo
problema de las retransmisiones extremo-a-extremo. TAP se enfrenta a este problema resolviendo
las retransmisiones de forma local a donde se producen para evitar el coste del tiempo RTT total
de la red y emplear sólo el RTT del enlace donde se produce la congestión.
Un RTT alto es un problema bastante grave en las redes de banda ancha. Veamos el por
qué de este problema mediante un ejemplo:
La electricidad se transmite en un cable de cobre a 2/3 de la velocidad de la luz. La luz en
fibra óptica se transmite también a una velocidad que es 2/3 de la que alcanza en el vacío. Si
disponemos de una línea transcontinental de 3000 Km, el retraso que experimenta una señal es de
3000/200000 = 15 ms. Supongamos que queremos enviar 1 Mb de datos por esa línea a 64 Kb/s y
esperar la confirmación. Sólamente bombear a la línea el Mb lleva 1000/64 = 15.6 segundos. El
retraso de propagación del impulso eléctrico es de 0.015 * 2 = 0.03 segundos, que no es
significativo frente a los 15.6, de modo que la distancia entre máquinas no es un factor que
influya en el diseño del sistema global. Consideremos ahora la instalación de adaptadores ATM
en ambas máquinas a una velocidad de 622 Mbs. Ahora poner en la línea 1 Mb supone 1/622 =
0.0016 s. Un retardo de propagación de 0.03 segundos, no sólo sí es significativo frente a 0.0016
segundos que se emplea en sacar el fichero a la línea, sino que es 18 veces mayor. Se tarda
muchísimo más en que el primer bit llegue al otro extremo que en poner en el cable el Mb entero.
Desde que comienza el envío hasta que vuelve la confirmación transcurren 0.0316 segundos, de
los cuales la línea está ocupada 0.0016 segundos y ociosa 0.03 segundos, es decir, el 95% del
tiempo. Un aumento de la velocidad de transmisión no provoca más que un menor
aprovechamiento de la línea, que se aproxima asintóticamente al 100%.
En el escenario descrito hemos supuesto una red ideal en la que no se produce ningún
problema debido a congestiones o a bits erróneos. Fácilmente podemos entender que cualquier
tipo de retransmisión debida a estos problemas acaba agravando aún más el problema descrito, ya
que se multiplica el tiempo RTT mientras el tiempo de inactividad de la fuente se mueve a valores
cercanos a 0. Con TAP se realizan las retransmisiones de forma local por lo que se consigue
decrementar la probabilidad de pérdida con el consiguiente efecto sobre el throughput de TCP
que evita los retardos debidos al RTT extremo-a-extremo. Se consigue así maximizar el goodput
con una mínima pérdida de paquetes en el nivel TCP y con un retardo mínimo de células en el
nivel ATM.
18
Simulador de Tráfico ATM con Garantía de Servicio
3.5. Limitaciones de ATM frente a la GoS
En el apartado 3.2 introdujimos el concepto de GoS como un parámetro adicional
derivado de los parámetros generales de QoS y cómo TAP pretende llegar a proporcionar GoS a
un conjunto de conexiones privilegiadas. En este apartado vamos a indicar las limitaciones que
impiden ofrecer a través de ATM el concepto de GoS.
•El primero y más importante problema es la imposibilidad de ATM de disponer de fiabilidad
total sin afectar al buen rendimiento de la red. Una red ATM asume que pueden producirse
pérdidas, de forma que la resolución de las mismas quedan delegadas en protocolos de capas
superiores.
•Ni las células ATM ni las unidades de transferencia mayores de la capa AAL disponen de
números de secuencia lo que impide la identificación de las que se pierden cuando la red
experimenta congestiones. Por lo tanto, como en el anterior caso, la detección de datos perdidos
es tarea de los protocolos superiores que, como sabemos, repercute en la eficiencia de la red por
la necesidad de realizar retransmisiones e-e.
•Si se quieren suprimir las retransmisiones e-e para las conexiones con GoS es necesario un
mecanismo que permita a los conmutadores AcTMs solicitar retransmisiones p-p de las tramas
perdidas cosa que no está especificado en la actualidad por ATM.
•Además, debido a las características propias de la GoS y para proporcionar ésta sin degradar el
rendimiento de una VPN son necesarios mecanismos que eviten la fragmentación de tramas y la
mezcla de células pertenecientes a tramas distintas en una transimisión (lo que se conoce como
interleaving).
19
Simulador de Tráfico ATM con Garantía de Servicio
II. LA PROPUESTA TAP
4. Introducción
Lo primero que hay que exponer en esta introducción es la definición de agente. El
concepto de agente puede ser estudiado desde muy distintos puntos de vista por lo que no existe
un consenso claro en su definición. Uno de los ámbitos de acción de los agentes es precisamente
el de los sistemas de telecomunicación, porque los agentes pueden dotar a las redes de
características de las que carecen en la actualidad. Genéricamente, podemos decir que un agente
es una entidad con objetivos, que alcanza ejecutando una serie de acciones, mediante un dominio
de conocimiento y situado en un entorno concreto. Podemos hablar de sistemas multiagentes
como un grupo de agentes que se comunican de algún modo entre sí.
También existe controversia acerca de la definición de redes activas. Estas redes se basan
en la posibilidad de equipar los nodos con características que los transforman en elementos
activos. En el caso que nos atañe en este proyecto, conseguimos dar a ciertos nodos de la red
(conmutadores activos) características activas mediante la implementación en ellos de agentes.
4.1. Conceptos fundamentales sobre agentes
Este apartado no pretende ser un compendio acerca de los agentes: origenes, tipos... Sino
que nos centramos en la definición estricta para la propuesta TAP. Nos encontramos ante un
problema cuando intentamos definir un agente. Existen numerosas definiciones en la literatura,
pero creemos que la más destacable puede ser:
“las redes de comunicaciones futuras se conciben más automatizadas, pudiendo ser
gestionadas por entidades software, tanto móviles como estáticas, coleccionando información de
estado de la red y que aportan la habilidad innata para invocar cambios efectivos en los
controladores de los conmutadores sin la interacción explícita de ningún operador humano.”
Dentro de la definición de agente caben muchos tipos. Uno de ellos es el agente software.
Es el tipo de agente más específico. Se puede definir como una entidad que puede interactuar con
su entorno. Es decir, existen agentes que pueden ser implementados usando software, lo que
significa que pueden ser autónomos y pueden reaccionar con otras entidades, incluyendo los
humanos, máquinas y otros agentes software en varios entornos o plataformas. Debemos destacar
que este planteamiento es el que nosotros usamos en nuestra propuesta de forma que nos
referiremos a la arquitectura TAP como constituida por agentes software.
20
Simulador de Tráfico ATM con Garantía de Servicio
4.2. Sistemas multiagentes (SMA)
La mayoría de los problemas se podrían solventar con un único agente, pero atendiendo a
la programación descendente y modular, ese problema, puede dividirse en otros subproblemas
cada vez más sencillos. Se huye de la idea del agente omnipotente. Se tiende a este planteamiento
en el que múltiples agentes autónomos interactúan, se coordinan (cooperando, compitiendo o
ambas cosas) y todo ello de una forma adaptativa. De esta forma se constituyen sociedades de
agentes a las que se consideran Sistemas MultiAgentes (SMA).
Motivos para emplear SMA:
-
El uso de un agente omnipotente puede darnos problemas en la escalabilidad y puede
producir pérdida de eficiencia. La solución pasa por dividir el problema y por lo tanto el
agente.
Si centramos todo el conocimiento sobre un agente pueden aparecer problemas como la
falta de robustez del sistema, ya que un error en el conocimiento del agente es propagado
a todo el sistema.
Distribuir la carga, las tareas o las funciones permite diseñar los agentes de un SMA
como componentes autónomos que actúan en paralelo para resolver un problema de
ámbito general.
Los agentes pueden ser entes autónomos o formar parte de un SMA. Resulta
relativamente sencillo extrapolar el concepto de agente hacia sistemas, poco o muy complejos,
donde intervengan diversos agentes software coordinados entre sí y compartiendo informaciones
que les sean de interés. De este modo podemos adquirir una idea clara e intuitiva de lo que sería
un sistema o sociedad de agentes múltiples, distribuidos y cooperativos que interaccionan entre sí
compartiendo información.
21
Simulador de Tráfico ATM con Garantía de Servicio
5. Arquitectura TAP
5.1. El SMA-TAP
La arquitectura TAP está basada en la incorporación de varios agentes software en el
modelo de conmutador propuesto y que hemos denominado AcTMs (conmutadores ATM
activos). De este modo damos lugar a una red ATM activa en la que sus conmutadores van a
desempeñar una función activa en la gestión de las colas de entrada, en la detección de
congestiones, así como en la labor de retransmisiones cuando empiezan a perderse células de las
fuentes de tráfico que se han elegido con tráfico garantizado.
En la figura 5.1 vemos la posición que ocupa SMA-TAP dentro de la arquitectura ATM.
SMA forma parte del Plano de Gestión ya que aporta nuevos mecanismos para la gestión de
recursos ATM, siendo transparente a funciones como CAC y UPC. En esa misma figura también
se muestra la extensión EAAL-5 que hemos desarrollado:
Figura 5.1: Situación del SMA-TAP en el modelo arquitectónico ATM
TAP centra sus objetivos en la consecución de la garantía de servicio, aunque es claro que
este SMA puede ser fácilmente ampliado con nuevas funcionalidades más propias de la capa de
control del modelo de referencia ATM
22
Simulador de Tráfico ATM con Garantía de Servicio
5.2. Arquitectura del SMA-TAP
La arquitectura SMA-TAP es un sistema constituido por 5 agentes. En la figura 5.2 se
puede observar esta arquitectura.
Los distintos agentes software que componen la arquitectura SMA-TAP son:
-
-
-
-
Agente CoSA (Class of Service Agent): Agente programable que se encarga de recibir los
parámetros del tráfico que proviene de las fuentes de entrada. Se encarga del
establecimiento de la conexión, de las tablas de routing para determinar los VPI/VCI
extremo a extremo y de la liberación de la conexión.
Agente WFQA (Weighted Fair Queuing Agent): Mantiene una coordinación constante
con el agente CoSA. Recibe del CoSA los flujos de entrada destinadas a las colas que
WFQA gestiona de forma justa y de acuerdo a los pesos establecidos en los parámetros
del tráfico.
Agente programable CCA (Control Congestion Agent): Controla las congestiones
basándose en EPDR y en otros algoritmos que el administrador de la red puede elegir.
Este agente monitoriza el buffer de entrada, y cuando su ocupación sobrepasa el umbral
establecido no acepta ninguna PDU entrante.
Agente RCA: Se encarga de generar células RM nativas que son transmitidas en sentido
contrario al del flujo de la información.
Agente DPA: Se encarga de obtener las PDU o células del buffer de entrada cuando son
transmisiones, o PDU de la DMTE cuando se trata de retransmisiones. Una vez recibidas,
se encargará de despacharlas completas al correspondiente puerto de salida, previa
actualización de la Tabla de Entrada/Salida de ese puerto. Con esta técnica se evitan las
congestiones de los puertos de salida y también la mezcla de células pertenecientes a
diferentes PDU o fuentes.
23
Simulador de Tráfico ATM con Garantía de Servicio
Figura 5.2 Arquitectura TAP con el subsiste ma SMA-TAP
Desde el punto de vista funcional de los agentes disponemos de un agente programable,
que puede actuar como agente inteligente y también como agente reactivo ante situaciones de
congestión. El agente CCA no sólo permite al operador elegir el algoritmo y los parámetros del
esquema de control de congestión, si no que se comporta reactivamente ante la aparición de
congestiones, y proactivamente pudiendo actuar para evitar la aparición de congestiones
ajustando el valor umbral del buffer. Por otro lado, WFQA es un agente colaborativo que recibe
eventos desde los agentes CoSA y RCA para llevar a cabo sus acciones generando como salida
células y/o PDU clasificadas de acuerdo a los pesos de sus fuentes. El agente CoSA, también
programable y reactivo, responde ante el establecimiento de conexión de las fuentes, para lo que
necesita coordinarse con otros agentes similares en conmutadores adyacentes. El agente RCA,
también reactivo, es capaz de atender eventos provocados por situaciones de congestión en su
propio conmutador y en otros conmutadores de la red. Este agente colabora también directamente
con el agente WQFA y de forma indirecta con CCA. Por último, DPA es un agente autónomo
que, mediante técnicas de control, se encarga de actualizar las estructuras de datos del sistema
como las Tablas de E/S, la memoria DMTE y el buffer del conmutador.
En la figura 5.3 se puede observar la distribución de los agentes en las capas de la
arquitectura SMA-TAP.
24
Simulador de Tráfico ATM con Garantía de Servicio
Figura 5.3 Arquitectura SMA-TAP en capas.
5.3. Conmutadores AcTMs
Existen en la literatura múltiples arquitecturas de conmutadores ATM, aunque la mayor
parte de ellas se basan en el uso de una matriz de conmutación donde confluyen las células de las
conexiones de entrada que son conmutadas (tras asignarles sus correspondientes valores
VCI/VPI) a los puertos de salida. Sobre esta propuesta base de arquitectura se han realizado
múltiples variaciones entre las que podemos situar TAP que, con la intención de solventar las
problemáticas que ya conocemos, ha sido equipada con los módulos citados en el apartado
anterior, los cuales van a ser seguidamente comentados en detalle.
5.3.1. Colas de entrada
Los conmutadores que constituyen las redes ATM deben encargarse de mezclar los flujos
de tráfico que provienen de fuentes diferentes y enrutarlos después hacia distintos destinos a
través de paths de conmutación y enlaces de transmisión que las células de las diversas fuentes
pueden compartir durante gran parte de su tránsito. Para que todo este proceso sea posible, los
nodos de la red deben disponer de un almacenamiento temporal de las células en buffers de
tamaño finito, de forma que el flujo de los datos en cada momento pueda hacer que el tamaño de
estas colas de almacén temporal crezca y disminuya de forma dinámica. En realidad, este no es
ningún mecanismo nuevo si lo comparamos con las redes de conmutación de paquetes clásicas,
aunque lo realmente novedoso en el caso de ATM es la muy superior velocidad de conmutación
(superiores a 622 Mbps en ATM frente a poco más de 256 Kbps en X.25). Estos requerimientos
de elevada potencia de conmutación obligan a que cualquier propuesta que pueda hacerse para la
labor de encolado del tráfico de entrada a los conmutadores deba ser optimizada en cuanto a los
tiempos de acceso y de procesamiento.
25
Simulador de Tráfico ATM con Garantía de Servicio
Por tanto, las labores principales de los conmutadores de la red son las de ofrecer un
almacén temporal de las células en tránsito hasta su destino (o al menos hasta el siguiente
conmutador), reenrutar estas células desde este almacén al correspondiente puerto de salida del
conmutador, y sobre todo, conseguirlo de la forma más eficiente y rápida posible, aunque en
nuestro caso deseamos añadir una nueva prestación como la GoS para aportar esa fiabilidad que
la red no aporta, pagando por ello un precio importante en prestaciones cuando el almacén
temporal de las células experimenta las impredecibles congestiones. Veremos después que las
técnicas de encolado en los nodos de la red juegan un papel fundamental en el diseño, operación y
rendimiento de las redes ATM, por lo que existen una gran variedad de formas de solventarlo en
los conmutadores, aunque los esquemas principales se dividen en tres categorías (representadas
en la figura 5.4), que colocan las colas en los siguientes puntos de los conmutadores:
-
En la entrada del conmutador, que se corresponde con la opción a) de la figura 5.4 donde
los buffers de células se sitúan a la entrada del conmutador. Si se emplean buffers FIFO,
se producen colisiones cuando dos o más cabeceras de colas compiten simultáneamente
por la misma salida, lo que provoca que una de las células pueda quedar bloqueada. Pero
también quedan bloqueadas las células que siguen a la célula bloqueada, aunque no
tengan la misma salida. Este tipo de desventaja puede solventarse con memoria RAM,
aunque se requiere para ello un control de las colas más complejo. Sucesivamente se han
ido proponiendo mejoras para este tipo de colas de entrada, y un ejemplo de ello es la
propuesta que comentaremos con TAP.
-
En la salida del conmutador, que se corresponde con la opción b) de la figura 5.4, donde
podemos observar que, en este caso, las colas de buffers se sitúan en los puertos de salida
del conmutador. En este tipo, el elemento de conmutación consta de una matriz con
buffers de salida y, sólo cuando la matriz opera a la misma velocidad que las líneas
entrantes, se provocarán las colisiones; es decir, varias células compiten simultáneamente
por el mismo puerto de salida. Este problema puede atacarse reduciendo el tiempo de
acceso al buffer, o bajando la velocidad de la matriz de conmutación. En muchos casos el
bloqueo interno se debe resolver con buffers adicionales.
-
En los puntos de cruce (crosspoints) de la matriz de conmutación de los conmutadores,
como puede observarse en el caso c) de la figura 5.4. A este tipo de elementos de
conmutación suele denominarse butterfly o encolado central, y se caracterizan porque los
buffers sólo se colocan en los puntos de cruce de la matriz, con lo que se previene que las
células que compiten por puertos diferentes no se afecten simultáneamente. Además,
mediante un control lógico, puede elegirse qué buffer es el primero en el caso de que
varias células o paquetes compitan por el mismo puerto de salida.
La situación c) de los buffers en los crosspoints supone disponer de una cola en cada uno
de los puntos del cruce de la matriz de conmutación, lo que implica que hay que dividir el espacio
de buffer total de N2 colas diferentes, cuando podrían ser N como ocurre en las otras dos opciones
citadas. Esta división de recursos de almacenamiento puede acabar provocando un incremento de
la probabilidad de pérdida de células al incrementar el número de colas potencialmente
congestionables, además de aumentar considerablemente la labor de gestión de colas.
26
Simulador de Tráfico ATM con Garantía de Servicio
Figura 5.4 Alternativas para situar las colas en los conmutadores
Tras largas investigaciones de los tres diseños, éstas se inclinan por el uso de colas de
entradas. Como se ha explicado anteriormente, en este proyecto se ha optado por la solución de
las colas de entradas. Al añadir diferentes pesos a las colas de entradas nos permite usar
mecanismos justos para el tratamiento de las colas. A esta solución de colas de entrada, en
nuestro proyecto, además, proponemos el uso de un buffer (figura 5.5) que es un punto donde se
multiplexan las salidas de las colas. Es en este buffer donde se solventan las congestiones, que es
el punto principal del uso de TAP.
Figura 5.5 Esquema de bloques de la arquitectura de los conmutadores AcTMs
27
Simulador de Tráfico ATM con Garantía de Servicio
Las colas de entrada realizan un buffering de las células que llegan al conmutador activo.
Cada cola realiza un tratamiento de dichas células en función de su VPI/VCI, intentando tratar de
forma individualizada cada conexión.
En el siguiente punto de este módulo expondremos el uso de mecanismos justos para el
tratamiento de las colas. Estos mecanismos evitarán situaciones de inanición de las fuentes con
menos requerimientos frente a aquellas que sean más ambiciosas. Veremos dos posibles
soluciones: Fair Queueing y QPWFQ.
28
Simulador de Tráfico ATM con Garantía de Servicio
6. Gestión justa de colas
En este apartado vamos a tratar el problema que surge cuando se producen situaciones de
injusticia en la entrada de los conmutadores. Esta injusticia se produce cuando hay fuentes
exigentes frente a que los son menos. Éstas últimas pueden caer en una situación de inanición.
En el caso de nuestra simulación, debido a la existencias de fuentes privilegiadas de
tráfico (mediante GoS), se hace necesario el uso de mecanismos de justicia. Una posible solución
es emplear conmutadores que realicen asignaciones de ancho de banda justas, pero los algoritmos
son demasiado complejos y esta complejidad puede llegar a hacer peligrar parámetros como del
delay y jitter, de importancia crítica para conexiones de alta velocidad (p.ej. conexiones en
tiempo real).
Todos los planteamientos de arquitectura ATM cuentan con la inclusión de colas
empleadas para aplicar la gestión del tráfico.
En general, los conmutadores ATM enrutan las células desde un conjunto de puertos de
entrada hasta un conjunto de puertos de salida basados en los identificadores de flujo VPI/VCI.
En el puerto de salida de un conmutador ATM un controlador de puerto multiplexa células desde
diferentes flujos de entrada en la línea de salida. Los puertos de salida de los conmutadores ATM
son gobernados por una política de planificación como FIFO, que decide qué células desencolar
de la cola de salida. Las políticas de planificación pueden ser clasificadas en work-conserving o
non work-conserving. Una política es work conserving si nunca deja el enlace de salida en estado
de inactividad mientras haya células dentro de la cola de salida. Al contrario, una política non
work-conserving puede dejar el enlace de salida en estado de inactividad incluso si la cola de
salida no está vacía. La siguiente tabla presenta la clasificación de algunas de las más conocidas
políticas de planificación.
Servicios work-conserving
Weighted Fair Queuing
Virtual Clock
Delay Earliest-Due-Date
Self-Clocked Fair Queuing
Servicios non-work-conserving
Jitter Earliest-Due-Date
Stop-and-Go
Hierarchical Round-Robin
Todas las políticas work-conserving tienen, para un conjunto dado de patrón de llegada de
células, idéntico retardo medio de células y necesidades máximas de buffer. Una política non
work-conserving puede necesitar mayor retardo medio de células y necesidades de buffer máximo
y medio que una política workconserving. Por otro lado, las políticas work-conserving tienden a
incrementar las ráfagas de tráfico, mientras las políticas non work-conserving pueden ser usadas
para limitar el tráfico a ráfagas. En líneas generales las políticas work-conserving son más fáciles
de implementar y requieren una gestión de buffers más sencilla.
Servicios work-conserving
Idéntico retardo medio de células
necesidades máximas de buffers.
Servicios non-work-conserving
y Puede requerir mayor retardo medio de
células y necesidades máximas y medias de
29
Simulador de Tráfico ATM con Garantía de Servicio
buffers.
Pueden ser usadas para limitar el tráfico a
ráfagas.
Fáciles de implementar.
No tan fáciles de implementar.
Envían los paquetes una vez que ha terminad Esperan un espacio de tiempo aleatorio antes
o el servicio, no espera para servir el de servir el siguiente paquete de una cola,
siguiente paquete.
incluso si hay paquetes esperando.
Tienden a incrementar las ráfagas de tráfico.
Las se pueden gestionar de diferentes maneras que influyen de manera muy diferente en
el tráfico y en los requisitos de los conmutadores.
6.1. Fair Queuing
Los algoritmos Fair Queuing se diseñaron para que los conmutadores y routers ofrezcan
el control de congestión y para la asignación justa de ancho de banda. Sin embargo, el coste de la
implementación en una red completa puede ser prohibitivo para aplicaciones de alta velocidad,
tanto por la complejidad en la programación como por la necesidad de que el algoritmo FQ
mantenga información del estado, gestione los buffers de entrada, realice la planificación de
paquetes...
No obstante, varias investigaciones han demostrado que las propuestas de control de
congestión extremoa-extremo pueden ser mejoradas de una forma sustancial si en los routers se
aplican técnicas justas de asignación del ancho de banda disponible en la red ya que, además de
proteger unas fuentes de otras, permiten que en la red puedan coexistir diversas políticas de
control de congestión. Del mismo modo, varias de estas investigaciones también reconocen que la
asignación justa de ancho de banda juega un papel necesario, aunque a veces no beneficioso, en el
control de congestión. Así, la mayor parte de propuestas en este campo parten de dos premisas
importantes, por un lado que los mecanismos justos de asignación de ancho de banda son
necesarios, y por otro, que la complejidad de estos mecanismos es un importante factor para su
adopción en las redes.
Lo que parece claro es que cualquier propuesta que realicemos en este sentido será
bastante más compleja de implementar que el clásico encolamiento FIFO que ha sido el más
usado tradicionalmente. Como es sabido, en FIFO los paquetes son servidos en el orden de
llegada, y los buffers son gestionados siguiendo una sencilla estrategia drop-tail según la cual los
paquetes entrantes son tirados cuando el buffer está lleno. Pero FIFO carece de la justicia que se
buscó con FQ y sus variantes y con mecanismos de abandono por flujos como FRED (Flow
Random Early Drop). En cualquiera de estas técnicas se requiere mantener el estado de los
diversos flujos por separado, de forma que, para cada paquete que llega, hay que clasificarlo en su
correspondiente flujo, actualizar las variables de estado de cada flujo y realizar operaciones
(encolar_paquete, tirar_paquete, priorizar_flujo, etc) en función del estado de cada flujo.
RED (Random Early Detection) sirve también los paquetes en el orden de llegada, pero la
gestión del buffer es mucho más sofisticada que el drop-tail de FIFO. RED tira
probabilísticamente paquetes largos antes de que el buffer se llene, ofreciendo indicación de
congestión rápida a los flujos que pueden ser afectados antes de que se produzca el rebosamiento
30
Simulador de Tráfico ATM con Garantía de Servicio
del buffer. De este modo RED mantiene dos umbrales en los buffers. Cuando la ocupación media
del buffer es menor que el primer umbral, no se tira ningún paquete, pero cuando se supera el
segundo umbral, los paquetes comienzan a ser tirados por la red. Cuando la ocupación del buffer
se encuentra entre los dos umbrales, es cuando la probabilidad de tirar paquetes incrementa
linealmente con la ocupación del buffer.
FRED (Flow Random Early Drop) lo que hace es ampliar RED para ofrecer un cierto grado
de asignación justa de ancho de banda. Para conseguir la justicia, FRED mantiene el estado de
todos los flujos que tienen, como poco, un paquete en el buffer. Al contrario que en RED, donde
la decisión de tirar paquetes se basa sólo en el estado del buffer, en FRED la decisión se basa
también en el estado de los flujos. De este modo, FRED tira preferentemente los paquetes de un
flujo al cual se le han tirado pocos paquetes anteriormente, y que poseen una cola mayor que el
tamaño medio de las colas. Este algoritmo tiene dos variantes, que se diferencian en que una de
las versiones garantiza a cada flujo un número mínimo de buffers.
Todos los algoritmos comentados presentan diferentes niveles de complejidad. FRED se
encarga de clasificar los flujos entrantes, mientras FIFO y RED no lo hacen. En suma, ninguno de
ellos debe implementar ningún algoritmo de planificación de paquetes, sin embargo, todos
aplican una sencilla planificación FIFO.
6.2. GPS, PGPS (WFQ) y PFQ
La disciplina GPS (Generalized Processor Sharing) tiene 2 propiedades importantes:
1) Puede garantizar un servicio de retardo limitado extremo-a-extremo a una sesión cuyo
tráfico está controlado por leaky bucket. (Bueno para tráfico best-effort y servicios jerárquicos de
enlace compartido)
2) Puede asegurar asignación justa de ancho de banda a todas las sesiones que tienen
trabajo en espera, estén o no sometidas al control de tráfico. (Base para aportar GoS al tráfico)
GPS usa un modelo fluido ideal que no se puede implantar en el mundo real por lo que se
han realizado aproximaciones a éste modelo. A estas aproximaciones se les denomina PGPS
(Packet Generalized Processor Sharing) o, en otros casos, PQF (Packet Fair Queuing). El
algoritmo (basado en GPS) más popular y más implantado es el WFQ (Weighted Fair Queuing) ,
también conocido como PGPS. Existen importantes diferencias entre los servicios ofrecidos por
el sistema de paquetes WFQ y el sistema fluido GPS.
GPS es una disciplina de los servicios de los paquetes en los puntos de encolado de la red.
GPS es una forma especial de procesador head-of-line compartiendo disciplinas de servicio PS
(Processor Sharing). Con PS tenemos una cola FIFO separada para cada sesión que comparte el
mismo enlace. Durante un intervalo de tiempo, cuando hay exactamente N colas no vacías cada
una de ellas asociada a un servicio compartido, el servidor GPS sirve los N paquetes de las
cabeceras de las colas simultáneamente, cada uno a una velocidad de N veces la velocidad del
enlace. Mientras un servidor PS sirve todas las colas no vacías a la misma velocidad, GPS
permite a diferentes sesiones tener diferentes servicios compartidos y sirve las colas no vacías en
proporción al servicio compartido de las correspondientes sesiones.
31
Simulador de Tráfico ATM con Garantía de Servicio
Un servidos GPS, sirviendo N sesiones, se caracteriza por N números reales positivos
φ 1, φ 2,..., φ N. Estos valores indican el tamaño relativo de servicio para cada sesión. El servidor
trabaja a una velocidad fija r y es work-conserving.
Hay que destacar que GPS es un servidor ideal que no transmite paquetes como
entidades. Esto asume que el servidor puede servir todas las sesiones pendientes simultáneamente
y que el tráfico es infinitamente divisible. En la realidad sólo una sesión puede recibir un servicio
en un instante, y un paquete entero debe ser servido antes de servir otro. En la figura 6.1 se
representa un diagrama de tiempos de la llegada y transferencia de paquetes pertenecientes a la
sesión i en un sistema GPS.
Figura 6.1 Diagrama de tiempos de llegada y salida de paquetes en la disciplina de servicio GPS
Una de las líneas de trabajo de GPS está centrada en el diseño de algoritmos de control de
congestión basados en realimentación para ser usados en redes de datagramas. Así, en este caso
las fuentes muestrean constantemente el estado de la red para detectar síntomas de congestión y,
cuando los detectan, las fuentes reducen la velocidad de envío para aliviar el efecto de la
congestión. En el caso de que todas las fuentes empleen la misma cola FIFO para el envío de su
tráfico, si una de las fuentes no reacciona al control de congestión, nos encontraremos con el
hecho de que todas las sesiones acabarán sufriendo el problema de congestión. Para evitar este
problema se propuso emplear una cola FIFO separada para cada sesión y atender las colas
existentes en una política Round-Robin. Este esquema se comporta mejor que un FIFO puro, pero
en el caso que existan fuentes con distintos tamaños de paquetes, puede ocurrir que las que
generen paquetes más grandes acaben consiguiendo más ancho de banda que las que los generan
más pequeños. Destacamos que la disciplina de servicio PS, descrita antes, este problema no
aparece porque las sesiones en espera reciben el mismo ancho de banda independientemente del
tamaño de los paquetes.
El algoritmo GPS tiene por tanto una serie de interesantes propiedades para las redes de
servicios integrados como ATM y, de hecho, se han propuesto muy diversos algoritmos PFQ
(Packet Fair Queuing) para aproximar GPS a alas redes de conmutación de paquetes, aunque no
demasiadas para las de tecnolgía ATM. El coste de implementación de los algoritmos PFQ está
influido por dos aspectos:
1) Cálculo de la función de tiempo virtual del sistema que es una medida dinámica del
tamaño de servicio justo normalizado que debe recibir cada sesión. La mayor parte
de los algoritmos PFQ propuestos se mueven entre costes O(1) y O(logN) en cuanto a
complejidad de la función de tiempo vitual.
32
Simulador de Tráfico ATM con Garantía de Servicio
2) El coste del mantenimiento del orden relativo de los paquetes a través de su marca de
tiempos en un mecanismo basado en colas con prioridad desde donde se transfieren
los paquetes. La complejidad algorítmica de implementación de una cola con
prioridad para N números arbitrarios es O(logN). Pueden conseguirse menores costes,
pero son de difícil implementación en redes de alta velocidad. Las colas con prioridad
en PFQ pueden basarse en tiempo virtual de inicio, en el de finalización, o en ambos.
Como cualquiera de estos tiempos crece monótamente con cada sesión, solo
necesitamos considerar las cabeceras de cada sesión cuando el servidor está tomando
el siguiente paquete a ser transferido. Así, el número de entidades en la cola con
prioridad coincide con el número de sesiones activas.
Existen bastantes aproximaciones de algoritmos PFQ que procesan paquetes basados en
GPS, pero todos usan un mecanismo similar de colas con prioridad, basados en la noción de
tiempo virtual. Las propuestas se diferencian en la elección de la función de tiempo virtual y en la
selección de la política de paquetes.
Para poder aproximarse a GPS, los algoritmos PFQ mantienen una función de tiempo
virtual V(.), un tiempo de inicio virtual Ii(.), y un tiempo de finalización virtual Fi(.) para cada una
de las i sesiones. En el caso de las redes ATM es lógico representar el tiempo virtual en términos
de la cantidad de células servidas.
En la mayor parte de los casos de PFQ, cuando el servidor está eligiendo el siguiente
paquete para transmitir, los algoritmos optan, de entre todos los paquetes del sistema, por aquel
que tenga el tiempo final virtual más pequeño, es decir, se aplica una política de selección de
paquetes “primero los tiempos virtuales más pequeños” (SFF). Esta política de selección de
paquetes suele dar lugar a límites de retardo casi idénticos a los del sistema fluido GPS, sin
embargo, acaba dando lugar a mayores tiempos de servicio que GPS.
Otra de las líneas más importantes de GPS está en la forma de ofrecer servicios con
garantía de retardo limitado en redes de conmutación de paquetes. El esquema PGPS (Packet
Generalized Processor Sharing) , bajo el nombre de WFQ (Weighted Fair Queuing) es el
algoritmo PFQ más conocido. La disciplina de servicio de PGPS se centra en el tratamiento
igualitario de todos los usuarios y, a partir de estos planteamientos, han surgido posteriormente
nuevas investigaciones que han dado lugar a variantes extendidas de PGPS.
Aunque WFQ es el algoritmo más conocido y reconocido como mecanismo de
planificación ideal en términos de sus propiedades combinadas de límite de retardo y
proporcionalidad de justicia, varios trabajos demuestran que la complejidad asintótica del
algoritmo crece linealmente con el número de sesiones atendidas por el planificador, lo que limita
su uso en aplicaciones de elevada velocidad. De este modo, se proponen 2 algoritmos de
complejidad constante O(1) en gestión de marcas de tiempos (pesos) y además, conservan los
mismo valores de retardo extremo-a-extremo y tamaños de buffers de WFQ. El primer algoritmo
FFQ (Frame-based Fair Queuing) emplea un mecanismo de tramas para recalibrar periódicamente
una variable global rastreando la evolución de los trabajos en el sistema y limitando la injusticia
en peridos cortos de tiempo determinados por el tiempo de las tramas. El segundo algoritmo
SPFQ (Starting Potential-based Fair Queuing) realiza la recalibración en el límite de los paquetes.
Aunque existen numerosas alternativas, este proyecto no abarca el estudio de éstos.
33
Simulador de Tráfico ATM con Garantía de Servicio
6.3. Propuesta QPWFQ para TAP
Comparando las diferentes propuestas, podemos decir que WFQ, también denominado
PGPS, aporta interesantes prestaciones en cuanto a retardo y justicia, sin embargo, su coste
computacional y complejidad de implementación han impedido su implantación.
Para este proyecto, hacemos uso del algoritmo QPWFQ (Queue PDU Wigthed Fair
Queuing) inspirado en QLWFQ (que se explicará a continuación), para conseguir aportar un
tratamiento justo a las PDU que llegan a los conmutadores AcTMs. Dado que debemos dar un
tratamiento privilegiado a las PDU pertenecientes a las conexiones con GoS, el mecanismo de
pesos de colas es de suma utilidad para nosotros. Además, nos encontramos con otra
particularidad no tratada por ninguno de los algoritmos estudiados que es el hecho de tener que
dar respuesta a las retransmisiones de PDUs congestionadas. Esto nos va a determinar el tener
que incluir en el algoritmo QPWFQ un tratamiento prioritario para las retransmisiones.
6.3.1. QLWFQ
La literatura presenta diversas variantes mejoradas sobre las propuestas anteriores. Para
nuestro proyecto queremos centrarnos en una de estas propuesta, QLWFQ (Queue Length based
WFQ), que es un algoritmo work-conserving de coste constante O(1) para la planificación de
colas per-VC en redes de conmutación de paquetes de longitud fija como ATM. QLWFQ es
compatible con FQ y FIFO y se basa en la asignación de pesos a las colas y en el establecimiento
de créditos para determinar el orden de atención de las células ATM en función de la
comparación de la longitud de cada cola con su peso particular.
El algoritmo compara, a la llegada y partida de las células, la longitud de las colas con los
pesos que cada una tiene asignados. QLWFQ es en realidad una simplificación de WRR
(Weighted Round Robin) consiguiendo un mejor equilibrio entre aislamiento de tráfico y
compartición de recursos que los algoritmos basados en marcas de tiempos.
6.3.2. QPWFQ
A continuación vamos a describir el funcionamiento general del algoritmo QPWFQ y, a
un tiempo, comentaremos el mecanismo aplicado a las colas de entrada de los conmutadores
AcTMs para demostrar justicia del mismo, así como su sencillez de implementación que acaba
resultando en un constante O(1). Igualmente, veremos que QPWFQ procesa, tanto células como
PDUs, y describiremos la sencilla técnica usada para mantener las características work
conserving de WFQ, así como la posibilidad de tratamiento prioritario de las solicitudes de
retransmisiones de PDUs pertenecientes a las conexiones garantizadas.
Como puede observarse en la figura 6.2 , tenemos 3 colas de espera, cada una de ellas con
su correspondiente peso p. En nuestro caso la Cola 1 tiene peso 3, la cola 2 peso 2 y la Cola 3
peso 1. Las posiciones de cada cola pueden almacenar, tanto PDU como células para ser
procesadas hasta el buffer del conmutador. Cuando una PDU, o una célula, llega a una cola, la
34
Simulador de Tráfico ATM con Garantía de Servicio
longitud l de esta cola es incrementada en una unidad y es introducido el número de cola en la
cola de turnos siempre que l<=p.
Cuando la cabecera de una cola de espera es servida, la longitud de esta cola es
decrementada en una unidad y se comprueba si l>=p para seguir atendiéndola, siempre y cuando
en las restantes colas no se cumpla l<=p. De este modo se garantiza la característica workconserving (el servicio no se detiene mientras exista tráfico que procesar), que permite atender
colas con tráfico continuado siempre y cuando en las restantes tráficos no exista tráfico.
En la figura 6.2 se supone que en el instante 0 en la cola 1 había una PDU, la cola 2
estaba vacía y en la cola 3 existía otra PDU. Así, la longitud de la cola 1 se incrementa en una
unidad, y en la cola de turnos se ha insertado el crédito 1 (suponiendo que atendemos las colas
circularmente y de forma ascendente) ya que su peso es 3 y la longitud de la cola en ese instante
es 1 (l<=p). Posteriormente es tratada la cola 3, su longitud es incrementada en 1, y se anota su
turno en la cola de turnos ya que su peso es 1, lo mismo que su longitud (l<=p) .Si suponemos
mantenernos en esta situación sin servir las cabeceras de las colas 1 y 3 a la salida, y en ese
momento llegan tres nuevas unidades a la cola 1, éstas serán atendidas de forma continuada por la
característica work-conserving, ya que a las colas 2 y 3 no llega tráfico. De este modo se atienden
dos nuevas entradas de la cola 1 pero al ser atendida la tercera llega una célula a la cola 2 que
pone su longitud a 1 y es pasado su turno a la cola de turnos ya que l=1 <= p=2.
Ahora veremos ¿cómo es el procedimiento de salida de las células o PDUs de las colas de
entrada?. En la cabecera de la cola de turnos hay una indicación acerca de la cola que debe ser
tratada en cada momento. Según la figura 6.2 la cola que hay que atender es la 1 (según la cola
de turnos). Al tratar la cola 1, se envía su cabecera al buffer y se decrementa la longitud de esta
cola en una unidad. A continuación se eliminan las cabeceras de la cola de turnos y de la cola 1 y
se procede a calcular primero si l<=p y después si l>=p.
En la figura de ejemplo (figura 6.2) se supone que no llegan PDUs pertenecientes a
retransmisiones de conexiones privilegiadas. Si ocurriese la llegada de una PDU de este tipo, el
agente WFQA le daría un tratamiento prioritario.
35
Simulador de Tráfico ATM con Garantía de Servicio
Figura 6.2 Esquema de planifiación del algoritmo QPWFQ.
El WFQA tendrá conocimiento de la inminente llegada de una PDU retransmitida a
través de la comunicación del agente RCA que le indica el índice VPI/VCI/PDUid/Port. Esta
comunicación activa una nueva variable asociada a cada cola para saber que va a llegar una
retransmisión. Cuando llega la PDU es introducida en su correspondiente cola y es apuntada para
garantizar el acceso directo. De este modo, las colas de espera pueden servir células y PDU, no
sólo desde las cabeceras, sino también desde los punteros que identifican las PDU retransmitidas.
Así, las colas FIFO, implementadas con punteros, permitirán priorizar las PDU retransmitidas
que, a medida que van llegando, son insertadas, no al final de las colas, sino al principio de las
mismas con la intención de garantizar el coste constante.
Para realizar las priorizaciones, se debe realizar también un tratamiento sobre la cola de
turnos, ya que, se debe insertar en su cabecera la indicación de la cola con la PDU que es
retransmisión de una conexión privilegiada.
Aunque las colas pueden contener células nativas ATM y PDU privilegiadas y,
aparentemente esto puede conducir a situaciones injustas en las células respecto a las PDU, la
estrategia aplicada, basada en los pesos y las longitudes de las colas, permite que no se produzcan
situaciones de inanición de paquetes pequeños respecto a los de mayor tamaño.
36
Simulador de Tráfico ATM con Garantía de Servicio
7. Mecanismos de control de
congestión
Los esquemas de control de congestión más conocidos son RCD (Random Cell Discard),
PPD (Partial Packet iscard) y EPD (Early Packet Discard). Avanzamos ya que el esquema EPD
se ha demostrado como una solución interesante para conseguir óptimo funcionamiento desde el
punto de vista de la justicia y utilización de los enlaces. Sin embargo, existen otros esquemas con
idénticos objetivos que son maximizar el throughput y la justicia, mientras se minimiza el retardo
en las redes ATM. Algunos de estos mecanismos son: ESPD (Early Selective Packet Discard) ,
FBA (Fair Buffer Allocation) y RED (Random Early Detection).
Para TAP, se ha introducido y modificado una variación de EPD en TAP de forma que,
cuando una de las PDU llega al buffer, esperamos a la célula final de cada PDU para aplicar EPD
en los conmutadores AcTMs, desechando aquellas PDU que provoquen congestión en el buffer y
solicitando su retransmisión mediante NACKs al conmutador previo. Las PDU que no provocan
congestión en el buffer son enviadas a los puertos de salida de forma completa aplicando VC
merge para aliviar también los problemas de interleaving.
Cuando se llena el buffer de un conmutador congestionado, las células que llegan serán
descartadas y, con una elevada probabilidad, muchos paquetes perderán células y mientras otras
células seguirán su transmisión a través de la red, provocando el indeseable fenómeno que de la
fragmentación de paquetes. Al evitar la fragmentación estamos optimizando el ancho de banda de
los enlaces de la red que no se ven sobrecargados con las retransmisiones extremo-extremo, ni
con la transmisión de PDU completas que pueden estar corruptas por la pérdida de una sola de
sus células.
En esta sección del proyecto explicaremos el mecanismo EPD para, a continuación,
explicar la modificación que se ha implantado, basado en EPD (EPDR).
7.1. Antecedentes, mecanismo EPD
El mecanismo EPD (Early Packet Discard), es una técnica de gestión de buffers
implementada para asegurar un elevado throughput extremo a extremo. Este mecanismo realiza
descartes de paquetes completos, en lugar de descartes parciales como hacen otros. EPD tirará los
paquetes completos antes de que el buffer acabe llenándose, con la intención de que los paquetes
que puedan ser susceptibles de perder alguna célula, y por tanto su integridad, no sean
transmitidos por la red.
Con EPD, en lugar de tirar células (o PDUs) de varias conexiones cuando el buffer se
llena, este mecanismo opta por tirar una PDU completa antes de llenar el buffer. De este modo,
también se evita fragmentación y se evita que paquetes corruptos se transmitan.
37
Simulador de Tráfico ATM con Garantía de Servicio
Veremos ahora la simplicidad de este algoritmo para comprobar que su implementación
es perfectamente asumible desde el punto de vista de la justicia y el goodput conseguidos. Para
poder aplicar EPD, en los conmutadores, hay que establecer un umbral en los buffers a fin de
marcar el llenado del buffer. Cuando este umbral es alcanzado, no se admitirá la entrada de más
paquetes. Es decir, cuando llega la primera célula de un paquete a un buffer que está lleno hasta, o
por encima de, su valor umbral, esa célula es desechada, y también todas las demás células
pertenecientes a ese paquete, aunque la cola descienda inmediatamente su nivel de llenado por
debajo del umbral. Por otro lado, las células de un paquete cuya primera célula llegó antes de que
el buffer alcanzase el umbral no serán tiradas a no ser que el buffer acabe llenándose. En suma,
cuando la primera célula de un paquete llega en un margen de llenado elevado del buffer, es
descartada junto a todas las demás que pertenecen a su mismo paquete, ante el riesgo de
provocarse la fragmentación del paquete.
Lo importante de este método es escoger el valor del umbral para evitar el llenado del
buffer con el consiguiente problema de fragmentación. Pero, además de la fragmentación,
debemos encontrar el equilibrio que también evite el exceso de descartes de células y , por lo
tanto, el número de retransmisiones. Entonces, si el umbral es demasiado alto, este mecanismo no
servirá para nada y si es excesivamente bajo se tirarán un número excesivo de paquetes.
En las siguientes figuras, se puede observar el funcionamiento de este mecanismo.
TAC=Tamaño_actual_de_la_cola
CMB=Capacidad_máxima_del_buffer_del_conmutador
Mientras una célula está llegando a un conmutador;
Si la célula es la primera célula de un paquete
Si TAC >= Umbral
En otro caso
Aceptar la célula en cola FIFO
FinSi
En otro caso
Si ya se ha tirado alguna célula de este paquete
Tirar la célula
En otro caso
Si TAC >= CMB
Tirar la célula
En otro caso
Aceptar la célula en cola FIFO
FinSi
FinSi
FinSi
FinMientras
Figura 7.1 Algoritmo EPD
38
Simulador de Tráfico ATM con Garantía de Servicio
Figura 7.2 Representación gráfica de EPD procesando PDUs AAL-5
El algoritmo EPD puede tener otros planteamientos o versiones, pero el problema general
es el mismo. Una de estas versiones es la que aplicamos en este proyecto, el mecanismo EPDR.
7.2. Propuesta EPDR
En este proyecto el esquema de control de buffer que empleamos es un mecanismo
basado en EPD. Este mecanismo recibe el nombre de Early PDU Discard and Relay (EPDR).
Este mecanismo:
Incluye un mecanismo de retransmisión cuando se detectan PDU que van a provocar
desbordamiento del buffer. Cuando se detecta el llenado del buffer, comienza el descarte
de células y, automáticamente se solicita una retransmisión al conmutador previo. Esta
propuesta permite la retransmisión de forma local, evitando retransmisiones extremo a
extremo, y así, mejorando el goodput. Las retransmisiones sólo se solicitan en el caso que
la fuente tenga suficiente tiempo de inactividad para atenderlas sin afectar a la
transmisión en curso. Esta propuesta ahorra, en el peor de los casos, el tiempo RTT
extremo a extremo (y ahorra el proceso de solicitud de retransmisión de protocolos
superiores como TCP). Y lo que es más importante, la implosión en los emisores de
tráfico es solventada por la delegación realizada en los conmutadores AcTMs que
soportan la arquitectura TAP.
 El problema de la fragmentación de PDUs se solventa empleando el campo EOM de las
tramas EAAL-5, que es, otra propuesta de este proyecto.

39
Simulador de Tráfico ATM con Garantía de Servicio
 El buffer es controlado por un agente programable que permite la coordinación con otros
agentes del sistema para ajustar los umbrales más convenientemente en función del
estado del conmutador.
 El coste algorítmico es similar a otros esquemas de este tipo. Los requisitos hardware
para su implementación no son extraordinarios.
En la figura 7.3 se muestra el algoritmo EPDR. Se puede observar la introducción
(respecto al algoritmo EPD) de una llamada a la función Retransmitir (indexPDU). El umbral lo
determina el agente CCA aunque, en la implementación del simulador, este valor se introduce
manualmente. Como podemos comprobar en el algoritmo, en cuanto la longitud actual de la cola
iguala el valor del umbral, el conmutador se dispondrá a tirar todas las células de la PDU que ha
provocado la situación. Cuando llega la primera célula de una PDU y ya se ha igualado el umbral,
se tira esa célula y se marca el VPI/VCI de la célula en la lista-descartes para, a continuación,
tirar todas las células de esa misma PDU hasta llegar a su última célula (EOM). Este es el modo
en que se garantiza que no se produzca la fragmentación de la PDU, impidiendo que no se envíe
ninguna célula de una PDU que ha provocado una situación de congestión. Una vez ha llegado la
última célula de la PDU congestionada, y puede accederse al campo PDUid, se solicita la
retransmisión de la PDU a través del agente RCA. Una vez solicitada la retransmisión de la
PDU se procede a eliminar el valor VPI/VCI de la lista-descartes para que la siguiente PDU de
esa misa conexión pueda ser aceptada en el buffer si ya ha pasado la situación de congestión.
La célula EOM de la trama descartada se introduce en el buffer (si hay espacio), ya que
esta célula, la emplea EAAL-5 para delimitar las diferentes PDUs. Con esta célula EOM se sabe
cuando acaba una trama descartada. Este mecanismo, al igual que el EPD, no evita la
fragmentación una vez que las células iniciales han entrado en el buffer y éste se ha llenado. Y,
como ocurría en el algoritmo EPD, la fragmentación depende del valor del umbral establecido en
el buffer del conmutador. Este valor del umbral debería ser unas 3 o 4 veces menor que el tamaño
medio de una PDU. Aunque las células iniciales hayan podido entrar en el buffer, el resto de
células serán automáticamente descartadas al saber que la trama está corrompida.
Mientras una célula llega al buffer
Si el VPI/VCI de la célula pertenece a la lista-descartes
Si la célula es una célula EOM
Si Longitud_de_Cola < Tamaño_Buffer
insertar la célula en el buffer
En otro caso
tirar la célula
FinSi
Retransmitir(indexPDU)
borrar el VPI/VCI de la lista-descartes
FinSi
En otro caso
tirar la célula
FinSi
En otro caso
Si Longitud_de_Cola < umbral
insertar la célula en el buffer
40
Simulador de Tráfico ATM con Garantía de Servicio
En otro caso
Si (primera célula de PDU o (el buffer está lleno))
tirar la célula
capturar el VPI/VCI en la lista-descartes
FinSi
En otro caso
insertar la célula en el buffer
FinSi
FinSi
FinMientras
Figura 7.3 Esquema de planificación del algoritmo EPDR
En la figura 7.4 se representa el funcionamiento del EPDR. Podemos observar el punto de
llegada del tráfico de entrada, así como los límites de los valores de la Conexión actual de cola
(LAC), el valor umbral (U), y el valor de tamaño máximo del buffer (TMB). También se muestra
la conexión existente entre el buffer y el agente WFQA, CCA, RCA y DPA, así como la conexión
del buffer con la memoria DMTE en la que se realizan las copias de las PDUs que han llegado
completas al buffer.
Figura 7.4 Esquema gráfico del buffer
41
Simulador de Tráfico ATM con Garantía de Servicio
BASES DE LA SIMULACIÓN
8. Introducción
En este módulo se expone un estudio de los mecanismos y procesos que intervienen en
las redes ATM reales. Esto es necesario ya que, como es natural, hay que conocer profundamente
la realidad que se pretende simular antes de intentar simularla. En nuestro caso, nuestro proyecto
se centrará en conseguir un tráfico lo suficientemente real como para poder estudiar las ventajas
de la implantación de TAP en las redes ATM. Por ello habrá ciertos aspectos de ATM que no
serán necesario simular, ya sea porque no intervienen en TAP o porque su inclusión oscurecería
el análisis de los resultados obtenidos. En este módulo, por tanto, procuraremos explicar qué está
simulado, qué está simplificado, qué ha cambiado y qué se ha omitido y qué se ha añadido en
nuestro simulador con respecto a una red ATM real.
9. Funciones y algoritmos de gestión
de conexiones
9.1. Funciones y algoritmos de gestión de
conexiones en las redes ATM reales.
En esta sección vamos a describir primeramente el proceso real en las redes ATM
mediante el cual se negocian, establecen y liberan las conexiones en las interfaces UNI y NNI.
Posteriormente presentaremos el método de establecimiento de conexiones en nuestro simulador
junto con aquellas estructuras y mensajes (tablas de enrutamiento, mensajes de
establecimiento/cierre de la conexión, etc.) que serán utilizados.
9.1.1. Señalización
Como ATM es un servicio orientado a conexión se necesitan protocolos específicos de
señalización, estructuras de enrutamiento así como protocolos que encaminen las peticiones de
conexión ATM a través de la red ATM. Las siguientes secciones describen el papel de la
señalización en una red ATM.
Como comentamos en el módulo I, los servicios orientados a la conexión de ATM se
implementan usando conexiones virtuales permanentes (PVCs) o conexiones virtuales
conmutadas (SVCs). En el caso de las PVC, el valor del par VPI/VCI en cada punto de
42
Simulador de Tráfico ATM con Garantía de Servicio
conmutación de la conexión se debe configurar manualmente y permanece activo de manera
permanente. Debido a que estos circuitos requieren una labor intensiva de configuración no son
muy escalables y no son una buena solución para las conexiones poco frecuentes o de corta
duración.
Los SVCs son la solución para los requerimientos de las conexiones bajo demanda. Son
establecidos cuando son necesarios y desactivados cuando ya no lo son, liberando así ancho de
banda en la red. Para lograr esta conducta dinámica los SVCs usan señalización: Para que dos
elementos finales obtengan una conexión es necesario que ambas sigan un criterio común, esto es,
dispongan de un protocolo de señalización común. En los SVC el sistema de señalización de
ATM se encarga de encontrar la ruta adecuada desde el host origen al host destino a lo largo de
varios switches. El host remoto debe aceptar el establecimiento de la conexión.
Además de los PVCs y los SVCs hay un tercer tipo híbrido de ambos llamado PVCs
ligeros. Estas conexiones son permanentes pero, como son establecidas mediante señalización,
pueden ser configuradas fácilmente y re-enrutadas automáticamente si falla uno de los enlaces
que la componen.
9.1.1.1. Establecimiento de la conexión y señalización
Hay varias maneras de establecer una conexión. La normal es adquirir primero un
circuito virtual con el conmutador inmediatamente adyacente para la señalización, y usarlo. Para
establecer tal circuito, como veremos más adelante según la interface UNI, las células que
contienen una solicitud se envían por el VPI 0/VCI 5. Si hay éxito, se abre un circuito virtual
nuevo por el se pueden enviar y recibir solicitudes y respuestas de establecimiento de conexión.
En la figura a se muestra cómo el router A (origen) establece una comunicación con el
router B (destino) usando señalización con un circuito virtual ya previamente establecido para
este propósito.
Figura 9.1 Ejemplo de conexión
Los pasos del proceso son los siguientes:
1- El Router A envía un paquete con un mensaje SETUP al conmutador directamente
conectado a él (conmutador ATM 1). Esta petición contiene la dirección ATM de ambos
extremos origen y destino así como las características demandadas para la conexión.
2- El conmutador ATM 1 reensambla el paquete del router A y lo examina. Responde al
Router A con un mensaje de establecimiento.
3- Si el conmutador ATM 1 tiene una entrada para el router B en su tabla de conmutación y
43
Simulador de Tráfico ATM con Garantía de Servicio
puede acomodar la QoS demandada por la conexión, entonces reserva recursos para la
conexión virtual y reenvía la petición hacia el siguiente conmutador (conmutador ATM
2) a través de una trayectoria dada.
4- Cada conmutador a lo largo del camino hacia el router B reensambla y examina el
paquete de señalización y posteriormente lo reenvía al siguiente conmutador tan sólo si
puede soportar los parámetros de tráfico en las interfaces de entrada y de salida. A
medida que el mensaje de establecimiento se propaga hacia el destino, es reconocido en
cada salto por un mensaje de llamada en proceso. Cuando ser remite el paquete cada
conmutador establece también las conexiones virtuales. Si cualquier conmutador a lo
largo de la trayectoria no puede satisfacer las demandas de tráfico la petición se rechaza y
se envía de vuelta al router A un mensaje de conexión rechazada.
5- Cuando el paquete de señalización legua al router B, éste lo reensambla y evalúa. Si
puede soportar las demandas entonces responde con el mensaje de aceptación de
conexión que será respondido por cada elemento por el que pase por uno de conexión
reconocida. Cuando el mensaje de aceptación llega de vuelta al router A se completa la
conexión virtual. Posteriormente los datos serán transmitidos a lo largo del mismo
camino por el que ha discurrido la señalización.
Cuando llega el momento de cortar la conexión se utiliza otra secuencia de señalización:
1- La parte que desea cortar envía un mensaje de liberación a la red ATM
2- En cada salto a lo largo del camino se reconoce el mensaje con uno de liberación
completada.
3- La red ATM propaga el mensaje de liberación al otro extremo y termina el proceso de
liberación; la conexión se considera así liberada.
Protocolos de Señalización ATM--- UNI y NNI
Los protocolos de señalización varían dependiendo de la interface de red ATM:
•Señalización en el Interface Usuario-Red (UNI): Se usa entre los sistemas finales y los
conmutadores ATM a través de enlaces UNI. También puede usarse entre dos conmutadores
ATM.
•Señalización en el Interface Red-Red (NNI): Se usa entre conmutadores ATM mediante
enlaces NNI.
La señalización UNI en ATM define el protocolo mediante el cual los SVCs se
establecen dinámicamente entre los dispositivos ATM de la red. La señalización NNI es parte de
la especificación PNNI que incluye además un protocolo de enrutamiento propio.
EL ATM Forum tiene la tarea de estandarizar los procedimientos de señalización. Las
especificaciones para UNI del ATM Forum están basadas en el protocolo llamado Q.2931 del
ITU-T. Este protocolo especifica un formato para los mensajes de control de llamada que
contiene información como el tipo de mensaje (establecimiento, liberación y otros) y más
elementos de información como el formato de enrutamiento y la QoS.
Las especificaciones UNI están agrupadas de la siguiente forma:
•UNI 3.x -- Consistente en dos conjuntos de especificaciones interoperativas, la UNI 3.0 y la UNI
3.1.
•UNI 4.0 -- Incluye las especificaciones UNI 3.x y añade algunas características no soportadas
44
Simulador de Tráfico ATM con Garantía de Servicio
por aquella. Entre estas características destacan la señalización para conexiones ABR y el PNNI
que especifica los protocolos de enrutamiento y señalización a través del NNI.
•
Los mensajes de control más significativos especificados en la UNI 3.1 son los
siguientes:
•Para conexiones p-p
- SETUP: petición de establecimiento de circuito.
- CALL PROCEEDING: respuesta a la anterior.
- CONECT: aceptación de conexión.
- CONNECT ACKNOWLEDGE: confirmación de la anterior.
- RELEASE: petición de liberación de la conexión.
- RELEASE COMPLETE: aceptación de la anterior.
•Para conexiones p-mp
- ADD PARTY: añade un destino a la conexión.
- ADD PARTY ACKNOWLEDGE: confirmación de la anterior.
- ADD PARTY REJECT: rechazo.
- DROP PARY: elimina un destino de la conexión.
- ADD PARTY ACKNOWLEDGE: confirmación de la anterior.
Todos estos mensajes los construye la capa AAL y como media cada uno de ellos se
descompondrá en al rededor de 30 células.
9.1.2. Direccionamiento
Las direcciones ATM son necesarias para los propósitos de la señalización cuando se
establecen conexiones conmutadas. Existen tres formatos de direcciones ATM diferentes
dependiendo del estándar de enrutamiento utilizado (OSI, CCITT). Sin embargo este aspecto (el
formato y distribución de las direcciones) queda fuera del ámbito de nuestro simulador ya que no
aporta nada a su propósito principal, es de comprobar las características de funcionamiento de la
arquitectura TAP. Como veremos posteriormente, el protocolo que hemos elegido para el
enrutamiento no necesita de direccionamientos jerárquicos lo que también justifica en cierta
medida nuestra decisión.
9.1.3. Enrutamiento
Existen dos protocolos de enrutamiento ATM: el "Interim Interswitch Signaling
Protocol" (IISP) y el "Private Network-Node Interface" (PNNI). IISP proporciona soluciones de
enrutamiento estático no fácilmente escalables y no aporta soporte para calidad de servicio (QoS).
PNNI proporciona una solución de enrutamiento escalable que determina dinámicamente los
caminos de enrutamiento y además soporta los requerimientos de QoS.
45
Simulador de Tráfico ATM con Garantía de Servicio
9.1.3.1. Enrutamiento estático con IISP
Como su propio nombre indica, el "Protocolo Interino de Señalización entre
Conmutadores" (IISP) es un protocolo de señalización para comunicaciones entre conmutadores.
IISP fue una medida temporal diseñada para permitir interconexión entre conmutadores usando
señalización basada en UNI hasta que la implementación del NNI, en la que está basada el
protocolo PNNI, estuviera finalizada.
Aunque menos poderoso y complejo que PNNI, IISP todavía se usa hoy en día para
permitir la compatibilidad con conmutadores primitivos que no soportaban el protocolo PNNI.
IISP también puede ser usado para aislar la distribución de información PNNI en situaciones de
diseño de red específicas.
Para permitir la señalización UNI, los conmutadores arbitrariamente toman el papel de
usuario (U) o red (N) en cada extremo de un enlace IISP. Las peticiones de señalización son
encaminadas entre conmutadores usando tablas de enrutamiento preconfiguradas en cada
conmutador. Estas tablas se configuran con las direcciones de los elementos a los que se puede
acceder a través de cada puerto del conmutador. Cuando un conmutador recibe una petición de
señalización, éste comprueba la dirección ATM destinataria en su tabla y obtiene el puerto por el
que deberá salir esta petición. Posteriormente redirige la petición de señalización a través del
puerto obtenido usando los procedimientos UNI.
El enrutamiento usando IISP requiere configuración manual de las tablas de
enrutamiento. Para un número pequeño de caminos posibles es una tarea relativamente simple,
pero en grandes redes la configuración requiere mucho tiempo y es propicia a errores.
Ventajas:
Algunas de las ventajas ofrecidas por IISP son las siguientes:
•Simple de configurar y de encontrar errores en redes pequeñas.
•Soportado por una la mayoría de los proveedores
•Puede usarse para conectar redes privadas ejecutando diferentes implementaciones
propietarias del PNNI
Inconvenientes
Las limitaciones potenciales del IISP son las siguientes:
•Configuración estática de enrutamientos.
•No muy escalable debido a la configuración manual de las tablas de enrutamiento.
•El cálculo de la ruta debe hacerse salto a salto. Cada conmutador debe elegir la el puerto de
salida para cada mensaje.
•Soporte limitado para QoS.
•No hay redireccionamiento "crankback" en caso de errores en la red. Sin embargo se pueden
configurar trayectorias redundantes.
46
Simulador de Tráfico ATM con Garantía de Servicio
9.1.3.2. Señalización y enrutamiento PNNI
El protocolo PNNI provee de mecanismos escalables de enrutamiento basados en la QoS
de ATM y VCCs conmutador-a-conmutador interoperables. Para conseguir esto la especificación
PNNI actúa en dos vertientes, señalización y enrutamiento.
9.1.3.2.1. Rasgos de la señalización PNNI
La señalización PNNI es una extensión de la señalización UNI para su uso en enlaces
NNI. La peticiones de señalización UNI, transportadas en el mismo canal virtual (VCI = 5), son
mapeadas en señalización NNI en el primer conmutador origen de una comunicación. La
señalización NNI es remapeada de nuevo a señalización UNI en el último conmutador destino.
Entre los rasgos característicos de la señalización PNNI se encuentran los siguientes:
•soporta UNI 3.1-incluyendo conexiones p-p y p-mp
•soporta UNI 4.0-con las siguientes capacidades:
•parámetros individuales de QoS
•señalización ABR
•Negociación de parámetros de tráfico
•CoS
•ATM anycast
9.1.3.2.2. Rasgos del enrutamiento PNNI
El componente de enrutamiento del protocolo PNNI especifica cómo las peticiones de
señalización y sus subsecuentes conexiones de datos se enrutan a través de una red ATM.
Entre los rasgos característicos del enrutamiento PNNI se encuentran los siguientes:
•Protocolo con conocimiento de la topología mediante mensajes intercambiados por los
elementos de la red a través de mecanismos de inundación.
•Configuración automática.
•Encaminamiento dinámico. Reacciona al estado de la topología.
•"Source routing". El conmutador ATM origen de una comunicación calcula por completo la
ruta en el establecimiento de conexiones a partir de su conocimiento de la topología actual.
Esta ruta la comunica a los demás conmutadores de la trayectoria elegida incluyéndola en el
mensaje de establecimiento por lo que éstos no deberán recalcularse.
•Selección de la ruta que satisfaga los parámetros de QoS requeridos por la conexión.
•Soporta redes PNNI jerárquicas.
• Soporta "crankback".
47
Simulador de Tráfico ATM con Garantía de Servicio
9.1.4. CAC “Connection Admission Control”
Hasta este momento hemos visto cuál es el proceso de establecimiento de una conexión,
los mensajes se intercambian los elementos que intervienen en el este proceso y las diversas
formas de elección de la ruta para dicha conexión. Sin embargo aún no hemos expuesto qué
mecanismo es el que se encarga de aceptar o rechazar una nueva conexión. Este mecanismo es el
CAC "connection admission control". Por lo tanto la función del CAC es la de decidir si podemos
incluir una nueva conexión sobre la base de los recursos que demanda el usuario y los que
tenemos disponibles. Se utiliza, pues, como mecanismo preventivo de control de congestión.
El CAC se halla implementado en los nodos de conmutación de la red ATM. Como
hemos descrito anteriormente, cuando un terminal m1 empieza una conexión contra otro terminal
m2 , m1 debe enviar un pedido de conexión (ESTABLECIMIENTO), al controlador de tráfico
del nodo ATM. El pedido de conexión indicará información tal como el ID del destino, el QoS
requerido y los parámetros de tráfico que definen las características de generación de la conexión.
El nodo ATM estima el QoS de los parámetros de tráfico y permite que m1 establezca la
conexión sólo cuando esta nueva conexión no degrade el QoS de ningún terminal.
Los algoritmos que realizan el control de admisión no están especificados en ningún
estándar. En lugar de ello se deja al fabricante implementar el mecanismo que crea oportuno de
acuerdo con el producto que quiera ofrecer. A continuación mencionaremos una clasificación de
tipos de algoritmos CAC creados hasta el momento.
9.1.4.1. Asignación no estadística “Peak Bandwidth Allocation”
En este tipo de algoritmos la nueva conexión se acepta si la suma de todas las tasas de
pico más la tasa de pico de la nueva conexión es menor que la capacidad del enlace. Es fácil de
implementar, solamente necesitaremos conocer la tasa de pico de la nueva conexión. Sin
embargo, debido a que el tráfico generalmente se genera a ráfagas, los puertos de salida estarán
infrautilizados.
9.1.4.2. Asignación estadística
Asignamos una capacidad por fuente inferior a la tasa de pico. La suma de todas las tasas
de pico puede ser superior a la capacidad de la fuente. Para ello necesitamos conocer el régimen
de llegadas de las fuentes. Es computacionalemente costoso pero sin embargo hace buen uso de
los puertos de salida.
9.1.4.3. Basado en medidas
Realiza una monitorización de los flujos tomando cierta cantidad de medidas como la tasa
de pico, utilización o el tamaño de ráfaga. Estima el CLR o el ancho de banda efectivo en función
de descriptores de tráfico y las medidas tomadas.
48
Simulador de Tráfico ATM con Garantía de Servicio
9.1.5. Tablas de enrutamiento de VCCs
Los diseñadores de ATM quisieron evitar dedicar demasiado tiempo de cómputo en los
conmutadores a determinar la manera de obtener la línea de salida para una célula a partir de su
información de circuito virtual. Por ello diseñaron la capa ATM para hacer posible un
enrutamiento eficiente.
En la capa ATM los conmutadores, para enrutar eficientemente las células de datos que
llegan a un conmutador hacia el puerto de salida adecuado, almacena unas tablas internas de
enrutamiento llamadas tablas VCCs. Estas tablas se rellenan para cada conexión en el momento
en el que ésta se establece. Posteriormente, durante el tiempo que dure el circuito virtual, cada
conmutador enviará las células siempre por el mismo camino usando la tabla VCCs. No se puede
asignar dentro de un mismo conmutador el mismo par VCI/VCI a dos conexiones activas en un
mismo instante.
Esta forma de enrutamiento se diferencia de la usada por los conmutadores de paquetes
en que en aquellos la ruta de destino se calcula individualmente para cada paquete, de este modo
la ruta a seguir podría cambiar entre un paquete y el siguiente. Por contra, en la conmutación de
células, cada una de las células pertenecientes a una misma conexión siguen todas la misma ruta.
Una tabla VCC en un conmutador podría presentar la siguiente forma:
DESDE
HACIA
Puerto
VPI
VCI
Puerto
VPI
VCI
5
33
7
3
3
1
1
3
*
2
7
*
2
7
3
4
9
7
Tabla 9.1: Tabla VCC genérica.
Según esta tabla de ejemplo, todo tráfico que llegue al conmutador por el enlace 5 con
VPI = 33 y VCI = 7 serán dirigidas al enlace 3 con VPI = 3 y VCI = 1.
Si queremos que el conmutador soporte conexiones p-mp será necesario que para cada
terna Puerto/VPI/VCI pueda haber más de una terna de destino. Por ejemplo:
49
Simulador de Tráfico ATM con Garantía de Servicio
DESDE
HACIA
Puerto
VPI
VCI
Puerto
VPI
VCI
5
33
7
3
3
1
4
1
3
5
2
1
1
3
*
2
7
*
2
7
3
4
9
7
Tabla 9.2: TablaVCC genérica con conexiones p-mp
Como hemos visto en este ejemplo el conmutador cambia los valores de VPI y VCI de
salida con respecto a los de entrada. Los conmutadores que cambian ambos valores se denominan
conmutadores VC en contraposición a los conmutadores VP que tan solo modifican el valor de
VPI dejando el VCI intacto. Los conmutadores VC aplican un mayor nivel de complejidad, ya
que manejan atributos como el nivel de errores, calidad de servicio, ancho de banda o servicios
relacionados con la tarificación. Lo normal es que los conmutadores que estén sólo conectados a
otros conmutadores sean conmutadores VP mientras que los conmutadores VC serán los que se
encuentren conectados directamente por algunos de sus puertos a un terminal.
9.2. Funciones y algoritmos de gestión de
conexiones de “simSwitch”
Una vez presentados los mecanismos que utiliza ATM para la señalización enrutamiento
y la gestión de conexiones, seguidamente pasaremos a explicar cuáles serán los mecanismos que
utilizará nuestra simulación para realizar todas estas labores. Seguiremos un orden análogo al de
los anteriores puntos por lo que primeramente nos centraremos en la señalización, continuaremos
describiendo el protocolo de establecimiento y liberación de conexiones, seguiremos
profundizando en el método de enrutamiento elegido y finalmente, tras presentar el algoritmo
CAC implementado, acabaremos con el método de contrucción y mantenimiento de las tablas
VCC.
9.2.1. Señalización en la simulación
La señalización en "simSwitch" está basada en la especificación UNI 3.0. Se ha optado
por ésta principalmente por el hecho de que las especificaciones posteriores están basadas en ella
y son muy similares en cuanto a la señalización. Otra razón es que, como veremos en el apartado
de enrutamiento, hemos escogido el protocolo de enrutamiento IISP diseñado para trabajar sobre
UNI en cualquier enlace de la red, ya sea entre conmutadores o entre un elemento final y un
conmutador. Por último la señalización UNI 3.0 es la más simple y fácil de entender con lo que,
además de proveer al simulador de un método de señalización realista, no oscurecemos el código
50
Simulador de Tráfico ATM con Garantía de Servicio
con algoritmos y protocolos complicados de implementar y entender.
9.2.1.1. Mensajes de señalización
En la especificación original los mensajes de señalización se empaquetan en PDUs AAL.
Nosotros, debido a la mayor simplicidad de nuestra implementación, los mensajes de señalización
los reduciremos a una sola célula por mensaje. Los elementos de la red reconocerán a una célula
como "célula de señalización" si al examinar el par VPI/VCI comprueban que pertenece al canal
de señalización, el 0/5. Este canal será un circuito virtual permanente en cada enlace y por lo
tanto no será necesario su establecimiento previo a la hora de mandar mensajes de señalización.
Un tipo de mensaje se diferenciará de otros mediante un "Id de mensaje" presente en el payload
de la célula de señalización.
9.2.1.2. Tipos de mensajes
Los mensajes de señalización que se intercambiarán los elementos de la red entre sí y la
información que contendrá cada célula quedan reflejados en la siguiente tabla:
Id Nombre
Significado
Parámetros
0
SETUP
1
CALL
PROCEEDING
2
CONECT
3
CONECT
ACKNOWLEDGE
4
RELEASE
5
RELEASE
COMPLETE
6
ADD PARTY
Esta función del protocolo permite a un usuario pedir VPI/VCI
el establecimiento de una conexión a un cierto destino. Dir. Origen
Dir. Destino
PCR
ToS
grado GoS
Mandado de un usuario a la red o de la red a un VPI/VCI
usuario para indicar que la el establecimiento de
conexión solicitado está siendo iniciado.
El usuario manda este mensaje a la red y la red VPI/VCI
usuario para indicar la aceptación de la conexión.
La red manda este mensaje a un usuario o un usuario a VPI/VCI
la red para indicar se ha recibido el mensaje
CONNECT.
Un usuario manda este mensaje a la red o la red a un VPI/VCI
usuario para pedir la finalización de una conexión
establecida p-p o p-mp.
La red manda este mensaje a un usuario o un usuario a VPI/VCI
la red para confirmar la liberación de la conexión.
También es utilizado por la red o por un usuario para
rechazar una solicitud de conexión.
Un usuario manda este mensaje a la red o la red lo VPI/VCI
manda a un usuario para añadir un nuevo receptor a Dir Origen
una conexión en conexiones p-mp. Es equivalente al Dir Destino
mensaje SETUP.
PCR
ToS
grado GoS
51
Simulador de Tráfico ATM con Garantía de Servicio
7
ADD
PARTY La red manda este mensaje a un usuario o un usuario a VPI/VCI
ACKNOWLEDGE la red para indicar la aceptación del mensaje anterior.
Tabla 9.3: Tipos de mensajes de señalización.
Se fijará el lector en que no hemos introducido ningún mensaje de rechazo de conexiones.
Esto es debido a que en nuestro simulador ninguna conexión es rechazada. Lo hemos dispuesto
para poder forzar situaciones de congestión a voluntad en los conmutadores de la red. Todas
aquellas conexiones que según el CAC no debieran ser aceptadas son, por tanto, admitidas sin
reservas. De la misma forma cualquier sumidero aceptará los parámetros de conexión que le
proponga una fuente. La única excepción a esta regla se produce cuando una fuente intenta
establecer una conexión mediante SETUP o ADD PARTY con un sumidero destino no existente.
En tal caso la red responde a la fuente con un mensaje RELEASE COMPLETED.
Seguidamente pasamos a explicar más detenidamente cuáles son las funciones de los
parámetros de las conexiones.
-
-
-
VPI/VCI --> El par de valores VCI/VPI con el que los datos enviados de la conexión
llegarán al elemento en cuestión. En las células SETUP y ADD PARTY se utiliza para
inicializar los valores de las tablas VPI/VCI. En las demás células se sirven para localizar la
conexión a la que van dirigidas dentro de un elemento..
Dir Origen, Dir Destino --> Las direcciones únicas del extremo origen y el extremo destino
de una conexión. Utilizados como índices en las tablas de enrutamiento de cada conmutador
para decidir el puerto de salida de un mensaje de señalización.
PCR --> PCR de la conexión solicitante. Usado para la adjudicación de pesos en las colas del
algoritmo WFQA en los conmutadores y como parámetro para el CAC.
ToS --> Tipo de servicio que se solicita al extremo receptor. Puede ser ordenado o no
ordenado.
Grado GoS --> Grado de garantía de servicio solicitado. Si su valor es cero la conexión no
solicita GoS.
Seguidamente expondremos un ejemplo de establecimiento y liberación de conexiones en
diagramas temporales para conexiones p-p y p-mp. En el ejemplo p-p vemos como el router A
intenta establecer una conexión con el router B a través de dos conmutadores. Se muestra también
la interface que actúa en cada lado de la comunicación.
52
Simulador de Tráfico ATM con Garantía de Servicio
SETUP
SETUP
CALL PROCEEDING
SETUP
CALL PROCEEDING
CALL PROCEEDING
t
CONECT
CONECT
CONECT ACK
CONECT
CONECT ACK
CONECT ACK
ROUTER A
CONMUTADOR A
CONMUTADOR B
ROUTER B
Figura 9.2: Cronograma del proceso de establecimiento de conexión con éxito.
SETUP
t
RELEASE COMPLETE
ROUTER A
CONMUTADOR A
CONMUTADOR B
ROUTER B
Figura 9.3: Cronograma del proceso de establecimiento de conexión sin éxito.
RELEASE
RELEASE
t
RELEASE COMPLETE
RELEASE
RELEASE COMPLETE
RELEASE COMPLETE
ROUTER A
CONMUTADOR A
CONMUTADOR B
Figura 9.4: Cronograma del proceso de liberación de conexión.
53
ROUTER B
Simulador de Tráfico ATM con Garantía de Servicio
ADD PARTY
ADD PARTY
ADD PARTY
t
ADD PARTY ACK
ADD PARTY ACK
ADD PARTY ACK
ROUTER A
CONMUTADOR A
CONMUTADOR C
ROUTER C
Figura 9.5: Cronograma del proceso de adición de un nuevo destino en conexiones p-mp con éxito.
ADD PARTY
t
RELEASE COMPLETE
ROUTER A
CONMUTADOR A
CONMUTADOR B
ROUTER B
Figura 9.6: Cronograma del proceso de adición de un nuevo destino en conexiones p-mp sin éxito.
9.2.1.3. Estados de llamada en conexiones.
Debido a que muchas llamadas pueden existir simultáneamente en el UNI, y a que cada
llamada puede estar en diferentes estados, se debe definir sin ambigüedades el estado de la
interface. Los posibles estados, con sus significados para la interface N y la U son los siguientes:
- NULL (0): No hay llamada
- CALL INITIATED (1):
U: Se ha mandado un mensaje SETUP y se está a la espera de la confirmación.
N: Se ha recibido un mensaje SETUP pero aun no se ha confirmado
- OUTGOING CALL PROCEEDING (3):
U: Se ha recibido confirmación del mensaje SETUP.
N: Se ha mandado confirmación al mensaje SETUP recibido.
-CALL PRESENT (6):
U: Se ha recibido un mensaje SETUP que aun no se ha confirmado.
N: Se he enviado un mensaje SETUP que aún no ha sido confirmado.
54
Simulador de Tráfico ATM con Garantía de Servicio
-CONNECT REQUEST (8):
U: Se ha confirmado un mensaje SETUP recibido.
N: Se ha recibido confirmación de un mensaje SETUP enviado
- INCOMING CALL PROCEEDING (9):
U: Se ha aceptado una petición de conexión con un mensaje CONNECTION.
N: Se ha recibido un mensaje CONECCTION aceptando una petición de conexión.
- ACTIVE (10):
U: Se ha recibido confirmación al mensaje CONNECTION en el extremo receptor de la
petición original de conexión. En el caso del emisor, éste pasa al estado ACTIVE cuando envía
un mensaje de confirmación de conexión.
N: Se ha mandado confirmación al mensaje CONNECTION al extremo receptor de la
petición original de conexión o se ha mandado un mensaje CONNECTION al origen de la
petición de conexión.
- RELEASE REQUEST (11):
U: Se manda un mensaje RELEASE de petición de liberación de la conexión aún no
confirmado.
N: Se recibe un mensaje RELEASE antes de su confirmación.
- RELEASE INDICATION (12)
U: Se ha recibido un mensaje RELEASE y aún no se ha confirmado
N: Se ha mandado un mensaje RELEASE no confirmado aún.
Es de importancia diferenciar entre el lado de usuario o el lado de red ya que, como
veremos más tarde, según el protocolo de enrutamiento que hemos elegido, el IISP, un
conmutador puede arbitrariamente tomar el papel de usuario o red en cada extremo de un enlace.
Existen dos estados más asociados con las conexiones p-mp. Estos estados tienen el
mismo significado en el lado del usuario o de la red y son los siguientes:
- ADD PARTY INITATED (P1): Se ha mandado un mensaje ADD PARTY.
- ADD PARTY RECIVED (P2): Se ha recibido un mensaje ADD PARTY.
Toda fuente se debe comprometer a no mandar células de datos hasta que no haya
establecido la conexión con todos los sumideros de una comunicación p-mp.
Debido a que muchas llamadas pueden existir simultáneamente en el UNI, y a que cada
llamada puede estar en diferentes estados, se debe definir sin ambigüedades el estado del
interface. Los posibles estados, con sus significados para la interface N y la U son los siguientes:
- NULL (0): No hay llamada
- CALL INITIATED (1):
U: Se ha mandado un mensaje SETUP y se está a la espera de la confirmación.
N: Se ha recibido un mensaje SETUP pero aun no se ha confirmado
- OUTGOING CALL PROCEEDING (3):
U: Se ha recibido confirmación del mensaje SETUP.
N: Se ha mandado confirmación al mensaje SETUP recibido.
-CALL PRESENT (6):
U: Se ha recibido un mensaje SETUP que aun no se ha confirmado.
N: Se he enviado un mensaje SETUP que aún no ha sido confirmado.
-CONNECT REQUEST (8):
U: Se ha confirmado un mensaje SETUP recibido.
N: Se ha recibido confirmación de un mensaje SETUP enviado
- INCOMING CALL PROCEEDING (9):
U: Se ha aceptado una petición de conexión con un mensaje CONNECTION.
N: Se ha recibido un mensaje CONECCTION aceptando una petición de conexión.
55
Simulador de Tráfico ATM con Garantía de Servicio
- ACTIVE (10):
U: Se ha recibido confirmación al mensaje CONNECTION en el extremo receptor de la
petición original de conexión. En el caso del emisor, éste pasa al estado ACTIVE cuando recibe
un mensaje de confirmación de conexión.
N: Se ha mandado confirmación al mensaje CONNECTION al extremo receptor de la
petición original de conexión o se ha mandado un mensaje CONNECTION al origen de la
petición de conexión.
- RELEASE REQUEST (11):
U: Se manda un mensaje RELEASE de petición de liberación de la conexión aún no
confirmado.
N: Se recibe un mensaje RELEASE antes de su confirmación.
- RELEASE INDICATION (12)
U: Se ha recibido un mensaje RELEASE y aún no se ha confirmado
N: Se ha mandado un mensaje RELEASE no confirmado aún.
Es de importancia diferenciar entre el lado de usuario o el lado de red ya que, como
veremos más tarde, según el protocolo de enrutamiento que hemos elegido, el IISP, un
conmutador puede arbitrariamente tomar el papel de usuario o red en cada extremo de un enlace.
Existen dos estados más asociados con las conexiones p-mp. Estos estados tienen el
mismo significado en el lado del usuario o de la red y son los siguientes:
- ADD PARTY INITATED (P1): Se ha mandado un mensaje ADD PARTY.
- ADD PARTY RECIVED (P2): Se ha recibido un mensaje ADD PARTY.
Toda fuente se debe comprometer a no mandar células de datos hasta que no haya
establecido la conexión con todos los sumideros de una comunicación p-mp.
9.2.1.4. Diagrama de estados de una conexión
Seguidamente mostramos el diagrama de estados para las interfaces de usuario y de red.
Cada conexión iniciada, en curso o liberándose se encuentra en uno de estos estados. El diagrama
a) muestra los estados en la interface de usuario de un elemento que inicia la conexión. El
diagrama b) muestra los estados en la interface de usuario pero para un elemento receptor de la
petición de conexión. En el c) se muestra el iniciador en la interface N y por último, en el d) se
muestra la parte receptora en la interface N.
Los textos de los arcos se leen de la siguiente forma:
RECIVE EL MENSAJE x/ ENVÍA EL MENSAJE y
Si en alguno de las dos partes aparece un signo de multiplicación “*“ querrá decir que se
trata de una comunicación entre interfaces. En el caso de que el asterisco aparezca en la primera
parte (esto es, antes de “/”) se tratará de una notificación recibida de la otra interface. Si por el
contrario el asterisco aparece en la segunda parte (esto es, tras “/”) indicará que se notifica a la
otra interface el mensaje recibido. Por ejemplo, un arco con un texto “*/SETUP” indicará que se
ha recibido de la interface de entrada una notificación de llegada de un mensaje de señalización
SETUP que provocará que esta interface, la de salida, envíe un mensaje SETUP por donde
corresponda.
56
Simulador de Tráfico ATM con Garantía de Servicio
Figura 9.7: Diagrama de estados en una fuente
Figura 9.8: Diagrama de estados en un sumidero
57
Simulador de Tráfico ATM con Garantía de Servicio
Figura 9.9: Diagrama de estados en la interface de entrada en de un conmutador
Figura 9.10: Diagrama de estados en la interface de salida en de un conmutado
58
Simulador de Tráfico ATM con Garantía de Servicio
9.2.1.5. Acciones a realizar en cada estado
Dependiendo del estado en el que se encuentre una conexión y de los mensajes recibidos
o enviados se deberán realizar diferentes acciones. En los siguientes puntos se describen esas
acciones para cada estado e interface.
- U0.- Una conexión se encuentra en este estado si ha finalizado o está a la espera de
activarse.
Una fuente con una conexión en este estado deberá comprobar si ha llegado el momento
de activarla. Si es así construirá un mensaje SETUP con los datos de la conexión y lo mandará al
conmutador al que esté conectado.
Un sumidero con una conexión en este estado esperará a un mensaje SETUP tras el cual
procederá a inicializar los elementos necesarios para el seguimiento de la conexión.
- U1.- Una conexión se encuentra en este estado si está a la espera de recibir un mensaje
CALL PROCEEDING o un mensaje RELEASE COMPLETE.
Cuando se recibe un CALL PROCEEDING se obtiene el valor de VPI/VCI que nos
servirá para diferenciar los mensajes dirigidos a esta conexión de los dirigidos a otras posibles
conexiones. Una fuente con una conexión en este estado no iniciará el proceso de abrir ninguna
otra conexión. El VPI/VCI seleccionado para esta conexión se obtendrá del mensaje CALL
PROCEEDING.
Cuando se recibe un RELEASE COMPLETE, la conexión se anula y por lo tanto no se
mandará ninguna célula de información para ella.
- U3.- Una conexión en este estado se encuentra a la espera de un mensaje
CONNECTION confirmando la solicitud de conexión por parte del sumidero.
- U6.- El sumidero destino construirá un mensaje CALL PROCEEDING y lo mandará de
vuelta.
- U8.- El sumidero construirá un mensaje de aceptación de la conexión CONNECTION.
- U9.- El sumidero se pone a la espera de recibir la confirmación CONNECTION ACK.
La fuente debe enviar un mensaje CONNECTION ACK
- U10.- En este estado se diferencia entre el comportamiento de una fuente y un
sumidero.
Si la comunicación es p-p la fuente empezará el proceso de envío y recepción de datos y
células RM. Si se trata de una conexión p-mp se deberá enviar tantos ADD PARTY como
destinos diferentes tenga. Una vez añadidos todos estos destinos comenzará el envío de datos.
Cuando sea el momento de cerrar la conexión (haya agotado su tiempo de simulación) se mandará
un mensaje RELEASE no mandando más células de datos.
El sumidero se podrá a la espera de recibir datos o células RM para esta conexión y las
procesará como sea conveniente. También esperará un mensaje RELEASE que le ordene liberar
la conexión. Cuando ésta se recibe deja de esperar más células de datos de esa conexión
- U11.- La fuente, una vez mandado el mensaje de liberación de la conexión, se pondrá a
la espera de recibir la confirmación con el mensaje RELEASE COMPLETE.
59
Simulador de Tráfico ATM con Garantía de Servicio
- U12.- El sumidero construirá y mandará un mensaje de confirmación RELEASE
COMPLETE y destruirá la conexión.
Para las interfaces N distinguiremos entre la interface N de entrada y la de salida
- N0.- En la interface de entrada un conmutador se encuentra a la espera de recibir una
solicitud de conexión SETUP. Al recibirla se pasa al estado siguiente.
En la interface de salida el conmutador se encuentra a la espera de que la interface de
entrada le comunique que ha recibido una señal SETUP. Entones comprueba las tablas de
enrutamiento, se actualizan las tablas VPI/VCI y finalmente se propaga la señal SETUP por la
salida seleccionada, y pasa al estado siguiente.
- N1.- El la interface de entrada se comprueba la existencia del destino. Si el destino
existe se aplica el algoritmo CAC, se comprueba los valores VPI/VCI de entrada y los modifica
en caso necesario y se devuelve un mensaje CALL PROCEEDING con el valor adjudicado de
VPI/VCI y se actualiza la tabla VPI/VCI. Igualmente comunica a la interface de salida la
recepción de un mensaje SETUP haciéndole cambiar de estado (de N0 a N6).
Si por el contrario el sumidero no existe se responde a la fuente con un mensaje
RELEASE COMPLETE y no se realizan más acciones. Es importante indicar que sólo será
posible el envío de este mensaje en el primer conmutador al que llegue el mensaje SETUP
- N3.- En este estado la interface de entrada espera a que la interface de salida le
comunique que se ha recibido una aceptación de conexión, mensaje CONNECTION, tras lo cual
propagará ese mensaje a los elementos precedentes.
- N6.- En este estado la interface de salida está esperando una confirmación mediante el
mensaje CALL PROCEEDING.
- N8.- La interfaz de salida se encuentra esperando un mensaje de conexión aceptada
CONNECTION. Al recibirlo le comunica a la interface de entrada el hecho para que propague en
sentido descendente este mensaje.
- N9.- La interfaz de salida confirma el anterior mensaje con CONNECTION ACK.
- N10.- La interface de entrada se pone a la espera de recibir un mensaje CONNECTION
ACK tras lo cual esperará recibir las células de datos de la conexión y esperará el mensaje
RELEASE. Una vez recibido le comunica este hecho a la interface de salida y pasa al siguiente
estado. También puede recibir un mensaje ADD PARTY tras lo cual actuaría como en el estado
N0 cambiando al estado P2 y notificándolo a la interfaz de salida.
La interfaz de salida esperará a recibir células de datos que serán enviadas por el puerto
de salida adecuado. Esta situación se mantendrá hasta que la interface de entrada le comunique
que ha recibido un mensaje RELEASE para esta conexión. Entonces propagará este mensaje y
pasará al siguiente estado. En el caso de conexiones p-mp el mensaje RELEASE se propagará por
todas aquellas salidas que sean necesarias.
- N11.- Se liberarán los recursos destinados a mantener esta conexión (colas de entrada,
entrada/s en la tabla VPI/VCI, etc.). Por último mandará al origen un mensaje de confirmación
RELEASE COMPLETED lo que indicará que la conexión ha sido liberada.
- N12.- La interfaz de salida espera la confirmación de la liberación de la conexión
60
Simulador de Tráfico ATM con Garantía de Servicio
mediante un mensaje RELEASE COMPLETED.
- P1.- Si nos encontramos en la fuente se construye un mensaje ADD PARTY a partir de
la información de la conexión. Se envía y se espera confirmación.
Si por el contrario este estado se ejecuta en un conmutador, el mensaje se construye a
partir del ADD PARTY recibido y se reenvía por donde corresponda según la tabla de
enrutamiento.
- P2.- Si nos encontramos en el sumidero debemos actuar como si hubiéramos recibido un
mensaje SETUP con la diferencia de que tan sólo habrá que mandar de vuelta un mensaje ADD
PARTY ACK pasando seguidamente al estado ACTIVO.
Si nos encontramos en un conmutador el proceso es diferente. Si el mensaje no ha
seguido el camino del SETUP inicial entonces se han de inicializar todas las estructuras como si
hubiéramos recibido un mensaje SETUP. Posteriormente se comprueba la función CAC y se pasa
a la interface de salida para ser reenviado.
Si nos encontramos en un conmutador entonces el mensaje DROP PARTY
ACKNOWLEDGE lo habremos recibido de la interface de salida. En este caso se deberán liberar
los recursos adjudicados a este destino de la conexión y reexpedir el mensaje por el puerto de
entrada que corresponda.
9.2.2. Direccionamiento en la simulación
Las funciones de direccionamiento en nuestro simulador están simplificadas hasta tal
punto que cada elemento de una topología queda unívocamente identificado mediante un único
número entero, que hará las veces de dirección ATM. Este identificador se inicializa en el
momento de crear un elemento de red.
9.2.3. Enrutamiento en la simulación
El protocolo de enrutamiento elegido para la simulación es el IISP descrito en uno de los
anteriores apartados. Nuestra elección se debe a que es un protocolo simple, con poca
complejidad y adecuado a nuestros propósitos ya que al ser sus tablas de enrutamiento estáticas
nos permite más fácilmente forzar rutas específicas a determinadas conexiones.
Como vimos, las peticiones de señalización son encaminadas entre conmutadores usando
tablas de enrutamiento preconfiguradas en cada conmutador. Esta preconfiguración la
realizaremos antes de que cualquier fuente inicie ninguna petición de conexión. En este apartado
describiremos qué forma tendrán las tablas de enrutamiento, cómo se utilizarán y qué algoritmos
de enrutamiento damos la posibilidad utilizar en nuestra implementación de este protocolo.
9.2.3.1. Tablas de enrutamiento:
Cada conmutador de nuestra red almacena una tabla de enrutamiento que deberá estar
creada e inicializada con los datos de enrutamiento antes de que alguna petición de conexión
61
Simulador de Tráfico ATM con Garantía de Servicio
llegue.
Las tablas de enrutamiento del algoritmo IISP presentan la siguiente estructura:
Dir Destino 1
Dir Destino 2
..................
Dir Destino n
Dir Origen 1
PuertoSalida
PuertoSalida
..................
PuertoSalida
Dir Origen 2
PuertoSalida
PuertoSalida
..................
PuertoSalida
...................
Dir Origen n
………………
PuertoSalida
………………
PuertoSalida
..................
..................
………………
PuertoSalida
Tabla 9.4: Tablas de enrutamiento IISP
Vista la forma de estas tablas se deduce que cada conmutador debe tener conocimiento
completo sobre la topología de la red. Como puede verse sólo se almacena el puerto de salida.
Para obtener el puerto de entrada no es necesario acudir a las tablas de enrutamiento ya que esta
información ya se almacenó cuando llegó la célula SETUP ó ADD PARTY en la señalización.
9.2.3.2. Inicialización de las tablas de enrutamiento
Como hemos apuntado anteriormente, el algoritmo a utilizar para obtener las matrices de
enrutamiento de cada conmutador deberá tener conocimiento de la topología completa de la red,
por lo que este algoritmo se calculará una vez finalizado el proceso de diseño de la topología.
Para el cálculo de enrutamiento utilizaremos el algoritmo de Floyd. Partimos de un grafo
dirigido dado por su matriz de adyacencia y calculado directamente a partir de la topología de la
red:
G(i, j) = c Si hay un enlace de i a j con coste c e i != j.
G(i, j) = INFINITO Si no hay tal enlace y e != j.
G(i, i) = 0.
Posteriormente se aplica el algoritmo y se obtienen la tabla C(i,j) (coste mínimo del
camino entre los nodos i y j) y la tabla P(i,j) (nodo intermedio entre i y j en el camino de coste
mínimo). El algoritmo es el siguiente:
Algoritmo de Floyd.
Proc floyd(G[1..n, 1..n], C[1..n, 1..n] , P[1..n, 1..n]);
C:=G; P:=[0];
Para k=1 hasta n hacer
Para i=1 hasta n hacer
Para j=1 hasta n hacer
Si C(i, k)+C(k, j) < C(i, j) entonces
C(i, j) = C(i, k) + C(k, j)
P(i, j) = k
Fsi;
Fpara;
62
Simulador de Tráfico ATM con Garantía de Servicio
Fpara;
Fpara;
Fproc;
Lo único que puede quedar un poco oscuro es el objetivo de la matriz P. Esta matriz es la
que se utiliza para conocer el camino concreto. Para hacerlo se actúa así, si queremos conocer el
camino mínimo entre i y j, calculamos las matrices C y P por el algoritmo anterior, a continuación
tomamos P(i, j) = k. Esto significa que el camino mínimo que lleva de i a j pasa por k.
Necesitamos conocer el camino mínimo de i a k y de k a j, pero como ya hemos calculado las
matrices C y P, consultamos P(i, k) = r y P(k, j) =s. A continuación consultamos P(i, r), P(r, k),
P(k, s) y P(s, j) ... etc.
Si C(i, j) = INFINITO, no hay camino de i a j.
Hemos propuesto dos criterios para la inicialización de costes en el grafo G.
- La primera basada en la latencia. Los valores de G se rellenan con el delay introducido
por el cable en un enlace. Una ruta será más costosa cuanto mayor sea el delay acumulado. Por lo
tanto el algoritmo aplicado a este grafo nos dará el camino entre dos nodos i y j que presente la
mínima latencia.
- La segunda se basa en el número de enlaces que atravesará una conexión. G(i,j)
inicialmente sólo contendrá los valores 1 ó 0. Contendrá un 1 si hay camino directo entre i y j y
contendrá un 0 en caso contrario. Por lo tanto el algoritmo aplicado a este grafo nos dará el
camino entre los nodos i y j que atraviese el menor número de enlaces.
Una vez obtenida la matriz P, utilizaremos sus valores para rellenar la matriz de
enrutamiento en cada uno de los conmutadores.
9.2.3.3. Utilización de una tabla de enrutamiento.
Estas tablas sólo las utilizará el conmutador a la hora de dirigir las células de señalización
SETUP y ADD PARTY y establecer VCs para las conexiones rellenado las tablas VCC. Cuando
se ha de enrutar éstas células de señalización, se examina su payload donde se encuentran sus
parámetros "Dir Origen" y "Dir Destino". Se utilizan estos dos parámetros como índices en la
tabla de enrutamiento y se obtiene el valor del puerto deseado. El algoritmo en pseudocódigo es
el siguiente:
function getPuerto( Tabla_routing, SEN_CELL, dirección) return Integer
begin
return tabla_routing[getDirOrigen(SEN_CELL)] [getDirDestino(SEN_CELL)]
end;
9.2.4. El algoritmo CAC en la simulación
En nuestro simulador utilizaremos un algoritmo de asignación no estadística muy
sencillo. Por las características especiales del simulador necesitamos que TODAS las solicitudes
de conexión sean aceptadas. La única misión de este algoritmo es la de avisar al operador de que
una determinada conexión puede degenerar el comportamiento de un conmutador pudiéndose
63
Simulador de Tráfico ATM con Garantía de Servicio
llegar a producir congestiones. Teniendo en cuenta el papel secundario del CAC en nuestro
simulador, la elección de un algoritmo CAC sencillo está completamente justificada.
El algoritmo CAC lanzará una alarma de "conexión potencialmente congestionante" al
operador cuando, al recibir una célula de señalización SETUP o ADD PARTY y comprobar su
propuesta de PCR, comprueba que, añadida al PCR de las conexiones activas, supera la potencia
de conmutación del conmutador o el ACR (Avaliable cell rate) de la portadora de salida del
puerto correspondiente. El algoritmo en pseudocódigo es el siguiente:
function compruebaCAC(puerto, SETUP, ABR_conmutacion, ABR_puerto) return alarma
begin
alarma = false;
pcr = getPCR(SETUP) ;
if ABR_conmutacion <= 0 or pcr > ABR_conmutacion then
alarma = true;
if ABR_puerto[puerto] <= 0 or pcr > ABR_puerto[puerto] then
alarma = true;
ABR_conmutacion = ABR_conmutacion - pcr;
ABR_puerto[puerto] = ABR_puerto[puerto] - pcr;
return alarma;
end function;
Como puede verse necesitamos también los valores del ABR de conmutación y ABR de
salida. Pase lo que pase el ABR se reduce en una cantidad igual al PCR solicitado por la
conexión. Cuando la conexión se cierra el ABR se aumentará en la misma cantidad que fue
disminuido en la apertura.
9.2.5. Tablas de enrutamiento de VCCs en la
simulación
En nuestra simulación las tablas de enrutamiento están diseñadas exactamente como
describimos en anteriores apartados. Cada conmutador almacenará una de estas tablas cuyos
valores internos cambiarán dinámicamente durante el transcurso de la simulación en reacción a
peticiones de señalización.
Las tablas VCCs estarán indexadas por dos ternas de valores. La primera terna, la
llamada "terna de entrada" contendrá primeramente el valor del puerto de entrada de una
conexión seguido del VPI y del VCI adjudicado a esa conexión. La segunda terna, la "terna de
salida" contendrá una lista de ternas, una por cada puerto de salida diferente en una conexión pmp. Para cada elemento de la lista aparecerá primeramente el valor del puerto de salida, y después
el del VPI y del VCI con el que saldrán todas las células de la conexión en cuestión.
Terna de Entrada
Ternas de Salida
Puerto VPI
[0]
Puerto VPI
VCI
.....
[n]
.....
...
Puerto VPI
......
VCI
VCI
Tabla 9.5: Tabla VCC
64
Simulador de Tráfico ATM con Garantía de Servicio
9.2.5.1. Establecimiento de VCCs
Cuando un conmutador recibe una petición de establecimiento de conexión mediante una
célula de señalización SETUP, una vez ésta ha pasado el filtro del CAC, se debe crear una entrada
en la tabla VPI/VCI para este nueva conexión. Los pasos a seguir son los siguientes:
1.- En la solicitud SETUP están presentes dos valores que son el par VPI/VCI solicitado. Debido
a que en una fuente no se pueden programar dos conexiones con valores VPI/VCI idénticos, y a la
forma de asignación de ese para en los conmutadores, a un conmutador no le pueden llegar por el
mismo puerto de entrada dos solicitudes con VPI/VCI idénticos.
2.- El conmutador crea una nueva línea en la terna de entrada en la tabla VPI/VCI con los valores
del puerto por el que entró la célula de señalización y el VPI/VCI adjudicados
3.- Posteriormente adjudica los dos valores del par VPI/VCI de la terna de salida siguiendo los
siguientes criterios:
- El VPI de salida será idéntico para todas las células de aquellas conexiones que
compartan el mismo sumidero destino. Esto se hace así para facilitar el enrutamiento VP en los
conmutadores intermedios. Para ello cada conmutador debe guardar un registro del VPI de salida
utilizado para cada sumidero. Para simplificar esto, a este VPI se le adjudicará el valor de "Id
Destino" presente en todas las células de señalización, consiguiendo así el requerimiento anterior.
- El VCI de salida será diferente para cada conexión que comparta un puerto y un VPI de
salida. De esta forma diferenciaremos unas conexiones de otras dirigidas al mismo sumidero.
Para implementar esto deberemos mantener un registro de los VCI utilizados para cada VPI. El
valor VPI adjudicado será más bajo que se encuentre libre en el registro, y lo marcaremos
seguidamente como ocupado.
4.- Con los valores obtenidos del par VPI/VCI de salida y el puerto de salida se crea una terna de
salida y se asocia a la terna de entrada obtenida.
*.- En el caso de las conexiones p-mp, si a un conmutador le llega una célula ADD PARTY
deberá comprobar el VPI/VCI y el puerto de entrada para ver si la conexión ha sido ya
previamente restablecida en el conmutador. Si es así no deberá crear una nueva línea en la terna
de entrada, en caso contrario procederá siguiendo los pasos 2 a 4.
Si la terna de entrada ya estaba establecida entonces se obtendrá el puerto de salida y se
comparará con el campo puerto de salida de la lista de ternas de salida. Si es igual a alguna de
ellas querrá decir que ambas conexiones saldrán por el mismo puerto por lo que no será necesario
añadir ninguna terna de salida a la/s ya presente/s.
Si el puerto de salida no coincide con ninguno de la lista querrá decir que este conmutador debe
mandar los mismos datos de esta conexión por dos o más puertos diferentes. En consecuencia
deberá añadir una nueva terna a la lista de ternas de salida siguiendo los puntos 3 y 4.
65
Simulador de Tráfico ATM con Garantía de Servicio
Pseudocódigo:
procedure addVCC(SEN_CELL, puerto_entrada, puerto_salida)
begin
VPI/VCI_entrada = getVPI/VCI(SEN_CELL);
if tipo(SEN_CELL) = SETUP or
(tipo(SEN_CELL) = ADD PARTY and
not conexionPresente(puerto_entrada, VPI/VCI_entrada) then
begin
VPI/VCI_adjudicado = getVPI/VCI_Libre(tablaVCC, VPI/VCI_entrada);
terna_entrada = addTernaEntrada(tablaVCCs, puerto_entrada,
VPI/VCI_adjudicado);
VPI_salida = getDirDestino(SEN_CELL);
VCI_salida = getVCILibre(puerto_salida, VPI_salida);
addTernaSalida(terna_entrada, puerto_salida, VPI/VCI_salida);
else
begin
terma_entrada = getTernaEntrada(tablaVCCs, puerto_entrada, VPI/VCI_entrada)
if puertoSalidaNuevo(terna_entrada, puerto_salida, tablaVCC) then
begin
VPI_salida = getDirDestino(SEN_CELL);
VCI_salida = getVCILibre(puerto_salida, VPI_salida);
addTernaSalida(terna_entrada, puerto_salida, VPI/VCI_salida);
end if
end if
end procedure;
9.2.5.2. Liberación de VCCs
La liberación de conexiones se iniciará en el caso de que a un conmutador le llegue un
mensaje de señalización RELEASE. Los pasos a seguir son los siguientes:
1.- Se comprueba si el VC está activo. Para ello examinamos la tabla VCCs y utilizamos el valor
VPI/VCI y puerto de entrada como índice.
2.- Si está activo simplemente se borra de la tabla VCC la terna de entrada con su/s
correspondiente/s terna/s de salida.
Pseudocódigo
procedure delVCC(SEN_CELL, puerto_entrada)
begin
VPI/VCI = getVPI/VCI(SEN_CELL);
if conexionPresente(puerto_entrada, VPI/VCI) then
begin
terma_entrada = getTernaEntrada(tablaVCCs, puerto_entrada, VPI/VCI)
delTernasSalida( tabla VCCs, terna_entrada);
delTernaEntrada( tabla VCCs, puerto_entrada, VPI/VCI);
end if;
end procedure;
9.2.5.3. Uso de las tablas VCCs
Cuando a algún conmutador llega una célula de datos, para conmutarla al puerto de salida
66
Simulador de Tráfico ATM con Garantía de Servicio
adecuado con los valore VPI/VCI correctos debe consultar la tabla VCCs. Para ello necesitará los
valores de la terna de entrada. Como resultado obtendrá una lista consistente en una ó más de
ternas con la información necesaria para la conmutación.
Pseudocódigo
procedure getTernasSalida(puerto_entrada, VPI/VCI_entrada) return Cjto_ternas_salida
begin
terna_entrada = getTernaEntrada(tablaVCC, puerto_entrada, VPI/VCI_entrada);
Cjto_ternas_salida = getTernasSalida(tablaVCC, terna_entrada);
return Cjto_ternas_Salida;
end procedure;
67
Simulador de Tráfico ATM con Garantía de Servicio
10. Funciones y procedimientos para
la gestión del tráfico
10.1. Introducción
En este apartado vamos a indicar los diferentes mecanismos que es posible utilizar en
ATM para el control del tráfico y las congestiones. Las redes ATM reales pueden implementar
una o una combinación de estas funciones con el fin de obtener los objetivos de QoS
especificados en las conexiones.
En nuestro simulador no hemos tenido en cuenta los parámetros de QoS. Las razones de
ello son varias:
•
•
•
•
•
Por una parte no existen algoritmos estándar para la consecución de la QoS. Cada
fabricante proporciona los parámetros negociados a una conexión mediante sus propios
mecanismos propietarios.
En segundo lugar, en el caso de que nos decidiéramos a implementar algún mecanismo de
QoS, no compensaría la complejidad introducida con los beneficios obtenidos. No
olvidemos que el objetivo principal del simulador es el de crear un entorno de red ATM
relativamente realista e idóneo para comprobar el grado de GoS obtenido mediante la
implantación en las VPN de conmutadores activos que soporten el protocolo TAP. Cuantos
más algoritmos haya modificando el tráfico por su cuenta menos clara quedará la aportación
del protocolo TAP a la mejora de la red.
Un factor importante y relacionado con el anterior punto es el tiempo de cómputo. Nuestro
propósito es el de crear un simulador que pueda realizar las simulaciones lo más cercanas
posibles al tiempo real. La introducción de los parámetros de QoS en el simulador haría
considerablemente más complejos los conmutadores por lo que afectaría negativamente
al tiempo de simulación. Esto es así ya que cuanto más complejo sea un conmutador más
tiempo llevará que realice sus operaciones y por lo tanto más lento hará el proceso de
simulación.
El protocolo TAP no está directamente relacionado con la QoS. Cierto es que los agentes
controlan la mayoría de los aspectos de la múltiplexación de células en los conmutadores sin
embargo no son los responsables directos de la ejecución de los algoritmos dedicados a la
consecución de la QoS.
Por último, uno de nuestros objetivos a la hora de crear el simulador es hacer el tráfico de la
red lo más determinista posible para poder así crear situaciones de congestión en los
conmutadores, observar los resultados y poder reproducirlos con posterioridad si fuese
necesario. Un simulador con control de la QoS reduciría el grado de determinismo lo que
impediría la fácil comparación de resultados entre varias simulaciones.
En definitiva, dado que la GoS no está relacionada directamente con la QoS, y que la
introducción del manejo de los parámetros de QoS tan solo oscurecería y complicaría nuestro
simulador, para nuestros propósitos, de ahora en adelante supondremos que ninguna conexión va
68
Simulador de Tráfico ATM con Garantía de Servicio
a requerir que la VPN satisfacer los requerimientos de QoS (CDV, CDT, CLR, etc). Por lo tanto
no será necesaria la simulación de la negociación de tales parámetros ni su impacto en el tráfico.
Volviendo al tema que nos ocupa en este apartado, describiremos las siguientes funciones
para el control de tráfico y congestiones indicando para cada una de ellas si se ha implementado
en nuestro simulador, de qué manera y por qué. Las funciones son las siguientes:
•
•
•
•
•
•
•
•
•
Connection Admisión Control (Control de admisión de conexiones)
Usage Parameter Control (Control de parámetros de uso)
Selective Cell Discarding (Descarte selectivo de células)
Traffic Shaping (Modelado de tráfico)
Explicit Forward Congestion Indication (Indicación explicita de congestión ascendente)
Resource Magnagement using Virtual Paths (Gestión de recursos mediante el uso de VPs)
Frame Discart (Descarte de marcos)
Generic Flow Control (Control de flujo genérico)
ABR Flow Control (Control de flujo ABR)
10.2. Connection Admisión Control
La función del control de admisión de conexiones (CAC) se define como el conjunto de
acciones tomadas por la red en el establecimiento de un SVC o por la gestión de la red durante el
establecimiento de un PVC para determinar qué conexiones deben ser admitidas o rechazadas. En
nuestro simulador implementamos una versión muy simple de esta función que utilizamos para
comprobar qué conexiones podrían causar congestión.
10.3. Usage Parameter Control
La función UPC es opcional en las redes reales.
El control de los parámetros de uso (UPC) se define como el conjunto de acciones
tomadas por la red para monitorizar y controlar el tráfico. Su propósito principal es proteger los
recursos de la red de fallos de comportamiento maliciosos u accidentales que puedan afectar la
QoS de otras conexiones establecidas mediante la detección de violaciones de los parámetros
negociados y la toma de decisiones apropiadas.
En el caso de nuestro simulador esta función no será necesaria por varios motivos:
primeramente, como ya apuntamos al comienzo de este capítulo, nosotros no implementamos
QoS. Además, dadas las características específicas de nuestra simulación, las fuentes no generan
nunca tráfico a una velocidad mayor a la indicada en la conexión por lo que los “fallos”
accidentales o maliciosos en los que una fuente utiliza más ancho de banda del adjudicado no se
producen.
69
Simulador de Tráfico ATM con Garantía de Servicio
10.4. Selective Cell Discard
El descarte selectivo es una función opcional en las redes ATM reales.
Un elemento de red congestionado puede selectivamente descartar células que pueden
encontrarse en una o ambas de las siguientes situaciones:
a) No cumple las condiciones de la conexión
b) Presenta su CLP = 1
El objetivo de esta función es el de proteger el CLP = 0 lo máximo posible.
Esta función está parcialmente implementada en nuestro simulador. En lo que respecta al
apartado a) todas las células no congestionadas llegan en el momento en el que tienen que llegar a
los diversos elementos de la red por lo que siempre cumplirán las condiciones de la conexión. En
lo que respecta al apartado b) en igualdades de condiciones con conexiones no privilegiadas, en
un buffer que ha alcanzado su umbral no se almacenarán células con el CLP = 1, las cuales serán
descartadas, mientras que las células con su CLP = 0 sí se almacenarán hasta que se llegue al
límite de capacidad del buffer.
10.5. Traffic Shaping
El moldeado de tráfico es un mecanismo que altera las características de tráfico de un flujo
de células de una conexión para conseguir mejor eficiencia mientras que se consiguen los
objetivos de QoS.
Debido a que esta técnica va principalmente dirigida a la consecución de parámetros de QoS
hemos decidido obviarla en nuestro simulador.
10.6. Explicit Forward Congestion Indication
La aplicación de técnicas de indicación de congestión ascendente explícita (EFCI) es
opcional para una red ATM.
Un elemento de red en un inminente estado de congestión o ya en él puede establecer en
EFCI en la cabecera de la célula para que esta indicación pueda ser examinada por los terminales
sumideros de las conexiones. Por ejemplo, una fuente puede usar este indicador para implementar
un protocolo que de forma adaptativa disminuye la velocidad de la conexión durante las
congestiones o posibles congestiones inminentes. Un elemento de red que no esté en estado de
congestión o en un estado de congestión inminente no modificará el valor de este indicador. Un
estado de congestión inminente es aquel en el que el elemento de la red está operando alrededor
de su capacidad máxima calculada.
70
Simulador de Tráfico ATM con Garantía de Servicio
Este servicio ha sido desarrollado para categorías de servicio CBR, VBR y UBR. Como
veremos posteriormente para ABR existe otro mecanismo de control de congestiones en los
terminales el cual se encuentra implementado parcialmente en nuestro simulador. En el capítulo
12 presentamos las categorías de servicios que soportaría el simulador (ABR y UBR) y las
razones de esta elección. Dado que la categoría UBR la incluimos para las conexiones a las que
no queremos que se le aplique ningún mecanismo de prevención de congestiones, y que la ABR
tiene el suyo propio, no creemos necesario incluir este mecanismo, el EFCI, en nuestro simulador.
10.7. Resource Management using Virtual
Paths
Los Virtual Paths son un concepto importante del control de tráfico y la gestión de
recursos en las redes ATM. En relación con el control de tráfico, los VPCs se pueden utilizar
para:
•
•
•
Simplificar el CAC;
Implementar una forma de control de prioridades segmentando grupos de conexiones
virtuales de acuerdo a su categoría de servicio.
Conseguir una forma eficiente de distribuir mensajes para las operaciones de control de
tráfico (por ejemplo indicar congestión en una red distribuyendo un mensaje simple para
todos los VCCs de un VPC determinado);
Los VPC también juegan un papel clave en la gestión de recursos. Mediante la reserva de
capacidad para los VPC, el tiempo de establecimiento de VCCs se reduce. En definitiva, mediante
el agrupado de VCCs en VPCs obtenemos dos niveles de abstracción; por una parte podemos
abstraer el control de un gran número de conexiones con requerimientos similares al control de un
solo VPC y por la otra podemos manejar las características los VCCs dentro de un VPC sin tener
que preocuparnos de los cientos o miles de VCCs presentes en otros VPCs.
10.8. Frame Discard
Si un elemento de la red necesita descartar células, en muchos casos es más efectivo un
descarte a nivel de marcos que a nivel de células. Un marco en una unidad de protocolo AAL. La
red detecta los marcos examinando el campo SDU-type en el payload de la célula de cabeza. El
descarte de marcos puede ayudar a evitar el colapso por congestión e incrementar el goodput.
Como se explica en el capítulo 15, los conmutadores activos de nuestro simulador
contienen buffers de salida con mecanismos de control de congestión que evitan la fragmentación
de PDUs. Uno de las acciones que realiza este mecanismo es el descarte de marcos que se prevé
no cabrán enteros en el buffer. Por lo tanto se puede decir que en el simulador se implementa un
procedimiento de descarte de marcos.
71
Simulador de Tráfico ATM con Garantía de Servicio
10.9. Generic Flow Control
El campo GFC está presente sólo en las células entre un host y la red; es sobrescrito por
el primer conmutador al que llega, por lo que no tiene un significado de terminal a terminal, y no
se entrega al destino. Originalmente se pensó que este campo tendría alguna utilidad para el
control de flujo o de prioridad entre los hosts y las redes, pero no hay valores definidos para él, y
la red lo ignora. Por tanto el uso del campo GFC de las células en la interfaz UNI no se contempla
en este documento. No hay valores definidos para el GFC y nuestro simulador, por tanto nunca es
examinado.
10.10. ABR Flow Control
En el servicio ABR, la fuente adapta su velocidad para adaptarse a las condiciones de la
red. La información acerca del estado de la red como la disponibilidad de ancho de banda, estado
de congestión y congestión inminente se comunica a la fuente mediante células de control
especiales llamadas Resource Managemente Cells (células RM).
Nuestro simulador soporta la categoría ABR junto con una versión simplificada del
modelo de control de flujo ABR. Para ver la descripción de este modelo y ver el capítulo 3
dedicado a la implementación de las categorías de servicio ABR y UBR.
11. Categorías de servicio
implementadas
Para los propósitos de nuestro simulador hemos implementado las categorías de servicio
ABR y UBR con limitaciones. Las razones de esta elección son varias:
Primeramente por la naturaleza del tráfico que se va a simular ya que las categorías de
servicio ABR y UBR son la propuesta estándar de ATM para soportar el tráfico de datos, que
precisamente es el tipo de datos para el que está pensada la GoS.
Por otra parte, mientras que ABR tiene la capacidad de reducir su ritmo de envío de
tráfico mediante realimentación con células BRM si se producen congestiones en la red, la
categoría UBR no hace promesas y no realimenta información sobre los congestionamientos. En
nuestra simulación, en algunas ocasiones forzaremos a que en algún conmutador se produzca
congestión para observar el comportamiento del protocolo TAP ante tales situaciones. Si tan solo
utilizáramos la categoría de servicio ABR, al tener un sistema autorregulador de flujo ante
congestiones, no podríamos estudiar de manera aislada los mecanismos activados por el protocolo
TAP y su impacto en el entorno de la simulación. En el otro extremo, si tan solo
implementáramos la categoría UBR, no podríamos comprobar el funcionamiento conjunto del
protocolo TAP junto con los sistemas de realimentación de ABR y dar una medida del auténtico
72
Simulador de Tráfico ATM con Garantía de Servicio
potencial de ambos mecanismos funcionando conjuntamente para la prevención de congestiones
por un lado y la minimización de los prejuicios ocasionados por ellas por el otro.
Otra razón para elegir aquellas dos categorías es que a pesar de que el protocolo TAP se
propuso principalmente para la categoría UBR necesitamos una referencia con alguna otra
categoría de servicio y sus formas de combatir o prevenir la congestión para comparar resultados
y sacar conclusiones. Con una VPN simulada en la que pudiesen convivir conexiones tanto ABR
como UBR tendríamos una base para poder crear gran cantidad de supuestos y situaciones que
ajustasen a nuestros requerimientos y poder demostrar, en la medida de nuestras posibilidades,
con casos prácticos, la viabilidad del protocolo TAP en una VPN real.
Por otro lado, al prescindir de las otras dos categorías de servicio especificadas para ATM
(CBR y VBR) no podremos comprobar el impacto de añadir conexiones que requieran una alta
calidad de servicio de tiempo real en el comportamiento de la VPN ya que nuestra versión de
ABR y UBR no requieren limitaciones en el retado ni en la variabilidad de retardo. Sin embargo,
al estar la propuesta TAP dirigida al tráfico de datos sin requerimientos de tiempo real, no
consideramos necesario la inclusión de las categorías antes citadas.
11.1. Las categorías de servicio ABR y UBR
Estas categorías de servicio están pensadas, como apuntamos en la introducción al
capítulo, para aplicaciones sin requerimientos de tiempo real. Se diferencian entre ellas en la
naturaleza de los servicios proporcionados por la red y los mecanismos que se implementan en
los sistemas terminales y la red para proporcionarlos. La elección de una categoría de servicio
será específica para cada aplicación.
11.2. ABR-l
En este apartado vamos a describir las características de esta categoría de servicio en
nuestro simulador. Como avisamos en el apartado anterior, se han suprimido todos los
mecanismos derivados de la introducción de la QoS y otros muchos han sido simplificados. Con
el fin de diferenciar la categoría de servicio que nosotros implementamos con la especificada por
la ITU-T, a la nuestra la denominamos ABR-l (ABR little)
11.2.1. Modelo de servicio detallado para ABR-l
Los siguientes puntos resumen algunas propiedades del servicio ABR-l:
•
•
El objetivo del servicio ABR-l es proveer rápido acceso al ancho de banda no usado por la
red hasta el límite de PCR, siempre que la red tenga ancho de banda disponible.
Debe ser aplicable tanto a VCCs como a VPCs.
73
Simulador de Tráfico ATM con Garantía de Servicio
•
•
•
•
•
El MCR se negocia independientemente para cada dirección en una conexión bidireccional
ABR-l. Una fuente puede que esté obligada a enviar a una velocidad menor que MCR cuando
se está negociando una MCR > 0.
La velocidad de envío de una fuente en una conexión nunca será menor que MCR. El MCR
negociado variará entre cero y el mayor valor soportado por la red. Este valor máximo puede
ser igualmente cero. Si la fuente no indica un MCR, se supondrá el valor por defecto que es
cero.
A cada conexión se le asignará el valor máximo de MCR que el ancho de banda de la red
pueda soportar por estricto orden temporal de llegada de peticiones de conexión. Hemos
querido que sea así, en contrapartida a la asignación justa de recursos de la red que se aplica
en redes ATM reales, para proporcionarnos la posibilidad de provocar congestiones en
elementos específicos de la red.
Aunque la red se compromete a soportar el MCR de cada fuente, puede que alguna reciba
indicaciones de reducir esta velocidad bajo el MCR. Si alguna fuente recibe la indicación de
bajar la velocidad por debajo de su MCR lo que debe hacer es reducirla hasta el MCR. Si una
fuente está transmitiendo al MCR y recibe indicaciones de bajar la velocidad, la fuente no
necesitará hacer ningún cambio.
Durante el establecimiento de conexiones para una conexión con un MCR = 0, el CAC no
bloqueará dicha conexión por causa del ancho de banda reservado para otras conexiones.
Realmente el CAC en nuestro simulador únicamente avisa si una conexión tiene probabilidad
de provocar congestiones sin tomar ninguna decisión.
11.2.2. Modelo de control de flujo para ABR-l
El control de flujo ABR sucede entre la fuente y el sumidero de una conexión. Las
fuentes y destinos se encuentran conectadas mediante conexiones bidireccionales. En aras de la
simplicidad en nuestro simulador los flujos de datos serán unidireccionales, de la fuente al
sumidero, mientras que solo las células RM y las de señalización asociada a la conexión
circularán en sentido descendente. La dirección ascendente es la que va desde la Fuente hasta el
sumidero mientras que la descendente es en sentido contrario. Para el flujo de información
ascendente existe un bucle de control de dos flujos de células RM, uno ascendente y otro
descendente. La fuente generará células RM ascendentes que darán la vuelta al llegar al sumidero
y volverán a su origen (FRM si son ascendentes o BRM si son descendentes) Las BRM llevan
información de realimentación suministrada por los conmutadores de la red.
En una red ATM real un elemento de red puede:
•
•
•
Insertar directamente información de realimentación en las células RM cuando pasa en la
dirección ascendente o descendente.
Informar indirectamente a la fuente acerca de una congestión estableciendo el bit EFCI en la
cabecera de las células de datos en la dirección ascendente del flujo de información. En este
caso el sumidero actualizará la BRM basándose en esta información de congestión.
Generar BRMs.
En nuestra simulación, para el control de congestiones utilizamos el primer y el tercer
método. Como indicamos en el capítulo 2 no utilizaremos el control de flujo basado en EFCI.
Emplearemos el primer método para el control de congestiones normalizado de ABR-l. Además
74
Simulador de Tráfico ATM con Garantía de Servicio
el método utilizado para dar a conocer la situación en la que se detecta la pérdida de una trama
congestionada con el fin de solicitar retransmisiones será el tercero.
11.2.3. Parámetros de servicio ABR-l
En esta sección presentamos los parámetros utilizados en el simulador para implementar
al control de flujo ABR-l. En el servicio ABR real existen algunos parámetros más pero han sido
suprimidos por no ser necesarios en nuestro nivel de simulación
Parámetro
PCR
MCR
ICR
RIF
RDF
ACR
Descripción
La velocidad de célula pico, Peak Cell Rate, es la
velocidad que la fuente nunca excederá.
La velocidad mínima de célula, Minimum Cell Rate, es
la velocidad a la que la fuente le está siempre
permitido enviar
La Velocidad de Célula Inicial, Inital Cell Rate, es la
velocidad a la que la fuente envía inicialmente.
El Factor de Incremento de Velocidad, Rate Increase
Factor, controla el aumento de velocidad que la fuente
puede aplicar tras recibir una célula RM
El Factor de Decremento de Velocidad, Rate Decrease
Factor, controla el decremento de la velocidad de
transmisión.
La Velocidad de Célula Permitida, Allowed Cell Rate,
es la velocidad actual a la que la fuente se le está
permitido enviar.
Unidades y rango
Células/seg
Céluas/seg
Células/seg
Potencia de dos, desde
1/32768 hasta 1
Potencia de dos
Células/segundo
Tabla 11.1: Parámetros de servicio ABR-l
Los parámetros señalados en negrita se negocian durante el establecimiento de la
conexión. Si no se especifica algún parámetro se sustituye por un valor por defecto.
11.2.4. Estructura de las células RM
La siguiente tabla muestra los campos y su posición en el formato de célula RM.
75
Simulador de Tráfico ATM con Garantía de Servicio
Tabla 11.2: Campos de una célula RM.
En nuestra simulación no utilizamos todos los campos anteriores. Como se explicó en el
capítulo 10, los bits del 21 al 51 se utilizan para las retransmisiones locales. Seguidamente los
parámetros utilizados para la implementación del control de flujo ABR-l.
•
•
•
•
Header: Los cinco primeros bytes de una célula RM corresponden a la cabecera estándar de
una célula ATM con PTI = 110 (binario), y CLP = 1.
DIR: indica la dirección del flujo RM. Si es ascendente DIR = 0 y si es descendente DIR = 1.
Cuando la célula llega al destino DIR cambia de 0 a 1.
CI: Cuando una fuente detecta una BRM con este bit a 1 entonces decrementará su ACR.
NI: Este bit se utiliza para indicar a una fuente que no aumente su ACR. Puede ser utilizado
por un conmutador para indicar congestiones inminentes.
11.2.5. Comportamiento de la fuente
1. El valor de ACR nunca excederá el valor de PCR ni será menor que MCR.
2. Antes de que una fuente envíe su primera célula después del establecimiento de una conexión
establecerá ACR a ICR.
3. Se enviará una FRM cada 32 células de datos. En un servicio ABR real la cadencia de envíos
de células FRM depende de diversos parámetros como Mrm y Nrm. Hemos considerado una
cadencia de células RM fija para simplificar la implementación.
4. Cuando una fuente recibe una célula BRM con el bit CI = 1 entonces la fuente reducirá su
ACR por lo menos en ACR * RDF, a no ser que de esta reducción resulte un valor menor
que MCR en cuyo caso se establecería ABR = MCR. Si en la célula BRM CI = 0 y NI = 0
entonces la fuente debe incrementar ACR en no más del RIF * PCR, a un valor no mayor que
PCR. Si NI = 1 entonces la fuente no incrementará ACR.
76
Simulador de Tráfico ATM con Garantía de Servicio
11.2.6. Comportamiento del sumidero
En nuestro servicio ABR-l el sumidero actuará únicamente como “pared” donde
rebotarán las células FRM emitidas por la fuente.
1. Cuando recibe una célula FRM el sumidero debe transmitir la célula en sentido contrario para
devolverla a la fuente. Cambiará el bit DIR de ascendente a descendente.
2. En nuestro ABR-l, por la misma razón que en punto anterior, un sumidero no podrá generar
células BRM.
11.2.7. Comportamiento de los conmutadores
Nuestros conmutadores implementan un método de control de flujo basado en los campos
CI y NI.
1. Un conmutador puede generar una célula BRM a alguna fuente cuando detecta que alguno de
sus puntos de encolamiento está a punto de experimentar una congestión (con lo que generará
una BRM con el bit NI = 1) o cuando detecta una congestión (generará una BRM con el CI =
1) La velocidad máxima de creación de estas células no sobrepasará las 10 células / s. El bit
BN = 1 y DIR = 1
2. Cuando a un conmutador llega una RM ya sea ascendente o descendente, seguirá la política
descrita en el punto 1 para los bits CI y NI y posteriormente la enviará por donde
corresponda.
11.2.8. Algoritmos en pseudocódigo
Seguidamente presentamos el algoritmo utilizado en la fuente y el sumidero de una
comunicación ABR-l.
•
Inicialización por conexión
ACR = ICR
Time_to_send = 32
•
Pseudocódigo de envío en la fuente
if now >= time_to_send then
send RM(DIR=forward, CI=0, NI=0, CLP=1)
now = 0;
end if;
| Si es el momento de enviar
| Enviamos RM
now es un contador que almacena el número de células de datos que se han enviado.
Cuando el valor llega a time_to_send, indica que es el momento de insertar una célula RM en el
tráfico.
77
Simulador de Tráfico ATM con Garantía de Servicio
•
Pseudocódigo de recepción en la fuente
If receive RM(DIR = backward, CI, NI, BN) then
If CI=1 then
ACR = ACR – ACR*RDF;
ACR = max(MCR, ACR);
Else if NI = 0 then
ACR = ACR + RIF*PCR;
ACR = min (ACR, PCR);
End if
End if
•
| Ajustamos ACR
| Si congestión
| Disminuimos
| Si no inminente
| Aumentamos
Pseudocódigo de recepción en el sumidero
If receive RM(DIR= forward, CI, NI, BN) then | Acción de rebote
Send RM(DIR=backward, CI, NI);
End if;
11.3. UBR-l
Como hicimos con ABR, creando nuestra propia versión ABR-l, a la adaptación de la
clase de servicio UBR la llamaremos en adelante UBR-l.
En esta categoría de servicio la fuente de la comunicación emite a una tasa constante de
células dada por PCR. Los conmutadores aceptan todas las células UBR-l y, si sobra capacidad,
también se entregan. Si ocurren congestionamientos, se descartan las células UBR-l sin
realimentación a la fuente y sin esperar que ésta reduzca su velocidad. La categoría UBR es
razonable para aplicaciones que no tienen restricciones de entrega y quieren llevar ellas mismas
su propio control de errores y de flujo. Proponemos como posible utilización de las fuentes UBRl en nuestro simulador la de focos generadores de congestiones.
78
Simulador de Tráfico ATM con Garantía de Servicio
SIMULACIONES
12. Simulaciones
En este módulo vamos a exponer los resultados obtenidos en la simulación de diferentes
topologías con diversas conexiones. Como objetivo principal nos proponemos demostrar los
beneficios resultantes de introducir conmutadores AcTM en redes ATM. Estos beneficios serán
consecuencia de las retransmisiones locales entre conmutadores AcTM en contraposición a las
retransmisiones extremo a extremo propias de protocolos de capas superiores como, por ejemplo,
el TCP/IP.
En una red con AcTMs, al congestionar una trama en un conmutador AcTM, éste enviará
una petición de retransmisión de dicha trama congestionada en la trayectoria inversa a la seguida
por ella en una célula RM. Un conmutador AcTM que reciba una petición de retransmisión deberá
buscar en su memoria DMTE la trama solicitada. Si está presente se retransmitirá hacia el
solicitante, en caso contrario la petición se propagará hacia conmutadores anteriores. En la
realización de este proceso aparentemente sencillo intervienen multitud de factores y elementos.
Además, el usuario, a la hora de configurar la red y las conexiones, puede intervenir en algunos
de aquellos factores y elementos alterando parámetros configurables. En los siguientes puntos
exponemos algunos de estos factores y elementos con sus consecuencias previstas en el tráfico:
•
•
•
•
•
•
Ubicación de AcTMs: En una topología mixta donde coexistan conmutadores activos y no
activos debería ser importante la colocación de los AcTMs. Se intuye que cuanto más cerca
estén los conmutadores activos entre si, mayor será el beneficio de las retransmisiones
locales.
Delays: por la misma razón anterior el delays entre conmutadores activos es importante e
influyente ya que provocarán mayor lentitud en las retransmisiones.
Tamaños de memoria: Es un parámetro configurable muy importante por una razón muy
sencilla, cuanto mayor sea la memoria disponible en el buffer o DMTE en los conmutadores
menor será la posibilidad de congestión y mayor la de retransmisión local.
GoS: El parámetro de garantía de servicio en una conexión privilegiada tendrá mucha
importancia a la hora de la realización de las retransmisiones locales ya que cuanto mayor sea
éste mayor será la probabilidad de que aquéllas puedan ser realizadas con éxito.
Algoritmos: Los algoritmos predominantes que pueden alterar el comportamiento del tráfico
son el EPDR y el WFQA. El principal de ellos es el EPDR. Mediante la alteración del valor
del umbral el usuario debería ser capaz de configurar el buffer de un conmutador AcTM para
que se comporte de manera óptima según el tráfico predominante. El WFQA tendrá más
relevancia cuanto más diferentes sean las velocidades de salida contratada para las fuentes ya
que este algoritmo da prioridad a las conexiones procedentes de fuentes más rápidas.
Tamaños de trama EAAL: Debería tener influencia directa sobre el comportamiento del
algoritmo EPDR. Cuanto mayor sean las trama menores posibilidades habrá de que ésta
quepa en el búfer según los requisitos de EPDR.
79
Simulador de Tráfico ATM con Garantía de Servicio
En posteriores apartados nos dedicaremos a comprobar y ratificar o corregir las
afirmaciones hechas en los anteriores puntos. Para ello expondremos los resultados obtenidos
mediante la realización de múltiples simulaciones mediante el paquete software desarrollado para
este proyecto. Todos los archivos obtenidos (.top, .fis, .dgs, .cfg) en la realización de estas
simulaciones están almacenados en el CD adjunto a este documento para posibilitar así la
verificación de los resultados obtenidos.
12.1. La Topología Base
Para poder comparar los resultados obtenidos en las diferentes simulaciones éstas deben
realizarse sobre topologías similares. Partiremos pues de una topología común que
modificaremos ligeramente para observar las consecuencias de dichas modificaciones. La
topología elegida es la siguiente:
Fig 22.1: Topología de base.
Los elementos que intervienen en ella son los siguientes:
• Conmutadores: Partimos de una red cuyos conmutadores son es su totalidad activos. En un
posterior apartado estudiaremos qué ocurriría con topologías mixtas.
• Fuentes: Hemos creado cuatro fuentes ATM para crear tráfico de fondo (nativo ATM), una
fuente EAAL que creará tráfico con requerimientos de GoS y una fuente AAL sin
requerimientos de GoS.
• Sumideros: Existen dos sumideros para recibir el tráfico de fondo y un sumidero por cada
fuente AAL y EAAL. Cada uno recibirá el tráfico correspondiente a su nombre.
80
Simulador de Tráfico ATM con Garantía de Servicio
Esta topología está pensada para crear situaciones de congestión en los conmutadores
CA_6 y CA_7. Esto se consigue gracias al tráfico creado por las fuentes F_ATM_x. Estas fuentes
envían al conmutador al que están conectados tráficos a ráfagas en forma de células ATM a una
velocidad superior a la que el conmutador es capaz de sacarlo del buffer. Lo que se pretende es
que le búfer se llene y se vacíe alternativamente para poder comprobar el comportamiento del
tráfico de tramas en distintos valores de llenado de búfer. Por cada uno de los dos conmutadores
potencialmente congestionables circularán las tramas creadas por las fuentes AAL y EAAL de
manera que el tráfico EAAL atravesará CA_6 y el tráfico AAL atravesará el CA_7. La gráfica de
llenado de búfer de los conmutadores CA_6 y CA_7 es la siguiente:
Gráfica 22.2: Gráfica de variación de llenado del buffer en relación al tiempo.
Como alternativa podríamos optar por conexiones ABR adaptativas cuyo tráfico podría
ser similar en lo referente a los picos y los valles. Sin embargo este tipo de tráfico podría
oscurecer los resultados obtenidos debido a su misma variabilidad con las condiciones del búfer.
Lo que buscamos en un tráfico de fondo constante y fijo donde poder comparar distintos factores
variables.
El delay de todos los cables ha sido ajustado a 2-4ms de manera que podamos establecer
un valor de tick de 100ns lo que aumentará la velocidad de simulación al tiempo de que el
decremento del realismo es suficientemente pequeño como para que los resultados obtenidos sean
representativos.
Las velocidades de portadora han sido establecidas en 107 células/segundo (alrededor de
unos 4.2 Gbps). Como excepción nos encontramos con la portadora que llega hasta los sumideros
ATM. Con el fin de que el llenado de los búferes fuera más fácil se ha establecido este valor a
4.5x106 (aproximadamente 1.9 Gbps).
Se realizarán todas las simulaciones a una duración máxima de 4.3 milisegundos
simulados. Consideramos que es tiempo suficiente como para obtener resultados representativos
teniendo en cuenta el tráfico de fondo generado.
81
Simulador de Tráfico ATM con Garantía de Servicio
12.2. Comportamiento del tráfico de tramas
con relación al umbral.
En este apartado vamos a fijarnos primeramente en el efecto del umbral en el tráfico de
tramas. Para ello hemos realizado múltiples simulaciones para distintos valores de umbral y
distintos valores de tamaños de trama. Nuestro propósito es comprobar primeramente que el
tráfico EAAL mejora con respecto al AAL en el sentido de que llegan más tramas correctas EAAL
al sumidero destino que con AAL evitando así las retransmisiones de protocolos superiores al
TAP como, por ejemplo, TCP/IP. Así mismo queremos también demostrar que el valor del
umbral debe ser establecido en relación al tamaño medio de las tramas EAAL que circulan por un
conmutador en congestión.
Las conexiones AAL y EAAL que intervendrán en la topología presentan la siguiente
configuración:
Conexion
Nombre: conEAAL
Destinos: S_EAAL_1
VPI VCI: 1 1
Inicio: 0.0
Duracion: 4.0
TipoTrafico: EAAL
Tamaño: 16
GoS: 9
TipoCos: UBR
PCR: 366792.44
Conexion
Nombre: conAAL
Destinos: S_AAL_1
VPI VCI: 1 1
Inicio: 0.0
Duracion: 4.0
TipoTrafico: AAL
Tamaño: 16
TipoCos: UBR
PCR: 366792.44
Cuadro 22.1: Conexiones de tramas programadas.
Es necesario señalar que se ha provisto a las conexiones EAAL de un tamaño suficiente
de GoS para suministrar todas las retransmisiones que sean necesarias. Así mismo la memoria
DMTE es suficientemente grande como para contener las tramas solicitadas en el grado GoS. En
posteriores apartados veremos el efecto de estos valores sobre el tráfico.
Primeramente nos centraremos sobre el tráfico EAAL y veremos el número de tramas que
llegan correctamente al sumidero S_EAAL_1 que es el destino de las tramas mandadas por la
fuente F_EAAL_1.
82
Simulador de Tráfico ATM con Garantía de Servicio
90
80
70
60
50
40
30
20
10
0
Tramas
recibidas
Tamaño trama
(células)
64
32
16
70% 80%
64
90%
95%
99% 100%
Tamaño del umbral (con relación al
tamaño del buffer)
70%
80%
90%
95%
99%
100%
64
21
21
21
23
22
17
32
43
43
44
44
45
34
16
80
84
84
84
86
73
Gráfica 22.2: Comparación de las tramas EAAL llegadas correctamente al sumidero S_EAAL_1.
De esta gráfica deducimos varias cosas:
1-
2-
La primera de ellas es que con valores de umbral inferiores a 100% (donde no actuará
éste y por lo tanto no habrán solicitudes de retransmisión) todas las tramas enviadas
llegarán a su destino correctamente. La fluctuación que se observa en los valores se
debe a las tramas in-flight, es decir, a las tramas que se encuentran en los cables y no
han llegado a un conmutador. Este hecho se ha deducido estudiando el fichero FIS de
cada una de las simulaciones
Cuando no actúan las retransmisiones, es decir, cuando el valor del umbral está al
100% y EPDR no actúa, hay tramas que se pierden debido a las congestiones y que
deberán ser recuperadas por protocolos superiores. En la gráfica 4 se demuestra cómo
aun sin actuar el EPDR el tráfico mejora considerablemente con tramas EAAL con
respecto a las AAL.
En la siguiente gráfica observamos los mismos valores anteriores pero traducidos a
número de células que llegan al sumidero S_ EAAL_1. De esta forma observaremos más
fácilmente el porcentaje de información que llega a dicho sumidero.
83
Simulador de Tráfico ATM con Garantía de Servicio
1600
1400
1200
1000
Bytes recibidos
800
64
600
32
400
16
200
0
70%
80%
90%
95%
16
32
64
99%
100%
Tamaño del umbral (con relación al tamaño del
buffer)
70%
80%
90%
95%
99%
100%
64
1344
1344
1344
1472
1408
1088
32
1376
1376
1408
1408
1440
1024
16
1280
1344
1344
1344
1376
1168
Gráfica 22.3: Comparación de los bytes totales llegados correctamente al sumidero S_EAAL_1.
En esta gráfica podemos observar que para mayor longitud de trama se observa más
información in-flight observándose las fluctuaciones más elevadas en porcentajes elevados del
umbral. Esto es consecuencia del tamaño de la trama, cuanto más grande sea la trama mayor
información contendrá y más células se encontrarán in-flight. Observamos de nuevo el menor
número de información recibida por el sumidero cuando no actúa el algoritmo EPDR.
En la anterior gráfica hemos visto como el tráfico se degrada cuando el algoritmo EPDR
no actúa en un conmutador activo que despacha tramas EAAL. En la gráfica que a continuación
mostramos comparamos el rendimiento de esta conexión EAAL con la conexión AAL que circula
paralela a ella. La conexión AAL atraviesa por elementos idénticos a la EAAL y con tráfico de
fondo también idéntico. Además su configuración es igual a la EAAL con la salvedad, claro está,
de que no tiene GoS.
84
Simulador de Tráfico ATM con Garantía de Servicio
80
Tamaño trama
(células)
70
60
64
50
Tramas
recibidas
32
40
16
30
20
10
16
0
64
EAAL
EAAL
AAL
AAL
Correctas Corruptas Correctas
Corruptas
Tipo de trama y corrección
a su llegada al sumidero.
EAAL Correctas
EAAL Corruptas
AAL Correctas
AAL Corruptas
64
17
0
7
15
32
34
0
28
14
16
73
0
68
16
Gráfica 22.4: Tramas EAAL y AAL llegadas correctas y corruptas a los sumideros S_EAAL_1 y
S_AAL_1 respectivamente con el umbral al 100%.
Esta gráfica es muy representativa. Se puede observar cómo a pesar de no actuar el
sistema de control del búfer ni el sistema de retransmisiones, el tráfico EAAL se ve mejorado
sensiblemente con respecto al AAL en el sentido de que las tramas corruptas que circulan por la
red son nulas. Esto es debido a que el conmutador CA_9 desecha todas las tramas no correctas
procedentes de conexiones EAAL. Esta labor la realiza el agente CoSa en los conmutadores
activos. Como consecuencia, mientras que las tramas AAL corruptas siguen circulando por la red
ocupando ancho de banda de forma innecesaria, las tramas corruptas de conexiones EAAL
desaparecerán en el siguiente conmutador activo por el que vayan a cruzar.
Además se puede ver que las tramas recibidas correctamente con tráfico EAAL son
superiores a las recibidas con tráfico AAL. Esto no es debido a las retransmisiones ya que con el
umbral al 100% un conmutador no realiza peticiones de retransmisión. El motivo de esta mejora
es debido al agente CoSa junto con la forma del tráfico de fondo. Éste agente retiene las tramas
EAAL hasta que están completas antes de enviarlas a que sean conmutadas. En un tráfico de
fondo a ráfagas, como el diseñado para esta topología, el hecho de inyectar la trama entera al
buffer provoca que sea más probable que todas las células de la trama sufran la misma suerte. Por
lo tanto, como el búfer está menos tiempo lleno que semi-lleno congestionarán menos tramas. En
el caso de las tramas AAL las células pertenecientes a éstas son conmutadas e introducidas en el
85
Simulador de Tráfico ATM con Garantía de Servicio
búfer al mismo ritmo al que llegan, sin reensamblado. Por tanto, al tardar más tiempo una trama
en ser conmutada, hay más probabilidades de que coincida su almacenamiento en el búfer con
una etapa de congestión de éste.
En anteriores párrafos hemos visto cómo el nivel del umbral no es decisivo a la hora del
número de tramas que llegan a un sumidero destino, a excepción de un umbral al 100% por
razones ya explicadas. Sin embargo hemos apuntado el hecho de que se producen congestiones y
que se pierden células pertenecientes a tramas. En posteriores gráficas veremos en qué influye el
umbral en la existencia de congestiones y en las peticiones de retransmisión de tramas.
25000
20000
15000
Tam.
trama
Células
descartadas 10000
64
32
5000
16
0
70%
80%
16
90%
64
95%
99%
Tamaño del umbral (con relación al
tamaño del buffer)
100%
70%
80%
90%
95%
99%
100%
64
8896
4376
2177
1689
4586
256
32
15700
8446
3130
1839
3686
697
16
20756
11914
4420
2061
1038
661
Gráfica 22.5: Comparación de las células descartadas en el conmutador CA_9 en función del
tamaño de trama.
En la anterior gráfica se muestran las células que se descartan en el conmutador CA_9
como consecuencia de descartes de células realizados por el EPDR o por congestiones. Vemos
cómo a medida que aumentamos el porcentaje del umbral disminuyen el número de células
descartadas pero sólo hasta un cierto valor. En la gráfica se observa cómo en el porcentaje del
99% en un búfer de 1000 células el número de células descartadas vuelve a crecer. Hay varias
razones para este comportamiento:
1- Según el comportamiento del EPDR si al ir a conmutar la primera célula de una trama
EAAL se observa que el nivel de llenado del búfer ha sobrepasado al umbral, esta célula
86
Simulador de Tráfico ATM con Garantía de Servicio
se descarta, junto con las células pertenecientes a la misma trama que se conmuten con
posterioridad. Por lo tanto, a menor nivel de umbral es más probable que se descarte una
trama.
2- El hecho del repunte de tramas descartadas en un umbral con porcentaje al 99% lo
explicaremos mejor a partir de la siguiente gráfica:
Gráfica 22.6: Comparación de los niveles de llenado del búfer del conmutador CA_6 en umbrales
al 95% y al 99%.
En la gráfica se ve cómo para valores elevados de llenado del buffer se producen muchas
más congestiones con el búfer al 99% que con el búfer al 95%. Analizando el FIS vemos
que esto se debe concretamente a que se intenta introducir una trama en el búfer que no
va a caber. Según el algoritmo EPDR, cuando se conmuta la primera célula de una trama
se comprueba primeramente si cabe según el umbral, si es así se introduce, si no se
descarta junto con las células pertenecientes a la misma trama que aparezcan a
continuación. El problema surge cuando el espacio entre el umbral y el búfer está muy
cercano al tamaño de trama. En este caso será más probable que la trama comience a
introducirse por debajo del umbral, que lo sobrepase y que finalmente haya que descartar
alguna de sus células al no caber físicamente el búfer. El hecho de que se descarten
menos células (con un umbral al 99%) a medida que disminuimos el tamaño de trama
corrobora nuestra explicación.
Los hechos descritos anteriormente pueden verse en la gráfica de retransmisiones
solicitadas que vemos a continuación:
87
Simulador de Tráfico ATM con Garantía de Servicio
Tamaño trama
(células)
1400
1200
1000
64
800
Retrans.
Solicitadas
32
600
16
400
200
0
70% 80%
90%
64
95%
99% 100%
Tamaño del umbral (con relación al
tamaño del buffer)
70%
80%
90%
95%
99%
100%
64
128
68
24
17
78
0
32
468
241
76
36
111
0
16
1232
689
231
86
26
0
Gráfica 22.7: Comparación de las retransmisiones solicitadas por el conmutador CA_6 al
conmutador CA_4.
En esta gráfica anterior se ve más claramente el efecto del umbral sobre el descarte de
tramas. Las diferencias tan grandes de descartes entre tamaños de tramas se deben a que se envían
más tramas de 16 células que de 32 y que de 64; sin embargo los bytes mandados por la fuente
F_EAAL_1 son los mismos. Así mismo se ve que se descartan más tramas de 32 que de 64
células con el umbral al 99%. Este hecho se debe a que las retransmisiones de tramas de 32
células son más rápidas al tenerse que enviar menor número de células.
12.3. Influencia del EPDR en la
fragmentación
Un hecho importante y nocivo para las redes que pretende evitar el EPDR es la
fragmentación de tramas, es decir, se pretende evitar que continúen tramas EAAL a las que se les
ha congestionado alguna célula y por lo tanto ha tenido que ser descartada. En este apartado
pretendemos estudiar cómo afecta el umbral al número de tramas fragmentadas que, a pesar del
EPDR, continúan hacia el sumidero destino. Para estudiar este hecho hemos de modificar la
88
Simulador de Tráfico ATM con Garantía de Servicio
topología base para evitar que el último conmutador, el agente CoSa del CA_9, elimine aquellas
tramas que detecta fragmentadas; por ello hemos sustituido este conmutador por un conmutador
no activo, el CNA_1 que comparte la misma configuración en los elementos comunes. La nueva
topología se muestra en la figura 22.8.
Figura 22.8: Topología mixta con conmutadores no activos finales.
Para estudiar el efecto de la fragmentación nos concentraremos en simulaciones creadas
sobre tramas de tamaño fijo de 32 células. Como elementos cambiantes tendremos el porcentaje
del umbral. Estudiaremos la fragmentación de las EAAL en contraste con las conexiones AAL las
cuales no se beneficiarán directamente de los mecanismos del EPDR.
Podemos ver en la gráfica 22.9 los resultados obtenidos. Observamos que las tramas AAL
se fragmentan a un ritmo constante independientemente del valor del umbral. Esto es lógico si
tenemos en cuenta que el algoritmo EPDR no actúa sobre conexiones AAL sino únicamente sobre
las conexiones EAAL por lo que el valor del umbral para las primeras no tiene ninguna
influencia. Por otro lado siempre llegan más tramas correctas que incorrectas siendo las segundas
aproximadamente el 43% de las tramas totales recibidas por el sumidero.
En cuanto a la fragmentación de las tramas EAAL hemos obtenido una gráfica muy
parecida a anteriores gráficas. Al igual que con las células descartadas y las peticiones de
retransmisiones, las tramas fragmentadas descienden a medida que aumenta el umbral, a
excepción del fenómeno ya conocido del repunte en el porcentaje al 99%. La explicación se debe
a que cuando por acción del umbral se descarta una trama, si la célula EOM de dicha trama cabe
en el búfer, ésta se introduce aunque se haya descartado todas las células de información de la
trama. Sin embargo el repunte no aparece tan pronunciado como en anteriores gráficos. Esto es
debido a la misma circunstancia anterior, a que le EOM sólo se introduce en el caso de que haya
89
Simulador de Tráfico ATM con Garantía de Servicio
espacio en el buffer. Por eso mismo es mucho menos probable en un búfer al 99% (casi al 100%)
de su capacidad quepa la célula EOM.
450
400
Tramas
recibidas
Tipo Trama
350
300
250
200
150
100
50
0
AAL
Corruptas
AAL
Correctas
EAAL
Correctas
EAALCorrup
tas
EAAL Correctas
70% 80%
90% 95%
AAL Corruptas
99% 100%
Tam año del um bral (con relación
al tam año del buffer)
70%
80%
90%
95%
99%
100%
AAL Corruptas
14
14
14
14
14
14
AAL Correctas
28
28
28
28
28
28
EAAL Correctas
43
43
43
43
42
34
EAALCorruptas
440
220
69
31
64
8
Gráfica 22.9: Proporción entre las tramas llegadas correcta e incorrectamente al sumidero
S_EAAL_1 para tramas de 32 células con distintos valores de umbral.
Para finalizar este apartado vamos a estudiar el efecto de los conmutadores activos, para
un umbral al 100% en conexiones EAAL y AAL. En la gráfica 22.10 se pueden observar los
resultados de este caso. De esta gráfica se obtienen dos conclusiones:
12-
Las conexiones EAAL mejoran con respecto a las AAL, aun sin el mecanismo de
retransmisiones.
Sin la actuación del EPDR se pierden muchas más tramas completas que con
conexiones AAL. Este hecho destaca más con conexiones de 64 células.
La explicación, que tiene que ver con al agente CoSa junto con la forma del tráfico de
fondo, se dio ya en el anterior punto.
90
Simulador de Tráfico ATM con Garantía de Servicio
90
Tamaño trama
(células)
80
70
Tramas
recibidas
60
64
50
32
40
16
30
20
10
0
EAAL
Bien
EAAL
Mal
64
AAL
Bien
AAL
Mal
Total
EAAL
Total
AAL
Tipo de trama y corrección
a su llegada al sumidero.
EAAL Bien
EAAL Mal
AAL Bien
AAL Mal
Total EAAL
Total AAL
64
17
2
7
15
19
22
32
34
8
28
14
42
42
16
73
10
68
16
83
84
Gráfica 22.10: Diferencia entre tramas correcta e incorrectamente llegadas según el tipo de
conexión con un umbral al 100%.
12.4. Influencia del tamaño del búfer del
conmutador congestionado
En este punto estudiaremos la influencia del tamaño del búfer sobre las conexiones
EAAL en congestión. Partiremos de la topología descrita en la figura 22.1 y estudiaremos algunas
simulaciones con distintos tamaños de búfer y de umbral. El tamaño de trama lo hacemos esta vez
constante al valor de 32 células. Para cada valor diferente de capacidad de búfer se ha modificado
el tráfico de fondo para que el patrón de llenado sea igual al mostrado en la gráfica 22.2. Para ello
se aumentando o disminuido, según sea el caso, la velocidad de envío del tráfico ATM de fondo
así como velocidad de portadora de salida del puerto al que está conectado el sumidero ATM.
A priori parece obvio que con valores mayores de búfer el tráfico, tanto de células ATM
como de tramas AAL y EAAL, se verá favorecido y no tan afectado por las temidas congestiones.
En la gráfica 22.11 se pueden observar los datos obtenidos en las simulaciones.
91
Simulador de Tráfico ATM con Garantía de Servicio
600
Tamaño del
búfer
500
400
Retrans.
solicitadas
500
300
1.000
2.000
200
4.000
100
2.000
0
70% 80%
90% 95%
99% 100%
500
Tamaño del umbral (con relación al
tamaño del buffer)
70%
80%
90%
95%
99%
100%
500
451
205
58
43
136
0
1.000
468
241
76
37
111
0
2.000
504
280
74
22
6
0
4.000
545
313
71
24
2
0
Gráfica 22.11: Retransmisiones solicitadas con distintos valores de búfer(con tráfico de fondo
revisado) y de umbral para tramas de 32 células.
Vemos que el efecto repunte en el umbral al 99% disminuye a medida que aumentamos el
tamaño del búfer hasta que llegamos a un punto que desaparece. Sin embargo es de prever que si
subimos el umbral por encima del 99% el efecto repunte volverá a aparecer.
Por tanto llegamos a la conclusión de que hay que encontrar un equilibro entre el tamaño
del búfer y el valor del umbral teniendo en cuenta el tamaño medio de trama. Para el algoritmo
EPDR estos parecen ser los factores más importantes.
12.5. Influencia del grado de GoS de las
conexiones privilegiadas.
En este apartado estudiaremos la influencia del grado de GoS en el rendimiento de las
conexiones EAAL. Recordemos que el grado de GoS es un parámetro que se establece para las
conexiones EAAL y que se negocia con los conmutadores activos durante el transcurso del
92
Simulador de Tráfico ATM con Garantía de Servicio
proceso de establecimiento de conexiones. Este parámetro representa el número de tramas EAAL
que se pide a los conmutadores guarden en su memoria DMTE para poder servir peticiones de
retransmisión.
En un principio se puede pensar que cuanto mayor sea le valor de la DMTE mejor será el
rendimiento de la conexión. Veremos con la siguiente gráfica si eso es cierto.
Las simulaciones en las que se basa esta gráfica han sido realizadas sobre las tramas que
más retransmisiones provocan en el conmutador CA_6, las de 16 células. La topología de la que
partimos es idéntica a la presentada en la figura 1. Vamos a estudiar el número de retransmisiones
no servidas para distintos grados de GoS para la conexión EAAL en función del valor del umbral.
Por retransmisiones no servidas entendemos aquellas que pide el conmutador CA_6 y que no
pueden servir ni el conmutador CA_4 ni el CA_1 por no existir ya copia de la trama en la DMTE.
Este hecho sucede cuando la trama requerida ha sido sustituida por una más reciente al no haber
espacio libre en la DMTE. En la gráfica 22.12 se presentan los resultados obtenidos.
40
Grado
de
GoS
35
30
Retrans.
no
servidas.
25
9
20
4
15
3
10
2
1
5
1
3
0
70% 80%
90% 95%
9
99%
Tamaño del umbral (con
relación al tamaño del buffer)
70%
80%
90%
95%
99%
9
0
0
0
0
0
4
0
0
0
0
0
3
2
0
0
0
0
2
18
1
0
0
0
1
38
16
0
0
0
Gráfica 22.12: Número de retransmisiones no servidas en relación con el umbral para distintos
valores de GoS.
93
Simulador de Tráfico ATM con Garantía de Servicio
Vemos en esta gráfica cómo el número de tramas no servidas desciende rápidamente a
medida que aumentamos el grado de GoS. Todas estas tramas no servidas se perderán y tendrán
que ser retransmitidas por los protocolos superiores del modelo ATM si se las quiere recuperar.
También se muestra cómo llega un momento que aunque aumentemos el grado de GoS no mejora
el rendimiento ya que se sirven todas aquellas peticiones de retransmisión que se solicitan
mientras que éstas están ocupando espacio en la DMTE de manera innecesaria. Por tanto hay que
llegar a un compromiso entre las congestiones esperadas que se produzcan para una conexión y el
grado de GoS solicitado sin aumentar éste de manera innecesaria.
Vemos también cómo sólo se pierden tramas por retransmisiones no servidas en
porcentajes de umbral del 70% y de 80%. El descenso tan brusco se debe a que se pierden menos
tramas y por tanto se transmiten menos peticiones de retransmisión. Esto provoca que no aumente
el tráfico EAAL con retransmisiones y, consecuentemente, que no se produzcan congestiones por
este tráfico añadido, un hecho éste que hay que evitar a la hora de diseñar una red con
conmutadores activos.
Así pues hemos visto que un exceso de peticiones de retransmisión puede provocar un
aumento exponencial en el tráfico existente entre dos conmutadores. Una forma de solucionar
este hecho perjudicial podría ser la de distanciar los conmutadores activos entre si. Cuanto mayor
sea la distancia entre dos conmutadores activos más tiempo pasará desde una congestión y su
consecuente petición de retransmisión hasta el momento en el que esta petición es atendida y
servida. Esto sería beneficioso para el tráfico en el sentido de que habría dado tiempo para que
actuaran en los conmutadores los mecanismos de prevención y evitación de congestión y, por
tanto, bajase el nivel de llenado del búfer antes de que llegara la trama congestionada.
En las siguientes gráficas vamos a estudiar la anterior hipótesis. Para ello hemos
construido una topología mixta en la que el conmutador anterior al conmutador congestionado lo
hemos sustituido por un conmutador no activo por lo que la petición de retransmisión la tendrá
que servir el primer conmutador. La nueva topología, idéntica a la de la gráfica anterior salvo por
la diferencia anteriormente indicada, se muestra en la figura 22.13.
94
Simulador de Tráfico ATM con Garantía de Servicio
Figura 22.13: Topología mixta con retransmisiones de largo recorrido
La gráfica 22.13 resultante de hacer la simulación de la topología anterior para diferentes
tamaños de GoS y de umbral es un poco sorprendente.
95
Simulador de Tráfico ATM con Garantía de Servicio
40
Grado
de
GoS
35
30
Retrans.
no
servidas.
25
9
20
4
15
3
10
2
1
5
1
3
0
70% 80%
90% 95%
9
99%
Tamaño del umbral (con
relación al tamaño del buffer)
70%
80%
90%
95%
99%
9
0
0
0
0
0
4
0
0
0
0
0
3
1
0
0
0
0
2
21
0
0
0
0
1
38
18
0
0
0
Gráfica 22.14: Número de retransmisiones no servidas en relación con el umbral para distintos
valores de GoS.
Vemos que no se altera de forma aparente el aspecto de la gráfica a parte de algún
pequeño aumento para las tramas no servidas en GoS de 1 trama. Sin embargo si estudiamos la
gráfica siguiente veremos que si que ha mejorado el tráfico por la red. En ella, la gráfica 22.15,
hacemos una comparación de las peticiones de retransmisión para la topología mixta y la original
para un GoS de 1 célula. Vemos que para umbrales pequeños las peticiones de retransmisión se
reducen considerablemente mientras que, según la gráfica anterior, el número de tramas perdidas
es idéntico. Por lo tanto deducimos que el alejamiento entre conmutadores activos ha provocado
un aumento en el rendimiento de la red.
Es de suponer que también habrá que llegar a un compromiso entre la separación de los
conmutadores activos y la separación entre fuente y sumidero de una conexión EAAL ya que si la
primera es demasiado cercana a la segunda los beneficios de las retransmisiones locales podrían
resultar demasiado pequeños en comparación con los recursos empleados. También habrá que
encontrar el equilibrio entre la separación de conmutadores activos y el grado de GoS porque
llegará un momento en el que si aumentamos la separación será menos probable que la trama
requerida para retransmisión se encuentre en la DMTE.
96
Simulador de Tráfico ATM con Garantía de Servicio
1200
1000
Tipo
Topología
800
Peticiones
Retrans.
600
Mixta
400
Norm al
200
0
70%
Normal
80%
90%
Mixta
95%
99%
Tamaño del umbral (con relación al tamaño
del buffer)
70%
80%
90%
95%
99%
Mixta
769
456
176
74
18
Norm al
1005
583
321
86
27
Gráfica 22.15: Comparación de las peticiones de retransmisión para topologías mixta y normal
con GoS de 1 trama.
12.6. Influencia del tamaño de la memoria
DMTE
Hemos visto en el punto anterior que cuanto mayor es el grado de GoS mayores
posibilidades hay de que una trama EAAL descartada se encuentre almacenada en la DMTE de
un conmutador anterior al que se le solicite la retransmisión de dicha trama. También hemos visto
que llega un momento que un grado de GoS determinado es suficiente para servir todas las
retransmisiones por lo que aunque aumentemos el grado de GoS no mejora el rendimiento de una
conexión.
Teniendo en cuenta el párrafo anterior, a la hora de elegir el tamaño de la DMTE se ha de
hacer de manera que en ésta memoria haya suficiente espacio para todas aquellas conexiones que
soliciten GoS. Por otra parte, en la negociación de apertura de conexión, un AcTM debería
modificar el valor de GoS requerido por una conexión para que éste no supere el que se considera
suficiente según la configuración de la red. Este grado GoS suficiente se debe calcular en función
del tamaño disponible de DMTE, de las conexiones que se estime que en un futuro pedirán GoS y
del tamaño de trama y velocidad de estas conexiones.
97
Simulador de Tráfico ATM con Garantía de Servicio
Por lo tanto el tamaño de la DMTE se debe escoger cuidadosamente para encontrar un
equilibrio entre los recursos empleados en ella y el beneficio que aporta a las conexiones
privilegiadas.
12.7. Influencia de la velocidad de salida de
las fuentes EAAL
En este apartado vamos a mostrar la influencia que ejerce la velocidad de salida de una
conexión en un conmutador EAAL. Para ello escogeremos una configuración de la red que, según
las gráficas mostradas hasta el momento, consideramos óptima. En esta configuración el
conmutador CA_6 tendrá un tamaño de búfer de 1000 células y un umbral al 95%. La conexión
EAAL tendrá una GoS de dos tramas siendo ésta de un tamaño de 32 células. Con esta
configuración a la velocidad de salida de anteriores pruebas, la conexión provocaría congestiones
en el conmutador CA_6. Todas las tramas perdodas en estas congestiones serán recuperadas y
servidas por en conmutador CA_4 por lo que no se perderá ninguna trama. Se van a probar cuatro
diferentes velocidades de salida. A partir de esta configuración observaremos qué efectos
provocará en la red el aumento o disminución de la velocidad de envío de la conexión
privilegiada.
Las gráficas obtenidas son las siguientes:
35000
30000
25000
20000
Células
descartadas 15000
10000
5000
0
v*0.1
v
v*10
Velocidad de salida EAAL (v = 366792.45 células/seg)
Células Descartadas
v*100
v*0.1
v
v*10
v*100
100
1829
28940
31750
Gráfica 22.16: Comparación de las células descartadas en el conmutador CA_6 para diferentes
velocidades de salida en la fuente EAAL.
98
Simulador de Tráfico ATM con Garantía de Servicio
900
800
700
600
500
400
300
200
100
0
Restrans.
Solicitadas
v*0.1
v
v*10
Velocidad de salida EAAL (v = 366792.45
células/seg)
Retransm isiones
Solicitadas
v*100
v*0.1
v
v*10
v*100
1
37
719
802
Gráfica 22.17: Comparación de las peticiones de retransmisión que realiza el conmutador CA_6
para diferentes velocidades de salida en la fuente EAAL.
450
400
350
300
250
200
150
100
50
0
Tramas
correctas.
v*0.1
v
v*10
Velocidad de salida EAAL (v = 366792.45
células/seg)
Tram as Recibidas
v*100
v*0.1
v
v*10
v*100
4
44
382
437
Gráfica 22.18: Comparación de las tramas correctas llegadas al sumidero para diferentes
velocidades de salida en la fuente EAAL.
99
Simulador de Tráfico ATM con Garantía de Servicio
En estas gráficas vemos cómo se produce un aumento significativo en las células
descartadas así como en las peticiones de retrasmisión de v*10 con respecto a v. Este aumento es
lógico si se tiene en cuenta que las tramas enviadas con v*10 son aproximadamente diez veces
más que las enviadas con v. Sin embargo este aumento no es tan significativo si comparamos
v*10 con v*100. Esto se debe a dos razones:
1-
2-
Las velocidades de portadora de salida de los conmutadores son todas de 10 7
células/segundo por lo que la velocidad de salida de los conmutadores limita la
velocidad de salida de la fuente.
La segunda razón y la más importante se puede explicar mejor si tenemos en cuenta la
siguiente gráfica:
300
250
Restrans.
no
Servidas
200
150
100
50
0
v*0.1
v
v*10
Velocidad de salida EAAL (v =
366792.45 células/seg)
Retransm isiones no
Servidas
v*100
v*0.1
v
v*10
v*100
0
0
277
54
Gráfica 22.19: Comparación de las peticiones de retransmisión no servidas por el conmutador
CA_4 para diferentes velocidades de salida en la fuente EAAL.
En la anterior gráfica puede verse un hecho muy significativo: con v*100 se retransmiten
menos tramas que para v*10 mientras que vimos en la gráfica 22.17 que para v*100 se
producen más solicitudes. Esto se debe a que las retransmisiones se realizan cuando el
conmutador no tiene tráfico normal para enviar. De esta forma una velocidad de envío de
la fuente cercana a la velocidad de la portadora de los conmutadores provoca que no haya
espacio temporal para enviar las tramas a retransmitir.
De las anteriores gráficas sacamos se deduce que hay que limitar la velocidad de salida de
las fuentes de manera que el conmutador que se prevé sirva las retransmisiones tenga suficiente
tiempo libre (tiempo OFF) para servirlas. Si no se cumple lo anterior las retransmisiones que se
pueden servir localmente disminuyen de forma significativa y por tanto los conmutadores AcTMs
pierden gran parte de sus ventajas.
100
Simulador de Tráfico ATM con Garantía de Servicio
13. Conclusiones
Hemos demostrado en este módulo con multitud de datos cómo la inclusión de
conmutadores activos que realicen retransmisiones locales e implementen el EPDR mejora el
rendimiento de una red ATM con congestiones en alguno de sus conmutadores. Entonces,
estudiadas las gráficas de anteriores puntos, como conclusiones principales a este módulo
podemos sacar las siguientes:
1- ATM mejora con la inclusión de AcTMs.
2- El rendimiento de una red con AcTMs varía considerablemente en relación a una
buena elección de sus parámetros configurables.
3- Hay dos grupos de parámetros principales y que guardan estrecha relación entre si y
que deberían ser configurados teniendo una visión global de sus relaciones:
a. Tamaño de búfer en un AcTM, proporción del umbral y tamaño medio de
trama EAAL.
b. Grado de GoS, distancia temporal entre AcTMs y velocidad de envío de
tramas.
4- Encontrar un equilibrio entre todos los parámetros configurables puede ser una labor
sumamente complicada aunque puede verse facilitada en la medida en que sea
predecible el tráfico circulante por la red.
13.1. Trabajos futuros
En este módulo hemos realizado gran cantidad de pruebas y simulaciones sobre distintas
topologías, conexiones y configuraciones de conmutadores. Posteriormente hemos analizado los
resultados obtenidos y, a partir de ellos, hemos obtenido diversas conclusiones. Debido
principalmente a que queda fuera del ámbito de este proyecto, no hemos querido profundizar más
en el análisis de los resultados y, como ha podido verse, las conclusiones aportadas son de
carácter general y esquemático. Esto deja la puerta abierta a futuros trabajos que se centren en el
estudio estadístico de los resultados obtenidos y la creación de fórmulas matemáticas para la
elección de los parámetros configurables que intervienen en la arquitectura TAP y/o que influyen
en su comportamiento.
Por otra parte, en lo referente al simulador en si, aún hay mucho que hacer en relación a
tres puntos importantes:
1- Mejorar el realismo: La red ATM que nosotros hemos conseguido está simplificada en
diversos aspectos, como por ejemplo en la QoS. Como trabajos futuros se propone la
implementación completa de los aspectos simplificados y la inclusión de aquellos
suprimidos con lo que se mejoraría el realismo global de las simulaciones.
2- Mejorar la rapidez: Uno de los problemas mayores a los que se enfrenta el usuario del
paquete SimSwitch es a la gran cantidad de recursos que necesita la realización de
simulaciones y la obtención y clasificación de resultados y en consecuencia la lentitud en
estos dos procesos cuando los recursos de que se disponen son limitados. Para el primer
101
Simulador de Tráfico ATM con Garantía de Servicio
problema se ha propuesto la posibilidad de modificación del valor del tick mediante el
que es posible obtener una mayor velocidad a costa del realismo. Para futuros trabajos
queda pendiente la obtención de un rendimiento mayor en el proceso de generación de los
archivos “.dgs” ya sea mediante la depuración y modificación de algoritmos o un cambio
en la filosofía de generación
3- Mejorar herramientas de estudio: El analizador que ofrecemos en el paquete está
pensado para ofrecer al usuario resultados concretos para distintos seguimientos y
gráficas de variación con el tiempo de dichos resultados. Como trabajo futuro de propone
la creación de herramientas para el estudio detallado de los valores obtenidos como la
obtención de variables estadísticas, por ejemplo.
Este ha sido un proyecto con grandes retos y metas elevadas en el que hemos tenido que
sacrificar ciertos aspectos en aras de hacerlo abordable como proyecto fin de carrera. Sin
embargo, como tal, consideramos que los resultados obtenidos superan nuestras expectativas y
podemos decir con orgullo que estamos completamente satisfechos del trabajo realizado y del
resultado obtenido.
102
Simulador de Tráfico ATM con Garantía de Servicio
BIBLIOGRAFÍA
Libros
•
•
•
•
•
•
•
•
Andel, R., Huber, M. N., Schörder, S., “ATM Networks Concepts, Protocols.
Applocationes (2ª Ed.)” Addison-Wesley, 1998
J. M. Pitss “Introduction to ATM. Design and Performance”, Ed. Wiley, 1997
M. de Prycker “Asynchronous Transfer Mode. Solutions for Broadband ISDN (3ª
Ed.),” Ed. Prentice Hall, 1995
Froufe, A. “Java 2; Manual de Usuario y Turorial”, Ed. Ra-Ma, 2000.
Stallings W. “Comunicaciones y Redes de Computadores” Sexta edición. Ed. PrenticeHall, 2000.
Alberto León-García. “Redes de Comunicación”. Ed. Mc Graw Hill. 2002
Tanenbaum, A.S. “Redes de Computadoras” 3ª edición. Ed Prentice-Hall, 1997.
Caballero, J.M. “Redes de Banda Ancha” Ed. Marcombosa, 1997.
Artículos
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
González, J.L. “Protocolo Activo para Transmisiones Garantizadas sobre una
Arquitectura Distribuida y Multiagente en Redes ATM”. Tesis Doctoral UPC, 2001.
“ATM User-Network Intrerface (UNI) Signalling Specification Version 4.0” ATM
Forum Technical Comunitee, ATM Forum Document af-sgt-0061, 1996
“ATM User Network Interface 3.1 specification”, ATM Forum, 1994
“Private Network-Network Interface Specification Version 1.0” ATM Forum
Document af-pnni-0055.000, 1996
Lucen Technologies, “AXP 800: Guía de configuración ATM” versión 8.0, 2001
Datenkomunikation und Netzwerke “ATM PNNI Routing”, Proin, 2001.
Golmie, N., Mouveaux, F., Hester, L., Saintillan, Y., Koenig, A., Su, D. “The NIST
ATM/HFC Network Simulator; Operation and Programming Guide” version 4.0.
U.S. Department od Commerce, 1998.
Calatrava, E., Esparza, O: “Algoritmos de Control de Admisión” Encaminament i
Gestió de Recursos amb QoS en les Xarxes de Banda Amplia, 2002.
“Auto-Configuration of PVCs”, ATM Forum, af-nm-0122.000, 1999.
González-Sánchez, J.L., Domingo-Pascual, J.D.: “Protocol for Reliable Transfer in
ATM Networks with Active Switches”
González-Sánchez, J.L., Domingo-Pascual, J.D.: “Survey on Protocols for ATM
Networks”
“Remote Monitoring MIB Extensions for ATM Networks”, ATM Forum, AF-NMTEST-0080.000, 1997.
“Traffic Management Specification Version 4.0”, ATM Forum, af-tm-0056.000, 1996
The VINT Proyect “The ns Manual” Fall-Varadham, 2002
Ushbeck, C. “Topologías de Banda Ancha BISDN/ATM” Complementos Electrónicos,
1999.
103