atm

30
ATM - Modo de Transferencia Asíncrona MULTIPLEXACION EN ATM: * PROTOCOLO ATM: * La capa de adaptación de ATM: * 1)Capa de convergencia (convergence sublayer (CS)) : * 2)Capa de Segmentación y reensamblaje (segmentation and reassembly (SAR)) * AAL1: * Capa de convergencia: * Capa de segmentación y reensamblaje: * ALL 2: * Capa de convergencia: * Capa de segmentación y recuperación: * AAL 3: * Capa de convergencia: * Capa de segmentación 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 más en estos días en los ambientes Informáticos y de Telecomunicaciones. La tecnología llamada Asynchronous Transfer Mode (ATM) Modo de Transferencia Asíncrona es el corazón de los servicios digitales integrados que ofrecerán las nuevas redes digitales de servicios integrados de Banda Ancha (B-ISDN), para muchos ya no hay cuestionamientos; el llamado tráfico del "Cyber espacio", con su voluminoso y tumultuoso crecimiento, impone a los operadores de redes públicas y privadas una voraz demanda de anchos de banda mayores y flexibles con soluciones robustas. La versatilidad de la conmutación de paquetes de longitud fija, denominadas celdas ATM, son las tablas más

Upload: juanacho001

Post on 15-Jan-2016

4 views

Category:

Documents


0 download

DESCRIPTION

atm

TRANSCRIPT

Page 1: Atm

ATM - Modo de Transferencia Asiacutencrona

MULTIPLEXACION EN ATM PROTOCOLO ATM La capa de adaptacioacuten de ATM

1)Capa de convergencia (convergence sublayer (CS))

2)Capa de Segmentacioacuten y reensamblaje (segmentation and reassembly (SAR))

AAL1

Capa de convergencia

Capa de segmentacioacuten y reensamblaje

ALL 2

Capa de convergencia

Capa de segmentacioacuten y recuperacioacuten

AAL 3

Capa de convergencia

Capa de segmentacioacuten 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 maacutes en estos diacuteas en los ambientes Informaacuteticos y de Telecomunicaciones La tecnologiacutea llamada Asynchronous Transfer Mode (ATM) Modo de Transferencia Asiacutencrona es el corazoacuten de los servicios digitales integrados que ofreceraacuten las nuevas redes digitales de servicios integrados de Banda Ancha (B-ISDN) para muchos ya no hay cuestionamientos el llamado traacutefico del Cyber espacio con su voluminoso y tumultuoso crecimiento impone a los operadores de redes puacuteblicas y privadas una voraz demanda de anchos de banda mayores y flexibles con soluciones robustas La versatilidad de la conmutacioacuten de paquetes de longitud fija denominadas celdas ATM son las tablas maacutes calificadas para soportar la cresta de esta Ciberola donde los surfeadores de la banda ancha navegan Algunos criacuteticos establecen una analogiacutea de la tecnologiacutea ATM con la red digital de servicios integrados o ISDN por sus siglas en ingleacutes Al respecto se escuchan respuestas de expertos que desautorizan esta comparacioacuten aduciendo que la ISDN es una gran tecnologiacutea que llegoacute en una eacutepoca equivocada en teacuterminos de que el mercado estaba principalmente en manos de actores con posiciones monopoliacutesticas Ahora el mercado estaacute cambiando la ISDN estaacute encontrando una gran cantidad de aplicaciones De toda forma la tecnologiacutea ATM se proyecta para diferentes necesidades a pesar de su estrecha relacioacuten con ISDN en teacuterminos de voluacutemenes de datos flexibilidad de conmutacioacuten y facilidades para el operador

Los conmutadores ATM aseguran que el traacutefico de grandes voluacutemenes 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 puacuteblicos de salud con requerimientos de videoconferencias meacutedicas redes financieras interconectadas con los entes de intermediacioacuten y validacioacuten o con las exigencias que pronto seraacuten familiares como viacutedeo en demanda para nuestros hogares con alta definicioacuten de imaacutegenes y calidad de sonido de un CD etc Para el operador con la flexibilidad del ATM una llamada telefoacutenica con traacutefico de voz seraacute tarifado a una tasa diferente a la que estariacutea dispuesto a pagar un cirujano asistiendo en tiempo real a una operacioacuten 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 Ademaacutes la demanda por acceso a Internet ha tomado a la industria de telecomunicaciones como una tormenta Hoy diacutea los accesos conmutados a Internet estaacuten 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 administracioacuten de la red (Network Management) En varios aspectos ATM es el resultado de una pregunta similar a la de teoriacutea del campo unificada en fiacutesica iquestCoacutemo se puede transportar un universo diferente de servicio de voz viacutedeo por un lado y datos por otro de manera eficiente usando una simple tecnologiacutea de conmutacioacuten y multiplexacioacuten ATM contesta esta pregunta combinando la simplicidad de la multiplexacioacuten por divisioacuten en el tiempo (Time Division Multiplex TDM) encontrado en la conmutacioacuten de circuitos con la eficiencia de las redes de conmutacioacuten de paquetes con multiplexacioacuten estadiacutestica Por eso es que algunos hacen reminiscencias de perspectivas de conmutacioacuten de circuitos mientras que otros lo hacen a redes de paquetes orientados a conexioacuten

MULTIPLEXACION EN ATM

Un examen maacutes cercano del protocolo ATM y coacutemo opera ayudaraacute a explicar coacutemo los circuitos virtuales las rutas virtuales los conmutadores y los servicios que ellos acarrean se afectan entre siacute La figura No1 muestra un formato baacutesico y la jerarquiacutea de ATM Una conexioacuten ATM consiste de celdas de informacioacuten 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 raacutefagas (bursty traffic) como los datos Cada celda compuesta por 53 bytes de los cuales 48 (opcionalmente 44) son para trasiego de informacioacuten y los restantes para uso de campos de control (cabecera) con informacioacuten de quieacuten 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 conexioacuten La organizacioacuten de la cabecera (header) variaraacute levemente dependiendo de siacute la informacioacuten relacionada es para interfaces de red a red o de usuario a red Las celdas son enrutadas individualmente a traveacutes de los conmutadores basados en estos identificadores los cuales tienen significado local - ya que pueden ser cambiados de interface a interface

La teacutecnica ATM multiplexa muchas celdas de circuitos virtuales en una ruta (path) virtual colocaacutendolas en particiones (slots) similar a la teacutecnica TDM Sin embargo ATM llena cada slot con celdas de un circuito virtual a la primera oportunidad similar a la operacioacuten de una red conmutada de paquetes La figura No2 describe los procesos de conmutacioacuten impliacutecitos los VC switches y los VP switches

Los slots de celda no usados son llenados con celdas idle identificadas por un patroacuten especiacutefico en la cabecera de la celda Este sistema no es igual al llamado bit stuffingen la multiplexacioacuten Asiacutencrona ya que aplica a celdas enteras Diferentes categoriacuteas de traacutefico son convertidas en celdas ATM viacutea la capa de adaptacioacuten de ATM (AAL - ATM Adaptation Layer) de acuerdo con el protocolo usado (Maacutes adelante se explica este protocolo) La tecnologiacutea ATM ha sido definida tanto por el ANSI como por el CCITT a traveacutes de sus respectivos comiteacutes ANSI T1 UIT SG XVIII como la tecnologiacutea 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 teacutecnicas de conmutacioacuten y multiplexacioacuten en la capa de enlace (Capa 2 del modelo OSI) para el trasiego del traacutefico del usuario final de la fuente al destino dentro de una red El ATM Forum grupo de fabricantes y usuarios dedicado al anaacutelisis y avances de ATM ha aprobado cuatro velocidades UNI (User Network Interfases) para ATM DS3 (44736 Mbits)

SONET STS3c (15552 Mbits) y 100 Mbits para UNI privados y 155 Mbits para UNI privadas UNI privadas se refieren a la interconexioacuten 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 Mbits especificado para redes de operadores (carriers) con redes T3 existentes velocidades UNI adicionales se han venido evaluando y estaacuten ofrecieacutendose Tambieacuten hay un alto intereacutes en interfases para velocidades EI (2Mbps) y T1 (1544 Mbps) para accesos ATM de baja velocidad

PROTOCOLO ATM

El protocolo ATM consiste de tres niveles o capas baacutesicas (Ver figura No 3) La primera capa llamada capa fiacutesica (Physical Layer) define los interfases fiacutesicos con los medios de transmisioacuten y el protocolo de trama para la red ATM es responsable de la correcta transmisioacuten y recepcioacuten de los bits en el medio fiacutesico apropiado A diferencia de muchas tecnologiacuteas LAN como Ethernet que especifica ciertos medios de transmisioacuten (10 base T 10 base 5 etc) ATM es independiente del transporte fiacutesico Las celdas ATM pueden ser transportadas en redes SONET (Synchronous Optical Network) SDH (Synchronous Digital Hierarchy) T3E3 TIEI o auacuten en modems de 9600 bps Hay dos subcapas en la capa fiacutesica que separan el medio fiacutesico de transmisioacuten y la extraccioacuten de los datos

La subcapa PMD (Physical Medium Depedent) tiene que ver con los detalles que se especifican para velocidades de transmisioacuten tipos de conectores fiacutesicos extraccioacuten 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 extraccioacuten de informacioacuten contenida desde la misma capa fiacutesica Esto incluye la generacioacuten y el chequeo del Header Error Correccioacuten (HEC) extrayendo celdas desde el flujo de bits de entrada y el procesamiento de celdas idles y el reconocimiento del liacutemite de la celda Otra funcioacuten importante es intercambiar informacioacuten de operacioacuten y mantenimiento (OAM) con el plano de administracioacuten (Ver figura No4) La segunda capa es la capa ATM Ello define la estructura de la celda y coacutemo las celdas fluyen sobre las conexiones loacutegicas 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 informacioacuten

Las celdas son transmitidas serialmente y se propagan en estricta secuencia numeacuterica a traveacutes de la red El tamantildeo 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 viacutedeo y protocolos sensibles al retardo A pesar de que no se disentildeoacute especiacuteficamente para eso la longitud de la celda ATM acomoda convenientemente dos Fast Packets IPX de 24 bytes cada uno Los comiteacutes de estaacutendares 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 aacuterea 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 puacuteblico (carrier) Especiacuteficamente la funcioacuten 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 conmutacioacuten de las celdas ATM

La capa de adaptacioacuten de ATM

La tercer capa es la ATM Adaptation Layer (AAL) La AAL juega un rol clave en el manejo de muacuteltiples tipos de traacutefico 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 maacutes altas tales como emulacioacuten de circuitos (circuit emulation) viacutedeo 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 estaacuten definidos actualmente La capa de Adaptacioacuten de ATM yace entre el ATM layer y las capas maacutes altas que usan el servicio ATM Su propoacutesito principal es resolver cualquier disparidad entre un servicio requerido por el usuario y atender los servicios disponibles del ATM layer La capa de adaptacioacuten introduce la informacioacuten en paquetes ATM y controla los errores de la transmisioacuten La informacioacuten transportada por la capa de adaptacioacuten se divide en cuatro clases seguacuten las propiedades siguientes

1 Que la informacioacuten que esta siendo transportada dependa o no del tiempo 2 Tasa de bit constantevariable 3 Modo de conexioacuten

Estas propiedades definen ocho clases posibles cuatro se definen como B-ISDN Clases de servicios La capa de adaptacioacuten 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 adaptacioacuten 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 informacioacuten en la cabecera y en el payload depende de la clase de informacioacuten que va a ser transportada

2)Capa de Segmentacioacuten 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 informacioacuten necesaria para el reensamblaje en el destino La figura siguiente aporta una mejor comprensioacuten 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 tamantildeo de la celda ATM para su transmisioacuten Tambieacuten realiza la funcioacuten inversa (reemsamblado) para las unidades de informacioacuten de orden superior Cada porcioacuten es ubicada en su propia unidad de protocolo de segmentacioacuten 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 informacioacuten que regule el tiempo con los datos AAL-1 provee recuperacioacuten de errores e indica la informacioacuten con errores que no podraacute ser recuperada

Capa de convergencia

Las funciones provistas a esta capa difieren dependiendo del servicio que se proveyoacute Provee la correccioacuten de errores

Capa de segmentacioacuten y reensamblaje

En esta capa los datos son segmentados y se les antildeade una cabecera La cabecera contiene 3 campos (ver diagrama)

Nuacutemero de secuencia usado para detectar una insercioacuten o perdida de un paquete Nuacutemero de secuencia para la proteccioacuten usado para corregir errores que ocurren en el

numero de secuencia Indicador de capa de convergencia usado para indicar la presencia de la funcioacuten de la capa

de convergencia

ALL 2

AAL-2 se usa para transferir datos con tasa de bits variable que dependen del tiempo Enviacutea la informacioacuten del tiempo conjuntamente con los datos para que esta puede recuperarse en el destino AAL-2 provee recuperacioacuten de errores e indica la informacioacuten que no puede recuperarse

Capa de convergencia

Esta capa provee para la correccioacuten de errores y transporta la informacioacuten del tiempo desde el origen al destino

Capa de segmentacioacuten y recuperacioacuten

El mensaje es segmentado y se le antildeade 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 informacioacuten es

o BOM comenzando de mensaje o COM continuacioacuten de mensaje o EOM fin de mensaje o indica que el paquete contiene informacioacuten de tiempo u

otra

El payload tambieacuten 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 disentildea para transferir los datos con tasa de bits variable que son independientes del tiempo AAL-3 puede ser dividido en dos modos de operacioacuten

1 Fiable En caso de perdida o mala recepcioacuten de datos estos vuelven a ser enviados El control de flujo es soportado

2 No fiable La recuperacioacuten 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 comuacuten de la capa de convergencia Esto es provisto tambieacuten por el AAL-2 CS Antildeade una cabecera y un payload a la parte comuacuten (ver diagrama)

La cabecera contiene 3 campos Indicador de la parte comuacuten que dice que el payload forma parte de la parte comuacuten Etiqueta de comienzo que indica el comienzo de la parte comuacuten de la capa de

convergencia Tamantildeo del buffer que dice al receptor el espacio necesario para acomodar el mensaje

El payload tambieacuten contiene 3 campos Alineacioacuten 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 comuacuten de la CS(capa de convergencia) El campo de longitud tiene la longitud de la parte comuacuten de la CS

1 Parte especifica del servicio Las funciones proveiacutedas en esta que capa dependen de los servicios pedidos Generalmente se incluyen funciones para la recuperacioacuten y deteccioacuten de errores y puede incluir tambieacuten funciones especiales

Capa de segmentacioacuten y reensamblaje

En esta capa los datos son partidos en paquetes de ATM Una cabecera y el payload que contiene la informacioacuten necesaria para la recuperacioacuten de errores y reensamblaje se antildeaden 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 Continuacioacuten de mensaje EOM Fin de mensaje SSM Mensaje uacutenico en el segmento

2) Numero de secuencia usado para detectar una insercioacuten o una perdida de un paquete 3) Identificador de multiplexacioacuten Este campo se usa para distinguir datos de diferentes comunicaciones que ha sido multiplexadas en una uacutenica conexioacuten de ATM El payload contiene dos de campos 1) Indicado de longitud que indica el nuacutemero de bytes uacutetiles en un paquete parcialmente lleno 2) CRC es para el control de errores

ALL 4

AAL-4 se disentildea para transportar datos con tasa de bits variable independientes del tiempo Es similar al AAL3 y tambieacuten puede operar en transmisioacuten fiable y o fiable AAL-4 provee la capacidad de transferir datos fuera de una conexioacuten expliacutecita

AAL 2 AAL 34 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 traacutefico de redes de aacuterea local (LAN) AAL 2 y AAL 3 soportan paquetes orientados a conexioacuten (Ver figura No5)

(El teacutermino orientado a conexioacuten describe la transferencia de datos despueacutes 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 jamaacutes vean estos errores reportados la degradacioacuten de respuesta o de caudal (through put) seriacutean los uacutenicos siacutentomas A diferencia de los mecanismos de control extremo a extremo que utiliza TCP en internerworking la capacidad de Gbitseg de la red ATM genera un juego de requerimientos necesarios para el control de flujo Si el control del flujo se hiciese como una realimentacioacuten del lazo extremo a extremo en el momento en que el mensaje de control de flujo arribase a la fuente eacutesta habriacutea transmitido ya algunos Mbytes de datos en el sistema exacerbando la congestioacuten Y en el momento en que la fuente reaccionase al mensaje de control la condicioacuten de congestioacuten hubiese podido desaparecer apagando innecesariamente la fuente La constante de tiempo de la realimentacioacuten extremo a extremo en las redes ATM (retardo de realimentacioacuten por producto lazo - ancho de banda) debe ser lo suficientemente alta como para cumplir con las necesidades del usuario sin que la dinaacutemica de la red se vuelva impractica Las condiciones de congestioacuten en las redes ATM estaacuten previstas para que sean extremadamente dinaacutemicas requiriendo de mecanismos de hardware lo suficientemente raacutepidos para llevar a la red al estado estacionario necesitando que la red en siacute eacuteste activamente involucrada en el raacutepido establecimiento de este estado estacionario Sin embargo esta aproximacioacuten simplista de control reactivo de lazo cerrado extremo a extremo en condiciones de congestioacuten no se considera suficiente para las redes ATM El consenso entre los investigadores de este campo arroja recomendaciones que incluyen el empleo de una coleccioacuten de esquemas de control de flujo junto con la colocacioacuten adecuada de los recursos y dimensionamiento de las redes para que aunados se pueda tratar y evadir la congestioacuten ya sea

Detectando y manipulando la congestioacuten que se genera tempranamente monitoreando de cerca las entradassalidas que estaacuten dentro de los conmutadores ATM y reaccionando gradualmente a medida que vaya arribando a ciertos niveles prefijados Tratando y controlando la inyeccioacuten de la conexioacuten de datos dentro de la red en la UNI (unidad interfaz de red) de tal forma que su tasa de inyeccioacuten sea modulada y medida alliacute primero antes de tener que ir a la conexioacuten de usuario a tomar acciones mas draacutesticas El estado de la red debe ser comunicado a la UNI generando raacutepidamente una celda de control de flujo siempre que se vaya a descartar una celda en alguacuten nodo debido a congestioacuten La UNI debe entonces manejar la congestioacuten cambiando su tasa de inyeccioacuten

o notificaacutendola a la conexioacuten de usuario para que cese el flujo dependiendo del nivel de severidad de la congestioacutenEl mayor compromiso durante el control de congestioacuten es el de tratar y afectar solo a los flujos de conexioacuten que son responsables de la congestioacuten y actuar de forma transparente frente a los flujos que observan buen comportamiento Al mismo tiempo permitir que el flujo de conexioacuten utilice tanto ancho de banda como necesite sino hay congestioacuten La recomendacioacuten UIT - T I 371 especifica un contrato de traacutefico que define como el traacutefico del usuario seria administrado El contrato que existe para cada conexion virtual (virtual path o virtual channel) es baacutesicamente un acuerdo entre el usuario y la red con respecto a la Calidad de Servicio (Quality Of Service - Q o S) y los paraacutemetros que regulan el flujo de celdas Estos descriptores de trafico dependen de una particular clase de servicio y pueden incluir bajo la especificacioacuten del ATM Forum UNI a cinco Q o S referenciados en los AALS El objetivo de estas sub clases de servicio es agrupar caracteriacutesticas 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 paraacutemetros pueden incluir el Sustained Cell Rate (SCR) el Miacutenimum Cell Rate (MCR) el Peak Cell Rate (PCR) yo el Burst Tolerance (BT) Para soportar todas las diferentes clases de servicios definidos por los estaacutendares el switch ATM debe ser capaz de definir eacutestos paraacutemetros en base a cada VC o cada VP y debe proveer amortiguadores (buffers) para absorber las raacutefagas de trafico

INTEROPERABILIDAD ENTRE FRAME RELAY Y ATM El objetivo final para todos los servicios descritos anteriormente es una migracioacuten suave de Frame Relay yo SMDS a redes ATM Por ejemplo la recomendacioacuten UIT - T I555 provee un marco para la interoperabilidad de Frame Relay y ATM Para alcanzar una maacutexima eficiencia se trata de brindar este servicio de interoperabilidad en la capa maacutes baja posible mediante conversioacuten de protocolo

PRIMER ESCENARIO

Cuando el servicio de Frame Relay es dado sobre la RDSI en banda ancha y los usuarios se conectan a traveacutes de la UNI de Frame Relay En esta solucioacuten 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 (VCVP) para enlazar los puntos de acceso Frame Relay En este esquema se puede explotar la naturaleza de orientacioacuten a conexioacuten Frame Relay (F R) siguiendo un comportamiento como

El usuario del enrutador pregunta por una conexioacuten al equipo interfaz de red El equipo interfaz de la red coloca las conexiones Frame Relay dentro de una conexioacuten ATM con las direcciones destino apropiadas Por cada trama de equipo interfaz de red traslada de la conexioacuten de Frame Relay a la ATM y viceversa La conexioacuten ATM esta desocupada cuando no se necesitaPara lograr este uacuteltimo punto el manejo de la poliacutetica de conexion del VC sera un aspecto crucial para el desempentildeo de este procedimiento Resulta difiacutecil de terminar el procedimiento para manejar un VC cuando la fuente de traacutefico es no orientada a conexioacuten 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 conexioacuten 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 opcioacuten se toma ventaja del uso actual del FR el cual es proveer un mallado virtual entre diferentes sitios para cargar traacutefico no orientado a conexioacuten 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 conmutacioacuten 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 traveacutes de sus respectivas interfaces de red (NNIs) Esto permitiriacutea a un proveedor de red manejar esta heterogeacutenea red como un todo Frame Relay provee usualmente la interconexioacuten para LAN a pesar de su natural orientacioacuten a conexioacuten 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 sobresimplificacioacuten los dos protocolos (AAL 3 y AAL 5) ofrecen basicamente el mismo servicio CPAAL (Parte Comuacuten 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 implementacioacuten y eficiencia del protocolo que incide en el costo Las caracteriacutesticas a tomar en cuenta cuyo detalle puede ser tema de otro artiacuteculo tienen que ver con Delimitacioacuten y Alineamiento de Tramas Multiplexacioacuten Deteccioacuten de errores de transmisioacuten eficiencia en la transmisioacuten 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 tecnologiacutea de red empresarial virtual del futuro un teacutermino que refleja tanto la evolucioacuten del modelo empresarial global y el eacutenfasis en la conectividad loacutegica donde los usuarios obtienen acceso a los recursos que necesitan y el operador de la red provee las rutas de conexioacuten y asigna el ancho de banda necesario a fuentes de traacutefico muy diferentes (voz datos viacutedeo) Aquellos que construyen y operan redes deben volver los ojos a las capacidades de la tecnologiacutea ATM ya que aspiran a la maacutegica combinacioacuten interconectividad global - escalabilidad de tecnologiacuteas y satisfaccioacuten del cliente local

BIBLIOGRAFIA

1 CCITT Rec I362 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 vol2 No8 ATM Testing crosses network boundaries Jim Frimmel

6 Newslink Alcatel Telecomrsquos customer magazine Vol IV No4 4th Quarter 1996 Adapting Networks to the Internet Challenge Krish Prabhu

Trabajo realizado por

Ivan Dario Cruz PradaNicruz[arroba]col1telecomcomco

Revisioacuten y Clasificacioacuten de Protocolos para Redes de Tecnologiacutea ATM

Joseacute Luis Gonzaacutelez-Saacutenchez y Jordi Domingo-Pascual

ResumenLa tecnologiacutea 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 investigacioacuten maacutes activo con la aspiracioacuten 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 asiacute como las caracteriacutesticas multicast la escalabilidad y la fiabilidad Se profundiza en el concepto de protocolo nativo ATM y son introducidos los protocolos maacutes importantes que satisfacen este importante requerimiento (N3 CONGRESS y kStack entre otros) Es importante destacar tambieacuten los protocolos de transporte pensados especiacuteficamente para la tecnologiacutea ATM La caracteriacutestica multicast (multipoint-to-multipoint) es una de las que maacutes esfuerzo estaacute costando garantizar a ATM pero existen ya propuestas que permiten la comunicacioacuten fiable a elevados anchos de banda y entre muacuteltiples emisores y receptores (SMART MCMP o MWAX) El artiacuteculo concluye con las investigacioness maacutes novedosas en torno a los protocolos ATM como las iniciativas que proponen redes ATM programables o activas (active networks) usando agentes moacuteviles

1-Introduccioacuten y motivacionesLa actual demanda de aplicaciones relacionadas con informacioacuten multimedia como son la video-conferencia audio-conferencia video bajo demanda (VoD) o sistemas colaborativos (pizarras compartidas teletrabajo telemedicina etc) y su coexistencia con aplicaciones maacutes claacutesicas (bases de datos transferencias de ficheros WWW etc) requiere tecnologiacuteas de comunicaciones capaces de ofrecer elevadas prestaciones Estas elevadas prestaciones estaacuten directamente relacionadas con la calidad de servicio (QoS) y concretamente con conceptos claramente parametrizables como el ancho de banda y la velocidad de transmisioacuten (throughput) el retardo de las transferencias (delay) la variabilidad en el retardo (jitter) la fiabilidad (reliability) de las transmisiones las caracteriacutesticas de multidifusioacuten a grupos dispersos de usuarios (multicast) y la posibilidad de gestionar muacuteltiples clases de servicio o flujos de informacioacuten en redes multiclass Para que las nuevas tecnologiacuteas en comunicaciones puedan ofrecer estas caracteriacutesticas es necesario revisar potenciar y ampliar las actuales arquitecturas servicios y protocolosde comunicaciones En los uacuteltimos dos o tres antildeos las investigaciones en el campo de ATM estaacuten dado lugar a importantes propuestas cuyo principal objetivo es ofrecer a las aplicaciones demandadas actualmente algunas o todas las caracteriacutesticas citadas anteriormente Presentamos en este trabajo los conceptos y propuestas maacutes novedosas en el contexto de ATM para ayudar al lector interesado en el dinaacutemico complejo y sofisticado campo de los protocolos de comunicaciones Realizamos la revisioacuten de algunos de los maacutes importantes conceptos teacutecnicas ideas y mecanismos en protocolos de altas prestaciones para redes de tecnologiacutea ATM El principal objetivo de este documento es ofrecer una actualizada visioacuten general no extensiva ni profunda de los protocolos propuestos y en desarrollo para dotar a las diversas clases de servicio ATM de las citadas caracteriacutesticas de calidad de servicio que aporten las potenciales elevadas prestaciones que la tecnologiacutea ATM es capaz de ofrecer El resto del documento estaacute estructurado de la siguiente forma La seccioacuten 2 revisa el concepto de protocolo nativo centrado en el contexto de las redes ATM La seccioacuten 3 describe las propuestas maacutes interesantes actualmente en materia de protocolos de transporte El apartado 4 comenta las transferencias multicast como un importante objetivo para una tecnologiacutea orientada a la conexioacuten como es ATM Concluimos en la seccioacuten 5 con los campos de investigacioacuten abiertos recientemente como son las redes activas y los procolos booster

2- Protocolos nativos ATM

Las aplicaciones nativas ATM estaacuten especiacuteficamente pensadas para usar la tecnologiacutea ATM y para explotar al maacuteximo sus especiales caracteriacutesticas Los protocolos nativos se encargan por tanto de ofrecer esas caracteriacutesticas intriacutensecas de las redes de tecnologiacutea ATM (soporte de QoS sentildealizacioacuten direccionamiento etc) a las aplicaciones nativas ATM (VoD pizarras compartidas video-conferencia) No obstante existen tambieacuten activas investigaciones para conseguir soportar sobre redes ATM aplicaciones no nativas ATM desarrolladas para otras tecnologiacuteas (IP Frame Relay SMDS) En [1] el termino native ATM services define servicios ATM especiacuteficos 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 adaptacioacuten (AALs) Disponibilidad de circuitos virtuales conmutados (SVCs) y circuitos virtuales permanentes (PVCs) Consideraciones relativas a la gestioacuten de traacutefico (clases de servicio garantiacuteas de QoS etc) Posibilidad de distribucioacuten de conexiones y de participacioacuten local en la administracioacuten de la red (protocolos ILMI y OAM)

El propoacutesito de los servicios nativos ATM es ofrecer el acceso a las clases de servicio o a las caracteriacutesticas de QoS en redes ATM Estos servicios nativos tambieacuten ofrecen soporte a un amplio y heterogeacuteneo rango de flujos con diversas propiedades y requerimientos recomendados en [1] Los protocolos de transferencia nativos ATM gestionan la sentildealizacioacuten UNI para establecer los SVCs configurar PVCs y mapear los perfiles de QoS en la correspondiente clase de servicio Los protocolos nativos tambieacuten realizan funciones claacutesicas como las de transporte mecanismos de control de errores transferencia de datos y controles de flujo y de congestioacuten En la referencia [1] se especifica la definicioacuten semaacutentica de los servicios y consideramos que es uacutetil contrastar esta semaacutentica con las redes ATM actuales que usan TCP como capa de transporte e IP-over-ATM como capa de red planteamiento por otro lado poco adecuado [2] por las siguientes razones

Las redes IP no garantizan la QoS extremo-extremo ofrecida por las redes ATM a circuitos individuales IP multiplexa muacuteltiples conexiones de transporte con distintos requerimientos de QoS en VCs simples TCP no soporta ceacutelulas RM (Resource Management) ABR y por consiguiente no puede usar directamente las garantiacuteas de QoS ofrecidas por la red ATM Adaptation Layer 5 (AAL5) realiza labores de checksum para detectar corrupcioacuten de datos TCP tambieacuten realiza estas labores (redundantes con AAL5) costosas en overhead (cada byte de un paquete debe ser chequeado) TCPIP son la representacioacuten de un grupo de protocolos bastante maacutes 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] Ademaacutes 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 tecnologiacutea ATM y tambieacuten existen antiguas y no nativas aplicaciones Este escenario implica cambiar las aplicaciones o proponer nuevas pilas de protocolos nativos ATM La encapsulacioacuten consecutiva de paquetes genera problemas de overhead y funciones redundantes como se ha argumentado anteriormente La limitacioacuten de recursos en los sistemas finales es otra importante motivacioacuten 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 puacuteblicos disfrutan tambieacuten de estas ventajas ATM RDSI y la telefoniacutea ofrecen un esquema de direccionamiento universal basado en NSAPE164 el cual es capaz de enrutar traacutefico de forma nativa Por tanto aunque ATM dispone de protocolos nativos con direccionamiento intriacutenceso estructurado y jeraacuterquico eacuteste no es aprovechado por las aplicaciones que estaacuten 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 tambieacuten existen importantes investigaciones en torno a los protocolos nativos ATM En esta seccioacuten se muestran las propuestas maacutes importantes y actuales en materia de protocolos nativos ATM[2] [7] [8] [9] [10] [11] [12] que a su vezestaacuten sirviendo de base para nuevas investigaciones

[8] presentan el disentildeo implementacioacuten y comportamiento de una pila en modo nativo ATM y contrasta la semaacutentica 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 automaacuteticamente los siguientes problemas

IP-over-ATM no ofrece garantiacutea de QoS pues sus aplicaciones soacutelo ven la interfaz IP El nuacutecleo 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 sentildealizacioacuten 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 caracteriacutesticas la entrega fiable y no fiable de datos con control de flujo Este protocolo de transporte es ampliado en la seccioacuten 5 [2] presenta N3 (Native Non-broadcasting medium access Networking) un protocolo de transporte ligero y nativo ATM La pila N3 se ha disentildeado 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 ademaacutes aporta otras importantes novedades Los principales componentes de N3 incluyen una API sockets ATM nativa un protocolo de transporte ATM y un servicio de nombres ATM (Fig2) El protocolo de transporte ATM propuesto en [2] ofrece soporte para tres diferentes tipos de servicio entrega garantizada (mecanismos de retransmisioacuten) 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 congestioacuten de la transferencia de datagramas y de la multiplexacioacuten 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 maacutes importante El Flow Management se responsabiliza de manipular los flujos de datos desde y hasta la red viacutea la interfaz AAL La segmentacioacuten el reensamblado y el control de errores es tambieacuten 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 congestioacuten y de flujo extremo-extremo maacutes complejo

[7] describe la semaacutentica de una pila de protocolos y explora una nueva arquitectura de protocolo adaptada a la tecnologiacutea ATM y a las aplicaciones multimedia El disentildeo estaacute basado en tres principios baacutesicos separacioacuten de flujos de control y de datos minimizacioacuten del overhead y de la duplicidad de funciones y acceso de las aplicaciones al nivel ATM con garantiacuteas 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-over-ATM 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 moacutedulo CNTL abre una conexioacuten de sentildealizacioacuten con el dispositivo ATM y establece una gestioacuten de las llamadas de mensajes de configuracioacuten PF_ATM separa flujos de datos y de control para aliviar el liacutemite de comportamiento en las comunicaciones Esto permite a los mecanismos de control de traacutefico ser raacutepidos y sencillos mientras los mecanismos de control pueden ser tan complicados como sea necesario Esta separacioacuten permite tambieacuten que los dispositivos puedan estar en los puntos finales de una conexioacuten La interfaz PF_ATM da a las aplicaciones acceso directo a la capa de enlace ATM y extiende las garantiacuteas de QoS a los puntos extremos de la comunicacioacuten Un segundo prototipo[7] es disentildeado e implementado con dos objetivos principales en la optimizacioacuten de la pila nativa ATM

Optimizar los caminos de datos entre los adaptadores ATM aprovechando la separacioacuten de flujos de control y de datos y la capacidad de gestioacuten de datos especiacuteficos de las conexiones de la pila ATM

Optimizar el procesamiento de overheads usando una pila de protocolos nativo ATM en lugar de UDPIP

[11] introduce CONGRESS (CONnection oriented Group-address RESolution Service) otro eficiente protocolo nativo ATM para la resolucioacuten y gestioacuten 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 disentildeo basado en los dos siguientes principios

Disentildeo jeraacuterquico los servicios del protocolo son ofrecidos a las aplicaciones por muacuteltiples servidores organizados jeraacuterquicamente No inundacioacuten se evita la inundacioacuten 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 implementacioacuten sobre Unix y Windows NT estaacute 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 antildeadido un moacutedulo que monitoria la QoS extremo-a-extremo

3- Protocolos de transporte para redes ATMEn los dos o tres uacuteltimos antildeos ha habido numerosos e interesante intentos por disentildear protocolos de transporte La referencia [10] presenta un completo y ya claacutesico resumen de las propuestas maacutes interesantes en materia de protocolos de transporte para redes de alta velocidad (mayoritariamente IP en el artiacuteculo) Ademaacutes la referencia [13] ofrece una interesante visioacuten de las caracteriacutesticas maacutes importantes en los protocolos de elevada velocidad Son estudiadas tambieacuten diversas arquitecturas de protocolos y varias teacutecnicas de implementacioacuten Los protocolos de transporte de elevada velocidad son fuente de activas investigaciones y estaacuten en constante evolucioacuten desde hace maacutes de dos deacutecadas 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 aacutembito de las comunicaciones que ha recibido mayor atencioacuten es la capa de transporte la cuarta capa del OSI-RM de los protocolos de comunicaciones TCP e ISO TP4 son los dos maacutes populares protocolos de transporte Pero centraacutendonos maacutes concretamente en el aacutembito de ATM la literatura presenta varios protocolos de transporte y arquitecturas para redes de alta velocidad revisadas resumidamente a continuacioacuten [7] ofrece una excelente y didaacutectica arquitectura de pila de protocolos para aplicaciones multimedia en modo nativo ATM Esta arquitectura de protocolo ha sido ya descrita brevemente en la seccioacuten anterior [8] presentan el disentildeo implementacioacuten 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 estaacute formada por tres entidades principales aplicacioacuten sentildealizacioacuten y transporte La siguiente Tabla 1 muestra un conjunto de nueve baacutesicos 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 combinacioacuten de servicios La marca X indica el servicio baacutesico soportado en cada clase de servicio general

Clases de servicio

Servicios Servicio de comportamiento

garantizado

Servicio fiable Servicio Best effort

- Transferencia Simplex de datos

X X X

- Control de errores - deteccion de errorestimeouts retransmisiones

No existente (ofrecido por

AAL5)

- Bucle abierto - Control de flujo realimentado

No existente -

- X

- No existente

- Tamantildeo de mensaje ilimitado

X X X

- Eleccioacuten de blocking - Aplicacioacuten Non-blocking

X X

X X

X X

- Eleccioacuten de byte stream - Semaacutentica transferencia de mensajes

X X

X X

X X

- Garantiacuteas de QoS requerimientos de ancho de banda

No soportado No soportado

- Reserva de recursos X No existente No existente

- Transferencias Multicast X No soportado Para servicios no fiables

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 recuperacioacuten de peacuterdidas del protocolo estaacutendar SSCOP [14] y demuestran que el resultado ofrece baja latencia eficiente recuperacioacuten de ceacutelulas perdidas y es tan robusto como el estaacutendar SSCOP

4- Protocolos multipointEl crecimiento de las redes ATM viene motivado en parte por la demanda de servicios multimedia para grupos dispersos de usuarios El traacutefico multicast tiene caracteriacutesticas particulares descritas para ATM en UNI 40 [6] y anteriores [5] La distribucioacuten de informacioacuten punto-a-multipunto (uno-a-muchos) o multipunto-a-multipunto (muchos-a-muchos) es un objetivo baacutesico propuesto por varios protocolos y arquitecturas ATM que ofrecen el soporte multimedia yo multicast como audio-conferencia video-conferencia trabajos colaborativos o VoD ATM es auacuten una tecnologiacutea emergente disentildeada 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 30) para ATM define conexiones punto-a-multipunto y las conexiones multipunto-a-multipunto soacutelo 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 topologiacutea completamente mallada todos-con-todos Aunque esta topologiacutea ofrece conexiones multipunto-a-multipunto hay que destacar que no escala bien cuando el nuacutemero de participantes es elevado Una alternativa al anterior esquema es el uso de un servidor que actuacutea a modo de raiacutez en el aacuterbol multipunto Este meacutetodo soacutelo requiere un nodo raiacutez para almacenar informacioacuten pero la desventaja de este meacutetodo son las potenciales congestiones en el servidor

cuando debe encargarse de enviacuteos y retransmisiones de las conexiones multipunto-a-multipunto

Para solventar las limitaciones de UNI 30 y UNI 31 [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 sentildealizacioacuten ATM (UNI 31 UNI 40) [4][5][6] Comenzamos destacando la referencia [16] como un reciente trabajo que revisa y compara los protocolos de transporte multicast maacutes importantes en Internet como MTP-2 XTP RTP SRM RAMP RMTP MFTP STORM etc IETF e IRTF (como ITU-T y ATM Forum) tambieacuten impulsan una importante actividad en este campo La referencia [16] revisa los maacutes representativos protocolos multicast y los clasifica de acuerdo a la taxonomiacutea de varias caracteriacutesticas (propagacioacuten de datos mecanismos de fiabilidad retransmisiones control de congestioacuten y de flujo gestioacuten de grupos multicast etc) En Internet los mecanismos efectivos de control de congestioacuten son una de las prioridades en las investigaciones de las transferencias multicast fiables Los mecanismos de seguridad y las teacutecnicas escalables de recuperacioacuten 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 maacutes importantes caracteriacutesticas En esta seccioacuten 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 maacutes interesantes en los siguientes paacuterrafos SMART (shared many-to-many ATM reservations)[3] es un protocolo para controlar un aacuterbol ATM multicast compartido soportando comunicaciones muchos-a-muchos (many-to-many) Esta propuesta tiene importantes caracteriacutesticas como que reside completamente en la capa ATM y no requiere ninguacuten servidor soporta uno o varios VCCs (y tambieacuten VPCs) cuyo nuacutemero es libremente configurado y es independiente del nuacutemero de puntos finales usa el concepto de bloques de datos como en la clase de servicio ABT y tambieacuten permite VCCs de las clases CBR VBR o UBR el protocolo garantiza que no existen puntos de interrelacioacuten en los VCC del aacuterbol son respetadas las garantiacuteas del contrato de traacutefico asociado con los VCCs etc SMART puede ser entendido como un protocolo completamente distribuido para coordinar la distribucioacuten de VPIsVCIs 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 ceacutelulas de datos desde diferentes fuentes pueden llegar intercaladas a un destinatario) y tambieacuten Demand Sharing (los recursos asignados a conexiones muchos-a-muchos son dinaacutemicamente compartidas entre todas las potenciales fuentes El artiacuteculo [3] describe el protocolo SMART formal e informalmente y propone completas pruebas de correccioacuten y un detallado anaacutelisis de comportamiento para estudios futuros Tambieacuten son sugeridas otras investigaciones como son ofrecer justicia en los accesos a los aacuterboles multicast investigar las ceacutelulas RM perioacutedicamente para aliviar las congestiones en la red o disminuir el tiempo de acceso del usuario a los aacuterboles de distribucioacuten multicast anaacutelisis de las ceacutelulas RM dentro de cada VCC o fuera enviando todas las ceacutelulas RM en un VCC dedicado En [17] se presenta MWAX un algoritmo dinaacutemico 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 artiacuteculo describe un esquema jeraacuterquico basado en CBT para incorporar routing multipunto-a-multipunto en PNNI En el algoritmo los nodos core actuacutean como participantes pasivos para eliminar la dependencia en la seleccioacuten de estos nodos Con un mecanismo de backup se consigue un algoritmo tolerante a fallos en los nodos core lo cual puede ser faacutecilmente 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 jerarquiacutea SEAM (Scalable and Efficient ATM Multicast) [18] propone una arquitectura escalable eficiente y multicast multipunto-a-multipunto para redes ATM que usa un soacutelo VC para un grupo multicast de muacuteltiples 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 Tambieacuten realiza aportaciones para conseguir soportar IP multicast sobre redes ATM extensas

SEAM usa un soacutelo aacuterbol de distribucioacuten 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 sentildealizacioacuten del grupo Este trabajo deja abiertas investigaciones referentes a la gestioacuten de traacutefico y a la entrega fiable de traacuteficos multicasting Concluimos esta seccioacuten destacando MCMP (Multiparty Conference Management Protocol) [19] que sin estar pensado especiacuteficamente para ATM es un protocolo de nivel sesioacutentransporte distribuido extremo-extremo y desarrollado para gestioacuten de grupos de aplicaciones de conferencia MCMP es un conjunto de algoritmos de control distribuido para configuracioacuten de conferencias multipunto y gestioacuten de miembros de grupos de usuarios Conceptualmente MCMP reside en el nivel de sesioacuten en el que se establece la infraestructura para activar la transferencia de informacioacuten entre los participantes en la conferencia Pero funcionalmente el protocolo acompasa los niveles de sesioacuten y de transporte pues utiliza directamente servicios del nivel de red Son destacables las condiciones de correccioacuten (conectividad validacioacuten unicidad consistencia y terminacioacuten) que deben ser satisfechas una vez que la conferencia ha sido configurada por el algoritmo de configuracioacuten de MCMP El artiacuteculo muestra exhaustivas pruebas de correccioacuten para uno de los algoritmos y tambieacuten describe la especificacioacuten y verificacioacuten del protocolo

5- Nuevos campos de investigacioacutenEn todas las redes existen gran variedad de elementos hardware (switchs routers bridges brouters hubs ETDs etc) que realizan muy diversas funciones (conmutacioacuten routing puenteo controles de congestioacuten y de flujo garantiacutea de QoS ejecucioacuten de aplicaciones etc) En la actualidad la red es mayormente un canal de comunicacioacuten para transferir paquetes entre equipos finales (ayudada por los elementos hardware antes citados) Pero tambieacuten se estaacuten realizando importante esfuerzos para equipar a los elementos hardware con elevadas prestaciones aportadas por diversas teacutecnicas software Esto dota a la red de caracteriacutesticas activas (active networks) en el sentido de que los elementos hardware que la componen computan modifican u operan los contenidos de los paquetes y tambieacuten seraacuten capaces de transferir o propagar coacutedigo Por consiguiente una red activa es una red programable [20] es una excelente revisioacuten de este novedoso campo de investigacioacuten que discute dos planteamientos en la realizacioacuten de redes activas la idea del conmutador programable y la de la caacutepsula Una red es activa si en sus aacuterboles de distribucioacuten multicast existen nodos activos con capacidad para ejecutar programas yo capaces de implementar mecanismos de propagacioacuten de coacutedigo Algunas de las ventajas de los protocolos activos son conseguidas instalando nodos activos en puntos estrateacutegicos de la red Otro nuevo concepto es presentado en [21] como una metodologiacutea para el disentildeo de protocolos Los protocol boosters son una nueva contribucioacuten a las redes activas o programables Una ventaja de los boosters es que pueden ser faacutecilmente 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 aacuterea extensa Este papel introduce una arquitectura software orientada a agente y propone el concepto de agente de comunicacioacuten para servicio de comunicacioacuten 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 artiacuteculo muestra agentes software moacuteviles usados para implementar operaciones robustas y funciones de mantenimiento en redes ATM Los agentes desempentildean un rol similar al de las ceacutelulas OAM en ATM estaacutendar pues son transmitidos entre entidades de control a intervalos regulares usando recursos predefinidos La diferencia entre los agentes moacuteviles y las ceacutelulas OAM reside en que eacutestos pueden contener coacutedigo Para concluir destacar que la integracioacuten del traacutefico IP sobre tecnologiacutea ATM es tambieacuten uno de los campos maacutes activos en la actualidad En esta liacutenea pueden destacarse los siguientes protocolos IP-over-ATM IP Switching Tag Switching NHRP MPOA IMSS CSR ARIS AREQUIPARED y EPD Referencias

1 ____ Native ATM Service Semantic Description Version 1 ATM Forum Technical Committee ATM Forum Document af-saa-0048000 (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 Broadband Networks Multimedia Applications Services and Techniques ECMASTrsquo98 Springer (May 1998)

3 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 Nordm 3 (April 1997)

4 W D Zhong K Yukimatsu Design requeriments and architectures for multicast ATM switching IEICE Trans Com Vol E77-B pp 1420-1428 (Nov 1994)

5 ____ ATM user-network interface version 31 specification ATM Forum (1994)

6 ____ Traffic Management Specification Version 40 ATM Forum Technical Committee ATM Forum Document af-tm-0056000 (April 1996)

7 D Kandlur D Saha and W Willebeck Protocol Architecture for multimedia Application over ATM Networks IEEE Journal Selected and Communications Vol 14 Nordm 7 pp 1349-1359 (Sep 1996)

8 R Ahuja S Keshav and H Saran Design Implementation and Performance Measurement of a Native-Mode ATM Transport Layer (Estended Version) IEEEACM Transactions on Networking Vol 4 Nordm 4 (Aug 1996)

9 R Karabek A Native ATM Protocol Architecture Design and Performance Evaluation IEEE Proceedings 22nd Annual Conference on Local Computer Networks pp 204-210 (1997)

10 D C Feldmeier A framework of architectural concepts for high-speed communications systems IEEE J Select Areas CommunVol11 Nordm 4 (May 1993)

11 T Anker D Breitgand D Dolev Z Levy Congress CONnection-oriented Group-address RESolution Service Proceeding of SPIE97 vol 3233 on Broadband Networking Technologies Nov (1997)

12 kStack httpcometcolumbiaedusoftwarekStack

13 T La Porta and M Schwartz Architectures Features and Implementation of High-Speed Transport Protocols IEEE Network Magazine pp 14-22 (May 1991)

14 ____ B-ISDN ATM Adaptation Layer Service Specific Connection Oriented Protocol (SSCOP) Q2110 ITU-T (10-Mar 1994)

15 J Soleacute-Pareta J Vila-Sallent Network-based paralell computing over ATM using improved SSCOP protocol Computer Communications 19 pp 915-926 (1996)

16 K Obraczka Multicast Transport Protocols A survey and Taxonomy IEEE Communi Magazine (1998)

17 R Venkateswaran CS Raghavendra X Chen and VP Kumar A Scalable Dynamic Multicast Routing Algorithm in ATM Networks IEEE pp 1361-1365 (1997)

18 Matthias Grossglauser and KK Ramakrishnan SEAM Scalable and Efficient ATM Multicast IEEE 1997 pp 867-875 (1997)

19 M Nguyen and M Schwartz MCMP A Transportsession level Distributed Protocol for Desktop Conference Setup IEEE Journal Selected and comunications Vol 14 Nordm 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 Nordm 3 pp 437-443 (April 1998)

22 R Kishimoto Agent communication system for multimedia communication services INFOCOMrsquo96 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 Nordm 3 pp 414-423 (April 1998)

  • ATM - Modo de Transferencia Asiacutencrona
  • Revisioacuten y Clasificacioacuten de Protocolos para Redes de Tecnologiacutea ATM
    • Resumen
    • 1-Introduccioacuten y motivaciones
    • 2- Protocolos nativos ATM
    • 3- Protocolos de transporte para redes ATM
    • 4- Protocolos multipoint
    • 5- Nuevos campos de investigacioacuten
      • Referencias
Page 2: Atm

Los conmutadores ATM aseguran que el traacutefico de grandes voluacutemenes 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 puacuteblicos de salud con requerimientos de videoconferencias meacutedicas redes financieras interconectadas con los entes de intermediacioacuten y validacioacuten o con las exigencias que pronto seraacuten familiares como viacutedeo en demanda para nuestros hogares con alta definicioacuten de imaacutegenes y calidad de sonido de un CD etc Para el operador con la flexibilidad del ATM una llamada telefoacutenica con traacutefico de voz seraacute tarifado a una tasa diferente a la que estariacutea dispuesto a pagar un cirujano asistiendo en tiempo real a una operacioacuten 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 Ademaacutes la demanda por acceso a Internet ha tomado a la industria de telecomunicaciones como una tormenta Hoy diacutea los accesos conmutados a Internet estaacuten 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 administracioacuten de la red (Network Management) En varios aspectos ATM es el resultado de una pregunta similar a la de teoriacutea del campo unificada en fiacutesica iquestCoacutemo se puede transportar un universo diferente de servicio de voz viacutedeo por un lado y datos por otro de manera eficiente usando una simple tecnologiacutea de conmutacioacuten y multiplexacioacuten ATM contesta esta pregunta combinando la simplicidad de la multiplexacioacuten por divisioacuten en el tiempo (Time Division Multiplex TDM) encontrado en la conmutacioacuten de circuitos con la eficiencia de las redes de conmutacioacuten de paquetes con multiplexacioacuten estadiacutestica Por eso es que algunos hacen reminiscencias de perspectivas de conmutacioacuten de circuitos mientras que otros lo hacen a redes de paquetes orientados a conexioacuten

MULTIPLEXACION EN ATM

Un examen maacutes cercano del protocolo ATM y coacutemo opera ayudaraacute a explicar coacutemo los circuitos virtuales las rutas virtuales los conmutadores y los servicios que ellos acarrean se afectan entre siacute La figura No1 muestra un formato baacutesico y la jerarquiacutea de ATM Una conexioacuten ATM consiste de celdas de informacioacuten 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 raacutefagas (bursty traffic) como los datos Cada celda compuesta por 53 bytes de los cuales 48 (opcionalmente 44) son para trasiego de informacioacuten y los restantes para uso de campos de control (cabecera) con informacioacuten de quieacuten 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 conexioacuten La organizacioacuten de la cabecera (header) variaraacute levemente dependiendo de siacute la informacioacuten relacionada es para interfaces de red a red o de usuario a red Las celdas son enrutadas individualmente a traveacutes de los conmutadores basados en estos identificadores los cuales tienen significado local - ya que pueden ser cambiados de interface a interface

La teacutecnica ATM multiplexa muchas celdas de circuitos virtuales en una ruta (path) virtual colocaacutendolas en particiones (slots) similar a la teacutecnica TDM Sin embargo ATM llena cada slot con celdas de un circuito virtual a la primera oportunidad similar a la operacioacuten de una red conmutada de paquetes La figura No2 describe los procesos de conmutacioacuten impliacutecitos los VC switches y los VP switches

Los slots de celda no usados son llenados con celdas idle identificadas por un patroacuten especiacutefico en la cabecera de la celda Este sistema no es igual al llamado bit stuffingen la multiplexacioacuten Asiacutencrona ya que aplica a celdas enteras Diferentes categoriacuteas de traacutefico son convertidas en celdas ATM viacutea la capa de adaptacioacuten de ATM (AAL - ATM Adaptation Layer) de acuerdo con el protocolo usado (Maacutes adelante se explica este protocolo) La tecnologiacutea ATM ha sido definida tanto por el ANSI como por el CCITT a traveacutes de sus respectivos comiteacutes ANSI T1 UIT SG XVIII como la tecnologiacutea 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 teacutecnicas de conmutacioacuten y multiplexacioacuten en la capa de enlace (Capa 2 del modelo OSI) para el trasiego del traacutefico del usuario final de la fuente al destino dentro de una red El ATM Forum grupo de fabricantes y usuarios dedicado al anaacutelisis y avances de ATM ha aprobado cuatro velocidades UNI (User Network Interfases) para ATM DS3 (44736 Mbits)

SONET STS3c (15552 Mbits) y 100 Mbits para UNI privados y 155 Mbits para UNI privadas UNI privadas se refieren a la interconexioacuten 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 Mbits especificado para redes de operadores (carriers) con redes T3 existentes velocidades UNI adicionales se han venido evaluando y estaacuten ofrecieacutendose Tambieacuten hay un alto intereacutes en interfases para velocidades EI (2Mbps) y T1 (1544 Mbps) para accesos ATM de baja velocidad

PROTOCOLO ATM

El protocolo ATM consiste de tres niveles o capas baacutesicas (Ver figura No 3) La primera capa llamada capa fiacutesica (Physical Layer) define los interfases fiacutesicos con los medios de transmisioacuten y el protocolo de trama para la red ATM es responsable de la correcta transmisioacuten y recepcioacuten de los bits en el medio fiacutesico apropiado A diferencia de muchas tecnologiacuteas LAN como Ethernet que especifica ciertos medios de transmisioacuten (10 base T 10 base 5 etc) ATM es independiente del transporte fiacutesico Las celdas ATM pueden ser transportadas en redes SONET (Synchronous Optical Network) SDH (Synchronous Digital Hierarchy) T3E3 TIEI o auacuten en modems de 9600 bps Hay dos subcapas en la capa fiacutesica que separan el medio fiacutesico de transmisioacuten y la extraccioacuten de los datos

La subcapa PMD (Physical Medium Depedent) tiene que ver con los detalles que se especifican para velocidades de transmisioacuten tipos de conectores fiacutesicos extraccioacuten 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 extraccioacuten de informacioacuten contenida desde la misma capa fiacutesica Esto incluye la generacioacuten y el chequeo del Header Error Correccioacuten (HEC) extrayendo celdas desde el flujo de bits de entrada y el procesamiento de celdas idles y el reconocimiento del liacutemite de la celda Otra funcioacuten importante es intercambiar informacioacuten de operacioacuten y mantenimiento (OAM) con el plano de administracioacuten (Ver figura No4) La segunda capa es la capa ATM Ello define la estructura de la celda y coacutemo las celdas fluyen sobre las conexiones loacutegicas 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 informacioacuten

Las celdas son transmitidas serialmente y se propagan en estricta secuencia numeacuterica a traveacutes de la red El tamantildeo 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 viacutedeo y protocolos sensibles al retardo A pesar de que no se disentildeoacute especiacuteficamente para eso la longitud de la celda ATM acomoda convenientemente dos Fast Packets IPX de 24 bytes cada uno Los comiteacutes de estaacutendares 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 aacuterea 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 puacuteblico (carrier) Especiacuteficamente la funcioacuten 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 conmutacioacuten de las celdas ATM

La capa de adaptacioacuten de ATM

La tercer capa es la ATM Adaptation Layer (AAL) La AAL juega un rol clave en el manejo de muacuteltiples tipos de traacutefico 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 maacutes altas tales como emulacioacuten de circuitos (circuit emulation) viacutedeo 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 estaacuten definidos actualmente La capa de Adaptacioacuten de ATM yace entre el ATM layer y las capas maacutes altas que usan el servicio ATM Su propoacutesito principal es resolver cualquier disparidad entre un servicio requerido por el usuario y atender los servicios disponibles del ATM layer La capa de adaptacioacuten introduce la informacioacuten en paquetes ATM y controla los errores de la transmisioacuten La informacioacuten transportada por la capa de adaptacioacuten se divide en cuatro clases seguacuten las propiedades siguientes

1 Que la informacioacuten que esta siendo transportada dependa o no del tiempo 2 Tasa de bit constantevariable 3 Modo de conexioacuten

Estas propiedades definen ocho clases posibles cuatro se definen como B-ISDN Clases de servicios La capa de adaptacioacuten 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 adaptacioacuten 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 informacioacuten en la cabecera y en el payload depende de la clase de informacioacuten que va a ser transportada

2)Capa de Segmentacioacuten 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 informacioacuten necesaria para el reensamblaje en el destino La figura siguiente aporta una mejor comprensioacuten 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 tamantildeo de la celda ATM para su transmisioacuten Tambieacuten realiza la funcioacuten inversa (reemsamblado) para las unidades de informacioacuten de orden superior Cada porcioacuten es ubicada en su propia unidad de protocolo de segmentacioacuten 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 informacioacuten que regule el tiempo con los datos AAL-1 provee recuperacioacuten de errores e indica la informacioacuten con errores que no podraacute ser recuperada

Capa de convergencia

Las funciones provistas a esta capa difieren dependiendo del servicio que se proveyoacute Provee la correccioacuten de errores

Capa de segmentacioacuten y reensamblaje

En esta capa los datos son segmentados y se les antildeade una cabecera La cabecera contiene 3 campos (ver diagrama)

Nuacutemero de secuencia usado para detectar una insercioacuten o perdida de un paquete Nuacutemero de secuencia para la proteccioacuten usado para corregir errores que ocurren en el

numero de secuencia Indicador de capa de convergencia usado para indicar la presencia de la funcioacuten de la capa

de convergencia

ALL 2

AAL-2 se usa para transferir datos con tasa de bits variable que dependen del tiempo Enviacutea la informacioacuten del tiempo conjuntamente con los datos para que esta puede recuperarse en el destino AAL-2 provee recuperacioacuten de errores e indica la informacioacuten que no puede recuperarse

Capa de convergencia

Esta capa provee para la correccioacuten de errores y transporta la informacioacuten del tiempo desde el origen al destino

Capa de segmentacioacuten y recuperacioacuten

El mensaje es segmentado y se le antildeade 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 informacioacuten es

o BOM comenzando de mensaje o COM continuacioacuten de mensaje o EOM fin de mensaje o indica que el paquete contiene informacioacuten de tiempo u

otra

El payload tambieacuten 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 disentildea para transferir los datos con tasa de bits variable que son independientes del tiempo AAL-3 puede ser dividido en dos modos de operacioacuten

1 Fiable En caso de perdida o mala recepcioacuten de datos estos vuelven a ser enviados El control de flujo es soportado

2 No fiable La recuperacioacuten 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 comuacuten de la capa de convergencia Esto es provisto tambieacuten por el AAL-2 CS Antildeade una cabecera y un payload a la parte comuacuten (ver diagrama)

La cabecera contiene 3 campos Indicador de la parte comuacuten que dice que el payload forma parte de la parte comuacuten Etiqueta de comienzo que indica el comienzo de la parte comuacuten de la capa de

convergencia Tamantildeo del buffer que dice al receptor el espacio necesario para acomodar el mensaje

El payload tambieacuten contiene 3 campos Alineacioacuten 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 comuacuten de la CS(capa de convergencia) El campo de longitud tiene la longitud de la parte comuacuten de la CS

1 Parte especifica del servicio Las funciones proveiacutedas en esta que capa dependen de los servicios pedidos Generalmente se incluyen funciones para la recuperacioacuten y deteccioacuten de errores y puede incluir tambieacuten funciones especiales

Capa de segmentacioacuten y reensamblaje

En esta capa los datos son partidos en paquetes de ATM Una cabecera y el payload que contiene la informacioacuten necesaria para la recuperacioacuten de errores y reensamblaje se antildeaden 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 Continuacioacuten de mensaje EOM Fin de mensaje SSM Mensaje uacutenico en el segmento

2) Numero de secuencia usado para detectar una insercioacuten o una perdida de un paquete 3) Identificador de multiplexacioacuten Este campo se usa para distinguir datos de diferentes comunicaciones que ha sido multiplexadas en una uacutenica conexioacuten de ATM El payload contiene dos de campos 1) Indicado de longitud que indica el nuacutemero de bytes uacutetiles en un paquete parcialmente lleno 2) CRC es para el control de errores

ALL 4

AAL-4 se disentildea para transportar datos con tasa de bits variable independientes del tiempo Es similar al AAL3 y tambieacuten puede operar en transmisioacuten fiable y o fiable AAL-4 provee la capacidad de transferir datos fuera de una conexioacuten expliacutecita

AAL 2 AAL 34 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 traacutefico de redes de aacuterea local (LAN) AAL 2 y AAL 3 soportan paquetes orientados a conexioacuten (Ver figura No5)

(El teacutermino orientado a conexioacuten describe la transferencia de datos despueacutes 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 jamaacutes vean estos errores reportados la degradacioacuten de respuesta o de caudal (through put) seriacutean los uacutenicos siacutentomas A diferencia de los mecanismos de control extremo a extremo que utiliza TCP en internerworking la capacidad de Gbitseg de la red ATM genera un juego de requerimientos necesarios para el control de flujo Si el control del flujo se hiciese como una realimentacioacuten del lazo extremo a extremo en el momento en que el mensaje de control de flujo arribase a la fuente eacutesta habriacutea transmitido ya algunos Mbytes de datos en el sistema exacerbando la congestioacuten Y en el momento en que la fuente reaccionase al mensaje de control la condicioacuten de congestioacuten hubiese podido desaparecer apagando innecesariamente la fuente La constante de tiempo de la realimentacioacuten extremo a extremo en las redes ATM (retardo de realimentacioacuten por producto lazo - ancho de banda) debe ser lo suficientemente alta como para cumplir con las necesidades del usuario sin que la dinaacutemica de la red se vuelva impractica Las condiciones de congestioacuten en las redes ATM estaacuten previstas para que sean extremadamente dinaacutemicas requiriendo de mecanismos de hardware lo suficientemente raacutepidos para llevar a la red al estado estacionario necesitando que la red en siacute eacuteste activamente involucrada en el raacutepido establecimiento de este estado estacionario Sin embargo esta aproximacioacuten simplista de control reactivo de lazo cerrado extremo a extremo en condiciones de congestioacuten no se considera suficiente para las redes ATM El consenso entre los investigadores de este campo arroja recomendaciones que incluyen el empleo de una coleccioacuten de esquemas de control de flujo junto con la colocacioacuten adecuada de los recursos y dimensionamiento de las redes para que aunados se pueda tratar y evadir la congestioacuten ya sea

Detectando y manipulando la congestioacuten que se genera tempranamente monitoreando de cerca las entradassalidas que estaacuten dentro de los conmutadores ATM y reaccionando gradualmente a medida que vaya arribando a ciertos niveles prefijados Tratando y controlando la inyeccioacuten de la conexioacuten de datos dentro de la red en la UNI (unidad interfaz de red) de tal forma que su tasa de inyeccioacuten sea modulada y medida alliacute primero antes de tener que ir a la conexioacuten de usuario a tomar acciones mas draacutesticas El estado de la red debe ser comunicado a la UNI generando raacutepidamente una celda de control de flujo siempre que se vaya a descartar una celda en alguacuten nodo debido a congestioacuten La UNI debe entonces manejar la congestioacuten cambiando su tasa de inyeccioacuten

o notificaacutendola a la conexioacuten de usuario para que cese el flujo dependiendo del nivel de severidad de la congestioacutenEl mayor compromiso durante el control de congestioacuten es el de tratar y afectar solo a los flujos de conexioacuten que son responsables de la congestioacuten y actuar de forma transparente frente a los flujos que observan buen comportamiento Al mismo tiempo permitir que el flujo de conexioacuten utilice tanto ancho de banda como necesite sino hay congestioacuten La recomendacioacuten UIT - T I 371 especifica un contrato de traacutefico que define como el traacutefico del usuario seria administrado El contrato que existe para cada conexion virtual (virtual path o virtual channel) es baacutesicamente un acuerdo entre el usuario y la red con respecto a la Calidad de Servicio (Quality Of Service - Q o S) y los paraacutemetros que regulan el flujo de celdas Estos descriptores de trafico dependen de una particular clase de servicio y pueden incluir bajo la especificacioacuten del ATM Forum UNI a cinco Q o S referenciados en los AALS El objetivo de estas sub clases de servicio es agrupar caracteriacutesticas 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 paraacutemetros pueden incluir el Sustained Cell Rate (SCR) el Miacutenimum Cell Rate (MCR) el Peak Cell Rate (PCR) yo el Burst Tolerance (BT) Para soportar todas las diferentes clases de servicios definidos por los estaacutendares el switch ATM debe ser capaz de definir eacutestos paraacutemetros en base a cada VC o cada VP y debe proveer amortiguadores (buffers) para absorber las raacutefagas de trafico

INTEROPERABILIDAD ENTRE FRAME RELAY Y ATM El objetivo final para todos los servicios descritos anteriormente es una migracioacuten suave de Frame Relay yo SMDS a redes ATM Por ejemplo la recomendacioacuten UIT - T I555 provee un marco para la interoperabilidad de Frame Relay y ATM Para alcanzar una maacutexima eficiencia se trata de brindar este servicio de interoperabilidad en la capa maacutes baja posible mediante conversioacuten de protocolo

PRIMER ESCENARIO

Cuando el servicio de Frame Relay es dado sobre la RDSI en banda ancha y los usuarios se conectan a traveacutes de la UNI de Frame Relay En esta solucioacuten 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 (VCVP) para enlazar los puntos de acceso Frame Relay En este esquema se puede explotar la naturaleza de orientacioacuten a conexioacuten Frame Relay (F R) siguiendo un comportamiento como

El usuario del enrutador pregunta por una conexioacuten al equipo interfaz de red El equipo interfaz de la red coloca las conexiones Frame Relay dentro de una conexioacuten ATM con las direcciones destino apropiadas Por cada trama de equipo interfaz de red traslada de la conexioacuten de Frame Relay a la ATM y viceversa La conexioacuten ATM esta desocupada cuando no se necesitaPara lograr este uacuteltimo punto el manejo de la poliacutetica de conexion del VC sera un aspecto crucial para el desempentildeo de este procedimiento Resulta difiacutecil de terminar el procedimiento para manejar un VC cuando la fuente de traacutefico es no orientada a conexioacuten 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 conexioacuten 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 opcioacuten se toma ventaja del uso actual del FR el cual es proveer un mallado virtual entre diferentes sitios para cargar traacutefico no orientado a conexioacuten 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 conmutacioacuten 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 traveacutes de sus respectivas interfaces de red (NNIs) Esto permitiriacutea a un proveedor de red manejar esta heterogeacutenea red como un todo Frame Relay provee usualmente la interconexioacuten para LAN a pesar de su natural orientacioacuten a conexioacuten 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 sobresimplificacioacuten los dos protocolos (AAL 3 y AAL 5) ofrecen basicamente el mismo servicio CPAAL (Parte Comuacuten 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 implementacioacuten y eficiencia del protocolo que incide en el costo Las caracteriacutesticas a tomar en cuenta cuyo detalle puede ser tema de otro artiacuteculo tienen que ver con Delimitacioacuten y Alineamiento de Tramas Multiplexacioacuten Deteccioacuten de errores de transmisioacuten eficiencia en la transmisioacuten 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 tecnologiacutea de red empresarial virtual del futuro un teacutermino que refleja tanto la evolucioacuten del modelo empresarial global y el eacutenfasis en la conectividad loacutegica donde los usuarios obtienen acceso a los recursos que necesitan y el operador de la red provee las rutas de conexioacuten y asigna el ancho de banda necesario a fuentes de traacutefico muy diferentes (voz datos viacutedeo) Aquellos que construyen y operan redes deben volver los ojos a las capacidades de la tecnologiacutea ATM ya que aspiran a la maacutegica combinacioacuten interconectividad global - escalabilidad de tecnologiacuteas y satisfaccioacuten del cliente local

BIBLIOGRAFIA

1 CCITT Rec I362 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 vol2 No8 ATM Testing crosses network boundaries Jim Frimmel

6 Newslink Alcatel Telecomrsquos customer magazine Vol IV No4 4th Quarter 1996 Adapting Networks to the Internet Challenge Krish Prabhu

Trabajo realizado por

Ivan Dario Cruz PradaNicruz[arroba]col1telecomcomco

Revisioacuten y Clasificacioacuten de Protocolos para Redes de Tecnologiacutea ATM

Joseacute Luis Gonzaacutelez-Saacutenchez y Jordi Domingo-Pascual

ResumenLa tecnologiacutea 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 investigacioacuten maacutes activo con la aspiracioacuten 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 asiacute como las caracteriacutesticas multicast la escalabilidad y la fiabilidad Se profundiza en el concepto de protocolo nativo ATM y son introducidos los protocolos maacutes importantes que satisfacen este importante requerimiento (N3 CONGRESS y kStack entre otros) Es importante destacar tambieacuten los protocolos de transporte pensados especiacuteficamente para la tecnologiacutea ATM La caracteriacutestica multicast (multipoint-to-multipoint) es una de las que maacutes esfuerzo estaacute costando garantizar a ATM pero existen ya propuestas que permiten la comunicacioacuten fiable a elevados anchos de banda y entre muacuteltiples emisores y receptores (SMART MCMP o MWAX) El artiacuteculo concluye con las investigacioness maacutes novedosas en torno a los protocolos ATM como las iniciativas que proponen redes ATM programables o activas (active networks) usando agentes moacuteviles

1-Introduccioacuten y motivacionesLa actual demanda de aplicaciones relacionadas con informacioacuten multimedia como son la video-conferencia audio-conferencia video bajo demanda (VoD) o sistemas colaborativos (pizarras compartidas teletrabajo telemedicina etc) y su coexistencia con aplicaciones maacutes claacutesicas (bases de datos transferencias de ficheros WWW etc) requiere tecnologiacuteas de comunicaciones capaces de ofrecer elevadas prestaciones Estas elevadas prestaciones estaacuten directamente relacionadas con la calidad de servicio (QoS) y concretamente con conceptos claramente parametrizables como el ancho de banda y la velocidad de transmisioacuten (throughput) el retardo de las transferencias (delay) la variabilidad en el retardo (jitter) la fiabilidad (reliability) de las transmisiones las caracteriacutesticas de multidifusioacuten a grupos dispersos de usuarios (multicast) y la posibilidad de gestionar muacuteltiples clases de servicio o flujos de informacioacuten en redes multiclass Para que las nuevas tecnologiacuteas en comunicaciones puedan ofrecer estas caracteriacutesticas es necesario revisar potenciar y ampliar las actuales arquitecturas servicios y protocolosde comunicaciones En los uacuteltimos dos o tres antildeos las investigaciones en el campo de ATM estaacuten dado lugar a importantes propuestas cuyo principal objetivo es ofrecer a las aplicaciones demandadas actualmente algunas o todas las caracteriacutesticas citadas anteriormente Presentamos en este trabajo los conceptos y propuestas maacutes novedosas en el contexto de ATM para ayudar al lector interesado en el dinaacutemico complejo y sofisticado campo de los protocolos de comunicaciones Realizamos la revisioacuten de algunos de los maacutes importantes conceptos teacutecnicas ideas y mecanismos en protocolos de altas prestaciones para redes de tecnologiacutea ATM El principal objetivo de este documento es ofrecer una actualizada visioacuten general no extensiva ni profunda de los protocolos propuestos y en desarrollo para dotar a las diversas clases de servicio ATM de las citadas caracteriacutesticas de calidad de servicio que aporten las potenciales elevadas prestaciones que la tecnologiacutea ATM es capaz de ofrecer El resto del documento estaacute estructurado de la siguiente forma La seccioacuten 2 revisa el concepto de protocolo nativo centrado en el contexto de las redes ATM La seccioacuten 3 describe las propuestas maacutes interesantes actualmente en materia de protocolos de transporte El apartado 4 comenta las transferencias multicast como un importante objetivo para una tecnologiacutea orientada a la conexioacuten como es ATM Concluimos en la seccioacuten 5 con los campos de investigacioacuten abiertos recientemente como son las redes activas y los procolos booster

2- Protocolos nativos ATM

Las aplicaciones nativas ATM estaacuten especiacuteficamente pensadas para usar la tecnologiacutea ATM y para explotar al maacuteximo sus especiales caracteriacutesticas Los protocolos nativos se encargan por tanto de ofrecer esas caracteriacutesticas intriacutensecas de las redes de tecnologiacutea ATM (soporte de QoS sentildealizacioacuten direccionamiento etc) a las aplicaciones nativas ATM (VoD pizarras compartidas video-conferencia) No obstante existen tambieacuten activas investigaciones para conseguir soportar sobre redes ATM aplicaciones no nativas ATM desarrolladas para otras tecnologiacuteas (IP Frame Relay SMDS) En [1] el termino native ATM services define servicios ATM especiacuteficos 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 adaptacioacuten (AALs) Disponibilidad de circuitos virtuales conmutados (SVCs) y circuitos virtuales permanentes (PVCs) Consideraciones relativas a la gestioacuten de traacutefico (clases de servicio garantiacuteas de QoS etc) Posibilidad de distribucioacuten de conexiones y de participacioacuten local en la administracioacuten de la red (protocolos ILMI y OAM)

El propoacutesito de los servicios nativos ATM es ofrecer el acceso a las clases de servicio o a las caracteriacutesticas de QoS en redes ATM Estos servicios nativos tambieacuten ofrecen soporte a un amplio y heterogeacuteneo rango de flujos con diversas propiedades y requerimientos recomendados en [1] Los protocolos de transferencia nativos ATM gestionan la sentildealizacioacuten UNI para establecer los SVCs configurar PVCs y mapear los perfiles de QoS en la correspondiente clase de servicio Los protocolos nativos tambieacuten realizan funciones claacutesicas como las de transporte mecanismos de control de errores transferencia de datos y controles de flujo y de congestioacuten En la referencia [1] se especifica la definicioacuten semaacutentica de los servicios y consideramos que es uacutetil contrastar esta semaacutentica con las redes ATM actuales que usan TCP como capa de transporte e IP-over-ATM como capa de red planteamiento por otro lado poco adecuado [2] por las siguientes razones

Las redes IP no garantizan la QoS extremo-extremo ofrecida por las redes ATM a circuitos individuales IP multiplexa muacuteltiples conexiones de transporte con distintos requerimientos de QoS en VCs simples TCP no soporta ceacutelulas RM (Resource Management) ABR y por consiguiente no puede usar directamente las garantiacuteas de QoS ofrecidas por la red ATM Adaptation Layer 5 (AAL5) realiza labores de checksum para detectar corrupcioacuten de datos TCP tambieacuten realiza estas labores (redundantes con AAL5) costosas en overhead (cada byte de un paquete debe ser chequeado) TCPIP son la representacioacuten de un grupo de protocolos bastante maacutes 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] Ademaacutes 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 tecnologiacutea ATM y tambieacuten existen antiguas y no nativas aplicaciones Este escenario implica cambiar las aplicaciones o proponer nuevas pilas de protocolos nativos ATM La encapsulacioacuten consecutiva de paquetes genera problemas de overhead y funciones redundantes como se ha argumentado anteriormente La limitacioacuten de recursos en los sistemas finales es otra importante motivacioacuten 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 puacuteblicos disfrutan tambieacuten de estas ventajas ATM RDSI y la telefoniacutea ofrecen un esquema de direccionamiento universal basado en NSAPE164 el cual es capaz de enrutar traacutefico de forma nativa Por tanto aunque ATM dispone de protocolos nativos con direccionamiento intriacutenceso estructurado y jeraacuterquico eacuteste no es aprovechado por las aplicaciones que estaacuten 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 tambieacuten existen importantes investigaciones en torno a los protocolos nativos ATM En esta seccioacuten se muestran las propuestas maacutes importantes y actuales en materia de protocolos nativos ATM[2] [7] [8] [9] [10] [11] [12] que a su vezestaacuten sirviendo de base para nuevas investigaciones

[8] presentan el disentildeo implementacioacuten y comportamiento de una pila en modo nativo ATM y contrasta la semaacutentica 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 automaacuteticamente los siguientes problemas

IP-over-ATM no ofrece garantiacutea de QoS pues sus aplicaciones soacutelo ven la interfaz IP El nuacutecleo 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 sentildealizacioacuten 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 caracteriacutesticas la entrega fiable y no fiable de datos con control de flujo Este protocolo de transporte es ampliado en la seccioacuten 5 [2] presenta N3 (Native Non-broadcasting medium access Networking) un protocolo de transporte ligero y nativo ATM La pila N3 se ha disentildeado 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 ademaacutes aporta otras importantes novedades Los principales componentes de N3 incluyen una API sockets ATM nativa un protocolo de transporte ATM y un servicio de nombres ATM (Fig2) El protocolo de transporte ATM propuesto en [2] ofrece soporte para tres diferentes tipos de servicio entrega garantizada (mecanismos de retransmisioacuten) 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 congestioacuten de la transferencia de datagramas y de la multiplexacioacuten 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 maacutes importante El Flow Management se responsabiliza de manipular los flujos de datos desde y hasta la red viacutea la interfaz AAL La segmentacioacuten el reensamblado y el control de errores es tambieacuten 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 congestioacuten y de flujo extremo-extremo maacutes complejo

[7] describe la semaacutentica de una pila de protocolos y explora una nueva arquitectura de protocolo adaptada a la tecnologiacutea ATM y a las aplicaciones multimedia El disentildeo estaacute basado en tres principios baacutesicos separacioacuten de flujos de control y de datos minimizacioacuten del overhead y de la duplicidad de funciones y acceso de las aplicaciones al nivel ATM con garantiacuteas 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-over-ATM 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 moacutedulo CNTL abre una conexioacuten de sentildealizacioacuten con el dispositivo ATM y establece una gestioacuten de las llamadas de mensajes de configuracioacuten PF_ATM separa flujos de datos y de control para aliviar el liacutemite de comportamiento en las comunicaciones Esto permite a los mecanismos de control de traacutefico ser raacutepidos y sencillos mientras los mecanismos de control pueden ser tan complicados como sea necesario Esta separacioacuten permite tambieacuten que los dispositivos puedan estar en los puntos finales de una conexioacuten La interfaz PF_ATM da a las aplicaciones acceso directo a la capa de enlace ATM y extiende las garantiacuteas de QoS a los puntos extremos de la comunicacioacuten Un segundo prototipo[7] es disentildeado e implementado con dos objetivos principales en la optimizacioacuten de la pila nativa ATM

Optimizar los caminos de datos entre los adaptadores ATM aprovechando la separacioacuten de flujos de control y de datos y la capacidad de gestioacuten de datos especiacuteficos de las conexiones de la pila ATM

Optimizar el procesamiento de overheads usando una pila de protocolos nativo ATM en lugar de UDPIP

[11] introduce CONGRESS (CONnection oriented Group-address RESolution Service) otro eficiente protocolo nativo ATM para la resolucioacuten y gestioacuten 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 disentildeo basado en los dos siguientes principios

Disentildeo jeraacuterquico los servicios del protocolo son ofrecidos a las aplicaciones por muacuteltiples servidores organizados jeraacuterquicamente No inundacioacuten se evita la inundacioacuten 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 implementacioacuten sobre Unix y Windows NT estaacute 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 antildeadido un moacutedulo que monitoria la QoS extremo-a-extremo

3- Protocolos de transporte para redes ATMEn los dos o tres uacuteltimos antildeos ha habido numerosos e interesante intentos por disentildear protocolos de transporte La referencia [10] presenta un completo y ya claacutesico resumen de las propuestas maacutes interesantes en materia de protocolos de transporte para redes de alta velocidad (mayoritariamente IP en el artiacuteculo) Ademaacutes la referencia [13] ofrece una interesante visioacuten de las caracteriacutesticas maacutes importantes en los protocolos de elevada velocidad Son estudiadas tambieacuten diversas arquitecturas de protocolos y varias teacutecnicas de implementacioacuten Los protocolos de transporte de elevada velocidad son fuente de activas investigaciones y estaacuten en constante evolucioacuten desde hace maacutes de dos deacutecadas 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 aacutembito de las comunicaciones que ha recibido mayor atencioacuten es la capa de transporte la cuarta capa del OSI-RM de los protocolos de comunicaciones TCP e ISO TP4 son los dos maacutes populares protocolos de transporte Pero centraacutendonos maacutes concretamente en el aacutembito de ATM la literatura presenta varios protocolos de transporte y arquitecturas para redes de alta velocidad revisadas resumidamente a continuacioacuten [7] ofrece una excelente y didaacutectica arquitectura de pila de protocolos para aplicaciones multimedia en modo nativo ATM Esta arquitectura de protocolo ha sido ya descrita brevemente en la seccioacuten anterior [8] presentan el disentildeo implementacioacuten 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 estaacute formada por tres entidades principales aplicacioacuten sentildealizacioacuten y transporte La siguiente Tabla 1 muestra un conjunto de nueve baacutesicos 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 combinacioacuten de servicios La marca X indica el servicio baacutesico soportado en cada clase de servicio general

Clases de servicio

Servicios Servicio de comportamiento

garantizado

Servicio fiable Servicio Best effort

- Transferencia Simplex de datos

X X X

- Control de errores - deteccion de errorestimeouts retransmisiones

No existente (ofrecido por

AAL5)

- Bucle abierto - Control de flujo realimentado

No existente -

- X

- No existente

- Tamantildeo de mensaje ilimitado

X X X

- Eleccioacuten de blocking - Aplicacioacuten Non-blocking

X X

X X

X X

- Eleccioacuten de byte stream - Semaacutentica transferencia de mensajes

X X

X X

X X

- Garantiacuteas de QoS requerimientos de ancho de banda

No soportado No soportado

- Reserva de recursos X No existente No existente

- Transferencias Multicast X No soportado Para servicios no fiables

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 recuperacioacuten de peacuterdidas del protocolo estaacutendar SSCOP [14] y demuestran que el resultado ofrece baja latencia eficiente recuperacioacuten de ceacutelulas perdidas y es tan robusto como el estaacutendar SSCOP

4- Protocolos multipointEl crecimiento de las redes ATM viene motivado en parte por la demanda de servicios multimedia para grupos dispersos de usuarios El traacutefico multicast tiene caracteriacutesticas particulares descritas para ATM en UNI 40 [6] y anteriores [5] La distribucioacuten de informacioacuten punto-a-multipunto (uno-a-muchos) o multipunto-a-multipunto (muchos-a-muchos) es un objetivo baacutesico propuesto por varios protocolos y arquitecturas ATM que ofrecen el soporte multimedia yo multicast como audio-conferencia video-conferencia trabajos colaborativos o VoD ATM es auacuten una tecnologiacutea emergente disentildeada 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 30) para ATM define conexiones punto-a-multipunto y las conexiones multipunto-a-multipunto soacutelo 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 topologiacutea completamente mallada todos-con-todos Aunque esta topologiacutea ofrece conexiones multipunto-a-multipunto hay que destacar que no escala bien cuando el nuacutemero de participantes es elevado Una alternativa al anterior esquema es el uso de un servidor que actuacutea a modo de raiacutez en el aacuterbol multipunto Este meacutetodo soacutelo requiere un nodo raiacutez para almacenar informacioacuten pero la desventaja de este meacutetodo son las potenciales congestiones en el servidor

cuando debe encargarse de enviacuteos y retransmisiones de las conexiones multipunto-a-multipunto

Para solventar las limitaciones de UNI 30 y UNI 31 [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 sentildealizacioacuten ATM (UNI 31 UNI 40) [4][5][6] Comenzamos destacando la referencia [16] como un reciente trabajo que revisa y compara los protocolos de transporte multicast maacutes importantes en Internet como MTP-2 XTP RTP SRM RAMP RMTP MFTP STORM etc IETF e IRTF (como ITU-T y ATM Forum) tambieacuten impulsan una importante actividad en este campo La referencia [16] revisa los maacutes representativos protocolos multicast y los clasifica de acuerdo a la taxonomiacutea de varias caracteriacutesticas (propagacioacuten de datos mecanismos de fiabilidad retransmisiones control de congestioacuten y de flujo gestioacuten de grupos multicast etc) En Internet los mecanismos efectivos de control de congestioacuten son una de las prioridades en las investigaciones de las transferencias multicast fiables Los mecanismos de seguridad y las teacutecnicas escalables de recuperacioacuten 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 maacutes importantes caracteriacutesticas En esta seccioacuten 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 maacutes interesantes en los siguientes paacuterrafos SMART (shared many-to-many ATM reservations)[3] es un protocolo para controlar un aacuterbol ATM multicast compartido soportando comunicaciones muchos-a-muchos (many-to-many) Esta propuesta tiene importantes caracteriacutesticas como que reside completamente en la capa ATM y no requiere ninguacuten servidor soporta uno o varios VCCs (y tambieacuten VPCs) cuyo nuacutemero es libremente configurado y es independiente del nuacutemero de puntos finales usa el concepto de bloques de datos como en la clase de servicio ABT y tambieacuten permite VCCs de las clases CBR VBR o UBR el protocolo garantiza que no existen puntos de interrelacioacuten en los VCC del aacuterbol son respetadas las garantiacuteas del contrato de traacutefico asociado con los VCCs etc SMART puede ser entendido como un protocolo completamente distribuido para coordinar la distribucioacuten de VPIsVCIs 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 ceacutelulas de datos desde diferentes fuentes pueden llegar intercaladas a un destinatario) y tambieacuten Demand Sharing (los recursos asignados a conexiones muchos-a-muchos son dinaacutemicamente compartidas entre todas las potenciales fuentes El artiacuteculo [3] describe el protocolo SMART formal e informalmente y propone completas pruebas de correccioacuten y un detallado anaacutelisis de comportamiento para estudios futuros Tambieacuten son sugeridas otras investigaciones como son ofrecer justicia en los accesos a los aacuterboles multicast investigar las ceacutelulas RM perioacutedicamente para aliviar las congestiones en la red o disminuir el tiempo de acceso del usuario a los aacuterboles de distribucioacuten multicast anaacutelisis de las ceacutelulas RM dentro de cada VCC o fuera enviando todas las ceacutelulas RM en un VCC dedicado En [17] se presenta MWAX un algoritmo dinaacutemico 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 artiacuteculo describe un esquema jeraacuterquico basado en CBT para incorporar routing multipunto-a-multipunto en PNNI En el algoritmo los nodos core actuacutean como participantes pasivos para eliminar la dependencia en la seleccioacuten de estos nodos Con un mecanismo de backup se consigue un algoritmo tolerante a fallos en los nodos core lo cual puede ser faacutecilmente 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 jerarquiacutea SEAM (Scalable and Efficient ATM Multicast) [18] propone una arquitectura escalable eficiente y multicast multipunto-a-multipunto para redes ATM que usa un soacutelo VC para un grupo multicast de muacuteltiples 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 Tambieacuten realiza aportaciones para conseguir soportar IP multicast sobre redes ATM extensas

SEAM usa un soacutelo aacuterbol de distribucioacuten 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 sentildealizacioacuten del grupo Este trabajo deja abiertas investigaciones referentes a la gestioacuten de traacutefico y a la entrega fiable de traacuteficos multicasting Concluimos esta seccioacuten destacando MCMP (Multiparty Conference Management Protocol) [19] que sin estar pensado especiacuteficamente para ATM es un protocolo de nivel sesioacutentransporte distribuido extremo-extremo y desarrollado para gestioacuten de grupos de aplicaciones de conferencia MCMP es un conjunto de algoritmos de control distribuido para configuracioacuten de conferencias multipunto y gestioacuten de miembros de grupos de usuarios Conceptualmente MCMP reside en el nivel de sesioacuten en el que se establece la infraestructura para activar la transferencia de informacioacuten entre los participantes en la conferencia Pero funcionalmente el protocolo acompasa los niveles de sesioacuten y de transporte pues utiliza directamente servicios del nivel de red Son destacables las condiciones de correccioacuten (conectividad validacioacuten unicidad consistencia y terminacioacuten) que deben ser satisfechas una vez que la conferencia ha sido configurada por el algoritmo de configuracioacuten de MCMP El artiacuteculo muestra exhaustivas pruebas de correccioacuten para uno de los algoritmos y tambieacuten describe la especificacioacuten y verificacioacuten del protocolo

5- Nuevos campos de investigacioacutenEn todas las redes existen gran variedad de elementos hardware (switchs routers bridges brouters hubs ETDs etc) que realizan muy diversas funciones (conmutacioacuten routing puenteo controles de congestioacuten y de flujo garantiacutea de QoS ejecucioacuten de aplicaciones etc) En la actualidad la red es mayormente un canal de comunicacioacuten para transferir paquetes entre equipos finales (ayudada por los elementos hardware antes citados) Pero tambieacuten se estaacuten realizando importante esfuerzos para equipar a los elementos hardware con elevadas prestaciones aportadas por diversas teacutecnicas software Esto dota a la red de caracteriacutesticas activas (active networks) en el sentido de que los elementos hardware que la componen computan modifican u operan los contenidos de los paquetes y tambieacuten seraacuten capaces de transferir o propagar coacutedigo Por consiguiente una red activa es una red programable [20] es una excelente revisioacuten de este novedoso campo de investigacioacuten que discute dos planteamientos en la realizacioacuten de redes activas la idea del conmutador programable y la de la caacutepsula Una red es activa si en sus aacuterboles de distribucioacuten multicast existen nodos activos con capacidad para ejecutar programas yo capaces de implementar mecanismos de propagacioacuten de coacutedigo Algunas de las ventajas de los protocolos activos son conseguidas instalando nodos activos en puntos estrateacutegicos de la red Otro nuevo concepto es presentado en [21] como una metodologiacutea para el disentildeo de protocolos Los protocol boosters son una nueva contribucioacuten a las redes activas o programables Una ventaja de los boosters es que pueden ser faacutecilmente 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 aacuterea extensa Este papel introduce una arquitectura software orientada a agente y propone el concepto de agente de comunicacioacuten para servicio de comunicacioacuten 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 artiacuteculo muestra agentes software moacuteviles usados para implementar operaciones robustas y funciones de mantenimiento en redes ATM Los agentes desempentildean un rol similar al de las ceacutelulas OAM en ATM estaacutendar pues son transmitidos entre entidades de control a intervalos regulares usando recursos predefinidos La diferencia entre los agentes moacuteviles y las ceacutelulas OAM reside en que eacutestos pueden contener coacutedigo Para concluir destacar que la integracioacuten del traacutefico IP sobre tecnologiacutea ATM es tambieacuten uno de los campos maacutes activos en la actualidad En esta liacutenea pueden destacarse los siguientes protocolos IP-over-ATM IP Switching Tag Switching NHRP MPOA IMSS CSR ARIS AREQUIPARED y EPD Referencias

1 ____ Native ATM Service Semantic Description Version 1 ATM Forum Technical Committee ATM Forum Document af-saa-0048000 (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 Broadband Networks Multimedia Applications Services and Techniques ECMASTrsquo98 Springer (May 1998)

3 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 Nordm 3 (April 1997)

4 W D Zhong K Yukimatsu Design requeriments and architectures for multicast ATM switching IEICE Trans Com Vol E77-B pp 1420-1428 (Nov 1994)

5 ____ ATM user-network interface version 31 specification ATM Forum (1994)

6 ____ Traffic Management Specification Version 40 ATM Forum Technical Committee ATM Forum Document af-tm-0056000 (April 1996)

7 D Kandlur D Saha and W Willebeck Protocol Architecture for multimedia Application over ATM Networks IEEE Journal Selected and Communications Vol 14 Nordm 7 pp 1349-1359 (Sep 1996)

8 R Ahuja S Keshav and H Saran Design Implementation and Performance Measurement of a Native-Mode ATM Transport Layer (Estended Version) IEEEACM Transactions on Networking Vol 4 Nordm 4 (Aug 1996)

9 R Karabek A Native ATM Protocol Architecture Design and Performance Evaluation IEEE Proceedings 22nd Annual Conference on Local Computer Networks pp 204-210 (1997)

10 D C Feldmeier A framework of architectural concepts for high-speed communications systems IEEE J Select Areas CommunVol11 Nordm 4 (May 1993)

11 T Anker D Breitgand D Dolev Z Levy Congress CONnection-oriented Group-address RESolution Service Proceeding of SPIE97 vol 3233 on Broadband Networking Technologies Nov (1997)

12 kStack httpcometcolumbiaedusoftwarekStack

13 T La Porta and M Schwartz Architectures Features and Implementation of High-Speed Transport Protocols IEEE Network Magazine pp 14-22 (May 1991)

14 ____ B-ISDN ATM Adaptation Layer Service Specific Connection Oriented Protocol (SSCOP) Q2110 ITU-T (10-Mar 1994)

15 J Soleacute-Pareta J Vila-Sallent Network-based paralell computing over ATM using improved SSCOP protocol Computer Communications 19 pp 915-926 (1996)

16 K Obraczka Multicast Transport Protocols A survey and Taxonomy IEEE Communi Magazine (1998)

17 R Venkateswaran CS Raghavendra X Chen and VP Kumar A Scalable Dynamic Multicast Routing Algorithm in ATM Networks IEEE pp 1361-1365 (1997)

18 Matthias Grossglauser and KK Ramakrishnan SEAM Scalable and Efficient ATM Multicast IEEE 1997 pp 867-875 (1997)

19 M Nguyen and M Schwartz MCMP A Transportsession level Distributed Protocol for Desktop Conference Setup IEEE Journal Selected and comunications Vol 14 Nordm 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 Nordm 3 pp 437-443 (April 1998)

22 R Kishimoto Agent communication system for multimedia communication services INFOCOMrsquo96 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 Nordm 3 pp 414-423 (April 1998)

  • ATM - Modo de Transferencia Asiacutencrona
  • Revisioacuten y Clasificacioacuten de Protocolos para Redes de Tecnologiacutea ATM
    • Resumen
    • 1-Introduccioacuten y motivaciones
    • 2- Protocolos nativos ATM
    • 3- Protocolos de transporte para redes ATM
    • 4- Protocolos multipoint
    • 5- Nuevos campos de investigacioacuten
      • Referencias
Page 3: Atm

La teacutecnica ATM multiplexa muchas celdas de circuitos virtuales en una ruta (path) virtual colocaacutendolas en particiones (slots) similar a la teacutecnica TDM Sin embargo ATM llena cada slot con celdas de un circuito virtual a la primera oportunidad similar a la operacioacuten de una red conmutada de paquetes La figura No2 describe los procesos de conmutacioacuten impliacutecitos los VC switches y los VP switches

Los slots de celda no usados son llenados con celdas idle identificadas por un patroacuten especiacutefico en la cabecera de la celda Este sistema no es igual al llamado bit stuffingen la multiplexacioacuten Asiacutencrona ya que aplica a celdas enteras Diferentes categoriacuteas de traacutefico son convertidas en celdas ATM viacutea la capa de adaptacioacuten de ATM (AAL - ATM Adaptation Layer) de acuerdo con el protocolo usado (Maacutes adelante se explica este protocolo) La tecnologiacutea ATM ha sido definida tanto por el ANSI como por el CCITT a traveacutes de sus respectivos comiteacutes ANSI T1 UIT SG XVIII como la tecnologiacutea 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 teacutecnicas de conmutacioacuten y multiplexacioacuten en la capa de enlace (Capa 2 del modelo OSI) para el trasiego del traacutefico del usuario final de la fuente al destino dentro de una red El ATM Forum grupo de fabricantes y usuarios dedicado al anaacutelisis y avances de ATM ha aprobado cuatro velocidades UNI (User Network Interfases) para ATM DS3 (44736 Mbits)

SONET STS3c (15552 Mbits) y 100 Mbits para UNI privados y 155 Mbits para UNI privadas UNI privadas se refieren a la interconexioacuten 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 Mbits especificado para redes de operadores (carriers) con redes T3 existentes velocidades UNI adicionales se han venido evaluando y estaacuten ofrecieacutendose Tambieacuten hay un alto intereacutes en interfases para velocidades EI (2Mbps) y T1 (1544 Mbps) para accesos ATM de baja velocidad

PROTOCOLO ATM

El protocolo ATM consiste de tres niveles o capas baacutesicas (Ver figura No 3) La primera capa llamada capa fiacutesica (Physical Layer) define los interfases fiacutesicos con los medios de transmisioacuten y el protocolo de trama para la red ATM es responsable de la correcta transmisioacuten y recepcioacuten de los bits en el medio fiacutesico apropiado A diferencia de muchas tecnologiacuteas LAN como Ethernet que especifica ciertos medios de transmisioacuten (10 base T 10 base 5 etc) ATM es independiente del transporte fiacutesico Las celdas ATM pueden ser transportadas en redes SONET (Synchronous Optical Network) SDH (Synchronous Digital Hierarchy) T3E3 TIEI o auacuten en modems de 9600 bps Hay dos subcapas en la capa fiacutesica que separan el medio fiacutesico de transmisioacuten y la extraccioacuten de los datos

La subcapa PMD (Physical Medium Depedent) tiene que ver con los detalles que se especifican para velocidades de transmisioacuten tipos de conectores fiacutesicos extraccioacuten 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 extraccioacuten de informacioacuten contenida desde la misma capa fiacutesica Esto incluye la generacioacuten y el chequeo del Header Error Correccioacuten (HEC) extrayendo celdas desde el flujo de bits de entrada y el procesamiento de celdas idles y el reconocimiento del liacutemite de la celda Otra funcioacuten importante es intercambiar informacioacuten de operacioacuten y mantenimiento (OAM) con el plano de administracioacuten (Ver figura No4) La segunda capa es la capa ATM Ello define la estructura de la celda y coacutemo las celdas fluyen sobre las conexiones loacutegicas 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 informacioacuten

Las celdas son transmitidas serialmente y se propagan en estricta secuencia numeacuterica a traveacutes de la red El tamantildeo 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 viacutedeo y protocolos sensibles al retardo A pesar de que no se disentildeoacute especiacuteficamente para eso la longitud de la celda ATM acomoda convenientemente dos Fast Packets IPX de 24 bytes cada uno Los comiteacutes de estaacutendares 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 aacuterea 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 puacuteblico (carrier) Especiacuteficamente la funcioacuten 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 conmutacioacuten de las celdas ATM

La capa de adaptacioacuten de ATM

La tercer capa es la ATM Adaptation Layer (AAL) La AAL juega un rol clave en el manejo de muacuteltiples tipos de traacutefico 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 maacutes altas tales como emulacioacuten de circuitos (circuit emulation) viacutedeo 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 estaacuten definidos actualmente La capa de Adaptacioacuten de ATM yace entre el ATM layer y las capas maacutes altas que usan el servicio ATM Su propoacutesito principal es resolver cualquier disparidad entre un servicio requerido por el usuario y atender los servicios disponibles del ATM layer La capa de adaptacioacuten introduce la informacioacuten en paquetes ATM y controla los errores de la transmisioacuten La informacioacuten transportada por la capa de adaptacioacuten se divide en cuatro clases seguacuten las propiedades siguientes

1 Que la informacioacuten que esta siendo transportada dependa o no del tiempo 2 Tasa de bit constantevariable 3 Modo de conexioacuten

Estas propiedades definen ocho clases posibles cuatro se definen como B-ISDN Clases de servicios La capa de adaptacioacuten 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 adaptacioacuten 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 informacioacuten en la cabecera y en el payload depende de la clase de informacioacuten que va a ser transportada

2)Capa de Segmentacioacuten 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 informacioacuten necesaria para el reensamblaje en el destino La figura siguiente aporta una mejor comprensioacuten 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 tamantildeo de la celda ATM para su transmisioacuten Tambieacuten realiza la funcioacuten inversa (reemsamblado) para las unidades de informacioacuten de orden superior Cada porcioacuten es ubicada en su propia unidad de protocolo de segmentacioacuten 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 informacioacuten que regule el tiempo con los datos AAL-1 provee recuperacioacuten de errores e indica la informacioacuten con errores que no podraacute ser recuperada

Capa de convergencia

Las funciones provistas a esta capa difieren dependiendo del servicio que se proveyoacute Provee la correccioacuten de errores

Capa de segmentacioacuten y reensamblaje

En esta capa los datos son segmentados y se les antildeade una cabecera La cabecera contiene 3 campos (ver diagrama)

Nuacutemero de secuencia usado para detectar una insercioacuten o perdida de un paquete Nuacutemero de secuencia para la proteccioacuten usado para corregir errores que ocurren en el

numero de secuencia Indicador de capa de convergencia usado para indicar la presencia de la funcioacuten de la capa

de convergencia

ALL 2

AAL-2 se usa para transferir datos con tasa de bits variable que dependen del tiempo Enviacutea la informacioacuten del tiempo conjuntamente con los datos para que esta puede recuperarse en el destino AAL-2 provee recuperacioacuten de errores e indica la informacioacuten que no puede recuperarse

Capa de convergencia

Esta capa provee para la correccioacuten de errores y transporta la informacioacuten del tiempo desde el origen al destino

Capa de segmentacioacuten y recuperacioacuten

El mensaje es segmentado y se le antildeade 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 informacioacuten es

o BOM comenzando de mensaje o COM continuacioacuten de mensaje o EOM fin de mensaje o indica que el paquete contiene informacioacuten de tiempo u

otra

El payload tambieacuten 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 disentildea para transferir los datos con tasa de bits variable que son independientes del tiempo AAL-3 puede ser dividido en dos modos de operacioacuten

1 Fiable En caso de perdida o mala recepcioacuten de datos estos vuelven a ser enviados El control de flujo es soportado

2 No fiable La recuperacioacuten 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 comuacuten de la capa de convergencia Esto es provisto tambieacuten por el AAL-2 CS Antildeade una cabecera y un payload a la parte comuacuten (ver diagrama)

La cabecera contiene 3 campos Indicador de la parte comuacuten que dice que el payload forma parte de la parte comuacuten Etiqueta de comienzo que indica el comienzo de la parte comuacuten de la capa de

convergencia Tamantildeo del buffer que dice al receptor el espacio necesario para acomodar el mensaje

El payload tambieacuten contiene 3 campos Alineacioacuten 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 comuacuten de la CS(capa de convergencia) El campo de longitud tiene la longitud de la parte comuacuten de la CS

1 Parte especifica del servicio Las funciones proveiacutedas en esta que capa dependen de los servicios pedidos Generalmente se incluyen funciones para la recuperacioacuten y deteccioacuten de errores y puede incluir tambieacuten funciones especiales

Capa de segmentacioacuten y reensamblaje

En esta capa los datos son partidos en paquetes de ATM Una cabecera y el payload que contiene la informacioacuten necesaria para la recuperacioacuten de errores y reensamblaje se antildeaden 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 Continuacioacuten de mensaje EOM Fin de mensaje SSM Mensaje uacutenico en el segmento

2) Numero de secuencia usado para detectar una insercioacuten o una perdida de un paquete 3) Identificador de multiplexacioacuten Este campo se usa para distinguir datos de diferentes comunicaciones que ha sido multiplexadas en una uacutenica conexioacuten de ATM El payload contiene dos de campos 1) Indicado de longitud que indica el nuacutemero de bytes uacutetiles en un paquete parcialmente lleno 2) CRC es para el control de errores

ALL 4

AAL-4 se disentildea para transportar datos con tasa de bits variable independientes del tiempo Es similar al AAL3 y tambieacuten puede operar en transmisioacuten fiable y o fiable AAL-4 provee la capacidad de transferir datos fuera de una conexioacuten expliacutecita

AAL 2 AAL 34 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 traacutefico de redes de aacuterea local (LAN) AAL 2 y AAL 3 soportan paquetes orientados a conexioacuten (Ver figura No5)

(El teacutermino orientado a conexioacuten describe la transferencia de datos despueacutes 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 jamaacutes vean estos errores reportados la degradacioacuten de respuesta o de caudal (through put) seriacutean los uacutenicos siacutentomas A diferencia de los mecanismos de control extremo a extremo que utiliza TCP en internerworking la capacidad de Gbitseg de la red ATM genera un juego de requerimientos necesarios para el control de flujo Si el control del flujo se hiciese como una realimentacioacuten del lazo extremo a extremo en el momento en que el mensaje de control de flujo arribase a la fuente eacutesta habriacutea transmitido ya algunos Mbytes de datos en el sistema exacerbando la congestioacuten Y en el momento en que la fuente reaccionase al mensaje de control la condicioacuten de congestioacuten hubiese podido desaparecer apagando innecesariamente la fuente La constante de tiempo de la realimentacioacuten extremo a extremo en las redes ATM (retardo de realimentacioacuten por producto lazo - ancho de banda) debe ser lo suficientemente alta como para cumplir con las necesidades del usuario sin que la dinaacutemica de la red se vuelva impractica Las condiciones de congestioacuten en las redes ATM estaacuten previstas para que sean extremadamente dinaacutemicas requiriendo de mecanismos de hardware lo suficientemente raacutepidos para llevar a la red al estado estacionario necesitando que la red en siacute eacuteste activamente involucrada en el raacutepido establecimiento de este estado estacionario Sin embargo esta aproximacioacuten simplista de control reactivo de lazo cerrado extremo a extremo en condiciones de congestioacuten no se considera suficiente para las redes ATM El consenso entre los investigadores de este campo arroja recomendaciones que incluyen el empleo de una coleccioacuten de esquemas de control de flujo junto con la colocacioacuten adecuada de los recursos y dimensionamiento de las redes para que aunados se pueda tratar y evadir la congestioacuten ya sea

Detectando y manipulando la congestioacuten que se genera tempranamente monitoreando de cerca las entradassalidas que estaacuten dentro de los conmutadores ATM y reaccionando gradualmente a medida que vaya arribando a ciertos niveles prefijados Tratando y controlando la inyeccioacuten de la conexioacuten de datos dentro de la red en la UNI (unidad interfaz de red) de tal forma que su tasa de inyeccioacuten sea modulada y medida alliacute primero antes de tener que ir a la conexioacuten de usuario a tomar acciones mas draacutesticas El estado de la red debe ser comunicado a la UNI generando raacutepidamente una celda de control de flujo siempre que se vaya a descartar una celda en alguacuten nodo debido a congestioacuten La UNI debe entonces manejar la congestioacuten cambiando su tasa de inyeccioacuten

o notificaacutendola a la conexioacuten de usuario para que cese el flujo dependiendo del nivel de severidad de la congestioacutenEl mayor compromiso durante el control de congestioacuten es el de tratar y afectar solo a los flujos de conexioacuten que son responsables de la congestioacuten y actuar de forma transparente frente a los flujos que observan buen comportamiento Al mismo tiempo permitir que el flujo de conexioacuten utilice tanto ancho de banda como necesite sino hay congestioacuten La recomendacioacuten UIT - T I 371 especifica un contrato de traacutefico que define como el traacutefico del usuario seria administrado El contrato que existe para cada conexion virtual (virtual path o virtual channel) es baacutesicamente un acuerdo entre el usuario y la red con respecto a la Calidad de Servicio (Quality Of Service - Q o S) y los paraacutemetros que regulan el flujo de celdas Estos descriptores de trafico dependen de una particular clase de servicio y pueden incluir bajo la especificacioacuten del ATM Forum UNI a cinco Q o S referenciados en los AALS El objetivo de estas sub clases de servicio es agrupar caracteriacutesticas 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 paraacutemetros pueden incluir el Sustained Cell Rate (SCR) el Miacutenimum Cell Rate (MCR) el Peak Cell Rate (PCR) yo el Burst Tolerance (BT) Para soportar todas las diferentes clases de servicios definidos por los estaacutendares el switch ATM debe ser capaz de definir eacutestos paraacutemetros en base a cada VC o cada VP y debe proveer amortiguadores (buffers) para absorber las raacutefagas de trafico

INTEROPERABILIDAD ENTRE FRAME RELAY Y ATM El objetivo final para todos los servicios descritos anteriormente es una migracioacuten suave de Frame Relay yo SMDS a redes ATM Por ejemplo la recomendacioacuten UIT - T I555 provee un marco para la interoperabilidad de Frame Relay y ATM Para alcanzar una maacutexima eficiencia se trata de brindar este servicio de interoperabilidad en la capa maacutes baja posible mediante conversioacuten de protocolo

PRIMER ESCENARIO

Cuando el servicio de Frame Relay es dado sobre la RDSI en banda ancha y los usuarios se conectan a traveacutes de la UNI de Frame Relay En esta solucioacuten 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 (VCVP) para enlazar los puntos de acceso Frame Relay En este esquema se puede explotar la naturaleza de orientacioacuten a conexioacuten Frame Relay (F R) siguiendo un comportamiento como

El usuario del enrutador pregunta por una conexioacuten al equipo interfaz de red El equipo interfaz de la red coloca las conexiones Frame Relay dentro de una conexioacuten ATM con las direcciones destino apropiadas Por cada trama de equipo interfaz de red traslada de la conexioacuten de Frame Relay a la ATM y viceversa La conexioacuten ATM esta desocupada cuando no se necesitaPara lograr este uacuteltimo punto el manejo de la poliacutetica de conexion del VC sera un aspecto crucial para el desempentildeo de este procedimiento Resulta difiacutecil de terminar el procedimiento para manejar un VC cuando la fuente de traacutefico es no orientada a conexioacuten 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 conexioacuten 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 opcioacuten se toma ventaja del uso actual del FR el cual es proveer un mallado virtual entre diferentes sitios para cargar traacutefico no orientado a conexioacuten 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 conmutacioacuten 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 traveacutes de sus respectivas interfaces de red (NNIs) Esto permitiriacutea a un proveedor de red manejar esta heterogeacutenea red como un todo Frame Relay provee usualmente la interconexioacuten para LAN a pesar de su natural orientacioacuten a conexioacuten 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 sobresimplificacioacuten los dos protocolos (AAL 3 y AAL 5) ofrecen basicamente el mismo servicio CPAAL (Parte Comuacuten 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 implementacioacuten y eficiencia del protocolo que incide en el costo Las caracteriacutesticas a tomar en cuenta cuyo detalle puede ser tema de otro artiacuteculo tienen que ver con Delimitacioacuten y Alineamiento de Tramas Multiplexacioacuten Deteccioacuten de errores de transmisioacuten eficiencia en la transmisioacuten 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 tecnologiacutea de red empresarial virtual del futuro un teacutermino que refleja tanto la evolucioacuten del modelo empresarial global y el eacutenfasis en la conectividad loacutegica donde los usuarios obtienen acceso a los recursos que necesitan y el operador de la red provee las rutas de conexioacuten y asigna el ancho de banda necesario a fuentes de traacutefico muy diferentes (voz datos viacutedeo) Aquellos que construyen y operan redes deben volver los ojos a las capacidades de la tecnologiacutea ATM ya que aspiran a la maacutegica combinacioacuten interconectividad global - escalabilidad de tecnologiacuteas y satisfaccioacuten del cliente local

BIBLIOGRAFIA

1 CCITT Rec I362 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 vol2 No8 ATM Testing crosses network boundaries Jim Frimmel

6 Newslink Alcatel Telecomrsquos customer magazine Vol IV No4 4th Quarter 1996 Adapting Networks to the Internet Challenge Krish Prabhu

Trabajo realizado por

Ivan Dario Cruz PradaNicruz[arroba]col1telecomcomco

Revisioacuten y Clasificacioacuten de Protocolos para Redes de Tecnologiacutea ATM

Joseacute Luis Gonzaacutelez-Saacutenchez y Jordi Domingo-Pascual

ResumenLa tecnologiacutea 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 investigacioacuten maacutes activo con la aspiracioacuten 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 asiacute como las caracteriacutesticas multicast la escalabilidad y la fiabilidad Se profundiza en el concepto de protocolo nativo ATM y son introducidos los protocolos maacutes importantes que satisfacen este importante requerimiento (N3 CONGRESS y kStack entre otros) Es importante destacar tambieacuten los protocolos de transporte pensados especiacuteficamente para la tecnologiacutea ATM La caracteriacutestica multicast (multipoint-to-multipoint) es una de las que maacutes esfuerzo estaacute costando garantizar a ATM pero existen ya propuestas que permiten la comunicacioacuten fiable a elevados anchos de banda y entre muacuteltiples emisores y receptores (SMART MCMP o MWAX) El artiacuteculo concluye con las investigacioness maacutes novedosas en torno a los protocolos ATM como las iniciativas que proponen redes ATM programables o activas (active networks) usando agentes moacuteviles

1-Introduccioacuten y motivacionesLa actual demanda de aplicaciones relacionadas con informacioacuten multimedia como son la video-conferencia audio-conferencia video bajo demanda (VoD) o sistemas colaborativos (pizarras compartidas teletrabajo telemedicina etc) y su coexistencia con aplicaciones maacutes claacutesicas (bases de datos transferencias de ficheros WWW etc) requiere tecnologiacuteas de comunicaciones capaces de ofrecer elevadas prestaciones Estas elevadas prestaciones estaacuten directamente relacionadas con la calidad de servicio (QoS) y concretamente con conceptos claramente parametrizables como el ancho de banda y la velocidad de transmisioacuten (throughput) el retardo de las transferencias (delay) la variabilidad en el retardo (jitter) la fiabilidad (reliability) de las transmisiones las caracteriacutesticas de multidifusioacuten a grupos dispersos de usuarios (multicast) y la posibilidad de gestionar muacuteltiples clases de servicio o flujos de informacioacuten en redes multiclass Para que las nuevas tecnologiacuteas en comunicaciones puedan ofrecer estas caracteriacutesticas es necesario revisar potenciar y ampliar las actuales arquitecturas servicios y protocolosde comunicaciones En los uacuteltimos dos o tres antildeos las investigaciones en el campo de ATM estaacuten dado lugar a importantes propuestas cuyo principal objetivo es ofrecer a las aplicaciones demandadas actualmente algunas o todas las caracteriacutesticas citadas anteriormente Presentamos en este trabajo los conceptos y propuestas maacutes novedosas en el contexto de ATM para ayudar al lector interesado en el dinaacutemico complejo y sofisticado campo de los protocolos de comunicaciones Realizamos la revisioacuten de algunos de los maacutes importantes conceptos teacutecnicas ideas y mecanismos en protocolos de altas prestaciones para redes de tecnologiacutea ATM El principal objetivo de este documento es ofrecer una actualizada visioacuten general no extensiva ni profunda de los protocolos propuestos y en desarrollo para dotar a las diversas clases de servicio ATM de las citadas caracteriacutesticas de calidad de servicio que aporten las potenciales elevadas prestaciones que la tecnologiacutea ATM es capaz de ofrecer El resto del documento estaacute estructurado de la siguiente forma La seccioacuten 2 revisa el concepto de protocolo nativo centrado en el contexto de las redes ATM La seccioacuten 3 describe las propuestas maacutes interesantes actualmente en materia de protocolos de transporte El apartado 4 comenta las transferencias multicast como un importante objetivo para una tecnologiacutea orientada a la conexioacuten como es ATM Concluimos en la seccioacuten 5 con los campos de investigacioacuten abiertos recientemente como son las redes activas y los procolos booster

2- Protocolos nativos ATM

Las aplicaciones nativas ATM estaacuten especiacuteficamente pensadas para usar la tecnologiacutea ATM y para explotar al maacuteximo sus especiales caracteriacutesticas Los protocolos nativos se encargan por tanto de ofrecer esas caracteriacutesticas intriacutensecas de las redes de tecnologiacutea ATM (soporte de QoS sentildealizacioacuten direccionamiento etc) a las aplicaciones nativas ATM (VoD pizarras compartidas video-conferencia) No obstante existen tambieacuten activas investigaciones para conseguir soportar sobre redes ATM aplicaciones no nativas ATM desarrolladas para otras tecnologiacuteas (IP Frame Relay SMDS) En [1] el termino native ATM services define servicios ATM especiacuteficos 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 adaptacioacuten (AALs) Disponibilidad de circuitos virtuales conmutados (SVCs) y circuitos virtuales permanentes (PVCs) Consideraciones relativas a la gestioacuten de traacutefico (clases de servicio garantiacuteas de QoS etc) Posibilidad de distribucioacuten de conexiones y de participacioacuten local en la administracioacuten de la red (protocolos ILMI y OAM)

El propoacutesito de los servicios nativos ATM es ofrecer el acceso a las clases de servicio o a las caracteriacutesticas de QoS en redes ATM Estos servicios nativos tambieacuten ofrecen soporte a un amplio y heterogeacuteneo rango de flujos con diversas propiedades y requerimientos recomendados en [1] Los protocolos de transferencia nativos ATM gestionan la sentildealizacioacuten UNI para establecer los SVCs configurar PVCs y mapear los perfiles de QoS en la correspondiente clase de servicio Los protocolos nativos tambieacuten realizan funciones claacutesicas como las de transporte mecanismos de control de errores transferencia de datos y controles de flujo y de congestioacuten En la referencia [1] se especifica la definicioacuten semaacutentica de los servicios y consideramos que es uacutetil contrastar esta semaacutentica con las redes ATM actuales que usan TCP como capa de transporte e IP-over-ATM como capa de red planteamiento por otro lado poco adecuado [2] por las siguientes razones

Las redes IP no garantizan la QoS extremo-extremo ofrecida por las redes ATM a circuitos individuales IP multiplexa muacuteltiples conexiones de transporte con distintos requerimientos de QoS en VCs simples TCP no soporta ceacutelulas RM (Resource Management) ABR y por consiguiente no puede usar directamente las garantiacuteas de QoS ofrecidas por la red ATM Adaptation Layer 5 (AAL5) realiza labores de checksum para detectar corrupcioacuten de datos TCP tambieacuten realiza estas labores (redundantes con AAL5) costosas en overhead (cada byte de un paquete debe ser chequeado) TCPIP son la representacioacuten de un grupo de protocolos bastante maacutes 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] Ademaacutes 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 tecnologiacutea ATM y tambieacuten existen antiguas y no nativas aplicaciones Este escenario implica cambiar las aplicaciones o proponer nuevas pilas de protocolos nativos ATM La encapsulacioacuten consecutiva de paquetes genera problemas de overhead y funciones redundantes como se ha argumentado anteriormente La limitacioacuten de recursos en los sistemas finales es otra importante motivacioacuten 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 puacuteblicos disfrutan tambieacuten de estas ventajas ATM RDSI y la telefoniacutea ofrecen un esquema de direccionamiento universal basado en NSAPE164 el cual es capaz de enrutar traacutefico de forma nativa Por tanto aunque ATM dispone de protocolos nativos con direccionamiento intriacutenceso estructurado y jeraacuterquico eacuteste no es aprovechado por las aplicaciones que estaacuten 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 tambieacuten existen importantes investigaciones en torno a los protocolos nativos ATM En esta seccioacuten se muestran las propuestas maacutes importantes y actuales en materia de protocolos nativos ATM[2] [7] [8] [9] [10] [11] [12] que a su vezestaacuten sirviendo de base para nuevas investigaciones

[8] presentan el disentildeo implementacioacuten y comportamiento de una pila en modo nativo ATM y contrasta la semaacutentica 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 automaacuteticamente los siguientes problemas

IP-over-ATM no ofrece garantiacutea de QoS pues sus aplicaciones soacutelo ven la interfaz IP El nuacutecleo 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 sentildealizacioacuten 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 caracteriacutesticas la entrega fiable y no fiable de datos con control de flujo Este protocolo de transporte es ampliado en la seccioacuten 5 [2] presenta N3 (Native Non-broadcasting medium access Networking) un protocolo de transporte ligero y nativo ATM La pila N3 se ha disentildeado 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 ademaacutes aporta otras importantes novedades Los principales componentes de N3 incluyen una API sockets ATM nativa un protocolo de transporte ATM y un servicio de nombres ATM (Fig2) El protocolo de transporte ATM propuesto en [2] ofrece soporte para tres diferentes tipos de servicio entrega garantizada (mecanismos de retransmisioacuten) 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 congestioacuten de la transferencia de datagramas y de la multiplexacioacuten 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 maacutes importante El Flow Management se responsabiliza de manipular los flujos de datos desde y hasta la red viacutea la interfaz AAL La segmentacioacuten el reensamblado y el control de errores es tambieacuten 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 congestioacuten y de flujo extremo-extremo maacutes complejo

[7] describe la semaacutentica de una pila de protocolos y explora una nueva arquitectura de protocolo adaptada a la tecnologiacutea ATM y a las aplicaciones multimedia El disentildeo estaacute basado en tres principios baacutesicos separacioacuten de flujos de control y de datos minimizacioacuten del overhead y de la duplicidad de funciones y acceso de las aplicaciones al nivel ATM con garantiacuteas 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-over-ATM 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 moacutedulo CNTL abre una conexioacuten de sentildealizacioacuten con el dispositivo ATM y establece una gestioacuten de las llamadas de mensajes de configuracioacuten PF_ATM separa flujos de datos y de control para aliviar el liacutemite de comportamiento en las comunicaciones Esto permite a los mecanismos de control de traacutefico ser raacutepidos y sencillos mientras los mecanismos de control pueden ser tan complicados como sea necesario Esta separacioacuten permite tambieacuten que los dispositivos puedan estar en los puntos finales de una conexioacuten La interfaz PF_ATM da a las aplicaciones acceso directo a la capa de enlace ATM y extiende las garantiacuteas de QoS a los puntos extremos de la comunicacioacuten Un segundo prototipo[7] es disentildeado e implementado con dos objetivos principales en la optimizacioacuten de la pila nativa ATM

Optimizar los caminos de datos entre los adaptadores ATM aprovechando la separacioacuten de flujos de control y de datos y la capacidad de gestioacuten de datos especiacuteficos de las conexiones de la pila ATM

Optimizar el procesamiento de overheads usando una pila de protocolos nativo ATM en lugar de UDPIP

[11] introduce CONGRESS (CONnection oriented Group-address RESolution Service) otro eficiente protocolo nativo ATM para la resolucioacuten y gestioacuten 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 disentildeo basado en los dos siguientes principios

Disentildeo jeraacuterquico los servicios del protocolo son ofrecidos a las aplicaciones por muacuteltiples servidores organizados jeraacuterquicamente No inundacioacuten se evita la inundacioacuten 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 implementacioacuten sobre Unix y Windows NT estaacute 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 antildeadido un moacutedulo que monitoria la QoS extremo-a-extremo

3- Protocolos de transporte para redes ATMEn los dos o tres uacuteltimos antildeos ha habido numerosos e interesante intentos por disentildear protocolos de transporte La referencia [10] presenta un completo y ya claacutesico resumen de las propuestas maacutes interesantes en materia de protocolos de transporte para redes de alta velocidad (mayoritariamente IP en el artiacuteculo) Ademaacutes la referencia [13] ofrece una interesante visioacuten de las caracteriacutesticas maacutes importantes en los protocolos de elevada velocidad Son estudiadas tambieacuten diversas arquitecturas de protocolos y varias teacutecnicas de implementacioacuten Los protocolos de transporte de elevada velocidad son fuente de activas investigaciones y estaacuten en constante evolucioacuten desde hace maacutes de dos deacutecadas 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 aacutembito de las comunicaciones que ha recibido mayor atencioacuten es la capa de transporte la cuarta capa del OSI-RM de los protocolos de comunicaciones TCP e ISO TP4 son los dos maacutes populares protocolos de transporte Pero centraacutendonos maacutes concretamente en el aacutembito de ATM la literatura presenta varios protocolos de transporte y arquitecturas para redes de alta velocidad revisadas resumidamente a continuacioacuten [7] ofrece una excelente y didaacutectica arquitectura de pila de protocolos para aplicaciones multimedia en modo nativo ATM Esta arquitectura de protocolo ha sido ya descrita brevemente en la seccioacuten anterior [8] presentan el disentildeo implementacioacuten 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 estaacute formada por tres entidades principales aplicacioacuten sentildealizacioacuten y transporte La siguiente Tabla 1 muestra un conjunto de nueve baacutesicos 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 combinacioacuten de servicios La marca X indica el servicio baacutesico soportado en cada clase de servicio general

Clases de servicio

Servicios Servicio de comportamiento

garantizado

Servicio fiable Servicio Best effort

- Transferencia Simplex de datos

X X X

- Control de errores - deteccion de errorestimeouts retransmisiones

No existente (ofrecido por

AAL5)

- Bucle abierto - Control de flujo realimentado

No existente -

- X

- No existente

- Tamantildeo de mensaje ilimitado

X X X

- Eleccioacuten de blocking - Aplicacioacuten Non-blocking

X X

X X

X X

- Eleccioacuten de byte stream - Semaacutentica transferencia de mensajes

X X

X X

X X

- Garantiacuteas de QoS requerimientos de ancho de banda

No soportado No soportado

- Reserva de recursos X No existente No existente

- Transferencias Multicast X No soportado Para servicios no fiables

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 recuperacioacuten de peacuterdidas del protocolo estaacutendar SSCOP [14] y demuestran que el resultado ofrece baja latencia eficiente recuperacioacuten de ceacutelulas perdidas y es tan robusto como el estaacutendar SSCOP

4- Protocolos multipointEl crecimiento de las redes ATM viene motivado en parte por la demanda de servicios multimedia para grupos dispersos de usuarios El traacutefico multicast tiene caracteriacutesticas particulares descritas para ATM en UNI 40 [6] y anteriores [5] La distribucioacuten de informacioacuten punto-a-multipunto (uno-a-muchos) o multipunto-a-multipunto (muchos-a-muchos) es un objetivo baacutesico propuesto por varios protocolos y arquitecturas ATM que ofrecen el soporte multimedia yo multicast como audio-conferencia video-conferencia trabajos colaborativos o VoD ATM es auacuten una tecnologiacutea emergente disentildeada 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 30) para ATM define conexiones punto-a-multipunto y las conexiones multipunto-a-multipunto soacutelo 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 topologiacutea completamente mallada todos-con-todos Aunque esta topologiacutea ofrece conexiones multipunto-a-multipunto hay que destacar que no escala bien cuando el nuacutemero de participantes es elevado Una alternativa al anterior esquema es el uso de un servidor que actuacutea a modo de raiacutez en el aacuterbol multipunto Este meacutetodo soacutelo requiere un nodo raiacutez para almacenar informacioacuten pero la desventaja de este meacutetodo son las potenciales congestiones en el servidor

cuando debe encargarse de enviacuteos y retransmisiones de las conexiones multipunto-a-multipunto

Para solventar las limitaciones de UNI 30 y UNI 31 [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 sentildealizacioacuten ATM (UNI 31 UNI 40) [4][5][6] Comenzamos destacando la referencia [16] como un reciente trabajo que revisa y compara los protocolos de transporte multicast maacutes importantes en Internet como MTP-2 XTP RTP SRM RAMP RMTP MFTP STORM etc IETF e IRTF (como ITU-T y ATM Forum) tambieacuten impulsan una importante actividad en este campo La referencia [16] revisa los maacutes representativos protocolos multicast y los clasifica de acuerdo a la taxonomiacutea de varias caracteriacutesticas (propagacioacuten de datos mecanismos de fiabilidad retransmisiones control de congestioacuten y de flujo gestioacuten de grupos multicast etc) En Internet los mecanismos efectivos de control de congestioacuten son una de las prioridades en las investigaciones de las transferencias multicast fiables Los mecanismos de seguridad y las teacutecnicas escalables de recuperacioacuten 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 maacutes importantes caracteriacutesticas En esta seccioacuten 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 maacutes interesantes en los siguientes paacuterrafos SMART (shared many-to-many ATM reservations)[3] es un protocolo para controlar un aacuterbol ATM multicast compartido soportando comunicaciones muchos-a-muchos (many-to-many) Esta propuesta tiene importantes caracteriacutesticas como que reside completamente en la capa ATM y no requiere ninguacuten servidor soporta uno o varios VCCs (y tambieacuten VPCs) cuyo nuacutemero es libremente configurado y es independiente del nuacutemero de puntos finales usa el concepto de bloques de datos como en la clase de servicio ABT y tambieacuten permite VCCs de las clases CBR VBR o UBR el protocolo garantiza que no existen puntos de interrelacioacuten en los VCC del aacuterbol son respetadas las garantiacuteas del contrato de traacutefico asociado con los VCCs etc SMART puede ser entendido como un protocolo completamente distribuido para coordinar la distribucioacuten de VPIsVCIs 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 ceacutelulas de datos desde diferentes fuentes pueden llegar intercaladas a un destinatario) y tambieacuten Demand Sharing (los recursos asignados a conexiones muchos-a-muchos son dinaacutemicamente compartidas entre todas las potenciales fuentes El artiacuteculo [3] describe el protocolo SMART formal e informalmente y propone completas pruebas de correccioacuten y un detallado anaacutelisis de comportamiento para estudios futuros Tambieacuten son sugeridas otras investigaciones como son ofrecer justicia en los accesos a los aacuterboles multicast investigar las ceacutelulas RM perioacutedicamente para aliviar las congestiones en la red o disminuir el tiempo de acceso del usuario a los aacuterboles de distribucioacuten multicast anaacutelisis de las ceacutelulas RM dentro de cada VCC o fuera enviando todas las ceacutelulas RM en un VCC dedicado En [17] se presenta MWAX un algoritmo dinaacutemico 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 artiacuteculo describe un esquema jeraacuterquico basado en CBT para incorporar routing multipunto-a-multipunto en PNNI En el algoritmo los nodos core actuacutean como participantes pasivos para eliminar la dependencia en la seleccioacuten de estos nodos Con un mecanismo de backup se consigue un algoritmo tolerante a fallos en los nodos core lo cual puede ser faacutecilmente 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 jerarquiacutea SEAM (Scalable and Efficient ATM Multicast) [18] propone una arquitectura escalable eficiente y multicast multipunto-a-multipunto para redes ATM que usa un soacutelo VC para un grupo multicast de muacuteltiples 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 Tambieacuten realiza aportaciones para conseguir soportar IP multicast sobre redes ATM extensas

SEAM usa un soacutelo aacuterbol de distribucioacuten 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 sentildealizacioacuten del grupo Este trabajo deja abiertas investigaciones referentes a la gestioacuten de traacutefico y a la entrega fiable de traacuteficos multicasting Concluimos esta seccioacuten destacando MCMP (Multiparty Conference Management Protocol) [19] que sin estar pensado especiacuteficamente para ATM es un protocolo de nivel sesioacutentransporte distribuido extremo-extremo y desarrollado para gestioacuten de grupos de aplicaciones de conferencia MCMP es un conjunto de algoritmos de control distribuido para configuracioacuten de conferencias multipunto y gestioacuten de miembros de grupos de usuarios Conceptualmente MCMP reside en el nivel de sesioacuten en el que se establece la infraestructura para activar la transferencia de informacioacuten entre los participantes en la conferencia Pero funcionalmente el protocolo acompasa los niveles de sesioacuten y de transporte pues utiliza directamente servicios del nivel de red Son destacables las condiciones de correccioacuten (conectividad validacioacuten unicidad consistencia y terminacioacuten) que deben ser satisfechas una vez que la conferencia ha sido configurada por el algoritmo de configuracioacuten de MCMP El artiacuteculo muestra exhaustivas pruebas de correccioacuten para uno de los algoritmos y tambieacuten describe la especificacioacuten y verificacioacuten del protocolo

5- Nuevos campos de investigacioacutenEn todas las redes existen gran variedad de elementos hardware (switchs routers bridges brouters hubs ETDs etc) que realizan muy diversas funciones (conmutacioacuten routing puenteo controles de congestioacuten y de flujo garantiacutea de QoS ejecucioacuten de aplicaciones etc) En la actualidad la red es mayormente un canal de comunicacioacuten para transferir paquetes entre equipos finales (ayudada por los elementos hardware antes citados) Pero tambieacuten se estaacuten realizando importante esfuerzos para equipar a los elementos hardware con elevadas prestaciones aportadas por diversas teacutecnicas software Esto dota a la red de caracteriacutesticas activas (active networks) en el sentido de que los elementos hardware que la componen computan modifican u operan los contenidos de los paquetes y tambieacuten seraacuten capaces de transferir o propagar coacutedigo Por consiguiente una red activa es una red programable [20] es una excelente revisioacuten de este novedoso campo de investigacioacuten que discute dos planteamientos en la realizacioacuten de redes activas la idea del conmutador programable y la de la caacutepsula Una red es activa si en sus aacuterboles de distribucioacuten multicast existen nodos activos con capacidad para ejecutar programas yo capaces de implementar mecanismos de propagacioacuten de coacutedigo Algunas de las ventajas de los protocolos activos son conseguidas instalando nodos activos en puntos estrateacutegicos de la red Otro nuevo concepto es presentado en [21] como una metodologiacutea para el disentildeo de protocolos Los protocol boosters son una nueva contribucioacuten a las redes activas o programables Una ventaja de los boosters es que pueden ser faacutecilmente 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 aacuterea extensa Este papel introduce una arquitectura software orientada a agente y propone el concepto de agente de comunicacioacuten para servicio de comunicacioacuten 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 artiacuteculo muestra agentes software moacuteviles usados para implementar operaciones robustas y funciones de mantenimiento en redes ATM Los agentes desempentildean un rol similar al de las ceacutelulas OAM en ATM estaacutendar pues son transmitidos entre entidades de control a intervalos regulares usando recursos predefinidos La diferencia entre los agentes moacuteviles y las ceacutelulas OAM reside en que eacutestos pueden contener coacutedigo Para concluir destacar que la integracioacuten del traacutefico IP sobre tecnologiacutea ATM es tambieacuten uno de los campos maacutes activos en la actualidad En esta liacutenea pueden destacarse los siguientes protocolos IP-over-ATM IP Switching Tag Switching NHRP MPOA IMSS CSR ARIS AREQUIPARED y EPD Referencias

1 ____ Native ATM Service Semantic Description Version 1 ATM Forum Technical Committee ATM Forum Document af-saa-0048000 (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 Broadband Networks Multimedia Applications Services and Techniques ECMASTrsquo98 Springer (May 1998)

3 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 Nordm 3 (April 1997)

4 W D Zhong K Yukimatsu Design requeriments and architectures for multicast ATM switching IEICE Trans Com Vol E77-B pp 1420-1428 (Nov 1994)

5 ____ ATM user-network interface version 31 specification ATM Forum (1994)

6 ____ Traffic Management Specification Version 40 ATM Forum Technical Committee ATM Forum Document af-tm-0056000 (April 1996)

7 D Kandlur D Saha and W Willebeck Protocol Architecture for multimedia Application over ATM Networks IEEE Journal Selected and Communications Vol 14 Nordm 7 pp 1349-1359 (Sep 1996)

8 R Ahuja S Keshav and H Saran Design Implementation and Performance Measurement of a Native-Mode ATM Transport Layer (Estended Version) IEEEACM Transactions on Networking Vol 4 Nordm 4 (Aug 1996)

9 R Karabek A Native ATM Protocol Architecture Design and Performance Evaluation IEEE Proceedings 22nd Annual Conference on Local Computer Networks pp 204-210 (1997)

10 D C Feldmeier A framework of architectural concepts for high-speed communications systems IEEE J Select Areas CommunVol11 Nordm 4 (May 1993)

11 T Anker D Breitgand D Dolev Z Levy Congress CONnection-oriented Group-address RESolution Service Proceeding of SPIE97 vol 3233 on Broadband Networking Technologies Nov (1997)

12 kStack httpcometcolumbiaedusoftwarekStack

13 T La Porta and M Schwartz Architectures Features and Implementation of High-Speed Transport Protocols IEEE Network Magazine pp 14-22 (May 1991)

14 ____ B-ISDN ATM Adaptation Layer Service Specific Connection Oriented Protocol (SSCOP) Q2110 ITU-T (10-Mar 1994)

15 J Soleacute-Pareta J Vila-Sallent Network-based paralell computing over ATM using improved SSCOP protocol Computer Communications 19 pp 915-926 (1996)

16 K Obraczka Multicast Transport Protocols A survey and Taxonomy IEEE Communi Magazine (1998)

17 R Venkateswaran CS Raghavendra X Chen and VP Kumar A Scalable Dynamic Multicast Routing Algorithm in ATM Networks IEEE pp 1361-1365 (1997)

18 Matthias Grossglauser and KK Ramakrishnan SEAM Scalable and Efficient ATM Multicast IEEE 1997 pp 867-875 (1997)

19 M Nguyen and M Schwartz MCMP A Transportsession level Distributed Protocol for Desktop Conference Setup IEEE Journal Selected and comunications Vol 14 Nordm 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 Nordm 3 pp 437-443 (April 1998)

22 R Kishimoto Agent communication system for multimedia communication services INFOCOMrsquo96 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 Nordm 3 pp 414-423 (April 1998)

  • ATM - Modo de Transferencia Asiacutencrona
  • Revisioacuten y Clasificacioacuten de Protocolos para Redes de Tecnologiacutea ATM
    • Resumen
    • 1-Introduccioacuten y motivaciones
    • 2- Protocolos nativos ATM
    • 3- Protocolos de transporte para redes ATM
    • 4- Protocolos multipoint
    • 5- Nuevos campos de investigacioacuten
      • Referencias
Page 4: Atm

SONET STS3c (15552 Mbits) y 100 Mbits para UNI privados y 155 Mbits para UNI privadas UNI privadas se refieren a la interconexioacuten 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 Mbits especificado para redes de operadores (carriers) con redes T3 existentes velocidades UNI adicionales se han venido evaluando y estaacuten ofrecieacutendose Tambieacuten hay un alto intereacutes en interfases para velocidades EI (2Mbps) y T1 (1544 Mbps) para accesos ATM de baja velocidad

PROTOCOLO ATM

El protocolo ATM consiste de tres niveles o capas baacutesicas (Ver figura No 3) La primera capa llamada capa fiacutesica (Physical Layer) define los interfases fiacutesicos con los medios de transmisioacuten y el protocolo de trama para la red ATM es responsable de la correcta transmisioacuten y recepcioacuten de los bits en el medio fiacutesico apropiado A diferencia de muchas tecnologiacuteas LAN como Ethernet que especifica ciertos medios de transmisioacuten (10 base T 10 base 5 etc) ATM es independiente del transporte fiacutesico Las celdas ATM pueden ser transportadas en redes SONET (Synchronous Optical Network) SDH (Synchronous Digital Hierarchy) T3E3 TIEI o auacuten en modems de 9600 bps Hay dos subcapas en la capa fiacutesica que separan el medio fiacutesico de transmisioacuten y la extraccioacuten de los datos

La subcapa PMD (Physical Medium Depedent) tiene que ver con los detalles que se especifican para velocidades de transmisioacuten tipos de conectores fiacutesicos extraccioacuten 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 extraccioacuten de informacioacuten contenida desde la misma capa fiacutesica Esto incluye la generacioacuten y el chequeo del Header Error Correccioacuten (HEC) extrayendo celdas desde el flujo de bits de entrada y el procesamiento de celdas idles y el reconocimiento del liacutemite de la celda Otra funcioacuten importante es intercambiar informacioacuten de operacioacuten y mantenimiento (OAM) con el plano de administracioacuten (Ver figura No4) La segunda capa es la capa ATM Ello define la estructura de la celda y coacutemo las celdas fluyen sobre las conexiones loacutegicas 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 informacioacuten

Las celdas son transmitidas serialmente y se propagan en estricta secuencia numeacuterica a traveacutes de la red El tamantildeo 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 viacutedeo y protocolos sensibles al retardo A pesar de que no se disentildeoacute especiacuteficamente para eso la longitud de la celda ATM acomoda convenientemente dos Fast Packets IPX de 24 bytes cada uno Los comiteacutes de estaacutendares 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 aacuterea 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 puacuteblico (carrier) Especiacuteficamente la funcioacuten 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 conmutacioacuten de las celdas ATM

La capa de adaptacioacuten de ATM

La tercer capa es la ATM Adaptation Layer (AAL) La AAL juega un rol clave en el manejo de muacuteltiples tipos de traacutefico 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 maacutes altas tales como emulacioacuten de circuitos (circuit emulation) viacutedeo 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 estaacuten definidos actualmente La capa de Adaptacioacuten de ATM yace entre el ATM layer y las capas maacutes altas que usan el servicio ATM Su propoacutesito principal es resolver cualquier disparidad entre un servicio requerido por el usuario y atender los servicios disponibles del ATM layer La capa de adaptacioacuten introduce la informacioacuten en paquetes ATM y controla los errores de la transmisioacuten La informacioacuten transportada por la capa de adaptacioacuten se divide en cuatro clases seguacuten las propiedades siguientes

1 Que la informacioacuten que esta siendo transportada dependa o no del tiempo 2 Tasa de bit constantevariable 3 Modo de conexioacuten

Estas propiedades definen ocho clases posibles cuatro se definen como B-ISDN Clases de servicios La capa de adaptacioacuten 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 adaptacioacuten 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 informacioacuten en la cabecera y en el payload depende de la clase de informacioacuten que va a ser transportada

2)Capa de Segmentacioacuten 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 informacioacuten necesaria para el reensamblaje en el destino La figura siguiente aporta una mejor comprensioacuten 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 tamantildeo de la celda ATM para su transmisioacuten Tambieacuten realiza la funcioacuten inversa (reemsamblado) para las unidades de informacioacuten de orden superior Cada porcioacuten es ubicada en su propia unidad de protocolo de segmentacioacuten 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 informacioacuten que regule el tiempo con los datos AAL-1 provee recuperacioacuten de errores e indica la informacioacuten con errores que no podraacute ser recuperada

Capa de convergencia

Las funciones provistas a esta capa difieren dependiendo del servicio que se proveyoacute Provee la correccioacuten de errores

Capa de segmentacioacuten y reensamblaje

En esta capa los datos son segmentados y se les antildeade una cabecera La cabecera contiene 3 campos (ver diagrama)

Nuacutemero de secuencia usado para detectar una insercioacuten o perdida de un paquete Nuacutemero de secuencia para la proteccioacuten usado para corregir errores que ocurren en el

numero de secuencia Indicador de capa de convergencia usado para indicar la presencia de la funcioacuten de la capa

de convergencia

ALL 2

AAL-2 se usa para transferir datos con tasa de bits variable que dependen del tiempo Enviacutea la informacioacuten del tiempo conjuntamente con los datos para que esta puede recuperarse en el destino AAL-2 provee recuperacioacuten de errores e indica la informacioacuten que no puede recuperarse

Capa de convergencia

Esta capa provee para la correccioacuten de errores y transporta la informacioacuten del tiempo desde el origen al destino

Capa de segmentacioacuten y recuperacioacuten

El mensaje es segmentado y se le antildeade 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 informacioacuten es

o BOM comenzando de mensaje o COM continuacioacuten de mensaje o EOM fin de mensaje o indica que el paquete contiene informacioacuten de tiempo u

otra

El payload tambieacuten 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 disentildea para transferir los datos con tasa de bits variable que son independientes del tiempo AAL-3 puede ser dividido en dos modos de operacioacuten

1 Fiable En caso de perdida o mala recepcioacuten de datos estos vuelven a ser enviados El control de flujo es soportado

2 No fiable La recuperacioacuten 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 comuacuten de la capa de convergencia Esto es provisto tambieacuten por el AAL-2 CS Antildeade una cabecera y un payload a la parte comuacuten (ver diagrama)

La cabecera contiene 3 campos Indicador de la parte comuacuten que dice que el payload forma parte de la parte comuacuten Etiqueta de comienzo que indica el comienzo de la parte comuacuten de la capa de

convergencia Tamantildeo del buffer que dice al receptor el espacio necesario para acomodar el mensaje

El payload tambieacuten contiene 3 campos Alineacioacuten 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 comuacuten de la CS(capa de convergencia) El campo de longitud tiene la longitud de la parte comuacuten de la CS

1 Parte especifica del servicio Las funciones proveiacutedas en esta que capa dependen de los servicios pedidos Generalmente se incluyen funciones para la recuperacioacuten y deteccioacuten de errores y puede incluir tambieacuten funciones especiales

Capa de segmentacioacuten y reensamblaje

En esta capa los datos son partidos en paquetes de ATM Una cabecera y el payload que contiene la informacioacuten necesaria para la recuperacioacuten de errores y reensamblaje se antildeaden 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 Continuacioacuten de mensaje EOM Fin de mensaje SSM Mensaje uacutenico en el segmento

2) Numero de secuencia usado para detectar una insercioacuten o una perdida de un paquete 3) Identificador de multiplexacioacuten Este campo se usa para distinguir datos de diferentes comunicaciones que ha sido multiplexadas en una uacutenica conexioacuten de ATM El payload contiene dos de campos 1) Indicado de longitud que indica el nuacutemero de bytes uacutetiles en un paquete parcialmente lleno 2) CRC es para el control de errores

ALL 4

AAL-4 se disentildea para transportar datos con tasa de bits variable independientes del tiempo Es similar al AAL3 y tambieacuten puede operar en transmisioacuten fiable y o fiable AAL-4 provee la capacidad de transferir datos fuera de una conexioacuten expliacutecita

AAL 2 AAL 34 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 traacutefico de redes de aacuterea local (LAN) AAL 2 y AAL 3 soportan paquetes orientados a conexioacuten (Ver figura No5)

(El teacutermino orientado a conexioacuten describe la transferencia de datos despueacutes 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 jamaacutes vean estos errores reportados la degradacioacuten de respuesta o de caudal (through put) seriacutean los uacutenicos siacutentomas A diferencia de los mecanismos de control extremo a extremo que utiliza TCP en internerworking la capacidad de Gbitseg de la red ATM genera un juego de requerimientos necesarios para el control de flujo Si el control del flujo se hiciese como una realimentacioacuten del lazo extremo a extremo en el momento en que el mensaje de control de flujo arribase a la fuente eacutesta habriacutea transmitido ya algunos Mbytes de datos en el sistema exacerbando la congestioacuten Y en el momento en que la fuente reaccionase al mensaje de control la condicioacuten de congestioacuten hubiese podido desaparecer apagando innecesariamente la fuente La constante de tiempo de la realimentacioacuten extremo a extremo en las redes ATM (retardo de realimentacioacuten por producto lazo - ancho de banda) debe ser lo suficientemente alta como para cumplir con las necesidades del usuario sin que la dinaacutemica de la red se vuelva impractica Las condiciones de congestioacuten en las redes ATM estaacuten previstas para que sean extremadamente dinaacutemicas requiriendo de mecanismos de hardware lo suficientemente raacutepidos para llevar a la red al estado estacionario necesitando que la red en siacute eacuteste activamente involucrada en el raacutepido establecimiento de este estado estacionario Sin embargo esta aproximacioacuten simplista de control reactivo de lazo cerrado extremo a extremo en condiciones de congestioacuten no se considera suficiente para las redes ATM El consenso entre los investigadores de este campo arroja recomendaciones que incluyen el empleo de una coleccioacuten de esquemas de control de flujo junto con la colocacioacuten adecuada de los recursos y dimensionamiento de las redes para que aunados se pueda tratar y evadir la congestioacuten ya sea

Detectando y manipulando la congestioacuten que se genera tempranamente monitoreando de cerca las entradassalidas que estaacuten dentro de los conmutadores ATM y reaccionando gradualmente a medida que vaya arribando a ciertos niveles prefijados Tratando y controlando la inyeccioacuten de la conexioacuten de datos dentro de la red en la UNI (unidad interfaz de red) de tal forma que su tasa de inyeccioacuten sea modulada y medida alliacute primero antes de tener que ir a la conexioacuten de usuario a tomar acciones mas draacutesticas El estado de la red debe ser comunicado a la UNI generando raacutepidamente una celda de control de flujo siempre que se vaya a descartar una celda en alguacuten nodo debido a congestioacuten La UNI debe entonces manejar la congestioacuten cambiando su tasa de inyeccioacuten

o notificaacutendola a la conexioacuten de usuario para que cese el flujo dependiendo del nivel de severidad de la congestioacutenEl mayor compromiso durante el control de congestioacuten es el de tratar y afectar solo a los flujos de conexioacuten que son responsables de la congestioacuten y actuar de forma transparente frente a los flujos que observan buen comportamiento Al mismo tiempo permitir que el flujo de conexioacuten utilice tanto ancho de banda como necesite sino hay congestioacuten La recomendacioacuten UIT - T I 371 especifica un contrato de traacutefico que define como el traacutefico del usuario seria administrado El contrato que existe para cada conexion virtual (virtual path o virtual channel) es baacutesicamente un acuerdo entre el usuario y la red con respecto a la Calidad de Servicio (Quality Of Service - Q o S) y los paraacutemetros que regulan el flujo de celdas Estos descriptores de trafico dependen de una particular clase de servicio y pueden incluir bajo la especificacioacuten del ATM Forum UNI a cinco Q o S referenciados en los AALS El objetivo de estas sub clases de servicio es agrupar caracteriacutesticas 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 paraacutemetros pueden incluir el Sustained Cell Rate (SCR) el Miacutenimum Cell Rate (MCR) el Peak Cell Rate (PCR) yo el Burst Tolerance (BT) Para soportar todas las diferentes clases de servicios definidos por los estaacutendares el switch ATM debe ser capaz de definir eacutestos paraacutemetros en base a cada VC o cada VP y debe proveer amortiguadores (buffers) para absorber las raacutefagas de trafico

INTEROPERABILIDAD ENTRE FRAME RELAY Y ATM El objetivo final para todos los servicios descritos anteriormente es una migracioacuten suave de Frame Relay yo SMDS a redes ATM Por ejemplo la recomendacioacuten UIT - T I555 provee un marco para la interoperabilidad de Frame Relay y ATM Para alcanzar una maacutexima eficiencia se trata de brindar este servicio de interoperabilidad en la capa maacutes baja posible mediante conversioacuten de protocolo

PRIMER ESCENARIO

Cuando el servicio de Frame Relay es dado sobre la RDSI en banda ancha y los usuarios se conectan a traveacutes de la UNI de Frame Relay En esta solucioacuten 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 (VCVP) para enlazar los puntos de acceso Frame Relay En este esquema se puede explotar la naturaleza de orientacioacuten a conexioacuten Frame Relay (F R) siguiendo un comportamiento como

El usuario del enrutador pregunta por una conexioacuten al equipo interfaz de red El equipo interfaz de la red coloca las conexiones Frame Relay dentro de una conexioacuten ATM con las direcciones destino apropiadas Por cada trama de equipo interfaz de red traslada de la conexioacuten de Frame Relay a la ATM y viceversa La conexioacuten ATM esta desocupada cuando no se necesitaPara lograr este uacuteltimo punto el manejo de la poliacutetica de conexion del VC sera un aspecto crucial para el desempentildeo de este procedimiento Resulta difiacutecil de terminar el procedimiento para manejar un VC cuando la fuente de traacutefico es no orientada a conexioacuten 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 conexioacuten 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 opcioacuten se toma ventaja del uso actual del FR el cual es proveer un mallado virtual entre diferentes sitios para cargar traacutefico no orientado a conexioacuten 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 conmutacioacuten 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 traveacutes de sus respectivas interfaces de red (NNIs) Esto permitiriacutea a un proveedor de red manejar esta heterogeacutenea red como un todo Frame Relay provee usualmente la interconexioacuten para LAN a pesar de su natural orientacioacuten a conexioacuten 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 sobresimplificacioacuten los dos protocolos (AAL 3 y AAL 5) ofrecen basicamente el mismo servicio CPAAL (Parte Comuacuten 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 implementacioacuten y eficiencia del protocolo que incide en el costo Las caracteriacutesticas a tomar en cuenta cuyo detalle puede ser tema de otro artiacuteculo tienen que ver con Delimitacioacuten y Alineamiento de Tramas Multiplexacioacuten Deteccioacuten de errores de transmisioacuten eficiencia en la transmisioacuten 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 tecnologiacutea de red empresarial virtual del futuro un teacutermino que refleja tanto la evolucioacuten del modelo empresarial global y el eacutenfasis en la conectividad loacutegica donde los usuarios obtienen acceso a los recursos que necesitan y el operador de la red provee las rutas de conexioacuten y asigna el ancho de banda necesario a fuentes de traacutefico muy diferentes (voz datos viacutedeo) Aquellos que construyen y operan redes deben volver los ojos a las capacidades de la tecnologiacutea ATM ya que aspiran a la maacutegica combinacioacuten interconectividad global - escalabilidad de tecnologiacuteas y satisfaccioacuten del cliente local

BIBLIOGRAFIA

1 CCITT Rec I362 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 vol2 No8 ATM Testing crosses network boundaries Jim Frimmel

6 Newslink Alcatel Telecomrsquos customer magazine Vol IV No4 4th Quarter 1996 Adapting Networks to the Internet Challenge Krish Prabhu

Trabajo realizado por

Ivan Dario Cruz PradaNicruz[arroba]col1telecomcomco

Revisioacuten y Clasificacioacuten de Protocolos para Redes de Tecnologiacutea ATM

Joseacute Luis Gonzaacutelez-Saacutenchez y Jordi Domingo-Pascual

ResumenLa tecnologiacutea 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 investigacioacuten maacutes activo con la aspiracioacuten 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 asiacute como las caracteriacutesticas multicast la escalabilidad y la fiabilidad Se profundiza en el concepto de protocolo nativo ATM y son introducidos los protocolos maacutes importantes que satisfacen este importante requerimiento (N3 CONGRESS y kStack entre otros) Es importante destacar tambieacuten los protocolos de transporte pensados especiacuteficamente para la tecnologiacutea ATM La caracteriacutestica multicast (multipoint-to-multipoint) es una de las que maacutes esfuerzo estaacute costando garantizar a ATM pero existen ya propuestas que permiten la comunicacioacuten fiable a elevados anchos de banda y entre muacuteltiples emisores y receptores (SMART MCMP o MWAX) El artiacuteculo concluye con las investigacioness maacutes novedosas en torno a los protocolos ATM como las iniciativas que proponen redes ATM programables o activas (active networks) usando agentes moacuteviles

1-Introduccioacuten y motivacionesLa actual demanda de aplicaciones relacionadas con informacioacuten multimedia como son la video-conferencia audio-conferencia video bajo demanda (VoD) o sistemas colaborativos (pizarras compartidas teletrabajo telemedicina etc) y su coexistencia con aplicaciones maacutes claacutesicas (bases de datos transferencias de ficheros WWW etc) requiere tecnologiacuteas de comunicaciones capaces de ofrecer elevadas prestaciones Estas elevadas prestaciones estaacuten directamente relacionadas con la calidad de servicio (QoS) y concretamente con conceptos claramente parametrizables como el ancho de banda y la velocidad de transmisioacuten (throughput) el retardo de las transferencias (delay) la variabilidad en el retardo (jitter) la fiabilidad (reliability) de las transmisiones las caracteriacutesticas de multidifusioacuten a grupos dispersos de usuarios (multicast) y la posibilidad de gestionar muacuteltiples clases de servicio o flujos de informacioacuten en redes multiclass Para que las nuevas tecnologiacuteas en comunicaciones puedan ofrecer estas caracteriacutesticas es necesario revisar potenciar y ampliar las actuales arquitecturas servicios y protocolosde comunicaciones En los uacuteltimos dos o tres antildeos las investigaciones en el campo de ATM estaacuten dado lugar a importantes propuestas cuyo principal objetivo es ofrecer a las aplicaciones demandadas actualmente algunas o todas las caracteriacutesticas citadas anteriormente Presentamos en este trabajo los conceptos y propuestas maacutes novedosas en el contexto de ATM para ayudar al lector interesado en el dinaacutemico complejo y sofisticado campo de los protocolos de comunicaciones Realizamos la revisioacuten de algunos de los maacutes importantes conceptos teacutecnicas ideas y mecanismos en protocolos de altas prestaciones para redes de tecnologiacutea ATM El principal objetivo de este documento es ofrecer una actualizada visioacuten general no extensiva ni profunda de los protocolos propuestos y en desarrollo para dotar a las diversas clases de servicio ATM de las citadas caracteriacutesticas de calidad de servicio que aporten las potenciales elevadas prestaciones que la tecnologiacutea ATM es capaz de ofrecer El resto del documento estaacute estructurado de la siguiente forma La seccioacuten 2 revisa el concepto de protocolo nativo centrado en el contexto de las redes ATM La seccioacuten 3 describe las propuestas maacutes interesantes actualmente en materia de protocolos de transporte El apartado 4 comenta las transferencias multicast como un importante objetivo para una tecnologiacutea orientada a la conexioacuten como es ATM Concluimos en la seccioacuten 5 con los campos de investigacioacuten abiertos recientemente como son las redes activas y los procolos booster

2- Protocolos nativos ATM

Las aplicaciones nativas ATM estaacuten especiacuteficamente pensadas para usar la tecnologiacutea ATM y para explotar al maacuteximo sus especiales caracteriacutesticas Los protocolos nativos se encargan por tanto de ofrecer esas caracteriacutesticas intriacutensecas de las redes de tecnologiacutea ATM (soporte de QoS sentildealizacioacuten direccionamiento etc) a las aplicaciones nativas ATM (VoD pizarras compartidas video-conferencia) No obstante existen tambieacuten activas investigaciones para conseguir soportar sobre redes ATM aplicaciones no nativas ATM desarrolladas para otras tecnologiacuteas (IP Frame Relay SMDS) En [1] el termino native ATM services define servicios ATM especiacuteficos 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 adaptacioacuten (AALs) Disponibilidad de circuitos virtuales conmutados (SVCs) y circuitos virtuales permanentes (PVCs) Consideraciones relativas a la gestioacuten de traacutefico (clases de servicio garantiacuteas de QoS etc) Posibilidad de distribucioacuten de conexiones y de participacioacuten local en la administracioacuten de la red (protocolos ILMI y OAM)

El propoacutesito de los servicios nativos ATM es ofrecer el acceso a las clases de servicio o a las caracteriacutesticas de QoS en redes ATM Estos servicios nativos tambieacuten ofrecen soporte a un amplio y heterogeacuteneo rango de flujos con diversas propiedades y requerimientos recomendados en [1] Los protocolos de transferencia nativos ATM gestionan la sentildealizacioacuten UNI para establecer los SVCs configurar PVCs y mapear los perfiles de QoS en la correspondiente clase de servicio Los protocolos nativos tambieacuten realizan funciones claacutesicas como las de transporte mecanismos de control de errores transferencia de datos y controles de flujo y de congestioacuten En la referencia [1] se especifica la definicioacuten semaacutentica de los servicios y consideramos que es uacutetil contrastar esta semaacutentica con las redes ATM actuales que usan TCP como capa de transporte e IP-over-ATM como capa de red planteamiento por otro lado poco adecuado [2] por las siguientes razones

Las redes IP no garantizan la QoS extremo-extremo ofrecida por las redes ATM a circuitos individuales IP multiplexa muacuteltiples conexiones de transporte con distintos requerimientos de QoS en VCs simples TCP no soporta ceacutelulas RM (Resource Management) ABR y por consiguiente no puede usar directamente las garantiacuteas de QoS ofrecidas por la red ATM Adaptation Layer 5 (AAL5) realiza labores de checksum para detectar corrupcioacuten de datos TCP tambieacuten realiza estas labores (redundantes con AAL5) costosas en overhead (cada byte de un paquete debe ser chequeado) TCPIP son la representacioacuten de un grupo de protocolos bastante maacutes 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] Ademaacutes 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 tecnologiacutea ATM y tambieacuten existen antiguas y no nativas aplicaciones Este escenario implica cambiar las aplicaciones o proponer nuevas pilas de protocolos nativos ATM La encapsulacioacuten consecutiva de paquetes genera problemas de overhead y funciones redundantes como se ha argumentado anteriormente La limitacioacuten de recursos en los sistemas finales es otra importante motivacioacuten 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 puacuteblicos disfrutan tambieacuten de estas ventajas ATM RDSI y la telefoniacutea ofrecen un esquema de direccionamiento universal basado en NSAPE164 el cual es capaz de enrutar traacutefico de forma nativa Por tanto aunque ATM dispone de protocolos nativos con direccionamiento intriacutenceso estructurado y jeraacuterquico eacuteste no es aprovechado por las aplicaciones que estaacuten 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 tambieacuten existen importantes investigaciones en torno a los protocolos nativos ATM En esta seccioacuten se muestran las propuestas maacutes importantes y actuales en materia de protocolos nativos ATM[2] [7] [8] [9] [10] [11] [12] que a su vezestaacuten sirviendo de base para nuevas investigaciones

[8] presentan el disentildeo implementacioacuten y comportamiento de una pila en modo nativo ATM y contrasta la semaacutentica 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 automaacuteticamente los siguientes problemas

IP-over-ATM no ofrece garantiacutea de QoS pues sus aplicaciones soacutelo ven la interfaz IP El nuacutecleo 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 sentildealizacioacuten 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 caracteriacutesticas la entrega fiable y no fiable de datos con control de flujo Este protocolo de transporte es ampliado en la seccioacuten 5 [2] presenta N3 (Native Non-broadcasting medium access Networking) un protocolo de transporte ligero y nativo ATM La pila N3 se ha disentildeado 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 ademaacutes aporta otras importantes novedades Los principales componentes de N3 incluyen una API sockets ATM nativa un protocolo de transporte ATM y un servicio de nombres ATM (Fig2) El protocolo de transporte ATM propuesto en [2] ofrece soporte para tres diferentes tipos de servicio entrega garantizada (mecanismos de retransmisioacuten) 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 congestioacuten de la transferencia de datagramas y de la multiplexacioacuten 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 maacutes importante El Flow Management se responsabiliza de manipular los flujos de datos desde y hasta la red viacutea la interfaz AAL La segmentacioacuten el reensamblado y el control de errores es tambieacuten 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 congestioacuten y de flujo extremo-extremo maacutes complejo

[7] describe la semaacutentica de una pila de protocolos y explora una nueva arquitectura de protocolo adaptada a la tecnologiacutea ATM y a las aplicaciones multimedia El disentildeo estaacute basado en tres principios baacutesicos separacioacuten de flujos de control y de datos minimizacioacuten del overhead y de la duplicidad de funciones y acceso de las aplicaciones al nivel ATM con garantiacuteas 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-over-ATM 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 moacutedulo CNTL abre una conexioacuten de sentildealizacioacuten con el dispositivo ATM y establece una gestioacuten de las llamadas de mensajes de configuracioacuten PF_ATM separa flujos de datos y de control para aliviar el liacutemite de comportamiento en las comunicaciones Esto permite a los mecanismos de control de traacutefico ser raacutepidos y sencillos mientras los mecanismos de control pueden ser tan complicados como sea necesario Esta separacioacuten permite tambieacuten que los dispositivos puedan estar en los puntos finales de una conexioacuten La interfaz PF_ATM da a las aplicaciones acceso directo a la capa de enlace ATM y extiende las garantiacuteas de QoS a los puntos extremos de la comunicacioacuten Un segundo prototipo[7] es disentildeado e implementado con dos objetivos principales en la optimizacioacuten de la pila nativa ATM

Optimizar los caminos de datos entre los adaptadores ATM aprovechando la separacioacuten de flujos de control y de datos y la capacidad de gestioacuten de datos especiacuteficos de las conexiones de la pila ATM

Optimizar el procesamiento de overheads usando una pila de protocolos nativo ATM en lugar de UDPIP

[11] introduce CONGRESS (CONnection oriented Group-address RESolution Service) otro eficiente protocolo nativo ATM para la resolucioacuten y gestioacuten 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 disentildeo basado en los dos siguientes principios

Disentildeo jeraacuterquico los servicios del protocolo son ofrecidos a las aplicaciones por muacuteltiples servidores organizados jeraacuterquicamente No inundacioacuten se evita la inundacioacuten 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 implementacioacuten sobre Unix y Windows NT estaacute 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 antildeadido un moacutedulo que monitoria la QoS extremo-a-extremo

3- Protocolos de transporte para redes ATMEn los dos o tres uacuteltimos antildeos ha habido numerosos e interesante intentos por disentildear protocolos de transporte La referencia [10] presenta un completo y ya claacutesico resumen de las propuestas maacutes interesantes en materia de protocolos de transporte para redes de alta velocidad (mayoritariamente IP en el artiacuteculo) Ademaacutes la referencia [13] ofrece una interesante visioacuten de las caracteriacutesticas maacutes importantes en los protocolos de elevada velocidad Son estudiadas tambieacuten diversas arquitecturas de protocolos y varias teacutecnicas de implementacioacuten Los protocolos de transporte de elevada velocidad son fuente de activas investigaciones y estaacuten en constante evolucioacuten desde hace maacutes de dos deacutecadas 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 aacutembito de las comunicaciones que ha recibido mayor atencioacuten es la capa de transporte la cuarta capa del OSI-RM de los protocolos de comunicaciones TCP e ISO TP4 son los dos maacutes populares protocolos de transporte Pero centraacutendonos maacutes concretamente en el aacutembito de ATM la literatura presenta varios protocolos de transporte y arquitecturas para redes de alta velocidad revisadas resumidamente a continuacioacuten [7] ofrece una excelente y didaacutectica arquitectura de pila de protocolos para aplicaciones multimedia en modo nativo ATM Esta arquitectura de protocolo ha sido ya descrita brevemente en la seccioacuten anterior [8] presentan el disentildeo implementacioacuten 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 estaacute formada por tres entidades principales aplicacioacuten sentildealizacioacuten y transporte La siguiente Tabla 1 muestra un conjunto de nueve baacutesicos 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 combinacioacuten de servicios La marca X indica el servicio baacutesico soportado en cada clase de servicio general

Clases de servicio

Servicios Servicio de comportamiento

garantizado

Servicio fiable Servicio Best effort

- Transferencia Simplex de datos

X X X

- Control de errores - deteccion de errorestimeouts retransmisiones

No existente (ofrecido por

AAL5)

- Bucle abierto - Control de flujo realimentado

No existente -

- X

- No existente

- Tamantildeo de mensaje ilimitado

X X X

- Eleccioacuten de blocking - Aplicacioacuten Non-blocking

X X

X X

X X

- Eleccioacuten de byte stream - Semaacutentica transferencia de mensajes

X X

X X

X X

- Garantiacuteas de QoS requerimientos de ancho de banda

No soportado No soportado

- Reserva de recursos X No existente No existente

- Transferencias Multicast X No soportado Para servicios no fiables

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 recuperacioacuten de peacuterdidas del protocolo estaacutendar SSCOP [14] y demuestran que el resultado ofrece baja latencia eficiente recuperacioacuten de ceacutelulas perdidas y es tan robusto como el estaacutendar SSCOP

4- Protocolos multipointEl crecimiento de las redes ATM viene motivado en parte por la demanda de servicios multimedia para grupos dispersos de usuarios El traacutefico multicast tiene caracteriacutesticas particulares descritas para ATM en UNI 40 [6] y anteriores [5] La distribucioacuten de informacioacuten punto-a-multipunto (uno-a-muchos) o multipunto-a-multipunto (muchos-a-muchos) es un objetivo baacutesico propuesto por varios protocolos y arquitecturas ATM que ofrecen el soporte multimedia yo multicast como audio-conferencia video-conferencia trabajos colaborativos o VoD ATM es auacuten una tecnologiacutea emergente disentildeada 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 30) para ATM define conexiones punto-a-multipunto y las conexiones multipunto-a-multipunto soacutelo 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 topologiacutea completamente mallada todos-con-todos Aunque esta topologiacutea ofrece conexiones multipunto-a-multipunto hay que destacar que no escala bien cuando el nuacutemero de participantes es elevado Una alternativa al anterior esquema es el uso de un servidor que actuacutea a modo de raiacutez en el aacuterbol multipunto Este meacutetodo soacutelo requiere un nodo raiacutez para almacenar informacioacuten pero la desventaja de este meacutetodo son las potenciales congestiones en el servidor

cuando debe encargarse de enviacuteos y retransmisiones de las conexiones multipunto-a-multipunto

Para solventar las limitaciones de UNI 30 y UNI 31 [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 sentildealizacioacuten ATM (UNI 31 UNI 40) [4][5][6] Comenzamos destacando la referencia [16] como un reciente trabajo que revisa y compara los protocolos de transporte multicast maacutes importantes en Internet como MTP-2 XTP RTP SRM RAMP RMTP MFTP STORM etc IETF e IRTF (como ITU-T y ATM Forum) tambieacuten impulsan una importante actividad en este campo La referencia [16] revisa los maacutes representativos protocolos multicast y los clasifica de acuerdo a la taxonomiacutea de varias caracteriacutesticas (propagacioacuten de datos mecanismos de fiabilidad retransmisiones control de congestioacuten y de flujo gestioacuten de grupos multicast etc) En Internet los mecanismos efectivos de control de congestioacuten son una de las prioridades en las investigaciones de las transferencias multicast fiables Los mecanismos de seguridad y las teacutecnicas escalables de recuperacioacuten 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 maacutes importantes caracteriacutesticas En esta seccioacuten 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 maacutes interesantes en los siguientes paacuterrafos SMART (shared many-to-many ATM reservations)[3] es un protocolo para controlar un aacuterbol ATM multicast compartido soportando comunicaciones muchos-a-muchos (many-to-many) Esta propuesta tiene importantes caracteriacutesticas como que reside completamente en la capa ATM y no requiere ninguacuten servidor soporta uno o varios VCCs (y tambieacuten VPCs) cuyo nuacutemero es libremente configurado y es independiente del nuacutemero de puntos finales usa el concepto de bloques de datos como en la clase de servicio ABT y tambieacuten permite VCCs de las clases CBR VBR o UBR el protocolo garantiza que no existen puntos de interrelacioacuten en los VCC del aacuterbol son respetadas las garantiacuteas del contrato de traacutefico asociado con los VCCs etc SMART puede ser entendido como un protocolo completamente distribuido para coordinar la distribucioacuten de VPIsVCIs 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 ceacutelulas de datos desde diferentes fuentes pueden llegar intercaladas a un destinatario) y tambieacuten Demand Sharing (los recursos asignados a conexiones muchos-a-muchos son dinaacutemicamente compartidas entre todas las potenciales fuentes El artiacuteculo [3] describe el protocolo SMART formal e informalmente y propone completas pruebas de correccioacuten y un detallado anaacutelisis de comportamiento para estudios futuros Tambieacuten son sugeridas otras investigaciones como son ofrecer justicia en los accesos a los aacuterboles multicast investigar las ceacutelulas RM perioacutedicamente para aliviar las congestiones en la red o disminuir el tiempo de acceso del usuario a los aacuterboles de distribucioacuten multicast anaacutelisis de las ceacutelulas RM dentro de cada VCC o fuera enviando todas las ceacutelulas RM en un VCC dedicado En [17] se presenta MWAX un algoritmo dinaacutemico 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 artiacuteculo describe un esquema jeraacuterquico basado en CBT para incorporar routing multipunto-a-multipunto en PNNI En el algoritmo los nodos core actuacutean como participantes pasivos para eliminar la dependencia en la seleccioacuten de estos nodos Con un mecanismo de backup se consigue un algoritmo tolerante a fallos en los nodos core lo cual puede ser faacutecilmente 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 jerarquiacutea SEAM (Scalable and Efficient ATM Multicast) [18] propone una arquitectura escalable eficiente y multicast multipunto-a-multipunto para redes ATM que usa un soacutelo VC para un grupo multicast de muacuteltiples 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 Tambieacuten realiza aportaciones para conseguir soportar IP multicast sobre redes ATM extensas

SEAM usa un soacutelo aacuterbol de distribucioacuten 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 sentildealizacioacuten del grupo Este trabajo deja abiertas investigaciones referentes a la gestioacuten de traacutefico y a la entrega fiable de traacuteficos multicasting Concluimos esta seccioacuten destacando MCMP (Multiparty Conference Management Protocol) [19] que sin estar pensado especiacuteficamente para ATM es un protocolo de nivel sesioacutentransporte distribuido extremo-extremo y desarrollado para gestioacuten de grupos de aplicaciones de conferencia MCMP es un conjunto de algoritmos de control distribuido para configuracioacuten de conferencias multipunto y gestioacuten de miembros de grupos de usuarios Conceptualmente MCMP reside en el nivel de sesioacuten en el que se establece la infraestructura para activar la transferencia de informacioacuten entre los participantes en la conferencia Pero funcionalmente el protocolo acompasa los niveles de sesioacuten y de transporte pues utiliza directamente servicios del nivel de red Son destacables las condiciones de correccioacuten (conectividad validacioacuten unicidad consistencia y terminacioacuten) que deben ser satisfechas una vez que la conferencia ha sido configurada por el algoritmo de configuracioacuten de MCMP El artiacuteculo muestra exhaustivas pruebas de correccioacuten para uno de los algoritmos y tambieacuten describe la especificacioacuten y verificacioacuten del protocolo

5- Nuevos campos de investigacioacutenEn todas las redes existen gran variedad de elementos hardware (switchs routers bridges brouters hubs ETDs etc) que realizan muy diversas funciones (conmutacioacuten routing puenteo controles de congestioacuten y de flujo garantiacutea de QoS ejecucioacuten de aplicaciones etc) En la actualidad la red es mayormente un canal de comunicacioacuten para transferir paquetes entre equipos finales (ayudada por los elementos hardware antes citados) Pero tambieacuten se estaacuten realizando importante esfuerzos para equipar a los elementos hardware con elevadas prestaciones aportadas por diversas teacutecnicas software Esto dota a la red de caracteriacutesticas activas (active networks) en el sentido de que los elementos hardware que la componen computan modifican u operan los contenidos de los paquetes y tambieacuten seraacuten capaces de transferir o propagar coacutedigo Por consiguiente una red activa es una red programable [20] es una excelente revisioacuten de este novedoso campo de investigacioacuten que discute dos planteamientos en la realizacioacuten de redes activas la idea del conmutador programable y la de la caacutepsula Una red es activa si en sus aacuterboles de distribucioacuten multicast existen nodos activos con capacidad para ejecutar programas yo capaces de implementar mecanismos de propagacioacuten de coacutedigo Algunas de las ventajas de los protocolos activos son conseguidas instalando nodos activos en puntos estrateacutegicos de la red Otro nuevo concepto es presentado en [21] como una metodologiacutea para el disentildeo de protocolos Los protocol boosters son una nueva contribucioacuten a las redes activas o programables Una ventaja de los boosters es que pueden ser faacutecilmente 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 aacuterea extensa Este papel introduce una arquitectura software orientada a agente y propone el concepto de agente de comunicacioacuten para servicio de comunicacioacuten 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 artiacuteculo muestra agentes software moacuteviles usados para implementar operaciones robustas y funciones de mantenimiento en redes ATM Los agentes desempentildean un rol similar al de las ceacutelulas OAM en ATM estaacutendar pues son transmitidos entre entidades de control a intervalos regulares usando recursos predefinidos La diferencia entre los agentes moacuteviles y las ceacutelulas OAM reside en que eacutestos pueden contener coacutedigo Para concluir destacar que la integracioacuten del traacutefico IP sobre tecnologiacutea ATM es tambieacuten uno de los campos maacutes activos en la actualidad En esta liacutenea pueden destacarse los siguientes protocolos IP-over-ATM IP Switching Tag Switching NHRP MPOA IMSS CSR ARIS AREQUIPARED y EPD Referencias

1 ____ Native ATM Service Semantic Description Version 1 ATM Forum Technical Committee ATM Forum Document af-saa-0048000 (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 Broadband Networks Multimedia Applications Services and Techniques ECMASTrsquo98 Springer (May 1998)

3 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 Nordm 3 (April 1997)

4 W D Zhong K Yukimatsu Design requeriments and architectures for multicast ATM switching IEICE Trans Com Vol E77-B pp 1420-1428 (Nov 1994)

5 ____ ATM user-network interface version 31 specification ATM Forum (1994)

6 ____ Traffic Management Specification Version 40 ATM Forum Technical Committee ATM Forum Document af-tm-0056000 (April 1996)

7 D Kandlur D Saha and W Willebeck Protocol Architecture for multimedia Application over ATM Networks IEEE Journal Selected and Communications Vol 14 Nordm 7 pp 1349-1359 (Sep 1996)

8 R Ahuja S Keshav and H Saran Design Implementation and Performance Measurement of a Native-Mode ATM Transport Layer (Estended Version) IEEEACM Transactions on Networking Vol 4 Nordm 4 (Aug 1996)

9 R Karabek A Native ATM Protocol Architecture Design and Performance Evaluation IEEE Proceedings 22nd Annual Conference on Local Computer Networks pp 204-210 (1997)

10 D C Feldmeier A framework of architectural concepts for high-speed communications systems IEEE J Select Areas CommunVol11 Nordm 4 (May 1993)

11 T Anker D Breitgand D Dolev Z Levy Congress CONnection-oriented Group-address RESolution Service Proceeding of SPIE97 vol 3233 on Broadband Networking Technologies Nov (1997)

12 kStack httpcometcolumbiaedusoftwarekStack

13 T La Porta and M Schwartz Architectures Features and Implementation of High-Speed Transport Protocols IEEE Network Magazine pp 14-22 (May 1991)

14 ____ B-ISDN ATM Adaptation Layer Service Specific Connection Oriented Protocol (SSCOP) Q2110 ITU-T (10-Mar 1994)

15 J Soleacute-Pareta J Vila-Sallent Network-based paralell computing over ATM using improved SSCOP protocol Computer Communications 19 pp 915-926 (1996)

16 K Obraczka Multicast Transport Protocols A survey and Taxonomy IEEE Communi Magazine (1998)

17 R Venkateswaran CS Raghavendra X Chen and VP Kumar A Scalable Dynamic Multicast Routing Algorithm in ATM Networks IEEE pp 1361-1365 (1997)

18 Matthias Grossglauser and KK Ramakrishnan SEAM Scalable and Efficient ATM Multicast IEEE 1997 pp 867-875 (1997)

19 M Nguyen and M Schwartz MCMP A Transportsession level Distributed Protocol for Desktop Conference Setup IEEE Journal Selected and comunications Vol 14 Nordm 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 Nordm 3 pp 437-443 (April 1998)

22 R Kishimoto Agent communication system for multimedia communication services INFOCOMrsquo96 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 Nordm 3 pp 414-423 (April 1998)

  • ATM - Modo de Transferencia Asiacutencrona
  • Revisioacuten y Clasificacioacuten de Protocolos para Redes de Tecnologiacutea ATM
    • Resumen
    • 1-Introduccioacuten y motivaciones
    • 2- Protocolos nativos ATM
    • 3- Protocolos de transporte para redes ATM
    • 4- Protocolos multipoint
    • 5- Nuevos campos de investigacioacuten
      • Referencias
Page 5: Atm

Las celdas son transmitidas serialmente y se propagan en estricta secuencia numeacuterica a traveacutes de la red El tamantildeo 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 viacutedeo y protocolos sensibles al retardo A pesar de que no se disentildeoacute especiacuteficamente para eso la longitud de la celda ATM acomoda convenientemente dos Fast Packets IPX de 24 bytes cada uno Los comiteacutes de estaacutendares 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 aacuterea 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 puacuteblico (carrier) Especiacuteficamente la funcioacuten 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 conmutacioacuten de las celdas ATM

La capa de adaptacioacuten de ATM

La tercer capa es la ATM Adaptation Layer (AAL) La AAL juega un rol clave en el manejo de muacuteltiples tipos de traacutefico 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 maacutes altas tales como emulacioacuten de circuitos (circuit emulation) viacutedeo 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 estaacuten definidos actualmente La capa de Adaptacioacuten de ATM yace entre el ATM layer y las capas maacutes altas que usan el servicio ATM Su propoacutesito principal es resolver cualquier disparidad entre un servicio requerido por el usuario y atender los servicios disponibles del ATM layer La capa de adaptacioacuten introduce la informacioacuten en paquetes ATM y controla los errores de la transmisioacuten La informacioacuten transportada por la capa de adaptacioacuten se divide en cuatro clases seguacuten las propiedades siguientes

1 Que la informacioacuten que esta siendo transportada dependa o no del tiempo 2 Tasa de bit constantevariable 3 Modo de conexioacuten

Estas propiedades definen ocho clases posibles cuatro se definen como B-ISDN Clases de servicios La capa de adaptacioacuten 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 adaptacioacuten 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 informacioacuten en la cabecera y en el payload depende de la clase de informacioacuten que va a ser transportada

2)Capa de Segmentacioacuten 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 informacioacuten necesaria para el reensamblaje en el destino La figura siguiente aporta una mejor comprensioacuten 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 tamantildeo de la celda ATM para su transmisioacuten Tambieacuten realiza la funcioacuten inversa (reemsamblado) para las unidades de informacioacuten de orden superior Cada porcioacuten es ubicada en su propia unidad de protocolo de segmentacioacuten 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 informacioacuten que regule el tiempo con los datos AAL-1 provee recuperacioacuten de errores e indica la informacioacuten con errores que no podraacute ser recuperada

Capa de convergencia

Las funciones provistas a esta capa difieren dependiendo del servicio que se proveyoacute Provee la correccioacuten de errores

Capa de segmentacioacuten y reensamblaje

En esta capa los datos son segmentados y se les antildeade una cabecera La cabecera contiene 3 campos (ver diagrama)

Nuacutemero de secuencia usado para detectar una insercioacuten o perdida de un paquete Nuacutemero de secuencia para la proteccioacuten usado para corregir errores que ocurren en el

numero de secuencia Indicador de capa de convergencia usado para indicar la presencia de la funcioacuten de la capa

de convergencia

ALL 2

AAL-2 se usa para transferir datos con tasa de bits variable que dependen del tiempo Enviacutea la informacioacuten del tiempo conjuntamente con los datos para que esta puede recuperarse en el destino AAL-2 provee recuperacioacuten de errores e indica la informacioacuten que no puede recuperarse

Capa de convergencia

Esta capa provee para la correccioacuten de errores y transporta la informacioacuten del tiempo desde el origen al destino

Capa de segmentacioacuten y recuperacioacuten

El mensaje es segmentado y se le antildeade 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 informacioacuten es

o BOM comenzando de mensaje o COM continuacioacuten de mensaje o EOM fin de mensaje o indica que el paquete contiene informacioacuten de tiempo u

otra

El payload tambieacuten 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 disentildea para transferir los datos con tasa de bits variable que son independientes del tiempo AAL-3 puede ser dividido en dos modos de operacioacuten

1 Fiable En caso de perdida o mala recepcioacuten de datos estos vuelven a ser enviados El control de flujo es soportado

2 No fiable La recuperacioacuten 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 comuacuten de la capa de convergencia Esto es provisto tambieacuten por el AAL-2 CS Antildeade una cabecera y un payload a la parte comuacuten (ver diagrama)

La cabecera contiene 3 campos Indicador de la parte comuacuten que dice que el payload forma parte de la parte comuacuten Etiqueta de comienzo que indica el comienzo de la parte comuacuten de la capa de

convergencia Tamantildeo del buffer que dice al receptor el espacio necesario para acomodar el mensaje

El payload tambieacuten contiene 3 campos Alineacioacuten 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 comuacuten de la CS(capa de convergencia) El campo de longitud tiene la longitud de la parte comuacuten de la CS

1 Parte especifica del servicio Las funciones proveiacutedas en esta que capa dependen de los servicios pedidos Generalmente se incluyen funciones para la recuperacioacuten y deteccioacuten de errores y puede incluir tambieacuten funciones especiales

Capa de segmentacioacuten y reensamblaje

En esta capa los datos son partidos en paquetes de ATM Una cabecera y el payload que contiene la informacioacuten necesaria para la recuperacioacuten de errores y reensamblaje se antildeaden 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 Continuacioacuten de mensaje EOM Fin de mensaje SSM Mensaje uacutenico en el segmento

2) Numero de secuencia usado para detectar una insercioacuten o una perdida de un paquete 3) Identificador de multiplexacioacuten Este campo se usa para distinguir datos de diferentes comunicaciones que ha sido multiplexadas en una uacutenica conexioacuten de ATM El payload contiene dos de campos 1) Indicado de longitud que indica el nuacutemero de bytes uacutetiles en un paquete parcialmente lleno 2) CRC es para el control de errores

ALL 4

AAL-4 se disentildea para transportar datos con tasa de bits variable independientes del tiempo Es similar al AAL3 y tambieacuten puede operar en transmisioacuten fiable y o fiable AAL-4 provee la capacidad de transferir datos fuera de una conexioacuten expliacutecita

AAL 2 AAL 34 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 traacutefico de redes de aacuterea local (LAN) AAL 2 y AAL 3 soportan paquetes orientados a conexioacuten (Ver figura No5)

(El teacutermino orientado a conexioacuten describe la transferencia de datos despueacutes 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 jamaacutes vean estos errores reportados la degradacioacuten de respuesta o de caudal (through put) seriacutean los uacutenicos siacutentomas A diferencia de los mecanismos de control extremo a extremo que utiliza TCP en internerworking la capacidad de Gbitseg de la red ATM genera un juego de requerimientos necesarios para el control de flujo Si el control del flujo se hiciese como una realimentacioacuten del lazo extremo a extremo en el momento en que el mensaje de control de flujo arribase a la fuente eacutesta habriacutea transmitido ya algunos Mbytes de datos en el sistema exacerbando la congestioacuten Y en el momento en que la fuente reaccionase al mensaje de control la condicioacuten de congestioacuten hubiese podido desaparecer apagando innecesariamente la fuente La constante de tiempo de la realimentacioacuten extremo a extremo en las redes ATM (retardo de realimentacioacuten por producto lazo - ancho de banda) debe ser lo suficientemente alta como para cumplir con las necesidades del usuario sin que la dinaacutemica de la red se vuelva impractica Las condiciones de congestioacuten en las redes ATM estaacuten previstas para que sean extremadamente dinaacutemicas requiriendo de mecanismos de hardware lo suficientemente raacutepidos para llevar a la red al estado estacionario necesitando que la red en siacute eacuteste activamente involucrada en el raacutepido establecimiento de este estado estacionario Sin embargo esta aproximacioacuten simplista de control reactivo de lazo cerrado extremo a extremo en condiciones de congestioacuten no se considera suficiente para las redes ATM El consenso entre los investigadores de este campo arroja recomendaciones que incluyen el empleo de una coleccioacuten de esquemas de control de flujo junto con la colocacioacuten adecuada de los recursos y dimensionamiento de las redes para que aunados se pueda tratar y evadir la congestioacuten ya sea

Detectando y manipulando la congestioacuten que se genera tempranamente monitoreando de cerca las entradassalidas que estaacuten dentro de los conmutadores ATM y reaccionando gradualmente a medida que vaya arribando a ciertos niveles prefijados Tratando y controlando la inyeccioacuten de la conexioacuten de datos dentro de la red en la UNI (unidad interfaz de red) de tal forma que su tasa de inyeccioacuten sea modulada y medida alliacute primero antes de tener que ir a la conexioacuten de usuario a tomar acciones mas draacutesticas El estado de la red debe ser comunicado a la UNI generando raacutepidamente una celda de control de flujo siempre que se vaya a descartar una celda en alguacuten nodo debido a congestioacuten La UNI debe entonces manejar la congestioacuten cambiando su tasa de inyeccioacuten

o notificaacutendola a la conexioacuten de usuario para que cese el flujo dependiendo del nivel de severidad de la congestioacutenEl mayor compromiso durante el control de congestioacuten es el de tratar y afectar solo a los flujos de conexioacuten que son responsables de la congestioacuten y actuar de forma transparente frente a los flujos que observan buen comportamiento Al mismo tiempo permitir que el flujo de conexioacuten utilice tanto ancho de banda como necesite sino hay congestioacuten La recomendacioacuten UIT - T I 371 especifica un contrato de traacutefico que define como el traacutefico del usuario seria administrado El contrato que existe para cada conexion virtual (virtual path o virtual channel) es baacutesicamente un acuerdo entre el usuario y la red con respecto a la Calidad de Servicio (Quality Of Service - Q o S) y los paraacutemetros que regulan el flujo de celdas Estos descriptores de trafico dependen de una particular clase de servicio y pueden incluir bajo la especificacioacuten del ATM Forum UNI a cinco Q o S referenciados en los AALS El objetivo de estas sub clases de servicio es agrupar caracteriacutesticas 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 paraacutemetros pueden incluir el Sustained Cell Rate (SCR) el Miacutenimum Cell Rate (MCR) el Peak Cell Rate (PCR) yo el Burst Tolerance (BT) Para soportar todas las diferentes clases de servicios definidos por los estaacutendares el switch ATM debe ser capaz de definir eacutestos paraacutemetros en base a cada VC o cada VP y debe proveer amortiguadores (buffers) para absorber las raacutefagas de trafico

INTEROPERABILIDAD ENTRE FRAME RELAY Y ATM El objetivo final para todos los servicios descritos anteriormente es una migracioacuten suave de Frame Relay yo SMDS a redes ATM Por ejemplo la recomendacioacuten UIT - T I555 provee un marco para la interoperabilidad de Frame Relay y ATM Para alcanzar una maacutexima eficiencia se trata de brindar este servicio de interoperabilidad en la capa maacutes baja posible mediante conversioacuten de protocolo

PRIMER ESCENARIO

Cuando el servicio de Frame Relay es dado sobre la RDSI en banda ancha y los usuarios se conectan a traveacutes de la UNI de Frame Relay En esta solucioacuten 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 (VCVP) para enlazar los puntos de acceso Frame Relay En este esquema se puede explotar la naturaleza de orientacioacuten a conexioacuten Frame Relay (F R) siguiendo un comportamiento como

El usuario del enrutador pregunta por una conexioacuten al equipo interfaz de red El equipo interfaz de la red coloca las conexiones Frame Relay dentro de una conexioacuten ATM con las direcciones destino apropiadas Por cada trama de equipo interfaz de red traslada de la conexioacuten de Frame Relay a la ATM y viceversa La conexioacuten ATM esta desocupada cuando no se necesitaPara lograr este uacuteltimo punto el manejo de la poliacutetica de conexion del VC sera un aspecto crucial para el desempentildeo de este procedimiento Resulta difiacutecil de terminar el procedimiento para manejar un VC cuando la fuente de traacutefico es no orientada a conexioacuten 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 conexioacuten 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 opcioacuten se toma ventaja del uso actual del FR el cual es proveer un mallado virtual entre diferentes sitios para cargar traacutefico no orientado a conexioacuten 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 conmutacioacuten 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 traveacutes de sus respectivas interfaces de red (NNIs) Esto permitiriacutea a un proveedor de red manejar esta heterogeacutenea red como un todo Frame Relay provee usualmente la interconexioacuten para LAN a pesar de su natural orientacioacuten a conexioacuten 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 sobresimplificacioacuten los dos protocolos (AAL 3 y AAL 5) ofrecen basicamente el mismo servicio CPAAL (Parte Comuacuten 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 implementacioacuten y eficiencia del protocolo que incide en el costo Las caracteriacutesticas a tomar en cuenta cuyo detalle puede ser tema de otro artiacuteculo tienen que ver con Delimitacioacuten y Alineamiento de Tramas Multiplexacioacuten Deteccioacuten de errores de transmisioacuten eficiencia en la transmisioacuten 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 tecnologiacutea de red empresarial virtual del futuro un teacutermino que refleja tanto la evolucioacuten del modelo empresarial global y el eacutenfasis en la conectividad loacutegica donde los usuarios obtienen acceso a los recursos que necesitan y el operador de la red provee las rutas de conexioacuten y asigna el ancho de banda necesario a fuentes de traacutefico muy diferentes (voz datos viacutedeo) Aquellos que construyen y operan redes deben volver los ojos a las capacidades de la tecnologiacutea ATM ya que aspiran a la maacutegica combinacioacuten interconectividad global - escalabilidad de tecnologiacuteas y satisfaccioacuten del cliente local

BIBLIOGRAFIA

1 CCITT Rec I362 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 vol2 No8 ATM Testing crosses network boundaries Jim Frimmel

6 Newslink Alcatel Telecomrsquos customer magazine Vol IV No4 4th Quarter 1996 Adapting Networks to the Internet Challenge Krish Prabhu

Trabajo realizado por

Ivan Dario Cruz PradaNicruz[arroba]col1telecomcomco

Revisioacuten y Clasificacioacuten de Protocolos para Redes de Tecnologiacutea ATM

Joseacute Luis Gonzaacutelez-Saacutenchez y Jordi Domingo-Pascual

ResumenLa tecnologiacutea 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 investigacioacuten maacutes activo con la aspiracioacuten 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 asiacute como las caracteriacutesticas multicast la escalabilidad y la fiabilidad Se profundiza en el concepto de protocolo nativo ATM y son introducidos los protocolos maacutes importantes que satisfacen este importante requerimiento (N3 CONGRESS y kStack entre otros) Es importante destacar tambieacuten los protocolos de transporte pensados especiacuteficamente para la tecnologiacutea ATM La caracteriacutestica multicast (multipoint-to-multipoint) es una de las que maacutes esfuerzo estaacute costando garantizar a ATM pero existen ya propuestas que permiten la comunicacioacuten fiable a elevados anchos de banda y entre muacuteltiples emisores y receptores (SMART MCMP o MWAX) El artiacuteculo concluye con las investigacioness maacutes novedosas en torno a los protocolos ATM como las iniciativas que proponen redes ATM programables o activas (active networks) usando agentes moacuteviles

1-Introduccioacuten y motivacionesLa actual demanda de aplicaciones relacionadas con informacioacuten multimedia como son la video-conferencia audio-conferencia video bajo demanda (VoD) o sistemas colaborativos (pizarras compartidas teletrabajo telemedicina etc) y su coexistencia con aplicaciones maacutes claacutesicas (bases de datos transferencias de ficheros WWW etc) requiere tecnologiacuteas de comunicaciones capaces de ofrecer elevadas prestaciones Estas elevadas prestaciones estaacuten directamente relacionadas con la calidad de servicio (QoS) y concretamente con conceptos claramente parametrizables como el ancho de banda y la velocidad de transmisioacuten (throughput) el retardo de las transferencias (delay) la variabilidad en el retardo (jitter) la fiabilidad (reliability) de las transmisiones las caracteriacutesticas de multidifusioacuten a grupos dispersos de usuarios (multicast) y la posibilidad de gestionar muacuteltiples clases de servicio o flujos de informacioacuten en redes multiclass Para que las nuevas tecnologiacuteas en comunicaciones puedan ofrecer estas caracteriacutesticas es necesario revisar potenciar y ampliar las actuales arquitecturas servicios y protocolosde comunicaciones En los uacuteltimos dos o tres antildeos las investigaciones en el campo de ATM estaacuten dado lugar a importantes propuestas cuyo principal objetivo es ofrecer a las aplicaciones demandadas actualmente algunas o todas las caracteriacutesticas citadas anteriormente Presentamos en este trabajo los conceptos y propuestas maacutes novedosas en el contexto de ATM para ayudar al lector interesado en el dinaacutemico complejo y sofisticado campo de los protocolos de comunicaciones Realizamos la revisioacuten de algunos de los maacutes importantes conceptos teacutecnicas ideas y mecanismos en protocolos de altas prestaciones para redes de tecnologiacutea ATM El principal objetivo de este documento es ofrecer una actualizada visioacuten general no extensiva ni profunda de los protocolos propuestos y en desarrollo para dotar a las diversas clases de servicio ATM de las citadas caracteriacutesticas de calidad de servicio que aporten las potenciales elevadas prestaciones que la tecnologiacutea ATM es capaz de ofrecer El resto del documento estaacute estructurado de la siguiente forma La seccioacuten 2 revisa el concepto de protocolo nativo centrado en el contexto de las redes ATM La seccioacuten 3 describe las propuestas maacutes interesantes actualmente en materia de protocolos de transporte El apartado 4 comenta las transferencias multicast como un importante objetivo para una tecnologiacutea orientada a la conexioacuten como es ATM Concluimos en la seccioacuten 5 con los campos de investigacioacuten abiertos recientemente como son las redes activas y los procolos booster

2- Protocolos nativos ATM

Las aplicaciones nativas ATM estaacuten especiacuteficamente pensadas para usar la tecnologiacutea ATM y para explotar al maacuteximo sus especiales caracteriacutesticas Los protocolos nativos se encargan por tanto de ofrecer esas caracteriacutesticas intriacutensecas de las redes de tecnologiacutea ATM (soporte de QoS sentildealizacioacuten direccionamiento etc) a las aplicaciones nativas ATM (VoD pizarras compartidas video-conferencia) No obstante existen tambieacuten activas investigaciones para conseguir soportar sobre redes ATM aplicaciones no nativas ATM desarrolladas para otras tecnologiacuteas (IP Frame Relay SMDS) En [1] el termino native ATM services define servicios ATM especiacuteficos 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 adaptacioacuten (AALs) Disponibilidad de circuitos virtuales conmutados (SVCs) y circuitos virtuales permanentes (PVCs) Consideraciones relativas a la gestioacuten de traacutefico (clases de servicio garantiacuteas de QoS etc) Posibilidad de distribucioacuten de conexiones y de participacioacuten local en la administracioacuten de la red (protocolos ILMI y OAM)

El propoacutesito de los servicios nativos ATM es ofrecer el acceso a las clases de servicio o a las caracteriacutesticas de QoS en redes ATM Estos servicios nativos tambieacuten ofrecen soporte a un amplio y heterogeacuteneo rango de flujos con diversas propiedades y requerimientos recomendados en [1] Los protocolos de transferencia nativos ATM gestionan la sentildealizacioacuten UNI para establecer los SVCs configurar PVCs y mapear los perfiles de QoS en la correspondiente clase de servicio Los protocolos nativos tambieacuten realizan funciones claacutesicas como las de transporte mecanismos de control de errores transferencia de datos y controles de flujo y de congestioacuten En la referencia [1] se especifica la definicioacuten semaacutentica de los servicios y consideramos que es uacutetil contrastar esta semaacutentica con las redes ATM actuales que usan TCP como capa de transporte e IP-over-ATM como capa de red planteamiento por otro lado poco adecuado [2] por las siguientes razones

Las redes IP no garantizan la QoS extremo-extremo ofrecida por las redes ATM a circuitos individuales IP multiplexa muacuteltiples conexiones de transporte con distintos requerimientos de QoS en VCs simples TCP no soporta ceacutelulas RM (Resource Management) ABR y por consiguiente no puede usar directamente las garantiacuteas de QoS ofrecidas por la red ATM Adaptation Layer 5 (AAL5) realiza labores de checksum para detectar corrupcioacuten de datos TCP tambieacuten realiza estas labores (redundantes con AAL5) costosas en overhead (cada byte de un paquete debe ser chequeado) TCPIP son la representacioacuten de un grupo de protocolos bastante maacutes 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] Ademaacutes 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 tecnologiacutea ATM y tambieacuten existen antiguas y no nativas aplicaciones Este escenario implica cambiar las aplicaciones o proponer nuevas pilas de protocolos nativos ATM La encapsulacioacuten consecutiva de paquetes genera problemas de overhead y funciones redundantes como se ha argumentado anteriormente La limitacioacuten de recursos en los sistemas finales es otra importante motivacioacuten 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 puacuteblicos disfrutan tambieacuten de estas ventajas ATM RDSI y la telefoniacutea ofrecen un esquema de direccionamiento universal basado en NSAPE164 el cual es capaz de enrutar traacutefico de forma nativa Por tanto aunque ATM dispone de protocolos nativos con direccionamiento intriacutenceso estructurado y jeraacuterquico eacuteste no es aprovechado por las aplicaciones que estaacuten 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 tambieacuten existen importantes investigaciones en torno a los protocolos nativos ATM En esta seccioacuten se muestran las propuestas maacutes importantes y actuales en materia de protocolos nativos ATM[2] [7] [8] [9] [10] [11] [12] que a su vezestaacuten sirviendo de base para nuevas investigaciones

[8] presentan el disentildeo implementacioacuten y comportamiento de una pila en modo nativo ATM y contrasta la semaacutentica 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 automaacuteticamente los siguientes problemas

IP-over-ATM no ofrece garantiacutea de QoS pues sus aplicaciones soacutelo ven la interfaz IP El nuacutecleo 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 sentildealizacioacuten 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 caracteriacutesticas la entrega fiable y no fiable de datos con control de flujo Este protocolo de transporte es ampliado en la seccioacuten 5 [2] presenta N3 (Native Non-broadcasting medium access Networking) un protocolo de transporte ligero y nativo ATM La pila N3 se ha disentildeado 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 ademaacutes aporta otras importantes novedades Los principales componentes de N3 incluyen una API sockets ATM nativa un protocolo de transporte ATM y un servicio de nombres ATM (Fig2) El protocolo de transporte ATM propuesto en [2] ofrece soporte para tres diferentes tipos de servicio entrega garantizada (mecanismos de retransmisioacuten) 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 congestioacuten de la transferencia de datagramas y de la multiplexacioacuten 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 maacutes importante El Flow Management se responsabiliza de manipular los flujos de datos desde y hasta la red viacutea la interfaz AAL La segmentacioacuten el reensamblado y el control de errores es tambieacuten 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 congestioacuten y de flujo extremo-extremo maacutes complejo

[7] describe la semaacutentica de una pila de protocolos y explora una nueva arquitectura de protocolo adaptada a la tecnologiacutea ATM y a las aplicaciones multimedia El disentildeo estaacute basado en tres principios baacutesicos separacioacuten de flujos de control y de datos minimizacioacuten del overhead y de la duplicidad de funciones y acceso de las aplicaciones al nivel ATM con garantiacuteas 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-over-ATM 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 moacutedulo CNTL abre una conexioacuten de sentildealizacioacuten con el dispositivo ATM y establece una gestioacuten de las llamadas de mensajes de configuracioacuten PF_ATM separa flujos de datos y de control para aliviar el liacutemite de comportamiento en las comunicaciones Esto permite a los mecanismos de control de traacutefico ser raacutepidos y sencillos mientras los mecanismos de control pueden ser tan complicados como sea necesario Esta separacioacuten permite tambieacuten que los dispositivos puedan estar en los puntos finales de una conexioacuten La interfaz PF_ATM da a las aplicaciones acceso directo a la capa de enlace ATM y extiende las garantiacuteas de QoS a los puntos extremos de la comunicacioacuten Un segundo prototipo[7] es disentildeado e implementado con dos objetivos principales en la optimizacioacuten de la pila nativa ATM

Optimizar los caminos de datos entre los adaptadores ATM aprovechando la separacioacuten de flujos de control y de datos y la capacidad de gestioacuten de datos especiacuteficos de las conexiones de la pila ATM

Optimizar el procesamiento de overheads usando una pila de protocolos nativo ATM en lugar de UDPIP

[11] introduce CONGRESS (CONnection oriented Group-address RESolution Service) otro eficiente protocolo nativo ATM para la resolucioacuten y gestioacuten 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 disentildeo basado en los dos siguientes principios

Disentildeo jeraacuterquico los servicios del protocolo son ofrecidos a las aplicaciones por muacuteltiples servidores organizados jeraacuterquicamente No inundacioacuten se evita la inundacioacuten 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 implementacioacuten sobre Unix y Windows NT estaacute 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 antildeadido un moacutedulo que monitoria la QoS extremo-a-extremo

3- Protocolos de transporte para redes ATMEn los dos o tres uacuteltimos antildeos ha habido numerosos e interesante intentos por disentildear protocolos de transporte La referencia [10] presenta un completo y ya claacutesico resumen de las propuestas maacutes interesantes en materia de protocolos de transporte para redes de alta velocidad (mayoritariamente IP en el artiacuteculo) Ademaacutes la referencia [13] ofrece una interesante visioacuten de las caracteriacutesticas maacutes importantes en los protocolos de elevada velocidad Son estudiadas tambieacuten diversas arquitecturas de protocolos y varias teacutecnicas de implementacioacuten Los protocolos de transporte de elevada velocidad son fuente de activas investigaciones y estaacuten en constante evolucioacuten desde hace maacutes de dos deacutecadas 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 aacutembito de las comunicaciones que ha recibido mayor atencioacuten es la capa de transporte la cuarta capa del OSI-RM de los protocolos de comunicaciones TCP e ISO TP4 son los dos maacutes populares protocolos de transporte Pero centraacutendonos maacutes concretamente en el aacutembito de ATM la literatura presenta varios protocolos de transporte y arquitecturas para redes de alta velocidad revisadas resumidamente a continuacioacuten [7] ofrece una excelente y didaacutectica arquitectura de pila de protocolos para aplicaciones multimedia en modo nativo ATM Esta arquitectura de protocolo ha sido ya descrita brevemente en la seccioacuten anterior [8] presentan el disentildeo implementacioacuten 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 estaacute formada por tres entidades principales aplicacioacuten sentildealizacioacuten y transporte La siguiente Tabla 1 muestra un conjunto de nueve baacutesicos 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 combinacioacuten de servicios La marca X indica el servicio baacutesico soportado en cada clase de servicio general

Clases de servicio

Servicios Servicio de comportamiento

garantizado

Servicio fiable Servicio Best effort

- Transferencia Simplex de datos

X X X

- Control de errores - deteccion de errorestimeouts retransmisiones

No existente (ofrecido por

AAL5)

- Bucle abierto - Control de flujo realimentado

No existente -

- X

- No existente

- Tamantildeo de mensaje ilimitado

X X X

- Eleccioacuten de blocking - Aplicacioacuten Non-blocking

X X

X X

X X

- Eleccioacuten de byte stream - Semaacutentica transferencia de mensajes

X X

X X

X X

- Garantiacuteas de QoS requerimientos de ancho de banda

No soportado No soportado

- Reserva de recursos X No existente No existente

- Transferencias Multicast X No soportado Para servicios no fiables

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 recuperacioacuten de peacuterdidas del protocolo estaacutendar SSCOP [14] y demuestran que el resultado ofrece baja latencia eficiente recuperacioacuten de ceacutelulas perdidas y es tan robusto como el estaacutendar SSCOP

4- Protocolos multipointEl crecimiento de las redes ATM viene motivado en parte por la demanda de servicios multimedia para grupos dispersos de usuarios El traacutefico multicast tiene caracteriacutesticas particulares descritas para ATM en UNI 40 [6] y anteriores [5] La distribucioacuten de informacioacuten punto-a-multipunto (uno-a-muchos) o multipunto-a-multipunto (muchos-a-muchos) es un objetivo baacutesico propuesto por varios protocolos y arquitecturas ATM que ofrecen el soporte multimedia yo multicast como audio-conferencia video-conferencia trabajos colaborativos o VoD ATM es auacuten una tecnologiacutea emergente disentildeada 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 30) para ATM define conexiones punto-a-multipunto y las conexiones multipunto-a-multipunto soacutelo 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 topologiacutea completamente mallada todos-con-todos Aunque esta topologiacutea ofrece conexiones multipunto-a-multipunto hay que destacar que no escala bien cuando el nuacutemero de participantes es elevado Una alternativa al anterior esquema es el uso de un servidor que actuacutea a modo de raiacutez en el aacuterbol multipunto Este meacutetodo soacutelo requiere un nodo raiacutez para almacenar informacioacuten pero la desventaja de este meacutetodo son las potenciales congestiones en el servidor

cuando debe encargarse de enviacuteos y retransmisiones de las conexiones multipunto-a-multipunto

Para solventar las limitaciones de UNI 30 y UNI 31 [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 sentildealizacioacuten ATM (UNI 31 UNI 40) [4][5][6] Comenzamos destacando la referencia [16] como un reciente trabajo que revisa y compara los protocolos de transporte multicast maacutes importantes en Internet como MTP-2 XTP RTP SRM RAMP RMTP MFTP STORM etc IETF e IRTF (como ITU-T y ATM Forum) tambieacuten impulsan una importante actividad en este campo La referencia [16] revisa los maacutes representativos protocolos multicast y los clasifica de acuerdo a la taxonomiacutea de varias caracteriacutesticas (propagacioacuten de datos mecanismos de fiabilidad retransmisiones control de congestioacuten y de flujo gestioacuten de grupos multicast etc) En Internet los mecanismos efectivos de control de congestioacuten son una de las prioridades en las investigaciones de las transferencias multicast fiables Los mecanismos de seguridad y las teacutecnicas escalables de recuperacioacuten 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 maacutes importantes caracteriacutesticas En esta seccioacuten 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 maacutes interesantes en los siguientes paacuterrafos SMART (shared many-to-many ATM reservations)[3] es un protocolo para controlar un aacuterbol ATM multicast compartido soportando comunicaciones muchos-a-muchos (many-to-many) Esta propuesta tiene importantes caracteriacutesticas como que reside completamente en la capa ATM y no requiere ninguacuten servidor soporta uno o varios VCCs (y tambieacuten VPCs) cuyo nuacutemero es libremente configurado y es independiente del nuacutemero de puntos finales usa el concepto de bloques de datos como en la clase de servicio ABT y tambieacuten permite VCCs de las clases CBR VBR o UBR el protocolo garantiza que no existen puntos de interrelacioacuten en los VCC del aacuterbol son respetadas las garantiacuteas del contrato de traacutefico asociado con los VCCs etc SMART puede ser entendido como un protocolo completamente distribuido para coordinar la distribucioacuten de VPIsVCIs 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 ceacutelulas de datos desde diferentes fuentes pueden llegar intercaladas a un destinatario) y tambieacuten Demand Sharing (los recursos asignados a conexiones muchos-a-muchos son dinaacutemicamente compartidas entre todas las potenciales fuentes El artiacuteculo [3] describe el protocolo SMART formal e informalmente y propone completas pruebas de correccioacuten y un detallado anaacutelisis de comportamiento para estudios futuros Tambieacuten son sugeridas otras investigaciones como son ofrecer justicia en los accesos a los aacuterboles multicast investigar las ceacutelulas RM perioacutedicamente para aliviar las congestiones en la red o disminuir el tiempo de acceso del usuario a los aacuterboles de distribucioacuten multicast anaacutelisis de las ceacutelulas RM dentro de cada VCC o fuera enviando todas las ceacutelulas RM en un VCC dedicado En [17] se presenta MWAX un algoritmo dinaacutemico 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 artiacuteculo describe un esquema jeraacuterquico basado en CBT para incorporar routing multipunto-a-multipunto en PNNI En el algoritmo los nodos core actuacutean como participantes pasivos para eliminar la dependencia en la seleccioacuten de estos nodos Con un mecanismo de backup se consigue un algoritmo tolerante a fallos en los nodos core lo cual puede ser faacutecilmente 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 jerarquiacutea SEAM (Scalable and Efficient ATM Multicast) [18] propone una arquitectura escalable eficiente y multicast multipunto-a-multipunto para redes ATM que usa un soacutelo VC para un grupo multicast de muacuteltiples 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 Tambieacuten realiza aportaciones para conseguir soportar IP multicast sobre redes ATM extensas

SEAM usa un soacutelo aacuterbol de distribucioacuten 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 sentildealizacioacuten del grupo Este trabajo deja abiertas investigaciones referentes a la gestioacuten de traacutefico y a la entrega fiable de traacuteficos multicasting Concluimos esta seccioacuten destacando MCMP (Multiparty Conference Management Protocol) [19] que sin estar pensado especiacuteficamente para ATM es un protocolo de nivel sesioacutentransporte distribuido extremo-extremo y desarrollado para gestioacuten de grupos de aplicaciones de conferencia MCMP es un conjunto de algoritmos de control distribuido para configuracioacuten de conferencias multipunto y gestioacuten de miembros de grupos de usuarios Conceptualmente MCMP reside en el nivel de sesioacuten en el que se establece la infraestructura para activar la transferencia de informacioacuten entre los participantes en la conferencia Pero funcionalmente el protocolo acompasa los niveles de sesioacuten y de transporte pues utiliza directamente servicios del nivel de red Son destacables las condiciones de correccioacuten (conectividad validacioacuten unicidad consistencia y terminacioacuten) que deben ser satisfechas una vez que la conferencia ha sido configurada por el algoritmo de configuracioacuten de MCMP El artiacuteculo muestra exhaustivas pruebas de correccioacuten para uno de los algoritmos y tambieacuten describe la especificacioacuten y verificacioacuten del protocolo

5- Nuevos campos de investigacioacutenEn todas las redes existen gran variedad de elementos hardware (switchs routers bridges brouters hubs ETDs etc) que realizan muy diversas funciones (conmutacioacuten routing puenteo controles de congestioacuten y de flujo garantiacutea de QoS ejecucioacuten de aplicaciones etc) En la actualidad la red es mayormente un canal de comunicacioacuten para transferir paquetes entre equipos finales (ayudada por los elementos hardware antes citados) Pero tambieacuten se estaacuten realizando importante esfuerzos para equipar a los elementos hardware con elevadas prestaciones aportadas por diversas teacutecnicas software Esto dota a la red de caracteriacutesticas activas (active networks) en el sentido de que los elementos hardware que la componen computan modifican u operan los contenidos de los paquetes y tambieacuten seraacuten capaces de transferir o propagar coacutedigo Por consiguiente una red activa es una red programable [20] es una excelente revisioacuten de este novedoso campo de investigacioacuten que discute dos planteamientos en la realizacioacuten de redes activas la idea del conmutador programable y la de la caacutepsula Una red es activa si en sus aacuterboles de distribucioacuten multicast existen nodos activos con capacidad para ejecutar programas yo capaces de implementar mecanismos de propagacioacuten de coacutedigo Algunas de las ventajas de los protocolos activos son conseguidas instalando nodos activos en puntos estrateacutegicos de la red Otro nuevo concepto es presentado en [21] como una metodologiacutea para el disentildeo de protocolos Los protocol boosters son una nueva contribucioacuten a las redes activas o programables Una ventaja de los boosters es que pueden ser faacutecilmente 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 aacuterea extensa Este papel introduce una arquitectura software orientada a agente y propone el concepto de agente de comunicacioacuten para servicio de comunicacioacuten 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 artiacuteculo muestra agentes software moacuteviles usados para implementar operaciones robustas y funciones de mantenimiento en redes ATM Los agentes desempentildean un rol similar al de las ceacutelulas OAM en ATM estaacutendar pues son transmitidos entre entidades de control a intervalos regulares usando recursos predefinidos La diferencia entre los agentes moacuteviles y las ceacutelulas OAM reside en que eacutestos pueden contener coacutedigo Para concluir destacar que la integracioacuten del traacutefico IP sobre tecnologiacutea ATM es tambieacuten uno de los campos maacutes activos en la actualidad En esta liacutenea pueden destacarse los siguientes protocolos IP-over-ATM IP Switching Tag Switching NHRP MPOA IMSS CSR ARIS AREQUIPARED y EPD Referencias

1 ____ Native ATM Service Semantic Description Version 1 ATM Forum Technical Committee ATM Forum Document af-saa-0048000 (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 Broadband Networks Multimedia Applications Services and Techniques ECMASTrsquo98 Springer (May 1998)

3 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 Nordm 3 (April 1997)

4 W D Zhong K Yukimatsu Design requeriments and architectures for multicast ATM switching IEICE Trans Com Vol E77-B pp 1420-1428 (Nov 1994)

5 ____ ATM user-network interface version 31 specification ATM Forum (1994)

6 ____ Traffic Management Specification Version 40 ATM Forum Technical Committee ATM Forum Document af-tm-0056000 (April 1996)

7 D Kandlur D Saha and W Willebeck Protocol Architecture for multimedia Application over ATM Networks IEEE Journal Selected and Communications Vol 14 Nordm 7 pp 1349-1359 (Sep 1996)

8 R Ahuja S Keshav and H Saran Design Implementation and Performance Measurement of a Native-Mode ATM Transport Layer (Estended Version) IEEEACM Transactions on Networking Vol 4 Nordm 4 (Aug 1996)

9 R Karabek A Native ATM Protocol Architecture Design and Performance Evaluation IEEE Proceedings 22nd Annual Conference on Local Computer Networks pp 204-210 (1997)

10 D C Feldmeier A framework of architectural concepts for high-speed communications systems IEEE J Select Areas CommunVol11 Nordm 4 (May 1993)

11 T Anker D Breitgand D Dolev Z Levy Congress CONnection-oriented Group-address RESolution Service Proceeding of SPIE97 vol 3233 on Broadband Networking Technologies Nov (1997)

12 kStack httpcometcolumbiaedusoftwarekStack

13 T La Porta and M Schwartz Architectures Features and Implementation of High-Speed Transport Protocols IEEE Network Magazine pp 14-22 (May 1991)

14 ____ B-ISDN ATM Adaptation Layer Service Specific Connection Oriented Protocol (SSCOP) Q2110 ITU-T (10-Mar 1994)

15 J Soleacute-Pareta J Vila-Sallent Network-based paralell computing over ATM using improved SSCOP protocol Computer Communications 19 pp 915-926 (1996)

16 K Obraczka Multicast Transport Protocols A survey and Taxonomy IEEE Communi Magazine (1998)

17 R Venkateswaran CS Raghavendra X Chen and VP Kumar A Scalable Dynamic Multicast Routing Algorithm in ATM Networks IEEE pp 1361-1365 (1997)

18 Matthias Grossglauser and KK Ramakrishnan SEAM Scalable and Efficient ATM Multicast IEEE 1997 pp 867-875 (1997)

19 M Nguyen and M Schwartz MCMP A Transportsession level Distributed Protocol for Desktop Conference Setup IEEE Journal Selected and comunications Vol 14 Nordm 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 Nordm 3 pp 437-443 (April 1998)

22 R Kishimoto Agent communication system for multimedia communication services INFOCOMrsquo96 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 Nordm 3 pp 414-423 (April 1998)

  • ATM - Modo de Transferencia Asiacutencrona
  • Revisioacuten y Clasificacioacuten de Protocolos para Redes de Tecnologiacutea ATM
    • Resumen
    • 1-Introduccioacuten y motivaciones
    • 2- Protocolos nativos ATM
    • 3- Protocolos de transporte para redes ATM
    • 4- Protocolos multipoint
    • 5- Nuevos campos de investigacioacuten
      • Referencias
Page 6: Atm

AAL-2 AAL-3 AAL-4

La capa de adaptacioacuten 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 informacioacuten en la cabecera y en el payload depende de la clase de informacioacuten que va a ser transportada

2)Capa de Segmentacioacuten 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 informacioacuten necesaria para el reensamblaje en el destino La figura siguiente aporta una mejor comprensioacuten 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 tamantildeo de la celda ATM para su transmisioacuten Tambieacuten realiza la funcioacuten inversa (reemsamblado) para las unidades de informacioacuten de orden superior Cada porcioacuten es ubicada en su propia unidad de protocolo de segmentacioacuten 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 informacioacuten que regule el tiempo con los datos AAL-1 provee recuperacioacuten de errores e indica la informacioacuten con errores que no podraacute ser recuperada

Capa de convergencia

Las funciones provistas a esta capa difieren dependiendo del servicio que se proveyoacute Provee la correccioacuten de errores

Capa de segmentacioacuten y reensamblaje

En esta capa los datos son segmentados y se les antildeade una cabecera La cabecera contiene 3 campos (ver diagrama)

Nuacutemero de secuencia usado para detectar una insercioacuten o perdida de un paquete Nuacutemero de secuencia para la proteccioacuten usado para corregir errores que ocurren en el

numero de secuencia Indicador de capa de convergencia usado para indicar la presencia de la funcioacuten de la capa

de convergencia

ALL 2

AAL-2 se usa para transferir datos con tasa de bits variable que dependen del tiempo Enviacutea la informacioacuten del tiempo conjuntamente con los datos para que esta puede recuperarse en el destino AAL-2 provee recuperacioacuten de errores e indica la informacioacuten que no puede recuperarse

Capa de convergencia

Esta capa provee para la correccioacuten de errores y transporta la informacioacuten del tiempo desde el origen al destino

Capa de segmentacioacuten y recuperacioacuten

El mensaje es segmentado y se le antildeade 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 informacioacuten es

o BOM comenzando de mensaje o COM continuacioacuten de mensaje o EOM fin de mensaje o indica que el paquete contiene informacioacuten de tiempo u

otra

El payload tambieacuten 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 disentildea para transferir los datos con tasa de bits variable que son independientes del tiempo AAL-3 puede ser dividido en dos modos de operacioacuten

1 Fiable En caso de perdida o mala recepcioacuten de datos estos vuelven a ser enviados El control de flujo es soportado

2 No fiable La recuperacioacuten 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 comuacuten de la capa de convergencia Esto es provisto tambieacuten por el AAL-2 CS Antildeade una cabecera y un payload a la parte comuacuten (ver diagrama)

La cabecera contiene 3 campos Indicador de la parte comuacuten que dice que el payload forma parte de la parte comuacuten Etiqueta de comienzo que indica el comienzo de la parte comuacuten de la capa de

convergencia Tamantildeo del buffer que dice al receptor el espacio necesario para acomodar el mensaje

El payload tambieacuten contiene 3 campos Alineacioacuten 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 comuacuten de la CS(capa de convergencia) El campo de longitud tiene la longitud de la parte comuacuten de la CS

1 Parte especifica del servicio Las funciones proveiacutedas en esta que capa dependen de los servicios pedidos Generalmente se incluyen funciones para la recuperacioacuten y deteccioacuten de errores y puede incluir tambieacuten funciones especiales

Capa de segmentacioacuten y reensamblaje

En esta capa los datos son partidos en paquetes de ATM Una cabecera y el payload que contiene la informacioacuten necesaria para la recuperacioacuten de errores y reensamblaje se antildeaden 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 Continuacioacuten de mensaje EOM Fin de mensaje SSM Mensaje uacutenico en el segmento

2) Numero de secuencia usado para detectar una insercioacuten o una perdida de un paquete 3) Identificador de multiplexacioacuten Este campo se usa para distinguir datos de diferentes comunicaciones que ha sido multiplexadas en una uacutenica conexioacuten de ATM El payload contiene dos de campos 1) Indicado de longitud que indica el nuacutemero de bytes uacutetiles en un paquete parcialmente lleno 2) CRC es para el control de errores

ALL 4

AAL-4 se disentildea para transportar datos con tasa de bits variable independientes del tiempo Es similar al AAL3 y tambieacuten puede operar en transmisioacuten fiable y o fiable AAL-4 provee la capacidad de transferir datos fuera de una conexioacuten expliacutecita

AAL 2 AAL 34 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 traacutefico de redes de aacuterea local (LAN) AAL 2 y AAL 3 soportan paquetes orientados a conexioacuten (Ver figura No5)

(El teacutermino orientado a conexioacuten describe la transferencia de datos despueacutes 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 jamaacutes vean estos errores reportados la degradacioacuten de respuesta o de caudal (through put) seriacutean los uacutenicos siacutentomas A diferencia de los mecanismos de control extremo a extremo que utiliza TCP en internerworking la capacidad de Gbitseg de la red ATM genera un juego de requerimientos necesarios para el control de flujo Si el control del flujo se hiciese como una realimentacioacuten del lazo extremo a extremo en el momento en que el mensaje de control de flujo arribase a la fuente eacutesta habriacutea transmitido ya algunos Mbytes de datos en el sistema exacerbando la congestioacuten Y en el momento en que la fuente reaccionase al mensaje de control la condicioacuten de congestioacuten hubiese podido desaparecer apagando innecesariamente la fuente La constante de tiempo de la realimentacioacuten extremo a extremo en las redes ATM (retardo de realimentacioacuten por producto lazo - ancho de banda) debe ser lo suficientemente alta como para cumplir con las necesidades del usuario sin que la dinaacutemica de la red se vuelva impractica Las condiciones de congestioacuten en las redes ATM estaacuten previstas para que sean extremadamente dinaacutemicas requiriendo de mecanismos de hardware lo suficientemente raacutepidos para llevar a la red al estado estacionario necesitando que la red en siacute eacuteste activamente involucrada en el raacutepido establecimiento de este estado estacionario Sin embargo esta aproximacioacuten simplista de control reactivo de lazo cerrado extremo a extremo en condiciones de congestioacuten no se considera suficiente para las redes ATM El consenso entre los investigadores de este campo arroja recomendaciones que incluyen el empleo de una coleccioacuten de esquemas de control de flujo junto con la colocacioacuten adecuada de los recursos y dimensionamiento de las redes para que aunados se pueda tratar y evadir la congestioacuten ya sea

Detectando y manipulando la congestioacuten que se genera tempranamente monitoreando de cerca las entradassalidas que estaacuten dentro de los conmutadores ATM y reaccionando gradualmente a medida que vaya arribando a ciertos niveles prefijados Tratando y controlando la inyeccioacuten de la conexioacuten de datos dentro de la red en la UNI (unidad interfaz de red) de tal forma que su tasa de inyeccioacuten sea modulada y medida alliacute primero antes de tener que ir a la conexioacuten de usuario a tomar acciones mas draacutesticas El estado de la red debe ser comunicado a la UNI generando raacutepidamente una celda de control de flujo siempre que se vaya a descartar una celda en alguacuten nodo debido a congestioacuten La UNI debe entonces manejar la congestioacuten cambiando su tasa de inyeccioacuten

o notificaacutendola a la conexioacuten de usuario para que cese el flujo dependiendo del nivel de severidad de la congestioacutenEl mayor compromiso durante el control de congestioacuten es el de tratar y afectar solo a los flujos de conexioacuten que son responsables de la congestioacuten y actuar de forma transparente frente a los flujos que observan buen comportamiento Al mismo tiempo permitir que el flujo de conexioacuten utilice tanto ancho de banda como necesite sino hay congestioacuten La recomendacioacuten UIT - T I 371 especifica un contrato de traacutefico que define como el traacutefico del usuario seria administrado El contrato que existe para cada conexion virtual (virtual path o virtual channel) es baacutesicamente un acuerdo entre el usuario y la red con respecto a la Calidad de Servicio (Quality Of Service - Q o S) y los paraacutemetros que regulan el flujo de celdas Estos descriptores de trafico dependen de una particular clase de servicio y pueden incluir bajo la especificacioacuten del ATM Forum UNI a cinco Q o S referenciados en los AALS El objetivo de estas sub clases de servicio es agrupar caracteriacutesticas 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 paraacutemetros pueden incluir el Sustained Cell Rate (SCR) el Miacutenimum Cell Rate (MCR) el Peak Cell Rate (PCR) yo el Burst Tolerance (BT) Para soportar todas las diferentes clases de servicios definidos por los estaacutendares el switch ATM debe ser capaz de definir eacutestos paraacutemetros en base a cada VC o cada VP y debe proveer amortiguadores (buffers) para absorber las raacutefagas de trafico

INTEROPERABILIDAD ENTRE FRAME RELAY Y ATM El objetivo final para todos los servicios descritos anteriormente es una migracioacuten suave de Frame Relay yo SMDS a redes ATM Por ejemplo la recomendacioacuten UIT - T I555 provee un marco para la interoperabilidad de Frame Relay y ATM Para alcanzar una maacutexima eficiencia se trata de brindar este servicio de interoperabilidad en la capa maacutes baja posible mediante conversioacuten de protocolo

PRIMER ESCENARIO

Cuando el servicio de Frame Relay es dado sobre la RDSI en banda ancha y los usuarios se conectan a traveacutes de la UNI de Frame Relay En esta solucioacuten 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 (VCVP) para enlazar los puntos de acceso Frame Relay En este esquema se puede explotar la naturaleza de orientacioacuten a conexioacuten Frame Relay (F R) siguiendo un comportamiento como

El usuario del enrutador pregunta por una conexioacuten al equipo interfaz de red El equipo interfaz de la red coloca las conexiones Frame Relay dentro de una conexioacuten ATM con las direcciones destino apropiadas Por cada trama de equipo interfaz de red traslada de la conexioacuten de Frame Relay a la ATM y viceversa La conexioacuten ATM esta desocupada cuando no se necesitaPara lograr este uacuteltimo punto el manejo de la poliacutetica de conexion del VC sera un aspecto crucial para el desempentildeo de este procedimiento Resulta difiacutecil de terminar el procedimiento para manejar un VC cuando la fuente de traacutefico es no orientada a conexioacuten 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 conexioacuten 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 opcioacuten se toma ventaja del uso actual del FR el cual es proveer un mallado virtual entre diferentes sitios para cargar traacutefico no orientado a conexioacuten 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 conmutacioacuten 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 traveacutes de sus respectivas interfaces de red (NNIs) Esto permitiriacutea a un proveedor de red manejar esta heterogeacutenea red como un todo Frame Relay provee usualmente la interconexioacuten para LAN a pesar de su natural orientacioacuten a conexioacuten 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 sobresimplificacioacuten los dos protocolos (AAL 3 y AAL 5) ofrecen basicamente el mismo servicio CPAAL (Parte Comuacuten 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 implementacioacuten y eficiencia del protocolo que incide en el costo Las caracteriacutesticas a tomar en cuenta cuyo detalle puede ser tema de otro artiacuteculo tienen que ver con Delimitacioacuten y Alineamiento de Tramas Multiplexacioacuten Deteccioacuten de errores de transmisioacuten eficiencia en la transmisioacuten 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 tecnologiacutea de red empresarial virtual del futuro un teacutermino que refleja tanto la evolucioacuten del modelo empresarial global y el eacutenfasis en la conectividad loacutegica donde los usuarios obtienen acceso a los recursos que necesitan y el operador de la red provee las rutas de conexioacuten y asigna el ancho de banda necesario a fuentes de traacutefico muy diferentes (voz datos viacutedeo) Aquellos que construyen y operan redes deben volver los ojos a las capacidades de la tecnologiacutea ATM ya que aspiran a la maacutegica combinacioacuten interconectividad global - escalabilidad de tecnologiacuteas y satisfaccioacuten del cliente local

BIBLIOGRAFIA

1 CCITT Rec I362 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 vol2 No8 ATM Testing crosses network boundaries Jim Frimmel

6 Newslink Alcatel Telecomrsquos customer magazine Vol IV No4 4th Quarter 1996 Adapting Networks to the Internet Challenge Krish Prabhu

Trabajo realizado por

Ivan Dario Cruz PradaNicruz[arroba]col1telecomcomco

Revisioacuten y Clasificacioacuten de Protocolos para Redes de Tecnologiacutea ATM

Joseacute Luis Gonzaacutelez-Saacutenchez y Jordi Domingo-Pascual

ResumenLa tecnologiacutea 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 investigacioacuten maacutes activo con la aspiracioacuten 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 asiacute como las caracteriacutesticas multicast la escalabilidad y la fiabilidad Se profundiza en el concepto de protocolo nativo ATM y son introducidos los protocolos maacutes importantes que satisfacen este importante requerimiento (N3 CONGRESS y kStack entre otros) Es importante destacar tambieacuten los protocolos de transporte pensados especiacuteficamente para la tecnologiacutea ATM La caracteriacutestica multicast (multipoint-to-multipoint) es una de las que maacutes esfuerzo estaacute costando garantizar a ATM pero existen ya propuestas que permiten la comunicacioacuten fiable a elevados anchos de banda y entre muacuteltiples emisores y receptores (SMART MCMP o MWAX) El artiacuteculo concluye con las investigacioness maacutes novedosas en torno a los protocolos ATM como las iniciativas que proponen redes ATM programables o activas (active networks) usando agentes moacuteviles

1-Introduccioacuten y motivacionesLa actual demanda de aplicaciones relacionadas con informacioacuten multimedia como son la video-conferencia audio-conferencia video bajo demanda (VoD) o sistemas colaborativos (pizarras compartidas teletrabajo telemedicina etc) y su coexistencia con aplicaciones maacutes claacutesicas (bases de datos transferencias de ficheros WWW etc) requiere tecnologiacuteas de comunicaciones capaces de ofrecer elevadas prestaciones Estas elevadas prestaciones estaacuten directamente relacionadas con la calidad de servicio (QoS) y concretamente con conceptos claramente parametrizables como el ancho de banda y la velocidad de transmisioacuten (throughput) el retardo de las transferencias (delay) la variabilidad en el retardo (jitter) la fiabilidad (reliability) de las transmisiones las caracteriacutesticas de multidifusioacuten a grupos dispersos de usuarios (multicast) y la posibilidad de gestionar muacuteltiples clases de servicio o flujos de informacioacuten en redes multiclass Para que las nuevas tecnologiacuteas en comunicaciones puedan ofrecer estas caracteriacutesticas es necesario revisar potenciar y ampliar las actuales arquitecturas servicios y protocolosde comunicaciones En los uacuteltimos dos o tres antildeos las investigaciones en el campo de ATM estaacuten dado lugar a importantes propuestas cuyo principal objetivo es ofrecer a las aplicaciones demandadas actualmente algunas o todas las caracteriacutesticas citadas anteriormente Presentamos en este trabajo los conceptos y propuestas maacutes novedosas en el contexto de ATM para ayudar al lector interesado en el dinaacutemico complejo y sofisticado campo de los protocolos de comunicaciones Realizamos la revisioacuten de algunos de los maacutes importantes conceptos teacutecnicas ideas y mecanismos en protocolos de altas prestaciones para redes de tecnologiacutea ATM El principal objetivo de este documento es ofrecer una actualizada visioacuten general no extensiva ni profunda de los protocolos propuestos y en desarrollo para dotar a las diversas clases de servicio ATM de las citadas caracteriacutesticas de calidad de servicio que aporten las potenciales elevadas prestaciones que la tecnologiacutea ATM es capaz de ofrecer El resto del documento estaacute estructurado de la siguiente forma La seccioacuten 2 revisa el concepto de protocolo nativo centrado en el contexto de las redes ATM La seccioacuten 3 describe las propuestas maacutes interesantes actualmente en materia de protocolos de transporte El apartado 4 comenta las transferencias multicast como un importante objetivo para una tecnologiacutea orientada a la conexioacuten como es ATM Concluimos en la seccioacuten 5 con los campos de investigacioacuten abiertos recientemente como son las redes activas y los procolos booster

2- Protocolos nativos ATM

Las aplicaciones nativas ATM estaacuten especiacuteficamente pensadas para usar la tecnologiacutea ATM y para explotar al maacuteximo sus especiales caracteriacutesticas Los protocolos nativos se encargan por tanto de ofrecer esas caracteriacutesticas intriacutensecas de las redes de tecnologiacutea ATM (soporte de QoS sentildealizacioacuten direccionamiento etc) a las aplicaciones nativas ATM (VoD pizarras compartidas video-conferencia) No obstante existen tambieacuten activas investigaciones para conseguir soportar sobre redes ATM aplicaciones no nativas ATM desarrolladas para otras tecnologiacuteas (IP Frame Relay SMDS) En [1] el termino native ATM services define servicios ATM especiacuteficos 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 adaptacioacuten (AALs) Disponibilidad de circuitos virtuales conmutados (SVCs) y circuitos virtuales permanentes (PVCs) Consideraciones relativas a la gestioacuten de traacutefico (clases de servicio garantiacuteas de QoS etc) Posibilidad de distribucioacuten de conexiones y de participacioacuten local en la administracioacuten de la red (protocolos ILMI y OAM)

El propoacutesito de los servicios nativos ATM es ofrecer el acceso a las clases de servicio o a las caracteriacutesticas de QoS en redes ATM Estos servicios nativos tambieacuten ofrecen soporte a un amplio y heterogeacuteneo rango de flujos con diversas propiedades y requerimientos recomendados en [1] Los protocolos de transferencia nativos ATM gestionan la sentildealizacioacuten UNI para establecer los SVCs configurar PVCs y mapear los perfiles de QoS en la correspondiente clase de servicio Los protocolos nativos tambieacuten realizan funciones claacutesicas como las de transporte mecanismos de control de errores transferencia de datos y controles de flujo y de congestioacuten En la referencia [1] se especifica la definicioacuten semaacutentica de los servicios y consideramos que es uacutetil contrastar esta semaacutentica con las redes ATM actuales que usan TCP como capa de transporte e IP-over-ATM como capa de red planteamiento por otro lado poco adecuado [2] por las siguientes razones

Las redes IP no garantizan la QoS extremo-extremo ofrecida por las redes ATM a circuitos individuales IP multiplexa muacuteltiples conexiones de transporte con distintos requerimientos de QoS en VCs simples TCP no soporta ceacutelulas RM (Resource Management) ABR y por consiguiente no puede usar directamente las garantiacuteas de QoS ofrecidas por la red ATM Adaptation Layer 5 (AAL5) realiza labores de checksum para detectar corrupcioacuten de datos TCP tambieacuten realiza estas labores (redundantes con AAL5) costosas en overhead (cada byte de un paquete debe ser chequeado) TCPIP son la representacioacuten de un grupo de protocolos bastante maacutes 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] Ademaacutes 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 tecnologiacutea ATM y tambieacuten existen antiguas y no nativas aplicaciones Este escenario implica cambiar las aplicaciones o proponer nuevas pilas de protocolos nativos ATM La encapsulacioacuten consecutiva de paquetes genera problemas de overhead y funciones redundantes como se ha argumentado anteriormente La limitacioacuten de recursos en los sistemas finales es otra importante motivacioacuten 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 puacuteblicos disfrutan tambieacuten de estas ventajas ATM RDSI y la telefoniacutea ofrecen un esquema de direccionamiento universal basado en NSAPE164 el cual es capaz de enrutar traacutefico de forma nativa Por tanto aunque ATM dispone de protocolos nativos con direccionamiento intriacutenceso estructurado y jeraacuterquico eacuteste no es aprovechado por las aplicaciones que estaacuten 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 tambieacuten existen importantes investigaciones en torno a los protocolos nativos ATM En esta seccioacuten se muestran las propuestas maacutes importantes y actuales en materia de protocolos nativos ATM[2] [7] [8] [9] [10] [11] [12] que a su vezestaacuten sirviendo de base para nuevas investigaciones

[8] presentan el disentildeo implementacioacuten y comportamiento de una pila en modo nativo ATM y contrasta la semaacutentica 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 automaacuteticamente los siguientes problemas

IP-over-ATM no ofrece garantiacutea de QoS pues sus aplicaciones soacutelo ven la interfaz IP El nuacutecleo 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 sentildealizacioacuten 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 caracteriacutesticas la entrega fiable y no fiable de datos con control de flujo Este protocolo de transporte es ampliado en la seccioacuten 5 [2] presenta N3 (Native Non-broadcasting medium access Networking) un protocolo de transporte ligero y nativo ATM La pila N3 se ha disentildeado 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 ademaacutes aporta otras importantes novedades Los principales componentes de N3 incluyen una API sockets ATM nativa un protocolo de transporte ATM y un servicio de nombres ATM (Fig2) El protocolo de transporte ATM propuesto en [2] ofrece soporte para tres diferentes tipos de servicio entrega garantizada (mecanismos de retransmisioacuten) 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 congestioacuten de la transferencia de datagramas y de la multiplexacioacuten 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 maacutes importante El Flow Management se responsabiliza de manipular los flujos de datos desde y hasta la red viacutea la interfaz AAL La segmentacioacuten el reensamblado y el control de errores es tambieacuten 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 congestioacuten y de flujo extremo-extremo maacutes complejo

[7] describe la semaacutentica de una pila de protocolos y explora una nueva arquitectura de protocolo adaptada a la tecnologiacutea ATM y a las aplicaciones multimedia El disentildeo estaacute basado en tres principios baacutesicos separacioacuten de flujos de control y de datos minimizacioacuten del overhead y de la duplicidad de funciones y acceso de las aplicaciones al nivel ATM con garantiacuteas 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-over-ATM 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 moacutedulo CNTL abre una conexioacuten de sentildealizacioacuten con el dispositivo ATM y establece una gestioacuten de las llamadas de mensajes de configuracioacuten PF_ATM separa flujos de datos y de control para aliviar el liacutemite de comportamiento en las comunicaciones Esto permite a los mecanismos de control de traacutefico ser raacutepidos y sencillos mientras los mecanismos de control pueden ser tan complicados como sea necesario Esta separacioacuten permite tambieacuten que los dispositivos puedan estar en los puntos finales de una conexioacuten La interfaz PF_ATM da a las aplicaciones acceso directo a la capa de enlace ATM y extiende las garantiacuteas de QoS a los puntos extremos de la comunicacioacuten Un segundo prototipo[7] es disentildeado e implementado con dos objetivos principales en la optimizacioacuten de la pila nativa ATM

Optimizar los caminos de datos entre los adaptadores ATM aprovechando la separacioacuten de flujos de control y de datos y la capacidad de gestioacuten de datos especiacuteficos de las conexiones de la pila ATM

Optimizar el procesamiento de overheads usando una pila de protocolos nativo ATM en lugar de UDPIP

[11] introduce CONGRESS (CONnection oriented Group-address RESolution Service) otro eficiente protocolo nativo ATM para la resolucioacuten y gestioacuten 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 disentildeo basado en los dos siguientes principios

Disentildeo jeraacuterquico los servicios del protocolo son ofrecidos a las aplicaciones por muacuteltiples servidores organizados jeraacuterquicamente No inundacioacuten se evita la inundacioacuten 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 implementacioacuten sobre Unix y Windows NT estaacute 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 antildeadido un moacutedulo que monitoria la QoS extremo-a-extremo

3- Protocolos de transporte para redes ATMEn los dos o tres uacuteltimos antildeos ha habido numerosos e interesante intentos por disentildear protocolos de transporte La referencia [10] presenta un completo y ya claacutesico resumen de las propuestas maacutes interesantes en materia de protocolos de transporte para redes de alta velocidad (mayoritariamente IP en el artiacuteculo) Ademaacutes la referencia [13] ofrece una interesante visioacuten de las caracteriacutesticas maacutes importantes en los protocolos de elevada velocidad Son estudiadas tambieacuten diversas arquitecturas de protocolos y varias teacutecnicas de implementacioacuten Los protocolos de transporte de elevada velocidad son fuente de activas investigaciones y estaacuten en constante evolucioacuten desde hace maacutes de dos deacutecadas 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 aacutembito de las comunicaciones que ha recibido mayor atencioacuten es la capa de transporte la cuarta capa del OSI-RM de los protocolos de comunicaciones TCP e ISO TP4 son los dos maacutes populares protocolos de transporte Pero centraacutendonos maacutes concretamente en el aacutembito de ATM la literatura presenta varios protocolos de transporte y arquitecturas para redes de alta velocidad revisadas resumidamente a continuacioacuten [7] ofrece una excelente y didaacutectica arquitectura de pila de protocolos para aplicaciones multimedia en modo nativo ATM Esta arquitectura de protocolo ha sido ya descrita brevemente en la seccioacuten anterior [8] presentan el disentildeo implementacioacuten 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 estaacute formada por tres entidades principales aplicacioacuten sentildealizacioacuten y transporte La siguiente Tabla 1 muestra un conjunto de nueve baacutesicos 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 combinacioacuten de servicios La marca X indica el servicio baacutesico soportado en cada clase de servicio general

Clases de servicio

Servicios Servicio de comportamiento

garantizado

Servicio fiable Servicio Best effort

- Transferencia Simplex de datos

X X X

- Control de errores - deteccion de errorestimeouts retransmisiones

No existente (ofrecido por

AAL5)

- Bucle abierto - Control de flujo realimentado

No existente -

- X

- No existente

- Tamantildeo de mensaje ilimitado

X X X

- Eleccioacuten de blocking - Aplicacioacuten Non-blocking

X X

X X

X X

- Eleccioacuten de byte stream - Semaacutentica transferencia de mensajes

X X

X X

X X

- Garantiacuteas de QoS requerimientos de ancho de banda

No soportado No soportado

- Reserva de recursos X No existente No existente

- Transferencias Multicast X No soportado Para servicios no fiables

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 recuperacioacuten de peacuterdidas del protocolo estaacutendar SSCOP [14] y demuestran que el resultado ofrece baja latencia eficiente recuperacioacuten de ceacutelulas perdidas y es tan robusto como el estaacutendar SSCOP

4- Protocolos multipointEl crecimiento de las redes ATM viene motivado en parte por la demanda de servicios multimedia para grupos dispersos de usuarios El traacutefico multicast tiene caracteriacutesticas particulares descritas para ATM en UNI 40 [6] y anteriores [5] La distribucioacuten de informacioacuten punto-a-multipunto (uno-a-muchos) o multipunto-a-multipunto (muchos-a-muchos) es un objetivo baacutesico propuesto por varios protocolos y arquitecturas ATM que ofrecen el soporte multimedia yo multicast como audio-conferencia video-conferencia trabajos colaborativos o VoD ATM es auacuten una tecnologiacutea emergente disentildeada 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 30) para ATM define conexiones punto-a-multipunto y las conexiones multipunto-a-multipunto soacutelo 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 topologiacutea completamente mallada todos-con-todos Aunque esta topologiacutea ofrece conexiones multipunto-a-multipunto hay que destacar que no escala bien cuando el nuacutemero de participantes es elevado Una alternativa al anterior esquema es el uso de un servidor que actuacutea a modo de raiacutez en el aacuterbol multipunto Este meacutetodo soacutelo requiere un nodo raiacutez para almacenar informacioacuten pero la desventaja de este meacutetodo son las potenciales congestiones en el servidor

cuando debe encargarse de enviacuteos y retransmisiones de las conexiones multipunto-a-multipunto

Para solventar las limitaciones de UNI 30 y UNI 31 [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 sentildealizacioacuten ATM (UNI 31 UNI 40) [4][5][6] Comenzamos destacando la referencia [16] como un reciente trabajo que revisa y compara los protocolos de transporte multicast maacutes importantes en Internet como MTP-2 XTP RTP SRM RAMP RMTP MFTP STORM etc IETF e IRTF (como ITU-T y ATM Forum) tambieacuten impulsan una importante actividad en este campo La referencia [16] revisa los maacutes representativos protocolos multicast y los clasifica de acuerdo a la taxonomiacutea de varias caracteriacutesticas (propagacioacuten de datos mecanismos de fiabilidad retransmisiones control de congestioacuten y de flujo gestioacuten de grupos multicast etc) En Internet los mecanismos efectivos de control de congestioacuten son una de las prioridades en las investigaciones de las transferencias multicast fiables Los mecanismos de seguridad y las teacutecnicas escalables de recuperacioacuten 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 maacutes importantes caracteriacutesticas En esta seccioacuten 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 maacutes interesantes en los siguientes paacuterrafos SMART (shared many-to-many ATM reservations)[3] es un protocolo para controlar un aacuterbol ATM multicast compartido soportando comunicaciones muchos-a-muchos (many-to-many) Esta propuesta tiene importantes caracteriacutesticas como que reside completamente en la capa ATM y no requiere ninguacuten servidor soporta uno o varios VCCs (y tambieacuten VPCs) cuyo nuacutemero es libremente configurado y es independiente del nuacutemero de puntos finales usa el concepto de bloques de datos como en la clase de servicio ABT y tambieacuten permite VCCs de las clases CBR VBR o UBR el protocolo garantiza que no existen puntos de interrelacioacuten en los VCC del aacuterbol son respetadas las garantiacuteas del contrato de traacutefico asociado con los VCCs etc SMART puede ser entendido como un protocolo completamente distribuido para coordinar la distribucioacuten de VPIsVCIs 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 ceacutelulas de datos desde diferentes fuentes pueden llegar intercaladas a un destinatario) y tambieacuten Demand Sharing (los recursos asignados a conexiones muchos-a-muchos son dinaacutemicamente compartidas entre todas las potenciales fuentes El artiacuteculo [3] describe el protocolo SMART formal e informalmente y propone completas pruebas de correccioacuten y un detallado anaacutelisis de comportamiento para estudios futuros Tambieacuten son sugeridas otras investigaciones como son ofrecer justicia en los accesos a los aacuterboles multicast investigar las ceacutelulas RM perioacutedicamente para aliviar las congestiones en la red o disminuir el tiempo de acceso del usuario a los aacuterboles de distribucioacuten multicast anaacutelisis de las ceacutelulas RM dentro de cada VCC o fuera enviando todas las ceacutelulas RM en un VCC dedicado En [17] se presenta MWAX un algoritmo dinaacutemico 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 artiacuteculo describe un esquema jeraacuterquico basado en CBT para incorporar routing multipunto-a-multipunto en PNNI En el algoritmo los nodos core actuacutean como participantes pasivos para eliminar la dependencia en la seleccioacuten de estos nodos Con un mecanismo de backup se consigue un algoritmo tolerante a fallos en los nodos core lo cual puede ser faacutecilmente 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 jerarquiacutea SEAM (Scalable and Efficient ATM Multicast) [18] propone una arquitectura escalable eficiente y multicast multipunto-a-multipunto para redes ATM que usa un soacutelo VC para un grupo multicast de muacuteltiples 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 Tambieacuten realiza aportaciones para conseguir soportar IP multicast sobre redes ATM extensas

SEAM usa un soacutelo aacuterbol de distribucioacuten 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 sentildealizacioacuten del grupo Este trabajo deja abiertas investigaciones referentes a la gestioacuten de traacutefico y a la entrega fiable de traacuteficos multicasting Concluimos esta seccioacuten destacando MCMP (Multiparty Conference Management Protocol) [19] que sin estar pensado especiacuteficamente para ATM es un protocolo de nivel sesioacutentransporte distribuido extremo-extremo y desarrollado para gestioacuten de grupos de aplicaciones de conferencia MCMP es un conjunto de algoritmos de control distribuido para configuracioacuten de conferencias multipunto y gestioacuten de miembros de grupos de usuarios Conceptualmente MCMP reside en el nivel de sesioacuten en el que se establece la infraestructura para activar la transferencia de informacioacuten entre los participantes en la conferencia Pero funcionalmente el protocolo acompasa los niveles de sesioacuten y de transporte pues utiliza directamente servicios del nivel de red Son destacables las condiciones de correccioacuten (conectividad validacioacuten unicidad consistencia y terminacioacuten) que deben ser satisfechas una vez que la conferencia ha sido configurada por el algoritmo de configuracioacuten de MCMP El artiacuteculo muestra exhaustivas pruebas de correccioacuten para uno de los algoritmos y tambieacuten describe la especificacioacuten y verificacioacuten del protocolo

5- Nuevos campos de investigacioacutenEn todas las redes existen gran variedad de elementos hardware (switchs routers bridges brouters hubs ETDs etc) que realizan muy diversas funciones (conmutacioacuten routing puenteo controles de congestioacuten y de flujo garantiacutea de QoS ejecucioacuten de aplicaciones etc) En la actualidad la red es mayormente un canal de comunicacioacuten para transferir paquetes entre equipos finales (ayudada por los elementos hardware antes citados) Pero tambieacuten se estaacuten realizando importante esfuerzos para equipar a los elementos hardware con elevadas prestaciones aportadas por diversas teacutecnicas software Esto dota a la red de caracteriacutesticas activas (active networks) en el sentido de que los elementos hardware que la componen computan modifican u operan los contenidos de los paquetes y tambieacuten seraacuten capaces de transferir o propagar coacutedigo Por consiguiente una red activa es una red programable [20] es una excelente revisioacuten de este novedoso campo de investigacioacuten que discute dos planteamientos en la realizacioacuten de redes activas la idea del conmutador programable y la de la caacutepsula Una red es activa si en sus aacuterboles de distribucioacuten multicast existen nodos activos con capacidad para ejecutar programas yo capaces de implementar mecanismos de propagacioacuten de coacutedigo Algunas de las ventajas de los protocolos activos son conseguidas instalando nodos activos en puntos estrateacutegicos de la red Otro nuevo concepto es presentado en [21] como una metodologiacutea para el disentildeo de protocolos Los protocol boosters son una nueva contribucioacuten a las redes activas o programables Una ventaja de los boosters es que pueden ser faacutecilmente 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 aacuterea extensa Este papel introduce una arquitectura software orientada a agente y propone el concepto de agente de comunicacioacuten para servicio de comunicacioacuten 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 artiacuteculo muestra agentes software moacuteviles usados para implementar operaciones robustas y funciones de mantenimiento en redes ATM Los agentes desempentildean un rol similar al de las ceacutelulas OAM en ATM estaacutendar pues son transmitidos entre entidades de control a intervalos regulares usando recursos predefinidos La diferencia entre los agentes moacuteviles y las ceacutelulas OAM reside en que eacutestos pueden contener coacutedigo Para concluir destacar que la integracioacuten del traacutefico IP sobre tecnologiacutea ATM es tambieacuten uno de los campos maacutes activos en la actualidad En esta liacutenea pueden destacarse los siguientes protocolos IP-over-ATM IP Switching Tag Switching NHRP MPOA IMSS CSR ARIS AREQUIPARED y EPD Referencias

1 ____ Native ATM Service Semantic Description Version 1 ATM Forum Technical Committee ATM Forum Document af-saa-0048000 (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 Broadband Networks Multimedia Applications Services and Techniques ECMASTrsquo98 Springer (May 1998)

3 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 Nordm 3 (April 1997)

4 W D Zhong K Yukimatsu Design requeriments and architectures for multicast ATM switching IEICE Trans Com Vol E77-B pp 1420-1428 (Nov 1994)

5 ____ ATM user-network interface version 31 specification ATM Forum (1994)

6 ____ Traffic Management Specification Version 40 ATM Forum Technical Committee ATM Forum Document af-tm-0056000 (April 1996)

7 D Kandlur D Saha and W Willebeck Protocol Architecture for multimedia Application over ATM Networks IEEE Journal Selected and Communications Vol 14 Nordm 7 pp 1349-1359 (Sep 1996)

8 R Ahuja S Keshav and H Saran Design Implementation and Performance Measurement of a Native-Mode ATM Transport Layer (Estended Version) IEEEACM Transactions on Networking Vol 4 Nordm 4 (Aug 1996)

9 R Karabek A Native ATM Protocol Architecture Design and Performance Evaluation IEEE Proceedings 22nd Annual Conference on Local Computer Networks pp 204-210 (1997)

10 D C Feldmeier A framework of architectural concepts for high-speed communications systems IEEE J Select Areas CommunVol11 Nordm 4 (May 1993)

11 T Anker D Breitgand D Dolev Z Levy Congress CONnection-oriented Group-address RESolution Service Proceeding of SPIE97 vol 3233 on Broadband Networking Technologies Nov (1997)

12 kStack httpcometcolumbiaedusoftwarekStack

13 T La Porta and M Schwartz Architectures Features and Implementation of High-Speed Transport Protocols IEEE Network Magazine pp 14-22 (May 1991)

14 ____ B-ISDN ATM Adaptation Layer Service Specific Connection Oriented Protocol (SSCOP) Q2110 ITU-T (10-Mar 1994)

15 J Soleacute-Pareta J Vila-Sallent Network-based paralell computing over ATM using improved SSCOP protocol Computer Communications 19 pp 915-926 (1996)

16 K Obraczka Multicast Transport Protocols A survey and Taxonomy IEEE Communi Magazine (1998)

17 R Venkateswaran CS Raghavendra X Chen and VP Kumar A Scalable Dynamic Multicast Routing Algorithm in ATM Networks IEEE pp 1361-1365 (1997)

18 Matthias Grossglauser and KK Ramakrishnan SEAM Scalable and Efficient ATM Multicast IEEE 1997 pp 867-875 (1997)

19 M Nguyen and M Schwartz MCMP A Transportsession level Distributed Protocol for Desktop Conference Setup IEEE Journal Selected and comunications Vol 14 Nordm 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 Nordm 3 pp 437-443 (April 1998)

22 R Kishimoto Agent communication system for multimedia communication services INFOCOMrsquo96 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 Nordm 3 pp 414-423 (April 1998)

  • ATM - Modo de Transferencia Asiacutencrona
  • Revisioacuten y Clasificacioacuten de Protocolos para Redes de Tecnologiacutea ATM
    • Resumen
    • 1-Introduccioacuten y motivaciones
    • 2- Protocolos nativos ATM
    • 3- Protocolos de transporte para redes ATM
    • 4- Protocolos multipoint
    • 5- Nuevos campos de investigacioacuten
      • Referencias
Page 7: Atm

Nuacutemero de secuencia usado para detectar una insercioacuten o perdida de un paquete Nuacutemero de secuencia para la proteccioacuten usado para corregir errores que ocurren en el

numero de secuencia Indicador de capa de convergencia usado para indicar la presencia de la funcioacuten de la capa

de convergencia

ALL 2

AAL-2 se usa para transferir datos con tasa de bits variable que dependen del tiempo Enviacutea la informacioacuten del tiempo conjuntamente con los datos para que esta puede recuperarse en el destino AAL-2 provee recuperacioacuten de errores e indica la informacioacuten que no puede recuperarse

Capa de convergencia

Esta capa provee para la correccioacuten de errores y transporta la informacioacuten del tiempo desde el origen al destino

Capa de segmentacioacuten y recuperacioacuten

El mensaje es segmentado y se le antildeade 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 informacioacuten es

o BOM comenzando de mensaje o COM continuacioacuten de mensaje o EOM fin de mensaje o indica que el paquete contiene informacioacuten de tiempo u

otra

El payload tambieacuten 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 disentildea para transferir los datos con tasa de bits variable que son independientes del tiempo AAL-3 puede ser dividido en dos modos de operacioacuten

1 Fiable En caso de perdida o mala recepcioacuten de datos estos vuelven a ser enviados El control de flujo es soportado

2 No fiable La recuperacioacuten 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 comuacuten de la capa de convergencia Esto es provisto tambieacuten por el AAL-2 CS Antildeade una cabecera y un payload a la parte comuacuten (ver diagrama)

La cabecera contiene 3 campos Indicador de la parte comuacuten que dice que el payload forma parte de la parte comuacuten Etiqueta de comienzo que indica el comienzo de la parte comuacuten de la capa de

convergencia Tamantildeo del buffer que dice al receptor el espacio necesario para acomodar el mensaje

El payload tambieacuten contiene 3 campos Alineacioacuten 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 comuacuten de la CS(capa de convergencia) El campo de longitud tiene la longitud de la parte comuacuten de la CS

1 Parte especifica del servicio Las funciones proveiacutedas en esta que capa dependen de los servicios pedidos Generalmente se incluyen funciones para la recuperacioacuten y deteccioacuten de errores y puede incluir tambieacuten funciones especiales

Capa de segmentacioacuten y reensamblaje

En esta capa los datos son partidos en paquetes de ATM Una cabecera y el payload que contiene la informacioacuten necesaria para la recuperacioacuten de errores y reensamblaje se antildeaden 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 Continuacioacuten de mensaje EOM Fin de mensaje SSM Mensaje uacutenico en el segmento

2) Numero de secuencia usado para detectar una insercioacuten o una perdida de un paquete 3) Identificador de multiplexacioacuten Este campo se usa para distinguir datos de diferentes comunicaciones que ha sido multiplexadas en una uacutenica conexioacuten de ATM El payload contiene dos de campos 1) Indicado de longitud que indica el nuacutemero de bytes uacutetiles en un paquete parcialmente lleno 2) CRC es para el control de errores

ALL 4

AAL-4 se disentildea para transportar datos con tasa de bits variable independientes del tiempo Es similar al AAL3 y tambieacuten puede operar en transmisioacuten fiable y o fiable AAL-4 provee la capacidad de transferir datos fuera de una conexioacuten expliacutecita

AAL 2 AAL 34 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 traacutefico de redes de aacuterea local (LAN) AAL 2 y AAL 3 soportan paquetes orientados a conexioacuten (Ver figura No5)

(El teacutermino orientado a conexioacuten describe la transferencia de datos despueacutes 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 jamaacutes vean estos errores reportados la degradacioacuten de respuesta o de caudal (through put) seriacutean los uacutenicos siacutentomas A diferencia de los mecanismos de control extremo a extremo que utiliza TCP en internerworking la capacidad de Gbitseg de la red ATM genera un juego de requerimientos necesarios para el control de flujo Si el control del flujo se hiciese como una realimentacioacuten del lazo extremo a extremo en el momento en que el mensaje de control de flujo arribase a la fuente eacutesta habriacutea transmitido ya algunos Mbytes de datos en el sistema exacerbando la congestioacuten Y en el momento en que la fuente reaccionase al mensaje de control la condicioacuten de congestioacuten hubiese podido desaparecer apagando innecesariamente la fuente La constante de tiempo de la realimentacioacuten extremo a extremo en las redes ATM (retardo de realimentacioacuten por producto lazo - ancho de banda) debe ser lo suficientemente alta como para cumplir con las necesidades del usuario sin que la dinaacutemica de la red se vuelva impractica Las condiciones de congestioacuten en las redes ATM estaacuten previstas para que sean extremadamente dinaacutemicas requiriendo de mecanismos de hardware lo suficientemente raacutepidos para llevar a la red al estado estacionario necesitando que la red en siacute eacuteste activamente involucrada en el raacutepido establecimiento de este estado estacionario Sin embargo esta aproximacioacuten simplista de control reactivo de lazo cerrado extremo a extremo en condiciones de congestioacuten no se considera suficiente para las redes ATM El consenso entre los investigadores de este campo arroja recomendaciones que incluyen el empleo de una coleccioacuten de esquemas de control de flujo junto con la colocacioacuten adecuada de los recursos y dimensionamiento de las redes para que aunados se pueda tratar y evadir la congestioacuten ya sea

Detectando y manipulando la congestioacuten que se genera tempranamente monitoreando de cerca las entradassalidas que estaacuten dentro de los conmutadores ATM y reaccionando gradualmente a medida que vaya arribando a ciertos niveles prefijados Tratando y controlando la inyeccioacuten de la conexioacuten de datos dentro de la red en la UNI (unidad interfaz de red) de tal forma que su tasa de inyeccioacuten sea modulada y medida alliacute primero antes de tener que ir a la conexioacuten de usuario a tomar acciones mas draacutesticas El estado de la red debe ser comunicado a la UNI generando raacutepidamente una celda de control de flujo siempre que se vaya a descartar una celda en alguacuten nodo debido a congestioacuten La UNI debe entonces manejar la congestioacuten cambiando su tasa de inyeccioacuten

o notificaacutendola a la conexioacuten de usuario para que cese el flujo dependiendo del nivel de severidad de la congestioacutenEl mayor compromiso durante el control de congestioacuten es el de tratar y afectar solo a los flujos de conexioacuten que son responsables de la congestioacuten y actuar de forma transparente frente a los flujos que observan buen comportamiento Al mismo tiempo permitir que el flujo de conexioacuten utilice tanto ancho de banda como necesite sino hay congestioacuten La recomendacioacuten UIT - T I 371 especifica un contrato de traacutefico que define como el traacutefico del usuario seria administrado El contrato que existe para cada conexion virtual (virtual path o virtual channel) es baacutesicamente un acuerdo entre el usuario y la red con respecto a la Calidad de Servicio (Quality Of Service - Q o S) y los paraacutemetros que regulan el flujo de celdas Estos descriptores de trafico dependen de una particular clase de servicio y pueden incluir bajo la especificacioacuten del ATM Forum UNI a cinco Q o S referenciados en los AALS El objetivo de estas sub clases de servicio es agrupar caracteriacutesticas 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 paraacutemetros pueden incluir el Sustained Cell Rate (SCR) el Miacutenimum Cell Rate (MCR) el Peak Cell Rate (PCR) yo el Burst Tolerance (BT) Para soportar todas las diferentes clases de servicios definidos por los estaacutendares el switch ATM debe ser capaz de definir eacutestos paraacutemetros en base a cada VC o cada VP y debe proveer amortiguadores (buffers) para absorber las raacutefagas de trafico

INTEROPERABILIDAD ENTRE FRAME RELAY Y ATM El objetivo final para todos los servicios descritos anteriormente es una migracioacuten suave de Frame Relay yo SMDS a redes ATM Por ejemplo la recomendacioacuten UIT - T I555 provee un marco para la interoperabilidad de Frame Relay y ATM Para alcanzar una maacutexima eficiencia se trata de brindar este servicio de interoperabilidad en la capa maacutes baja posible mediante conversioacuten de protocolo

PRIMER ESCENARIO

Cuando el servicio de Frame Relay es dado sobre la RDSI en banda ancha y los usuarios se conectan a traveacutes de la UNI de Frame Relay En esta solucioacuten 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 (VCVP) para enlazar los puntos de acceso Frame Relay En este esquema se puede explotar la naturaleza de orientacioacuten a conexioacuten Frame Relay (F R) siguiendo un comportamiento como

El usuario del enrutador pregunta por una conexioacuten al equipo interfaz de red El equipo interfaz de la red coloca las conexiones Frame Relay dentro de una conexioacuten ATM con las direcciones destino apropiadas Por cada trama de equipo interfaz de red traslada de la conexioacuten de Frame Relay a la ATM y viceversa La conexioacuten ATM esta desocupada cuando no se necesitaPara lograr este uacuteltimo punto el manejo de la poliacutetica de conexion del VC sera un aspecto crucial para el desempentildeo de este procedimiento Resulta difiacutecil de terminar el procedimiento para manejar un VC cuando la fuente de traacutefico es no orientada a conexioacuten 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 conexioacuten 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 opcioacuten se toma ventaja del uso actual del FR el cual es proveer un mallado virtual entre diferentes sitios para cargar traacutefico no orientado a conexioacuten 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 conmutacioacuten 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 traveacutes de sus respectivas interfaces de red (NNIs) Esto permitiriacutea a un proveedor de red manejar esta heterogeacutenea red como un todo Frame Relay provee usualmente la interconexioacuten para LAN a pesar de su natural orientacioacuten a conexioacuten 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 sobresimplificacioacuten los dos protocolos (AAL 3 y AAL 5) ofrecen basicamente el mismo servicio CPAAL (Parte Comuacuten 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 implementacioacuten y eficiencia del protocolo que incide en el costo Las caracteriacutesticas a tomar en cuenta cuyo detalle puede ser tema de otro artiacuteculo tienen que ver con Delimitacioacuten y Alineamiento de Tramas Multiplexacioacuten Deteccioacuten de errores de transmisioacuten eficiencia en la transmisioacuten 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 tecnologiacutea de red empresarial virtual del futuro un teacutermino que refleja tanto la evolucioacuten del modelo empresarial global y el eacutenfasis en la conectividad loacutegica donde los usuarios obtienen acceso a los recursos que necesitan y el operador de la red provee las rutas de conexioacuten y asigna el ancho de banda necesario a fuentes de traacutefico muy diferentes (voz datos viacutedeo) Aquellos que construyen y operan redes deben volver los ojos a las capacidades de la tecnologiacutea ATM ya que aspiran a la maacutegica combinacioacuten interconectividad global - escalabilidad de tecnologiacuteas y satisfaccioacuten del cliente local

BIBLIOGRAFIA

1 CCITT Rec I362 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 vol2 No8 ATM Testing crosses network boundaries Jim Frimmel

6 Newslink Alcatel Telecomrsquos customer magazine Vol IV No4 4th Quarter 1996 Adapting Networks to the Internet Challenge Krish Prabhu

Trabajo realizado por

Ivan Dario Cruz PradaNicruz[arroba]col1telecomcomco

Revisioacuten y Clasificacioacuten de Protocolos para Redes de Tecnologiacutea ATM

Joseacute Luis Gonzaacutelez-Saacutenchez y Jordi Domingo-Pascual

ResumenLa tecnologiacutea 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 investigacioacuten maacutes activo con la aspiracioacuten 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 asiacute como las caracteriacutesticas multicast la escalabilidad y la fiabilidad Se profundiza en el concepto de protocolo nativo ATM y son introducidos los protocolos maacutes importantes que satisfacen este importante requerimiento (N3 CONGRESS y kStack entre otros) Es importante destacar tambieacuten los protocolos de transporte pensados especiacuteficamente para la tecnologiacutea ATM La caracteriacutestica multicast (multipoint-to-multipoint) es una de las que maacutes esfuerzo estaacute costando garantizar a ATM pero existen ya propuestas que permiten la comunicacioacuten fiable a elevados anchos de banda y entre muacuteltiples emisores y receptores (SMART MCMP o MWAX) El artiacuteculo concluye con las investigacioness maacutes novedosas en torno a los protocolos ATM como las iniciativas que proponen redes ATM programables o activas (active networks) usando agentes moacuteviles

1-Introduccioacuten y motivacionesLa actual demanda de aplicaciones relacionadas con informacioacuten multimedia como son la video-conferencia audio-conferencia video bajo demanda (VoD) o sistemas colaborativos (pizarras compartidas teletrabajo telemedicina etc) y su coexistencia con aplicaciones maacutes claacutesicas (bases de datos transferencias de ficheros WWW etc) requiere tecnologiacuteas de comunicaciones capaces de ofrecer elevadas prestaciones Estas elevadas prestaciones estaacuten directamente relacionadas con la calidad de servicio (QoS) y concretamente con conceptos claramente parametrizables como el ancho de banda y la velocidad de transmisioacuten (throughput) el retardo de las transferencias (delay) la variabilidad en el retardo (jitter) la fiabilidad (reliability) de las transmisiones las caracteriacutesticas de multidifusioacuten a grupos dispersos de usuarios (multicast) y la posibilidad de gestionar muacuteltiples clases de servicio o flujos de informacioacuten en redes multiclass Para que las nuevas tecnologiacuteas en comunicaciones puedan ofrecer estas caracteriacutesticas es necesario revisar potenciar y ampliar las actuales arquitecturas servicios y protocolosde comunicaciones En los uacuteltimos dos o tres antildeos las investigaciones en el campo de ATM estaacuten dado lugar a importantes propuestas cuyo principal objetivo es ofrecer a las aplicaciones demandadas actualmente algunas o todas las caracteriacutesticas citadas anteriormente Presentamos en este trabajo los conceptos y propuestas maacutes novedosas en el contexto de ATM para ayudar al lector interesado en el dinaacutemico complejo y sofisticado campo de los protocolos de comunicaciones Realizamos la revisioacuten de algunos de los maacutes importantes conceptos teacutecnicas ideas y mecanismos en protocolos de altas prestaciones para redes de tecnologiacutea ATM El principal objetivo de este documento es ofrecer una actualizada visioacuten general no extensiva ni profunda de los protocolos propuestos y en desarrollo para dotar a las diversas clases de servicio ATM de las citadas caracteriacutesticas de calidad de servicio que aporten las potenciales elevadas prestaciones que la tecnologiacutea ATM es capaz de ofrecer El resto del documento estaacute estructurado de la siguiente forma La seccioacuten 2 revisa el concepto de protocolo nativo centrado en el contexto de las redes ATM La seccioacuten 3 describe las propuestas maacutes interesantes actualmente en materia de protocolos de transporte El apartado 4 comenta las transferencias multicast como un importante objetivo para una tecnologiacutea orientada a la conexioacuten como es ATM Concluimos en la seccioacuten 5 con los campos de investigacioacuten abiertos recientemente como son las redes activas y los procolos booster

2- Protocolos nativos ATM

Las aplicaciones nativas ATM estaacuten especiacuteficamente pensadas para usar la tecnologiacutea ATM y para explotar al maacuteximo sus especiales caracteriacutesticas Los protocolos nativos se encargan por tanto de ofrecer esas caracteriacutesticas intriacutensecas de las redes de tecnologiacutea ATM (soporte de QoS sentildealizacioacuten direccionamiento etc) a las aplicaciones nativas ATM (VoD pizarras compartidas video-conferencia) No obstante existen tambieacuten activas investigaciones para conseguir soportar sobre redes ATM aplicaciones no nativas ATM desarrolladas para otras tecnologiacuteas (IP Frame Relay SMDS) En [1] el termino native ATM services define servicios ATM especiacuteficos 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 adaptacioacuten (AALs) Disponibilidad de circuitos virtuales conmutados (SVCs) y circuitos virtuales permanentes (PVCs) Consideraciones relativas a la gestioacuten de traacutefico (clases de servicio garantiacuteas de QoS etc) Posibilidad de distribucioacuten de conexiones y de participacioacuten local en la administracioacuten de la red (protocolos ILMI y OAM)

El propoacutesito de los servicios nativos ATM es ofrecer el acceso a las clases de servicio o a las caracteriacutesticas de QoS en redes ATM Estos servicios nativos tambieacuten ofrecen soporte a un amplio y heterogeacuteneo rango de flujos con diversas propiedades y requerimientos recomendados en [1] Los protocolos de transferencia nativos ATM gestionan la sentildealizacioacuten UNI para establecer los SVCs configurar PVCs y mapear los perfiles de QoS en la correspondiente clase de servicio Los protocolos nativos tambieacuten realizan funciones claacutesicas como las de transporte mecanismos de control de errores transferencia de datos y controles de flujo y de congestioacuten En la referencia [1] se especifica la definicioacuten semaacutentica de los servicios y consideramos que es uacutetil contrastar esta semaacutentica con las redes ATM actuales que usan TCP como capa de transporte e IP-over-ATM como capa de red planteamiento por otro lado poco adecuado [2] por las siguientes razones

Las redes IP no garantizan la QoS extremo-extremo ofrecida por las redes ATM a circuitos individuales IP multiplexa muacuteltiples conexiones de transporte con distintos requerimientos de QoS en VCs simples TCP no soporta ceacutelulas RM (Resource Management) ABR y por consiguiente no puede usar directamente las garantiacuteas de QoS ofrecidas por la red ATM Adaptation Layer 5 (AAL5) realiza labores de checksum para detectar corrupcioacuten de datos TCP tambieacuten realiza estas labores (redundantes con AAL5) costosas en overhead (cada byte de un paquete debe ser chequeado) TCPIP son la representacioacuten de un grupo de protocolos bastante maacutes 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] Ademaacutes 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 tecnologiacutea ATM y tambieacuten existen antiguas y no nativas aplicaciones Este escenario implica cambiar las aplicaciones o proponer nuevas pilas de protocolos nativos ATM La encapsulacioacuten consecutiva de paquetes genera problemas de overhead y funciones redundantes como se ha argumentado anteriormente La limitacioacuten de recursos en los sistemas finales es otra importante motivacioacuten 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 puacuteblicos disfrutan tambieacuten de estas ventajas ATM RDSI y la telefoniacutea ofrecen un esquema de direccionamiento universal basado en NSAPE164 el cual es capaz de enrutar traacutefico de forma nativa Por tanto aunque ATM dispone de protocolos nativos con direccionamiento intriacutenceso estructurado y jeraacuterquico eacuteste no es aprovechado por las aplicaciones que estaacuten 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 tambieacuten existen importantes investigaciones en torno a los protocolos nativos ATM En esta seccioacuten se muestran las propuestas maacutes importantes y actuales en materia de protocolos nativos ATM[2] [7] [8] [9] [10] [11] [12] que a su vezestaacuten sirviendo de base para nuevas investigaciones

[8] presentan el disentildeo implementacioacuten y comportamiento de una pila en modo nativo ATM y contrasta la semaacutentica 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 automaacuteticamente los siguientes problemas

IP-over-ATM no ofrece garantiacutea de QoS pues sus aplicaciones soacutelo ven la interfaz IP El nuacutecleo 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 sentildealizacioacuten 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 caracteriacutesticas la entrega fiable y no fiable de datos con control de flujo Este protocolo de transporte es ampliado en la seccioacuten 5 [2] presenta N3 (Native Non-broadcasting medium access Networking) un protocolo de transporte ligero y nativo ATM La pila N3 se ha disentildeado 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 ademaacutes aporta otras importantes novedades Los principales componentes de N3 incluyen una API sockets ATM nativa un protocolo de transporte ATM y un servicio de nombres ATM (Fig2) El protocolo de transporte ATM propuesto en [2] ofrece soporte para tres diferentes tipos de servicio entrega garantizada (mecanismos de retransmisioacuten) 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 congestioacuten de la transferencia de datagramas y de la multiplexacioacuten 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 maacutes importante El Flow Management se responsabiliza de manipular los flujos de datos desde y hasta la red viacutea la interfaz AAL La segmentacioacuten el reensamblado y el control de errores es tambieacuten 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 congestioacuten y de flujo extremo-extremo maacutes complejo

[7] describe la semaacutentica de una pila de protocolos y explora una nueva arquitectura de protocolo adaptada a la tecnologiacutea ATM y a las aplicaciones multimedia El disentildeo estaacute basado en tres principios baacutesicos separacioacuten de flujos de control y de datos minimizacioacuten del overhead y de la duplicidad de funciones y acceso de las aplicaciones al nivel ATM con garantiacuteas 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-over-ATM 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 moacutedulo CNTL abre una conexioacuten de sentildealizacioacuten con el dispositivo ATM y establece una gestioacuten de las llamadas de mensajes de configuracioacuten PF_ATM separa flujos de datos y de control para aliviar el liacutemite de comportamiento en las comunicaciones Esto permite a los mecanismos de control de traacutefico ser raacutepidos y sencillos mientras los mecanismos de control pueden ser tan complicados como sea necesario Esta separacioacuten permite tambieacuten que los dispositivos puedan estar en los puntos finales de una conexioacuten La interfaz PF_ATM da a las aplicaciones acceso directo a la capa de enlace ATM y extiende las garantiacuteas de QoS a los puntos extremos de la comunicacioacuten Un segundo prototipo[7] es disentildeado e implementado con dos objetivos principales en la optimizacioacuten de la pila nativa ATM

Optimizar los caminos de datos entre los adaptadores ATM aprovechando la separacioacuten de flujos de control y de datos y la capacidad de gestioacuten de datos especiacuteficos de las conexiones de la pila ATM

Optimizar el procesamiento de overheads usando una pila de protocolos nativo ATM en lugar de UDPIP

[11] introduce CONGRESS (CONnection oriented Group-address RESolution Service) otro eficiente protocolo nativo ATM para la resolucioacuten y gestioacuten 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 disentildeo basado en los dos siguientes principios

Disentildeo jeraacuterquico los servicios del protocolo son ofrecidos a las aplicaciones por muacuteltiples servidores organizados jeraacuterquicamente No inundacioacuten se evita la inundacioacuten 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 implementacioacuten sobre Unix y Windows NT estaacute 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 antildeadido un moacutedulo que monitoria la QoS extremo-a-extremo

3- Protocolos de transporte para redes ATMEn los dos o tres uacuteltimos antildeos ha habido numerosos e interesante intentos por disentildear protocolos de transporte La referencia [10] presenta un completo y ya claacutesico resumen de las propuestas maacutes interesantes en materia de protocolos de transporte para redes de alta velocidad (mayoritariamente IP en el artiacuteculo) Ademaacutes la referencia [13] ofrece una interesante visioacuten de las caracteriacutesticas maacutes importantes en los protocolos de elevada velocidad Son estudiadas tambieacuten diversas arquitecturas de protocolos y varias teacutecnicas de implementacioacuten Los protocolos de transporte de elevada velocidad son fuente de activas investigaciones y estaacuten en constante evolucioacuten desde hace maacutes de dos deacutecadas 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 aacutembito de las comunicaciones que ha recibido mayor atencioacuten es la capa de transporte la cuarta capa del OSI-RM de los protocolos de comunicaciones TCP e ISO TP4 son los dos maacutes populares protocolos de transporte Pero centraacutendonos maacutes concretamente en el aacutembito de ATM la literatura presenta varios protocolos de transporte y arquitecturas para redes de alta velocidad revisadas resumidamente a continuacioacuten [7] ofrece una excelente y didaacutectica arquitectura de pila de protocolos para aplicaciones multimedia en modo nativo ATM Esta arquitectura de protocolo ha sido ya descrita brevemente en la seccioacuten anterior [8] presentan el disentildeo implementacioacuten 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 estaacute formada por tres entidades principales aplicacioacuten sentildealizacioacuten y transporte La siguiente Tabla 1 muestra un conjunto de nueve baacutesicos 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 combinacioacuten de servicios La marca X indica el servicio baacutesico soportado en cada clase de servicio general

Clases de servicio

Servicios Servicio de comportamiento

garantizado

Servicio fiable Servicio Best effort

- Transferencia Simplex de datos

X X X

- Control de errores - deteccion de errorestimeouts retransmisiones

No existente (ofrecido por

AAL5)

- Bucle abierto - Control de flujo realimentado

No existente -

- X

- No existente

- Tamantildeo de mensaje ilimitado

X X X

- Eleccioacuten de blocking - Aplicacioacuten Non-blocking

X X

X X

X X

- Eleccioacuten de byte stream - Semaacutentica transferencia de mensajes

X X

X X

X X

- Garantiacuteas de QoS requerimientos de ancho de banda

No soportado No soportado

- Reserva de recursos X No existente No existente

- Transferencias Multicast X No soportado Para servicios no fiables

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 recuperacioacuten de peacuterdidas del protocolo estaacutendar SSCOP [14] y demuestran que el resultado ofrece baja latencia eficiente recuperacioacuten de ceacutelulas perdidas y es tan robusto como el estaacutendar SSCOP

4- Protocolos multipointEl crecimiento de las redes ATM viene motivado en parte por la demanda de servicios multimedia para grupos dispersos de usuarios El traacutefico multicast tiene caracteriacutesticas particulares descritas para ATM en UNI 40 [6] y anteriores [5] La distribucioacuten de informacioacuten punto-a-multipunto (uno-a-muchos) o multipunto-a-multipunto (muchos-a-muchos) es un objetivo baacutesico propuesto por varios protocolos y arquitecturas ATM que ofrecen el soporte multimedia yo multicast como audio-conferencia video-conferencia trabajos colaborativos o VoD ATM es auacuten una tecnologiacutea emergente disentildeada 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 30) para ATM define conexiones punto-a-multipunto y las conexiones multipunto-a-multipunto soacutelo 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 topologiacutea completamente mallada todos-con-todos Aunque esta topologiacutea ofrece conexiones multipunto-a-multipunto hay que destacar que no escala bien cuando el nuacutemero de participantes es elevado Una alternativa al anterior esquema es el uso de un servidor que actuacutea a modo de raiacutez en el aacuterbol multipunto Este meacutetodo soacutelo requiere un nodo raiacutez para almacenar informacioacuten pero la desventaja de este meacutetodo son las potenciales congestiones en el servidor

cuando debe encargarse de enviacuteos y retransmisiones de las conexiones multipunto-a-multipunto

Para solventar las limitaciones de UNI 30 y UNI 31 [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 sentildealizacioacuten ATM (UNI 31 UNI 40) [4][5][6] Comenzamos destacando la referencia [16] como un reciente trabajo que revisa y compara los protocolos de transporte multicast maacutes importantes en Internet como MTP-2 XTP RTP SRM RAMP RMTP MFTP STORM etc IETF e IRTF (como ITU-T y ATM Forum) tambieacuten impulsan una importante actividad en este campo La referencia [16] revisa los maacutes representativos protocolos multicast y los clasifica de acuerdo a la taxonomiacutea de varias caracteriacutesticas (propagacioacuten de datos mecanismos de fiabilidad retransmisiones control de congestioacuten y de flujo gestioacuten de grupos multicast etc) En Internet los mecanismos efectivos de control de congestioacuten son una de las prioridades en las investigaciones de las transferencias multicast fiables Los mecanismos de seguridad y las teacutecnicas escalables de recuperacioacuten 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 maacutes importantes caracteriacutesticas En esta seccioacuten 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 maacutes interesantes en los siguientes paacuterrafos SMART (shared many-to-many ATM reservations)[3] es un protocolo para controlar un aacuterbol ATM multicast compartido soportando comunicaciones muchos-a-muchos (many-to-many) Esta propuesta tiene importantes caracteriacutesticas como que reside completamente en la capa ATM y no requiere ninguacuten servidor soporta uno o varios VCCs (y tambieacuten VPCs) cuyo nuacutemero es libremente configurado y es independiente del nuacutemero de puntos finales usa el concepto de bloques de datos como en la clase de servicio ABT y tambieacuten permite VCCs de las clases CBR VBR o UBR el protocolo garantiza que no existen puntos de interrelacioacuten en los VCC del aacuterbol son respetadas las garantiacuteas del contrato de traacutefico asociado con los VCCs etc SMART puede ser entendido como un protocolo completamente distribuido para coordinar la distribucioacuten de VPIsVCIs 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 ceacutelulas de datos desde diferentes fuentes pueden llegar intercaladas a un destinatario) y tambieacuten Demand Sharing (los recursos asignados a conexiones muchos-a-muchos son dinaacutemicamente compartidas entre todas las potenciales fuentes El artiacuteculo [3] describe el protocolo SMART formal e informalmente y propone completas pruebas de correccioacuten y un detallado anaacutelisis de comportamiento para estudios futuros Tambieacuten son sugeridas otras investigaciones como son ofrecer justicia en los accesos a los aacuterboles multicast investigar las ceacutelulas RM perioacutedicamente para aliviar las congestiones en la red o disminuir el tiempo de acceso del usuario a los aacuterboles de distribucioacuten multicast anaacutelisis de las ceacutelulas RM dentro de cada VCC o fuera enviando todas las ceacutelulas RM en un VCC dedicado En [17] se presenta MWAX un algoritmo dinaacutemico 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 artiacuteculo describe un esquema jeraacuterquico basado en CBT para incorporar routing multipunto-a-multipunto en PNNI En el algoritmo los nodos core actuacutean como participantes pasivos para eliminar la dependencia en la seleccioacuten de estos nodos Con un mecanismo de backup se consigue un algoritmo tolerante a fallos en los nodos core lo cual puede ser faacutecilmente 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 jerarquiacutea SEAM (Scalable and Efficient ATM Multicast) [18] propone una arquitectura escalable eficiente y multicast multipunto-a-multipunto para redes ATM que usa un soacutelo VC para un grupo multicast de muacuteltiples 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 Tambieacuten realiza aportaciones para conseguir soportar IP multicast sobre redes ATM extensas

SEAM usa un soacutelo aacuterbol de distribucioacuten 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 sentildealizacioacuten del grupo Este trabajo deja abiertas investigaciones referentes a la gestioacuten de traacutefico y a la entrega fiable de traacuteficos multicasting Concluimos esta seccioacuten destacando MCMP (Multiparty Conference Management Protocol) [19] que sin estar pensado especiacuteficamente para ATM es un protocolo de nivel sesioacutentransporte distribuido extremo-extremo y desarrollado para gestioacuten de grupos de aplicaciones de conferencia MCMP es un conjunto de algoritmos de control distribuido para configuracioacuten de conferencias multipunto y gestioacuten de miembros de grupos de usuarios Conceptualmente MCMP reside en el nivel de sesioacuten en el que se establece la infraestructura para activar la transferencia de informacioacuten entre los participantes en la conferencia Pero funcionalmente el protocolo acompasa los niveles de sesioacuten y de transporte pues utiliza directamente servicios del nivel de red Son destacables las condiciones de correccioacuten (conectividad validacioacuten unicidad consistencia y terminacioacuten) que deben ser satisfechas una vez que la conferencia ha sido configurada por el algoritmo de configuracioacuten de MCMP El artiacuteculo muestra exhaustivas pruebas de correccioacuten para uno de los algoritmos y tambieacuten describe la especificacioacuten y verificacioacuten del protocolo

5- Nuevos campos de investigacioacutenEn todas las redes existen gran variedad de elementos hardware (switchs routers bridges brouters hubs ETDs etc) que realizan muy diversas funciones (conmutacioacuten routing puenteo controles de congestioacuten y de flujo garantiacutea de QoS ejecucioacuten de aplicaciones etc) En la actualidad la red es mayormente un canal de comunicacioacuten para transferir paquetes entre equipos finales (ayudada por los elementos hardware antes citados) Pero tambieacuten se estaacuten realizando importante esfuerzos para equipar a los elementos hardware con elevadas prestaciones aportadas por diversas teacutecnicas software Esto dota a la red de caracteriacutesticas activas (active networks) en el sentido de que los elementos hardware que la componen computan modifican u operan los contenidos de los paquetes y tambieacuten seraacuten capaces de transferir o propagar coacutedigo Por consiguiente una red activa es una red programable [20] es una excelente revisioacuten de este novedoso campo de investigacioacuten que discute dos planteamientos en la realizacioacuten de redes activas la idea del conmutador programable y la de la caacutepsula Una red es activa si en sus aacuterboles de distribucioacuten multicast existen nodos activos con capacidad para ejecutar programas yo capaces de implementar mecanismos de propagacioacuten de coacutedigo Algunas de las ventajas de los protocolos activos son conseguidas instalando nodos activos en puntos estrateacutegicos de la red Otro nuevo concepto es presentado en [21] como una metodologiacutea para el disentildeo de protocolos Los protocol boosters son una nueva contribucioacuten a las redes activas o programables Una ventaja de los boosters es que pueden ser faacutecilmente 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 aacuterea extensa Este papel introduce una arquitectura software orientada a agente y propone el concepto de agente de comunicacioacuten para servicio de comunicacioacuten 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 artiacuteculo muestra agentes software moacuteviles usados para implementar operaciones robustas y funciones de mantenimiento en redes ATM Los agentes desempentildean un rol similar al de las ceacutelulas OAM en ATM estaacutendar pues son transmitidos entre entidades de control a intervalos regulares usando recursos predefinidos La diferencia entre los agentes moacuteviles y las ceacutelulas OAM reside en que eacutestos pueden contener coacutedigo Para concluir destacar que la integracioacuten del traacutefico IP sobre tecnologiacutea ATM es tambieacuten uno de los campos maacutes activos en la actualidad En esta liacutenea pueden destacarse los siguientes protocolos IP-over-ATM IP Switching Tag Switching NHRP MPOA IMSS CSR ARIS AREQUIPARED y EPD Referencias

1 ____ Native ATM Service Semantic Description Version 1 ATM Forum Technical Committee ATM Forum Document af-saa-0048000 (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 Broadband Networks Multimedia Applications Services and Techniques ECMASTrsquo98 Springer (May 1998)

3 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 Nordm 3 (April 1997)

4 W D Zhong K Yukimatsu Design requeriments and architectures for multicast ATM switching IEICE Trans Com Vol E77-B pp 1420-1428 (Nov 1994)

5 ____ ATM user-network interface version 31 specification ATM Forum (1994)

6 ____ Traffic Management Specification Version 40 ATM Forum Technical Committee ATM Forum Document af-tm-0056000 (April 1996)

7 D Kandlur D Saha and W Willebeck Protocol Architecture for multimedia Application over ATM Networks IEEE Journal Selected and Communications Vol 14 Nordm 7 pp 1349-1359 (Sep 1996)

8 R Ahuja S Keshav and H Saran Design Implementation and Performance Measurement of a Native-Mode ATM Transport Layer (Estended Version) IEEEACM Transactions on Networking Vol 4 Nordm 4 (Aug 1996)

9 R Karabek A Native ATM Protocol Architecture Design and Performance Evaluation IEEE Proceedings 22nd Annual Conference on Local Computer Networks pp 204-210 (1997)

10 D C Feldmeier A framework of architectural concepts for high-speed communications systems IEEE J Select Areas CommunVol11 Nordm 4 (May 1993)

11 T Anker D Breitgand D Dolev Z Levy Congress CONnection-oriented Group-address RESolution Service Proceeding of SPIE97 vol 3233 on Broadband Networking Technologies Nov (1997)

12 kStack httpcometcolumbiaedusoftwarekStack

13 T La Porta and M Schwartz Architectures Features and Implementation of High-Speed Transport Protocols IEEE Network Magazine pp 14-22 (May 1991)

14 ____ B-ISDN ATM Adaptation Layer Service Specific Connection Oriented Protocol (SSCOP) Q2110 ITU-T (10-Mar 1994)

15 J Soleacute-Pareta J Vila-Sallent Network-based paralell computing over ATM using improved SSCOP protocol Computer Communications 19 pp 915-926 (1996)

16 K Obraczka Multicast Transport Protocols A survey and Taxonomy IEEE Communi Magazine (1998)

17 R Venkateswaran CS Raghavendra X Chen and VP Kumar A Scalable Dynamic Multicast Routing Algorithm in ATM Networks IEEE pp 1361-1365 (1997)

18 Matthias Grossglauser and KK Ramakrishnan SEAM Scalable and Efficient ATM Multicast IEEE 1997 pp 867-875 (1997)

19 M Nguyen and M Schwartz MCMP A Transportsession level Distributed Protocol for Desktop Conference Setup IEEE Journal Selected and comunications Vol 14 Nordm 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 Nordm 3 pp 437-443 (April 1998)

22 R Kishimoto Agent communication system for multimedia communication services INFOCOMrsquo96 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 Nordm 3 pp 414-423 (April 1998)

  • ATM - Modo de Transferencia Asiacutencrona
  • Revisioacuten y Clasificacioacuten de Protocolos para Redes de Tecnologiacutea ATM
    • Resumen
    • 1-Introduccioacuten y motivaciones
    • 2- Protocolos nativos ATM
    • 3- Protocolos de transporte para redes ATM
    • 4- Protocolos multipoint
    • 5- Nuevos campos de investigacioacuten
      • Referencias
Page 8: Atm

1 Parte comuacuten de la capa de convergencia Esto es provisto tambieacuten por el AAL-2 CS Antildeade una cabecera y un payload a la parte comuacuten (ver diagrama)

La cabecera contiene 3 campos Indicador de la parte comuacuten que dice que el payload forma parte de la parte comuacuten Etiqueta de comienzo que indica el comienzo de la parte comuacuten de la capa de

convergencia Tamantildeo del buffer que dice al receptor el espacio necesario para acomodar el mensaje

El payload tambieacuten contiene 3 campos Alineacioacuten 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 comuacuten de la CS(capa de convergencia) El campo de longitud tiene la longitud de la parte comuacuten de la CS

1 Parte especifica del servicio Las funciones proveiacutedas en esta que capa dependen de los servicios pedidos Generalmente se incluyen funciones para la recuperacioacuten y deteccioacuten de errores y puede incluir tambieacuten funciones especiales

Capa de segmentacioacuten y reensamblaje

En esta capa los datos son partidos en paquetes de ATM Una cabecera y el payload que contiene la informacioacuten necesaria para la recuperacioacuten de errores y reensamblaje se antildeaden 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 Continuacioacuten de mensaje EOM Fin de mensaje SSM Mensaje uacutenico en el segmento

2) Numero de secuencia usado para detectar una insercioacuten o una perdida de un paquete 3) Identificador de multiplexacioacuten Este campo se usa para distinguir datos de diferentes comunicaciones que ha sido multiplexadas en una uacutenica conexioacuten de ATM El payload contiene dos de campos 1) Indicado de longitud que indica el nuacutemero de bytes uacutetiles en un paquete parcialmente lleno 2) CRC es para el control de errores

ALL 4

AAL-4 se disentildea para transportar datos con tasa de bits variable independientes del tiempo Es similar al AAL3 y tambieacuten puede operar en transmisioacuten fiable y o fiable AAL-4 provee la capacidad de transferir datos fuera de una conexioacuten expliacutecita

AAL 2 AAL 34 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 traacutefico de redes de aacuterea local (LAN) AAL 2 y AAL 3 soportan paquetes orientados a conexioacuten (Ver figura No5)

(El teacutermino orientado a conexioacuten describe la transferencia de datos despueacutes 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 jamaacutes vean estos errores reportados la degradacioacuten de respuesta o de caudal (through put) seriacutean los uacutenicos siacutentomas A diferencia de los mecanismos de control extremo a extremo que utiliza TCP en internerworking la capacidad de Gbitseg de la red ATM genera un juego de requerimientos necesarios para el control de flujo Si el control del flujo se hiciese como una realimentacioacuten del lazo extremo a extremo en el momento en que el mensaje de control de flujo arribase a la fuente eacutesta habriacutea transmitido ya algunos Mbytes de datos en el sistema exacerbando la congestioacuten Y en el momento en que la fuente reaccionase al mensaje de control la condicioacuten de congestioacuten hubiese podido desaparecer apagando innecesariamente la fuente La constante de tiempo de la realimentacioacuten extremo a extremo en las redes ATM (retardo de realimentacioacuten por producto lazo - ancho de banda) debe ser lo suficientemente alta como para cumplir con las necesidades del usuario sin que la dinaacutemica de la red se vuelva impractica Las condiciones de congestioacuten en las redes ATM estaacuten previstas para que sean extremadamente dinaacutemicas requiriendo de mecanismos de hardware lo suficientemente raacutepidos para llevar a la red al estado estacionario necesitando que la red en siacute eacuteste activamente involucrada en el raacutepido establecimiento de este estado estacionario Sin embargo esta aproximacioacuten simplista de control reactivo de lazo cerrado extremo a extremo en condiciones de congestioacuten no se considera suficiente para las redes ATM El consenso entre los investigadores de este campo arroja recomendaciones que incluyen el empleo de una coleccioacuten de esquemas de control de flujo junto con la colocacioacuten adecuada de los recursos y dimensionamiento de las redes para que aunados se pueda tratar y evadir la congestioacuten ya sea

Detectando y manipulando la congestioacuten que se genera tempranamente monitoreando de cerca las entradassalidas que estaacuten dentro de los conmutadores ATM y reaccionando gradualmente a medida que vaya arribando a ciertos niveles prefijados Tratando y controlando la inyeccioacuten de la conexioacuten de datos dentro de la red en la UNI (unidad interfaz de red) de tal forma que su tasa de inyeccioacuten sea modulada y medida alliacute primero antes de tener que ir a la conexioacuten de usuario a tomar acciones mas draacutesticas El estado de la red debe ser comunicado a la UNI generando raacutepidamente una celda de control de flujo siempre que se vaya a descartar una celda en alguacuten nodo debido a congestioacuten La UNI debe entonces manejar la congestioacuten cambiando su tasa de inyeccioacuten

o notificaacutendola a la conexioacuten de usuario para que cese el flujo dependiendo del nivel de severidad de la congestioacutenEl mayor compromiso durante el control de congestioacuten es el de tratar y afectar solo a los flujos de conexioacuten que son responsables de la congestioacuten y actuar de forma transparente frente a los flujos que observan buen comportamiento Al mismo tiempo permitir que el flujo de conexioacuten utilice tanto ancho de banda como necesite sino hay congestioacuten La recomendacioacuten UIT - T I 371 especifica un contrato de traacutefico que define como el traacutefico del usuario seria administrado El contrato que existe para cada conexion virtual (virtual path o virtual channel) es baacutesicamente un acuerdo entre el usuario y la red con respecto a la Calidad de Servicio (Quality Of Service - Q o S) y los paraacutemetros que regulan el flujo de celdas Estos descriptores de trafico dependen de una particular clase de servicio y pueden incluir bajo la especificacioacuten del ATM Forum UNI a cinco Q o S referenciados en los AALS El objetivo de estas sub clases de servicio es agrupar caracteriacutesticas 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 paraacutemetros pueden incluir el Sustained Cell Rate (SCR) el Miacutenimum Cell Rate (MCR) el Peak Cell Rate (PCR) yo el Burst Tolerance (BT) Para soportar todas las diferentes clases de servicios definidos por los estaacutendares el switch ATM debe ser capaz de definir eacutestos paraacutemetros en base a cada VC o cada VP y debe proveer amortiguadores (buffers) para absorber las raacutefagas de trafico

INTEROPERABILIDAD ENTRE FRAME RELAY Y ATM El objetivo final para todos los servicios descritos anteriormente es una migracioacuten suave de Frame Relay yo SMDS a redes ATM Por ejemplo la recomendacioacuten UIT - T I555 provee un marco para la interoperabilidad de Frame Relay y ATM Para alcanzar una maacutexima eficiencia se trata de brindar este servicio de interoperabilidad en la capa maacutes baja posible mediante conversioacuten de protocolo

PRIMER ESCENARIO

Cuando el servicio de Frame Relay es dado sobre la RDSI en banda ancha y los usuarios se conectan a traveacutes de la UNI de Frame Relay En esta solucioacuten 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 (VCVP) para enlazar los puntos de acceso Frame Relay En este esquema se puede explotar la naturaleza de orientacioacuten a conexioacuten Frame Relay (F R) siguiendo un comportamiento como

El usuario del enrutador pregunta por una conexioacuten al equipo interfaz de red El equipo interfaz de la red coloca las conexiones Frame Relay dentro de una conexioacuten ATM con las direcciones destino apropiadas Por cada trama de equipo interfaz de red traslada de la conexioacuten de Frame Relay a la ATM y viceversa La conexioacuten ATM esta desocupada cuando no se necesitaPara lograr este uacuteltimo punto el manejo de la poliacutetica de conexion del VC sera un aspecto crucial para el desempentildeo de este procedimiento Resulta difiacutecil de terminar el procedimiento para manejar un VC cuando la fuente de traacutefico es no orientada a conexioacuten 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 conexioacuten 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 opcioacuten se toma ventaja del uso actual del FR el cual es proveer un mallado virtual entre diferentes sitios para cargar traacutefico no orientado a conexioacuten 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 conmutacioacuten 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 traveacutes de sus respectivas interfaces de red (NNIs) Esto permitiriacutea a un proveedor de red manejar esta heterogeacutenea red como un todo Frame Relay provee usualmente la interconexioacuten para LAN a pesar de su natural orientacioacuten a conexioacuten 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 sobresimplificacioacuten los dos protocolos (AAL 3 y AAL 5) ofrecen basicamente el mismo servicio CPAAL (Parte Comuacuten 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 implementacioacuten y eficiencia del protocolo que incide en el costo Las caracteriacutesticas a tomar en cuenta cuyo detalle puede ser tema de otro artiacuteculo tienen que ver con Delimitacioacuten y Alineamiento de Tramas Multiplexacioacuten Deteccioacuten de errores de transmisioacuten eficiencia en la transmisioacuten 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 tecnologiacutea de red empresarial virtual del futuro un teacutermino que refleja tanto la evolucioacuten del modelo empresarial global y el eacutenfasis en la conectividad loacutegica donde los usuarios obtienen acceso a los recursos que necesitan y el operador de la red provee las rutas de conexioacuten y asigna el ancho de banda necesario a fuentes de traacutefico muy diferentes (voz datos viacutedeo) Aquellos que construyen y operan redes deben volver los ojos a las capacidades de la tecnologiacutea ATM ya que aspiran a la maacutegica combinacioacuten interconectividad global - escalabilidad de tecnologiacuteas y satisfaccioacuten del cliente local

BIBLIOGRAFIA

1 CCITT Rec I362 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 vol2 No8 ATM Testing crosses network boundaries Jim Frimmel

6 Newslink Alcatel Telecomrsquos customer magazine Vol IV No4 4th Quarter 1996 Adapting Networks to the Internet Challenge Krish Prabhu

Trabajo realizado por

Ivan Dario Cruz PradaNicruz[arroba]col1telecomcomco

Revisioacuten y Clasificacioacuten de Protocolos para Redes de Tecnologiacutea ATM

Joseacute Luis Gonzaacutelez-Saacutenchez y Jordi Domingo-Pascual

ResumenLa tecnologiacutea 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 investigacioacuten maacutes activo con la aspiracioacuten 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 asiacute como las caracteriacutesticas multicast la escalabilidad y la fiabilidad Se profundiza en el concepto de protocolo nativo ATM y son introducidos los protocolos maacutes importantes que satisfacen este importante requerimiento (N3 CONGRESS y kStack entre otros) Es importante destacar tambieacuten los protocolos de transporte pensados especiacuteficamente para la tecnologiacutea ATM La caracteriacutestica multicast (multipoint-to-multipoint) es una de las que maacutes esfuerzo estaacute costando garantizar a ATM pero existen ya propuestas que permiten la comunicacioacuten fiable a elevados anchos de banda y entre muacuteltiples emisores y receptores (SMART MCMP o MWAX) El artiacuteculo concluye con las investigacioness maacutes novedosas en torno a los protocolos ATM como las iniciativas que proponen redes ATM programables o activas (active networks) usando agentes moacuteviles

1-Introduccioacuten y motivacionesLa actual demanda de aplicaciones relacionadas con informacioacuten multimedia como son la video-conferencia audio-conferencia video bajo demanda (VoD) o sistemas colaborativos (pizarras compartidas teletrabajo telemedicina etc) y su coexistencia con aplicaciones maacutes claacutesicas (bases de datos transferencias de ficheros WWW etc) requiere tecnologiacuteas de comunicaciones capaces de ofrecer elevadas prestaciones Estas elevadas prestaciones estaacuten directamente relacionadas con la calidad de servicio (QoS) y concretamente con conceptos claramente parametrizables como el ancho de banda y la velocidad de transmisioacuten (throughput) el retardo de las transferencias (delay) la variabilidad en el retardo (jitter) la fiabilidad (reliability) de las transmisiones las caracteriacutesticas de multidifusioacuten a grupos dispersos de usuarios (multicast) y la posibilidad de gestionar muacuteltiples clases de servicio o flujos de informacioacuten en redes multiclass Para que las nuevas tecnologiacuteas en comunicaciones puedan ofrecer estas caracteriacutesticas es necesario revisar potenciar y ampliar las actuales arquitecturas servicios y protocolosde comunicaciones En los uacuteltimos dos o tres antildeos las investigaciones en el campo de ATM estaacuten dado lugar a importantes propuestas cuyo principal objetivo es ofrecer a las aplicaciones demandadas actualmente algunas o todas las caracteriacutesticas citadas anteriormente Presentamos en este trabajo los conceptos y propuestas maacutes novedosas en el contexto de ATM para ayudar al lector interesado en el dinaacutemico complejo y sofisticado campo de los protocolos de comunicaciones Realizamos la revisioacuten de algunos de los maacutes importantes conceptos teacutecnicas ideas y mecanismos en protocolos de altas prestaciones para redes de tecnologiacutea ATM El principal objetivo de este documento es ofrecer una actualizada visioacuten general no extensiva ni profunda de los protocolos propuestos y en desarrollo para dotar a las diversas clases de servicio ATM de las citadas caracteriacutesticas de calidad de servicio que aporten las potenciales elevadas prestaciones que la tecnologiacutea ATM es capaz de ofrecer El resto del documento estaacute estructurado de la siguiente forma La seccioacuten 2 revisa el concepto de protocolo nativo centrado en el contexto de las redes ATM La seccioacuten 3 describe las propuestas maacutes interesantes actualmente en materia de protocolos de transporte El apartado 4 comenta las transferencias multicast como un importante objetivo para una tecnologiacutea orientada a la conexioacuten como es ATM Concluimos en la seccioacuten 5 con los campos de investigacioacuten abiertos recientemente como son las redes activas y los procolos booster

2- Protocolos nativos ATM

Las aplicaciones nativas ATM estaacuten especiacuteficamente pensadas para usar la tecnologiacutea ATM y para explotar al maacuteximo sus especiales caracteriacutesticas Los protocolos nativos se encargan por tanto de ofrecer esas caracteriacutesticas intriacutensecas de las redes de tecnologiacutea ATM (soporte de QoS sentildealizacioacuten direccionamiento etc) a las aplicaciones nativas ATM (VoD pizarras compartidas video-conferencia) No obstante existen tambieacuten activas investigaciones para conseguir soportar sobre redes ATM aplicaciones no nativas ATM desarrolladas para otras tecnologiacuteas (IP Frame Relay SMDS) En [1] el termino native ATM services define servicios ATM especiacuteficos 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 adaptacioacuten (AALs) Disponibilidad de circuitos virtuales conmutados (SVCs) y circuitos virtuales permanentes (PVCs) Consideraciones relativas a la gestioacuten de traacutefico (clases de servicio garantiacuteas de QoS etc) Posibilidad de distribucioacuten de conexiones y de participacioacuten local en la administracioacuten de la red (protocolos ILMI y OAM)

El propoacutesito de los servicios nativos ATM es ofrecer el acceso a las clases de servicio o a las caracteriacutesticas de QoS en redes ATM Estos servicios nativos tambieacuten ofrecen soporte a un amplio y heterogeacuteneo rango de flujos con diversas propiedades y requerimientos recomendados en [1] Los protocolos de transferencia nativos ATM gestionan la sentildealizacioacuten UNI para establecer los SVCs configurar PVCs y mapear los perfiles de QoS en la correspondiente clase de servicio Los protocolos nativos tambieacuten realizan funciones claacutesicas como las de transporte mecanismos de control de errores transferencia de datos y controles de flujo y de congestioacuten En la referencia [1] se especifica la definicioacuten semaacutentica de los servicios y consideramos que es uacutetil contrastar esta semaacutentica con las redes ATM actuales que usan TCP como capa de transporte e IP-over-ATM como capa de red planteamiento por otro lado poco adecuado [2] por las siguientes razones

Las redes IP no garantizan la QoS extremo-extremo ofrecida por las redes ATM a circuitos individuales IP multiplexa muacuteltiples conexiones de transporte con distintos requerimientos de QoS en VCs simples TCP no soporta ceacutelulas RM (Resource Management) ABR y por consiguiente no puede usar directamente las garantiacuteas de QoS ofrecidas por la red ATM Adaptation Layer 5 (AAL5) realiza labores de checksum para detectar corrupcioacuten de datos TCP tambieacuten realiza estas labores (redundantes con AAL5) costosas en overhead (cada byte de un paquete debe ser chequeado) TCPIP son la representacioacuten de un grupo de protocolos bastante maacutes 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] Ademaacutes 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 tecnologiacutea ATM y tambieacuten existen antiguas y no nativas aplicaciones Este escenario implica cambiar las aplicaciones o proponer nuevas pilas de protocolos nativos ATM La encapsulacioacuten consecutiva de paquetes genera problemas de overhead y funciones redundantes como se ha argumentado anteriormente La limitacioacuten de recursos en los sistemas finales es otra importante motivacioacuten 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 puacuteblicos disfrutan tambieacuten de estas ventajas ATM RDSI y la telefoniacutea ofrecen un esquema de direccionamiento universal basado en NSAPE164 el cual es capaz de enrutar traacutefico de forma nativa Por tanto aunque ATM dispone de protocolos nativos con direccionamiento intriacutenceso estructurado y jeraacuterquico eacuteste no es aprovechado por las aplicaciones que estaacuten 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 tambieacuten existen importantes investigaciones en torno a los protocolos nativos ATM En esta seccioacuten se muestran las propuestas maacutes importantes y actuales en materia de protocolos nativos ATM[2] [7] [8] [9] [10] [11] [12] que a su vezestaacuten sirviendo de base para nuevas investigaciones

[8] presentan el disentildeo implementacioacuten y comportamiento de una pila en modo nativo ATM y contrasta la semaacutentica 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 automaacuteticamente los siguientes problemas

IP-over-ATM no ofrece garantiacutea de QoS pues sus aplicaciones soacutelo ven la interfaz IP El nuacutecleo 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 sentildealizacioacuten 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 caracteriacutesticas la entrega fiable y no fiable de datos con control de flujo Este protocolo de transporte es ampliado en la seccioacuten 5 [2] presenta N3 (Native Non-broadcasting medium access Networking) un protocolo de transporte ligero y nativo ATM La pila N3 se ha disentildeado 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 ademaacutes aporta otras importantes novedades Los principales componentes de N3 incluyen una API sockets ATM nativa un protocolo de transporte ATM y un servicio de nombres ATM (Fig2) El protocolo de transporte ATM propuesto en [2] ofrece soporte para tres diferentes tipos de servicio entrega garantizada (mecanismos de retransmisioacuten) 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 congestioacuten de la transferencia de datagramas y de la multiplexacioacuten 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 maacutes importante El Flow Management se responsabiliza de manipular los flujos de datos desde y hasta la red viacutea la interfaz AAL La segmentacioacuten el reensamblado y el control de errores es tambieacuten 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 congestioacuten y de flujo extremo-extremo maacutes complejo

[7] describe la semaacutentica de una pila de protocolos y explora una nueva arquitectura de protocolo adaptada a la tecnologiacutea ATM y a las aplicaciones multimedia El disentildeo estaacute basado en tres principios baacutesicos separacioacuten de flujos de control y de datos minimizacioacuten del overhead y de la duplicidad de funciones y acceso de las aplicaciones al nivel ATM con garantiacuteas 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-over-ATM 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 moacutedulo CNTL abre una conexioacuten de sentildealizacioacuten con el dispositivo ATM y establece una gestioacuten de las llamadas de mensajes de configuracioacuten PF_ATM separa flujos de datos y de control para aliviar el liacutemite de comportamiento en las comunicaciones Esto permite a los mecanismos de control de traacutefico ser raacutepidos y sencillos mientras los mecanismos de control pueden ser tan complicados como sea necesario Esta separacioacuten permite tambieacuten que los dispositivos puedan estar en los puntos finales de una conexioacuten La interfaz PF_ATM da a las aplicaciones acceso directo a la capa de enlace ATM y extiende las garantiacuteas de QoS a los puntos extremos de la comunicacioacuten Un segundo prototipo[7] es disentildeado e implementado con dos objetivos principales en la optimizacioacuten de la pila nativa ATM

Optimizar los caminos de datos entre los adaptadores ATM aprovechando la separacioacuten de flujos de control y de datos y la capacidad de gestioacuten de datos especiacuteficos de las conexiones de la pila ATM

Optimizar el procesamiento de overheads usando una pila de protocolos nativo ATM en lugar de UDPIP

[11] introduce CONGRESS (CONnection oriented Group-address RESolution Service) otro eficiente protocolo nativo ATM para la resolucioacuten y gestioacuten 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 disentildeo basado en los dos siguientes principios

Disentildeo jeraacuterquico los servicios del protocolo son ofrecidos a las aplicaciones por muacuteltiples servidores organizados jeraacuterquicamente No inundacioacuten se evita la inundacioacuten 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 implementacioacuten sobre Unix y Windows NT estaacute 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 antildeadido un moacutedulo que monitoria la QoS extremo-a-extremo

3- Protocolos de transporte para redes ATMEn los dos o tres uacuteltimos antildeos ha habido numerosos e interesante intentos por disentildear protocolos de transporte La referencia [10] presenta un completo y ya claacutesico resumen de las propuestas maacutes interesantes en materia de protocolos de transporte para redes de alta velocidad (mayoritariamente IP en el artiacuteculo) Ademaacutes la referencia [13] ofrece una interesante visioacuten de las caracteriacutesticas maacutes importantes en los protocolos de elevada velocidad Son estudiadas tambieacuten diversas arquitecturas de protocolos y varias teacutecnicas de implementacioacuten Los protocolos de transporte de elevada velocidad son fuente de activas investigaciones y estaacuten en constante evolucioacuten desde hace maacutes de dos deacutecadas 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 aacutembito de las comunicaciones que ha recibido mayor atencioacuten es la capa de transporte la cuarta capa del OSI-RM de los protocolos de comunicaciones TCP e ISO TP4 son los dos maacutes populares protocolos de transporte Pero centraacutendonos maacutes concretamente en el aacutembito de ATM la literatura presenta varios protocolos de transporte y arquitecturas para redes de alta velocidad revisadas resumidamente a continuacioacuten [7] ofrece una excelente y didaacutectica arquitectura de pila de protocolos para aplicaciones multimedia en modo nativo ATM Esta arquitectura de protocolo ha sido ya descrita brevemente en la seccioacuten anterior [8] presentan el disentildeo implementacioacuten 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 estaacute formada por tres entidades principales aplicacioacuten sentildealizacioacuten y transporte La siguiente Tabla 1 muestra un conjunto de nueve baacutesicos 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 combinacioacuten de servicios La marca X indica el servicio baacutesico soportado en cada clase de servicio general

Clases de servicio

Servicios Servicio de comportamiento

garantizado

Servicio fiable Servicio Best effort

- Transferencia Simplex de datos

X X X

- Control de errores - deteccion de errorestimeouts retransmisiones

No existente (ofrecido por

AAL5)

- Bucle abierto - Control de flujo realimentado

No existente -

- X

- No existente

- Tamantildeo de mensaje ilimitado

X X X

- Eleccioacuten de blocking - Aplicacioacuten Non-blocking

X X

X X

X X

- Eleccioacuten de byte stream - Semaacutentica transferencia de mensajes

X X

X X

X X

- Garantiacuteas de QoS requerimientos de ancho de banda

No soportado No soportado

- Reserva de recursos X No existente No existente

- Transferencias Multicast X No soportado Para servicios no fiables

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 recuperacioacuten de peacuterdidas del protocolo estaacutendar SSCOP [14] y demuestran que el resultado ofrece baja latencia eficiente recuperacioacuten de ceacutelulas perdidas y es tan robusto como el estaacutendar SSCOP

4- Protocolos multipointEl crecimiento de las redes ATM viene motivado en parte por la demanda de servicios multimedia para grupos dispersos de usuarios El traacutefico multicast tiene caracteriacutesticas particulares descritas para ATM en UNI 40 [6] y anteriores [5] La distribucioacuten de informacioacuten punto-a-multipunto (uno-a-muchos) o multipunto-a-multipunto (muchos-a-muchos) es un objetivo baacutesico propuesto por varios protocolos y arquitecturas ATM que ofrecen el soporte multimedia yo multicast como audio-conferencia video-conferencia trabajos colaborativos o VoD ATM es auacuten una tecnologiacutea emergente disentildeada 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 30) para ATM define conexiones punto-a-multipunto y las conexiones multipunto-a-multipunto soacutelo 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 topologiacutea completamente mallada todos-con-todos Aunque esta topologiacutea ofrece conexiones multipunto-a-multipunto hay que destacar que no escala bien cuando el nuacutemero de participantes es elevado Una alternativa al anterior esquema es el uso de un servidor que actuacutea a modo de raiacutez en el aacuterbol multipunto Este meacutetodo soacutelo requiere un nodo raiacutez para almacenar informacioacuten pero la desventaja de este meacutetodo son las potenciales congestiones en el servidor

cuando debe encargarse de enviacuteos y retransmisiones de las conexiones multipunto-a-multipunto

Para solventar las limitaciones de UNI 30 y UNI 31 [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 sentildealizacioacuten ATM (UNI 31 UNI 40) [4][5][6] Comenzamos destacando la referencia [16] como un reciente trabajo que revisa y compara los protocolos de transporte multicast maacutes importantes en Internet como MTP-2 XTP RTP SRM RAMP RMTP MFTP STORM etc IETF e IRTF (como ITU-T y ATM Forum) tambieacuten impulsan una importante actividad en este campo La referencia [16] revisa los maacutes representativos protocolos multicast y los clasifica de acuerdo a la taxonomiacutea de varias caracteriacutesticas (propagacioacuten de datos mecanismos de fiabilidad retransmisiones control de congestioacuten y de flujo gestioacuten de grupos multicast etc) En Internet los mecanismos efectivos de control de congestioacuten son una de las prioridades en las investigaciones de las transferencias multicast fiables Los mecanismos de seguridad y las teacutecnicas escalables de recuperacioacuten 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 maacutes importantes caracteriacutesticas En esta seccioacuten 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 maacutes interesantes en los siguientes paacuterrafos SMART (shared many-to-many ATM reservations)[3] es un protocolo para controlar un aacuterbol ATM multicast compartido soportando comunicaciones muchos-a-muchos (many-to-many) Esta propuesta tiene importantes caracteriacutesticas como que reside completamente en la capa ATM y no requiere ninguacuten servidor soporta uno o varios VCCs (y tambieacuten VPCs) cuyo nuacutemero es libremente configurado y es independiente del nuacutemero de puntos finales usa el concepto de bloques de datos como en la clase de servicio ABT y tambieacuten permite VCCs de las clases CBR VBR o UBR el protocolo garantiza que no existen puntos de interrelacioacuten en los VCC del aacuterbol son respetadas las garantiacuteas del contrato de traacutefico asociado con los VCCs etc SMART puede ser entendido como un protocolo completamente distribuido para coordinar la distribucioacuten de VPIsVCIs 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 ceacutelulas de datos desde diferentes fuentes pueden llegar intercaladas a un destinatario) y tambieacuten Demand Sharing (los recursos asignados a conexiones muchos-a-muchos son dinaacutemicamente compartidas entre todas las potenciales fuentes El artiacuteculo [3] describe el protocolo SMART formal e informalmente y propone completas pruebas de correccioacuten y un detallado anaacutelisis de comportamiento para estudios futuros Tambieacuten son sugeridas otras investigaciones como son ofrecer justicia en los accesos a los aacuterboles multicast investigar las ceacutelulas RM perioacutedicamente para aliviar las congestiones en la red o disminuir el tiempo de acceso del usuario a los aacuterboles de distribucioacuten multicast anaacutelisis de las ceacutelulas RM dentro de cada VCC o fuera enviando todas las ceacutelulas RM en un VCC dedicado En [17] se presenta MWAX un algoritmo dinaacutemico 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 artiacuteculo describe un esquema jeraacuterquico basado en CBT para incorporar routing multipunto-a-multipunto en PNNI En el algoritmo los nodos core actuacutean como participantes pasivos para eliminar la dependencia en la seleccioacuten de estos nodos Con un mecanismo de backup se consigue un algoritmo tolerante a fallos en los nodos core lo cual puede ser faacutecilmente 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 jerarquiacutea SEAM (Scalable and Efficient ATM Multicast) [18] propone una arquitectura escalable eficiente y multicast multipunto-a-multipunto para redes ATM que usa un soacutelo VC para un grupo multicast de muacuteltiples 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 Tambieacuten realiza aportaciones para conseguir soportar IP multicast sobre redes ATM extensas

SEAM usa un soacutelo aacuterbol de distribucioacuten 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 sentildealizacioacuten del grupo Este trabajo deja abiertas investigaciones referentes a la gestioacuten de traacutefico y a la entrega fiable de traacuteficos multicasting Concluimos esta seccioacuten destacando MCMP (Multiparty Conference Management Protocol) [19] que sin estar pensado especiacuteficamente para ATM es un protocolo de nivel sesioacutentransporte distribuido extremo-extremo y desarrollado para gestioacuten de grupos de aplicaciones de conferencia MCMP es un conjunto de algoritmos de control distribuido para configuracioacuten de conferencias multipunto y gestioacuten de miembros de grupos de usuarios Conceptualmente MCMP reside en el nivel de sesioacuten en el que se establece la infraestructura para activar la transferencia de informacioacuten entre los participantes en la conferencia Pero funcionalmente el protocolo acompasa los niveles de sesioacuten y de transporte pues utiliza directamente servicios del nivel de red Son destacables las condiciones de correccioacuten (conectividad validacioacuten unicidad consistencia y terminacioacuten) que deben ser satisfechas una vez que la conferencia ha sido configurada por el algoritmo de configuracioacuten de MCMP El artiacuteculo muestra exhaustivas pruebas de correccioacuten para uno de los algoritmos y tambieacuten describe la especificacioacuten y verificacioacuten del protocolo

5- Nuevos campos de investigacioacutenEn todas las redes existen gran variedad de elementos hardware (switchs routers bridges brouters hubs ETDs etc) que realizan muy diversas funciones (conmutacioacuten routing puenteo controles de congestioacuten y de flujo garantiacutea de QoS ejecucioacuten de aplicaciones etc) En la actualidad la red es mayormente un canal de comunicacioacuten para transferir paquetes entre equipos finales (ayudada por los elementos hardware antes citados) Pero tambieacuten se estaacuten realizando importante esfuerzos para equipar a los elementos hardware con elevadas prestaciones aportadas por diversas teacutecnicas software Esto dota a la red de caracteriacutesticas activas (active networks) en el sentido de que los elementos hardware que la componen computan modifican u operan los contenidos de los paquetes y tambieacuten seraacuten capaces de transferir o propagar coacutedigo Por consiguiente una red activa es una red programable [20] es una excelente revisioacuten de este novedoso campo de investigacioacuten que discute dos planteamientos en la realizacioacuten de redes activas la idea del conmutador programable y la de la caacutepsula Una red es activa si en sus aacuterboles de distribucioacuten multicast existen nodos activos con capacidad para ejecutar programas yo capaces de implementar mecanismos de propagacioacuten de coacutedigo Algunas de las ventajas de los protocolos activos son conseguidas instalando nodos activos en puntos estrateacutegicos de la red Otro nuevo concepto es presentado en [21] como una metodologiacutea para el disentildeo de protocolos Los protocol boosters son una nueva contribucioacuten a las redes activas o programables Una ventaja de los boosters es que pueden ser faacutecilmente 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 aacuterea extensa Este papel introduce una arquitectura software orientada a agente y propone el concepto de agente de comunicacioacuten para servicio de comunicacioacuten 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 artiacuteculo muestra agentes software moacuteviles usados para implementar operaciones robustas y funciones de mantenimiento en redes ATM Los agentes desempentildean un rol similar al de las ceacutelulas OAM en ATM estaacutendar pues son transmitidos entre entidades de control a intervalos regulares usando recursos predefinidos La diferencia entre los agentes moacuteviles y las ceacutelulas OAM reside en que eacutestos pueden contener coacutedigo Para concluir destacar que la integracioacuten del traacutefico IP sobre tecnologiacutea ATM es tambieacuten uno de los campos maacutes activos en la actualidad En esta liacutenea pueden destacarse los siguientes protocolos IP-over-ATM IP Switching Tag Switching NHRP MPOA IMSS CSR ARIS AREQUIPARED y EPD Referencias

1 ____ Native ATM Service Semantic Description Version 1 ATM Forum Technical Committee ATM Forum Document af-saa-0048000 (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 Broadband Networks Multimedia Applications Services and Techniques ECMASTrsquo98 Springer (May 1998)

3 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 Nordm 3 (April 1997)

4 W D Zhong K Yukimatsu Design requeriments and architectures for multicast ATM switching IEICE Trans Com Vol E77-B pp 1420-1428 (Nov 1994)

5 ____ ATM user-network interface version 31 specification ATM Forum (1994)

6 ____ Traffic Management Specification Version 40 ATM Forum Technical Committee ATM Forum Document af-tm-0056000 (April 1996)

7 D Kandlur D Saha and W Willebeck Protocol Architecture for multimedia Application over ATM Networks IEEE Journal Selected and Communications Vol 14 Nordm 7 pp 1349-1359 (Sep 1996)

8 R Ahuja S Keshav and H Saran Design Implementation and Performance Measurement of a Native-Mode ATM Transport Layer (Estended Version) IEEEACM Transactions on Networking Vol 4 Nordm 4 (Aug 1996)

9 R Karabek A Native ATM Protocol Architecture Design and Performance Evaluation IEEE Proceedings 22nd Annual Conference on Local Computer Networks pp 204-210 (1997)

10 D C Feldmeier A framework of architectural concepts for high-speed communications systems IEEE J Select Areas CommunVol11 Nordm 4 (May 1993)

11 T Anker D Breitgand D Dolev Z Levy Congress CONnection-oriented Group-address RESolution Service Proceeding of SPIE97 vol 3233 on Broadband Networking Technologies Nov (1997)

12 kStack httpcometcolumbiaedusoftwarekStack

13 T La Porta and M Schwartz Architectures Features and Implementation of High-Speed Transport Protocols IEEE Network Magazine pp 14-22 (May 1991)

14 ____ B-ISDN ATM Adaptation Layer Service Specific Connection Oriented Protocol (SSCOP) Q2110 ITU-T (10-Mar 1994)

15 J Soleacute-Pareta J Vila-Sallent Network-based paralell computing over ATM using improved SSCOP protocol Computer Communications 19 pp 915-926 (1996)

16 K Obraczka Multicast Transport Protocols A survey and Taxonomy IEEE Communi Magazine (1998)

17 R Venkateswaran CS Raghavendra X Chen and VP Kumar A Scalable Dynamic Multicast Routing Algorithm in ATM Networks IEEE pp 1361-1365 (1997)

18 Matthias Grossglauser and KK Ramakrishnan SEAM Scalable and Efficient ATM Multicast IEEE 1997 pp 867-875 (1997)

19 M Nguyen and M Schwartz MCMP A Transportsession level Distributed Protocol for Desktop Conference Setup IEEE Journal Selected and comunications Vol 14 Nordm 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 Nordm 3 pp 437-443 (April 1998)

22 R Kishimoto Agent communication system for multimedia communication services INFOCOMrsquo96 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 Nordm 3 pp 414-423 (April 1998)

  • ATM - Modo de Transferencia Asiacutencrona
  • Revisioacuten y Clasificacioacuten de Protocolos para Redes de Tecnologiacutea ATM
    • Resumen
    • 1-Introduccioacuten y motivaciones
    • 2- Protocolos nativos ATM
    • 3- Protocolos de transporte para redes ATM
    • 4- Protocolos multipoint
    • 5- Nuevos campos de investigacioacuten
      • Referencias
Page 9: Atm

AAL 2 AAL 34 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 traacutefico de redes de aacuterea local (LAN) AAL 2 y AAL 3 soportan paquetes orientados a conexioacuten (Ver figura No5)

(El teacutermino orientado a conexioacuten describe la transferencia de datos despueacutes 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 jamaacutes vean estos errores reportados la degradacioacuten de respuesta o de caudal (through put) seriacutean los uacutenicos siacutentomas A diferencia de los mecanismos de control extremo a extremo que utiliza TCP en internerworking la capacidad de Gbitseg de la red ATM genera un juego de requerimientos necesarios para el control de flujo Si el control del flujo se hiciese como una realimentacioacuten del lazo extremo a extremo en el momento en que el mensaje de control de flujo arribase a la fuente eacutesta habriacutea transmitido ya algunos Mbytes de datos en el sistema exacerbando la congestioacuten Y en el momento en que la fuente reaccionase al mensaje de control la condicioacuten de congestioacuten hubiese podido desaparecer apagando innecesariamente la fuente La constante de tiempo de la realimentacioacuten extremo a extremo en las redes ATM (retardo de realimentacioacuten por producto lazo - ancho de banda) debe ser lo suficientemente alta como para cumplir con las necesidades del usuario sin que la dinaacutemica de la red se vuelva impractica Las condiciones de congestioacuten en las redes ATM estaacuten previstas para que sean extremadamente dinaacutemicas requiriendo de mecanismos de hardware lo suficientemente raacutepidos para llevar a la red al estado estacionario necesitando que la red en siacute eacuteste activamente involucrada en el raacutepido establecimiento de este estado estacionario Sin embargo esta aproximacioacuten simplista de control reactivo de lazo cerrado extremo a extremo en condiciones de congestioacuten no se considera suficiente para las redes ATM El consenso entre los investigadores de este campo arroja recomendaciones que incluyen el empleo de una coleccioacuten de esquemas de control de flujo junto con la colocacioacuten adecuada de los recursos y dimensionamiento de las redes para que aunados se pueda tratar y evadir la congestioacuten ya sea

Detectando y manipulando la congestioacuten que se genera tempranamente monitoreando de cerca las entradassalidas que estaacuten dentro de los conmutadores ATM y reaccionando gradualmente a medida que vaya arribando a ciertos niveles prefijados Tratando y controlando la inyeccioacuten de la conexioacuten de datos dentro de la red en la UNI (unidad interfaz de red) de tal forma que su tasa de inyeccioacuten sea modulada y medida alliacute primero antes de tener que ir a la conexioacuten de usuario a tomar acciones mas draacutesticas El estado de la red debe ser comunicado a la UNI generando raacutepidamente una celda de control de flujo siempre que se vaya a descartar una celda en alguacuten nodo debido a congestioacuten La UNI debe entonces manejar la congestioacuten cambiando su tasa de inyeccioacuten

o notificaacutendola a la conexioacuten de usuario para que cese el flujo dependiendo del nivel de severidad de la congestioacutenEl mayor compromiso durante el control de congestioacuten es el de tratar y afectar solo a los flujos de conexioacuten que son responsables de la congestioacuten y actuar de forma transparente frente a los flujos que observan buen comportamiento Al mismo tiempo permitir que el flujo de conexioacuten utilice tanto ancho de banda como necesite sino hay congestioacuten La recomendacioacuten UIT - T I 371 especifica un contrato de traacutefico que define como el traacutefico del usuario seria administrado El contrato que existe para cada conexion virtual (virtual path o virtual channel) es baacutesicamente un acuerdo entre el usuario y la red con respecto a la Calidad de Servicio (Quality Of Service - Q o S) y los paraacutemetros que regulan el flujo de celdas Estos descriptores de trafico dependen de una particular clase de servicio y pueden incluir bajo la especificacioacuten del ATM Forum UNI a cinco Q o S referenciados en los AALS El objetivo de estas sub clases de servicio es agrupar caracteriacutesticas 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 paraacutemetros pueden incluir el Sustained Cell Rate (SCR) el Miacutenimum Cell Rate (MCR) el Peak Cell Rate (PCR) yo el Burst Tolerance (BT) Para soportar todas las diferentes clases de servicios definidos por los estaacutendares el switch ATM debe ser capaz de definir eacutestos paraacutemetros en base a cada VC o cada VP y debe proveer amortiguadores (buffers) para absorber las raacutefagas de trafico

INTEROPERABILIDAD ENTRE FRAME RELAY Y ATM El objetivo final para todos los servicios descritos anteriormente es una migracioacuten suave de Frame Relay yo SMDS a redes ATM Por ejemplo la recomendacioacuten UIT - T I555 provee un marco para la interoperabilidad de Frame Relay y ATM Para alcanzar una maacutexima eficiencia se trata de brindar este servicio de interoperabilidad en la capa maacutes baja posible mediante conversioacuten de protocolo

PRIMER ESCENARIO

Cuando el servicio de Frame Relay es dado sobre la RDSI en banda ancha y los usuarios se conectan a traveacutes de la UNI de Frame Relay En esta solucioacuten 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 (VCVP) para enlazar los puntos de acceso Frame Relay En este esquema se puede explotar la naturaleza de orientacioacuten a conexioacuten Frame Relay (F R) siguiendo un comportamiento como

El usuario del enrutador pregunta por una conexioacuten al equipo interfaz de red El equipo interfaz de la red coloca las conexiones Frame Relay dentro de una conexioacuten ATM con las direcciones destino apropiadas Por cada trama de equipo interfaz de red traslada de la conexioacuten de Frame Relay a la ATM y viceversa La conexioacuten ATM esta desocupada cuando no se necesitaPara lograr este uacuteltimo punto el manejo de la poliacutetica de conexion del VC sera un aspecto crucial para el desempentildeo de este procedimiento Resulta difiacutecil de terminar el procedimiento para manejar un VC cuando la fuente de traacutefico es no orientada a conexioacuten 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 conexioacuten 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 opcioacuten se toma ventaja del uso actual del FR el cual es proveer un mallado virtual entre diferentes sitios para cargar traacutefico no orientado a conexioacuten 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 conmutacioacuten 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 traveacutes de sus respectivas interfaces de red (NNIs) Esto permitiriacutea a un proveedor de red manejar esta heterogeacutenea red como un todo Frame Relay provee usualmente la interconexioacuten para LAN a pesar de su natural orientacioacuten a conexioacuten 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 sobresimplificacioacuten los dos protocolos (AAL 3 y AAL 5) ofrecen basicamente el mismo servicio CPAAL (Parte Comuacuten 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 implementacioacuten y eficiencia del protocolo que incide en el costo Las caracteriacutesticas a tomar en cuenta cuyo detalle puede ser tema de otro artiacuteculo tienen que ver con Delimitacioacuten y Alineamiento de Tramas Multiplexacioacuten Deteccioacuten de errores de transmisioacuten eficiencia en la transmisioacuten 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 tecnologiacutea de red empresarial virtual del futuro un teacutermino que refleja tanto la evolucioacuten del modelo empresarial global y el eacutenfasis en la conectividad loacutegica donde los usuarios obtienen acceso a los recursos que necesitan y el operador de la red provee las rutas de conexioacuten y asigna el ancho de banda necesario a fuentes de traacutefico muy diferentes (voz datos viacutedeo) Aquellos que construyen y operan redes deben volver los ojos a las capacidades de la tecnologiacutea ATM ya que aspiran a la maacutegica combinacioacuten interconectividad global - escalabilidad de tecnologiacuteas y satisfaccioacuten del cliente local

BIBLIOGRAFIA

1 CCITT Rec I362 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 vol2 No8 ATM Testing crosses network boundaries Jim Frimmel

6 Newslink Alcatel Telecomrsquos customer magazine Vol IV No4 4th Quarter 1996 Adapting Networks to the Internet Challenge Krish Prabhu

Trabajo realizado por

Ivan Dario Cruz PradaNicruz[arroba]col1telecomcomco

Revisioacuten y Clasificacioacuten de Protocolos para Redes de Tecnologiacutea ATM

Joseacute Luis Gonzaacutelez-Saacutenchez y Jordi Domingo-Pascual

ResumenLa tecnologiacutea 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 investigacioacuten maacutes activo con la aspiracioacuten 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 asiacute como las caracteriacutesticas multicast la escalabilidad y la fiabilidad Se profundiza en el concepto de protocolo nativo ATM y son introducidos los protocolos maacutes importantes que satisfacen este importante requerimiento (N3 CONGRESS y kStack entre otros) Es importante destacar tambieacuten los protocolos de transporte pensados especiacuteficamente para la tecnologiacutea ATM La caracteriacutestica multicast (multipoint-to-multipoint) es una de las que maacutes esfuerzo estaacute costando garantizar a ATM pero existen ya propuestas que permiten la comunicacioacuten fiable a elevados anchos de banda y entre muacuteltiples emisores y receptores (SMART MCMP o MWAX) El artiacuteculo concluye con las investigacioness maacutes novedosas en torno a los protocolos ATM como las iniciativas que proponen redes ATM programables o activas (active networks) usando agentes moacuteviles

1-Introduccioacuten y motivacionesLa actual demanda de aplicaciones relacionadas con informacioacuten multimedia como son la video-conferencia audio-conferencia video bajo demanda (VoD) o sistemas colaborativos (pizarras compartidas teletrabajo telemedicina etc) y su coexistencia con aplicaciones maacutes claacutesicas (bases de datos transferencias de ficheros WWW etc) requiere tecnologiacuteas de comunicaciones capaces de ofrecer elevadas prestaciones Estas elevadas prestaciones estaacuten directamente relacionadas con la calidad de servicio (QoS) y concretamente con conceptos claramente parametrizables como el ancho de banda y la velocidad de transmisioacuten (throughput) el retardo de las transferencias (delay) la variabilidad en el retardo (jitter) la fiabilidad (reliability) de las transmisiones las caracteriacutesticas de multidifusioacuten a grupos dispersos de usuarios (multicast) y la posibilidad de gestionar muacuteltiples clases de servicio o flujos de informacioacuten en redes multiclass Para que las nuevas tecnologiacuteas en comunicaciones puedan ofrecer estas caracteriacutesticas es necesario revisar potenciar y ampliar las actuales arquitecturas servicios y protocolosde comunicaciones En los uacuteltimos dos o tres antildeos las investigaciones en el campo de ATM estaacuten dado lugar a importantes propuestas cuyo principal objetivo es ofrecer a las aplicaciones demandadas actualmente algunas o todas las caracteriacutesticas citadas anteriormente Presentamos en este trabajo los conceptos y propuestas maacutes novedosas en el contexto de ATM para ayudar al lector interesado en el dinaacutemico complejo y sofisticado campo de los protocolos de comunicaciones Realizamos la revisioacuten de algunos de los maacutes importantes conceptos teacutecnicas ideas y mecanismos en protocolos de altas prestaciones para redes de tecnologiacutea ATM El principal objetivo de este documento es ofrecer una actualizada visioacuten general no extensiva ni profunda de los protocolos propuestos y en desarrollo para dotar a las diversas clases de servicio ATM de las citadas caracteriacutesticas de calidad de servicio que aporten las potenciales elevadas prestaciones que la tecnologiacutea ATM es capaz de ofrecer El resto del documento estaacute estructurado de la siguiente forma La seccioacuten 2 revisa el concepto de protocolo nativo centrado en el contexto de las redes ATM La seccioacuten 3 describe las propuestas maacutes interesantes actualmente en materia de protocolos de transporte El apartado 4 comenta las transferencias multicast como un importante objetivo para una tecnologiacutea orientada a la conexioacuten como es ATM Concluimos en la seccioacuten 5 con los campos de investigacioacuten abiertos recientemente como son las redes activas y los procolos booster

2- Protocolos nativos ATM

Las aplicaciones nativas ATM estaacuten especiacuteficamente pensadas para usar la tecnologiacutea ATM y para explotar al maacuteximo sus especiales caracteriacutesticas Los protocolos nativos se encargan por tanto de ofrecer esas caracteriacutesticas intriacutensecas de las redes de tecnologiacutea ATM (soporte de QoS sentildealizacioacuten direccionamiento etc) a las aplicaciones nativas ATM (VoD pizarras compartidas video-conferencia) No obstante existen tambieacuten activas investigaciones para conseguir soportar sobre redes ATM aplicaciones no nativas ATM desarrolladas para otras tecnologiacuteas (IP Frame Relay SMDS) En [1] el termino native ATM services define servicios ATM especiacuteficos 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 adaptacioacuten (AALs) Disponibilidad de circuitos virtuales conmutados (SVCs) y circuitos virtuales permanentes (PVCs) Consideraciones relativas a la gestioacuten de traacutefico (clases de servicio garantiacuteas de QoS etc) Posibilidad de distribucioacuten de conexiones y de participacioacuten local en la administracioacuten de la red (protocolos ILMI y OAM)

El propoacutesito de los servicios nativos ATM es ofrecer el acceso a las clases de servicio o a las caracteriacutesticas de QoS en redes ATM Estos servicios nativos tambieacuten ofrecen soporte a un amplio y heterogeacuteneo rango de flujos con diversas propiedades y requerimientos recomendados en [1] Los protocolos de transferencia nativos ATM gestionan la sentildealizacioacuten UNI para establecer los SVCs configurar PVCs y mapear los perfiles de QoS en la correspondiente clase de servicio Los protocolos nativos tambieacuten realizan funciones claacutesicas como las de transporte mecanismos de control de errores transferencia de datos y controles de flujo y de congestioacuten En la referencia [1] se especifica la definicioacuten semaacutentica de los servicios y consideramos que es uacutetil contrastar esta semaacutentica con las redes ATM actuales que usan TCP como capa de transporte e IP-over-ATM como capa de red planteamiento por otro lado poco adecuado [2] por las siguientes razones

Las redes IP no garantizan la QoS extremo-extremo ofrecida por las redes ATM a circuitos individuales IP multiplexa muacuteltiples conexiones de transporte con distintos requerimientos de QoS en VCs simples TCP no soporta ceacutelulas RM (Resource Management) ABR y por consiguiente no puede usar directamente las garantiacuteas de QoS ofrecidas por la red ATM Adaptation Layer 5 (AAL5) realiza labores de checksum para detectar corrupcioacuten de datos TCP tambieacuten realiza estas labores (redundantes con AAL5) costosas en overhead (cada byte de un paquete debe ser chequeado) TCPIP son la representacioacuten de un grupo de protocolos bastante maacutes 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] Ademaacutes 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 tecnologiacutea ATM y tambieacuten existen antiguas y no nativas aplicaciones Este escenario implica cambiar las aplicaciones o proponer nuevas pilas de protocolos nativos ATM La encapsulacioacuten consecutiva de paquetes genera problemas de overhead y funciones redundantes como se ha argumentado anteriormente La limitacioacuten de recursos en los sistemas finales es otra importante motivacioacuten 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 puacuteblicos disfrutan tambieacuten de estas ventajas ATM RDSI y la telefoniacutea ofrecen un esquema de direccionamiento universal basado en NSAPE164 el cual es capaz de enrutar traacutefico de forma nativa Por tanto aunque ATM dispone de protocolos nativos con direccionamiento intriacutenceso estructurado y jeraacuterquico eacuteste no es aprovechado por las aplicaciones que estaacuten 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 tambieacuten existen importantes investigaciones en torno a los protocolos nativos ATM En esta seccioacuten se muestran las propuestas maacutes importantes y actuales en materia de protocolos nativos ATM[2] [7] [8] [9] [10] [11] [12] que a su vezestaacuten sirviendo de base para nuevas investigaciones

[8] presentan el disentildeo implementacioacuten y comportamiento de una pila en modo nativo ATM y contrasta la semaacutentica 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 automaacuteticamente los siguientes problemas

IP-over-ATM no ofrece garantiacutea de QoS pues sus aplicaciones soacutelo ven la interfaz IP El nuacutecleo 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 sentildealizacioacuten 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 caracteriacutesticas la entrega fiable y no fiable de datos con control de flujo Este protocolo de transporte es ampliado en la seccioacuten 5 [2] presenta N3 (Native Non-broadcasting medium access Networking) un protocolo de transporte ligero y nativo ATM La pila N3 se ha disentildeado 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 ademaacutes aporta otras importantes novedades Los principales componentes de N3 incluyen una API sockets ATM nativa un protocolo de transporte ATM y un servicio de nombres ATM (Fig2) El protocolo de transporte ATM propuesto en [2] ofrece soporte para tres diferentes tipos de servicio entrega garantizada (mecanismos de retransmisioacuten) 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 congestioacuten de la transferencia de datagramas y de la multiplexacioacuten 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 maacutes importante El Flow Management se responsabiliza de manipular los flujos de datos desde y hasta la red viacutea la interfaz AAL La segmentacioacuten el reensamblado y el control de errores es tambieacuten 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 congestioacuten y de flujo extremo-extremo maacutes complejo

[7] describe la semaacutentica de una pila de protocolos y explora una nueva arquitectura de protocolo adaptada a la tecnologiacutea ATM y a las aplicaciones multimedia El disentildeo estaacute basado en tres principios baacutesicos separacioacuten de flujos de control y de datos minimizacioacuten del overhead y de la duplicidad de funciones y acceso de las aplicaciones al nivel ATM con garantiacuteas 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-over-ATM 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 moacutedulo CNTL abre una conexioacuten de sentildealizacioacuten con el dispositivo ATM y establece una gestioacuten de las llamadas de mensajes de configuracioacuten PF_ATM separa flujos de datos y de control para aliviar el liacutemite de comportamiento en las comunicaciones Esto permite a los mecanismos de control de traacutefico ser raacutepidos y sencillos mientras los mecanismos de control pueden ser tan complicados como sea necesario Esta separacioacuten permite tambieacuten que los dispositivos puedan estar en los puntos finales de una conexioacuten La interfaz PF_ATM da a las aplicaciones acceso directo a la capa de enlace ATM y extiende las garantiacuteas de QoS a los puntos extremos de la comunicacioacuten Un segundo prototipo[7] es disentildeado e implementado con dos objetivos principales en la optimizacioacuten de la pila nativa ATM

Optimizar los caminos de datos entre los adaptadores ATM aprovechando la separacioacuten de flujos de control y de datos y la capacidad de gestioacuten de datos especiacuteficos de las conexiones de la pila ATM

Optimizar el procesamiento de overheads usando una pila de protocolos nativo ATM en lugar de UDPIP

[11] introduce CONGRESS (CONnection oriented Group-address RESolution Service) otro eficiente protocolo nativo ATM para la resolucioacuten y gestioacuten 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 disentildeo basado en los dos siguientes principios

Disentildeo jeraacuterquico los servicios del protocolo son ofrecidos a las aplicaciones por muacuteltiples servidores organizados jeraacuterquicamente No inundacioacuten se evita la inundacioacuten 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 implementacioacuten sobre Unix y Windows NT estaacute 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 antildeadido un moacutedulo que monitoria la QoS extremo-a-extremo

3- Protocolos de transporte para redes ATMEn los dos o tres uacuteltimos antildeos ha habido numerosos e interesante intentos por disentildear protocolos de transporte La referencia [10] presenta un completo y ya claacutesico resumen de las propuestas maacutes interesantes en materia de protocolos de transporte para redes de alta velocidad (mayoritariamente IP en el artiacuteculo) Ademaacutes la referencia [13] ofrece una interesante visioacuten de las caracteriacutesticas maacutes importantes en los protocolos de elevada velocidad Son estudiadas tambieacuten diversas arquitecturas de protocolos y varias teacutecnicas de implementacioacuten Los protocolos de transporte de elevada velocidad son fuente de activas investigaciones y estaacuten en constante evolucioacuten desde hace maacutes de dos deacutecadas 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 aacutembito de las comunicaciones que ha recibido mayor atencioacuten es la capa de transporte la cuarta capa del OSI-RM de los protocolos de comunicaciones TCP e ISO TP4 son los dos maacutes populares protocolos de transporte Pero centraacutendonos maacutes concretamente en el aacutembito de ATM la literatura presenta varios protocolos de transporte y arquitecturas para redes de alta velocidad revisadas resumidamente a continuacioacuten [7] ofrece una excelente y didaacutectica arquitectura de pila de protocolos para aplicaciones multimedia en modo nativo ATM Esta arquitectura de protocolo ha sido ya descrita brevemente en la seccioacuten anterior [8] presentan el disentildeo implementacioacuten 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 estaacute formada por tres entidades principales aplicacioacuten sentildealizacioacuten y transporte La siguiente Tabla 1 muestra un conjunto de nueve baacutesicos 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 combinacioacuten de servicios La marca X indica el servicio baacutesico soportado en cada clase de servicio general

Clases de servicio

Servicios Servicio de comportamiento

garantizado

Servicio fiable Servicio Best effort

- Transferencia Simplex de datos

X X X

- Control de errores - deteccion de errorestimeouts retransmisiones

No existente (ofrecido por

AAL5)

- Bucle abierto - Control de flujo realimentado

No existente -

- X

- No existente

- Tamantildeo de mensaje ilimitado

X X X

- Eleccioacuten de blocking - Aplicacioacuten Non-blocking

X X

X X

X X

- Eleccioacuten de byte stream - Semaacutentica transferencia de mensajes

X X

X X

X X

- Garantiacuteas de QoS requerimientos de ancho de banda

No soportado No soportado

- Reserva de recursos X No existente No existente

- Transferencias Multicast X No soportado Para servicios no fiables

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 recuperacioacuten de peacuterdidas del protocolo estaacutendar SSCOP [14] y demuestran que el resultado ofrece baja latencia eficiente recuperacioacuten de ceacutelulas perdidas y es tan robusto como el estaacutendar SSCOP

4- Protocolos multipointEl crecimiento de las redes ATM viene motivado en parte por la demanda de servicios multimedia para grupos dispersos de usuarios El traacutefico multicast tiene caracteriacutesticas particulares descritas para ATM en UNI 40 [6] y anteriores [5] La distribucioacuten de informacioacuten punto-a-multipunto (uno-a-muchos) o multipunto-a-multipunto (muchos-a-muchos) es un objetivo baacutesico propuesto por varios protocolos y arquitecturas ATM que ofrecen el soporte multimedia yo multicast como audio-conferencia video-conferencia trabajos colaborativos o VoD ATM es auacuten una tecnologiacutea emergente disentildeada 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 30) para ATM define conexiones punto-a-multipunto y las conexiones multipunto-a-multipunto soacutelo 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 topologiacutea completamente mallada todos-con-todos Aunque esta topologiacutea ofrece conexiones multipunto-a-multipunto hay que destacar que no escala bien cuando el nuacutemero de participantes es elevado Una alternativa al anterior esquema es el uso de un servidor que actuacutea a modo de raiacutez en el aacuterbol multipunto Este meacutetodo soacutelo requiere un nodo raiacutez para almacenar informacioacuten pero la desventaja de este meacutetodo son las potenciales congestiones en el servidor

cuando debe encargarse de enviacuteos y retransmisiones de las conexiones multipunto-a-multipunto

Para solventar las limitaciones de UNI 30 y UNI 31 [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 sentildealizacioacuten ATM (UNI 31 UNI 40) [4][5][6] Comenzamos destacando la referencia [16] como un reciente trabajo que revisa y compara los protocolos de transporte multicast maacutes importantes en Internet como MTP-2 XTP RTP SRM RAMP RMTP MFTP STORM etc IETF e IRTF (como ITU-T y ATM Forum) tambieacuten impulsan una importante actividad en este campo La referencia [16] revisa los maacutes representativos protocolos multicast y los clasifica de acuerdo a la taxonomiacutea de varias caracteriacutesticas (propagacioacuten de datos mecanismos de fiabilidad retransmisiones control de congestioacuten y de flujo gestioacuten de grupos multicast etc) En Internet los mecanismos efectivos de control de congestioacuten son una de las prioridades en las investigaciones de las transferencias multicast fiables Los mecanismos de seguridad y las teacutecnicas escalables de recuperacioacuten 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 maacutes importantes caracteriacutesticas En esta seccioacuten 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 maacutes interesantes en los siguientes paacuterrafos SMART (shared many-to-many ATM reservations)[3] es un protocolo para controlar un aacuterbol ATM multicast compartido soportando comunicaciones muchos-a-muchos (many-to-many) Esta propuesta tiene importantes caracteriacutesticas como que reside completamente en la capa ATM y no requiere ninguacuten servidor soporta uno o varios VCCs (y tambieacuten VPCs) cuyo nuacutemero es libremente configurado y es independiente del nuacutemero de puntos finales usa el concepto de bloques de datos como en la clase de servicio ABT y tambieacuten permite VCCs de las clases CBR VBR o UBR el protocolo garantiza que no existen puntos de interrelacioacuten en los VCC del aacuterbol son respetadas las garantiacuteas del contrato de traacutefico asociado con los VCCs etc SMART puede ser entendido como un protocolo completamente distribuido para coordinar la distribucioacuten de VPIsVCIs 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 ceacutelulas de datos desde diferentes fuentes pueden llegar intercaladas a un destinatario) y tambieacuten Demand Sharing (los recursos asignados a conexiones muchos-a-muchos son dinaacutemicamente compartidas entre todas las potenciales fuentes El artiacuteculo [3] describe el protocolo SMART formal e informalmente y propone completas pruebas de correccioacuten y un detallado anaacutelisis de comportamiento para estudios futuros Tambieacuten son sugeridas otras investigaciones como son ofrecer justicia en los accesos a los aacuterboles multicast investigar las ceacutelulas RM perioacutedicamente para aliviar las congestiones en la red o disminuir el tiempo de acceso del usuario a los aacuterboles de distribucioacuten multicast anaacutelisis de las ceacutelulas RM dentro de cada VCC o fuera enviando todas las ceacutelulas RM en un VCC dedicado En [17] se presenta MWAX un algoritmo dinaacutemico 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 artiacuteculo describe un esquema jeraacuterquico basado en CBT para incorporar routing multipunto-a-multipunto en PNNI En el algoritmo los nodos core actuacutean como participantes pasivos para eliminar la dependencia en la seleccioacuten de estos nodos Con un mecanismo de backup se consigue un algoritmo tolerante a fallos en los nodos core lo cual puede ser faacutecilmente 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 jerarquiacutea SEAM (Scalable and Efficient ATM Multicast) [18] propone una arquitectura escalable eficiente y multicast multipunto-a-multipunto para redes ATM que usa un soacutelo VC para un grupo multicast de muacuteltiples 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 Tambieacuten realiza aportaciones para conseguir soportar IP multicast sobre redes ATM extensas

SEAM usa un soacutelo aacuterbol de distribucioacuten 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 sentildealizacioacuten del grupo Este trabajo deja abiertas investigaciones referentes a la gestioacuten de traacutefico y a la entrega fiable de traacuteficos multicasting Concluimos esta seccioacuten destacando MCMP (Multiparty Conference Management Protocol) [19] que sin estar pensado especiacuteficamente para ATM es un protocolo de nivel sesioacutentransporte distribuido extremo-extremo y desarrollado para gestioacuten de grupos de aplicaciones de conferencia MCMP es un conjunto de algoritmos de control distribuido para configuracioacuten de conferencias multipunto y gestioacuten de miembros de grupos de usuarios Conceptualmente MCMP reside en el nivel de sesioacuten en el que se establece la infraestructura para activar la transferencia de informacioacuten entre los participantes en la conferencia Pero funcionalmente el protocolo acompasa los niveles de sesioacuten y de transporte pues utiliza directamente servicios del nivel de red Son destacables las condiciones de correccioacuten (conectividad validacioacuten unicidad consistencia y terminacioacuten) que deben ser satisfechas una vez que la conferencia ha sido configurada por el algoritmo de configuracioacuten de MCMP El artiacuteculo muestra exhaustivas pruebas de correccioacuten para uno de los algoritmos y tambieacuten describe la especificacioacuten y verificacioacuten del protocolo

5- Nuevos campos de investigacioacutenEn todas las redes existen gran variedad de elementos hardware (switchs routers bridges brouters hubs ETDs etc) que realizan muy diversas funciones (conmutacioacuten routing puenteo controles de congestioacuten y de flujo garantiacutea de QoS ejecucioacuten de aplicaciones etc) En la actualidad la red es mayormente un canal de comunicacioacuten para transferir paquetes entre equipos finales (ayudada por los elementos hardware antes citados) Pero tambieacuten se estaacuten realizando importante esfuerzos para equipar a los elementos hardware con elevadas prestaciones aportadas por diversas teacutecnicas software Esto dota a la red de caracteriacutesticas activas (active networks) en el sentido de que los elementos hardware que la componen computan modifican u operan los contenidos de los paquetes y tambieacuten seraacuten capaces de transferir o propagar coacutedigo Por consiguiente una red activa es una red programable [20] es una excelente revisioacuten de este novedoso campo de investigacioacuten que discute dos planteamientos en la realizacioacuten de redes activas la idea del conmutador programable y la de la caacutepsula Una red es activa si en sus aacuterboles de distribucioacuten multicast existen nodos activos con capacidad para ejecutar programas yo capaces de implementar mecanismos de propagacioacuten de coacutedigo Algunas de las ventajas de los protocolos activos son conseguidas instalando nodos activos en puntos estrateacutegicos de la red Otro nuevo concepto es presentado en [21] como una metodologiacutea para el disentildeo de protocolos Los protocol boosters son una nueva contribucioacuten a las redes activas o programables Una ventaja de los boosters es que pueden ser faacutecilmente 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 aacuterea extensa Este papel introduce una arquitectura software orientada a agente y propone el concepto de agente de comunicacioacuten para servicio de comunicacioacuten 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 artiacuteculo muestra agentes software moacuteviles usados para implementar operaciones robustas y funciones de mantenimiento en redes ATM Los agentes desempentildean un rol similar al de las ceacutelulas OAM en ATM estaacutendar pues son transmitidos entre entidades de control a intervalos regulares usando recursos predefinidos La diferencia entre los agentes moacuteviles y las ceacutelulas OAM reside en que eacutestos pueden contener coacutedigo Para concluir destacar que la integracioacuten del traacutefico IP sobre tecnologiacutea ATM es tambieacuten uno de los campos maacutes activos en la actualidad En esta liacutenea pueden destacarse los siguientes protocolos IP-over-ATM IP Switching Tag Switching NHRP MPOA IMSS CSR ARIS AREQUIPARED y EPD Referencias

1 ____ Native ATM Service Semantic Description Version 1 ATM Forum Technical Committee ATM Forum Document af-saa-0048000 (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 Broadband Networks Multimedia Applications Services and Techniques ECMASTrsquo98 Springer (May 1998)

3 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 Nordm 3 (April 1997)

4 W D Zhong K Yukimatsu Design requeriments and architectures for multicast ATM switching IEICE Trans Com Vol E77-B pp 1420-1428 (Nov 1994)

5 ____ ATM user-network interface version 31 specification ATM Forum (1994)

6 ____ Traffic Management Specification Version 40 ATM Forum Technical Committee ATM Forum Document af-tm-0056000 (April 1996)

7 D Kandlur D Saha and W Willebeck Protocol Architecture for multimedia Application over ATM Networks IEEE Journal Selected and Communications Vol 14 Nordm 7 pp 1349-1359 (Sep 1996)

8 R Ahuja S Keshav and H Saran Design Implementation and Performance Measurement of a Native-Mode ATM Transport Layer (Estended Version) IEEEACM Transactions on Networking Vol 4 Nordm 4 (Aug 1996)

9 R Karabek A Native ATM Protocol Architecture Design and Performance Evaluation IEEE Proceedings 22nd Annual Conference on Local Computer Networks pp 204-210 (1997)

10 D C Feldmeier A framework of architectural concepts for high-speed communications systems IEEE J Select Areas CommunVol11 Nordm 4 (May 1993)

11 T Anker D Breitgand D Dolev Z Levy Congress CONnection-oriented Group-address RESolution Service Proceeding of SPIE97 vol 3233 on Broadband Networking Technologies Nov (1997)

12 kStack httpcometcolumbiaedusoftwarekStack

13 T La Porta and M Schwartz Architectures Features and Implementation of High-Speed Transport Protocols IEEE Network Magazine pp 14-22 (May 1991)

14 ____ B-ISDN ATM Adaptation Layer Service Specific Connection Oriented Protocol (SSCOP) Q2110 ITU-T (10-Mar 1994)

15 J Soleacute-Pareta J Vila-Sallent Network-based paralell computing over ATM using improved SSCOP protocol Computer Communications 19 pp 915-926 (1996)

16 K Obraczka Multicast Transport Protocols A survey and Taxonomy IEEE Communi Magazine (1998)

17 R Venkateswaran CS Raghavendra X Chen and VP Kumar A Scalable Dynamic Multicast Routing Algorithm in ATM Networks IEEE pp 1361-1365 (1997)

18 Matthias Grossglauser and KK Ramakrishnan SEAM Scalable and Efficient ATM Multicast IEEE 1997 pp 867-875 (1997)

19 M Nguyen and M Schwartz MCMP A Transportsession level Distributed Protocol for Desktop Conference Setup IEEE Journal Selected and comunications Vol 14 Nordm 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 Nordm 3 pp 437-443 (April 1998)

22 R Kishimoto Agent communication system for multimedia communication services INFOCOMrsquo96 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 Nordm 3 pp 414-423 (April 1998)

  • ATM - Modo de Transferencia Asiacutencrona
  • Revisioacuten y Clasificacioacuten de Protocolos para Redes de Tecnologiacutea ATM
    • Resumen
    • 1-Introduccioacuten y motivaciones
    • 2- Protocolos nativos ATM
    • 3- Protocolos de transporte para redes ATM
    • 4- Protocolos multipoint
    • 5- Nuevos campos de investigacioacuten
      • Referencias
Page 10: Atm

o notificaacutendola a la conexioacuten de usuario para que cese el flujo dependiendo del nivel de severidad de la congestioacutenEl mayor compromiso durante el control de congestioacuten es el de tratar y afectar solo a los flujos de conexioacuten que son responsables de la congestioacuten y actuar de forma transparente frente a los flujos que observan buen comportamiento Al mismo tiempo permitir que el flujo de conexioacuten utilice tanto ancho de banda como necesite sino hay congestioacuten La recomendacioacuten UIT - T I 371 especifica un contrato de traacutefico que define como el traacutefico del usuario seria administrado El contrato que existe para cada conexion virtual (virtual path o virtual channel) es baacutesicamente un acuerdo entre el usuario y la red con respecto a la Calidad de Servicio (Quality Of Service - Q o S) y los paraacutemetros que regulan el flujo de celdas Estos descriptores de trafico dependen de una particular clase de servicio y pueden incluir bajo la especificacioacuten del ATM Forum UNI a cinco Q o S referenciados en los AALS El objetivo de estas sub clases de servicio es agrupar caracteriacutesticas 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 paraacutemetros pueden incluir el Sustained Cell Rate (SCR) el Miacutenimum Cell Rate (MCR) el Peak Cell Rate (PCR) yo el Burst Tolerance (BT) Para soportar todas las diferentes clases de servicios definidos por los estaacutendares el switch ATM debe ser capaz de definir eacutestos paraacutemetros en base a cada VC o cada VP y debe proveer amortiguadores (buffers) para absorber las raacutefagas de trafico

INTEROPERABILIDAD ENTRE FRAME RELAY Y ATM El objetivo final para todos los servicios descritos anteriormente es una migracioacuten suave de Frame Relay yo SMDS a redes ATM Por ejemplo la recomendacioacuten UIT - T I555 provee un marco para la interoperabilidad de Frame Relay y ATM Para alcanzar una maacutexima eficiencia se trata de brindar este servicio de interoperabilidad en la capa maacutes baja posible mediante conversioacuten de protocolo

PRIMER ESCENARIO

Cuando el servicio de Frame Relay es dado sobre la RDSI en banda ancha y los usuarios se conectan a traveacutes de la UNI de Frame Relay En esta solucioacuten 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 (VCVP) para enlazar los puntos de acceso Frame Relay En este esquema se puede explotar la naturaleza de orientacioacuten a conexioacuten Frame Relay (F R) siguiendo un comportamiento como

El usuario del enrutador pregunta por una conexioacuten al equipo interfaz de red El equipo interfaz de la red coloca las conexiones Frame Relay dentro de una conexioacuten ATM con las direcciones destino apropiadas Por cada trama de equipo interfaz de red traslada de la conexioacuten de Frame Relay a la ATM y viceversa La conexioacuten ATM esta desocupada cuando no se necesitaPara lograr este uacuteltimo punto el manejo de la poliacutetica de conexion del VC sera un aspecto crucial para el desempentildeo de este procedimiento Resulta difiacutecil de terminar el procedimiento para manejar un VC cuando la fuente de traacutefico es no orientada a conexioacuten 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 conexioacuten 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 opcioacuten se toma ventaja del uso actual del FR el cual es proveer un mallado virtual entre diferentes sitios para cargar traacutefico no orientado a conexioacuten 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 conmutacioacuten 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 traveacutes de sus respectivas interfaces de red (NNIs) Esto permitiriacutea a un proveedor de red manejar esta heterogeacutenea red como un todo Frame Relay provee usualmente la interconexioacuten para LAN a pesar de su natural orientacioacuten a conexioacuten 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 sobresimplificacioacuten los dos protocolos (AAL 3 y AAL 5) ofrecen basicamente el mismo servicio CPAAL (Parte Comuacuten 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 implementacioacuten y eficiencia del protocolo que incide en el costo Las caracteriacutesticas a tomar en cuenta cuyo detalle puede ser tema de otro artiacuteculo tienen que ver con Delimitacioacuten y Alineamiento de Tramas Multiplexacioacuten Deteccioacuten de errores de transmisioacuten eficiencia en la transmisioacuten 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 tecnologiacutea de red empresarial virtual del futuro un teacutermino que refleja tanto la evolucioacuten del modelo empresarial global y el eacutenfasis en la conectividad loacutegica donde los usuarios obtienen acceso a los recursos que necesitan y el operador de la red provee las rutas de conexioacuten y asigna el ancho de banda necesario a fuentes de traacutefico muy diferentes (voz datos viacutedeo) Aquellos que construyen y operan redes deben volver los ojos a las capacidades de la tecnologiacutea ATM ya que aspiran a la maacutegica combinacioacuten interconectividad global - escalabilidad de tecnologiacuteas y satisfaccioacuten del cliente local

BIBLIOGRAFIA

1 CCITT Rec I362 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 vol2 No8 ATM Testing crosses network boundaries Jim Frimmel

6 Newslink Alcatel Telecomrsquos customer magazine Vol IV No4 4th Quarter 1996 Adapting Networks to the Internet Challenge Krish Prabhu

Trabajo realizado por

Ivan Dario Cruz PradaNicruz[arroba]col1telecomcomco

Revisioacuten y Clasificacioacuten de Protocolos para Redes de Tecnologiacutea ATM

Joseacute Luis Gonzaacutelez-Saacutenchez y Jordi Domingo-Pascual

ResumenLa tecnologiacutea 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 investigacioacuten maacutes activo con la aspiracioacuten 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 asiacute como las caracteriacutesticas multicast la escalabilidad y la fiabilidad Se profundiza en el concepto de protocolo nativo ATM y son introducidos los protocolos maacutes importantes que satisfacen este importante requerimiento (N3 CONGRESS y kStack entre otros) Es importante destacar tambieacuten los protocolos de transporte pensados especiacuteficamente para la tecnologiacutea ATM La caracteriacutestica multicast (multipoint-to-multipoint) es una de las que maacutes esfuerzo estaacute costando garantizar a ATM pero existen ya propuestas que permiten la comunicacioacuten fiable a elevados anchos de banda y entre muacuteltiples emisores y receptores (SMART MCMP o MWAX) El artiacuteculo concluye con las investigacioness maacutes novedosas en torno a los protocolos ATM como las iniciativas que proponen redes ATM programables o activas (active networks) usando agentes moacuteviles

1-Introduccioacuten y motivacionesLa actual demanda de aplicaciones relacionadas con informacioacuten multimedia como son la video-conferencia audio-conferencia video bajo demanda (VoD) o sistemas colaborativos (pizarras compartidas teletrabajo telemedicina etc) y su coexistencia con aplicaciones maacutes claacutesicas (bases de datos transferencias de ficheros WWW etc) requiere tecnologiacuteas de comunicaciones capaces de ofrecer elevadas prestaciones Estas elevadas prestaciones estaacuten directamente relacionadas con la calidad de servicio (QoS) y concretamente con conceptos claramente parametrizables como el ancho de banda y la velocidad de transmisioacuten (throughput) el retardo de las transferencias (delay) la variabilidad en el retardo (jitter) la fiabilidad (reliability) de las transmisiones las caracteriacutesticas de multidifusioacuten a grupos dispersos de usuarios (multicast) y la posibilidad de gestionar muacuteltiples clases de servicio o flujos de informacioacuten en redes multiclass Para que las nuevas tecnologiacuteas en comunicaciones puedan ofrecer estas caracteriacutesticas es necesario revisar potenciar y ampliar las actuales arquitecturas servicios y protocolosde comunicaciones En los uacuteltimos dos o tres antildeos las investigaciones en el campo de ATM estaacuten dado lugar a importantes propuestas cuyo principal objetivo es ofrecer a las aplicaciones demandadas actualmente algunas o todas las caracteriacutesticas citadas anteriormente Presentamos en este trabajo los conceptos y propuestas maacutes novedosas en el contexto de ATM para ayudar al lector interesado en el dinaacutemico complejo y sofisticado campo de los protocolos de comunicaciones Realizamos la revisioacuten de algunos de los maacutes importantes conceptos teacutecnicas ideas y mecanismos en protocolos de altas prestaciones para redes de tecnologiacutea ATM El principal objetivo de este documento es ofrecer una actualizada visioacuten general no extensiva ni profunda de los protocolos propuestos y en desarrollo para dotar a las diversas clases de servicio ATM de las citadas caracteriacutesticas de calidad de servicio que aporten las potenciales elevadas prestaciones que la tecnologiacutea ATM es capaz de ofrecer El resto del documento estaacute estructurado de la siguiente forma La seccioacuten 2 revisa el concepto de protocolo nativo centrado en el contexto de las redes ATM La seccioacuten 3 describe las propuestas maacutes interesantes actualmente en materia de protocolos de transporte El apartado 4 comenta las transferencias multicast como un importante objetivo para una tecnologiacutea orientada a la conexioacuten como es ATM Concluimos en la seccioacuten 5 con los campos de investigacioacuten abiertos recientemente como son las redes activas y los procolos booster

2- Protocolos nativos ATM

Las aplicaciones nativas ATM estaacuten especiacuteficamente pensadas para usar la tecnologiacutea ATM y para explotar al maacuteximo sus especiales caracteriacutesticas Los protocolos nativos se encargan por tanto de ofrecer esas caracteriacutesticas intriacutensecas de las redes de tecnologiacutea ATM (soporte de QoS sentildealizacioacuten direccionamiento etc) a las aplicaciones nativas ATM (VoD pizarras compartidas video-conferencia) No obstante existen tambieacuten activas investigaciones para conseguir soportar sobre redes ATM aplicaciones no nativas ATM desarrolladas para otras tecnologiacuteas (IP Frame Relay SMDS) En [1] el termino native ATM services define servicios ATM especiacuteficos 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 adaptacioacuten (AALs) Disponibilidad de circuitos virtuales conmutados (SVCs) y circuitos virtuales permanentes (PVCs) Consideraciones relativas a la gestioacuten de traacutefico (clases de servicio garantiacuteas de QoS etc) Posibilidad de distribucioacuten de conexiones y de participacioacuten local en la administracioacuten de la red (protocolos ILMI y OAM)

El propoacutesito de los servicios nativos ATM es ofrecer el acceso a las clases de servicio o a las caracteriacutesticas de QoS en redes ATM Estos servicios nativos tambieacuten ofrecen soporte a un amplio y heterogeacuteneo rango de flujos con diversas propiedades y requerimientos recomendados en [1] Los protocolos de transferencia nativos ATM gestionan la sentildealizacioacuten UNI para establecer los SVCs configurar PVCs y mapear los perfiles de QoS en la correspondiente clase de servicio Los protocolos nativos tambieacuten realizan funciones claacutesicas como las de transporte mecanismos de control de errores transferencia de datos y controles de flujo y de congestioacuten En la referencia [1] se especifica la definicioacuten semaacutentica de los servicios y consideramos que es uacutetil contrastar esta semaacutentica con las redes ATM actuales que usan TCP como capa de transporte e IP-over-ATM como capa de red planteamiento por otro lado poco adecuado [2] por las siguientes razones

Las redes IP no garantizan la QoS extremo-extremo ofrecida por las redes ATM a circuitos individuales IP multiplexa muacuteltiples conexiones de transporte con distintos requerimientos de QoS en VCs simples TCP no soporta ceacutelulas RM (Resource Management) ABR y por consiguiente no puede usar directamente las garantiacuteas de QoS ofrecidas por la red ATM Adaptation Layer 5 (AAL5) realiza labores de checksum para detectar corrupcioacuten de datos TCP tambieacuten realiza estas labores (redundantes con AAL5) costosas en overhead (cada byte de un paquete debe ser chequeado) TCPIP son la representacioacuten de un grupo de protocolos bastante maacutes 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] Ademaacutes 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 tecnologiacutea ATM y tambieacuten existen antiguas y no nativas aplicaciones Este escenario implica cambiar las aplicaciones o proponer nuevas pilas de protocolos nativos ATM La encapsulacioacuten consecutiva de paquetes genera problemas de overhead y funciones redundantes como se ha argumentado anteriormente La limitacioacuten de recursos en los sistemas finales es otra importante motivacioacuten 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 puacuteblicos disfrutan tambieacuten de estas ventajas ATM RDSI y la telefoniacutea ofrecen un esquema de direccionamiento universal basado en NSAPE164 el cual es capaz de enrutar traacutefico de forma nativa Por tanto aunque ATM dispone de protocolos nativos con direccionamiento intriacutenceso estructurado y jeraacuterquico eacuteste no es aprovechado por las aplicaciones que estaacuten 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 tambieacuten existen importantes investigaciones en torno a los protocolos nativos ATM En esta seccioacuten se muestran las propuestas maacutes importantes y actuales en materia de protocolos nativos ATM[2] [7] [8] [9] [10] [11] [12] que a su vezestaacuten sirviendo de base para nuevas investigaciones

[8] presentan el disentildeo implementacioacuten y comportamiento de una pila en modo nativo ATM y contrasta la semaacutentica 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 automaacuteticamente los siguientes problemas

IP-over-ATM no ofrece garantiacutea de QoS pues sus aplicaciones soacutelo ven la interfaz IP El nuacutecleo 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 sentildealizacioacuten 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 caracteriacutesticas la entrega fiable y no fiable de datos con control de flujo Este protocolo de transporte es ampliado en la seccioacuten 5 [2] presenta N3 (Native Non-broadcasting medium access Networking) un protocolo de transporte ligero y nativo ATM La pila N3 se ha disentildeado 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 ademaacutes aporta otras importantes novedades Los principales componentes de N3 incluyen una API sockets ATM nativa un protocolo de transporte ATM y un servicio de nombres ATM (Fig2) El protocolo de transporte ATM propuesto en [2] ofrece soporte para tres diferentes tipos de servicio entrega garantizada (mecanismos de retransmisioacuten) 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 congestioacuten de la transferencia de datagramas y de la multiplexacioacuten 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 maacutes importante El Flow Management se responsabiliza de manipular los flujos de datos desde y hasta la red viacutea la interfaz AAL La segmentacioacuten el reensamblado y el control de errores es tambieacuten 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 congestioacuten y de flujo extremo-extremo maacutes complejo

[7] describe la semaacutentica de una pila de protocolos y explora una nueva arquitectura de protocolo adaptada a la tecnologiacutea ATM y a las aplicaciones multimedia El disentildeo estaacute basado en tres principios baacutesicos separacioacuten de flujos de control y de datos minimizacioacuten del overhead y de la duplicidad de funciones y acceso de las aplicaciones al nivel ATM con garantiacuteas 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-over-ATM 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 moacutedulo CNTL abre una conexioacuten de sentildealizacioacuten con el dispositivo ATM y establece una gestioacuten de las llamadas de mensajes de configuracioacuten PF_ATM separa flujos de datos y de control para aliviar el liacutemite de comportamiento en las comunicaciones Esto permite a los mecanismos de control de traacutefico ser raacutepidos y sencillos mientras los mecanismos de control pueden ser tan complicados como sea necesario Esta separacioacuten permite tambieacuten que los dispositivos puedan estar en los puntos finales de una conexioacuten La interfaz PF_ATM da a las aplicaciones acceso directo a la capa de enlace ATM y extiende las garantiacuteas de QoS a los puntos extremos de la comunicacioacuten Un segundo prototipo[7] es disentildeado e implementado con dos objetivos principales en la optimizacioacuten de la pila nativa ATM

Optimizar los caminos de datos entre los adaptadores ATM aprovechando la separacioacuten de flujos de control y de datos y la capacidad de gestioacuten de datos especiacuteficos de las conexiones de la pila ATM

Optimizar el procesamiento de overheads usando una pila de protocolos nativo ATM en lugar de UDPIP

[11] introduce CONGRESS (CONnection oriented Group-address RESolution Service) otro eficiente protocolo nativo ATM para la resolucioacuten y gestioacuten 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 disentildeo basado en los dos siguientes principios

Disentildeo jeraacuterquico los servicios del protocolo son ofrecidos a las aplicaciones por muacuteltiples servidores organizados jeraacuterquicamente No inundacioacuten se evita la inundacioacuten 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 implementacioacuten sobre Unix y Windows NT estaacute 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 antildeadido un moacutedulo que monitoria la QoS extremo-a-extremo

3- Protocolos de transporte para redes ATMEn los dos o tres uacuteltimos antildeos ha habido numerosos e interesante intentos por disentildear protocolos de transporte La referencia [10] presenta un completo y ya claacutesico resumen de las propuestas maacutes interesantes en materia de protocolos de transporte para redes de alta velocidad (mayoritariamente IP en el artiacuteculo) Ademaacutes la referencia [13] ofrece una interesante visioacuten de las caracteriacutesticas maacutes importantes en los protocolos de elevada velocidad Son estudiadas tambieacuten diversas arquitecturas de protocolos y varias teacutecnicas de implementacioacuten Los protocolos de transporte de elevada velocidad son fuente de activas investigaciones y estaacuten en constante evolucioacuten desde hace maacutes de dos deacutecadas 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 aacutembito de las comunicaciones que ha recibido mayor atencioacuten es la capa de transporte la cuarta capa del OSI-RM de los protocolos de comunicaciones TCP e ISO TP4 son los dos maacutes populares protocolos de transporte Pero centraacutendonos maacutes concretamente en el aacutembito de ATM la literatura presenta varios protocolos de transporte y arquitecturas para redes de alta velocidad revisadas resumidamente a continuacioacuten [7] ofrece una excelente y didaacutectica arquitectura de pila de protocolos para aplicaciones multimedia en modo nativo ATM Esta arquitectura de protocolo ha sido ya descrita brevemente en la seccioacuten anterior [8] presentan el disentildeo implementacioacuten 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 estaacute formada por tres entidades principales aplicacioacuten sentildealizacioacuten y transporte La siguiente Tabla 1 muestra un conjunto de nueve baacutesicos 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 combinacioacuten de servicios La marca X indica el servicio baacutesico soportado en cada clase de servicio general

Clases de servicio

Servicios Servicio de comportamiento

garantizado

Servicio fiable Servicio Best effort

- Transferencia Simplex de datos

X X X

- Control de errores - deteccion de errorestimeouts retransmisiones

No existente (ofrecido por

AAL5)

- Bucle abierto - Control de flujo realimentado

No existente -

- X

- No existente

- Tamantildeo de mensaje ilimitado

X X X

- Eleccioacuten de blocking - Aplicacioacuten Non-blocking

X X

X X

X X

- Eleccioacuten de byte stream - Semaacutentica transferencia de mensajes

X X

X X

X X

- Garantiacuteas de QoS requerimientos de ancho de banda

No soportado No soportado

- Reserva de recursos X No existente No existente

- Transferencias Multicast X No soportado Para servicios no fiables

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 recuperacioacuten de peacuterdidas del protocolo estaacutendar SSCOP [14] y demuestran que el resultado ofrece baja latencia eficiente recuperacioacuten de ceacutelulas perdidas y es tan robusto como el estaacutendar SSCOP

4- Protocolos multipointEl crecimiento de las redes ATM viene motivado en parte por la demanda de servicios multimedia para grupos dispersos de usuarios El traacutefico multicast tiene caracteriacutesticas particulares descritas para ATM en UNI 40 [6] y anteriores [5] La distribucioacuten de informacioacuten punto-a-multipunto (uno-a-muchos) o multipunto-a-multipunto (muchos-a-muchos) es un objetivo baacutesico propuesto por varios protocolos y arquitecturas ATM que ofrecen el soporte multimedia yo multicast como audio-conferencia video-conferencia trabajos colaborativos o VoD ATM es auacuten una tecnologiacutea emergente disentildeada 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 30) para ATM define conexiones punto-a-multipunto y las conexiones multipunto-a-multipunto soacutelo 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 topologiacutea completamente mallada todos-con-todos Aunque esta topologiacutea ofrece conexiones multipunto-a-multipunto hay que destacar que no escala bien cuando el nuacutemero de participantes es elevado Una alternativa al anterior esquema es el uso de un servidor que actuacutea a modo de raiacutez en el aacuterbol multipunto Este meacutetodo soacutelo requiere un nodo raiacutez para almacenar informacioacuten pero la desventaja de este meacutetodo son las potenciales congestiones en el servidor

cuando debe encargarse de enviacuteos y retransmisiones de las conexiones multipunto-a-multipunto

Para solventar las limitaciones de UNI 30 y UNI 31 [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 sentildealizacioacuten ATM (UNI 31 UNI 40) [4][5][6] Comenzamos destacando la referencia [16] como un reciente trabajo que revisa y compara los protocolos de transporte multicast maacutes importantes en Internet como MTP-2 XTP RTP SRM RAMP RMTP MFTP STORM etc IETF e IRTF (como ITU-T y ATM Forum) tambieacuten impulsan una importante actividad en este campo La referencia [16] revisa los maacutes representativos protocolos multicast y los clasifica de acuerdo a la taxonomiacutea de varias caracteriacutesticas (propagacioacuten de datos mecanismos de fiabilidad retransmisiones control de congestioacuten y de flujo gestioacuten de grupos multicast etc) En Internet los mecanismos efectivos de control de congestioacuten son una de las prioridades en las investigaciones de las transferencias multicast fiables Los mecanismos de seguridad y las teacutecnicas escalables de recuperacioacuten 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 maacutes importantes caracteriacutesticas En esta seccioacuten 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 maacutes interesantes en los siguientes paacuterrafos SMART (shared many-to-many ATM reservations)[3] es un protocolo para controlar un aacuterbol ATM multicast compartido soportando comunicaciones muchos-a-muchos (many-to-many) Esta propuesta tiene importantes caracteriacutesticas como que reside completamente en la capa ATM y no requiere ninguacuten servidor soporta uno o varios VCCs (y tambieacuten VPCs) cuyo nuacutemero es libremente configurado y es independiente del nuacutemero de puntos finales usa el concepto de bloques de datos como en la clase de servicio ABT y tambieacuten permite VCCs de las clases CBR VBR o UBR el protocolo garantiza que no existen puntos de interrelacioacuten en los VCC del aacuterbol son respetadas las garantiacuteas del contrato de traacutefico asociado con los VCCs etc SMART puede ser entendido como un protocolo completamente distribuido para coordinar la distribucioacuten de VPIsVCIs 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 ceacutelulas de datos desde diferentes fuentes pueden llegar intercaladas a un destinatario) y tambieacuten Demand Sharing (los recursos asignados a conexiones muchos-a-muchos son dinaacutemicamente compartidas entre todas las potenciales fuentes El artiacuteculo [3] describe el protocolo SMART formal e informalmente y propone completas pruebas de correccioacuten y un detallado anaacutelisis de comportamiento para estudios futuros Tambieacuten son sugeridas otras investigaciones como son ofrecer justicia en los accesos a los aacuterboles multicast investigar las ceacutelulas RM perioacutedicamente para aliviar las congestiones en la red o disminuir el tiempo de acceso del usuario a los aacuterboles de distribucioacuten multicast anaacutelisis de las ceacutelulas RM dentro de cada VCC o fuera enviando todas las ceacutelulas RM en un VCC dedicado En [17] se presenta MWAX un algoritmo dinaacutemico 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 artiacuteculo describe un esquema jeraacuterquico basado en CBT para incorporar routing multipunto-a-multipunto en PNNI En el algoritmo los nodos core actuacutean como participantes pasivos para eliminar la dependencia en la seleccioacuten de estos nodos Con un mecanismo de backup se consigue un algoritmo tolerante a fallos en los nodos core lo cual puede ser faacutecilmente 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 jerarquiacutea SEAM (Scalable and Efficient ATM Multicast) [18] propone una arquitectura escalable eficiente y multicast multipunto-a-multipunto para redes ATM que usa un soacutelo VC para un grupo multicast de muacuteltiples 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 Tambieacuten realiza aportaciones para conseguir soportar IP multicast sobre redes ATM extensas

SEAM usa un soacutelo aacuterbol de distribucioacuten 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 sentildealizacioacuten del grupo Este trabajo deja abiertas investigaciones referentes a la gestioacuten de traacutefico y a la entrega fiable de traacuteficos multicasting Concluimos esta seccioacuten destacando MCMP (Multiparty Conference Management Protocol) [19] que sin estar pensado especiacuteficamente para ATM es un protocolo de nivel sesioacutentransporte distribuido extremo-extremo y desarrollado para gestioacuten de grupos de aplicaciones de conferencia MCMP es un conjunto de algoritmos de control distribuido para configuracioacuten de conferencias multipunto y gestioacuten de miembros de grupos de usuarios Conceptualmente MCMP reside en el nivel de sesioacuten en el que se establece la infraestructura para activar la transferencia de informacioacuten entre los participantes en la conferencia Pero funcionalmente el protocolo acompasa los niveles de sesioacuten y de transporte pues utiliza directamente servicios del nivel de red Son destacables las condiciones de correccioacuten (conectividad validacioacuten unicidad consistencia y terminacioacuten) que deben ser satisfechas una vez que la conferencia ha sido configurada por el algoritmo de configuracioacuten de MCMP El artiacuteculo muestra exhaustivas pruebas de correccioacuten para uno de los algoritmos y tambieacuten describe la especificacioacuten y verificacioacuten del protocolo

5- Nuevos campos de investigacioacutenEn todas las redes existen gran variedad de elementos hardware (switchs routers bridges brouters hubs ETDs etc) que realizan muy diversas funciones (conmutacioacuten routing puenteo controles de congestioacuten y de flujo garantiacutea de QoS ejecucioacuten de aplicaciones etc) En la actualidad la red es mayormente un canal de comunicacioacuten para transferir paquetes entre equipos finales (ayudada por los elementos hardware antes citados) Pero tambieacuten se estaacuten realizando importante esfuerzos para equipar a los elementos hardware con elevadas prestaciones aportadas por diversas teacutecnicas software Esto dota a la red de caracteriacutesticas activas (active networks) en el sentido de que los elementos hardware que la componen computan modifican u operan los contenidos de los paquetes y tambieacuten seraacuten capaces de transferir o propagar coacutedigo Por consiguiente una red activa es una red programable [20] es una excelente revisioacuten de este novedoso campo de investigacioacuten que discute dos planteamientos en la realizacioacuten de redes activas la idea del conmutador programable y la de la caacutepsula Una red es activa si en sus aacuterboles de distribucioacuten multicast existen nodos activos con capacidad para ejecutar programas yo capaces de implementar mecanismos de propagacioacuten de coacutedigo Algunas de las ventajas de los protocolos activos son conseguidas instalando nodos activos en puntos estrateacutegicos de la red Otro nuevo concepto es presentado en [21] como una metodologiacutea para el disentildeo de protocolos Los protocol boosters son una nueva contribucioacuten a las redes activas o programables Una ventaja de los boosters es que pueden ser faacutecilmente 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 aacuterea extensa Este papel introduce una arquitectura software orientada a agente y propone el concepto de agente de comunicacioacuten para servicio de comunicacioacuten 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 artiacuteculo muestra agentes software moacuteviles usados para implementar operaciones robustas y funciones de mantenimiento en redes ATM Los agentes desempentildean un rol similar al de las ceacutelulas OAM en ATM estaacutendar pues son transmitidos entre entidades de control a intervalos regulares usando recursos predefinidos La diferencia entre los agentes moacuteviles y las ceacutelulas OAM reside en que eacutestos pueden contener coacutedigo Para concluir destacar que la integracioacuten del traacutefico IP sobre tecnologiacutea ATM es tambieacuten uno de los campos maacutes activos en la actualidad En esta liacutenea pueden destacarse los siguientes protocolos IP-over-ATM IP Switching Tag Switching NHRP MPOA IMSS CSR ARIS AREQUIPARED y EPD Referencias

1 ____ Native ATM Service Semantic Description Version 1 ATM Forum Technical Committee ATM Forum Document af-saa-0048000 (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 Broadband Networks Multimedia Applications Services and Techniques ECMASTrsquo98 Springer (May 1998)

3 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 Nordm 3 (April 1997)

4 W D Zhong K Yukimatsu Design requeriments and architectures for multicast ATM switching IEICE Trans Com Vol E77-B pp 1420-1428 (Nov 1994)

5 ____ ATM user-network interface version 31 specification ATM Forum (1994)

6 ____ Traffic Management Specification Version 40 ATM Forum Technical Committee ATM Forum Document af-tm-0056000 (April 1996)

7 D Kandlur D Saha and W Willebeck Protocol Architecture for multimedia Application over ATM Networks IEEE Journal Selected and Communications Vol 14 Nordm 7 pp 1349-1359 (Sep 1996)

8 R Ahuja S Keshav and H Saran Design Implementation and Performance Measurement of a Native-Mode ATM Transport Layer (Estended Version) IEEEACM Transactions on Networking Vol 4 Nordm 4 (Aug 1996)

9 R Karabek A Native ATM Protocol Architecture Design and Performance Evaluation IEEE Proceedings 22nd Annual Conference on Local Computer Networks pp 204-210 (1997)

10 D C Feldmeier A framework of architectural concepts for high-speed communications systems IEEE J Select Areas CommunVol11 Nordm 4 (May 1993)

11 T Anker D Breitgand D Dolev Z Levy Congress CONnection-oriented Group-address RESolution Service Proceeding of SPIE97 vol 3233 on Broadband Networking Technologies Nov (1997)

12 kStack httpcometcolumbiaedusoftwarekStack

13 T La Porta and M Schwartz Architectures Features and Implementation of High-Speed Transport Protocols IEEE Network Magazine pp 14-22 (May 1991)

14 ____ B-ISDN ATM Adaptation Layer Service Specific Connection Oriented Protocol (SSCOP) Q2110 ITU-T (10-Mar 1994)

15 J Soleacute-Pareta J Vila-Sallent Network-based paralell computing over ATM using improved SSCOP protocol Computer Communications 19 pp 915-926 (1996)

16 K Obraczka Multicast Transport Protocols A survey and Taxonomy IEEE Communi Magazine (1998)

17 R Venkateswaran CS Raghavendra X Chen and VP Kumar A Scalable Dynamic Multicast Routing Algorithm in ATM Networks IEEE pp 1361-1365 (1997)

18 Matthias Grossglauser and KK Ramakrishnan SEAM Scalable and Efficient ATM Multicast IEEE 1997 pp 867-875 (1997)

19 M Nguyen and M Schwartz MCMP A Transportsession level Distributed Protocol for Desktop Conference Setup IEEE Journal Selected and comunications Vol 14 Nordm 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 Nordm 3 pp 437-443 (April 1998)

22 R Kishimoto Agent communication system for multimedia communication services INFOCOMrsquo96 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 Nordm 3 pp 414-423 (April 1998)

  • ATM - Modo de Transferencia Asiacutencrona
  • Revisioacuten y Clasificacioacuten de Protocolos para Redes de Tecnologiacutea ATM
    • Resumen
    • 1-Introduccioacuten y motivaciones
    • 2- Protocolos nativos ATM
    • 3- Protocolos de transporte para redes ATM
    • 4- Protocolos multipoint
    • 5- Nuevos campos de investigacioacuten
      • Referencias
Page 11: Atm

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 opcioacuten se toma ventaja del uso actual del FR el cual es proveer un mallado virtual entre diferentes sitios para cargar traacutefico no orientado a conexioacuten 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 conmutacioacuten 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 traveacutes de sus respectivas interfaces de red (NNIs) Esto permitiriacutea a un proveedor de red manejar esta heterogeacutenea red como un todo Frame Relay provee usualmente la interconexioacuten para LAN a pesar de su natural orientacioacuten a conexioacuten 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 sobresimplificacioacuten los dos protocolos (AAL 3 y AAL 5) ofrecen basicamente el mismo servicio CPAAL (Parte Comuacuten 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 implementacioacuten y eficiencia del protocolo que incide en el costo Las caracteriacutesticas a tomar en cuenta cuyo detalle puede ser tema de otro artiacuteculo tienen que ver con Delimitacioacuten y Alineamiento de Tramas Multiplexacioacuten Deteccioacuten de errores de transmisioacuten eficiencia en la transmisioacuten 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 tecnologiacutea de red empresarial virtual del futuro un teacutermino que refleja tanto la evolucioacuten del modelo empresarial global y el eacutenfasis en la conectividad loacutegica donde los usuarios obtienen acceso a los recursos que necesitan y el operador de la red provee las rutas de conexioacuten y asigna el ancho de banda necesario a fuentes de traacutefico muy diferentes (voz datos viacutedeo) Aquellos que construyen y operan redes deben volver los ojos a las capacidades de la tecnologiacutea ATM ya que aspiran a la maacutegica combinacioacuten interconectividad global - escalabilidad de tecnologiacuteas y satisfaccioacuten del cliente local

BIBLIOGRAFIA

1 CCITT Rec I362 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 vol2 No8 ATM Testing crosses network boundaries Jim Frimmel

6 Newslink Alcatel Telecomrsquos customer magazine Vol IV No4 4th Quarter 1996 Adapting Networks to the Internet Challenge Krish Prabhu

Trabajo realizado por

Ivan Dario Cruz PradaNicruz[arroba]col1telecomcomco

Revisioacuten y Clasificacioacuten de Protocolos para Redes de Tecnologiacutea ATM

Joseacute Luis Gonzaacutelez-Saacutenchez y Jordi Domingo-Pascual

ResumenLa tecnologiacutea 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 investigacioacuten maacutes activo con la aspiracioacuten 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 asiacute como las caracteriacutesticas multicast la escalabilidad y la fiabilidad Se profundiza en el concepto de protocolo nativo ATM y son introducidos los protocolos maacutes importantes que satisfacen este importante requerimiento (N3 CONGRESS y kStack entre otros) Es importante destacar tambieacuten los protocolos de transporte pensados especiacuteficamente para la tecnologiacutea ATM La caracteriacutestica multicast (multipoint-to-multipoint) es una de las que maacutes esfuerzo estaacute costando garantizar a ATM pero existen ya propuestas que permiten la comunicacioacuten fiable a elevados anchos de banda y entre muacuteltiples emisores y receptores (SMART MCMP o MWAX) El artiacuteculo concluye con las investigacioness maacutes novedosas en torno a los protocolos ATM como las iniciativas que proponen redes ATM programables o activas (active networks) usando agentes moacuteviles

1-Introduccioacuten y motivacionesLa actual demanda de aplicaciones relacionadas con informacioacuten multimedia como son la video-conferencia audio-conferencia video bajo demanda (VoD) o sistemas colaborativos (pizarras compartidas teletrabajo telemedicina etc) y su coexistencia con aplicaciones maacutes claacutesicas (bases de datos transferencias de ficheros WWW etc) requiere tecnologiacuteas de comunicaciones capaces de ofrecer elevadas prestaciones Estas elevadas prestaciones estaacuten directamente relacionadas con la calidad de servicio (QoS) y concretamente con conceptos claramente parametrizables como el ancho de banda y la velocidad de transmisioacuten (throughput) el retardo de las transferencias (delay) la variabilidad en el retardo (jitter) la fiabilidad (reliability) de las transmisiones las caracteriacutesticas de multidifusioacuten a grupos dispersos de usuarios (multicast) y la posibilidad de gestionar muacuteltiples clases de servicio o flujos de informacioacuten en redes multiclass Para que las nuevas tecnologiacuteas en comunicaciones puedan ofrecer estas caracteriacutesticas es necesario revisar potenciar y ampliar las actuales arquitecturas servicios y protocolosde comunicaciones En los uacuteltimos dos o tres antildeos las investigaciones en el campo de ATM estaacuten dado lugar a importantes propuestas cuyo principal objetivo es ofrecer a las aplicaciones demandadas actualmente algunas o todas las caracteriacutesticas citadas anteriormente Presentamos en este trabajo los conceptos y propuestas maacutes novedosas en el contexto de ATM para ayudar al lector interesado en el dinaacutemico complejo y sofisticado campo de los protocolos de comunicaciones Realizamos la revisioacuten de algunos de los maacutes importantes conceptos teacutecnicas ideas y mecanismos en protocolos de altas prestaciones para redes de tecnologiacutea ATM El principal objetivo de este documento es ofrecer una actualizada visioacuten general no extensiva ni profunda de los protocolos propuestos y en desarrollo para dotar a las diversas clases de servicio ATM de las citadas caracteriacutesticas de calidad de servicio que aporten las potenciales elevadas prestaciones que la tecnologiacutea ATM es capaz de ofrecer El resto del documento estaacute estructurado de la siguiente forma La seccioacuten 2 revisa el concepto de protocolo nativo centrado en el contexto de las redes ATM La seccioacuten 3 describe las propuestas maacutes interesantes actualmente en materia de protocolos de transporte El apartado 4 comenta las transferencias multicast como un importante objetivo para una tecnologiacutea orientada a la conexioacuten como es ATM Concluimos en la seccioacuten 5 con los campos de investigacioacuten abiertos recientemente como son las redes activas y los procolos booster

2- Protocolos nativos ATM

Las aplicaciones nativas ATM estaacuten especiacuteficamente pensadas para usar la tecnologiacutea ATM y para explotar al maacuteximo sus especiales caracteriacutesticas Los protocolos nativos se encargan por tanto de ofrecer esas caracteriacutesticas intriacutensecas de las redes de tecnologiacutea ATM (soporte de QoS sentildealizacioacuten direccionamiento etc) a las aplicaciones nativas ATM (VoD pizarras compartidas video-conferencia) No obstante existen tambieacuten activas investigaciones para conseguir soportar sobre redes ATM aplicaciones no nativas ATM desarrolladas para otras tecnologiacuteas (IP Frame Relay SMDS) En [1] el termino native ATM services define servicios ATM especiacuteficos 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 adaptacioacuten (AALs) Disponibilidad de circuitos virtuales conmutados (SVCs) y circuitos virtuales permanentes (PVCs) Consideraciones relativas a la gestioacuten de traacutefico (clases de servicio garantiacuteas de QoS etc) Posibilidad de distribucioacuten de conexiones y de participacioacuten local en la administracioacuten de la red (protocolos ILMI y OAM)

El propoacutesito de los servicios nativos ATM es ofrecer el acceso a las clases de servicio o a las caracteriacutesticas de QoS en redes ATM Estos servicios nativos tambieacuten ofrecen soporte a un amplio y heterogeacuteneo rango de flujos con diversas propiedades y requerimientos recomendados en [1] Los protocolos de transferencia nativos ATM gestionan la sentildealizacioacuten UNI para establecer los SVCs configurar PVCs y mapear los perfiles de QoS en la correspondiente clase de servicio Los protocolos nativos tambieacuten realizan funciones claacutesicas como las de transporte mecanismos de control de errores transferencia de datos y controles de flujo y de congestioacuten En la referencia [1] se especifica la definicioacuten semaacutentica de los servicios y consideramos que es uacutetil contrastar esta semaacutentica con las redes ATM actuales que usan TCP como capa de transporte e IP-over-ATM como capa de red planteamiento por otro lado poco adecuado [2] por las siguientes razones

Las redes IP no garantizan la QoS extremo-extremo ofrecida por las redes ATM a circuitos individuales IP multiplexa muacuteltiples conexiones de transporte con distintos requerimientos de QoS en VCs simples TCP no soporta ceacutelulas RM (Resource Management) ABR y por consiguiente no puede usar directamente las garantiacuteas de QoS ofrecidas por la red ATM Adaptation Layer 5 (AAL5) realiza labores de checksum para detectar corrupcioacuten de datos TCP tambieacuten realiza estas labores (redundantes con AAL5) costosas en overhead (cada byte de un paquete debe ser chequeado) TCPIP son la representacioacuten de un grupo de protocolos bastante maacutes 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] Ademaacutes 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 tecnologiacutea ATM y tambieacuten existen antiguas y no nativas aplicaciones Este escenario implica cambiar las aplicaciones o proponer nuevas pilas de protocolos nativos ATM La encapsulacioacuten consecutiva de paquetes genera problemas de overhead y funciones redundantes como se ha argumentado anteriormente La limitacioacuten de recursos en los sistemas finales es otra importante motivacioacuten 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 puacuteblicos disfrutan tambieacuten de estas ventajas ATM RDSI y la telefoniacutea ofrecen un esquema de direccionamiento universal basado en NSAPE164 el cual es capaz de enrutar traacutefico de forma nativa Por tanto aunque ATM dispone de protocolos nativos con direccionamiento intriacutenceso estructurado y jeraacuterquico eacuteste no es aprovechado por las aplicaciones que estaacuten 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 tambieacuten existen importantes investigaciones en torno a los protocolos nativos ATM En esta seccioacuten se muestran las propuestas maacutes importantes y actuales en materia de protocolos nativos ATM[2] [7] [8] [9] [10] [11] [12] que a su vezestaacuten sirviendo de base para nuevas investigaciones

[8] presentan el disentildeo implementacioacuten y comportamiento de una pila en modo nativo ATM y contrasta la semaacutentica 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 automaacuteticamente los siguientes problemas

IP-over-ATM no ofrece garantiacutea de QoS pues sus aplicaciones soacutelo ven la interfaz IP El nuacutecleo 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 sentildealizacioacuten 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 caracteriacutesticas la entrega fiable y no fiable de datos con control de flujo Este protocolo de transporte es ampliado en la seccioacuten 5 [2] presenta N3 (Native Non-broadcasting medium access Networking) un protocolo de transporte ligero y nativo ATM La pila N3 se ha disentildeado 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 ademaacutes aporta otras importantes novedades Los principales componentes de N3 incluyen una API sockets ATM nativa un protocolo de transporte ATM y un servicio de nombres ATM (Fig2) El protocolo de transporte ATM propuesto en [2] ofrece soporte para tres diferentes tipos de servicio entrega garantizada (mecanismos de retransmisioacuten) 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 congestioacuten de la transferencia de datagramas y de la multiplexacioacuten 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 maacutes importante El Flow Management se responsabiliza de manipular los flujos de datos desde y hasta la red viacutea la interfaz AAL La segmentacioacuten el reensamblado y el control de errores es tambieacuten 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 congestioacuten y de flujo extremo-extremo maacutes complejo

[7] describe la semaacutentica de una pila de protocolos y explora una nueva arquitectura de protocolo adaptada a la tecnologiacutea ATM y a las aplicaciones multimedia El disentildeo estaacute basado en tres principios baacutesicos separacioacuten de flujos de control y de datos minimizacioacuten del overhead y de la duplicidad de funciones y acceso de las aplicaciones al nivel ATM con garantiacuteas 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-over-ATM 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 moacutedulo CNTL abre una conexioacuten de sentildealizacioacuten con el dispositivo ATM y establece una gestioacuten de las llamadas de mensajes de configuracioacuten PF_ATM separa flujos de datos y de control para aliviar el liacutemite de comportamiento en las comunicaciones Esto permite a los mecanismos de control de traacutefico ser raacutepidos y sencillos mientras los mecanismos de control pueden ser tan complicados como sea necesario Esta separacioacuten permite tambieacuten que los dispositivos puedan estar en los puntos finales de una conexioacuten La interfaz PF_ATM da a las aplicaciones acceso directo a la capa de enlace ATM y extiende las garantiacuteas de QoS a los puntos extremos de la comunicacioacuten Un segundo prototipo[7] es disentildeado e implementado con dos objetivos principales en la optimizacioacuten de la pila nativa ATM

Optimizar los caminos de datos entre los adaptadores ATM aprovechando la separacioacuten de flujos de control y de datos y la capacidad de gestioacuten de datos especiacuteficos de las conexiones de la pila ATM

Optimizar el procesamiento de overheads usando una pila de protocolos nativo ATM en lugar de UDPIP

[11] introduce CONGRESS (CONnection oriented Group-address RESolution Service) otro eficiente protocolo nativo ATM para la resolucioacuten y gestioacuten 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 disentildeo basado en los dos siguientes principios

Disentildeo jeraacuterquico los servicios del protocolo son ofrecidos a las aplicaciones por muacuteltiples servidores organizados jeraacuterquicamente No inundacioacuten se evita la inundacioacuten 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 implementacioacuten sobre Unix y Windows NT estaacute 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 antildeadido un moacutedulo que monitoria la QoS extremo-a-extremo

3- Protocolos de transporte para redes ATMEn los dos o tres uacuteltimos antildeos ha habido numerosos e interesante intentos por disentildear protocolos de transporte La referencia [10] presenta un completo y ya claacutesico resumen de las propuestas maacutes interesantes en materia de protocolos de transporte para redes de alta velocidad (mayoritariamente IP en el artiacuteculo) Ademaacutes la referencia [13] ofrece una interesante visioacuten de las caracteriacutesticas maacutes importantes en los protocolos de elevada velocidad Son estudiadas tambieacuten diversas arquitecturas de protocolos y varias teacutecnicas de implementacioacuten Los protocolos de transporte de elevada velocidad son fuente de activas investigaciones y estaacuten en constante evolucioacuten desde hace maacutes de dos deacutecadas 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 aacutembito de las comunicaciones que ha recibido mayor atencioacuten es la capa de transporte la cuarta capa del OSI-RM de los protocolos de comunicaciones TCP e ISO TP4 son los dos maacutes populares protocolos de transporte Pero centraacutendonos maacutes concretamente en el aacutembito de ATM la literatura presenta varios protocolos de transporte y arquitecturas para redes de alta velocidad revisadas resumidamente a continuacioacuten [7] ofrece una excelente y didaacutectica arquitectura de pila de protocolos para aplicaciones multimedia en modo nativo ATM Esta arquitectura de protocolo ha sido ya descrita brevemente en la seccioacuten anterior [8] presentan el disentildeo implementacioacuten 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 estaacute formada por tres entidades principales aplicacioacuten sentildealizacioacuten y transporte La siguiente Tabla 1 muestra un conjunto de nueve baacutesicos 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 combinacioacuten de servicios La marca X indica el servicio baacutesico soportado en cada clase de servicio general

Clases de servicio

Servicios Servicio de comportamiento

garantizado

Servicio fiable Servicio Best effort

- Transferencia Simplex de datos

X X X

- Control de errores - deteccion de errorestimeouts retransmisiones

No existente (ofrecido por

AAL5)

- Bucle abierto - Control de flujo realimentado

No existente -

- X

- No existente

- Tamantildeo de mensaje ilimitado

X X X

- Eleccioacuten de blocking - Aplicacioacuten Non-blocking

X X

X X

X X

- Eleccioacuten de byte stream - Semaacutentica transferencia de mensajes

X X

X X

X X

- Garantiacuteas de QoS requerimientos de ancho de banda

No soportado No soportado

- Reserva de recursos X No existente No existente

- Transferencias Multicast X No soportado Para servicios no fiables

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 recuperacioacuten de peacuterdidas del protocolo estaacutendar SSCOP [14] y demuestran que el resultado ofrece baja latencia eficiente recuperacioacuten de ceacutelulas perdidas y es tan robusto como el estaacutendar SSCOP

4- Protocolos multipointEl crecimiento de las redes ATM viene motivado en parte por la demanda de servicios multimedia para grupos dispersos de usuarios El traacutefico multicast tiene caracteriacutesticas particulares descritas para ATM en UNI 40 [6] y anteriores [5] La distribucioacuten de informacioacuten punto-a-multipunto (uno-a-muchos) o multipunto-a-multipunto (muchos-a-muchos) es un objetivo baacutesico propuesto por varios protocolos y arquitecturas ATM que ofrecen el soporte multimedia yo multicast como audio-conferencia video-conferencia trabajos colaborativos o VoD ATM es auacuten una tecnologiacutea emergente disentildeada 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 30) para ATM define conexiones punto-a-multipunto y las conexiones multipunto-a-multipunto soacutelo 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 topologiacutea completamente mallada todos-con-todos Aunque esta topologiacutea ofrece conexiones multipunto-a-multipunto hay que destacar que no escala bien cuando el nuacutemero de participantes es elevado Una alternativa al anterior esquema es el uso de un servidor que actuacutea a modo de raiacutez en el aacuterbol multipunto Este meacutetodo soacutelo requiere un nodo raiacutez para almacenar informacioacuten pero la desventaja de este meacutetodo son las potenciales congestiones en el servidor

cuando debe encargarse de enviacuteos y retransmisiones de las conexiones multipunto-a-multipunto

Para solventar las limitaciones de UNI 30 y UNI 31 [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 sentildealizacioacuten ATM (UNI 31 UNI 40) [4][5][6] Comenzamos destacando la referencia [16] como un reciente trabajo que revisa y compara los protocolos de transporte multicast maacutes importantes en Internet como MTP-2 XTP RTP SRM RAMP RMTP MFTP STORM etc IETF e IRTF (como ITU-T y ATM Forum) tambieacuten impulsan una importante actividad en este campo La referencia [16] revisa los maacutes representativos protocolos multicast y los clasifica de acuerdo a la taxonomiacutea de varias caracteriacutesticas (propagacioacuten de datos mecanismos de fiabilidad retransmisiones control de congestioacuten y de flujo gestioacuten de grupos multicast etc) En Internet los mecanismos efectivos de control de congestioacuten son una de las prioridades en las investigaciones de las transferencias multicast fiables Los mecanismos de seguridad y las teacutecnicas escalables de recuperacioacuten 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 maacutes importantes caracteriacutesticas En esta seccioacuten 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 maacutes interesantes en los siguientes paacuterrafos SMART (shared many-to-many ATM reservations)[3] es un protocolo para controlar un aacuterbol ATM multicast compartido soportando comunicaciones muchos-a-muchos (many-to-many) Esta propuesta tiene importantes caracteriacutesticas como que reside completamente en la capa ATM y no requiere ninguacuten servidor soporta uno o varios VCCs (y tambieacuten VPCs) cuyo nuacutemero es libremente configurado y es independiente del nuacutemero de puntos finales usa el concepto de bloques de datos como en la clase de servicio ABT y tambieacuten permite VCCs de las clases CBR VBR o UBR el protocolo garantiza que no existen puntos de interrelacioacuten en los VCC del aacuterbol son respetadas las garantiacuteas del contrato de traacutefico asociado con los VCCs etc SMART puede ser entendido como un protocolo completamente distribuido para coordinar la distribucioacuten de VPIsVCIs 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 ceacutelulas de datos desde diferentes fuentes pueden llegar intercaladas a un destinatario) y tambieacuten Demand Sharing (los recursos asignados a conexiones muchos-a-muchos son dinaacutemicamente compartidas entre todas las potenciales fuentes El artiacuteculo [3] describe el protocolo SMART formal e informalmente y propone completas pruebas de correccioacuten y un detallado anaacutelisis de comportamiento para estudios futuros Tambieacuten son sugeridas otras investigaciones como son ofrecer justicia en los accesos a los aacuterboles multicast investigar las ceacutelulas RM perioacutedicamente para aliviar las congestiones en la red o disminuir el tiempo de acceso del usuario a los aacuterboles de distribucioacuten multicast anaacutelisis de las ceacutelulas RM dentro de cada VCC o fuera enviando todas las ceacutelulas RM en un VCC dedicado En [17] se presenta MWAX un algoritmo dinaacutemico 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 artiacuteculo describe un esquema jeraacuterquico basado en CBT para incorporar routing multipunto-a-multipunto en PNNI En el algoritmo los nodos core actuacutean como participantes pasivos para eliminar la dependencia en la seleccioacuten de estos nodos Con un mecanismo de backup se consigue un algoritmo tolerante a fallos en los nodos core lo cual puede ser faacutecilmente 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 jerarquiacutea SEAM (Scalable and Efficient ATM Multicast) [18] propone una arquitectura escalable eficiente y multicast multipunto-a-multipunto para redes ATM que usa un soacutelo VC para un grupo multicast de muacuteltiples 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 Tambieacuten realiza aportaciones para conseguir soportar IP multicast sobre redes ATM extensas

SEAM usa un soacutelo aacuterbol de distribucioacuten 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 sentildealizacioacuten del grupo Este trabajo deja abiertas investigaciones referentes a la gestioacuten de traacutefico y a la entrega fiable de traacuteficos multicasting Concluimos esta seccioacuten destacando MCMP (Multiparty Conference Management Protocol) [19] que sin estar pensado especiacuteficamente para ATM es un protocolo de nivel sesioacutentransporte distribuido extremo-extremo y desarrollado para gestioacuten de grupos de aplicaciones de conferencia MCMP es un conjunto de algoritmos de control distribuido para configuracioacuten de conferencias multipunto y gestioacuten de miembros de grupos de usuarios Conceptualmente MCMP reside en el nivel de sesioacuten en el que se establece la infraestructura para activar la transferencia de informacioacuten entre los participantes en la conferencia Pero funcionalmente el protocolo acompasa los niveles de sesioacuten y de transporte pues utiliza directamente servicios del nivel de red Son destacables las condiciones de correccioacuten (conectividad validacioacuten unicidad consistencia y terminacioacuten) que deben ser satisfechas una vez que la conferencia ha sido configurada por el algoritmo de configuracioacuten de MCMP El artiacuteculo muestra exhaustivas pruebas de correccioacuten para uno de los algoritmos y tambieacuten describe la especificacioacuten y verificacioacuten del protocolo

5- Nuevos campos de investigacioacutenEn todas las redes existen gran variedad de elementos hardware (switchs routers bridges brouters hubs ETDs etc) que realizan muy diversas funciones (conmutacioacuten routing puenteo controles de congestioacuten y de flujo garantiacutea de QoS ejecucioacuten de aplicaciones etc) En la actualidad la red es mayormente un canal de comunicacioacuten para transferir paquetes entre equipos finales (ayudada por los elementos hardware antes citados) Pero tambieacuten se estaacuten realizando importante esfuerzos para equipar a los elementos hardware con elevadas prestaciones aportadas por diversas teacutecnicas software Esto dota a la red de caracteriacutesticas activas (active networks) en el sentido de que los elementos hardware que la componen computan modifican u operan los contenidos de los paquetes y tambieacuten seraacuten capaces de transferir o propagar coacutedigo Por consiguiente una red activa es una red programable [20] es una excelente revisioacuten de este novedoso campo de investigacioacuten que discute dos planteamientos en la realizacioacuten de redes activas la idea del conmutador programable y la de la caacutepsula Una red es activa si en sus aacuterboles de distribucioacuten multicast existen nodos activos con capacidad para ejecutar programas yo capaces de implementar mecanismos de propagacioacuten de coacutedigo Algunas de las ventajas de los protocolos activos son conseguidas instalando nodos activos en puntos estrateacutegicos de la red Otro nuevo concepto es presentado en [21] como una metodologiacutea para el disentildeo de protocolos Los protocol boosters son una nueva contribucioacuten a las redes activas o programables Una ventaja de los boosters es que pueden ser faacutecilmente 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 aacuterea extensa Este papel introduce una arquitectura software orientada a agente y propone el concepto de agente de comunicacioacuten para servicio de comunicacioacuten 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 artiacuteculo muestra agentes software moacuteviles usados para implementar operaciones robustas y funciones de mantenimiento en redes ATM Los agentes desempentildean un rol similar al de las ceacutelulas OAM en ATM estaacutendar pues son transmitidos entre entidades de control a intervalos regulares usando recursos predefinidos La diferencia entre los agentes moacuteviles y las ceacutelulas OAM reside en que eacutestos pueden contener coacutedigo Para concluir destacar que la integracioacuten del traacutefico IP sobre tecnologiacutea ATM es tambieacuten uno de los campos maacutes activos en la actualidad En esta liacutenea pueden destacarse los siguientes protocolos IP-over-ATM IP Switching Tag Switching NHRP MPOA IMSS CSR ARIS AREQUIPARED y EPD Referencias

1 ____ Native ATM Service Semantic Description Version 1 ATM Forum Technical Committee ATM Forum Document af-saa-0048000 (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 Broadband Networks Multimedia Applications Services and Techniques ECMASTrsquo98 Springer (May 1998)

3 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 Nordm 3 (April 1997)

4 W D Zhong K Yukimatsu Design requeriments and architectures for multicast ATM switching IEICE Trans Com Vol E77-B pp 1420-1428 (Nov 1994)

5 ____ ATM user-network interface version 31 specification ATM Forum (1994)

6 ____ Traffic Management Specification Version 40 ATM Forum Technical Committee ATM Forum Document af-tm-0056000 (April 1996)

7 D Kandlur D Saha and W Willebeck Protocol Architecture for multimedia Application over ATM Networks IEEE Journal Selected and Communications Vol 14 Nordm 7 pp 1349-1359 (Sep 1996)

8 R Ahuja S Keshav and H Saran Design Implementation and Performance Measurement of a Native-Mode ATM Transport Layer (Estended Version) IEEEACM Transactions on Networking Vol 4 Nordm 4 (Aug 1996)

9 R Karabek A Native ATM Protocol Architecture Design and Performance Evaluation IEEE Proceedings 22nd Annual Conference on Local Computer Networks pp 204-210 (1997)

10 D C Feldmeier A framework of architectural concepts for high-speed communications systems IEEE J Select Areas CommunVol11 Nordm 4 (May 1993)

11 T Anker D Breitgand D Dolev Z Levy Congress CONnection-oriented Group-address RESolution Service Proceeding of SPIE97 vol 3233 on Broadband Networking Technologies Nov (1997)

12 kStack httpcometcolumbiaedusoftwarekStack

13 T La Porta and M Schwartz Architectures Features and Implementation of High-Speed Transport Protocols IEEE Network Magazine pp 14-22 (May 1991)

14 ____ B-ISDN ATM Adaptation Layer Service Specific Connection Oriented Protocol (SSCOP) Q2110 ITU-T (10-Mar 1994)

15 J Soleacute-Pareta J Vila-Sallent Network-based paralell computing over ATM using improved SSCOP protocol Computer Communications 19 pp 915-926 (1996)

16 K Obraczka Multicast Transport Protocols A survey and Taxonomy IEEE Communi Magazine (1998)

17 R Venkateswaran CS Raghavendra X Chen and VP Kumar A Scalable Dynamic Multicast Routing Algorithm in ATM Networks IEEE pp 1361-1365 (1997)

18 Matthias Grossglauser and KK Ramakrishnan SEAM Scalable and Efficient ATM Multicast IEEE 1997 pp 867-875 (1997)

19 M Nguyen and M Schwartz MCMP A Transportsession level Distributed Protocol for Desktop Conference Setup IEEE Journal Selected and comunications Vol 14 Nordm 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 Nordm 3 pp 437-443 (April 1998)

22 R Kishimoto Agent communication system for multimedia communication services INFOCOMrsquo96 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 Nordm 3 pp 414-423 (April 1998)

  • ATM - Modo de Transferencia Asiacutencrona
  • Revisioacuten y Clasificacioacuten de Protocolos para Redes de Tecnologiacutea ATM
    • Resumen
    • 1-Introduccioacuten y motivaciones
    • 2- Protocolos nativos ATM
    • 3- Protocolos de transporte para redes ATM
    • 4- Protocolos multipoint
    • 5- Nuevos campos de investigacioacuten
      • Referencias
Page 12: Atm

Ivan Dario Cruz PradaNicruz[arroba]col1telecomcomco

Revisioacuten y Clasificacioacuten de Protocolos para Redes de Tecnologiacutea ATM

Joseacute Luis Gonzaacutelez-Saacutenchez y Jordi Domingo-Pascual

ResumenLa tecnologiacutea 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 investigacioacuten maacutes activo con la aspiracioacuten 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 asiacute como las caracteriacutesticas multicast la escalabilidad y la fiabilidad Se profundiza en el concepto de protocolo nativo ATM y son introducidos los protocolos maacutes importantes que satisfacen este importante requerimiento (N3 CONGRESS y kStack entre otros) Es importante destacar tambieacuten los protocolos de transporte pensados especiacuteficamente para la tecnologiacutea ATM La caracteriacutestica multicast (multipoint-to-multipoint) es una de las que maacutes esfuerzo estaacute costando garantizar a ATM pero existen ya propuestas que permiten la comunicacioacuten fiable a elevados anchos de banda y entre muacuteltiples emisores y receptores (SMART MCMP o MWAX) El artiacuteculo concluye con las investigacioness maacutes novedosas en torno a los protocolos ATM como las iniciativas que proponen redes ATM programables o activas (active networks) usando agentes moacuteviles

1-Introduccioacuten y motivacionesLa actual demanda de aplicaciones relacionadas con informacioacuten multimedia como son la video-conferencia audio-conferencia video bajo demanda (VoD) o sistemas colaborativos (pizarras compartidas teletrabajo telemedicina etc) y su coexistencia con aplicaciones maacutes claacutesicas (bases de datos transferencias de ficheros WWW etc) requiere tecnologiacuteas de comunicaciones capaces de ofrecer elevadas prestaciones Estas elevadas prestaciones estaacuten directamente relacionadas con la calidad de servicio (QoS) y concretamente con conceptos claramente parametrizables como el ancho de banda y la velocidad de transmisioacuten (throughput) el retardo de las transferencias (delay) la variabilidad en el retardo (jitter) la fiabilidad (reliability) de las transmisiones las caracteriacutesticas de multidifusioacuten a grupos dispersos de usuarios (multicast) y la posibilidad de gestionar muacuteltiples clases de servicio o flujos de informacioacuten en redes multiclass Para que las nuevas tecnologiacuteas en comunicaciones puedan ofrecer estas caracteriacutesticas es necesario revisar potenciar y ampliar las actuales arquitecturas servicios y protocolosde comunicaciones En los uacuteltimos dos o tres antildeos las investigaciones en el campo de ATM estaacuten dado lugar a importantes propuestas cuyo principal objetivo es ofrecer a las aplicaciones demandadas actualmente algunas o todas las caracteriacutesticas citadas anteriormente Presentamos en este trabajo los conceptos y propuestas maacutes novedosas en el contexto de ATM para ayudar al lector interesado en el dinaacutemico complejo y sofisticado campo de los protocolos de comunicaciones Realizamos la revisioacuten de algunos de los maacutes importantes conceptos teacutecnicas ideas y mecanismos en protocolos de altas prestaciones para redes de tecnologiacutea ATM El principal objetivo de este documento es ofrecer una actualizada visioacuten general no extensiva ni profunda de los protocolos propuestos y en desarrollo para dotar a las diversas clases de servicio ATM de las citadas caracteriacutesticas de calidad de servicio que aporten las potenciales elevadas prestaciones que la tecnologiacutea ATM es capaz de ofrecer El resto del documento estaacute estructurado de la siguiente forma La seccioacuten 2 revisa el concepto de protocolo nativo centrado en el contexto de las redes ATM La seccioacuten 3 describe las propuestas maacutes interesantes actualmente en materia de protocolos de transporte El apartado 4 comenta las transferencias multicast como un importante objetivo para una tecnologiacutea orientada a la conexioacuten como es ATM Concluimos en la seccioacuten 5 con los campos de investigacioacuten abiertos recientemente como son las redes activas y los procolos booster

2- Protocolos nativos ATM

Las aplicaciones nativas ATM estaacuten especiacuteficamente pensadas para usar la tecnologiacutea ATM y para explotar al maacuteximo sus especiales caracteriacutesticas Los protocolos nativos se encargan por tanto de ofrecer esas caracteriacutesticas intriacutensecas de las redes de tecnologiacutea ATM (soporte de QoS sentildealizacioacuten direccionamiento etc) a las aplicaciones nativas ATM (VoD pizarras compartidas video-conferencia) No obstante existen tambieacuten activas investigaciones para conseguir soportar sobre redes ATM aplicaciones no nativas ATM desarrolladas para otras tecnologiacuteas (IP Frame Relay SMDS) En [1] el termino native ATM services define servicios ATM especiacuteficos 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 adaptacioacuten (AALs) Disponibilidad de circuitos virtuales conmutados (SVCs) y circuitos virtuales permanentes (PVCs) Consideraciones relativas a la gestioacuten de traacutefico (clases de servicio garantiacuteas de QoS etc) Posibilidad de distribucioacuten de conexiones y de participacioacuten local en la administracioacuten de la red (protocolos ILMI y OAM)

El propoacutesito de los servicios nativos ATM es ofrecer el acceso a las clases de servicio o a las caracteriacutesticas de QoS en redes ATM Estos servicios nativos tambieacuten ofrecen soporte a un amplio y heterogeacuteneo rango de flujos con diversas propiedades y requerimientos recomendados en [1] Los protocolos de transferencia nativos ATM gestionan la sentildealizacioacuten UNI para establecer los SVCs configurar PVCs y mapear los perfiles de QoS en la correspondiente clase de servicio Los protocolos nativos tambieacuten realizan funciones claacutesicas como las de transporte mecanismos de control de errores transferencia de datos y controles de flujo y de congestioacuten En la referencia [1] se especifica la definicioacuten semaacutentica de los servicios y consideramos que es uacutetil contrastar esta semaacutentica con las redes ATM actuales que usan TCP como capa de transporte e IP-over-ATM como capa de red planteamiento por otro lado poco adecuado [2] por las siguientes razones

Las redes IP no garantizan la QoS extremo-extremo ofrecida por las redes ATM a circuitos individuales IP multiplexa muacuteltiples conexiones de transporte con distintos requerimientos de QoS en VCs simples TCP no soporta ceacutelulas RM (Resource Management) ABR y por consiguiente no puede usar directamente las garantiacuteas de QoS ofrecidas por la red ATM Adaptation Layer 5 (AAL5) realiza labores de checksum para detectar corrupcioacuten de datos TCP tambieacuten realiza estas labores (redundantes con AAL5) costosas en overhead (cada byte de un paquete debe ser chequeado) TCPIP son la representacioacuten de un grupo de protocolos bastante maacutes 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] Ademaacutes 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 tecnologiacutea ATM y tambieacuten existen antiguas y no nativas aplicaciones Este escenario implica cambiar las aplicaciones o proponer nuevas pilas de protocolos nativos ATM La encapsulacioacuten consecutiva de paquetes genera problemas de overhead y funciones redundantes como se ha argumentado anteriormente La limitacioacuten de recursos en los sistemas finales es otra importante motivacioacuten 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 puacuteblicos disfrutan tambieacuten de estas ventajas ATM RDSI y la telefoniacutea ofrecen un esquema de direccionamiento universal basado en NSAPE164 el cual es capaz de enrutar traacutefico de forma nativa Por tanto aunque ATM dispone de protocolos nativos con direccionamiento intriacutenceso estructurado y jeraacuterquico eacuteste no es aprovechado por las aplicaciones que estaacuten 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 tambieacuten existen importantes investigaciones en torno a los protocolos nativos ATM En esta seccioacuten se muestran las propuestas maacutes importantes y actuales en materia de protocolos nativos ATM[2] [7] [8] [9] [10] [11] [12] que a su vezestaacuten sirviendo de base para nuevas investigaciones

[8] presentan el disentildeo implementacioacuten y comportamiento de una pila en modo nativo ATM y contrasta la semaacutentica 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 automaacuteticamente los siguientes problemas

IP-over-ATM no ofrece garantiacutea de QoS pues sus aplicaciones soacutelo ven la interfaz IP El nuacutecleo 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 sentildealizacioacuten 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 caracteriacutesticas la entrega fiable y no fiable de datos con control de flujo Este protocolo de transporte es ampliado en la seccioacuten 5 [2] presenta N3 (Native Non-broadcasting medium access Networking) un protocolo de transporte ligero y nativo ATM La pila N3 se ha disentildeado 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 ademaacutes aporta otras importantes novedades Los principales componentes de N3 incluyen una API sockets ATM nativa un protocolo de transporte ATM y un servicio de nombres ATM (Fig2) El protocolo de transporte ATM propuesto en [2] ofrece soporte para tres diferentes tipos de servicio entrega garantizada (mecanismos de retransmisioacuten) 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 congestioacuten de la transferencia de datagramas y de la multiplexacioacuten 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 maacutes importante El Flow Management se responsabiliza de manipular los flujos de datos desde y hasta la red viacutea la interfaz AAL La segmentacioacuten el reensamblado y el control de errores es tambieacuten 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 congestioacuten y de flujo extremo-extremo maacutes complejo

[7] describe la semaacutentica de una pila de protocolos y explora una nueva arquitectura de protocolo adaptada a la tecnologiacutea ATM y a las aplicaciones multimedia El disentildeo estaacute basado en tres principios baacutesicos separacioacuten de flujos de control y de datos minimizacioacuten del overhead y de la duplicidad de funciones y acceso de las aplicaciones al nivel ATM con garantiacuteas 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-over-ATM 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 moacutedulo CNTL abre una conexioacuten de sentildealizacioacuten con el dispositivo ATM y establece una gestioacuten de las llamadas de mensajes de configuracioacuten PF_ATM separa flujos de datos y de control para aliviar el liacutemite de comportamiento en las comunicaciones Esto permite a los mecanismos de control de traacutefico ser raacutepidos y sencillos mientras los mecanismos de control pueden ser tan complicados como sea necesario Esta separacioacuten permite tambieacuten que los dispositivos puedan estar en los puntos finales de una conexioacuten La interfaz PF_ATM da a las aplicaciones acceso directo a la capa de enlace ATM y extiende las garantiacuteas de QoS a los puntos extremos de la comunicacioacuten Un segundo prototipo[7] es disentildeado e implementado con dos objetivos principales en la optimizacioacuten de la pila nativa ATM

Optimizar los caminos de datos entre los adaptadores ATM aprovechando la separacioacuten de flujos de control y de datos y la capacidad de gestioacuten de datos especiacuteficos de las conexiones de la pila ATM

Optimizar el procesamiento de overheads usando una pila de protocolos nativo ATM en lugar de UDPIP

[11] introduce CONGRESS (CONnection oriented Group-address RESolution Service) otro eficiente protocolo nativo ATM para la resolucioacuten y gestioacuten 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 disentildeo basado en los dos siguientes principios

Disentildeo jeraacuterquico los servicios del protocolo son ofrecidos a las aplicaciones por muacuteltiples servidores organizados jeraacuterquicamente No inundacioacuten se evita la inundacioacuten 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 implementacioacuten sobre Unix y Windows NT estaacute 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 antildeadido un moacutedulo que monitoria la QoS extremo-a-extremo

3- Protocolos de transporte para redes ATMEn los dos o tres uacuteltimos antildeos ha habido numerosos e interesante intentos por disentildear protocolos de transporte La referencia [10] presenta un completo y ya claacutesico resumen de las propuestas maacutes interesantes en materia de protocolos de transporte para redes de alta velocidad (mayoritariamente IP en el artiacuteculo) Ademaacutes la referencia [13] ofrece una interesante visioacuten de las caracteriacutesticas maacutes importantes en los protocolos de elevada velocidad Son estudiadas tambieacuten diversas arquitecturas de protocolos y varias teacutecnicas de implementacioacuten Los protocolos de transporte de elevada velocidad son fuente de activas investigaciones y estaacuten en constante evolucioacuten desde hace maacutes de dos deacutecadas 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 aacutembito de las comunicaciones que ha recibido mayor atencioacuten es la capa de transporte la cuarta capa del OSI-RM de los protocolos de comunicaciones TCP e ISO TP4 son los dos maacutes populares protocolos de transporte Pero centraacutendonos maacutes concretamente en el aacutembito de ATM la literatura presenta varios protocolos de transporte y arquitecturas para redes de alta velocidad revisadas resumidamente a continuacioacuten [7] ofrece una excelente y didaacutectica arquitectura de pila de protocolos para aplicaciones multimedia en modo nativo ATM Esta arquitectura de protocolo ha sido ya descrita brevemente en la seccioacuten anterior [8] presentan el disentildeo implementacioacuten 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 estaacute formada por tres entidades principales aplicacioacuten sentildealizacioacuten y transporte La siguiente Tabla 1 muestra un conjunto de nueve baacutesicos 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 combinacioacuten de servicios La marca X indica el servicio baacutesico soportado en cada clase de servicio general

Clases de servicio

Servicios Servicio de comportamiento

garantizado

Servicio fiable Servicio Best effort

- Transferencia Simplex de datos

X X X

- Control de errores - deteccion de errorestimeouts retransmisiones

No existente (ofrecido por

AAL5)

- Bucle abierto - Control de flujo realimentado

No existente -

- X

- No existente

- Tamantildeo de mensaje ilimitado

X X X

- Eleccioacuten de blocking - Aplicacioacuten Non-blocking

X X

X X

X X

- Eleccioacuten de byte stream - Semaacutentica transferencia de mensajes

X X

X X

X X

- Garantiacuteas de QoS requerimientos de ancho de banda

No soportado No soportado

- Reserva de recursos X No existente No existente

- Transferencias Multicast X No soportado Para servicios no fiables

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 recuperacioacuten de peacuterdidas del protocolo estaacutendar SSCOP [14] y demuestran que el resultado ofrece baja latencia eficiente recuperacioacuten de ceacutelulas perdidas y es tan robusto como el estaacutendar SSCOP

4- Protocolos multipointEl crecimiento de las redes ATM viene motivado en parte por la demanda de servicios multimedia para grupos dispersos de usuarios El traacutefico multicast tiene caracteriacutesticas particulares descritas para ATM en UNI 40 [6] y anteriores [5] La distribucioacuten de informacioacuten punto-a-multipunto (uno-a-muchos) o multipunto-a-multipunto (muchos-a-muchos) es un objetivo baacutesico propuesto por varios protocolos y arquitecturas ATM que ofrecen el soporte multimedia yo multicast como audio-conferencia video-conferencia trabajos colaborativos o VoD ATM es auacuten una tecnologiacutea emergente disentildeada 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 30) para ATM define conexiones punto-a-multipunto y las conexiones multipunto-a-multipunto soacutelo 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 topologiacutea completamente mallada todos-con-todos Aunque esta topologiacutea ofrece conexiones multipunto-a-multipunto hay que destacar que no escala bien cuando el nuacutemero de participantes es elevado Una alternativa al anterior esquema es el uso de un servidor que actuacutea a modo de raiacutez en el aacuterbol multipunto Este meacutetodo soacutelo requiere un nodo raiacutez para almacenar informacioacuten pero la desventaja de este meacutetodo son las potenciales congestiones en el servidor

cuando debe encargarse de enviacuteos y retransmisiones de las conexiones multipunto-a-multipunto

Para solventar las limitaciones de UNI 30 y UNI 31 [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 sentildealizacioacuten ATM (UNI 31 UNI 40) [4][5][6] Comenzamos destacando la referencia [16] como un reciente trabajo que revisa y compara los protocolos de transporte multicast maacutes importantes en Internet como MTP-2 XTP RTP SRM RAMP RMTP MFTP STORM etc IETF e IRTF (como ITU-T y ATM Forum) tambieacuten impulsan una importante actividad en este campo La referencia [16] revisa los maacutes representativos protocolos multicast y los clasifica de acuerdo a la taxonomiacutea de varias caracteriacutesticas (propagacioacuten de datos mecanismos de fiabilidad retransmisiones control de congestioacuten y de flujo gestioacuten de grupos multicast etc) En Internet los mecanismos efectivos de control de congestioacuten son una de las prioridades en las investigaciones de las transferencias multicast fiables Los mecanismos de seguridad y las teacutecnicas escalables de recuperacioacuten 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 maacutes importantes caracteriacutesticas En esta seccioacuten 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 maacutes interesantes en los siguientes paacuterrafos SMART (shared many-to-many ATM reservations)[3] es un protocolo para controlar un aacuterbol ATM multicast compartido soportando comunicaciones muchos-a-muchos (many-to-many) Esta propuesta tiene importantes caracteriacutesticas como que reside completamente en la capa ATM y no requiere ninguacuten servidor soporta uno o varios VCCs (y tambieacuten VPCs) cuyo nuacutemero es libremente configurado y es independiente del nuacutemero de puntos finales usa el concepto de bloques de datos como en la clase de servicio ABT y tambieacuten permite VCCs de las clases CBR VBR o UBR el protocolo garantiza que no existen puntos de interrelacioacuten en los VCC del aacuterbol son respetadas las garantiacuteas del contrato de traacutefico asociado con los VCCs etc SMART puede ser entendido como un protocolo completamente distribuido para coordinar la distribucioacuten de VPIsVCIs 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 ceacutelulas de datos desde diferentes fuentes pueden llegar intercaladas a un destinatario) y tambieacuten Demand Sharing (los recursos asignados a conexiones muchos-a-muchos son dinaacutemicamente compartidas entre todas las potenciales fuentes El artiacuteculo [3] describe el protocolo SMART formal e informalmente y propone completas pruebas de correccioacuten y un detallado anaacutelisis de comportamiento para estudios futuros Tambieacuten son sugeridas otras investigaciones como son ofrecer justicia en los accesos a los aacuterboles multicast investigar las ceacutelulas RM perioacutedicamente para aliviar las congestiones en la red o disminuir el tiempo de acceso del usuario a los aacuterboles de distribucioacuten multicast anaacutelisis de las ceacutelulas RM dentro de cada VCC o fuera enviando todas las ceacutelulas RM en un VCC dedicado En [17] se presenta MWAX un algoritmo dinaacutemico 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 artiacuteculo describe un esquema jeraacuterquico basado en CBT para incorporar routing multipunto-a-multipunto en PNNI En el algoritmo los nodos core actuacutean como participantes pasivos para eliminar la dependencia en la seleccioacuten de estos nodos Con un mecanismo de backup se consigue un algoritmo tolerante a fallos en los nodos core lo cual puede ser faacutecilmente 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 jerarquiacutea SEAM (Scalable and Efficient ATM Multicast) [18] propone una arquitectura escalable eficiente y multicast multipunto-a-multipunto para redes ATM que usa un soacutelo VC para un grupo multicast de muacuteltiples 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 Tambieacuten realiza aportaciones para conseguir soportar IP multicast sobre redes ATM extensas

SEAM usa un soacutelo aacuterbol de distribucioacuten 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 sentildealizacioacuten del grupo Este trabajo deja abiertas investigaciones referentes a la gestioacuten de traacutefico y a la entrega fiable de traacuteficos multicasting Concluimos esta seccioacuten destacando MCMP (Multiparty Conference Management Protocol) [19] que sin estar pensado especiacuteficamente para ATM es un protocolo de nivel sesioacutentransporte distribuido extremo-extremo y desarrollado para gestioacuten de grupos de aplicaciones de conferencia MCMP es un conjunto de algoritmos de control distribuido para configuracioacuten de conferencias multipunto y gestioacuten de miembros de grupos de usuarios Conceptualmente MCMP reside en el nivel de sesioacuten en el que se establece la infraestructura para activar la transferencia de informacioacuten entre los participantes en la conferencia Pero funcionalmente el protocolo acompasa los niveles de sesioacuten y de transporte pues utiliza directamente servicios del nivel de red Son destacables las condiciones de correccioacuten (conectividad validacioacuten unicidad consistencia y terminacioacuten) que deben ser satisfechas una vez que la conferencia ha sido configurada por el algoritmo de configuracioacuten de MCMP El artiacuteculo muestra exhaustivas pruebas de correccioacuten para uno de los algoritmos y tambieacuten describe la especificacioacuten y verificacioacuten del protocolo

5- Nuevos campos de investigacioacutenEn todas las redes existen gran variedad de elementos hardware (switchs routers bridges brouters hubs ETDs etc) que realizan muy diversas funciones (conmutacioacuten routing puenteo controles de congestioacuten y de flujo garantiacutea de QoS ejecucioacuten de aplicaciones etc) En la actualidad la red es mayormente un canal de comunicacioacuten para transferir paquetes entre equipos finales (ayudada por los elementos hardware antes citados) Pero tambieacuten se estaacuten realizando importante esfuerzos para equipar a los elementos hardware con elevadas prestaciones aportadas por diversas teacutecnicas software Esto dota a la red de caracteriacutesticas activas (active networks) en el sentido de que los elementos hardware que la componen computan modifican u operan los contenidos de los paquetes y tambieacuten seraacuten capaces de transferir o propagar coacutedigo Por consiguiente una red activa es una red programable [20] es una excelente revisioacuten de este novedoso campo de investigacioacuten que discute dos planteamientos en la realizacioacuten de redes activas la idea del conmutador programable y la de la caacutepsula Una red es activa si en sus aacuterboles de distribucioacuten multicast existen nodos activos con capacidad para ejecutar programas yo capaces de implementar mecanismos de propagacioacuten de coacutedigo Algunas de las ventajas de los protocolos activos son conseguidas instalando nodos activos en puntos estrateacutegicos de la red Otro nuevo concepto es presentado en [21] como una metodologiacutea para el disentildeo de protocolos Los protocol boosters son una nueva contribucioacuten a las redes activas o programables Una ventaja de los boosters es que pueden ser faacutecilmente 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 aacuterea extensa Este papel introduce una arquitectura software orientada a agente y propone el concepto de agente de comunicacioacuten para servicio de comunicacioacuten 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 artiacuteculo muestra agentes software moacuteviles usados para implementar operaciones robustas y funciones de mantenimiento en redes ATM Los agentes desempentildean un rol similar al de las ceacutelulas OAM en ATM estaacutendar pues son transmitidos entre entidades de control a intervalos regulares usando recursos predefinidos La diferencia entre los agentes moacuteviles y las ceacutelulas OAM reside en que eacutestos pueden contener coacutedigo Para concluir destacar que la integracioacuten del traacutefico IP sobre tecnologiacutea ATM es tambieacuten uno de los campos maacutes activos en la actualidad En esta liacutenea pueden destacarse los siguientes protocolos IP-over-ATM IP Switching Tag Switching NHRP MPOA IMSS CSR ARIS AREQUIPARED y EPD Referencias

1 ____ Native ATM Service Semantic Description Version 1 ATM Forum Technical Committee ATM Forum Document af-saa-0048000 (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 Broadband Networks Multimedia Applications Services and Techniques ECMASTrsquo98 Springer (May 1998)

3 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 Nordm 3 (April 1997)

4 W D Zhong K Yukimatsu Design requeriments and architectures for multicast ATM switching IEICE Trans Com Vol E77-B pp 1420-1428 (Nov 1994)

5 ____ ATM user-network interface version 31 specification ATM Forum (1994)

6 ____ Traffic Management Specification Version 40 ATM Forum Technical Committee ATM Forum Document af-tm-0056000 (April 1996)

7 D Kandlur D Saha and W Willebeck Protocol Architecture for multimedia Application over ATM Networks IEEE Journal Selected and Communications Vol 14 Nordm 7 pp 1349-1359 (Sep 1996)

8 R Ahuja S Keshav and H Saran Design Implementation and Performance Measurement of a Native-Mode ATM Transport Layer (Estended Version) IEEEACM Transactions on Networking Vol 4 Nordm 4 (Aug 1996)

9 R Karabek A Native ATM Protocol Architecture Design and Performance Evaluation IEEE Proceedings 22nd Annual Conference on Local Computer Networks pp 204-210 (1997)

10 D C Feldmeier A framework of architectural concepts for high-speed communications systems IEEE J Select Areas CommunVol11 Nordm 4 (May 1993)

11 T Anker D Breitgand D Dolev Z Levy Congress CONnection-oriented Group-address RESolution Service Proceeding of SPIE97 vol 3233 on Broadband Networking Technologies Nov (1997)

12 kStack httpcometcolumbiaedusoftwarekStack

13 T La Porta and M Schwartz Architectures Features and Implementation of High-Speed Transport Protocols IEEE Network Magazine pp 14-22 (May 1991)

14 ____ B-ISDN ATM Adaptation Layer Service Specific Connection Oriented Protocol (SSCOP) Q2110 ITU-T (10-Mar 1994)

15 J Soleacute-Pareta J Vila-Sallent Network-based paralell computing over ATM using improved SSCOP protocol Computer Communications 19 pp 915-926 (1996)

16 K Obraczka Multicast Transport Protocols A survey and Taxonomy IEEE Communi Magazine (1998)

17 R Venkateswaran CS Raghavendra X Chen and VP Kumar A Scalable Dynamic Multicast Routing Algorithm in ATM Networks IEEE pp 1361-1365 (1997)

18 Matthias Grossglauser and KK Ramakrishnan SEAM Scalable and Efficient ATM Multicast IEEE 1997 pp 867-875 (1997)

19 M Nguyen and M Schwartz MCMP A Transportsession level Distributed Protocol for Desktop Conference Setup IEEE Journal Selected and comunications Vol 14 Nordm 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 Nordm 3 pp 437-443 (April 1998)

22 R Kishimoto Agent communication system for multimedia communication services INFOCOMrsquo96 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 Nordm 3 pp 414-423 (April 1998)

  • ATM - Modo de Transferencia Asiacutencrona
  • Revisioacuten y Clasificacioacuten de Protocolos para Redes de Tecnologiacutea ATM
    • Resumen
    • 1-Introduccioacuten y motivaciones
    • 2- Protocolos nativos ATM
    • 3- Protocolos de transporte para redes ATM
    • 4- Protocolos multipoint
    • 5- Nuevos campos de investigacioacuten
      • Referencias
Page 13: Atm

Las aplicaciones nativas ATM estaacuten especiacuteficamente pensadas para usar la tecnologiacutea ATM y para explotar al maacuteximo sus especiales caracteriacutesticas Los protocolos nativos se encargan por tanto de ofrecer esas caracteriacutesticas intriacutensecas de las redes de tecnologiacutea ATM (soporte de QoS sentildealizacioacuten direccionamiento etc) a las aplicaciones nativas ATM (VoD pizarras compartidas video-conferencia) No obstante existen tambieacuten activas investigaciones para conseguir soportar sobre redes ATM aplicaciones no nativas ATM desarrolladas para otras tecnologiacuteas (IP Frame Relay SMDS) En [1] el termino native ATM services define servicios ATM especiacuteficos 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 adaptacioacuten (AALs) Disponibilidad de circuitos virtuales conmutados (SVCs) y circuitos virtuales permanentes (PVCs) Consideraciones relativas a la gestioacuten de traacutefico (clases de servicio garantiacuteas de QoS etc) Posibilidad de distribucioacuten de conexiones y de participacioacuten local en la administracioacuten de la red (protocolos ILMI y OAM)

El propoacutesito de los servicios nativos ATM es ofrecer el acceso a las clases de servicio o a las caracteriacutesticas de QoS en redes ATM Estos servicios nativos tambieacuten ofrecen soporte a un amplio y heterogeacuteneo rango de flujos con diversas propiedades y requerimientos recomendados en [1] Los protocolos de transferencia nativos ATM gestionan la sentildealizacioacuten UNI para establecer los SVCs configurar PVCs y mapear los perfiles de QoS en la correspondiente clase de servicio Los protocolos nativos tambieacuten realizan funciones claacutesicas como las de transporte mecanismos de control de errores transferencia de datos y controles de flujo y de congestioacuten En la referencia [1] se especifica la definicioacuten semaacutentica de los servicios y consideramos que es uacutetil contrastar esta semaacutentica con las redes ATM actuales que usan TCP como capa de transporte e IP-over-ATM como capa de red planteamiento por otro lado poco adecuado [2] por las siguientes razones

Las redes IP no garantizan la QoS extremo-extremo ofrecida por las redes ATM a circuitos individuales IP multiplexa muacuteltiples conexiones de transporte con distintos requerimientos de QoS en VCs simples TCP no soporta ceacutelulas RM (Resource Management) ABR y por consiguiente no puede usar directamente las garantiacuteas de QoS ofrecidas por la red ATM Adaptation Layer 5 (AAL5) realiza labores de checksum para detectar corrupcioacuten de datos TCP tambieacuten realiza estas labores (redundantes con AAL5) costosas en overhead (cada byte de un paquete debe ser chequeado) TCPIP son la representacioacuten de un grupo de protocolos bastante maacutes 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] Ademaacutes 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 tecnologiacutea ATM y tambieacuten existen antiguas y no nativas aplicaciones Este escenario implica cambiar las aplicaciones o proponer nuevas pilas de protocolos nativos ATM La encapsulacioacuten consecutiva de paquetes genera problemas de overhead y funciones redundantes como se ha argumentado anteriormente La limitacioacuten de recursos en los sistemas finales es otra importante motivacioacuten 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 puacuteblicos disfrutan tambieacuten de estas ventajas ATM RDSI y la telefoniacutea ofrecen un esquema de direccionamiento universal basado en NSAPE164 el cual es capaz de enrutar traacutefico de forma nativa Por tanto aunque ATM dispone de protocolos nativos con direccionamiento intriacutenceso estructurado y jeraacuterquico eacuteste no es aprovechado por las aplicaciones que estaacuten 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 tambieacuten existen importantes investigaciones en torno a los protocolos nativos ATM En esta seccioacuten se muestran las propuestas maacutes importantes y actuales en materia de protocolos nativos ATM[2] [7] [8] [9] [10] [11] [12] que a su vezestaacuten sirviendo de base para nuevas investigaciones

[8] presentan el disentildeo implementacioacuten y comportamiento de una pila en modo nativo ATM y contrasta la semaacutentica 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 automaacuteticamente los siguientes problemas

IP-over-ATM no ofrece garantiacutea de QoS pues sus aplicaciones soacutelo ven la interfaz IP El nuacutecleo 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 sentildealizacioacuten 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 caracteriacutesticas la entrega fiable y no fiable de datos con control de flujo Este protocolo de transporte es ampliado en la seccioacuten 5 [2] presenta N3 (Native Non-broadcasting medium access Networking) un protocolo de transporte ligero y nativo ATM La pila N3 se ha disentildeado 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 ademaacutes aporta otras importantes novedades Los principales componentes de N3 incluyen una API sockets ATM nativa un protocolo de transporte ATM y un servicio de nombres ATM (Fig2) El protocolo de transporte ATM propuesto en [2] ofrece soporte para tres diferentes tipos de servicio entrega garantizada (mecanismos de retransmisioacuten) 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 congestioacuten de la transferencia de datagramas y de la multiplexacioacuten 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 maacutes importante El Flow Management se responsabiliza de manipular los flujos de datos desde y hasta la red viacutea la interfaz AAL La segmentacioacuten el reensamblado y el control de errores es tambieacuten 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 congestioacuten y de flujo extremo-extremo maacutes complejo

[7] describe la semaacutentica de una pila de protocolos y explora una nueva arquitectura de protocolo adaptada a la tecnologiacutea ATM y a las aplicaciones multimedia El disentildeo estaacute basado en tres principios baacutesicos separacioacuten de flujos de control y de datos minimizacioacuten del overhead y de la duplicidad de funciones y acceso de las aplicaciones al nivel ATM con garantiacuteas 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-over-ATM 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 moacutedulo CNTL abre una conexioacuten de sentildealizacioacuten con el dispositivo ATM y establece una gestioacuten de las llamadas de mensajes de configuracioacuten PF_ATM separa flujos de datos y de control para aliviar el liacutemite de comportamiento en las comunicaciones Esto permite a los mecanismos de control de traacutefico ser raacutepidos y sencillos mientras los mecanismos de control pueden ser tan complicados como sea necesario Esta separacioacuten permite tambieacuten que los dispositivos puedan estar en los puntos finales de una conexioacuten La interfaz PF_ATM da a las aplicaciones acceso directo a la capa de enlace ATM y extiende las garantiacuteas de QoS a los puntos extremos de la comunicacioacuten Un segundo prototipo[7] es disentildeado e implementado con dos objetivos principales en la optimizacioacuten de la pila nativa ATM

Optimizar los caminos de datos entre los adaptadores ATM aprovechando la separacioacuten de flujos de control y de datos y la capacidad de gestioacuten de datos especiacuteficos de las conexiones de la pila ATM

Optimizar el procesamiento de overheads usando una pila de protocolos nativo ATM en lugar de UDPIP

[11] introduce CONGRESS (CONnection oriented Group-address RESolution Service) otro eficiente protocolo nativo ATM para la resolucioacuten y gestioacuten 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 disentildeo basado en los dos siguientes principios

Disentildeo jeraacuterquico los servicios del protocolo son ofrecidos a las aplicaciones por muacuteltiples servidores organizados jeraacuterquicamente No inundacioacuten se evita la inundacioacuten 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 implementacioacuten sobre Unix y Windows NT estaacute 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 antildeadido un moacutedulo que monitoria la QoS extremo-a-extremo

3- Protocolos de transporte para redes ATMEn los dos o tres uacuteltimos antildeos ha habido numerosos e interesante intentos por disentildear protocolos de transporte La referencia [10] presenta un completo y ya claacutesico resumen de las propuestas maacutes interesantes en materia de protocolos de transporte para redes de alta velocidad (mayoritariamente IP en el artiacuteculo) Ademaacutes la referencia [13] ofrece una interesante visioacuten de las caracteriacutesticas maacutes importantes en los protocolos de elevada velocidad Son estudiadas tambieacuten diversas arquitecturas de protocolos y varias teacutecnicas de implementacioacuten Los protocolos de transporte de elevada velocidad son fuente de activas investigaciones y estaacuten en constante evolucioacuten desde hace maacutes de dos deacutecadas 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 aacutembito de las comunicaciones que ha recibido mayor atencioacuten es la capa de transporte la cuarta capa del OSI-RM de los protocolos de comunicaciones TCP e ISO TP4 son los dos maacutes populares protocolos de transporte Pero centraacutendonos maacutes concretamente en el aacutembito de ATM la literatura presenta varios protocolos de transporte y arquitecturas para redes de alta velocidad revisadas resumidamente a continuacioacuten [7] ofrece una excelente y didaacutectica arquitectura de pila de protocolos para aplicaciones multimedia en modo nativo ATM Esta arquitectura de protocolo ha sido ya descrita brevemente en la seccioacuten anterior [8] presentan el disentildeo implementacioacuten 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 estaacute formada por tres entidades principales aplicacioacuten sentildealizacioacuten y transporte La siguiente Tabla 1 muestra un conjunto de nueve baacutesicos 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 combinacioacuten de servicios La marca X indica el servicio baacutesico soportado en cada clase de servicio general

Clases de servicio

Servicios Servicio de comportamiento

garantizado

Servicio fiable Servicio Best effort

- Transferencia Simplex de datos

X X X

- Control de errores - deteccion de errorestimeouts retransmisiones

No existente (ofrecido por

AAL5)

- Bucle abierto - Control de flujo realimentado

No existente -

- X

- No existente

- Tamantildeo de mensaje ilimitado

X X X

- Eleccioacuten de blocking - Aplicacioacuten Non-blocking

X X

X X

X X

- Eleccioacuten de byte stream - Semaacutentica transferencia de mensajes

X X

X X

X X

- Garantiacuteas de QoS requerimientos de ancho de banda

No soportado No soportado

- Reserva de recursos X No existente No existente

- Transferencias Multicast X No soportado Para servicios no fiables

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 recuperacioacuten de peacuterdidas del protocolo estaacutendar SSCOP [14] y demuestran que el resultado ofrece baja latencia eficiente recuperacioacuten de ceacutelulas perdidas y es tan robusto como el estaacutendar SSCOP

4- Protocolos multipointEl crecimiento de las redes ATM viene motivado en parte por la demanda de servicios multimedia para grupos dispersos de usuarios El traacutefico multicast tiene caracteriacutesticas particulares descritas para ATM en UNI 40 [6] y anteriores [5] La distribucioacuten de informacioacuten punto-a-multipunto (uno-a-muchos) o multipunto-a-multipunto (muchos-a-muchos) es un objetivo baacutesico propuesto por varios protocolos y arquitecturas ATM que ofrecen el soporte multimedia yo multicast como audio-conferencia video-conferencia trabajos colaborativos o VoD ATM es auacuten una tecnologiacutea emergente disentildeada 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 30) para ATM define conexiones punto-a-multipunto y las conexiones multipunto-a-multipunto soacutelo 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 topologiacutea completamente mallada todos-con-todos Aunque esta topologiacutea ofrece conexiones multipunto-a-multipunto hay que destacar que no escala bien cuando el nuacutemero de participantes es elevado Una alternativa al anterior esquema es el uso de un servidor que actuacutea a modo de raiacutez en el aacuterbol multipunto Este meacutetodo soacutelo requiere un nodo raiacutez para almacenar informacioacuten pero la desventaja de este meacutetodo son las potenciales congestiones en el servidor

cuando debe encargarse de enviacuteos y retransmisiones de las conexiones multipunto-a-multipunto

Para solventar las limitaciones de UNI 30 y UNI 31 [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 sentildealizacioacuten ATM (UNI 31 UNI 40) [4][5][6] Comenzamos destacando la referencia [16] como un reciente trabajo que revisa y compara los protocolos de transporte multicast maacutes importantes en Internet como MTP-2 XTP RTP SRM RAMP RMTP MFTP STORM etc IETF e IRTF (como ITU-T y ATM Forum) tambieacuten impulsan una importante actividad en este campo La referencia [16] revisa los maacutes representativos protocolos multicast y los clasifica de acuerdo a la taxonomiacutea de varias caracteriacutesticas (propagacioacuten de datos mecanismos de fiabilidad retransmisiones control de congestioacuten y de flujo gestioacuten de grupos multicast etc) En Internet los mecanismos efectivos de control de congestioacuten son una de las prioridades en las investigaciones de las transferencias multicast fiables Los mecanismos de seguridad y las teacutecnicas escalables de recuperacioacuten 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 maacutes importantes caracteriacutesticas En esta seccioacuten 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 maacutes interesantes en los siguientes paacuterrafos SMART (shared many-to-many ATM reservations)[3] es un protocolo para controlar un aacuterbol ATM multicast compartido soportando comunicaciones muchos-a-muchos (many-to-many) Esta propuesta tiene importantes caracteriacutesticas como que reside completamente en la capa ATM y no requiere ninguacuten servidor soporta uno o varios VCCs (y tambieacuten VPCs) cuyo nuacutemero es libremente configurado y es independiente del nuacutemero de puntos finales usa el concepto de bloques de datos como en la clase de servicio ABT y tambieacuten permite VCCs de las clases CBR VBR o UBR el protocolo garantiza que no existen puntos de interrelacioacuten en los VCC del aacuterbol son respetadas las garantiacuteas del contrato de traacutefico asociado con los VCCs etc SMART puede ser entendido como un protocolo completamente distribuido para coordinar la distribucioacuten de VPIsVCIs 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 ceacutelulas de datos desde diferentes fuentes pueden llegar intercaladas a un destinatario) y tambieacuten Demand Sharing (los recursos asignados a conexiones muchos-a-muchos son dinaacutemicamente compartidas entre todas las potenciales fuentes El artiacuteculo [3] describe el protocolo SMART formal e informalmente y propone completas pruebas de correccioacuten y un detallado anaacutelisis de comportamiento para estudios futuros Tambieacuten son sugeridas otras investigaciones como son ofrecer justicia en los accesos a los aacuterboles multicast investigar las ceacutelulas RM perioacutedicamente para aliviar las congestiones en la red o disminuir el tiempo de acceso del usuario a los aacuterboles de distribucioacuten multicast anaacutelisis de las ceacutelulas RM dentro de cada VCC o fuera enviando todas las ceacutelulas RM en un VCC dedicado En [17] se presenta MWAX un algoritmo dinaacutemico 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 artiacuteculo describe un esquema jeraacuterquico basado en CBT para incorporar routing multipunto-a-multipunto en PNNI En el algoritmo los nodos core actuacutean como participantes pasivos para eliminar la dependencia en la seleccioacuten de estos nodos Con un mecanismo de backup se consigue un algoritmo tolerante a fallos en los nodos core lo cual puede ser faacutecilmente 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 jerarquiacutea SEAM (Scalable and Efficient ATM Multicast) [18] propone una arquitectura escalable eficiente y multicast multipunto-a-multipunto para redes ATM que usa un soacutelo VC para un grupo multicast de muacuteltiples 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 Tambieacuten realiza aportaciones para conseguir soportar IP multicast sobre redes ATM extensas

SEAM usa un soacutelo aacuterbol de distribucioacuten 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 sentildealizacioacuten del grupo Este trabajo deja abiertas investigaciones referentes a la gestioacuten de traacutefico y a la entrega fiable de traacuteficos multicasting Concluimos esta seccioacuten destacando MCMP (Multiparty Conference Management Protocol) [19] que sin estar pensado especiacuteficamente para ATM es un protocolo de nivel sesioacutentransporte distribuido extremo-extremo y desarrollado para gestioacuten de grupos de aplicaciones de conferencia MCMP es un conjunto de algoritmos de control distribuido para configuracioacuten de conferencias multipunto y gestioacuten de miembros de grupos de usuarios Conceptualmente MCMP reside en el nivel de sesioacuten en el que se establece la infraestructura para activar la transferencia de informacioacuten entre los participantes en la conferencia Pero funcionalmente el protocolo acompasa los niveles de sesioacuten y de transporte pues utiliza directamente servicios del nivel de red Son destacables las condiciones de correccioacuten (conectividad validacioacuten unicidad consistencia y terminacioacuten) que deben ser satisfechas una vez que la conferencia ha sido configurada por el algoritmo de configuracioacuten de MCMP El artiacuteculo muestra exhaustivas pruebas de correccioacuten para uno de los algoritmos y tambieacuten describe la especificacioacuten y verificacioacuten del protocolo

5- Nuevos campos de investigacioacutenEn todas las redes existen gran variedad de elementos hardware (switchs routers bridges brouters hubs ETDs etc) que realizan muy diversas funciones (conmutacioacuten routing puenteo controles de congestioacuten y de flujo garantiacutea de QoS ejecucioacuten de aplicaciones etc) En la actualidad la red es mayormente un canal de comunicacioacuten para transferir paquetes entre equipos finales (ayudada por los elementos hardware antes citados) Pero tambieacuten se estaacuten realizando importante esfuerzos para equipar a los elementos hardware con elevadas prestaciones aportadas por diversas teacutecnicas software Esto dota a la red de caracteriacutesticas activas (active networks) en el sentido de que los elementos hardware que la componen computan modifican u operan los contenidos de los paquetes y tambieacuten seraacuten capaces de transferir o propagar coacutedigo Por consiguiente una red activa es una red programable [20] es una excelente revisioacuten de este novedoso campo de investigacioacuten que discute dos planteamientos en la realizacioacuten de redes activas la idea del conmutador programable y la de la caacutepsula Una red es activa si en sus aacuterboles de distribucioacuten multicast existen nodos activos con capacidad para ejecutar programas yo capaces de implementar mecanismos de propagacioacuten de coacutedigo Algunas de las ventajas de los protocolos activos son conseguidas instalando nodos activos en puntos estrateacutegicos de la red Otro nuevo concepto es presentado en [21] como una metodologiacutea para el disentildeo de protocolos Los protocol boosters son una nueva contribucioacuten a las redes activas o programables Una ventaja de los boosters es que pueden ser faacutecilmente 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 aacuterea extensa Este papel introduce una arquitectura software orientada a agente y propone el concepto de agente de comunicacioacuten para servicio de comunicacioacuten 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 artiacuteculo muestra agentes software moacuteviles usados para implementar operaciones robustas y funciones de mantenimiento en redes ATM Los agentes desempentildean un rol similar al de las ceacutelulas OAM en ATM estaacutendar pues son transmitidos entre entidades de control a intervalos regulares usando recursos predefinidos La diferencia entre los agentes moacuteviles y las ceacutelulas OAM reside en que eacutestos pueden contener coacutedigo Para concluir destacar que la integracioacuten del traacutefico IP sobre tecnologiacutea ATM es tambieacuten uno de los campos maacutes activos en la actualidad En esta liacutenea pueden destacarse los siguientes protocolos IP-over-ATM IP Switching Tag Switching NHRP MPOA IMSS CSR ARIS AREQUIPARED y EPD Referencias

1 ____ Native ATM Service Semantic Description Version 1 ATM Forum Technical Committee ATM Forum Document af-saa-0048000 (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 Broadband Networks Multimedia Applications Services and Techniques ECMASTrsquo98 Springer (May 1998)

3 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 Nordm 3 (April 1997)

4 W D Zhong K Yukimatsu Design requeriments and architectures for multicast ATM switching IEICE Trans Com Vol E77-B pp 1420-1428 (Nov 1994)

5 ____ ATM user-network interface version 31 specification ATM Forum (1994)

6 ____ Traffic Management Specification Version 40 ATM Forum Technical Committee ATM Forum Document af-tm-0056000 (April 1996)

7 D Kandlur D Saha and W Willebeck Protocol Architecture for multimedia Application over ATM Networks IEEE Journal Selected and Communications Vol 14 Nordm 7 pp 1349-1359 (Sep 1996)

8 R Ahuja S Keshav and H Saran Design Implementation and Performance Measurement of a Native-Mode ATM Transport Layer (Estended Version) IEEEACM Transactions on Networking Vol 4 Nordm 4 (Aug 1996)

9 R Karabek A Native ATM Protocol Architecture Design and Performance Evaluation IEEE Proceedings 22nd Annual Conference on Local Computer Networks pp 204-210 (1997)

10 D C Feldmeier A framework of architectural concepts for high-speed communications systems IEEE J Select Areas CommunVol11 Nordm 4 (May 1993)

11 T Anker D Breitgand D Dolev Z Levy Congress CONnection-oriented Group-address RESolution Service Proceeding of SPIE97 vol 3233 on Broadband Networking Technologies Nov (1997)

12 kStack httpcometcolumbiaedusoftwarekStack

13 T La Porta and M Schwartz Architectures Features and Implementation of High-Speed Transport Protocols IEEE Network Magazine pp 14-22 (May 1991)

14 ____ B-ISDN ATM Adaptation Layer Service Specific Connection Oriented Protocol (SSCOP) Q2110 ITU-T (10-Mar 1994)

15 J Soleacute-Pareta J Vila-Sallent Network-based paralell computing over ATM using improved SSCOP protocol Computer Communications 19 pp 915-926 (1996)

16 K Obraczka Multicast Transport Protocols A survey and Taxonomy IEEE Communi Magazine (1998)

17 R Venkateswaran CS Raghavendra X Chen and VP Kumar A Scalable Dynamic Multicast Routing Algorithm in ATM Networks IEEE pp 1361-1365 (1997)

18 Matthias Grossglauser and KK Ramakrishnan SEAM Scalable and Efficient ATM Multicast IEEE 1997 pp 867-875 (1997)

19 M Nguyen and M Schwartz MCMP A Transportsession level Distributed Protocol for Desktop Conference Setup IEEE Journal Selected and comunications Vol 14 Nordm 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 Nordm 3 pp 437-443 (April 1998)

22 R Kishimoto Agent communication system for multimedia communication services INFOCOMrsquo96 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 Nordm 3 pp 414-423 (April 1998)

  • ATM - Modo de Transferencia Asiacutencrona
  • Revisioacuten y Clasificacioacuten de Protocolos para Redes de Tecnologiacutea ATM
    • Resumen
    • 1-Introduccioacuten y motivaciones
    • 2- Protocolos nativos ATM
    • 3- Protocolos de transporte para redes ATM
    • 4- Protocolos multipoint
    • 5- Nuevos campos de investigacioacuten
      • Referencias
Page 14: Atm

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] Ademaacutes 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 tecnologiacutea ATM y tambieacuten existen antiguas y no nativas aplicaciones Este escenario implica cambiar las aplicaciones o proponer nuevas pilas de protocolos nativos ATM La encapsulacioacuten consecutiva de paquetes genera problemas de overhead y funciones redundantes como se ha argumentado anteriormente La limitacioacuten de recursos en los sistemas finales es otra importante motivacioacuten 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 puacuteblicos disfrutan tambieacuten de estas ventajas ATM RDSI y la telefoniacutea ofrecen un esquema de direccionamiento universal basado en NSAPE164 el cual es capaz de enrutar traacutefico de forma nativa Por tanto aunque ATM dispone de protocolos nativos con direccionamiento intriacutenceso estructurado y jeraacuterquico eacuteste no es aprovechado por las aplicaciones que estaacuten 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 tambieacuten existen importantes investigaciones en torno a los protocolos nativos ATM En esta seccioacuten se muestran las propuestas maacutes importantes y actuales en materia de protocolos nativos ATM[2] [7] [8] [9] [10] [11] [12] que a su vezestaacuten sirviendo de base para nuevas investigaciones

[8] presentan el disentildeo implementacioacuten y comportamiento de una pila en modo nativo ATM y contrasta la semaacutentica 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 automaacuteticamente los siguientes problemas

IP-over-ATM no ofrece garantiacutea de QoS pues sus aplicaciones soacutelo ven la interfaz IP El nuacutecleo 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 sentildealizacioacuten 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 caracteriacutesticas la entrega fiable y no fiable de datos con control de flujo Este protocolo de transporte es ampliado en la seccioacuten 5 [2] presenta N3 (Native Non-broadcasting medium access Networking) un protocolo de transporte ligero y nativo ATM La pila N3 se ha disentildeado 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 ademaacutes aporta otras importantes novedades Los principales componentes de N3 incluyen una API sockets ATM nativa un protocolo de transporte ATM y un servicio de nombres ATM (Fig2) El protocolo de transporte ATM propuesto en [2] ofrece soporte para tres diferentes tipos de servicio entrega garantizada (mecanismos de retransmisioacuten) 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 congestioacuten de la transferencia de datagramas y de la multiplexacioacuten 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 maacutes importante El Flow Management se responsabiliza de manipular los flujos de datos desde y hasta la red viacutea la interfaz AAL La segmentacioacuten el reensamblado y el control de errores es tambieacuten 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 congestioacuten y de flujo extremo-extremo maacutes complejo

[7] describe la semaacutentica de una pila de protocolos y explora una nueva arquitectura de protocolo adaptada a la tecnologiacutea ATM y a las aplicaciones multimedia El disentildeo estaacute basado en tres principios baacutesicos separacioacuten de flujos de control y de datos minimizacioacuten del overhead y de la duplicidad de funciones y acceso de las aplicaciones al nivel ATM con garantiacuteas 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-over-ATM 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 moacutedulo CNTL abre una conexioacuten de sentildealizacioacuten con el dispositivo ATM y establece una gestioacuten de las llamadas de mensajes de configuracioacuten PF_ATM separa flujos de datos y de control para aliviar el liacutemite de comportamiento en las comunicaciones Esto permite a los mecanismos de control de traacutefico ser raacutepidos y sencillos mientras los mecanismos de control pueden ser tan complicados como sea necesario Esta separacioacuten permite tambieacuten que los dispositivos puedan estar en los puntos finales de una conexioacuten La interfaz PF_ATM da a las aplicaciones acceso directo a la capa de enlace ATM y extiende las garantiacuteas de QoS a los puntos extremos de la comunicacioacuten Un segundo prototipo[7] es disentildeado e implementado con dos objetivos principales en la optimizacioacuten de la pila nativa ATM

Optimizar los caminos de datos entre los adaptadores ATM aprovechando la separacioacuten de flujos de control y de datos y la capacidad de gestioacuten de datos especiacuteficos de las conexiones de la pila ATM

Optimizar el procesamiento de overheads usando una pila de protocolos nativo ATM en lugar de UDPIP

[11] introduce CONGRESS (CONnection oriented Group-address RESolution Service) otro eficiente protocolo nativo ATM para la resolucioacuten y gestioacuten 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 disentildeo basado en los dos siguientes principios

Disentildeo jeraacuterquico los servicios del protocolo son ofrecidos a las aplicaciones por muacuteltiples servidores organizados jeraacuterquicamente No inundacioacuten se evita la inundacioacuten 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 implementacioacuten sobre Unix y Windows NT estaacute 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 antildeadido un moacutedulo que monitoria la QoS extremo-a-extremo

3- Protocolos de transporte para redes ATMEn los dos o tres uacuteltimos antildeos ha habido numerosos e interesante intentos por disentildear protocolos de transporte La referencia [10] presenta un completo y ya claacutesico resumen de las propuestas maacutes interesantes en materia de protocolos de transporte para redes de alta velocidad (mayoritariamente IP en el artiacuteculo) Ademaacutes la referencia [13] ofrece una interesante visioacuten de las caracteriacutesticas maacutes importantes en los protocolos de elevada velocidad Son estudiadas tambieacuten diversas arquitecturas de protocolos y varias teacutecnicas de implementacioacuten Los protocolos de transporte de elevada velocidad son fuente de activas investigaciones y estaacuten en constante evolucioacuten desde hace maacutes de dos deacutecadas 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 aacutembito de las comunicaciones que ha recibido mayor atencioacuten es la capa de transporte la cuarta capa del OSI-RM de los protocolos de comunicaciones TCP e ISO TP4 son los dos maacutes populares protocolos de transporte Pero centraacutendonos maacutes concretamente en el aacutembito de ATM la literatura presenta varios protocolos de transporte y arquitecturas para redes de alta velocidad revisadas resumidamente a continuacioacuten [7] ofrece una excelente y didaacutectica arquitectura de pila de protocolos para aplicaciones multimedia en modo nativo ATM Esta arquitectura de protocolo ha sido ya descrita brevemente en la seccioacuten anterior [8] presentan el disentildeo implementacioacuten 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 estaacute formada por tres entidades principales aplicacioacuten sentildealizacioacuten y transporte La siguiente Tabla 1 muestra un conjunto de nueve baacutesicos 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 combinacioacuten de servicios La marca X indica el servicio baacutesico soportado en cada clase de servicio general

Clases de servicio

Servicios Servicio de comportamiento

garantizado

Servicio fiable Servicio Best effort

- Transferencia Simplex de datos

X X X

- Control de errores - deteccion de errorestimeouts retransmisiones

No existente (ofrecido por

AAL5)

- Bucle abierto - Control de flujo realimentado

No existente -

- X

- No existente

- Tamantildeo de mensaje ilimitado

X X X

- Eleccioacuten de blocking - Aplicacioacuten Non-blocking

X X

X X

X X

- Eleccioacuten de byte stream - Semaacutentica transferencia de mensajes

X X

X X

X X

- Garantiacuteas de QoS requerimientos de ancho de banda

No soportado No soportado

- Reserva de recursos X No existente No existente

- Transferencias Multicast X No soportado Para servicios no fiables

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 recuperacioacuten de peacuterdidas del protocolo estaacutendar SSCOP [14] y demuestran que el resultado ofrece baja latencia eficiente recuperacioacuten de ceacutelulas perdidas y es tan robusto como el estaacutendar SSCOP

4- Protocolos multipointEl crecimiento de las redes ATM viene motivado en parte por la demanda de servicios multimedia para grupos dispersos de usuarios El traacutefico multicast tiene caracteriacutesticas particulares descritas para ATM en UNI 40 [6] y anteriores [5] La distribucioacuten de informacioacuten punto-a-multipunto (uno-a-muchos) o multipunto-a-multipunto (muchos-a-muchos) es un objetivo baacutesico propuesto por varios protocolos y arquitecturas ATM que ofrecen el soporte multimedia yo multicast como audio-conferencia video-conferencia trabajos colaborativos o VoD ATM es auacuten una tecnologiacutea emergente disentildeada 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 30) para ATM define conexiones punto-a-multipunto y las conexiones multipunto-a-multipunto soacutelo 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 topologiacutea completamente mallada todos-con-todos Aunque esta topologiacutea ofrece conexiones multipunto-a-multipunto hay que destacar que no escala bien cuando el nuacutemero de participantes es elevado Una alternativa al anterior esquema es el uso de un servidor que actuacutea a modo de raiacutez en el aacuterbol multipunto Este meacutetodo soacutelo requiere un nodo raiacutez para almacenar informacioacuten pero la desventaja de este meacutetodo son las potenciales congestiones en el servidor

cuando debe encargarse de enviacuteos y retransmisiones de las conexiones multipunto-a-multipunto

Para solventar las limitaciones de UNI 30 y UNI 31 [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 sentildealizacioacuten ATM (UNI 31 UNI 40) [4][5][6] Comenzamos destacando la referencia [16] como un reciente trabajo que revisa y compara los protocolos de transporte multicast maacutes importantes en Internet como MTP-2 XTP RTP SRM RAMP RMTP MFTP STORM etc IETF e IRTF (como ITU-T y ATM Forum) tambieacuten impulsan una importante actividad en este campo La referencia [16] revisa los maacutes representativos protocolos multicast y los clasifica de acuerdo a la taxonomiacutea de varias caracteriacutesticas (propagacioacuten de datos mecanismos de fiabilidad retransmisiones control de congestioacuten y de flujo gestioacuten de grupos multicast etc) En Internet los mecanismos efectivos de control de congestioacuten son una de las prioridades en las investigaciones de las transferencias multicast fiables Los mecanismos de seguridad y las teacutecnicas escalables de recuperacioacuten 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 maacutes importantes caracteriacutesticas En esta seccioacuten 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 maacutes interesantes en los siguientes paacuterrafos SMART (shared many-to-many ATM reservations)[3] es un protocolo para controlar un aacuterbol ATM multicast compartido soportando comunicaciones muchos-a-muchos (many-to-many) Esta propuesta tiene importantes caracteriacutesticas como que reside completamente en la capa ATM y no requiere ninguacuten servidor soporta uno o varios VCCs (y tambieacuten VPCs) cuyo nuacutemero es libremente configurado y es independiente del nuacutemero de puntos finales usa el concepto de bloques de datos como en la clase de servicio ABT y tambieacuten permite VCCs de las clases CBR VBR o UBR el protocolo garantiza que no existen puntos de interrelacioacuten en los VCC del aacuterbol son respetadas las garantiacuteas del contrato de traacutefico asociado con los VCCs etc SMART puede ser entendido como un protocolo completamente distribuido para coordinar la distribucioacuten de VPIsVCIs 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 ceacutelulas de datos desde diferentes fuentes pueden llegar intercaladas a un destinatario) y tambieacuten Demand Sharing (los recursos asignados a conexiones muchos-a-muchos son dinaacutemicamente compartidas entre todas las potenciales fuentes El artiacuteculo [3] describe el protocolo SMART formal e informalmente y propone completas pruebas de correccioacuten y un detallado anaacutelisis de comportamiento para estudios futuros Tambieacuten son sugeridas otras investigaciones como son ofrecer justicia en los accesos a los aacuterboles multicast investigar las ceacutelulas RM perioacutedicamente para aliviar las congestiones en la red o disminuir el tiempo de acceso del usuario a los aacuterboles de distribucioacuten multicast anaacutelisis de las ceacutelulas RM dentro de cada VCC o fuera enviando todas las ceacutelulas RM en un VCC dedicado En [17] se presenta MWAX un algoritmo dinaacutemico 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 artiacuteculo describe un esquema jeraacuterquico basado en CBT para incorporar routing multipunto-a-multipunto en PNNI En el algoritmo los nodos core actuacutean como participantes pasivos para eliminar la dependencia en la seleccioacuten de estos nodos Con un mecanismo de backup se consigue un algoritmo tolerante a fallos en los nodos core lo cual puede ser faacutecilmente 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 jerarquiacutea SEAM (Scalable and Efficient ATM Multicast) [18] propone una arquitectura escalable eficiente y multicast multipunto-a-multipunto para redes ATM que usa un soacutelo VC para un grupo multicast de muacuteltiples 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 Tambieacuten realiza aportaciones para conseguir soportar IP multicast sobre redes ATM extensas

SEAM usa un soacutelo aacuterbol de distribucioacuten 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 sentildealizacioacuten del grupo Este trabajo deja abiertas investigaciones referentes a la gestioacuten de traacutefico y a la entrega fiable de traacuteficos multicasting Concluimos esta seccioacuten destacando MCMP (Multiparty Conference Management Protocol) [19] que sin estar pensado especiacuteficamente para ATM es un protocolo de nivel sesioacutentransporte distribuido extremo-extremo y desarrollado para gestioacuten de grupos de aplicaciones de conferencia MCMP es un conjunto de algoritmos de control distribuido para configuracioacuten de conferencias multipunto y gestioacuten de miembros de grupos de usuarios Conceptualmente MCMP reside en el nivel de sesioacuten en el que se establece la infraestructura para activar la transferencia de informacioacuten entre los participantes en la conferencia Pero funcionalmente el protocolo acompasa los niveles de sesioacuten y de transporte pues utiliza directamente servicios del nivel de red Son destacables las condiciones de correccioacuten (conectividad validacioacuten unicidad consistencia y terminacioacuten) que deben ser satisfechas una vez que la conferencia ha sido configurada por el algoritmo de configuracioacuten de MCMP El artiacuteculo muestra exhaustivas pruebas de correccioacuten para uno de los algoritmos y tambieacuten describe la especificacioacuten y verificacioacuten del protocolo

5- Nuevos campos de investigacioacutenEn todas las redes existen gran variedad de elementos hardware (switchs routers bridges brouters hubs ETDs etc) que realizan muy diversas funciones (conmutacioacuten routing puenteo controles de congestioacuten y de flujo garantiacutea de QoS ejecucioacuten de aplicaciones etc) En la actualidad la red es mayormente un canal de comunicacioacuten para transferir paquetes entre equipos finales (ayudada por los elementos hardware antes citados) Pero tambieacuten se estaacuten realizando importante esfuerzos para equipar a los elementos hardware con elevadas prestaciones aportadas por diversas teacutecnicas software Esto dota a la red de caracteriacutesticas activas (active networks) en el sentido de que los elementos hardware que la componen computan modifican u operan los contenidos de los paquetes y tambieacuten seraacuten capaces de transferir o propagar coacutedigo Por consiguiente una red activa es una red programable [20] es una excelente revisioacuten de este novedoso campo de investigacioacuten que discute dos planteamientos en la realizacioacuten de redes activas la idea del conmutador programable y la de la caacutepsula Una red es activa si en sus aacuterboles de distribucioacuten multicast existen nodos activos con capacidad para ejecutar programas yo capaces de implementar mecanismos de propagacioacuten de coacutedigo Algunas de las ventajas de los protocolos activos son conseguidas instalando nodos activos en puntos estrateacutegicos de la red Otro nuevo concepto es presentado en [21] como una metodologiacutea para el disentildeo de protocolos Los protocol boosters son una nueva contribucioacuten a las redes activas o programables Una ventaja de los boosters es que pueden ser faacutecilmente 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 aacuterea extensa Este papel introduce una arquitectura software orientada a agente y propone el concepto de agente de comunicacioacuten para servicio de comunicacioacuten 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 artiacuteculo muestra agentes software moacuteviles usados para implementar operaciones robustas y funciones de mantenimiento en redes ATM Los agentes desempentildean un rol similar al de las ceacutelulas OAM en ATM estaacutendar pues son transmitidos entre entidades de control a intervalos regulares usando recursos predefinidos La diferencia entre los agentes moacuteviles y las ceacutelulas OAM reside en que eacutestos pueden contener coacutedigo Para concluir destacar que la integracioacuten del traacutefico IP sobre tecnologiacutea ATM es tambieacuten uno de los campos maacutes activos en la actualidad En esta liacutenea pueden destacarse los siguientes protocolos IP-over-ATM IP Switching Tag Switching NHRP MPOA IMSS CSR ARIS AREQUIPARED y EPD Referencias

1 ____ Native ATM Service Semantic Description Version 1 ATM Forum Technical Committee ATM Forum Document af-saa-0048000 (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 Broadband Networks Multimedia Applications Services and Techniques ECMASTrsquo98 Springer (May 1998)

3 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 Nordm 3 (April 1997)

4 W D Zhong K Yukimatsu Design requeriments and architectures for multicast ATM switching IEICE Trans Com Vol E77-B pp 1420-1428 (Nov 1994)

5 ____ ATM user-network interface version 31 specification ATM Forum (1994)

6 ____ Traffic Management Specification Version 40 ATM Forum Technical Committee ATM Forum Document af-tm-0056000 (April 1996)

7 D Kandlur D Saha and W Willebeck Protocol Architecture for multimedia Application over ATM Networks IEEE Journal Selected and Communications Vol 14 Nordm 7 pp 1349-1359 (Sep 1996)

8 R Ahuja S Keshav and H Saran Design Implementation and Performance Measurement of a Native-Mode ATM Transport Layer (Estended Version) IEEEACM Transactions on Networking Vol 4 Nordm 4 (Aug 1996)

9 R Karabek A Native ATM Protocol Architecture Design and Performance Evaluation IEEE Proceedings 22nd Annual Conference on Local Computer Networks pp 204-210 (1997)

10 D C Feldmeier A framework of architectural concepts for high-speed communications systems IEEE J Select Areas CommunVol11 Nordm 4 (May 1993)

11 T Anker D Breitgand D Dolev Z Levy Congress CONnection-oriented Group-address RESolution Service Proceeding of SPIE97 vol 3233 on Broadband Networking Technologies Nov (1997)

12 kStack httpcometcolumbiaedusoftwarekStack

13 T La Porta and M Schwartz Architectures Features and Implementation of High-Speed Transport Protocols IEEE Network Magazine pp 14-22 (May 1991)

14 ____ B-ISDN ATM Adaptation Layer Service Specific Connection Oriented Protocol (SSCOP) Q2110 ITU-T (10-Mar 1994)

15 J Soleacute-Pareta J Vila-Sallent Network-based paralell computing over ATM using improved SSCOP protocol Computer Communications 19 pp 915-926 (1996)

16 K Obraczka Multicast Transport Protocols A survey and Taxonomy IEEE Communi Magazine (1998)

17 R Venkateswaran CS Raghavendra X Chen and VP Kumar A Scalable Dynamic Multicast Routing Algorithm in ATM Networks IEEE pp 1361-1365 (1997)

18 Matthias Grossglauser and KK Ramakrishnan SEAM Scalable and Efficient ATM Multicast IEEE 1997 pp 867-875 (1997)

19 M Nguyen and M Schwartz MCMP A Transportsession level Distributed Protocol for Desktop Conference Setup IEEE Journal Selected and comunications Vol 14 Nordm 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 Nordm 3 pp 437-443 (April 1998)

22 R Kishimoto Agent communication system for multimedia communication services INFOCOMrsquo96 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 Nordm 3 pp 414-423 (April 1998)

  • ATM - Modo de Transferencia Asiacutencrona
  • Revisioacuten y Clasificacioacuten de Protocolos para Redes de Tecnologiacutea ATM
    • Resumen
    • 1-Introduccioacuten y motivaciones
    • 2- Protocolos nativos ATM
    • 3- Protocolos de transporte para redes ATM
    • 4- Protocolos multipoint
    • 5- Nuevos campos de investigacioacuten
      • Referencias
Page 15: Atm

[8] presentan el disentildeo implementacioacuten y comportamiento de una pila en modo nativo ATM y contrasta la semaacutentica 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 automaacuteticamente los siguientes problemas

IP-over-ATM no ofrece garantiacutea de QoS pues sus aplicaciones soacutelo ven la interfaz IP El nuacutecleo 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 sentildealizacioacuten 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 caracteriacutesticas la entrega fiable y no fiable de datos con control de flujo Este protocolo de transporte es ampliado en la seccioacuten 5 [2] presenta N3 (Native Non-broadcasting medium access Networking) un protocolo de transporte ligero y nativo ATM La pila N3 se ha disentildeado 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 ademaacutes aporta otras importantes novedades Los principales componentes de N3 incluyen una API sockets ATM nativa un protocolo de transporte ATM y un servicio de nombres ATM (Fig2) El protocolo de transporte ATM propuesto en [2] ofrece soporte para tres diferentes tipos de servicio entrega garantizada (mecanismos de retransmisioacuten) 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 congestioacuten de la transferencia de datagramas y de la multiplexacioacuten 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 maacutes importante El Flow Management se responsabiliza de manipular los flujos de datos desde y hasta la red viacutea la interfaz AAL La segmentacioacuten el reensamblado y el control de errores es tambieacuten 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 congestioacuten y de flujo extremo-extremo maacutes complejo

[7] describe la semaacutentica de una pila de protocolos y explora una nueva arquitectura de protocolo adaptada a la tecnologiacutea ATM y a las aplicaciones multimedia El disentildeo estaacute basado en tres principios baacutesicos separacioacuten de flujos de control y de datos minimizacioacuten del overhead y de la duplicidad de funciones y acceso de las aplicaciones al nivel ATM con garantiacuteas 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-over-ATM 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 moacutedulo CNTL abre una conexioacuten de sentildealizacioacuten con el dispositivo ATM y establece una gestioacuten de las llamadas de mensajes de configuracioacuten PF_ATM separa flujos de datos y de control para aliviar el liacutemite de comportamiento en las comunicaciones Esto permite a los mecanismos de control de traacutefico ser raacutepidos y sencillos mientras los mecanismos de control pueden ser tan complicados como sea necesario Esta separacioacuten permite tambieacuten que los dispositivos puedan estar en los puntos finales de una conexioacuten La interfaz PF_ATM da a las aplicaciones acceso directo a la capa de enlace ATM y extiende las garantiacuteas de QoS a los puntos extremos de la comunicacioacuten Un segundo prototipo[7] es disentildeado e implementado con dos objetivos principales en la optimizacioacuten de la pila nativa ATM

Optimizar los caminos de datos entre los adaptadores ATM aprovechando la separacioacuten de flujos de control y de datos y la capacidad de gestioacuten de datos especiacuteficos de las conexiones de la pila ATM

Optimizar el procesamiento de overheads usando una pila de protocolos nativo ATM en lugar de UDPIP

[11] introduce CONGRESS (CONnection oriented Group-address RESolution Service) otro eficiente protocolo nativo ATM para la resolucioacuten y gestioacuten 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 disentildeo basado en los dos siguientes principios

Disentildeo jeraacuterquico los servicios del protocolo son ofrecidos a las aplicaciones por muacuteltiples servidores organizados jeraacuterquicamente No inundacioacuten se evita la inundacioacuten 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 implementacioacuten sobre Unix y Windows NT estaacute 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 antildeadido un moacutedulo que monitoria la QoS extremo-a-extremo

3- Protocolos de transporte para redes ATMEn los dos o tres uacuteltimos antildeos ha habido numerosos e interesante intentos por disentildear protocolos de transporte La referencia [10] presenta un completo y ya claacutesico resumen de las propuestas maacutes interesantes en materia de protocolos de transporte para redes de alta velocidad (mayoritariamente IP en el artiacuteculo) Ademaacutes la referencia [13] ofrece una interesante visioacuten de las caracteriacutesticas maacutes importantes en los protocolos de elevada velocidad Son estudiadas tambieacuten diversas arquitecturas de protocolos y varias teacutecnicas de implementacioacuten Los protocolos de transporte de elevada velocidad son fuente de activas investigaciones y estaacuten en constante evolucioacuten desde hace maacutes de dos deacutecadas 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 aacutembito de las comunicaciones que ha recibido mayor atencioacuten es la capa de transporte la cuarta capa del OSI-RM de los protocolos de comunicaciones TCP e ISO TP4 son los dos maacutes populares protocolos de transporte Pero centraacutendonos maacutes concretamente en el aacutembito de ATM la literatura presenta varios protocolos de transporte y arquitecturas para redes de alta velocidad revisadas resumidamente a continuacioacuten [7] ofrece una excelente y didaacutectica arquitectura de pila de protocolos para aplicaciones multimedia en modo nativo ATM Esta arquitectura de protocolo ha sido ya descrita brevemente en la seccioacuten anterior [8] presentan el disentildeo implementacioacuten 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 estaacute formada por tres entidades principales aplicacioacuten sentildealizacioacuten y transporte La siguiente Tabla 1 muestra un conjunto de nueve baacutesicos 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 combinacioacuten de servicios La marca X indica el servicio baacutesico soportado en cada clase de servicio general

Clases de servicio

Servicios Servicio de comportamiento

garantizado

Servicio fiable Servicio Best effort

- Transferencia Simplex de datos

X X X

- Control de errores - deteccion de errorestimeouts retransmisiones

No existente (ofrecido por

AAL5)

- Bucle abierto - Control de flujo realimentado

No existente -

- X

- No existente

- Tamantildeo de mensaje ilimitado

X X X

- Eleccioacuten de blocking - Aplicacioacuten Non-blocking

X X

X X

X X

- Eleccioacuten de byte stream - Semaacutentica transferencia de mensajes

X X

X X

X X

- Garantiacuteas de QoS requerimientos de ancho de banda

No soportado No soportado

- Reserva de recursos X No existente No existente

- Transferencias Multicast X No soportado Para servicios no fiables

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 recuperacioacuten de peacuterdidas del protocolo estaacutendar SSCOP [14] y demuestran que el resultado ofrece baja latencia eficiente recuperacioacuten de ceacutelulas perdidas y es tan robusto como el estaacutendar SSCOP

4- Protocolos multipointEl crecimiento de las redes ATM viene motivado en parte por la demanda de servicios multimedia para grupos dispersos de usuarios El traacutefico multicast tiene caracteriacutesticas particulares descritas para ATM en UNI 40 [6] y anteriores [5] La distribucioacuten de informacioacuten punto-a-multipunto (uno-a-muchos) o multipunto-a-multipunto (muchos-a-muchos) es un objetivo baacutesico propuesto por varios protocolos y arquitecturas ATM que ofrecen el soporte multimedia yo multicast como audio-conferencia video-conferencia trabajos colaborativos o VoD ATM es auacuten una tecnologiacutea emergente disentildeada 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 30) para ATM define conexiones punto-a-multipunto y las conexiones multipunto-a-multipunto soacutelo 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 topologiacutea completamente mallada todos-con-todos Aunque esta topologiacutea ofrece conexiones multipunto-a-multipunto hay que destacar que no escala bien cuando el nuacutemero de participantes es elevado Una alternativa al anterior esquema es el uso de un servidor que actuacutea a modo de raiacutez en el aacuterbol multipunto Este meacutetodo soacutelo requiere un nodo raiacutez para almacenar informacioacuten pero la desventaja de este meacutetodo son las potenciales congestiones en el servidor

cuando debe encargarse de enviacuteos y retransmisiones de las conexiones multipunto-a-multipunto

Para solventar las limitaciones de UNI 30 y UNI 31 [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 sentildealizacioacuten ATM (UNI 31 UNI 40) [4][5][6] Comenzamos destacando la referencia [16] como un reciente trabajo que revisa y compara los protocolos de transporte multicast maacutes importantes en Internet como MTP-2 XTP RTP SRM RAMP RMTP MFTP STORM etc IETF e IRTF (como ITU-T y ATM Forum) tambieacuten impulsan una importante actividad en este campo La referencia [16] revisa los maacutes representativos protocolos multicast y los clasifica de acuerdo a la taxonomiacutea de varias caracteriacutesticas (propagacioacuten de datos mecanismos de fiabilidad retransmisiones control de congestioacuten y de flujo gestioacuten de grupos multicast etc) En Internet los mecanismos efectivos de control de congestioacuten son una de las prioridades en las investigaciones de las transferencias multicast fiables Los mecanismos de seguridad y las teacutecnicas escalables de recuperacioacuten 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 maacutes importantes caracteriacutesticas En esta seccioacuten 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 maacutes interesantes en los siguientes paacuterrafos SMART (shared many-to-many ATM reservations)[3] es un protocolo para controlar un aacuterbol ATM multicast compartido soportando comunicaciones muchos-a-muchos (many-to-many) Esta propuesta tiene importantes caracteriacutesticas como que reside completamente en la capa ATM y no requiere ninguacuten servidor soporta uno o varios VCCs (y tambieacuten VPCs) cuyo nuacutemero es libremente configurado y es independiente del nuacutemero de puntos finales usa el concepto de bloques de datos como en la clase de servicio ABT y tambieacuten permite VCCs de las clases CBR VBR o UBR el protocolo garantiza que no existen puntos de interrelacioacuten en los VCC del aacuterbol son respetadas las garantiacuteas del contrato de traacutefico asociado con los VCCs etc SMART puede ser entendido como un protocolo completamente distribuido para coordinar la distribucioacuten de VPIsVCIs 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 ceacutelulas de datos desde diferentes fuentes pueden llegar intercaladas a un destinatario) y tambieacuten Demand Sharing (los recursos asignados a conexiones muchos-a-muchos son dinaacutemicamente compartidas entre todas las potenciales fuentes El artiacuteculo [3] describe el protocolo SMART formal e informalmente y propone completas pruebas de correccioacuten y un detallado anaacutelisis de comportamiento para estudios futuros Tambieacuten son sugeridas otras investigaciones como son ofrecer justicia en los accesos a los aacuterboles multicast investigar las ceacutelulas RM perioacutedicamente para aliviar las congestiones en la red o disminuir el tiempo de acceso del usuario a los aacuterboles de distribucioacuten multicast anaacutelisis de las ceacutelulas RM dentro de cada VCC o fuera enviando todas las ceacutelulas RM en un VCC dedicado En [17] se presenta MWAX un algoritmo dinaacutemico 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 artiacuteculo describe un esquema jeraacuterquico basado en CBT para incorporar routing multipunto-a-multipunto en PNNI En el algoritmo los nodos core actuacutean como participantes pasivos para eliminar la dependencia en la seleccioacuten de estos nodos Con un mecanismo de backup se consigue un algoritmo tolerante a fallos en los nodos core lo cual puede ser faacutecilmente 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 jerarquiacutea SEAM (Scalable and Efficient ATM Multicast) [18] propone una arquitectura escalable eficiente y multicast multipunto-a-multipunto para redes ATM que usa un soacutelo VC para un grupo multicast de muacuteltiples 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 Tambieacuten realiza aportaciones para conseguir soportar IP multicast sobre redes ATM extensas

SEAM usa un soacutelo aacuterbol de distribucioacuten 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 sentildealizacioacuten del grupo Este trabajo deja abiertas investigaciones referentes a la gestioacuten de traacutefico y a la entrega fiable de traacuteficos multicasting Concluimos esta seccioacuten destacando MCMP (Multiparty Conference Management Protocol) [19] que sin estar pensado especiacuteficamente para ATM es un protocolo de nivel sesioacutentransporte distribuido extremo-extremo y desarrollado para gestioacuten de grupos de aplicaciones de conferencia MCMP es un conjunto de algoritmos de control distribuido para configuracioacuten de conferencias multipunto y gestioacuten de miembros de grupos de usuarios Conceptualmente MCMP reside en el nivel de sesioacuten en el que se establece la infraestructura para activar la transferencia de informacioacuten entre los participantes en la conferencia Pero funcionalmente el protocolo acompasa los niveles de sesioacuten y de transporte pues utiliza directamente servicios del nivel de red Son destacables las condiciones de correccioacuten (conectividad validacioacuten unicidad consistencia y terminacioacuten) que deben ser satisfechas una vez que la conferencia ha sido configurada por el algoritmo de configuracioacuten de MCMP El artiacuteculo muestra exhaustivas pruebas de correccioacuten para uno de los algoritmos y tambieacuten describe la especificacioacuten y verificacioacuten del protocolo

5- Nuevos campos de investigacioacutenEn todas las redes existen gran variedad de elementos hardware (switchs routers bridges brouters hubs ETDs etc) que realizan muy diversas funciones (conmutacioacuten routing puenteo controles de congestioacuten y de flujo garantiacutea de QoS ejecucioacuten de aplicaciones etc) En la actualidad la red es mayormente un canal de comunicacioacuten para transferir paquetes entre equipos finales (ayudada por los elementos hardware antes citados) Pero tambieacuten se estaacuten realizando importante esfuerzos para equipar a los elementos hardware con elevadas prestaciones aportadas por diversas teacutecnicas software Esto dota a la red de caracteriacutesticas activas (active networks) en el sentido de que los elementos hardware que la componen computan modifican u operan los contenidos de los paquetes y tambieacuten seraacuten capaces de transferir o propagar coacutedigo Por consiguiente una red activa es una red programable [20] es una excelente revisioacuten de este novedoso campo de investigacioacuten que discute dos planteamientos en la realizacioacuten de redes activas la idea del conmutador programable y la de la caacutepsula Una red es activa si en sus aacuterboles de distribucioacuten multicast existen nodos activos con capacidad para ejecutar programas yo capaces de implementar mecanismos de propagacioacuten de coacutedigo Algunas de las ventajas de los protocolos activos son conseguidas instalando nodos activos en puntos estrateacutegicos de la red Otro nuevo concepto es presentado en [21] como una metodologiacutea para el disentildeo de protocolos Los protocol boosters son una nueva contribucioacuten a las redes activas o programables Una ventaja de los boosters es que pueden ser faacutecilmente 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 aacuterea extensa Este papel introduce una arquitectura software orientada a agente y propone el concepto de agente de comunicacioacuten para servicio de comunicacioacuten 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 artiacuteculo muestra agentes software moacuteviles usados para implementar operaciones robustas y funciones de mantenimiento en redes ATM Los agentes desempentildean un rol similar al de las ceacutelulas OAM en ATM estaacutendar pues son transmitidos entre entidades de control a intervalos regulares usando recursos predefinidos La diferencia entre los agentes moacuteviles y las ceacutelulas OAM reside en que eacutestos pueden contener coacutedigo Para concluir destacar que la integracioacuten del traacutefico IP sobre tecnologiacutea ATM es tambieacuten uno de los campos maacutes activos en la actualidad En esta liacutenea pueden destacarse los siguientes protocolos IP-over-ATM IP Switching Tag Switching NHRP MPOA IMSS CSR ARIS AREQUIPARED y EPD Referencias

1 ____ Native ATM Service Semantic Description Version 1 ATM Forum Technical Committee ATM Forum Document af-saa-0048000 (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 Broadband Networks Multimedia Applications Services and Techniques ECMASTrsquo98 Springer (May 1998)

3 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 Nordm 3 (April 1997)

4 W D Zhong K Yukimatsu Design requeriments and architectures for multicast ATM switching IEICE Trans Com Vol E77-B pp 1420-1428 (Nov 1994)

5 ____ ATM user-network interface version 31 specification ATM Forum (1994)

6 ____ Traffic Management Specification Version 40 ATM Forum Technical Committee ATM Forum Document af-tm-0056000 (April 1996)

7 D Kandlur D Saha and W Willebeck Protocol Architecture for multimedia Application over ATM Networks IEEE Journal Selected and Communications Vol 14 Nordm 7 pp 1349-1359 (Sep 1996)

8 R Ahuja S Keshav and H Saran Design Implementation and Performance Measurement of a Native-Mode ATM Transport Layer (Estended Version) IEEEACM Transactions on Networking Vol 4 Nordm 4 (Aug 1996)

9 R Karabek A Native ATM Protocol Architecture Design and Performance Evaluation IEEE Proceedings 22nd Annual Conference on Local Computer Networks pp 204-210 (1997)

10 D C Feldmeier A framework of architectural concepts for high-speed communications systems IEEE J Select Areas CommunVol11 Nordm 4 (May 1993)

11 T Anker D Breitgand D Dolev Z Levy Congress CONnection-oriented Group-address RESolution Service Proceeding of SPIE97 vol 3233 on Broadband Networking Technologies Nov (1997)

12 kStack httpcometcolumbiaedusoftwarekStack

13 T La Porta and M Schwartz Architectures Features and Implementation of High-Speed Transport Protocols IEEE Network Magazine pp 14-22 (May 1991)

14 ____ B-ISDN ATM Adaptation Layer Service Specific Connection Oriented Protocol (SSCOP) Q2110 ITU-T (10-Mar 1994)

15 J Soleacute-Pareta J Vila-Sallent Network-based paralell computing over ATM using improved SSCOP protocol Computer Communications 19 pp 915-926 (1996)

16 K Obraczka Multicast Transport Protocols A survey and Taxonomy IEEE Communi Magazine (1998)

17 R Venkateswaran CS Raghavendra X Chen and VP Kumar A Scalable Dynamic Multicast Routing Algorithm in ATM Networks IEEE pp 1361-1365 (1997)

18 Matthias Grossglauser and KK Ramakrishnan SEAM Scalable and Efficient ATM Multicast IEEE 1997 pp 867-875 (1997)

19 M Nguyen and M Schwartz MCMP A Transportsession level Distributed Protocol for Desktop Conference Setup IEEE Journal Selected and comunications Vol 14 Nordm 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 Nordm 3 pp 437-443 (April 1998)

22 R Kishimoto Agent communication system for multimedia communication services INFOCOMrsquo96 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 Nordm 3 pp 414-423 (April 1998)

  • ATM - Modo de Transferencia Asiacutencrona
  • Revisioacuten y Clasificacioacuten de Protocolos para Redes de Tecnologiacutea ATM
    • Resumen
    • 1-Introduccioacuten y motivaciones
    • 2- Protocolos nativos ATM
    • 3- Protocolos de transporte para redes ATM
    • 4- Protocolos multipoint
    • 5- Nuevos campos de investigacioacuten
      • Referencias
Page 16: Atm

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 ademaacutes aporta otras importantes novedades Los principales componentes de N3 incluyen una API sockets ATM nativa un protocolo de transporte ATM y un servicio de nombres ATM (Fig2) El protocolo de transporte ATM propuesto en [2] ofrece soporte para tres diferentes tipos de servicio entrega garantizada (mecanismos de retransmisioacuten) 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 congestioacuten de la transferencia de datagramas y de la multiplexacioacuten 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 maacutes importante El Flow Management se responsabiliza de manipular los flujos de datos desde y hasta la red viacutea la interfaz AAL La segmentacioacuten el reensamblado y el control de errores es tambieacuten 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 congestioacuten y de flujo extremo-extremo maacutes complejo

[7] describe la semaacutentica de una pila de protocolos y explora una nueva arquitectura de protocolo adaptada a la tecnologiacutea ATM y a las aplicaciones multimedia El disentildeo estaacute basado en tres principios baacutesicos separacioacuten de flujos de control y de datos minimizacioacuten del overhead y de la duplicidad de funciones y acceso de las aplicaciones al nivel ATM con garantiacuteas 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-over-ATM 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 moacutedulo CNTL abre una conexioacuten de sentildealizacioacuten con el dispositivo ATM y establece una gestioacuten de las llamadas de mensajes de configuracioacuten PF_ATM separa flujos de datos y de control para aliviar el liacutemite de comportamiento en las comunicaciones Esto permite a los mecanismos de control de traacutefico ser raacutepidos y sencillos mientras los mecanismos de control pueden ser tan complicados como sea necesario Esta separacioacuten permite tambieacuten que los dispositivos puedan estar en los puntos finales de una conexioacuten La interfaz PF_ATM da a las aplicaciones acceso directo a la capa de enlace ATM y extiende las garantiacuteas de QoS a los puntos extremos de la comunicacioacuten Un segundo prototipo[7] es disentildeado e implementado con dos objetivos principales en la optimizacioacuten de la pila nativa ATM

Optimizar los caminos de datos entre los adaptadores ATM aprovechando la separacioacuten de flujos de control y de datos y la capacidad de gestioacuten de datos especiacuteficos de las conexiones de la pila ATM

Optimizar el procesamiento de overheads usando una pila de protocolos nativo ATM en lugar de UDPIP

[11] introduce CONGRESS (CONnection oriented Group-address RESolution Service) otro eficiente protocolo nativo ATM para la resolucioacuten y gestioacuten 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 disentildeo basado en los dos siguientes principios

Disentildeo jeraacuterquico los servicios del protocolo son ofrecidos a las aplicaciones por muacuteltiples servidores organizados jeraacuterquicamente No inundacioacuten se evita la inundacioacuten 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 implementacioacuten sobre Unix y Windows NT estaacute 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 antildeadido un moacutedulo que monitoria la QoS extremo-a-extremo

3- Protocolos de transporte para redes ATMEn los dos o tres uacuteltimos antildeos ha habido numerosos e interesante intentos por disentildear protocolos de transporte La referencia [10] presenta un completo y ya claacutesico resumen de las propuestas maacutes interesantes en materia de protocolos de transporte para redes de alta velocidad (mayoritariamente IP en el artiacuteculo) Ademaacutes la referencia [13] ofrece una interesante visioacuten de las caracteriacutesticas maacutes importantes en los protocolos de elevada velocidad Son estudiadas tambieacuten diversas arquitecturas de protocolos y varias teacutecnicas de implementacioacuten Los protocolos de transporte de elevada velocidad son fuente de activas investigaciones y estaacuten en constante evolucioacuten desde hace maacutes de dos deacutecadas 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 aacutembito de las comunicaciones que ha recibido mayor atencioacuten es la capa de transporte la cuarta capa del OSI-RM de los protocolos de comunicaciones TCP e ISO TP4 son los dos maacutes populares protocolos de transporte Pero centraacutendonos maacutes concretamente en el aacutembito de ATM la literatura presenta varios protocolos de transporte y arquitecturas para redes de alta velocidad revisadas resumidamente a continuacioacuten [7] ofrece una excelente y didaacutectica arquitectura de pila de protocolos para aplicaciones multimedia en modo nativo ATM Esta arquitectura de protocolo ha sido ya descrita brevemente en la seccioacuten anterior [8] presentan el disentildeo implementacioacuten 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 estaacute formada por tres entidades principales aplicacioacuten sentildealizacioacuten y transporte La siguiente Tabla 1 muestra un conjunto de nueve baacutesicos 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 combinacioacuten de servicios La marca X indica el servicio baacutesico soportado en cada clase de servicio general

Clases de servicio

Servicios Servicio de comportamiento

garantizado

Servicio fiable Servicio Best effort

- Transferencia Simplex de datos

X X X

- Control de errores - deteccion de errorestimeouts retransmisiones

No existente (ofrecido por

AAL5)

- Bucle abierto - Control de flujo realimentado

No existente -

- X

- No existente

- Tamantildeo de mensaje ilimitado

X X X

- Eleccioacuten de blocking - Aplicacioacuten Non-blocking

X X

X X

X X

- Eleccioacuten de byte stream - Semaacutentica transferencia de mensajes

X X

X X

X X

- Garantiacuteas de QoS requerimientos de ancho de banda

No soportado No soportado

- Reserva de recursos X No existente No existente

- Transferencias Multicast X No soportado Para servicios no fiables

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 recuperacioacuten de peacuterdidas del protocolo estaacutendar SSCOP [14] y demuestran que el resultado ofrece baja latencia eficiente recuperacioacuten de ceacutelulas perdidas y es tan robusto como el estaacutendar SSCOP

4- Protocolos multipointEl crecimiento de las redes ATM viene motivado en parte por la demanda de servicios multimedia para grupos dispersos de usuarios El traacutefico multicast tiene caracteriacutesticas particulares descritas para ATM en UNI 40 [6] y anteriores [5] La distribucioacuten de informacioacuten punto-a-multipunto (uno-a-muchos) o multipunto-a-multipunto (muchos-a-muchos) es un objetivo baacutesico propuesto por varios protocolos y arquitecturas ATM que ofrecen el soporte multimedia yo multicast como audio-conferencia video-conferencia trabajos colaborativos o VoD ATM es auacuten una tecnologiacutea emergente disentildeada 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 30) para ATM define conexiones punto-a-multipunto y las conexiones multipunto-a-multipunto soacutelo 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 topologiacutea completamente mallada todos-con-todos Aunque esta topologiacutea ofrece conexiones multipunto-a-multipunto hay que destacar que no escala bien cuando el nuacutemero de participantes es elevado Una alternativa al anterior esquema es el uso de un servidor que actuacutea a modo de raiacutez en el aacuterbol multipunto Este meacutetodo soacutelo requiere un nodo raiacutez para almacenar informacioacuten pero la desventaja de este meacutetodo son las potenciales congestiones en el servidor

cuando debe encargarse de enviacuteos y retransmisiones de las conexiones multipunto-a-multipunto

Para solventar las limitaciones de UNI 30 y UNI 31 [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 sentildealizacioacuten ATM (UNI 31 UNI 40) [4][5][6] Comenzamos destacando la referencia [16] como un reciente trabajo que revisa y compara los protocolos de transporte multicast maacutes importantes en Internet como MTP-2 XTP RTP SRM RAMP RMTP MFTP STORM etc IETF e IRTF (como ITU-T y ATM Forum) tambieacuten impulsan una importante actividad en este campo La referencia [16] revisa los maacutes representativos protocolos multicast y los clasifica de acuerdo a la taxonomiacutea de varias caracteriacutesticas (propagacioacuten de datos mecanismos de fiabilidad retransmisiones control de congestioacuten y de flujo gestioacuten de grupos multicast etc) En Internet los mecanismos efectivos de control de congestioacuten son una de las prioridades en las investigaciones de las transferencias multicast fiables Los mecanismos de seguridad y las teacutecnicas escalables de recuperacioacuten 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 maacutes importantes caracteriacutesticas En esta seccioacuten 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 maacutes interesantes en los siguientes paacuterrafos SMART (shared many-to-many ATM reservations)[3] es un protocolo para controlar un aacuterbol ATM multicast compartido soportando comunicaciones muchos-a-muchos (many-to-many) Esta propuesta tiene importantes caracteriacutesticas como que reside completamente en la capa ATM y no requiere ninguacuten servidor soporta uno o varios VCCs (y tambieacuten VPCs) cuyo nuacutemero es libremente configurado y es independiente del nuacutemero de puntos finales usa el concepto de bloques de datos como en la clase de servicio ABT y tambieacuten permite VCCs de las clases CBR VBR o UBR el protocolo garantiza que no existen puntos de interrelacioacuten en los VCC del aacuterbol son respetadas las garantiacuteas del contrato de traacutefico asociado con los VCCs etc SMART puede ser entendido como un protocolo completamente distribuido para coordinar la distribucioacuten de VPIsVCIs 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 ceacutelulas de datos desde diferentes fuentes pueden llegar intercaladas a un destinatario) y tambieacuten Demand Sharing (los recursos asignados a conexiones muchos-a-muchos son dinaacutemicamente compartidas entre todas las potenciales fuentes El artiacuteculo [3] describe el protocolo SMART formal e informalmente y propone completas pruebas de correccioacuten y un detallado anaacutelisis de comportamiento para estudios futuros Tambieacuten son sugeridas otras investigaciones como son ofrecer justicia en los accesos a los aacuterboles multicast investigar las ceacutelulas RM perioacutedicamente para aliviar las congestiones en la red o disminuir el tiempo de acceso del usuario a los aacuterboles de distribucioacuten multicast anaacutelisis de las ceacutelulas RM dentro de cada VCC o fuera enviando todas las ceacutelulas RM en un VCC dedicado En [17] se presenta MWAX un algoritmo dinaacutemico 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 artiacuteculo describe un esquema jeraacuterquico basado en CBT para incorporar routing multipunto-a-multipunto en PNNI En el algoritmo los nodos core actuacutean como participantes pasivos para eliminar la dependencia en la seleccioacuten de estos nodos Con un mecanismo de backup se consigue un algoritmo tolerante a fallos en los nodos core lo cual puede ser faacutecilmente 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 jerarquiacutea SEAM (Scalable and Efficient ATM Multicast) [18] propone una arquitectura escalable eficiente y multicast multipunto-a-multipunto para redes ATM que usa un soacutelo VC para un grupo multicast de muacuteltiples 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 Tambieacuten realiza aportaciones para conseguir soportar IP multicast sobre redes ATM extensas

SEAM usa un soacutelo aacuterbol de distribucioacuten 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 sentildealizacioacuten del grupo Este trabajo deja abiertas investigaciones referentes a la gestioacuten de traacutefico y a la entrega fiable de traacuteficos multicasting Concluimos esta seccioacuten destacando MCMP (Multiparty Conference Management Protocol) [19] que sin estar pensado especiacuteficamente para ATM es un protocolo de nivel sesioacutentransporte distribuido extremo-extremo y desarrollado para gestioacuten de grupos de aplicaciones de conferencia MCMP es un conjunto de algoritmos de control distribuido para configuracioacuten de conferencias multipunto y gestioacuten de miembros de grupos de usuarios Conceptualmente MCMP reside en el nivel de sesioacuten en el que se establece la infraestructura para activar la transferencia de informacioacuten entre los participantes en la conferencia Pero funcionalmente el protocolo acompasa los niveles de sesioacuten y de transporte pues utiliza directamente servicios del nivel de red Son destacables las condiciones de correccioacuten (conectividad validacioacuten unicidad consistencia y terminacioacuten) que deben ser satisfechas una vez que la conferencia ha sido configurada por el algoritmo de configuracioacuten de MCMP El artiacuteculo muestra exhaustivas pruebas de correccioacuten para uno de los algoritmos y tambieacuten describe la especificacioacuten y verificacioacuten del protocolo

5- Nuevos campos de investigacioacutenEn todas las redes existen gran variedad de elementos hardware (switchs routers bridges brouters hubs ETDs etc) que realizan muy diversas funciones (conmutacioacuten routing puenteo controles de congestioacuten y de flujo garantiacutea de QoS ejecucioacuten de aplicaciones etc) En la actualidad la red es mayormente un canal de comunicacioacuten para transferir paquetes entre equipos finales (ayudada por los elementos hardware antes citados) Pero tambieacuten se estaacuten realizando importante esfuerzos para equipar a los elementos hardware con elevadas prestaciones aportadas por diversas teacutecnicas software Esto dota a la red de caracteriacutesticas activas (active networks) en el sentido de que los elementos hardware que la componen computan modifican u operan los contenidos de los paquetes y tambieacuten seraacuten capaces de transferir o propagar coacutedigo Por consiguiente una red activa es una red programable [20] es una excelente revisioacuten de este novedoso campo de investigacioacuten que discute dos planteamientos en la realizacioacuten de redes activas la idea del conmutador programable y la de la caacutepsula Una red es activa si en sus aacuterboles de distribucioacuten multicast existen nodos activos con capacidad para ejecutar programas yo capaces de implementar mecanismos de propagacioacuten de coacutedigo Algunas de las ventajas de los protocolos activos son conseguidas instalando nodos activos en puntos estrateacutegicos de la red Otro nuevo concepto es presentado en [21] como una metodologiacutea para el disentildeo de protocolos Los protocol boosters son una nueva contribucioacuten a las redes activas o programables Una ventaja de los boosters es que pueden ser faacutecilmente 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 aacuterea extensa Este papel introduce una arquitectura software orientada a agente y propone el concepto de agente de comunicacioacuten para servicio de comunicacioacuten 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 artiacuteculo muestra agentes software moacuteviles usados para implementar operaciones robustas y funciones de mantenimiento en redes ATM Los agentes desempentildean un rol similar al de las ceacutelulas OAM en ATM estaacutendar pues son transmitidos entre entidades de control a intervalos regulares usando recursos predefinidos La diferencia entre los agentes moacuteviles y las ceacutelulas OAM reside en que eacutestos pueden contener coacutedigo Para concluir destacar que la integracioacuten del traacutefico IP sobre tecnologiacutea ATM es tambieacuten uno de los campos maacutes activos en la actualidad En esta liacutenea pueden destacarse los siguientes protocolos IP-over-ATM IP Switching Tag Switching NHRP MPOA IMSS CSR ARIS AREQUIPARED y EPD Referencias

1 ____ Native ATM Service Semantic Description Version 1 ATM Forum Technical Committee ATM Forum Document af-saa-0048000 (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 Broadband Networks Multimedia Applications Services and Techniques ECMASTrsquo98 Springer (May 1998)

3 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 Nordm 3 (April 1997)

4 W D Zhong K Yukimatsu Design requeriments and architectures for multicast ATM switching IEICE Trans Com Vol E77-B pp 1420-1428 (Nov 1994)

5 ____ ATM user-network interface version 31 specification ATM Forum (1994)

6 ____ Traffic Management Specification Version 40 ATM Forum Technical Committee ATM Forum Document af-tm-0056000 (April 1996)

7 D Kandlur D Saha and W Willebeck Protocol Architecture for multimedia Application over ATM Networks IEEE Journal Selected and Communications Vol 14 Nordm 7 pp 1349-1359 (Sep 1996)

8 R Ahuja S Keshav and H Saran Design Implementation and Performance Measurement of a Native-Mode ATM Transport Layer (Estended Version) IEEEACM Transactions on Networking Vol 4 Nordm 4 (Aug 1996)

9 R Karabek A Native ATM Protocol Architecture Design and Performance Evaluation IEEE Proceedings 22nd Annual Conference on Local Computer Networks pp 204-210 (1997)

10 D C Feldmeier A framework of architectural concepts for high-speed communications systems IEEE J Select Areas CommunVol11 Nordm 4 (May 1993)

11 T Anker D Breitgand D Dolev Z Levy Congress CONnection-oriented Group-address RESolution Service Proceeding of SPIE97 vol 3233 on Broadband Networking Technologies Nov (1997)

12 kStack httpcometcolumbiaedusoftwarekStack

13 T La Porta and M Schwartz Architectures Features and Implementation of High-Speed Transport Protocols IEEE Network Magazine pp 14-22 (May 1991)

14 ____ B-ISDN ATM Adaptation Layer Service Specific Connection Oriented Protocol (SSCOP) Q2110 ITU-T (10-Mar 1994)

15 J Soleacute-Pareta J Vila-Sallent Network-based paralell computing over ATM using improved SSCOP protocol Computer Communications 19 pp 915-926 (1996)

16 K Obraczka Multicast Transport Protocols A survey and Taxonomy IEEE Communi Magazine (1998)

17 R Venkateswaran CS Raghavendra X Chen and VP Kumar A Scalable Dynamic Multicast Routing Algorithm in ATM Networks IEEE pp 1361-1365 (1997)

18 Matthias Grossglauser and KK Ramakrishnan SEAM Scalable and Efficient ATM Multicast IEEE 1997 pp 867-875 (1997)

19 M Nguyen and M Schwartz MCMP A Transportsession level Distributed Protocol for Desktop Conference Setup IEEE Journal Selected and comunications Vol 14 Nordm 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 Nordm 3 pp 437-443 (April 1998)

22 R Kishimoto Agent communication system for multimedia communication services INFOCOMrsquo96 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 Nordm 3 pp 414-423 (April 1998)

  • ATM - Modo de Transferencia Asiacutencrona
  • Revisioacuten y Clasificacioacuten de Protocolos para Redes de Tecnologiacutea ATM
    • Resumen
    • 1-Introduccioacuten y motivaciones
    • 2- Protocolos nativos ATM
    • 3- Protocolos de transporte para redes ATM
    • 4- Protocolos multipoint
    • 5- Nuevos campos de investigacioacuten
      • Referencias
Page 17: Atm

Optimizar el procesamiento de overheads usando una pila de protocolos nativo ATM en lugar de UDPIP

[11] introduce CONGRESS (CONnection oriented Group-address RESolution Service) otro eficiente protocolo nativo ATM para la resolucioacuten y gestioacuten 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 disentildeo basado en los dos siguientes principios

Disentildeo jeraacuterquico los servicios del protocolo son ofrecidos a las aplicaciones por muacuteltiples servidores organizados jeraacuterquicamente No inundacioacuten se evita la inundacioacuten 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 implementacioacuten sobre Unix y Windows NT estaacute 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 antildeadido un moacutedulo que monitoria la QoS extremo-a-extremo

3- Protocolos de transporte para redes ATMEn los dos o tres uacuteltimos antildeos ha habido numerosos e interesante intentos por disentildear protocolos de transporte La referencia [10] presenta un completo y ya claacutesico resumen de las propuestas maacutes interesantes en materia de protocolos de transporte para redes de alta velocidad (mayoritariamente IP en el artiacuteculo) Ademaacutes la referencia [13] ofrece una interesante visioacuten de las caracteriacutesticas maacutes importantes en los protocolos de elevada velocidad Son estudiadas tambieacuten diversas arquitecturas de protocolos y varias teacutecnicas de implementacioacuten Los protocolos de transporte de elevada velocidad son fuente de activas investigaciones y estaacuten en constante evolucioacuten desde hace maacutes de dos deacutecadas 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 aacutembito de las comunicaciones que ha recibido mayor atencioacuten es la capa de transporte la cuarta capa del OSI-RM de los protocolos de comunicaciones TCP e ISO TP4 son los dos maacutes populares protocolos de transporte Pero centraacutendonos maacutes concretamente en el aacutembito de ATM la literatura presenta varios protocolos de transporte y arquitecturas para redes de alta velocidad revisadas resumidamente a continuacioacuten [7] ofrece una excelente y didaacutectica arquitectura de pila de protocolos para aplicaciones multimedia en modo nativo ATM Esta arquitectura de protocolo ha sido ya descrita brevemente en la seccioacuten anterior [8] presentan el disentildeo implementacioacuten 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 estaacute formada por tres entidades principales aplicacioacuten sentildealizacioacuten y transporte La siguiente Tabla 1 muestra un conjunto de nueve baacutesicos 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 combinacioacuten de servicios La marca X indica el servicio baacutesico soportado en cada clase de servicio general

Clases de servicio

Servicios Servicio de comportamiento

garantizado

Servicio fiable Servicio Best effort

- Transferencia Simplex de datos

X X X

- Control de errores - deteccion de errorestimeouts retransmisiones

No existente (ofrecido por

AAL5)

- Bucle abierto - Control de flujo realimentado

No existente -

- X

- No existente

- Tamantildeo de mensaje ilimitado

X X X

- Eleccioacuten de blocking - Aplicacioacuten Non-blocking

X X

X X

X X

- Eleccioacuten de byte stream - Semaacutentica transferencia de mensajes

X X

X X

X X

- Garantiacuteas de QoS requerimientos de ancho de banda

No soportado No soportado

- Reserva de recursos X No existente No existente

- Transferencias Multicast X No soportado Para servicios no fiables

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 recuperacioacuten de peacuterdidas del protocolo estaacutendar SSCOP [14] y demuestran que el resultado ofrece baja latencia eficiente recuperacioacuten de ceacutelulas perdidas y es tan robusto como el estaacutendar SSCOP

4- Protocolos multipointEl crecimiento de las redes ATM viene motivado en parte por la demanda de servicios multimedia para grupos dispersos de usuarios El traacutefico multicast tiene caracteriacutesticas particulares descritas para ATM en UNI 40 [6] y anteriores [5] La distribucioacuten de informacioacuten punto-a-multipunto (uno-a-muchos) o multipunto-a-multipunto (muchos-a-muchos) es un objetivo baacutesico propuesto por varios protocolos y arquitecturas ATM que ofrecen el soporte multimedia yo multicast como audio-conferencia video-conferencia trabajos colaborativos o VoD ATM es auacuten una tecnologiacutea emergente disentildeada 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 30) para ATM define conexiones punto-a-multipunto y las conexiones multipunto-a-multipunto soacutelo 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 topologiacutea completamente mallada todos-con-todos Aunque esta topologiacutea ofrece conexiones multipunto-a-multipunto hay que destacar que no escala bien cuando el nuacutemero de participantes es elevado Una alternativa al anterior esquema es el uso de un servidor que actuacutea a modo de raiacutez en el aacuterbol multipunto Este meacutetodo soacutelo requiere un nodo raiacutez para almacenar informacioacuten pero la desventaja de este meacutetodo son las potenciales congestiones en el servidor

cuando debe encargarse de enviacuteos y retransmisiones de las conexiones multipunto-a-multipunto

Para solventar las limitaciones de UNI 30 y UNI 31 [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 sentildealizacioacuten ATM (UNI 31 UNI 40) [4][5][6] Comenzamos destacando la referencia [16] como un reciente trabajo que revisa y compara los protocolos de transporte multicast maacutes importantes en Internet como MTP-2 XTP RTP SRM RAMP RMTP MFTP STORM etc IETF e IRTF (como ITU-T y ATM Forum) tambieacuten impulsan una importante actividad en este campo La referencia [16] revisa los maacutes representativos protocolos multicast y los clasifica de acuerdo a la taxonomiacutea de varias caracteriacutesticas (propagacioacuten de datos mecanismos de fiabilidad retransmisiones control de congestioacuten y de flujo gestioacuten de grupos multicast etc) En Internet los mecanismos efectivos de control de congestioacuten son una de las prioridades en las investigaciones de las transferencias multicast fiables Los mecanismos de seguridad y las teacutecnicas escalables de recuperacioacuten 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 maacutes importantes caracteriacutesticas En esta seccioacuten 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 maacutes interesantes en los siguientes paacuterrafos SMART (shared many-to-many ATM reservations)[3] es un protocolo para controlar un aacuterbol ATM multicast compartido soportando comunicaciones muchos-a-muchos (many-to-many) Esta propuesta tiene importantes caracteriacutesticas como que reside completamente en la capa ATM y no requiere ninguacuten servidor soporta uno o varios VCCs (y tambieacuten VPCs) cuyo nuacutemero es libremente configurado y es independiente del nuacutemero de puntos finales usa el concepto de bloques de datos como en la clase de servicio ABT y tambieacuten permite VCCs de las clases CBR VBR o UBR el protocolo garantiza que no existen puntos de interrelacioacuten en los VCC del aacuterbol son respetadas las garantiacuteas del contrato de traacutefico asociado con los VCCs etc SMART puede ser entendido como un protocolo completamente distribuido para coordinar la distribucioacuten de VPIsVCIs 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 ceacutelulas de datos desde diferentes fuentes pueden llegar intercaladas a un destinatario) y tambieacuten Demand Sharing (los recursos asignados a conexiones muchos-a-muchos son dinaacutemicamente compartidas entre todas las potenciales fuentes El artiacuteculo [3] describe el protocolo SMART formal e informalmente y propone completas pruebas de correccioacuten y un detallado anaacutelisis de comportamiento para estudios futuros Tambieacuten son sugeridas otras investigaciones como son ofrecer justicia en los accesos a los aacuterboles multicast investigar las ceacutelulas RM perioacutedicamente para aliviar las congestiones en la red o disminuir el tiempo de acceso del usuario a los aacuterboles de distribucioacuten multicast anaacutelisis de las ceacutelulas RM dentro de cada VCC o fuera enviando todas las ceacutelulas RM en un VCC dedicado En [17] se presenta MWAX un algoritmo dinaacutemico 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 artiacuteculo describe un esquema jeraacuterquico basado en CBT para incorporar routing multipunto-a-multipunto en PNNI En el algoritmo los nodos core actuacutean como participantes pasivos para eliminar la dependencia en la seleccioacuten de estos nodos Con un mecanismo de backup se consigue un algoritmo tolerante a fallos en los nodos core lo cual puede ser faacutecilmente 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 jerarquiacutea SEAM (Scalable and Efficient ATM Multicast) [18] propone una arquitectura escalable eficiente y multicast multipunto-a-multipunto para redes ATM que usa un soacutelo VC para un grupo multicast de muacuteltiples 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 Tambieacuten realiza aportaciones para conseguir soportar IP multicast sobre redes ATM extensas

SEAM usa un soacutelo aacuterbol de distribucioacuten 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 sentildealizacioacuten del grupo Este trabajo deja abiertas investigaciones referentes a la gestioacuten de traacutefico y a la entrega fiable de traacuteficos multicasting Concluimos esta seccioacuten destacando MCMP (Multiparty Conference Management Protocol) [19] que sin estar pensado especiacuteficamente para ATM es un protocolo de nivel sesioacutentransporte distribuido extremo-extremo y desarrollado para gestioacuten de grupos de aplicaciones de conferencia MCMP es un conjunto de algoritmos de control distribuido para configuracioacuten de conferencias multipunto y gestioacuten de miembros de grupos de usuarios Conceptualmente MCMP reside en el nivel de sesioacuten en el que se establece la infraestructura para activar la transferencia de informacioacuten entre los participantes en la conferencia Pero funcionalmente el protocolo acompasa los niveles de sesioacuten y de transporte pues utiliza directamente servicios del nivel de red Son destacables las condiciones de correccioacuten (conectividad validacioacuten unicidad consistencia y terminacioacuten) que deben ser satisfechas una vez que la conferencia ha sido configurada por el algoritmo de configuracioacuten de MCMP El artiacuteculo muestra exhaustivas pruebas de correccioacuten para uno de los algoritmos y tambieacuten describe la especificacioacuten y verificacioacuten del protocolo

5- Nuevos campos de investigacioacutenEn todas las redes existen gran variedad de elementos hardware (switchs routers bridges brouters hubs ETDs etc) que realizan muy diversas funciones (conmutacioacuten routing puenteo controles de congestioacuten y de flujo garantiacutea de QoS ejecucioacuten de aplicaciones etc) En la actualidad la red es mayormente un canal de comunicacioacuten para transferir paquetes entre equipos finales (ayudada por los elementos hardware antes citados) Pero tambieacuten se estaacuten realizando importante esfuerzos para equipar a los elementos hardware con elevadas prestaciones aportadas por diversas teacutecnicas software Esto dota a la red de caracteriacutesticas activas (active networks) en el sentido de que los elementos hardware que la componen computan modifican u operan los contenidos de los paquetes y tambieacuten seraacuten capaces de transferir o propagar coacutedigo Por consiguiente una red activa es una red programable [20] es una excelente revisioacuten de este novedoso campo de investigacioacuten que discute dos planteamientos en la realizacioacuten de redes activas la idea del conmutador programable y la de la caacutepsula Una red es activa si en sus aacuterboles de distribucioacuten multicast existen nodos activos con capacidad para ejecutar programas yo capaces de implementar mecanismos de propagacioacuten de coacutedigo Algunas de las ventajas de los protocolos activos son conseguidas instalando nodos activos en puntos estrateacutegicos de la red Otro nuevo concepto es presentado en [21] como una metodologiacutea para el disentildeo de protocolos Los protocol boosters son una nueva contribucioacuten a las redes activas o programables Una ventaja de los boosters es que pueden ser faacutecilmente 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 aacuterea extensa Este papel introduce una arquitectura software orientada a agente y propone el concepto de agente de comunicacioacuten para servicio de comunicacioacuten 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 artiacuteculo muestra agentes software moacuteviles usados para implementar operaciones robustas y funciones de mantenimiento en redes ATM Los agentes desempentildean un rol similar al de las ceacutelulas OAM en ATM estaacutendar pues son transmitidos entre entidades de control a intervalos regulares usando recursos predefinidos La diferencia entre los agentes moacuteviles y las ceacutelulas OAM reside en que eacutestos pueden contener coacutedigo Para concluir destacar que la integracioacuten del traacutefico IP sobre tecnologiacutea ATM es tambieacuten uno de los campos maacutes activos en la actualidad En esta liacutenea pueden destacarse los siguientes protocolos IP-over-ATM IP Switching Tag Switching NHRP MPOA IMSS CSR ARIS AREQUIPARED y EPD Referencias

1 ____ Native ATM Service Semantic Description Version 1 ATM Forum Technical Committee ATM Forum Document af-saa-0048000 (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 Broadband Networks Multimedia Applications Services and Techniques ECMASTrsquo98 Springer (May 1998)

3 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 Nordm 3 (April 1997)

4 W D Zhong K Yukimatsu Design requeriments and architectures for multicast ATM switching IEICE Trans Com Vol E77-B pp 1420-1428 (Nov 1994)

5 ____ ATM user-network interface version 31 specification ATM Forum (1994)

6 ____ Traffic Management Specification Version 40 ATM Forum Technical Committee ATM Forum Document af-tm-0056000 (April 1996)

7 D Kandlur D Saha and W Willebeck Protocol Architecture for multimedia Application over ATM Networks IEEE Journal Selected and Communications Vol 14 Nordm 7 pp 1349-1359 (Sep 1996)

8 R Ahuja S Keshav and H Saran Design Implementation and Performance Measurement of a Native-Mode ATM Transport Layer (Estended Version) IEEEACM Transactions on Networking Vol 4 Nordm 4 (Aug 1996)

9 R Karabek A Native ATM Protocol Architecture Design and Performance Evaluation IEEE Proceedings 22nd Annual Conference on Local Computer Networks pp 204-210 (1997)

10 D C Feldmeier A framework of architectural concepts for high-speed communications systems IEEE J Select Areas CommunVol11 Nordm 4 (May 1993)

11 T Anker D Breitgand D Dolev Z Levy Congress CONnection-oriented Group-address RESolution Service Proceeding of SPIE97 vol 3233 on Broadband Networking Technologies Nov (1997)

12 kStack httpcometcolumbiaedusoftwarekStack

13 T La Porta and M Schwartz Architectures Features and Implementation of High-Speed Transport Protocols IEEE Network Magazine pp 14-22 (May 1991)

14 ____ B-ISDN ATM Adaptation Layer Service Specific Connection Oriented Protocol (SSCOP) Q2110 ITU-T (10-Mar 1994)

15 J Soleacute-Pareta J Vila-Sallent Network-based paralell computing over ATM using improved SSCOP protocol Computer Communications 19 pp 915-926 (1996)

16 K Obraczka Multicast Transport Protocols A survey and Taxonomy IEEE Communi Magazine (1998)

17 R Venkateswaran CS Raghavendra X Chen and VP Kumar A Scalable Dynamic Multicast Routing Algorithm in ATM Networks IEEE pp 1361-1365 (1997)

18 Matthias Grossglauser and KK Ramakrishnan SEAM Scalable and Efficient ATM Multicast IEEE 1997 pp 867-875 (1997)

19 M Nguyen and M Schwartz MCMP A Transportsession level Distributed Protocol for Desktop Conference Setup IEEE Journal Selected and comunications Vol 14 Nordm 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 Nordm 3 pp 437-443 (April 1998)

22 R Kishimoto Agent communication system for multimedia communication services INFOCOMrsquo96 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 Nordm 3 pp 414-423 (April 1998)

  • ATM - Modo de Transferencia Asiacutencrona
  • Revisioacuten y Clasificacioacuten de Protocolos para Redes de Tecnologiacutea ATM
    • Resumen
    • 1-Introduccioacuten y motivaciones
    • 2- Protocolos nativos ATM
    • 3- Protocolos de transporte para redes ATM
    • 4- Protocolos multipoint
    • 5- Nuevos campos de investigacioacuten
      • Referencias
Page 18: Atm

- Control de errores - deteccion de errorestimeouts retransmisiones

No existente (ofrecido por

AAL5)

- Bucle abierto - Control de flujo realimentado

No existente -

- X

- No existente

- Tamantildeo de mensaje ilimitado

X X X

- Eleccioacuten de blocking - Aplicacioacuten Non-blocking

X X

X X

X X

- Eleccioacuten de byte stream - Semaacutentica transferencia de mensajes

X X

X X

X X

- Garantiacuteas de QoS requerimientos de ancho de banda

No soportado No soportado

- Reserva de recursos X No existente No existente

- Transferencias Multicast X No soportado Para servicios no fiables

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 recuperacioacuten de peacuterdidas del protocolo estaacutendar SSCOP [14] y demuestran que el resultado ofrece baja latencia eficiente recuperacioacuten de ceacutelulas perdidas y es tan robusto como el estaacutendar SSCOP

4- Protocolos multipointEl crecimiento de las redes ATM viene motivado en parte por la demanda de servicios multimedia para grupos dispersos de usuarios El traacutefico multicast tiene caracteriacutesticas particulares descritas para ATM en UNI 40 [6] y anteriores [5] La distribucioacuten de informacioacuten punto-a-multipunto (uno-a-muchos) o multipunto-a-multipunto (muchos-a-muchos) es un objetivo baacutesico propuesto por varios protocolos y arquitecturas ATM que ofrecen el soporte multimedia yo multicast como audio-conferencia video-conferencia trabajos colaborativos o VoD ATM es auacuten una tecnologiacutea emergente disentildeada 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 30) para ATM define conexiones punto-a-multipunto y las conexiones multipunto-a-multipunto soacutelo 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 topologiacutea completamente mallada todos-con-todos Aunque esta topologiacutea ofrece conexiones multipunto-a-multipunto hay que destacar que no escala bien cuando el nuacutemero de participantes es elevado Una alternativa al anterior esquema es el uso de un servidor que actuacutea a modo de raiacutez en el aacuterbol multipunto Este meacutetodo soacutelo requiere un nodo raiacutez para almacenar informacioacuten pero la desventaja de este meacutetodo son las potenciales congestiones en el servidor

cuando debe encargarse de enviacuteos y retransmisiones de las conexiones multipunto-a-multipunto

Para solventar las limitaciones de UNI 30 y UNI 31 [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 sentildealizacioacuten ATM (UNI 31 UNI 40) [4][5][6] Comenzamos destacando la referencia [16] como un reciente trabajo que revisa y compara los protocolos de transporte multicast maacutes importantes en Internet como MTP-2 XTP RTP SRM RAMP RMTP MFTP STORM etc IETF e IRTF (como ITU-T y ATM Forum) tambieacuten impulsan una importante actividad en este campo La referencia [16] revisa los maacutes representativos protocolos multicast y los clasifica de acuerdo a la taxonomiacutea de varias caracteriacutesticas (propagacioacuten de datos mecanismos de fiabilidad retransmisiones control de congestioacuten y de flujo gestioacuten de grupos multicast etc) En Internet los mecanismos efectivos de control de congestioacuten son una de las prioridades en las investigaciones de las transferencias multicast fiables Los mecanismos de seguridad y las teacutecnicas escalables de recuperacioacuten 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 maacutes importantes caracteriacutesticas En esta seccioacuten 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 maacutes interesantes en los siguientes paacuterrafos SMART (shared many-to-many ATM reservations)[3] es un protocolo para controlar un aacuterbol ATM multicast compartido soportando comunicaciones muchos-a-muchos (many-to-many) Esta propuesta tiene importantes caracteriacutesticas como que reside completamente en la capa ATM y no requiere ninguacuten servidor soporta uno o varios VCCs (y tambieacuten VPCs) cuyo nuacutemero es libremente configurado y es independiente del nuacutemero de puntos finales usa el concepto de bloques de datos como en la clase de servicio ABT y tambieacuten permite VCCs de las clases CBR VBR o UBR el protocolo garantiza que no existen puntos de interrelacioacuten en los VCC del aacuterbol son respetadas las garantiacuteas del contrato de traacutefico asociado con los VCCs etc SMART puede ser entendido como un protocolo completamente distribuido para coordinar la distribucioacuten de VPIsVCIs 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 ceacutelulas de datos desde diferentes fuentes pueden llegar intercaladas a un destinatario) y tambieacuten Demand Sharing (los recursos asignados a conexiones muchos-a-muchos son dinaacutemicamente compartidas entre todas las potenciales fuentes El artiacuteculo [3] describe el protocolo SMART formal e informalmente y propone completas pruebas de correccioacuten y un detallado anaacutelisis de comportamiento para estudios futuros Tambieacuten son sugeridas otras investigaciones como son ofrecer justicia en los accesos a los aacuterboles multicast investigar las ceacutelulas RM perioacutedicamente para aliviar las congestiones en la red o disminuir el tiempo de acceso del usuario a los aacuterboles de distribucioacuten multicast anaacutelisis de las ceacutelulas RM dentro de cada VCC o fuera enviando todas las ceacutelulas RM en un VCC dedicado En [17] se presenta MWAX un algoritmo dinaacutemico 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 artiacuteculo describe un esquema jeraacuterquico basado en CBT para incorporar routing multipunto-a-multipunto en PNNI En el algoritmo los nodos core actuacutean como participantes pasivos para eliminar la dependencia en la seleccioacuten de estos nodos Con un mecanismo de backup se consigue un algoritmo tolerante a fallos en los nodos core lo cual puede ser faacutecilmente 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 jerarquiacutea SEAM (Scalable and Efficient ATM Multicast) [18] propone una arquitectura escalable eficiente y multicast multipunto-a-multipunto para redes ATM que usa un soacutelo VC para un grupo multicast de muacuteltiples 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 Tambieacuten realiza aportaciones para conseguir soportar IP multicast sobre redes ATM extensas

SEAM usa un soacutelo aacuterbol de distribucioacuten 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 sentildealizacioacuten del grupo Este trabajo deja abiertas investigaciones referentes a la gestioacuten de traacutefico y a la entrega fiable de traacuteficos multicasting Concluimos esta seccioacuten destacando MCMP (Multiparty Conference Management Protocol) [19] que sin estar pensado especiacuteficamente para ATM es un protocolo de nivel sesioacutentransporte distribuido extremo-extremo y desarrollado para gestioacuten de grupos de aplicaciones de conferencia MCMP es un conjunto de algoritmos de control distribuido para configuracioacuten de conferencias multipunto y gestioacuten de miembros de grupos de usuarios Conceptualmente MCMP reside en el nivel de sesioacuten en el que se establece la infraestructura para activar la transferencia de informacioacuten entre los participantes en la conferencia Pero funcionalmente el protocolo acompasa los niveles de sesioacuten y de transporte pues utiliza directamente servicios del nivel de red Son destacables las condiciones de correccioacuten (conectividad validacioacuten unicidad consistencia y terminacioacuten) que deben ser satisfechas una vez que la conferencia ha sido configurada por el algoritmo de configuracioacuten de MCMP El artiacuteculo muestra exhaustivas pruebas de correccioacuten para uno de los algoritmos y tambieacuten describe la especificacioacuten y verificacioacuten del protocolo

5- Nuevos campos de investigacioacutenEn todas las redes existen gran variedad de elementos hardware (switchs routers bridges brouters hubs ETDs etc) que realizan muy diversas funciones (conmutacioacuten routing puenteo controles de congestioacuten y de flujo garantiacutea de QoS ejecucioacuten de aplicaciones etc) En la actualidad la red es mayormente un canal de comunicacioacuten para transferir paquetes entre equipos finales (ayudada por los elementos hardware antes citados) Pero tambieacuten se estaacuten realizando importante esfuerzos para equipar a los elementos hardware con elevadas prestaciones aportadas por diversas teacutecnicas software Esto dota a la red de caracteriacutesticas activas (active networks) en el sentido de que los elementos hardware que la componen computan modifican u operan los contenidos de los paquetes y tambieacuten seraacuten capaces de transferir o propagar coacutedigo Por consiguiente una red activa es una red programable [20] es una excelente revisioacuten de este novedoso campo de investigacioacuten que discute dos planteamientos en la realizacioacuten de redes activas la idea del conmutador programable y la de la caacutepsula Una red es activa si en sus aacuterboles de distribucioacuten multicast existen nodos activos con capacidad para ejecutar programas yo capaces de implementar mecanismos de propagacioacuten de coacutedigo Algunas de las ventajas de los protocolos activos son conseguidas instalando nodos activos en puntos estrateacutegicos de la red Otro nuevo concepto es presentado en [21] como una metodologiacutea para el disentildeo de protocolos Los protocol boosters son una nueva contribucioacuten a las redes activas o programables Una ventaja de los boosters es que pueden ser faacutecilmente 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 aacuterea extensa Este papel introduce una arquitectura software orientada a agente y propone el concepto de agente de comunicacioacuten para servicio de comunicacioacuten 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 artiacuteculo muestra agentes software moacuteviles usados para implementar operaciones robustas y funciones de mantenimiento en redes ATM Los agentes desempentildean un rol similar al de las ceacutelulas OAM en ATM estaacutendar pues son transmitidos entre entidades de control a intervalos regulares usando recursos predefinidos La diferencia entre los agentes moacuteviles y las ceacutelulas OAM reside en que eacutestos pueden contener coacutedigo Para concluir destacar que la integracioacuten del traacutefico IP sobre tecnologiacutea ATM es tambieacuten uno de los campos maacutes activos en la actualidad En esta liacutenea pueden destacarse los siguientes protocolos IP-over-ATM IP Switching Tag Switching NHRP MPOA IMSS CSR ARIS AREQUIPARED y EPD Referencias

1 ____ Native ATM Service Semantic Description Version 1 ATM Forum Technical Committee ATM Forum Document af-saa-0048000 (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 Broadband Networks Multimedia Applications Services and Techniques ECMASTrsquo98 Springer (May 1998)

3 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 Nordm 3 (April 1997)

4 W D Zhong K Yukimatsu Design requeriments and architectures for multicast ATM switching IEICE Trans Com Vol E77-B pp 1420-1428 (Nov 1994)

5 ____ ATM user-network interface version 31 specification ATM Forum (1994)

6 ____ Traffic Management Specification Version 40 ATM Forum Technical Committee ATM Forum Document af-tm-0056000 (April 1996)

7 D Kandlur D Saha and W Willebeck Protocol Architecture for multimedia Application over ATM Networks IEEE Journal Selected and Communications Vol 14 Nordm 7 pp 1349-1359 (Sep 1996)

8 R Ahuja S Keshav and H Saran Design Implementation and Performance Measurement of a Native-Mode ATM Transport Layer (Estended Version) IEEEACM Transactions on Networking Vol 4 Nordm 4 (Aug 1996)

9 R Karabek A Native ATM Protocol Architecture Design and Performance Evaluation IEEE Proceedings 22nd Annual Conference on Local Computer Networks pp 204-210 (1997)

10 D C Feldmeier A framework of architectural concepts for high-speed communications systems IEEE J Select Areas CommunVol11 Nordm 4 (May 1993)

11 T Anker D Breitgand D Dolev Z Levy Congress CONnection-oriented Group-address RESolution Service Proceeding of SPIE97 vol 3233 on Broadband Networking Technologies Nov (1997)

12 kStack httpcometcolumbiaedusoftwarekStack

13 T La Porta and M Schwartz Architectures Features and Implementation of High-Speed Transport Protocols IEEE Network Magazine pp 14-22 (May 1991)

14 ____ B-ISDN ATM Adaptation Layer Service Specific Connection Oriented Protocol (SSCOP) Q2110 ITU-T (10-Mar 1994)

15 J Soleacute-Pareta J Vila-Sallent Network-based paralell computing over ATM using improved SSCOP protocol Computer Communications 19 pp 915-926 (1996)

16 K Obraczka Multicast Transport Protocols A survey and Taxonomy IEEE Communi Magazine (1998)

17 R Venkateswaran CS Raghavendra X Chen and VP Kumar A Scalable Dynamic Multicast Routing Algorithm in ATM Networks IEEE pp 1361-1365 (1997)

18 Matthias Grossglauser and KK Ramakrishnan SEAM Scalable and Efficient ATM Multicast IEEE 1997 pp 867-875 (1997)

19 M Nguyen and M Schwartz MCMP A Transportsession level Distributed Protocol for Desktop Conference Setup IEEE Journal Selected and comunications Vol 14 Nordm 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 Nordm 3 pp 437-443 (April 1998)

22 R Kishimoto Agent communication system for multimedia communication services INFOCOMrsquo96 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 Nordm 3 pp 414-423 (April 1998)

  • ATM - Modo de Transferencia Asiacutencrona
  • Revisioacuten y Clasificacioacuten de Protocolos para Redes de Tecnologiacutea ATM
    • Resumen
    • 1-Introduccioacuten y motivaciones
    • 2- Protocolos nativos ATM
    • 3- Protocolos de transporte para redes ATM
    • 4- Protocolos multipoint
    • 5- Nuevos campos de investigacioacuten
      • Referencias
Page 19: Atm

cuando debe encargarse de enviacuteos y retransmisiones de las conexiones multipunto-a-multipunto

Para solventar las limitaciones de UNI 30 y UNI 31 [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 sentildealizacioacuten ATM (UNI 31 UNI 40) [4][5][6] Comenzamos destacando la referencia [16] como un reciente trabajo que revisa y compara los protocolos de transporte multicast maacutes importantes en Internet como MTP-2 XTP RTP SRM RAMP RMTP MFTP STORM etc IETF e IRTF (como ITU-T y ATM Forum) tambieacuten impulsan una importante actividad en este campo La referencia [16] revisa los maacutes representativos protocolos multicast y los clasifica de acuerdo a la taxonomiacutea de varias caracteriacutesticas (propagacioacuten de datos mecanismos de fiabilidad retransmisiones control de congestioacuten y de flujo gestioacuten de grupos multicast etc) En Internet los mecanismos efectivos de control de congestioacuten son una de las prioridades en las investigaciones de las transferencias multicast fiables Los mecanismos de seguridad y las teacutecnicas escalables de recuperacioacuten 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 maacutes importantes caracteriacutesticas En esta seccioacuten 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 maacutes interesantes en los siguientes paacuterrafos SMART (shared many-to-many ATM reservations)[3] es un protocolo para controlar un aacuterbol ATM multicast compartido soportando comunicaciones muchos-a-muchos (many-to-many) Esta propuesta tiene importantes caracteriacutesticas como que reside completamente en la capa ATM y no requiere ninguacuten servidor soporta uno o varios VCCs (y tambieacuten VPCs) cuyo nuacutemero es libremente configurado y es independiente del nuacutemero de puntos finales usa el concepto de bloques de datos como en la clase de servicio ABT y tambieacuten permite VCCs de las clases CBR VBR o UBR el protocolo garantiza que no existen puntos de interrelacioacuten en los VCC del aacuterbol son respetadas las garantiacuteas del contrato de traacutefico asociado con los VCCs etc SMART puede ser entendido como un protocolo completamente distribuido para coordinar la distribucioacuten de VPIsVCIs 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 ceacutelulas de datos desde diferentes fuentes pueden llegar intercaladas a un destinatario) y tambieacuten Demand Sharing (los recursos asignados a conexiones muchos-a-muchos son dinaacutemicamente compartidas entre todas las potenciales fuentes El artiacuteculo [3] describe el protocolo SMART formal e informalmente y propone completas pruebas de correccioacuten y un detallado anaacutelisis de comportamiento para estudios futuros Tambieacuten son sugeridas otras investigaciones como son ofrecer justicia en los accesos a los aacuterboles multicast investigar las ceacutelulas RM perioacutedicamente para aliviar las congestiones en la red o disminuir el tiempo de acceso del usuario a los aacuterboles de distribucioacuten multicast anaacutelisis de las ceacutelulas RM dentro de cada VCC o fuera enviando todas las ceacutelulas RM en un VCC dedicado En [17] se presenta MWAX un algoritmo dinaacutemico 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 artiacuteculo describe un esquema jeraacuterquico basado en CBT para incorporar routing multipunto-a-multipunto en PNNI En el algoritmo los nodos core actuacutean como participantes pasivos para eliminar la dependencia en la seleccioacuten de estos nodos Con un mecanismo de backup se consigue un algoritmo tolerante a fallos en los nodos core lo cual puede ser faacutecilmente 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 jerarquiacutea SEAM (Scalable and Efficient ATM Multicast) [18] propone una arquitectura escalable eficiente y multicast multipunto-a-multipunto para redes ATM que usa un soacutelo VC para un grupo multicast de muacuteltiples 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 Tambieacuten realiza aportaciones para conseguir soportar IP multicast sobre redes ATM extensas

SEAM usa un soacutelo aacuterbol de distribucioacuten 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 sentildealizacioacuten del grupo Este trabajo deja abiertas investigaciones referentes a la gestioacuten de traacutefico y a la entrega fiable de traacuteficos multicasting Concluimos esta seccioacuten destacando MCMP (Multiparty Conference Management Protocol) [19] que sin estar pensado especiacuteficamente para ATM es un protocolo de nivel sesioacutentransporte distribuido extremo-extremo y desarrollado para gestioacuten de grupos de aplicaciones de conferencia MCMP es un conjunto de algoritmos de control distribuido para configuracioacuten de conferencias multipunto y gestioacuten de miembros de grupos de usuarios Conceptualmente MCMP reside en el nivel de sesioacuten en el que se establece la infraestructura para activar la transferencia de informacioacuten entre los participantes en la conferencia Pero funcionalmente el protocolo acompasa los niveles de sesioacuten y de transporte pues utiliza directamente servicios del nivel de red Son destacables las condiciones de correccioacuten (conectividad validacioacuten unicidad consistencia y terminacioacuten) que deben ser satisfechas una vez que la conferencia ha sido configurada por el algoritmo de configuracioacuten de MCMP El artiacuteculo muestra exhaustivas pruebas de correccioacuten para uno de los algoritmos y tambieacuten describe la especificacioacuten y verificacioacuten del protocolo

5- Nuevos campos de investigacioacutenEn todas las redes existen gran variedad de elementos hardware (switchs routers bridges brouters hubs ETDs etc) que realizan muy diversas funciones (conmutacioacuten routing puenteo controles de congestioacuten y de flujo garantiacutea de QoS ejecucioacuten de aplicaciones etc) En la actualidad la red es mayormente un canal de comunicacioacuten para transferir paquetes entre equipos finales (ayudada por los elementos hardware antes citados) Pero tambieacuten se estaacuten realizando importante esfuerzos para equipar a los elementos hardware con elevadas prestaciones aportadas por diversas teacutecnicas software Esto dota a la red de caracteriacutesticas activas (active networks) en el sentido de que los elementos hardware que la componen computan modifican u operan los contenidos de los paquetes y tambieacuten seraacuten capaces de transferir o propagar coacutedigo Por consiguiente una red activa es una red programable [20] es una excelente revisioacuten de este novedoso campo de investigacioacuten que discute dos planteamientos en la realizacioacuten de redes activas la idea del conmutador programable y la de la caacutepsula Una red es activa si en sus aacuterboles de distribucioacuten multicast existen nodos activos con capacidad para ejecutar programas yo capaces de implementar mecanismos de propagacioacuten de coacutedigo Algunas de las ventajas de los protocolos activos son conseguidas instalando nodos activos en puntos estrateacutegicos de la red Otro nuevo concepto es presentado en [21] como una metodologiacutea para el disentildeo de protocolos Los protocol boosters son una nueva contribucioacuten a las redes activas o programables Una ventaja de los boosters es que pueden ser faacutecilmente 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 aacuterea extensa Este papel introduce una arquitectura software orientada a agente y propone el concepto de agente de comunicacioacuten para servicio de comunicacioacuten 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 artiacuteculo muestra agentes software moacuteviles usados para implementar operaciones robustas y funciones de mantenimiento en redes ATM Los agentes desempentildean un rol similar al de las ceacutelulas OAM en ATM estaacutendar pues son transmitidos entre entidades de control a intervalos regulares usando recursos predefinidos La diferencia entre los agentes moacuteviles y las ceacutelulas OAM reside en que eacutestos pueden contener coacutedigo Para concluir destacar que la integracioacuten del traacutefico IP sobre tecnologiacutea ATM es tambieacuten uno de los campos maacutes activos en la actualidad En esta liacutenea pueden destacarse los siguientes protocolos IP-over-ATM IP Switching Tag Switching NHRP MPOA IMSS CSR ARIS AREQUIPARED y EPD Referencias

1 ____ Native ATM Service Semantic Description Version 1 ATM Forum Technical Committee ATM Forum Document af-saa-0048000 (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 Broadband Networks Multimedia Applications Services and Techniques ECMASTrsquo98 Springer (May 1998)

3 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 Nordm 3 (April 1997)

4 W D Zhong K Yukimatsu Design requeriments and architectures for multicast ATM switching IEICE Trans Com Vol E77-B pp 1420-1428 (Nov 1994)

5 ____ ATM user-network interface version 31 specification ATM Forum (1994)

6 ____ Traffic Management Specification Version 40 ATM Forum Technical Committee ATM Forum Document af-tm-0056000 (April 1996)

7 D Kandlur D Saha and W Willebeck Protocol Architecture for multimedia Application over ATM Networks IEEE Journal Selected and Communications Vol 14 Nordm 7 pp 1349-1359 (Sep 1996)

8 R Ahuja S Keshav and H Saran Design Implementation and Performance Measurement of a Native-Mode ATM Transport Layer (Estended Version) IEEEACM Transactions on Networking Vol 4 Nordm 4 (Aug 1996)

9 R Karabek A Native ATM Protocol Architecture Design and Performance Evaluation IEEE Proceedings 22nd Annual Conference on Local Computer Networks pp 204-210 (1997)

10 D C Feldmeier A framework of architectural concepts for high-speed communications systems IEEE J Select Areas CommunVol11 Nordm 4 (May 1993)

11 T Anker D Breitgand D Dolev Z Levy Congress CONnection-oriented Group-address RESolution Service Proceeding of SPIE97 vol 3233 on Broadband Networking Technologies Nov (1997)

12 kStack httpcometcolumbiaedusoftwarekStack

13 T La Porta and M Schwartz Architectures Features and Implementation of High-Speed Transport Protocols IEEE Network Magazine pp 14-22 (May 1991)

14 ____ B-ISDN ATM Adaptation Layer Service Specific Connection Oriented Protocol (SSCOP) Q2110 ITU-T (10-Mar 1994)

15 J Soleacute-Pareta J Vila-Sallent Network-based paralell computing over ATM using improved SSCOP protocol Computer Communications 19 pp 915-926 (1996)

16 K Obraczka Multicast Transport Protocols A survey and Taxonomy IEEE Communi Magazine (1998)

17 R Venkateswaran CS Raghavendra X Chen and VP Kumar A Scalable Dynamic Multicast Routing Algorithm in ATM Networks IEEE pp 1361-1365 (1997)

18 Matthias Grossglauser and KK Ramakrishnan SEAM Scalable and Efficient ATM Multicast IEEE 1997 pp 867-875 (1997)

19 M Nguyen and M Schwartz MCMP A Transportsession level Distributed Protocol for Desktop Conference Setup IEEE Journal Selected and comunications Vol 14 Nordm 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 Nordm 3 pp 437-443 (April 1998)

22 R Kishimoto Agent communication system for multimedia communication services INFOCOMrsquo96 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 Nordm 3 pp 414-423 (April 1998)

  • ATM - Modo de Transferencia Asiacutencrona
  • Revisioacuten y Clasificacioacuten de Protocolos para Redes de Tecnologiacutea ATM
    • Resumen
    • 1-Introduccioacuten y motivaciones
    • 2- Protocolos nativos ATM
    • 3- Protocolos de transporte para redes ATM
    • 4- Protocolos multipoint
    • 5- Nuevos campos de investigacioacuten
      • Referencias
Page 20: Atm

SEAM usa un soacutelo aacuterbol de distribucioacuten 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 sentildealizacioacuten del grupo Este trabajo deja abiertas investigaciones referentes a la gestioacuten de traacutefico y a la entrega fiable de traacuteficos multicasting Concluimos esta seccioacuten destacando MCMP (Multiparty Conference Management Protocol) [19] que sin estar pensado especiacuteficamente para ATM es un protocolo de nivel sesioacutentransporte distribuido extremo-extremo y desarrollado para gestioacuten de grupos de aplicaciones de conferencia MCMP es un conjunto de algoritmos de control distribuido para configuracioacuten de conferencias multipunto y gestioacuten de miembros de grupos de usuarios Conceptualmente MCMP reside en el nivel de sesioacuten en el que se establece la infraestructura para activar la transferencia de informacioacuten entre los participantes en la conferencia Pero funcionalmente el protocolo acompasa los niveles de sesioacuten y de transporte pues utiliza directamente servicios del nivel de red Son destacables las condiciones de correccioacuten (conectividad validacioacuten unicidad consistencia y terminacioacuten) que deben ser satisfechas una vez que la conferencia ha sido configurada por el algoritmo de configuracioacuten de MCMP El artiacuteculo muestra exhaustivas pruebas de correccioacuten para uno de los algoritmos y tambieacuten describe la especificacioacuten y verificacioacuten del protocolo

5- Nuevos campos de investigacioacutenEn todas las redes existen gran variedad de elementos hardware (switchs routers bridges brouters hubs ETDs etc) que realizan muy diversas funciones (conmutacioacuten routing puenteo controles de congestioacuten y de flujo garantiacutea de QoS ejecucioacuten de aplicaciones etc) En la actualidad la red es mayormente un canal de comunicacioacuten para transferir paquetes entre equipos finales (ayudada por los elementos hardware antes citados) Pero tambieacuten se estaacuten realizando importante esfuerzos para equipar a los elementos hardware con elevadas prestaciones aportadas por diversas teacutecnicas software Esto dota a la red de caracteriacutesticas activas (active networks) en el sentido de que los elementos hardware que la componen computan modifican u operan los contenidos de los paquetes y tambieacuten seraacuten capaces de transferir o propagar coacutedigo Por consiguiente una red activa es una red programable [20] es una excelente revisioacuten de este novedoso campo de investigacioacuten que discute dos planteamientos en la realizacioacuten de redes activas la idea del conmutador programable y la de la caacutepsula Una red es activa si en sus aacuterboles de distribucioacuten multicast existen nodos activos con capacidad para ejecutar programas yo capaces de implementar mecanismos de propagacioacuten de coacutedigo Algunas de las ventajas de los protocolos activos son conseguidas instalando nodos activos en puntos estrateacutegicos de la red Otro nuevo concepto es presentado en [21] como una metodologiacutea para el disentildeo de protocolos Los protocol boosters son una nueva contribucioacuten a las redes activas o programables Una ventaja de los boosters es que pueden ser faacutecilmente 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 aacuterea extensa Este papel introduce una arquitectura software orientada a agente y propone el concepto de agente de comunicacioacuten para servicio de comunicacioacuten 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 artiacuteculo muestra agentes software moacuteviles usados para implementar operaciones robustas y funciones de mantenimiento en redes ATM Los agentes desempentildean un rol similar al de las ceacutelulas OAM en ATM estaacutendar pues son transmitidos entre entidades de control a intervalos regulares usando recursos predefinidos La diferencia entre los agentes moacuteviles y las ceacutelulas OAM reside en que eacutestos pueden contener coacutedigo Para concluir destacar que la integracioacuten del traacutefico IP sobre tecnologiacutea ATM es tambieacuten uno de los campos maacutes activos en la actualidad En esta liacutenea pueden destacarse los siguientes protocolos IP-over-ATM IP Switching Tag Switching NHRP MPOA IMSS CSR ARIS AREQUIPARED y EPD Referencias

1 ____ Native ATM Service Semantic Description Version 1 ATM Forum Technical Committee ATM Forum Document af-saa-0048000 (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 Broadband Networks Multimedia Applications Services and Techniques ECMASTrsquo98 Springer (May 1998)

3 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 Nordm 3 (April 1997)

4 W D Zhong K Yukimatsu Design requeriments and architectures for multicast ATM switching IEICE Trans Com Vol E77-B pp 1420-1428 (Nov 1994)

5 ____ ATM user-network interface version 31 specification ATM Forum (1994)

6 ____ Traffic Management Specification Version 40 ATM Forum Technical Committee ATM Forum Document af-tm-0056000 (April 1996)

7 D Kandlur D Saha and W Willebeck Protocol Architecture for multimedia Application over ATM Networks IEEE Journal Selected and Communications Vol 14 Nordm 7 pp 1349-1359 (Sep 1996)

8 R Ahuja S Keshav and H Saran Design Implementation and Performance Measurement of a Native-Mode ATM Transport Layer (Estended Version) IEEEACM Transactions on Networking Vol 4 Nordm 4 (Aug 1996)

9 R Karabek A Native ATM Protocol Architecture Design and Performance Evaluation IEEE Proceedings 22nd Annual Conference on Local Computer Networks pp 204-210 (1997)

10 D C Feldmeier A framework of architectural concepts for high-speed communications systems IEEE J Select Areas CommunVol11 Nordm 4 (May 1993)

11 T Anker D Breitgand D Dolev Z Levy Congress CONnection-oriented Group-address RESolution Service Proceeding of SPIE97 vol 3233 on Broadband Networking Technologies Nov (1997)

12 kStack httpcometcolumbiaedusoftwarekStack

13 T La Porta and M Schwartz Architectures Features and Implementation of High-Speed Transport Protocols IEEE Network Magazine pp 14-22 (May 1991)

14 ____ B-ISDN ATM Adaptation Layer Service Specific Connection Oriented Protocol (SSCOP) Q2110 ITU-T (10-Mar 1994)

15 J Soleacute-Pareta J Vila-Sallent Network-based paralell computing over ATM using improved SSCOP protocol Computer Communications 19 pp 915-926 (1996)

16 K Obraczka Multicast Transport Protocols A survey and Taxonomy IEEE Communi Magazine (1998)

17 R Venkateswaran CS Raghavendra X Chen and VP Kumar A Scalable Dynamic Multicast Routing Algorithm in ATM Networks IEEE pp 1361-1365 (1997)

18 Matthias Grossglauser and KK Ramakrishnan SEAM Scalable and Efficient ATM Multicast IEEE 1997 pp 867-875 (1997)

19 M Nguyen and M Schwartz MCMP A Transportsession level Distributed Protocol for Desktop Conference Setup IEEE Journal Selected and comunications Vol 14 Nordm 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 Nordm 3 pp 437-443 (April 1998)

22 R Kishimoto Agent communication system for multimedia communication services INFOCOMrsquo96 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 Nordm 3 pp 414-423 (April 1998)

  • ATM - Modo de Transferencia Asiacutencrona
  • Revisioacuten y Clasificacioacuten de Protocolos para Redes de Tecnologiacutea ATM
    • Resumen
    • 1-Introduccioacuten y motivaciones
    • 2- Protocolos nativos ATM
    • 3- Protocolos de transporte para redes ATM
    • 4- Protocolos multipoint
    • 5- Nuevos campos de investigacioacuten
      • Referencias
Page 21: Atm

Protocol Stack for Internet Applications in Residential Broadband Networks Multimedia Applications Services and Techniques ECMASTrsquo98 Springer (May 1998)

3 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 Nordm 3 (April 1997)

4 W D Zhong K Yukimatsu Design requeriments and architectures for multicast ATM switching IEICE Trans Com Vol E77-B pp 1420-1428 (Nov 1994)

5 ____ ATM user-network interface version 31 specification ATM Forum (1994)

6 ____ Traffic Management Specification Version 40 ATM Forum Technical Committee ATM Forum Document af-tm-0056000 (April 1996)

7 D Kandlur D Saha and W Willebeck Protocol Architecture for multimedia Application over ATM Networks IEEE Journal Selected and Communications Vol 14 Nordm 7 pp 1349-1359 (Sep 1996)

8 R Ahuja S Keshav and H Saran Design Implementation and Performance Measurement of a Native-Mode ATM Transport Layer (Estended Version) IEEEACM Transactions on Networking Vol 4 Nordm 4 (Aug 1996)

9 R Karabek A Native ATM Protocol Architecture Design and Performance Evaluation IEEE Proceedings 22nd Annual Conference on Local Computer Networks pp 204-210 (1997)

10 D C Feldmeier A framework of architectural concepts for high-speed communications systems IEEE J Select Areas CommunVol11 Nordm 4 (May 1993)

11 T Anker D Breitgand D Dolev Z Levy Congress CONnection-oriented Group-address RESolution Service Proceeding of SPIE97 vol 3233 on Broadband Networking Technologies Nov (1997)

12 kStack httpcometcolumbiaedusoftwarekStack

13 T La Porta and M Schwartz Architectures Features and Implementation of High-Speed Transport Protocols IEEE Network Magazine pp 14-22 (May 1991)

14 ____ B-ISDN ATM Adaptation Layer Service Specific Connection Oriented Protocol (SSCOP) Q2110 ITU-T (10-Mar 1994)

15 J Soleacute-Pareta J Vila-Sallent Network-based paralell computing over ATM using improved SSCOP protocol Computer Communications 19 pp 915-926 (1996)

16 K Obraczka Multicast Transport Protocols A survey and Taxonomy IEEE Communi Magazine (1998)

17 R Venkateswaran CS Raghavendra X Chen and VP Kumar A Scalable Dynamic Multicast Routing Algorithm in ATM Networks IEEE pp 1361-1365 (1997)

18 Matthias Grossglauser and KK Ramakrishnan SEAM Scalable and Efficient ATM Multicast IEEE 1997 pp 867-875 (1997)

19 M Nguyen and M Schwartz MCMP A Transportsession level Distributed Protocol for Desktop Conference Setup IEEE Journal Selected and comunications Vol 14 Nordm 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 Nordm 3 pp 437-443 (April 1998)

22 R Kishimoto Agent communication system for multimedia communication services INFOCOMrsquo96 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 Nordm 3 pp 414-423 (April 1998)

  • ATM - Modo de Transferencia Asiacutencrona
  • Revisioacuten y Clasificacioacuten de Protocolos para Redes de Tecnologiacutea ATM
    • Resumen
    • 1-Introduccioacuten y motivaciones
    • 2- Protocolos nativos ATM
    • 3- Protocolos de transporte para redes ATM
    • 4- Protocolos multipoint
    • 5- Nuevos campos de investigacioacuten
      • Referencias
Page 22: Atm

16 K Obraczka Multicast Transport Protocols A survey and Taxonomy IEEE Communi Magazine (1998)

17 R Venkateswaran CS Raghavendra X Chen and VP Kumar A Scalable Dynamic Multicast Routing Algorithm in ATM Networks IEEE pp 1361-1365 (1997)

18 Matthias Grossglauser and KK Ramakrishnan SEAM Scalable and Efficient ATM Multicast IEEE 1997 pp 867-875 (1997)

19 M Nguyen and M Schwartz MCMP A Transportsession level Distributed Protocol for Desktop Conference Setup IEEE Journal Selected and comunications Vol 14 Nordm 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 Nordm 3 pp 437-443 (April 1998)

22 R Kishimoto Agent communication system for multimedia communication services INFOCOMrsquo96 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 Nordm 3 pp 414-423 (April 1998)

  • ATM - Modo de Transferencia Asiacutencrona
  • Revisioacuten y Clasificacioacuten de Protocolos para Redes de Tecnologiacutea ATM
    • Resumen
    • 1-Introduccioacuten y motivaciones
    • 2- Protocolos nativos ATM
    • 3- Protocolos de transporte para redes ATM
    • 4- Protocolos multipoint
    • 5- Nuevos campos de investigacioacuten
      • Referencias