ATM - Modo de Transferencia Asncrona

MULTIPLEXACION EN ATM: *
PROTOCOLO ATM: *
La capa de adaptacin de ATM: *
1)Capa de convergencia (convergence sublayer (CS)) : *
2)Capa de Segmentacin y reensamblaje (segmentation and reassembly (SAR)) *
AAL1: *
Capa de convergencia: *
Capa de segmentacin y reensamblaje: *
ALL 2: *
Capa de convergencia: *
Capa de segmentacin y recuperacin: *
AAL 3: *
Capa de convergencia: *
Capa de segmentacin y reensamblaje *
ALL 4: *
PROBLEMAS EN ATM: *
INTEROPERABILIDAD ENTRE FRAME RELAY Y ATM *
PRIMER ESCENARIO: *
POSIBILIDAD 1: *
POSIBILIDAD 2: *
SEGUNDO ESCENARIO: *
CONCLUSION *
BIBLIOGRAFIA: *
ATM
INTRODUCCION:
Tres letras - ATM - se repiten cada vez ms en estos das en los ambientes Informticos y de
Telecomunicaciones. La tecnologa llamada Asynchronous Transfer Mode (ATM) Modo de
Transferencia Asncrona es el corazn de los servicios digitales integrados que ofrecern las
nuevas redes digitales de servicios integrados de Banda Ancha (B-ISDN), para muchos ya no hay
cuestionamientos; el llamado trfico del "Cyber espacio", con su voluminoso y tumultuoso
crecimiento, impone a los operadores de redes pblicas y privadas una voraz demanda de anchos
de banda mayores y flexibles con soluciones robustas. La versatilidad de la conmutacin de
paquetes de longitud fija, denominadas celdas ATM, son las tablas ms calificadas para soportar la
cresta de esta "Ciberola" donde los surfeadores de la banda ancha navegan.
Algunos crticos establecen una analoga de la tecnologa ATM con la red digital de servicios
integrados o ISDN por sus siglas en ingls. Al respecto se escuchan respuestas de expertos que
desautorizan esta comparacin aduciendo que la ISDN es una gran tecnologa que lleg en una
poca equivocada, en trminos de que el mercado estaba principalmente en manos de actores con
posiciones monopolsticas.
Ahora el mercado est cambiando, la ISDN est encontrando una gran cantidad de aplicaciones.
De toda forma la tecnologa ATM se proyecta para diferentes necesidades, a pesar de su estrecha
relacin con ISDN, en trminos de volmenes de datos, flexibilidad de conmutacin y facilidades
para el operador.

Los conmutadores ATM aseguran que el trfico de grandes volmenes es flexiblemente conmutado
al destino correcto. Los usuarios aprecian ambas cosas, ya que se cansan de esperar los datos y
las pantallas de llegada a sus terminales. Estas necesidades cuadran de maravilla para los
proveedores de servicios pblicos de salud, con requerimientos de videoconferencias mdicas,
redes financieras interconectadas con los entes de intermediacin y validacin, o con las
exigencias que pronto sern familiares como vdeo en demanda para nuestros hogares con alta
definicin de imgenes y calidad de sonido de un CD, etc.
Para el operador, con la flexibilidad del ATM, una llamada telefnica con trfico de voz ser tarifado
a una tasa diferente a la que estara dispuesto a pagar un cirujano asistiendo en tiempo real a una
operacin al otro lado del mundo. Ese es una de las fortalezas de ATM usted paga solamente por
la carga de celdas que es efectivamente transportada y conmutada para usted. Adems la
demanda por acceso a Internet ha tomado a la industria de telecomunicaciones como una
tormenta. Hoy da los accesos conmutados a Internet estn creando "Cuellos de Botella" en la
infraestructura. Para copar este problema los fabricantes no solo han desarrollado sistemas de
acceso sino aplicaciones para soluciones de fin a fin con conmutadores ATM, con solventes
sistemas de administracin de la red (Network Management).
En varios aspectos, ATM es el resultado de una pregunta similar a la de teora del campo unificada
en fsica Cmo se puede transportar un universo diferente de servicio de voz, vdeo por un lado y
datos por otro de manera eficiente usando una simple tecnologa de conmutacin y
multiplexacin?.
ATM contesta esta pregunta combinando la simplicidad de la multiplexacin por divisin en el
tiempo (Time Division Multiplex TDM) encontrado en la conmutacin de circuitos, con la eficiencia
de las redes de conmutacin de paquetes con multiplexacin estadstica. Por eso es que algunos
hacen reminiscencias de perspectivas de conmutacin de circuitos mientras que otros lo hacen a
redes de paquetes orientados a conexin.
MULTIPLEXACION EN ATM:
Un examen ms cercano del protocolo ATM y cmo opera ayudar a explicar cmo los circuitos
virtuales, las rutas virtuales, los conmutadores y los servicios que ellos acarrean se afectan entre
s.
La figura No.1 muestra un formato bsico y la jerarqua de ATM. Una conexin ATM, consiste de
"celdas" de informacin contenidos en un circuito virtual (VC). Estas celdas provienen de diferentes
fuentes representadas como generadores de bits a tasas de transferencia constantes como la voz
y a tasas variables tipo rfagas (bursty traffic) como los datos. Cada celda compuesta por 53 bytes,
de los cuales 48 (opcionalmente 44) son para trasiego de informacin y los restantes para uso de
campos de control (cabecera) con informacin de "quin soy" y "donde voy"; es identificada por un
"virtual circuit identifier" VCI y un "virtual path identifier" VPI dentro de esos campos de control, que
incluyen tanto el enrutamiento de celdas como el tipo de conexin. La organizacin de la cabecera
(header) variar levemente dependiendo de s la informacin relacionada es para interfaces de red
a red o de usuario a red. Las celdas son enrutadas individualmente a travs de los conmutadores
basados en estos identificadores, los cuales tienen significado local - ya que pueden ser cambiados
de interface a interface.

La tcnica ATM multiplexa muchas celdas de circuitos virtuales en una ruta (path) virtual
colocndolas en particiones (slots), similar a la tcnica TDM. Sin embargo, ATM llena cada slot con
celdas de un circuito virtual a la primera oportunidad, similar a la operacin de una red conmutada
de paquetes. La figura No.2 describe los procesos de conmutacin implcitos los VC switches y los
VP switches.

Los slots de celda no usados son llenados con celdas "idle", identificadas por un patrn especfico
en la cabecera de la celda. Este sistema no es igual al llamado "bit stuffing"en la multiplexacin
Asncrona, ya que aplica a celdas enteras.
Diferentes categoras de trfico son convertidas en celdas ATM va la capa de adaptacin de ATM
(AAL - ATM Adaptation Layer), de acuerdo con el protocolo usado. (Ms adelante se explica este
protocolo).
La tecnologa ATM ha sido definida tanto por el ANSI como por el CCITT a travs de sus
respectivos comits ANSI T1, UIT SG XVIII, como la tecnologa de transporte para la B-ISDN
(Broad Band Integrated Services Digital Network), la RDSI de banda ancha. En este contexto
"transporte" se refiere al uso de tcnicas de conmutacin y multiplexacin en la capa de enlace
(Capa 2 del modelo OSI) para el trasiego del trfico del usuario final de la fuente al destino, dentro
de una red. El ATM Forum, grupo de fabricantes y usuarios dedicado al anlisis y avances de ATM,
ha aprobado cuatro velocidades UNI (User Network Interfases) para ATM: DS3 (44.736 Mbit/s),

