Figura 1.- Diagrama simplificado del proceso ATM
En la Figura 1 se ilustra la forma en que diferentes flujos de información, de características distintas en cuanto a velocidad y formato, son agrupados en el denominado Módulo ATM para ser transportados mediante grandes enlaces de transmisión a velocidades (bit rate) de 155 o 622 Mbit/s facilitados generalmente por sistemas SDH.
En el terminal transmisor, la información es escrita byte a byte en el campo de información de usuario de la celda y a continuación se le añade la cabecera.
En el extremo distante, el receptor extrae la información, también byte a byte, de las celdas entrantes y de acuerdo con la información de cabecera, la envía donde ésta le indique, pudiendo ser un equipo terminal u otro módulo ATM para ser encaminada a otro destino. En caso de haber más de un camino entre los puntos de origen y destino, no todas las celdas enviadas durante el tiempo de conexión de un usuario serán necesariamente encaminadas por la misma ruta, ya que en ATM todas las conexiones funcionan sobre una base virtual.
PROTOCOLOS NATIVOS ATM
Las aplicaciones nativas ATM están específicamente pensadas para usar la tecnología ATM y para explotar al máximo sus especiales características. Los protocolos nativos se encargan, por tanto, de ofrecer esas características intrínsecas de las redes de tecnología ATM (soporte de QoS, señalización, direccionamiento, etc.) a las aplicaciones nativas ATM (VoD, pizarras compartidas, video-conferencia...). No obstante, existen también activas investigaciones para conseguir soportar sobre redes ATM aplicaciones no nativas ATM desarrolladas para otras tecnologías (IP, Frame Relay, SMDS...).
En [1], el termino native ATM services define servicios ATM específicos 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 adaptación (AALs).
* Disponibilidad de circuitos virtuales conmutados (SVCs) y circuitos virtuales permanentes (PVCs).
* Consideraciones relativas a la gestión de tráfico (clases de servicio, garantías de QoS, etc.).
* Posibilidad de distribución de conexiones y de participación local en la administración de la red (protocolos ILMI y OAM).
El propósito de los servicios nativos ATM es ofrecer el acceso a las clases de servicio o a las características de QoS en redes ATM. Estos servicios nativos también ofrecen soporte a un amplio y heterogéneo rango de flujos con diversas propiedades y requerimientos recomendados en [1] .
Los protocolos de transferencia nativos ATM gestionan la señalización UNI para establecer los SVCs, configurar PVCs y mapear los perfiles de QoS en la correspondiente clase de servicio. Los protocolos nativos también realizan funciones clásicas como las de transporte, mecanismos de control de errores, transferencia de datos, y controles de flujo y de congestión.
En la referencia [1] se especifica la definición semántica de los servicios y consideramos que es útil contrastar esta semántica 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 múltiples conexiones de transporte con distintos requerimientos de QoS en VCs simples.
* TCP no soporta células RM (Resource Management) ABR y por consiguiente no puede usar directamente las garantías de QoS ofrecidas por la red.
* ATM Adaptation Layer 5 (AAL5) realiza labores de checksum para detectar corrupción de datos. TCP también realiza estas labores (redundantes con AAL5) costosas en overhead (cada byte de un paquete debe ser chequeado).
* TCP/IP son la representación de un grupo de protocolos bastante más 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]. Además, 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 tecnología ATM y también existen antiguas y no nativas aplicaciones. Este escenario implica cambiar las aplicaciones o proponer nuevas pilas de protocolos nativos ATM.
* La encapsulación consecutiva de paquetes genera problemas de overhead y funciones redundantes como se ha argumentado anteriormente.
* La limitación de recursos en los sistemas finales es otra importante motivación 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 públicos disfrutan también de estas ventajas.
* ATM, RDSI y la telefonía ofrecen un esquema de direccionamiento universal basado en NSAP/E.164 el cual es capaz de enrutar tráfico de forma nativa. Por tanto, aunque ATM dispone de protocolos nativos con direccionamiento intrínceso estructurado y jerárquico, éste no es aprovechado por las aplicaciones que están 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 también existen importantes investigaciones en torno a los protocolos nativos ATM. En esta sección se muestran las propuestas más importantes y actuales en materia de protocolos nativos ATM[2], [7], [8], [9], [10], [11], [12] que, a su vez,están sirviendo de base para nuevas investigaciones.
presentan el diseño, implementación y comportamiento de una pila en modo nativo ATM y contrasta la semántica 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 automáticamente los siguientes problemas:
* IP-over-ATM no ofrece garantía de QoS pues sus aplicaciones sólo "ven" la interfaz IP.
* El núcleo 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 señalización.
* 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 características, la entrega fiable y no fiable de datos con control de flujo. Este protocolo de transporte es ampliado en la sección 5.
[2] presenta N3 (Native Non-broadcasting medium access Networking) un protocolo de transporte ligero y nativo ATM. La pila N3 se ha diseñado 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, además, 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 (Fig.2).
El protocolo de transporte ATM propuesto en [2] ofrece soporte para tres diferentes tipos de servicio: entrega garantizada (mecanismos de retransmisión), 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 congestión de la transferencia de datagramas y de la multiplexación 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 más importante. El Flow Management se responsabiliza de manipular los flujos de datos desde y hasta la red vía la interfaz AAL. La segmentación, el reensamblado y el control de errores es también 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 congestión y de flujo extremo-extremo más complejo.
describe la semántica de una pila de protocolos y explora una nueva arquitectura de protocolo adaptada a la tecnología ATM y a las aplicaciones multimedia. El diseño está basado en tres principios básicos: separación de flujos de control y de datos; minimización del overhead y de la duplicidad de funciones; y acceso de las aplicaciones al nivel ATM con garantías 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 módulo CNTL abre una conexión de señalización con el dispositivo ATM y establece una gestión de las llamadas de mensajes de configuración.
PF_ATM separa flujos de datos y de control para aliviar el límite de comportamiento en las comunicaciones. Esto permite a los mecanismos de control de tráfico ser rápidos y sencillos, mientras los mecanismos de control pueden ser tan complicados como sea necesario. Esta separación permite también que los dispositivos puedan estar en los puntos finales de una conexión.
La interfaz PF_ATM da a las aplicaciones acceso directo a la capa de enlace ATM y extiende las garantías de QoS a los puntos extremos de la comunicación.
Un segundo prototipo[7] es diseñado e implementado con dos objetivos principales en la optimización de la pila nativa ATM:
* Optimizar los caminos de datos entre los adaptadores ATM aprovechando la separación de flujos de control y de datos y la capacidad de gestión de datos específicos de las conexiones de la pila ATM.
* Optimizar el procesamiento de overheads usando una pila de protocolos nativo ATM en lugar de UDP/IP.
[11] introduce CONGRESS (CONnection oriented Group-address RESolution Service), otro eficiente protocolo nativo ATM para la resolución y gestión 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 diseño basado en los dos siguientes principios:
* Diseño jerárquico: los servicios del protocolo son ofrecidos a las aplicaciones por múltiples servidores organizados jerárquicamente.
* No inundación: se evita la inundación 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 implementación sobre Unix y Windows NT está basada y es compatible con los trabajos originales de Ahuja, Keshav y Saran [8] Native-Mode ATM Stack comentados anteriormente. El protocolo kStack es similar al original, pero se ha modificado sustancialmente en aspectos como su implementacion en el espacio de usuario, se ha ampliado implementando una capa de transporte con QoS y se ha añadido un módulo que monitoria la QoS extremo-a-extremo.
No comments:
Post a Comment