SONET STS3c (155.52 Mbit/s) y 100 Mbit/s para UNI privados y 155 Mbit/s para UNI privadas. UNI
privadas se refieren a la interconexin de usuarios ATM con un switch ATM privado que es
manejado como parte de la misma red corporativa. Aunque la tasa de datos original para ATM fue
de 45 Mbit/s especificado para redes de operadores (carriers) con redes T3 existentes, velocidades
UNI adicionales se han venido evaluando y estn ofrecindose. Tambin hay un alto inters en
interfases, para velocidades EI (2Mbps) y T1 (1,544 Mbps) para accesos ATM de baja velocidad.
PROTOCOLO ATM:
El protocolo ATM consiste de tres niveles o capas bsicas (Ver figura No 3).
La primera capa llamada capa fsica (Physical Layer), define los interfases fsicos con los medios
de transmisin y el protocolo de trama para la red ATM es responsable de la correcta transmisin y
recepcin de los bits en el medio fsico apropiado. A diferencia de muchas tecnologas LAN como
Ethernet, que especifica ciertos medios de transmisin, (10 base T, 10 base 5, etc.) ATM es
independiente del transporte fsico. Las celdas ATM pueden ser transportadas en redes SONET
(Synchronous Optical Network), SDH (Synchronous Digital Hierarchy), T3/E3, TI/EI o an en
modems de 9600 bps. Hay dos subcapas en la capa fsica que separan el medio fsico de
transmisin y la extraccin de los datos:

La subcapa PMD (Physical Medium Depedent) tiene que ver con los detalles que se especifican
para velocidades de transmisin, tipos de conectores fsicos, extraccin de reloj, etc., Por ejemplo,
la tasa de datos SONET que se usa, es parte del PMD. La subcapa TC (Transmission
Convergence) tiene que ver con la extraccin de informacin contenida desde la misma capa fsica.
Esto incluye la generacin y el chequeo del Header Error Correccin (HEC), extrayendo celdas
desde el flujo de bits de entrada y el procesamiento de celdas "idles" y el reconocimiento del lmite
de la celda. Otra funcin importante es intercambiar informacin de operacin y mantenimiento
(OAM) con el plano de administracin.
(Ver figura No.4)
La segunda capa es la capa ATM. Ello define la estructura de la celda y cmo las celdas fluyen
sobre las conexiones lgicas en una red ATM, esta capa es independiente del servicio. El formato
de una celda ATM es muy simple. Consiste de 5 bytes de cabecera y 48 bytes para informacin.

Las celdas son transmitidas serialmente y se propagan en estricta secuencia numrica a travs de
la red. El tamao de la celda ha sido escogido como un compromiso entre una larga celda, que es
muy eficiente para transmitir largas tramas de datos y longitudes de celdas cortas que minimizan el
retardo de procesamiento de extremo a extremo, que son buenas para voz, vdeo y protocolos
sensibles al retardo. A pesar de que no se dise especficamente para eso, la longitud de la celda
ATM acomoda convenientemente dos Fast Packets IPX de 24 bytes cada uno.
Los comits de estndares han definido dos tipos de cabeceras ATM: los User-to-Network Interface
(UNI) y la Network to Network Interface (UNI). La UNI es un modo nativo de interfaz ATM que
define la interfaz entre el equipo del cliente (Customer Premises Equipment), tal como hubs o
routerss ATM y la red de rea ancha ATM (ATM WAN). La NNI define la interfase entre los nodos
de la redes (los switches o conmutadores) o entre redes. La NNI puede usarse como una interfase
entre una red ATM de un usuario privado y la red ATM de un proveedor pblico (carrier).
Especficamente, la funcin principal de ambos tipos de cabeceras de UNI y la NNI, es identificar
las "Virtual paths identifiers" (VPIS) y los "virtual circuits" o virtual channels"(VCIS) como
identificadores para el ruteo y la conmutacin de las celdas ATM.
La capa de adaptacin de ATM:
La tercer capa es la ATM Adaptation Layer (AAL). La AAL juega un rol clave en el manejo de
mltiples tipos de trfico para usar la red ATM, y es dependiente del servicio. Especificamente, su
trabajo es adaptar los servicios dados por la capa ATM a aquellos servicios que son requeridos por
las capas ms altas, tales como emulacin de circuitos, (circuit emulation), vdeo, audio, frame
relay, etc. La AAL recibe los datos de varias fuentes o aplicaciones y las convierte en los
segmentos de 48 bytes. Cinco tipos de servico AAL estn definidos actualmente:
La capa de Adaptacin de ATM yace entre el ATM layer y las capas ms altas que usan el servicio
ATM. Su propsito principal es resolver cualquier disparidad entre un servicio requerido por el
usuario y atender los servicios disponibles del ATM layer. La capa de adaptacin introduce la
informacin en paquetes ATM y controla los errores de la transmisin. La informacin transportada
por la capa de adaptacin se divide en cuatro clases segn las propiedades siguientes:
1.
Que la informacin que esta siendo transportada dependa o no del tiempo.
2.
Tasa de bit constante/variable.
3.
Modo de conexin.
Estas propiedades definen ocho clases posibles, cuatro se definen como B-ISDN Clases de
servicios. La capa de adaptacin de ATM define 4 servicios para equiparar las 4 clases definidas
por B-ISDN:

AAL-1

AAL-2
AAL-3
AAL-4
La capa de adaptacin se divide en dos subcapas:
1)Capa de convergencia (convergence sublayer (CS)) :
En esta capa se calculan los valores que debe llevar la cabecera y los payloads del mensaje. La
informacin en la cabecera y en el payload depende de la clase de informacin que va a ser
transportada.
2)Capa de Segmentacin y reensamblaje (segmentation and reassembly (SAR))
Esta capa recibe los datos de la capa de convergencia y los divide en trozos formando los
paquetes de ATM. Agrega la cabecera que llevara la informacin necesaria para el reensamblaje
en el destino.
La figura siguiente aporta una mejor comprensin de ellas. La subcapa CS es dependiente del
servicio y se encarga de recibir y paquetizar los datos provenientes de varias aplicaciones en
tramas o paquete de datos longitud variable.

Estos paquetes son conocidos como (CS - PDU) CONVERGENCE SUBLAYER PROTOCOL DATA
UNITS.
Luego, la sub capa recibe los SAR CS - PDU, los reparte en porciones del tamao de la celda ATM
para su transmisin. Tambin realiza la funcin inversa (reemsamblado) para las unidades de
informacin de orden superior. Cada porcin es ubicada en su propia unidad de protocolo de
segmentacin y reemsable conocida como (SAR - PDU) SEGMENTATION AND REASSEMBLER
PROTOCOL DATA UNIT, de 48 bytes.
Finalmente cada SAR - PDU se ubica en el caudal de celdas ATM con su header y trailer
respectivos.
AAL1:
AAL-1 se usa para transferir tasas de bits constantes que dependen del tiempo. Debe enviar por lo
tanto informacin que regule el tiempo con los datos. AAL-1 provee recuperacin de errores e
indica la informacin con errores que no podr ser recuperada.
Capa de convergencia:
Las funciones provistas a esta capa difieren dependiendo del servicio que se provey. Provee la
correccin de errores.
Capa de segmentacin y reensamblaje:
En esta capa los datos son segmentados y se les aade una cabecera. La cabecera contiene 3
campos (ver diagrama)

Nmero de secuencia usado para detectar una insercin o perdida de un paquete.

Nmero de secuencia para la proteccin usado para corregir errores que ocurren en el
numero de secuencia.
Indicador de capa de convergencia usado para indicar la presencia de la funcin de la capa
de convergencia.

ALL 2:
AAL-2 se usa para transferir datos con tasa de bits variable que dependen del tiempo. Enva la
informacin del tiempo conjuntamente con los datos para que esta puede recuperarse en el
destino. AAL-2 provee recuperacin de errores e indica la informacin que no puede recuperarse.
Capa de convergencia:
Esta capa provee para la correccin de errores y transporta la informacin del tiempo desde el
origen al destino.
Capa de segmentacin y recuperacin:
El mensaje es segmentado y se le aade una cabecera a cada paquete. La cabecera contiene dos
campos.

Numero de secuencia que se usa para detectar paquetes introducidas o perdidas.

El tipo de informacin es:

o
BOM, comenzando de mensaje
o
COM, continuacin de mensaje
o
EOM, fin de mensaje o indica que el paquete contiene informacin de tiempo u
otra.
El payload tambin contiene dos de campos :
indicador de longitud que indica el numero de bytes validos en un paquete parcialmente
lleno.

CRC que es para hacer el control de errores.

AAL 3:
AAL-3 se disea para transferir los datos con tasa de bits variable que son independientes del
tiempo. AAL-3 puede ser dividido en dos modos de operacin:
1.
Fiable: En caso de perdida o mala recepcin de datos estos vuelven a ser
enviados. El control de flujo es soportado.
2.
No fiable: La recuperacin del error es dejado para capas mas altas y el control de
flujo es opcional.
Capa de convergencia:

La capa de convergencia en AAL 3 es parecida al ALL 2. Esta subdividida en dos secciones:

1.
Parte comn de la capa de convergencia. Esto es provisto tambin por el AAL-2
CS. Aade una cabecera y un payload a la parte comn (ver diagrama)

La cabecera contiene 3 campos:

Indicador de la parte comn que dice que el payload forma parte de la parte comn.
Etiqueta de comienzo que indica el comienzo de la parte comn de la capa de
convergencia.
Tamao del buffer que dice al receptor el espacio necesario para acomodar el mensaje.
El payload tambin contiene 3 campos:
Alineacin es un byte de relleno usado para hacer que la cabecera y el payload tengan la
misma longitud.
Fin de etiqueta que indica el fin de la parte comn de la CS(capa de convergencia).
El campo de longitud tiene la longitud de la parte comn de la CS.
1.

Parte especifica del servicio. Las funciones provedas en esta que capa dependen
de los servicios pedidos. Generalmente se incluyen funciones para la recuperacin y
deteccin de errores y puede incluir tambin funciones especiales.

Capa de segmentacin y reensamblaje

En esta capa los datos son partidos en paquetes de ATM. Una cabecera y el payload que contiene
la informacin necesaria para la recuperacin de errores y reensamblaje se aaden al paquete. La
cabecera contiene 3 campos:
1) Tipo de segmento que indica que parte de un mensaje contiene en payload. Tiene uno de los
siguientes valores:

BOM: Comenzando de mensaje

COM: Continuacin de mensaje

EOM: Fin de mensaje

SSM: Mensaje nico en el segmento

2) Numero de secuencia usado para detectar una insercin o una perdida de un paquete.
3) Identificador de multiplexacin. Este campo se usa para distinguir datos de diferentes
comunicaciones que ha sido multiplexadas en una nica conexin de ATM.
El payload contiene dos de campos:
1) Indicado de longitud que indica el nmero de bytes tiles en un paquete parcialmente lleno.
2) CRC es para el control de errores.

ALL 4:

AAL-4 se disea para transportar datos con tasa de bits variable independientes del tiempo. Es
similar al AAL3 y tambin puede operar en transmisin fiable y o fiable. AAL-4 provee la capacidad
de transferir datos fuera de una conexin explcita.
AAL 2, AAL 3/4 y AAL 5 manejan varios tipos de servicios de datos sobre la base de tasas de bits
variables tales como Switched Multimegabit Data Service (SMDS), Frame Relay o trfico de redes
de rea local (LAN). AAL 2 y AAL 3 soportan paquetes orientados a conexin. (Ver figura No.5)

(El trmino orientado a conexin describe la transferencia de datos despus del establecimiento de
un circuito virtual).
PROBLEMAS EN ATM:
En el pasado los protocolos de comunicaciones de datos evolucionaron en respuesta a circuitos
poco confiables. Los protocolos en general detectan errores en bits y tramas perdidas, luego
retransmiten los datos.
Los usuarios puede que jams vean estos errores reportados, la degradacin de respuesta o de
caudal (through put) seran los nicos sntomas.
A diferencia de los mecanismos de control extremo a extremo que utiliza TCP en internerworking,
la capacidad de Gbit/seg de la red ATM genera un juego de requerimientos necesarios para el
control de flujo. Si el control del flujo se hiciese como una realimentacin del lazo extremo a
extremo, en el momento en que el mensaje de control de flujo arribase a la fuente, sta habra
transmitido ya algunos Mbytes de datos en el sistema, exacerbando la congestin. Y en el
momento en que la fuente reaccionase al mensaje de control, la condicin de congestin hubiese
podido desaparecer apagando innecesariamente la fuente. La constante de tiempo de la
realimentacin extremo a extremo en las redes ATM (retardo de realimentacin por producto lazo ancho de banda) debe ser lo suficientemente alta como para cumplir con las necesidades del
usuario sin que la dinmica de la red se vuelva impractica.
Las condiciones de congestin en las redes ATM estn previstas para que sean extremadamente
dinmicas requiriendo de mecanismos de hardware lo suficientemente rpidos para llevar a la red
al estado estacionario, necesitando que la red en s, ste activamente involucrada en el rpido
establecimiento de este estado estacionario. Sin embargo, esta aproximacin simplista de control
reactivo de lazo cerrado extremo a extremo en condiciones de congestin no se considera
suficiente para las redes ATM.
El consenso entre los investigadores de este campo arroja recomendaciones que incluyen el
empleo de una coleccin de esquemas de control de flujo, junto con la colocacin adecuada de los
recursos y dimensionamiento de las redes, para que aunados se pueda tratar y evadir la
congestin ya sea:
Detectando y manipulando la congestin que se genera tempranamente monitoreando de
cerca las entradas/salidas que estn dentro de los conmutadores ATM y reaccionando
gradualmente a medida que vaya arribando a ciertos niveles prefijados.
Tratando y controlando la inyeccin de la conexin de datos dentro de la red en la UNI
(unidad interfaz de red) de tal forma que su tasa de inyeccin sea modulada y medida all
primero, antes de tener que ir a la conexin de usuario a tomar acciones mas drsticas.

El estado de la red debe ser comunicado a la UNI, generando rpidamente una celda de
control de flujo siempre que se vaya a descartar una celda en algn nodo debido a
congestin. La UNI debe entonces manejar la congestin, cambiando su tasa de inyeccin
o notificndola a la conexin de usuario para que cese el flujo dependiendo del nivel de
severidad de la congestin.
El mayor compromiso durante el control de congestin es el de tratar y afectar solo a los
flujos de conexin que son responsables de la congestin y actuar de forma transparente
frente a los flujos que observan buen comportamiento. Al mismo tiempo, permitir que el
flujo de conexin utilice tanto ancho de banda como necesite sino hay congestin.
La recomendacin UIT - T I. 371 especifica un contrato de trfico que define como el trfico
del usuario seria administrado. El contrato que existe para cada conexion virtual (virtual
path o virtual channel), es bsicamente un acuerdo entre el usuario y la red con respecto a
la Calidad de Servicio (Quality Of Service - Q o S) y los parmetros que regulan el flujo de
celdas. Estos descriptores de trafico dependen de una particular clase de servicio y pueden
incluir bajo la especificacin del ATM Forum UNI / a cinco Q o S referenciados en los
AALS. El objetivo de estas sub clases de servicio es agrupar caractersticas de servicio
como requerimiento de ancho de banda similares, sensibilidad a la perdida de datos y
retardos para un correcto manejo de los datos en los puertos de acceso ATM, etc. Estos
parmetros pueden incluir el Sustained Cell Rate (SCR), el Mnimum Cell Rate (MCR), el
Peak Cell Rate (PCR) y/o el Burst Tolerance (BT). Para soportar todas las diferentes clases
de servicios definidos por los estndares el switch ATM debe ser capaz de definir stos
parmetros en base a cada VC o cada VP y debe proveer amortiguadores (buffers) para
absorber las rfagas de trafico.
INTEROPERABILIDAD ENTRE FRAME RELAY Y ATM
El objetivo final para todos los servicios descritos anteriormente es una migracin suave de Frame
Relay y/o SMDS a redes ATM. Por ejemplo la recomendacin UIT - T I.555, provee un marco para
la interoperabilidad de Frame Relay y ATM.
Para alcanzar una mxima eficiencia se trata de brindar este servicio de interoperabilidad en la
capa ms baja posible mediante conversin de protocolo.
PRIMER ESCENARIO:
Cuando el servicio de Frame Relay es dado sobre la RDSI en banda ancha y los usuarios se
conectan a travs de la UNI de Frame Relay.
En esta solucin, se necesita un equipo que sirva de interfaz tanto para el usuario que recibe,
como para el que transmite. Para proveer el servicio del primer escenario existen dos posibilidades:

POSIBILIDAD 1:
Construir un mallado utilizando conexiones ATM (VC/VP) para enlazar los puntos de acceso Frame
Relay.
En este esquema se puede explotar la naturaleza de orientacin a conexin Frame Relay (F R)
siguiendo un comportamiento como:
El usuario del enrutador pregunta por una conexin al equipo interfaz de red.
El equipo interfaz de la red coloca las conexiones Frame Relay dentro de una conexin
ATM con las direcciones destino apropiadas.
Por cada trama de equipo interfaz de red traslada de la conexin de Frame Relay a la ATM
y viceversa.
La conexin ATM esta desocupada cuando no se necesita.
Para lograr este ltimo punto, el manejo de la poltica de conexion del VC, sera
un aspecto crucial para el desempeo de este procedimiento. Resulta difcil de terminar el
procedimiento para manejar un VC cuando la fuente de trfico es no orientada a conexin.
En este caso se pueden utilizar varios mecanismos:
No utilizar manejo alguno, lo que involucra el uso de circuitos ATM permanentes (VPs) en
lugar de los conmutadores (VCs) con un costo muy elevado.

Abrir y cerrar una conexion ATM con el destino apropiado para cada trama que arribe del
lado de Frame Relay en el equipo interfaz de red.
Abrir una conexin ATM cuando se necesite y cerrarla de acuerdo a un temporizador de
inactividad.
El problema debe ser solucionado ya sea por el enrutador del usuario o por el equipo
interfaz de red.
POSIBILIDAD 2:
Utilizar un servicio Frame Relay en todos los lugares en los cuales se establezcan conexiones ATM
en estrella. En esta opcin se toma ventaja del uso actual del FR, el cual es proveer un mallado
virtual entre diferentes sitios para cargar trfico no orientado a conexin.
Cada enrutador esta conectado al servidor de FR.
Todos los DLCIs (Data Link Connection Identifier) en cada interfaz FR pueden ser cargados a un
servidor FR dentro de un VC ATM.
En este escenario la funcionalidad de los equipos interfaz de red se simplifica debido a que solo
dialoga con el servidor.
La complejidad reside en el servidor que ejecuta funciones de conmutacin. Las tramas se
conmutan en la base de VCIs y DLCIs entrantes y salientes.
El servidor mantiene una tabla con las correspondencias entre los pares VCI / DLCI.
SEGUNDO ESCENARIO:
La red de Frame Relay y la red RDSI de banda ancha se interconectan a travs de sus respectivas
interfaces de red (NNIs).
Esto permitira a un proveedor de red, manejar esta heterognea red como un todo. Frame Relay
provee usualmente la interconexin para LAN a pesar de su natural orientacin a conexin.
En las redes Frame Relay existentes se puede conseguir un mallado de LANs a traves de circuitos
virtuales permanentes. Los datagramas de los LANs son cargados dentro de tramas FR y
enrutados de acuerdo con la etiqueta contenida en el DLCI.
Tratando de hacer un sobresimplificacin los dos protocolos (AAL 3 y AAL 5) ofrecen basicamente
el mismo servicio CPAAL (Parte Comn AAL) a las subcapas superiores. En este caso a la capa de
Convergencia de Frame Relay.
Existen sin embargo diferencia en las funcionalidades internas, simplicidad de implementacin y
eficiencia del protocolo que incide en el costo. Las caractersticas a tomar en cuenta, cuyo detalle
puede ser tema de otro artculo, tienen que ver con Delimitacin y Alineamiento de Tramas,
Multiplexacin, Deteccin de errores de transmisin, eficiencia en la transmisin. Analizadas estas
diferencias se propone seleccionar el AAL5 bajo la subcapa FR-CS para soportar el servicio Frame
Relay en RDSI de banda ancha.
CONCLUSION
ATM promete ser la tecnologa de red empresarial virtual del futuro, un trmino que refleja
tanto la evolucin del modelo empresarial global y el nfasis en la conectividad lgica,
donde los usuarios obtienen acceso a los recursos que necesitan y el operador de la red
provee las rutas de conexin y asigna el ancho de banda necesario a fuentes de trfico muy
diferentes (voz, datos, vdeo). Aquellos que construyen y operan redes deben volver los ojos
a las capacidades de la tecnologa ATM, ya que aspiran a la mgica combinacin:
interconectividad global - escalabilidad de tecnologas y satisfaccin del cliente local.

BIBLIOGRAFIA:
1.

CCITT Rec I.362 B-ISDN ATM Adaptation Layer (AAL) functional description. Geneva 1991.

2.

Frame Relay in Public Networks. M. Irfan Ali. IEEE - Communications Magazine - March 1992.

3.

Varios Brochures de fabricantes. Alcatel, Stratacom, Digital Link Corporation.

4.

ATM Internetworking. Anthony Alles. Cisco Systems Inc, Marzo 1995.

5.

Global Telephony Sept 1994, vol.2, No.8. ATM Testing crosses network boundaries, Jim Frimmel.

6.

Newslink, Alcatel Telecoms customer magazine. Vol. IV No.4, 4th Quarter 1996. Adapting Networks to the Internet Challenge. Krish Prabhu.

Trabajo realizado por:

Ivan Dario Cruz Prada
Nicruz[arroba]col1.telecom.com.co

Revisin y Clasificacin de Protocolos para Redes de Tecnologa ATM

Jos Luis Gonzlez-Snchez y Jordi Domingo-Pascual

Resumen
La tecnologa ATM (Asynchronous Transfer Mode) continua evolucionando y siendo fuente de
interesantes y novedosas propuestas. El desarrollo de avanzados protocolos de comunicaciones es uno
de los campos de investigacin ms activo, con la aspiracin de ofrecer el adecuado soporte a las
nuevas aplicaciones adaptadas a las clases de servicio nativas ATM. En este contexto son aspectos
clave los relativos a los protocolos nativos ATM, as como las caractersticas multicast, la escalabilidad y
la fiabilidad. Se profundiza en el concepto de protocolo nativo ATM y son introducidos los protocolos
ms importantes que satisfacen este importante requerimiento (N 3, CONGRESS y kStack, entre otros).
Es importante destacar tambin los protocolos de transporte pensados especficamente para la
tecnologa ATM. La caracterstica multicast (multipoint-to-multipoint) es una de las que ms esfuerzo
est costando garantizar a ATM, pero existen ya propuestas que permiten la comunicacin fiable a
elevados anchos de banda y entre mltiples emisores y receptores (SMART, MCMP o MWAX). El
artculo concluye con las investigacioness ms novedosas en torno a los protocolos ATM como las
iniciativas que proponen redes ATM programables o activas (active networks) usando agentes mviles.

1.-Introduccin y motivaciones
La actual demanda de aplicaciones relacionadas con informacin multimedia, como son la videoconferencia, audio-conferencia, video bajo demanda (VoD) o sistemas colaborativos (pizarras
compartidas, teletrabajo, telemedicina, etc.) y su coexistencia con aplicaciones ms clsicas (bases de
datos, transferencias de ficheros, WWW, etc.), requiere tecnologas de comunicaciones capaces de
ofrecer elevadas prestaciones. Estas elevadas prestaciones estn directamente relacionadas con la
calidad de servicio (QoS) y concretamente con conceptos claramente parametrizables como el ancho de
banda y la velocidad de transmisin (throughput), el retardo de las transferencias (delay); la variabilidad
en el retardo (jitter); la fiabilidad (reliability) de las transmisiones; las caractersticas de multidifusin a
grupos dispersos de usuarios (multicast) y la posibilidad de gestionar mltiples clases de servicio o flujos
de informacin en redes multiclass.
Para que las nuevas tecnologas en comunicaciones puedan ofrecer estas caractersticas es necesario
revisar, potenciar y ampliar las actuales arquitecturas, servicios y protocolosde comunicaciones. En los
ltimos dos o tres aos, las investigaciones en el campo de ATM estn dado lugar a importantes
propuestas cuyo principal objetivo es ofrecer a las aplicaciones demandadas actualmente algunas o
todas las caractersticas citadas anteriormente.
Presentamos en este trabajo los conceptos y propuestas ms novedosas en el contexto de ATM para
ayudar al lector interesado en el dinmico, complejo y sofisticado campo de los protocolos de
comunicaciones. Realizamos la revisin de algunos de los ms importantes conceptos, tcnicas, ideas y
mecanismos en protocolos de altas prestaciones para redes de tecnologa ATM. El principal objetivo de
este documento es ofrecer una actualizada visin general, no extensiva ni profunda, de los protocolos
propuestos y en desarrollo para dotar a las diversas clases de servicio ATM de las citadas
caractersticas de calidad de servicio que aporten las potenciales elevadas prestaciones que la
tecnologa ATM es capaz de ofrecer.
El resto del documento est estructurado de la siguiente forma. La seccin 2 revisa el concepto de
protocolo nativo centrado en el contexto de las redes ATM. La seccin 3 describe las propuestas ms
interesantes actualmente en materia de protocolos de transporte. El apartado 4 comenta las
transferencias multicast como un importante objetivo para una tecnologa orientada a la conexin como

es ATM. Concluimos en la seccin 5 con los campos de investigacin abiertos recientemente como son
las redes activas y los procolos booster.

2.- Protocolos nativos ATM

Las aplicaciones nativas ATM estn especficamente pensadas para usar la tecnologa ATM y para
explotar al mximo sus especiales caractersticas. Los protocolos nativos se encargan, por tanto, de
ofrecer esas caractersticas intrnsecas de las redes de tecnologa ATM (soporte de QoS, sealizacin,
direccionamiento, etc.) a las aplicaciones nativas ATM (VoD, pizarras compartidas, video-conferencia...).
No obstante, existen tambin activas investigaciones para conseguir soportar sobre redes ATM
aplicaciones no nativas ATM desarrolladas para otras tecnologas (IP, Frame Relay, SMDS...).
En [1], el termino native ATM services define servicios ATM especficos disponibles para el software y
hardware residentes en dispositivos de usuario UNI ATM. Por consiguiente, el programador de
aplicaciones dispone de nuevos servicios entre los que se pueden destacar los siguientes:
Transferencias de datos (fiables o no) usando
la capa ATM y varias capas de adaptacin
(AALs).
Disponibilidad de circuitos virtuales
conmutados (SVCs) y circuitos virtuales
permanentes (PVCs).
Consideraciones relativas a la gestin de
trfico (clases de servicio, garantas de QoS,
etc.).
Posibilidad de distribucin de conexiones y de
participacin local en la administracin de la
red (protocolos ILMI y OAM).
El propsito de los servicios nativos ATM es ofrecer el acceso a las clases de servicio o a las
caractersticas de QoS en redes ATM. Estos servicios nativos tambin ofrecen soporte a un amplio y
heterogneo rango de flujos con diversas propiedades y requerimientos recomendados en [1] .
Los protocolos de transferencia nativos ATM gestionan la sealizacin UNI para establecer los SVCs,
configurar PVCs y mapear los perfiles de QoS en la correspondiente clase de servicio. Los protocolos
nativos tambin realizan funciones clsicas como las de transporte, mecanismos de control de errores,
transferencia de datos, y controles de flujo y de congestin.
En la referencia [1] se especifica la definicin semntica de los servicios y consideramos que es til
contrastar esta semntica con las redes ATM actuales que usan TCP como capa de transporte e IPover-ATM como capa de red, planteamiento, por otro lado, poco adecuado [2] por las siguientes
razones:
Las redes IP no garantizan la QoS extremoextremo ofrecida por las redes ATM a circuitos
individuales. IP multiplexa mltiples
conexiones de transporte con distintos
requerimientos de QoS en VCs simples.
TCP no soporta clulas RM (Resource
Management) ABR y por consiguiente no
puede usar directamente las garantas de
QoS ofrecidas por la red.
ATM Adaptation Layer 5 (AAL5) realiza
labores de checksum para detectar corrupcin
de datos. TCP tambin realiza estas labores
(redundantes con AAL5) costosas en
overhead (cada byte de un paquete debe ser
chequeado).
TCP/IP son la representacin de un grupo de
protocolos bastante ms antiguos que ATM y
que ya han experimentado determinados
arreglos y evoluciones lo mismo que las
aplicaciones que los emplean, lo que acaba

dando, en algunos casos, inadecuados

comportamientos.
Estos y otros problemas son eliminados usando pilas de protocolos en modo nativo ATM que son
revisados en este apartado. La Fig. 1 muestra el modelo de referencia para servicios nativos ATM [1].
Adems, las siguientes razones [2] justifican el desarrollo de pilas de protocolos nativos ATM:
En la actualidad existen muchas aplicaciones
pensadas para explotar avanzados servicios
usando tecnologa ATM y tambin existen
antiguas y no nativas aplicaciones. Este
escenario implica cambiar las aplicaciones o
proponer nuevas pilas de protocolos nativos
ATM.
La encapsulacin consecutiva de paquetes
genera problemas de overhead y funciones
redundantes como se ha argumentado
anteriormente.
La limitacin de recursos en los sistemas
finales es otra importante motivacin para
usar pilas de protocolos nativos y ligeros.
La QoS ofrecida por el modo nativo es
aprovechada por los usuarios para demandar
recursos a los proveedores de servicios en
redes privadas. Los proveedores de servicios
pblicos disfrutan tambin de estas ventajas.
ATM, RDSI y la telefona ofrecen un esquema
de direccionamiento universal basado en
NSAP/E.164 el cual es capaz de enrutar
trfico de forma nativa. Por tanto, aunque
ATM dispone de protocolos nativos con
direccionamiento intrnceso estructurado y
jerrquico, ste no es aprovechado por las
aplicaciones que estn basadas en IP. El
esquema de direccionamiento ATM es una de
las principales dificultades en los protocolos
propuestos como nativos [2].
ATM Forum ha definido las especificaciones y tambin existen importantes investigaciones en torno a
los protocolos nativos ATM. En esta seccin se muestran las propuestas ms importantes y actuales en
materia de protocolos nativos ATM[2], [7], [8], [9], [10], [11], [12] que, a su vez,estn sirviendo de base
para nuevas investigaciones.

[8] presentan el diseo, implementacin y comportamiento de una pila en modo nativo ATM y contrasta
la semntica de su capa de transporte con TCP. Este trabajo es diferente a IP-over-ATM, y justifica el
uso de la pila nativa ATM para solventar automticamente los siguientes problemas:
IP-over-ATM no ofrece garanta de QoS pues
sus aplicaciones slo "ven" la interfaz IP.
El ncleo de los sistemas operativos y los
sistemas finales son sobrecargados con
considerable complejidad pues el subsistema
IP-over-ATM debe encargarse de las
peticiones de la sealizacin.
IP-over-ATM debe emular el routing IP sobre
conexiones punto-a-punto de la red ATM lo
que supone pagar un elevado precio en
prestaciones.
La capa de transporte propuesta en [8] ha sido construida para minimizar el overhead y sacar ventaja de
AAL5. Ofrece, entre otras caractersticas, la entrega fiable y no fiable de datos con control de flujo. Este
protocolo de transporte es ampliado en la seccin 5.
[2] presenta N3 (Native Non-broadcasting medium access Networking) un protocolo de transporte ligero y
nativo ATM. La pila N3 se ha diseado para ofrecer avanzados servicios multimedia a comunidades

residenciales. El documento describe una arquitectura capaz de ofrecer aplicaciones nativas ATM. La
pila de protocolo de transporte N3 se basa en implementaciones previas [8] y, adems, aporta otras
importantes novedades. Los principales componentes de N 3 incluyen una API sockets ATM nativa, un
protocolo de transporte ATM y un servicio de nombres ATM (Fig.2).
El protocolo de transporte ATM propuesto en [2] ofrece soporte para tres diferentes tipos de servicio:
entrega garantizada (mecanismos de retransmisin), velocidad garantizada (mecanismo leaky bucket) y
servicio best-effort. Otro objetivo principal de la pila ATM es su compatibilidad con aplicaciones
tradicionales sin necesidad de recompilaciones.
[9] presenta una arquitectura de servicio ATM en modo nativo capaz de ofrecer a las aplicaciones
nativas ATM acceso completo a las diversas clases de servicio ATM. Los elementos de la arquitectura
propuesta se responsabilizan de las transferencias eficientes de datos sobre ATM, del control de errores
extremo-extremo, del control de flujo y congestin de la transferencia de datagramas y de la
multiplexacin de VCs. La referencia [9] introduce los componentes de la arquitectura, sus
funcionalidades y capacidades. Los mayores esfuerzos del protocolo se centran en maximizar la
efectividad del rendimiento extremo-extremo en canales de datos que usan la clase de servicio UBR.
La Fig. 3 presenta los elementos de Native Mode Service Architecture donde el Flow Management es el
componente ms importante. El Flow Management se responsabiliza de manipular los flujos de datos
desde y hasta la red va la interfaz AAL. La segmentacin, el reensamblado y el control de errores es
tambin realizada por esta entidad. Para las clases de servicio CBR, VBR y ABR se emplea un sencillo
esquema de control llamado Back-Pressure Flow. Para servicios UBR se emplea un control de
congestin y de flujo extremo-extremo ms complejo.

[7] describe la semntica de una pila de protocolos y explora una nueva arquitectura de protocolo
adaptada a la tecnologa ATM y a las aplicaciones multimedia. El diseo est basado en tres principios
bsicos: separacin de flujos de control y de datos; minimizacin del overhead y de la duplicidad de
funciones; y acceso de las aplicaciones al nivel ATM con garantas de QoS.
La idea es mezclar el soporte nativo ATM en la estructura existente del protocolo (Fig. 4) que muestra
dos caminos separados en el protocolo: la familia nativa ATM y la familia del protocolo IP. Las
aplicaciones que tienen acceso transparente a la red ATM usan la familia del protocolo PF_INET. El
mapeo de IP en ATM es gestionado por la interfaz de red ATM (IF_ATM) usando el protocolo IP-overATM.
La interfaz Native ATM es constituida por la familia de protocolos PF_ATM que es directamente
soportada encima del dispositivo de red ATM sobrepasando la capa interfaz de red. El mdulo CNTL
abre una conexin de sealizacin con el dispositivo ATM y establece una gestin de las llamadas de
mensajes de configuracin.
PF_ATM separa flujos de datos y de control para aliviar el lmite de comportamiento en las
comunicaciones. Esto permite a los mecanismos de control de trfico ser rpidos y sencillos, mientras
los mecanismos de control pueden ser tan complicados como sea necesario. Esta separacin permite
tambin que los dispositivos puedan estar en los puntos finales de una conexin.
La interfaz PF_ATM da a las aplicaciones acceso directo a la capa de enlace ATM y extiende las
garantas de QoS a los puntos extremos de la comunicacin.
Un segundo prototipo[7] es diseado e implementado con dos objetivos principales en la optimizacin de
la pila nativa ATM:
Optimizar los caminos de datos entre los
adaptadores ATM aprovechando la
separacin de flujos de control y de datos y la
capacidad de gestin de datos especficos de
las conexiones de la pila ATM.

Optimizar el procesamiento de overheads

usando una pila de protocolos nativo ATM en
lugar de UDP/IP.
[11] introduce CONGRESS (CONnection oriented Group-address RESolution Service), otro eficiente
protocolo nativo ATM para la resolucin y gestin de direcciones de grupos multicast en una red ATM. El
servicio CONGRESS resuelve direcciones de grupo multicast y mantiene los miembros pertenecientes a
esos grupos para uso de las aplicaciones. CONGRESS ofrece escalabilidad con su diseo basado en
los dos siguientes principios:
Diseo jerrquico: los servicios del protocolo
son ofrecidos a las aplicaciones por mltiples
servidores organizados jerrquicamente.
No inundacin: se evita la inundacin de la
WAN en cada cambio de grupos multicast.
La referencia [12] presenta kStack, una nueva capa de transporte nativa ATM en el espacio de usuario
con soporte de QoS. Esta implementacin sobre Unix y Windows NT est basada y es compatible con
los trabajos originales de Ahuja, Keshav y Saran [8] Native-Mode ATM Stack comentados anteriormente.
El protocolo kStack es similar al original, pero se ha modificado sustancialmente en aspectos como su
implementacion en el espacio de usuario, se ha ampliado implementando una capa de transporte con
QoS y se ha aadido un mdulo que monitoria la QoS extremo-a-extremo.

3.- Protocolos de transporte para redes ATM

En los dos o tres ltimos aos ha habido numerosos e interesante intentos por disear protocolos de
transporte. La referencia [10] presenta un completo y, ya clsico, resumen de las propuestas ms
interesantes en materia de protocolos de transporte para redes de alta velocidad (mayoritariamente IP
en el artculo). Adems, la referencia [13] ofrece una interesante visin de las caractersticas ms
importantes en los protocolos de elevada velocidad. Son estudiadas tambin diversas arquitecturas de
protocolos y varias tcnicas de implementacin. Los protocolos de transporte de elevada velocidad son
fuente de activas investigaciones y estn en constante evolucin desde hace ms de dos dcadas, lo
que impide ser exhaustivo en este resumen: no citamos todos los protocolos, ni presentamos todos los
conceptos ni podemos analizar todas las soluciones.
Uno de los componentes del mbito de las comunicaciones que ha recibido mayor atencin es la capa
de transporte, la cuarta capa del OSI-RM de los protocolos de comunicaciones. TCP e ISO TP4 son los
dos ms populares protocolos de transporte. Pero centrndonos ms concretamente en el mbito de
ATM, la literatura presenta varios protocolos de transporte y arquitecturas para redes de alta velocidad
revisadas resumidamente a continuacin.
[7] ofrece una excelente y didctica arquitectura de pila de protocolos para aplicaciones multimedia en
modo nativo ATM. Esta arquitectura de protocolo ha sido ya descrita brevemente en la seccin anterior.
[8] presentan el diseo, implementacin y comportamiento de un protocolo situado en la capa de
transporte ATM. Esta es una interesante propuesta en la que se puede destacar que la pila ATM est
formada por tres entidades principales: aplicacin, sealizacin y transporte.
La siguiente Tabla 1 muestra un conjunto de nueve bsicos servicios ortogonales que pueden ser
combinados para obtener los requerimientos de determinadas aplicaciones. Actualmente, la capa de
transporte referenciada en soporta tres clases de servicio o combinacin de servicios. La marca X indica
el servicio bsico soportado en cada clase de servicio general.
Clases de servicio
Servicios

Servicio de
comportamiento
garantizado

Servicio fiable

Servicio Best
effort

- Transferencia Simplex de
datos

- Control de errores

deteccion de

No existente

errores,timeouts, (ofrecido por AAL5)

retransmisiones
- Bucle abierto
- Control de flujo
realimentado

No existente
-

No existente

- Tamao de mensaje
ilimitado

- Eleccin de blocking
- Aplicacin Non-blocking

X
X

X
X

X
X

- Eleccin de byte stream

- Semntica transferencia de
mensajes

X
X

X
X

X
X

requerimientos de
ancho de banda

No soportado

No soportado

- Reserva de recursos

No existente

No existente

- Transferencias Multicast

No soportado

Para servicios no
fiables

- Garantas de QoS

Tabla 1 Servicios ortogonales y clases de servicio

[15] resuelve el problema de soportar HPDC (High Performance Distributed Computing) sobre redes
ATM. Los autores sugieren modificaciones en los mecanismos de recuperacin de prdidas del
protocolo estndar SSCOP [14] y demuestran que el resultado ofrece baja latencia, eficiente
recuperacin de clulas perdidas y es tan robusto como el estndar SSCOP.

4.- Protocolos multipoint

El crecimiento de las redes ATM viene motivado, en parte, por la demanda de servicios multimedia para
grupos dispersos de usuarios. El trfico multicast tiene caractersticas particulares descritas para ATM
en UNI 4.0 [6] y anteriores [5]. La distribucin de informacin punto-a-multipunto (uno-a-muchos) o
multipunto-a-multipunto (muchos-a-muchos) es un objetivo bsico propuesto por varios protocolos y
arquitecturas ATM que ofrecen el soporte multimedia y/o multicast como audio-conferencia, videoconferencia, trabajos colaborativos o VoD.
ATM es an una tecnologa emergente diseada para ser usada por aplicaciones de datos, audio y
video, lo que requiere un buen comportamiento de las transferencias unicast y multicast. User Network
Interface (UNI 3.0) para ATM define conexiones punto-a-multipunto, y las conexiones multipunto-amultipunto slo pueden ser obtenidas de las dos siguientes formas:
El primer esquema consiste en configurar N
conexiones punto-a-multipunto para conseguir
conectar todos los nodos en una topologa
completamente mallada todos-con-todos.
Aunque esta topologa ofrece conexiones
multipunto-a-multipunto, hay que destacar
que no escala bien cuando el nmero de
participantes es elevado.
Una alternativa al anterior esquema es el uso
de un servidor que acta a modo de raz en el
rbol multipunto. Este mtodo slo requiere
un nodo raz para almacenar informacin,
pero la desventaja de este mtodo son las
potenciales congestiones en el servidor
cuando debe encargarse de envos y

retransmisiones de las conexiones

multipunto-a-multipunto.
Para solventar las limitaciones de UNI 3.0 y UNI 3.1 [5] que soportan conexiones uno-a-muchos, pero no
directamente (nativamente) conexiones muchos-a-muchos, y ofrecer a ATM verdadero servicio
multicast, ATM Forum, ITU-T e IETF han realizado varias propuestas al actual mecanismo de
sealizacin ATM (UNI 3.1, UNI 4.0), [4],[5],[6].
Comenzamos destacando la referencia [16] como un reciente trabajo que revisa y compara los
protocolos de transporte multicast ms importantes en Internet como MTP-2, XTP, RTP, SRM, RAMP,
RMTP, MFTP, STORM, etc.. IETF e IRTF (como ITU-T y ATM Forum) tambin impulsan una importante
actividad en este campo. La referencia [16] revisa los ms representativos protocolos multicast y los
clasifica de acuerdo a la taxonoma de varias caractersticas (propagacin de datos, mecanismos de
fiabilidad, retransmisiones, control de congestin y de flujo, gestin de grupos multicast, etc.). En
Internet los mecanismos efectivos de control de congestin son una de las prioridades en las
investigaciones de las transferencias multicast fiables. Los mecanismos de seguridad y las tcnicas
escalables de recuperacin de errores son algunos de los aspectos actualmente en estudio en el campo
de los protocolos de transporte multicast.
Hasta este punto hemos revisado algunos protocolos de transporte ATM y hemos citado sus ms
importantes caractersticas. En esta seccin comentaremos los problemas asociados a las
transferencias multicast uno-a-muchos o muchos-a-muchos. Actualmente no existen excesivas
propuestas en este importante faceta para ATM, pero vamos a resumir algunas de las ms interesantes
en los siguientes prrafos.
SMART (shared many-to-many ATM reservations)[3] es un protocolo para controlar un rbol ATM
multicast compartido soportando comunicaciones muchos-a-muchos (many-to-many). Esta propuesta
tiene importantes caractersticas como que: reside completamente en la capa ATM y no requiere ningn
servidor; soporta uno o varios VCCs (y tambin VPCs) cuyo nmero es libremente configurado y es
independiente del nmero de puntos finales; usa el concepto de bloques de datos como en la clase de
servicio ABT y tambin permite VCCs de las clases CBR, VBR o UBR; el protocolo garantiza que no
existen puntos de interrelacin en los VCC del rbol; son respetadas las garantas del contrato de trfico
asociado con los VCCs, etc. SMART puede ser entendido como un protocolo completamente distribuido
para coordinar la distribucin de VPIs/VCIs.
Para solventar las conocidas dificultades debidas al soporte y uso de muchos-a-muchos VCCs, SMART
usa el mecanismo de Cell Interleaving (sobre un VCC muchos-a-muchos, las clulas de datos desde
diferentes fuentes pueden llegar intercaladas a un destinatario) y tambin Demand Sharing (los recursos
asignados a conexiones muchos-a-muchos son dinmicamente compartidas entre todas las potenciales
fuentes.
El artculo [3] describe el protocolo SMART formal e informalmente, y propone completas pruebas de
correccin y un detallado anlisis de comportamiento para estudios futuros. Tambin son sugeridas otras
investigaciones como son: ofrecer justicia en los accesos a los rboles multicast; investigar las clulas
RM peridicamente para aliviar las congestiones en la red o disminuir el tiempo de acceso del usuario a
los rboles de distribucin multicast; anlisis de las clulas RM dentro de cada VCC o fuera enviando
todas las clulas RM en un VCC dedicado.
En [17] se presenta MWAX un algoritmo dinmico y escalable para routing multicast en el marco PNNI
de redes ATM. Los autores han identificado el problema para conseguir la escalabilidad con protocolos
multipunto-a-multipunto y se proponen soluciones para este problema. El artculo describe un esquema
jerrquico basado en CBT para incorporar routing multipunto-a-multipunto en PNNI. En el algoritmo los
nodos core actan como participantes pasivos para eliminar la dependencia en la seleccin de estos
nodos. Con un mecanismo de backup se consigue un algoritmo tolerante a fallos en los nodos core, lo
cual puede ser fcilmente extendido para incorporar QoS en el routing multicast. El protocolo-algoritmo
MWAS es recursivo, esto es, el mismo protocolo es ejecutado en cada nivel de la jerarqua.
SEAM (Scalable and Efficient ATM Multicast) [18] propone una arquitectura escalable, eficiente y
multicast multipunto-a-multipunto para redes ATM que usa un slo VC para un grupo multicast de
mltiples emisores y receptores y todo ello sin realizar cambios en la capa AAL5 de ATM. Esta
propuesta permite a los grupos multicast aprovechar el soporte de QoS y la escalabilidad del ancho de
banda. Tambin realiza aportaciones para conseguir soportar IP multicast sobre redes ATM extensas.
SEAM usa un slo rbol de distribucin compartido para todos los emisores y receptores. Cada grupo
multicast tiene un core asociado, el cual se usa como punto focal para todos los mensajes de

sealizacin del grupo. Este trabajo deja abiertas investigaciones referentes a la gestin de trfico y a la
entrega fiable de trficos multicasting.
Concluimos esta seccin destacando MCMP (Multiparty Conference Management Protocol) [19] que, sin
estar pensado especficamente para ATM, es un protocolo de nivel sesin/transporte distribuido
extremo-extremo y desarrollado para gestin de grupos de aplicaciones de conferencia. MCMP es un
conjunto de algoritmos de control distribuido para configuracin de conferencias multipunto y gestin de
miembros de grupos de usuarios.
Conceptualmente, MCMP reside en el nivel de sesin en el que se establece la infraestructura para
activar la transferencia de informacin entre los participantes en la conferencia. Pero funcionalmente, el
protocolo acompasa los niveles de sesin y de transporte pues utiliza directamente servicios del nivel de
red. Son destacables las condiciones de correccin (conectividad, validacin, unicidad, consistencia y
terminacin) que deben ser satisfechas una vez que la conferencia ha sido configurada por el algoritmo
de configuracin de MCMP. El artculo muestra exhaustivas pruebas de correccin para uno de los
algoritmos, y tambin describe la especificacin y verificacin del protocolo.

5.- Nuevos campos de investigacin

En todas las redes existen gran variedad de elementos hardware (switchs, routers, bridges, brouters,
hubs, ETDs, etc.) que realizan muy diversas funciones (conmutacin, routing, puenteo, controles de
congestin y de flujo, garanta de QoS, ejecucin de aplicaciones, etc.). En la actualidad la red es
mayormente un canal de comunicacin para transferir paquetes entre equipos finales (ayudada por los
elementos hardware antes citados). Pero tambin se estn realizando importante esfuerzos para
equipar a los elementos hardware con elevadas prestaciones aportadas por diversas tcnicas software.
Esto dota a la red de caractersticas activas (active networks) en el sentido de que los elementos
hardware que la componen computan, modifican u operan los contenidos de los paquetes y tambin
sern capaces de transferir o propagar cdigo. Por consiguiente, una red activa es una red programable.
[20] es una excelente revisin de este novedoso campo de investigacin que discute dos planteamientos
en la realizacin de redes activas, la idea del conmutador programable y la de la cpsula. Una red es
activa si en sus rboles de distribucin multicast existen nodos activos con capacidad para ejecutar
programas y/o capaces de implementar mecanismos de propagacin de cdigo. Algunas de las ventajas
de los protocolos activos son conseguidas instalando nodos activos en puntos estratgicos de la red.
Otro nuevo concepto es presentado en [21] como una metodologa para el diseo de protocolos. Los
protocol boosters son una nueva contribucin a las redes activas o programables. Una ventaja de los
boosters es que pueden ser fcilmente "inyectados" en los sistemas actuales sin provocar cambios en la
infraestructura de red.
Por otro lado, [22] propone el concepto de agente de comunicaciones para servicios de comunicaciones
multimedia en redes de rea extensa. Este papel introduce una arquitectura software orientada a agente
y propone el concepto de agente de comunicacin para servicio de comunicacin multimedia. Los
servicios multimedia son expresados como agentes.
Los conceptos como redes activas, protocolos boosters o agentes software han sido propuestos y
desarrollados para redes IP, sin embargo, la actividad empieza a notarse en las redes ATM, y la
referencia [23] es una de esas recientes investigaciones. Este artculo muestra agentes software mviles
usados para implementar operaciones robustas y funciones de mantenimiento en redes ATM. Los
agentes desempean un rol similar al de las clulas OAM en ATM estndar, pues son transmitidos entre
entidades de control a intervalos regulares usando recursos predefinidos. La diferencia entre los agentes
mviles y las clulas OAM reside en que stos pueden contener cdigo. Para concluir destacar que la
integracin del trfico IP sobre tecnologa ATM es tambin uno de los campos ms activos en la
actualidad. En esta lnea pueden destacarse los siguientes protocolos: IP-over-ATM, IP Switching, Tag
Switching, NHRP, MPOA, IMSS, CSR, ARIS AREQUIPA,RED y EPD.
Referencias
1. ____ "Native ATM Service: Semantic
Description Version 1," ATM Forum Technical
Committee, ATM Forum Document af-saa0048.000, (Feb. 1996).
2. T. Zahariadis, J. Sanchez-P, C. Georgopoulos,
V. Nellas, T. Arvanitis, D. Economou, G.
Stassinopoulos, "Native ATM Protocol Stack
for Internet Applications in Residential

3.

4.

5.
6.

7.

8.

9.

10.

11.

12.
13.

14.
15.

16.

Broadband Networks," Multimedia

Applications Services and Techniques
ECMAST98, Springer, (May 1998).
E. Gauthier, J. Le Boudec and P. Oechslin,
"SMART: A many-to-many Multicast protocol
for ATM," IEEE Journal on Selected Areas in
Communications. Vol. N 3 (April 1.997).
W. D. Zhong, K. Yukimatsu, "Design
requeriments and architectures for multicast
ATM switching," IEICE Trans. Com., Vol E77B, pp. 1420-1428, (Nov. 1994).
____ "ATM user-network interface version 3.1
specification", ATM Forum, (1994).
____ "Traffic Management Specification
Version 4.0," ATM Forum Technical
Committee, ATM Forum Document af-tm0056.000, (April 1996).
D. Kandlur, D. Saha and W. Willebeck,
"Protocol Architecture for multimedia
Application over ATM Networks," IEEE
Journal Selected and Communications Vol.
14, N 7, pp. 1.349-1.359, (Sep. 1996).
R. Ahuja, S. Keshav and H. Saran, "Design,
Implementation, and Performance
Measurement of a Native-Mode ATM
Transport Layer (Estended Version),"
IEEE/ACM Transactions on Networking, Vol 4,
N 4, (Aug. 1996).
R. Karabek, "A Native ATM Protocol
Architecture Design and Performance
Evaluation," IEEE Proceedings 22nd Annual
Conference on Local Computer Networks, pp.
204-210, (1997).
D. C. Feldmeier "A framework of architectural
concepts for high-speed communications
systems," IEEE J. Select. Areas
Commun.,Vol.11, N 4, (May 1993).
T. Anker, D. Breitgand, D. Dolev, Z. Levy,
"Congress: CONnection-oriented Groupaddress RESolution Service," Proceeding of
SPIE'97 vol 3233 on Broadband Networking
Technologies, Nov. (1997).
kStack
http://comet.columbia.edu/software/kStack
T. La Porta and M. Schwartz, "Architectures,
Features, and Implementation of High-Speed
Transport Protocols," IEEE Network
Magazine, pp. 14-22, (May. 1991).
____ "B-ISDN, ATM Adaptation Layer Service.
Specific Connection Oriented Protocol
(SSCOP) Q.2110," ITU-T, (10-Mar. 1994).
J. Sol-Pareta, J. Vila-Sallent, "Networkbased paralell computing over ATM using
improved SSCOP protocol," Computer
Communications 19 pp. 915-926, (1996).
K. Obraczka, "Multicast Transport Protocols: A
survey and Taxonomy," IEEE Communi.
Magazine, (1998).

17. R. Venkateswaran, C.S. Raghavendra, X.

Chen and V.P. Kumar, "A Scalable, Dynamic
Multicast Routing Algorithm in ATM Networks,
" IEEE, pp. 1361-1365 (1.997).
18. Matthias Grossglauser and K.K.
Ramakrishnan, "SEAM: Scalable and Efficient
ATM Multicast," IEEE 1.997, pp. 867-875,
(1.997).
19. M. Nguyen, and M. Schwartz, "MCMP: A
Transport/session level Distributed Protocol
for Desktop Conference Setup," IEEE Journal
Selected and comunications, Vol. 14 N 7, pp.
1404-1421, (Sept. 1996)
20. D. Tennenhouse et al., "A Survey of Active
Network Research," IEEE Communications
Magazine, (1997).
21. David C. Feldmeier, Anthony J. McAuley.
Jonathan M. Smith, Deborah S. Bakin, William
S. Marcus and Thomas M. Releigh, "Protocol
Boosters," IEEE JSAC Vol. 16, N 3, pp. 437443, (April 1.998).
22. R. Kishimoto, "Agent communication system
for multimedia communication services,"
INFOCOM96. Fifteenth Annual Joint
Conference of the IEEE Computer and
Communications Societies. Networking the
Next Generation., Proceedings IEEE Vol. 1,
pp. 10-17, (1996).
23. David A. Halls and Sean G. Rooney,
"Controlling the Tempest: Adaptive
Management in Advanced ATM Control
Architecture," IEEE JSAC Vol. 16, N 3, pp.
414-423, (April 1.998).