Wednesday, January 30, 2008
REDES ATM - RESUMEN GENERAL
La tecnología ATM (Asynchronous Transfer Mode) continúa evolucionando y siendo fuente de interesantes y novedosas propuestas. El desarrollo de avanzados protocolos de comunicaciones es uno de los campos de investigación más activo, con la aspiración de ofrecer el adecuado soporte a las nuevas aplicaciones adaptadas a las clases de servicio nativas ATM. En este contexto son aspectos clave los relativos a los protocolos nativos ATM, así como las características multicast, la escalabilidad y la fiabilidad. Se profundiza en el concepto de protocolo nativo ATM y son introducidos los protocolos más importantes que satisfacen este importante requerimiento (N3, CONGRESS y kStack, entre otros). Es importante destacar también los protocolos de transporte pensados específicamente para la tecnología ATM. La característica multicast (multipoint-to-multipoint) es una de las que más esfuerzo está costando garantizar a ATM, pero existen ya propuestas que permiten la comunicación fiable a elevados anchos de banda y entre múltiples emisores y receptores (SMART, MCMP o MWAX). El artículo concluye con las investigacioness más novedosas en torno a los protocolos ATM como las iniciativas que proponen redes ATM programables o activas (active networks) usando agentes móviles.
1. INTRODUCCIÓN Y MOTIVACIONES
La actual demanda de aplicaciones relacionadas con información 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 más clásicas (bases de datos, transferencias de ficheros, WWW, etc.), requiere tecnologías de comunicaciones capaces de ofrecer elevadas prestaciones. Estas elevadas prestaciones están directamente relacionadas con la calidad de servicio (QoS) y concretamente con conceptos claramente parametrizables como el ancho de banda y la velocidad de transmisión (throughput), el retardo de las transferencias (delay); la variabilidad en el retardo (jitter); la fiabilidad (reliability) de las transmisiones; las características de multidifusión a grupos dispersos de usuarios (multicast) y la posibilidad de gestionar múltiples clases de servicio o flujos de información en redes multiclass.
Para que las nuevas tecnologías en comunicaciones puedan ofrecer estas características es necesario revisar, potenciar y ampliar las actuales arquitecturas, servicios y protocolosde comunicaciones. En los últimos dos o tres años, las investigaciones en el campo de ATM están dado lugar a importantes propuestas cuyo principal objetivo es ofrecer a las aplicaciones demandadas actualmente algunas o todas las características citadas anteriormente.
Presentamos en este trabajo los conceptos y propuestas más novedosas en el contexto de ATM para ayudar al lector interesado en el dinámico, complejo y sofisticado campo de los protocolos de comunicaciones. Realizamos la revisión de algunos de los más importantes conceptos, técnicas, ideas y mecanismos en protocolos de altas prestaciones para redes de tecnología ATM. El principal objetivo de este documento es ofrecer una actualizada visión general, no extensiva ni profunda, de los protocolos propuestos y en desarrollo para dotar a las diversas clases de servicio ATM de las citadas características de calidad de servicio que aporten las potenciales elevadas prestaciones que la tecnología ATM es capaz de ofrecer.
El resto del documento está estructurado de la siguiente forma. La sección 2 revisa el concepto de protocolo nativo centrado en el contexto de las redes ATM. La sección 3 describe las propuestas más interesantes actualmente en materia de protocolos de transporte. El apartado 4 comenta las transferencias multicast como un importante objetivo para una tecnología orientada a la conexión como es ATM. Concluimos en la sección 5 con los campos de investigación abiertos recientemente como son las redes activas y los procolos booster.
Para que las nuevas tecnologías en comunicaciones puedan ofrecer estas características es necesario revisar, potenciar y ampliar las actuales arquitecturas, servicios y protocolosde comunicaciones. En los últimos dos o tres años, las investigaciones en el campo de ATM están dado lugar a importantes propuestas cuyo principal objetivo es ofrecer a las aplicaciones demandadas actualmente algunas o todas las características citadas anteriormente.
Presentamos en este trabajo los conceptos y propuestas más novedosas en el contexto de ATM para ayudar al lector interesado en el dinámico, complejo y sofisticado campo de los protocolos de comunicaciones. Realizamos la revisión de algunos de los más importantes conceptos, técnicas, ideas y mecanismos en protocolos de altas prestaciones para redes de tecnología ATM. El principal objetivo de este documento es ofrecer una actualizada visión general, no extensiva ni profunda, de los protocolos propuestos y en desarrollo para dotar a las diversas clases de servicio ATM de las citadas características de calidad de servicio que aporten las potenciales elevadas prestaciones que la tecnología ATM es capaz de ofrecer.
El resto del documento está estructurado de la siguiente forma. La sección 2 revisa el concepto de protocolo nativo centrado en el contexto de las redes ATM. La sección 3 describe las propuestas más interesantes actualmente en materia de protocolos de transporte. El apartado 4 comenta las transferencias multicast como un importante objetivo para una tecnología orientada a la conexión como es ATM. Concluimos en la sección 5 con los campos de investigación abiertos recientemente como son las redes activas y los procolos booster.
2. Historia de ATM
La primera referencia del ATM (Asynchronous Transfer Mode) tiene lugar en los años 60 cuando un norteamericano de origen oriental perteneciente a los laboratorios Bell describió y patentó un modo de transferencia no síncrono. Sin embargo el ATM no se hizo popular hasta 1988 cuando el CCITT decidió que sería la tecnología de conmutación de las futuras redes ISDN en banda ancha (rec I.121). Para ello, los valedores del ATM tuvieron primero que persuadir a algunos representantes de las redes de comunicaciones que hubieran preferido una simple ampliación de las capacidades de la ISDN en banda estrecha. Conseguido este primer objetivo y desechando los esquemas de transmisión síncronos, se empezaron a discutir aspectos tales como el tamaño de las celdas. Por un lado los representantes de EEUU y algún otro país proponían un tamaño de celdas grande de unos 128 bytes. Sin embargo para los representantes de los países europeos el tamaño ideal de las celdas era de 16 bytes, y señalaban que un tamaño de celda de 128 bytes provocaría retardos inaceptables de hasta 85 ms. Este retardo no permitiría la transmisión de voz con cierto nivel de calidad a la vez que obligaba a instalar canceladores de eco. Después de muchas discusiones y ante la falta de acuerdo, en la reunión del CCITT celebrada en Ginebra en Junio de 1989 se tomó una decisión salomónica: “Ni para unos ni para otros. 48 bytes será el tamaño de la celda”. Para la cabecera se tomó un tamaño de 5 bytes. Un extraño número primo 53 (48+5) sería el tamaño definitivo, en octetos, de las células ATM. Un número que tuvo la virtud de no satisfacer a nadie, pero que suponía un compromiso de todos los grupos de interés y evitaba una ruptura de consecuencias imprevisibles.
3. Principios de funcionamiento
Con esta tecnología, a fin de aprovechar al máximo la capacidad de los sistemas de transmisión, sean estos de cable o radioeléctricos, la información no es transmitida y conmutada a través de canales asignados en permanencia, sino en forma de cortos paquetes (celdas ATM) de longitud constante y que pueden ser enrutadas individualmente mediante el uso de los denominados canales virtuales y trayectos virtuales.
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.
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.
4. Protocolos de transporte para redes ATM
En los dos o tres últimos años ha habido numerosos e interesante intentos por diseñar protocolos de transporte. La referencia [10] presenta un completo y, ya clásico, resumen de las propuestas más interesantes en materia de protocolos de transporte para redes de alta velocidad (mayoritariamente IP en el artículo). Además, la referencia [13] ofrece una interesante visión de las características más importantes en los protocolos de elevada velocidad. Son estudiadas también diversas arquitecturas de protocolos y varias técnicas de implementación. Los protocolos de transporte de elevada velocidad son fuente de activas investigaciones y están en constante evolución desde hace más de dos décadas, lo que impide ser exhaustivo en este resumen: no citamos todos los protocolos, ni presentamos todos los conceptos ni podemos analizar todas las soluciones.
Uno de los componentes del ámbito de las comunicaciones que ha recibido mayor atención es la capa de transporte, la cuarta capa del OSI-RM de los protocolos de comunicaciones. TCP e ISO TP4 son los dos más populares protocolos de transporte. Pero centrándonos más concretamente en el ámbito de ATM, la literatura presenta varios protocolos de transporte y arquitecturas para redes de alta velocidad revisadas resumidamente a continuación.
[7] ofrece una excelente y didáctica arquitectura de pila de protocolos para aplicaciones multimedia en modo nativo ATM. Esta arquitectura de protocolo ha sido ya descrita brevemente en la sección anterior.
[8] presentan el diseño, implementación y comportamiento de un protocolo situado en la capa de transporte ATM. Esta es una interesante propuesta en la que se puede destacar que la pila ATM está formada por tres entidades principales: aplicación, señalización y transporte.
La siguiente Tabla 1 muestra un conjunto de nueve básicos 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 combinación de servicios. La marca X indica el servicio básico soportado en cada clase de servicio general.
resuelve el problema de soportar HPDC (High Performance Distributed Computing) sobre redes ATM. Los autores sugieren modificaciones en los mecanismos de recuperación de pérdidas del protocolo estándar SSCOP [14] y demuestran que el resultado ofrece baja latencia, eficiente recuperación de células perdidas y es tan robusto como el estándar SSCOP.
PROTOCOLOS MULTIPOINT
El crecimiento de las redes ATM viene motivado, en parte, por la demanda de servicios multimedia para grupos dispersos de usuarios. El tráfico multicast tiene características particulares descritas para ATM en UNI 4.0 [6] y anteriores [5]. La distribución de información punto-a-multipunto (uno-a-muchos) o multipunto-a-multipunto (muchos-a-muchos) es un objetivo básico propuesto por varios protocolos y arquitecturas ATM que ofrecen el soporte multimedia y/o multicast como audio-conferencia, video-conferencia, trabajos colaborativos o VoD.
ATM es aún una tecnología emergente diseñada para ser usada por aplicaciones de datos, audio y video, lo que requiere un buen comportamiento de las transferencias unicast y multicast. User Network Interface (UNI 3.0) para ATM define conexiones punto-a-multipunto, y las conexiones multipunto-a-multipunto sólo 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 topología completamente mallada todos-con-todos. Aunque esta topología ofrece conexiones multipunto-a-multipunto, hay que destacar que no escala bien cuando el número de participantes es elevado.
* Una alternativa al anterior esquema es el uso de un servidor que actúa a modo de raíz en el árbol multipunto. Este método sólo requiere un nodo raíz para almacenar información, pero la desventaja de este método son las potenciales congestiones en el servidor cuando debe encargarse de envíos y retransmisiones de las conexiones multipunto-a-multipunto.
Para solventar las limitaciones de UNI 3.0 y UNI 3.1 [5] que soportan conexiones uno-a-muchos, pero no directamente (nativamente) conexiones muchos-a-muchos, y ofrecer a ATM verdadero servicio multicast, ATM Forum, ITU-T e IETF han realizado varias propuestas al actual mecanismo de señalización ATM (UNI 3.1, UNI 4.0), [4],[5],[6].
Comenzamos destacando la referencia [16] como un reciente trabajo que revisa y compara los protocolos de transporte multicast más importantes en Internet como MTP-2, XTP, RTP, SRM, RAMP, RMTP, MFTP, STORM, etc.. IETF e IRTF (como ITU-T y ATM Forum) también impulsan una importante actividad en este campo. La referencia [16] revisa los más representativos protocolos multicast y los clasifica de acuerdo a la taxonomía de varias características (propagación de datos, mecanismos de fiabilidad, retransmisiones, control de congestión y de flujo, gestión de grupos multicast, etc.). En Internet los mecanismos efectivos de control de congestión son una de las prioridades en las investigaciones de las transferencias multicast fiables. Los mecanismos de seguridad y las técnicas escalables de recuperación 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 más importantes características. En esta sección 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 más interesantes en los siguientes párrafos.
SMART (shared many-to-many ATM reservations)[3] es un protocolo para controlar un árbol ATM multicast compartido soportando comunicaciones muchos-a-muchos (many-to-many). Esta propuesta tiene importantes características como que: reside completamente en la capa ATM y no requiere ningún servidor; soporta uno o varios VCCs (y también VPCs) cuyo número es libremente configurado y es independiente del número de puntos finales; usa el concepto de bloques de datos como en la clase de servicio ABT y también permite VCCs de las clases CBR, VBR o UBR; el protocolo garantiza que no existen puntos de interrelación en los VCC del árbol; son respetadas las garantías del contrato de tráfico asociado con los VCCs, etc. SMART puede ser entendido como un protocolo completamente distribuido para coordinar la distribución de VPIs/VCIs.
Para solventar las conocidas dificultades debidas al soporte y uso de muchos-a-muchos VCCs, SMART usa el mecanismo de Cell Interleaving (sobre un VCC muchos-a-muchos, las células de datos desde diferentes fuentes pueden llegar intercaladas a un destinatario) y también Demand Sharing (los recursos asignados a conexiones muchos-a-muchos son dinámicamente compartidas entre todas las potenciales fuentes.
El artículo [3] describe el protocolo SMART formal e informalmente, y propone completas pruebas de corrección y un detallado análisis de comportamiento para estudios futuros. También son sugeridas otras investigaciones como son: ofrecer justicia en los accesos a los árboles multicast; investigar las células RM periódicamente para aliviar las congestiones en la red o disminuir el tiempo de acceso del usuario a los árboles de distribución multicast; análisis de las células RM dentro de cada VCC o fuera enviando todas las células RM en un VCC dedicado.
En [17] se presenta MWAX un algoritmo dinámico 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 artículo describe un esquema jerárquico basado en CBT para incorporar routing multipunto-a-multipunto en PNNI. En el algoritmo los nodos core actúan como participantes pasivos para eliminar la dependencia en la selección de estos nodos. Con un mecanismo de backup se consigue un algoritmo tolerante a fallos en los nodos core, lo cual puede ser fácilmente 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 jerarquía.
SEAM (Scalable and Efficient ATM Multicast) [18] propone una arquitectura escalable, eficiente y multicast multipunto-a-multipunto para redes ATM que usa un sólo VC para un grupo multicast de múltiples 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. También realiza aportaciones para conseguir soportar IP multicast sobre redes ATM extensas.
SEAM usa un sólo árbol de distribución 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 señalización del grupo. Este trabajo deja abiertas investigaciones referentes a la gestión de tráfico y a la entrega fiable de tráficos multicasting.
Concluimos esta sección destacando MCMP (Multiparty Conference Management Protocol) [19] que, sin estar pensado específicamente para ATM, es un protocolo de nivel sesión/transporte distribuido extremo-extremo y desarrollado para gestión de grupos de aplicaciones de conferencia. MCMP es un conjunto de algoritmos de control distribuido para configuración de conferencias multipunto y gestión de miembros de grupos de usuarios.
Conceptualmente, MCMP reside en el nivel de sesión en el que se establece la infraestructura para activar la transferencia de información entre los participantes en la conferencia. Pero funcionalmente, el protocolo acompasa los niveles de sesión y de transporte pues utiliza directamente servicios del nivel de red. Son destacables las condiciones de corrección (conectividad, validación, unicidad, consistencia y terminación) que deben ser satisfechas una vez que la conferencia ha sido configurada por el algoritmo de configuración de MCMP. El artículo muestra exhaustivas pruebas de corrección para uno de los algoritmos, y también describe la especificación y verificación del protocolo.
5.- Nuevos campos de investigación
En todas las redes existen gran variedad de elementos hardware (switchs, routers, bridges, brouters, hubs, ETDs, etc.) que realizan muy diversas funciones (conmutación, routing, puenteo, controles de congestión y de flujo, garantía de QoS, ejecución de aplicaciones, etc.). En la actualidad la red es mayormente un canal de comunicación para transferir paquetes entre equipos finales (ayudada por los elementos hardware antes citados). Pero también se están realizando importante esfuerzos para equipar a los elementos hardware con elevadas prestaciones aportadas por diversas técnicas software. Esto dota a la red de características activas (active networks) en el sentido de que los elementos hardware que la componen computan, modifican u operan los contenidos de los paquetes y también serán capaces de transferir o propagar código. Por consiguiente, una red activa es una red programable.
[20] es una excelente revisión de este novedoso campo de investigación que discute dos planteamientos en la realización de redes activas, la idea del conmutador programable y la de la cápsula. Una red es activa si en sus árboles de distribución multicast existen nodos activos con capacidad para ejecutar programas y/o capaces de implementar mecanismos de propagación de código. Algunas de las ventajas de los protocolos activos son conseguidas instalando nodos activos en puntos estratégicos de la red.
Otro nuevo concepto es presentado en [21] como una metodología para el diseño de protocolos. Los protocol boosters son una nueva contribución a las redes activas o programables. Una ventaja de los boosters es que pueden ser fácilmente "inyectados" en los sistemas actuales sin provocar cambios en la infraestructura de red.
Por otro lado, [22] propone el concepto de agente de comunicaciones para servicios de comunicaciones multimedia en redes de área extensa. Este papel introduce una arquitectura software orientada a agente y propone el concepto de agente de comunicación para servicio de comunicación 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 artículo muestra agentes software móviles usados para implementar operaciones robustas y funciones de mantenimiento en redes ATM. Los agentes desempeñan un rol similar al de las células OAM en ATM estándar, pues son transmitidos entre entidades de control a intervalos regulares usando recursos predefinidos. La diferencia entre los agentes móviles y las células OAM reside en que éstos pueden contener código. Para concluir destacar que la integración del tráfico IP sobre tecnología ATM es también uno de los campos más activos en la actualidad. En esta línea pueden destacarse los siguientes protocolos: IP-over-ATM, IP Switching, Tag Switching, NHRP, MPOA, IMSS, CSR, ARIS AREQUIPA,RED y EPD.
Uno de los componentes del ámbito de las comunicaciones que ha recibido mayor atención es la capa de transporte, la cuarta capa del OSI-RM de los protocolos de comunicaciones. TCP e ISO TP4 son los dos más populares protocolos de transporte. Pero centrándonos más concretamente en el ámbito de ATM, la literatura presenta varios protocolos de transporte y arquitecturas para redes de alta velocidad revisadas resumidamente a continuación.
[7] ofrece una excelente y didáctica arquitectura de pila de protocolos para aplicaciones multimedia en modo nativo ATM. Esta arquitectura de protocolo ha sido ya descrita brevemente en la sección anterior.
[8] presentan el diseño, implementación y comportamiento de un protocolo situado en la capa de transporte ATM. Esta es una interesante propuesta en la que se puede destacar que la pila ATM está formada por tres entidades principales: aplicación, señalización y transporte.
La siguiente Tabla 1 muestra un conjunto de nueve básicos 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 combinación de servicios. La marca X indica el servicio básico soportado en cada clase de servicio general.
resuelve el problema de soportar HPDC (High Performance Distributed Computing) sobre redes ATM. Los autores sugieren modificaciones en los mecanismos de recuperación de pérdidas del protocolo estándar SSCOP [14] y demuestran que el resultado ofrece baja latencia, eficiente recuperación de células perdidas y es tan robusto como el estándar SSCOP.
PROTOCOLOS MULTIPOINT
El crecimiento de las redes ATM viene motivado, en parte, por la demanda de servicios multimedia para grupos dispersos de usuarios. El tráfico multicast tiene características particulares descritas para ATM en UNI 4.0 [6] y anteriores [5]. La distribución de información punto-a-multipunto (uno-a-muchos) o multipunto-a-multipunto (muchos-a-muchos) es un objetivo básico propuesto por varios protocolos y arquitecturas ATM que ofrecen el soporte multimedia y/o multicast como audio-conferencia, video-conferencia, trabajos colaborativos o VoD.
ATM es aún una tecnología emergente diseñada para ser usada por aplicaciones de datos, audio y video, lo que requiere un buen comportamiento de las transferencias unicast y multicast. User Network Interface (UNI 3.0) para ATM define conexiones punto-a-multipunto, y las conexiones multipunto-a-multipunto sólo 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 topología completamente mallada todos-con-todos. Aunque esta topología ofrece conexiones multipunto-a-multipunto, hay que destacar que no escala bien cuando el número de participantes es elevado.
* Una alternativa al anterior esquema es el uso de un servidor que actúa a modo de raíz en el árbol multipunto. Este método sólo requiere un nodo raíz para almacenar información, pero la desventaja de este método son las potenciales congestiones en el servidor cuando debe encargarse de envíos y retransmisiones de las conexiones multipunto-a-multipunto.
Para solventar las limitaciones de UNI 3.0 y UNI 3.1 [5] que soportan conexiones uno-a-muchos, pero no directamente (nativamente) conexiones muchos-a-muchos, y ofrecer a ATM verdadero servicio multicast, ATM Forum, ITU-T e IETF han realizado varias propuestas al actual mecanismo de señalización ATM (UNI 3.1, UNI 4.0), [4],[5],[6].
Comenzamos destacando la referencia [16] como un reciente trabajo que revisa y compara los protocolos de transporte multicast más importantes en Internet como MTP-2, XTP, RTP, SRM, RAMP, RMTP, MFTP, STORM, etc.. IETF e IRTF (como ITU-T y ATM Forum) también impulsan una importante actividad en este campo. La referencia [16] revisa los más representativos protocolos multicast y los clasifica de acuerdo a la taxonomía de varias características (propagación de datos, mecanismos de fiabilidad, retransmisiones, control de congestión y de flujo, gestión de grupos multicast, etc.). En Internet los mecanismos efectivos de control de congestión son una de las prioridades en las investigaciones de las transferencias multicast fiables. Los mecanismos de seguridad y las técnicas escalables de recuperación 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 más importantes características. En esta sección 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 más interesantes en los siguientes párrafos.
SMART (shared many-to-many ATM reservations)[3] es un protocolo para controlar un árbol ATM multicast compartido soportando comunicaciones muchos-a-muchos (many-to-many). Esta propuesta tiene importantes características como que: reside completamente en la capa ATM y no requiere ningún servidor; soporta uno o varios VCCs (y también VPCs) cuyo número es libremente configurado y es independiente del número de puntos finales; usa el concepto de bloques de datos como en la clase de servicio ABT y también permite VCCs de las clases CBR, VBR o UBR; el protocolo garantiza que no existen puntos de interrelación en los VCC del árbol; son respetadas las garantías del contrato de tráfico asociado con los VCCs, etc. SMART puede ser entendido como un protocolo completamente distribuido para coordinar la distribución de VPIs/VCIs.
Para solventar las conocidas dificultades debidas al soporte y uso de muchos-a-muchos VCCs, SMART usa el mecanismo de Cell Interleaving (sobre un VCC muchos-a-muchos, las células de datos desde diferentes fuentes pueden llegar intercaladas a un destinatario) y también Demand Sharing (los recursos asignados a conexiones muchos-a-muchos son dinámicamente compartidas entre todas las potenciales fuentes.
El artículo [3] describe el protocolo SMART formal e informalmente, y propone completas pruebas de corrección y un detallado análisis de comportamiento para estudios futuros. También son sugeridas otras investigaciones como son: ofrecer justicia en los accesos a los árboles multicast; investigar las células RM periódicamente para aliviar las congestiones en la red o disminuir el tiempo de acceso del usuario a los árboles de distribución multicast; análisis de las células RM dentro de cada VCC o fuera enviando todas las células RM en un VCC dedicado.
En [17] se presenta MWAX un algoritmo dinámico 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 artículo describe un esquema jerárquico basado en CBT para incorporar routing multipunto-a-multipunto en PNNI. En el algoritmo los nodos core actúan como participantes pasivos para eliminar la dependencia en la selección de estos nodos. Con un mecanismo de backup se consigue un algoritmo tolerante a fallos en los nodos core, lo cual puede ser fácilmente 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 jerarquía.
SEAM (Scalable and Efficient ATM Multicast) [18] propone una arquitectura escalable, eficiente y multicast multipunto-a-multipunto para redes ATM que usa un sólo VC para un grupo multicast de múltiples 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. También realiza aportaciones para conseguir soportar IP multicast sobre redes ATM extensas.
SEAM usa un sólo árbol de distribución 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 señalización del grupo. Este trabajo deja abiertas investigaciones referentes a la gestión de tráfico y a la entrega fiable de tráficos multicasting.
Concluimos esta sección destacando MCMP (Multiparty Conference Management Protocol) [19] que, sin estar pensado específicamente para ATM, es un protocolo de nivel sesión/transporte distribuido extremo-extremo y desarrollado para gestión de grupos de aplicaciones de conferencia. MCMP es un conjunto de algoritmos de control distribuido para configuración de conferencias multipunto y gestión de miembros de grupos de usuarios.
Conceptualmente, MCMP reside en el nivel de sesión en el que se establece la infraestructura para activar la transferencia de información entre los participantes en la conferencia. Pero funcionalmente, el protocolo acompasa los niveles de sesión y de transporte pues utiliza directamente servicios del nivel de red. Son destacables las condiciones de corrección (conectividad, validación, unicidad, consistencia y terminación) que deben ser satisfechas una vez que la conferencia ha sido configurada por el algoritmo de configuración de MCMP. El artículo muestra exhaustivas pruebas de corrección para uno de los algoritmos, y también describe la especificación y verificación del protocolo.
5.- Nuevos campos de investigación
En todas las redes existen gran variedad de elementos hardware (switchs, routers, bridges, brouters, hubs, ETDs, etc.) que realizan muy diversas funciones (conmutación, routing, puenteo, controles de congestión y de flujo, garantía de QoS, ejecución de aplicaciones, etc.). En la actualidad la red es mayormente un canal de comunicación para transferir paquetes entre equipos finales (ayudada por los elementos hardware antes citados). Pero también se están realizando importante esfuerzos para equipar a los elementos hardware con elevadas prestaciones aportadas por diversas técnicas software. Esto dota a la red de características activas (active networks) en el sentido de que los elementos hardware que la componen computan, modifican u operan los contenidos de los paquetes y también serán capaces de transferir o propagar código. Por consiguiente, una red activa es una red programable.
[20] es una excelente revisión de este novedoso campo de investigación que discute dos planteamientos en la realización de redes activas, la idea del conmutador programable y la de la cápsula. Una red es activa si en sus árboles de distribución multicast existen nodos activos con capacidad para ejecutar programas y/o capaces de implementar mecanismos de propagación de código. Algunas de las ventajas de los protocolos activos son conseguidas instalando nodos activos en puntos estratégicos de la red.
Otro nuevo concepto es presentado en [21] como una metodología para el diseño de protocolos. Los protocol boosters son una nueva contribución a las redes activas o programables. Una ventaja de los boosters es que pueden ser fácilmente "inyectados" en los sistemas actuales sin provocar cambios en la infraestructura de red.
Por otro lado, [22] propone el concepto de agente de comunicaciones para servicios de comunicaciones multimedia en redes de área extensa. Este papel introduce una arquitectura software orientada a agente y propone el concepto de agente de comunicación para servicio de comunicación 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 artículo muestra agentes software móviles usados para implementar operaciones robustas y funciones de mantenimiento en redes ATM. Los agentes desempeñan un rol similar al de las células OAM en ATM estándar, pues son transmitidos entre entidades de control a intervalos regulares usando recursos predefinidos. La diferencia entre los agentes móviles y las células OAM reside en que éstos pueden contener código. Para concluir destacar que la integración del tráfico IP sobre tecnología ATM es también uno de los campos más activos en la actualidad. En esta línea pueden destacarse los siguientes protocolos: IP-over-ATM, IP Switching, Tag Switching, NHRP, MPOA, IMSS, CSR, ARIS AREQUIPA,RED y EPD.
5. ARQUITECTURA DE RDSI-BA (ATM)
Para reunir los requisitos para vídeo de alta resolución, se necesitan velocidades de unos 150 Mbps. Además para poder ofrecer uno o más servicios interactivos y distribuidos se necesita una velocidad de línea de abonado de unos 600 Mbps. La única tecnología que permite estas velocidades es la fibra óptica. Por tanto la introducción de la RDSI-BA depende del ritmo de introducción del bucle de abonado de fibra. El dispositivo de conmutación debe soportar un amplio rango de velocidades diferentes y de parámetros de tráfico. Por eso se utiliza una tecnología de conmutación de paquetes rápidos que admite fácilmente el protocolo ATM.
Arquitectura funcional
RDSI-BA debe dar soporte a todos los servicios de transmisión a 64 Kbps que son admitidos por RDSI-BE para facilitar la conexión de RDSI-BE a RDSI-BA.
También observamos como el control de RDSI-BA se basa en señalización de canal común. Se usa un SS7 mejorado para admitir capacidades suplementarias de red de mayor velocidad.
En cuanto al protocolo de señalización, dos son los organismos que han definido estándares utilizados en ATM. El ITU-T ( antiguo CCITT ) definió el estándar Q.2391, versión mejorada del Q.391 utilizado en RDSI-BE. Por otro lado, el ATM FORUM ( asociación de fabricantes ) propuso la señalización UNI 3.0, basado precisamente en el Q.2391, que permite la interoperatividad entre distintos fabricantes.
Las diferencias entre Q.391 y Q.2391 son
• En Q.2391 no existe un canal común para la señalización ( canal D ), sino un canal virtual independiente para cada terminal.
• En vez de negociar el acceso a un canal B, se negocia una conexión de canal virtual entre extremos de la comunicación.
CONFIGURACIÓN DE REFERENCIA
Es básicamente la misma que la de RDSI-BE. Se utilizaron los mismos grupos funcionales añadiéndoles el prefijo B- para diferenciarlos. Con los puntos de referencia ocurre lo mismo, son iguales pero con el subíndice B.
Grupos funcionales
-B-NT1: Encargado de mantener las funciones de bajo nivel que conectan, mediante una línea física punto a punto, la red pública con los servicios de usuario. Es trasparente a los protocolos de señalización y al tráfico transportado.
-B-NT2:Realiza las funciones de adaptación a los diferentes medios y topologías. Son funciones suyas la señalización, adaptación y la multiplexación /demultiplexación de celdas.
-B-TE1: Es un equipo de usuario que soporta las interfaces y los protocolos definidos para RDSI-BA. Se conecta a los punto SB y TB.
-B-TE2: Es un equipo de usuario con una interfaz no estandarizada por la RDSI-BA. Se conecta al punto RB.
-B-TA: Adaptador que permite a los terminales B-TE2 conectarse a una RDSI-BA.
Puntos de referencia
Son los mismos que los de RDSI-BE con el subíndice B, aunque sólo se estandarizaron SB y TB. El punto RB se puede considerar dentro de este conjunto y permite conectar los dispositivos que acceden a través de los adaptadores de terminal de banda ancha ( B-TA ).
ESTRUCTURA DE LA TRANSMISIÓN
En términos de velocidades disponibles para abonados, se definen tres servicios de transmisión
• Servicio Full-duplex a 155´52 Mbps.
• Servicio asimétrico: Abonado-red a 155´52 Mbps y Red-abonado a 622´08 Mbps.
• Servicio Full-duplex a 622´08 Mbps.
La velocidad de 155´52 Mbps puede ya admitir todos los servicios de RDSI-BA. A esta velocidad se pueden incluir uno o varios canales de vídeo, por tanto, el servicio full-duplex a 155´52 Mbps será el servicio RDSI-BA más usado. La velocidad de 622´08 Mbps se necesita para gestionar la distribución de vídeo múltiple ( Videoconferencias simultáneas múltiples ). El abonado que quiera acceder a estos servicios utilizará el servicio asimétrico, dejando el servicio full-duplex a 622´08 Mbps para los suministradores de distribución de vídeo.
PROTOCOLO
El hecho de utilizar ATM en RDSI-BA marca la diferencia en los protocolos de RDSI-BA y RDSI-BE. En efecto, aunque RDSI-BA debe admitir aplicaciones en modo de circuito, estas se realizarán sobre un mecanismo de transporte basado en paquetes, por tanto, podemos decir que RDSI será una red de conmutación de paquetes ya que contiene servicios de banda ancha.
Plano de usuario: Proporciona al usuario transferencia de información, contemplando el control de flujo y control de errores.
Plano de control: Realiza control de llamadas y control de conexión (establecimiento, liberación, etc...).
Plano de gestión: Coordinan todos los planos y controla los recursos que residen en sus entidades de protocolo.
Estos planos se dividen en capas, como muestra la figura anterior, y estas capas se dividen a su vez en subcapas. En la tabla siguiente se contemplan las subcapas existentes y se indican las funciones que realizan cada una de ellas.
INTERCONEXIONES RDSI-BE<>RDSI-BA
Como cualquier red que desee tener aceptación en la industria, un objetivo prioritario es la interconexión con las redes existentes. El caso de la RDSI-BA y su relación con su predecesora, la RDSI-BE, no va a ser una excepción: cuando la RDSI-BA esté comercialmente disponible como servicio público, la RDSI-BE dispondrá de una base instalada considerable y unas infraestructuras relativamente recientes.
Las interconexiones se realizarán, en principio, con gateways entre las dos redes conectadas en cualesquiera de los grupos funcionales LE o TE del modelo de configuración de referencia. La interconexión estará limitada a las facilidades que ambas tengan en común. Por ejemplo, supongamos una conferencia entre un videoteléfono de alta definición conectado a RDSI-BA y un videoteléfono de la RDSI-BE. Es evidente que la resolución de la conexión será la de la RDSI-BE.
Arquitectura funcional
RDSI-BA debe dar soporte a todos los servicios de transmisión a 64 Kbps que son admitidos por RDSI-BE para facilitar la conexión de RDSI-BE a RDSI-BA.
También observamos como el control de RDSI-BA se basa en señalización de canal común. Se usa un SS7 mejorado para admitir capacidades suplementarias de red de mayor velocidad.
En cuanto al protocolo de señalización, dos son los organismos que han definido estándares utilizados en ATM. El ITU-T ( antiguo CCITT ) definió el estándar Q.2391, versión mejorada del Q.391 utilizado en RDSI-BE. Por otro lado, el ATM FORUM ( asociación de fabricantes ) propuso la señalización UNI 3.0, basado precisamente en el Q.2391, que permite la interoperatividad entre distintos fabricantes.
Las diferencias entre Q.391 y Q.2391 son
• En Q.2391 no existe un canal común para la señalización ( canal D ), sino un canal virtual independiente para cada terminal.
• En vez de negociar el acceso a un canal B, se negocia una conexión de canal virtual entre extremos de la comunicación.
CONFIGURACIÓN DE REFERENCIA
Es básicamente la misma que la de RDSI-BE. Se utilizaron los mismos grupos funcionales añadiéndoles el prefijo B- para diferenciarlos. Con los puntos de referencia ocurre lo mismo, son iguales pero con el subíndice B.
Grupos funcionales
-B-NT1: Encargado de mantener las funciones de bajo nivel que conectan, mediante una línea física punto a punto, la red pública con los servicios de usuario. Es trasparente a los protocolos de señalización y al tráfico transportado.
-B-NT2:Realiza las funciones de adaptación a los diferentes medios y topologías. Son funciones suyas la señalización, adaptación y la multiplexación /demultiplexación de celdas.
-B-TE1: Es un equipo de usuario que soporta las interfaces y los protocolos definidos para RDSI-BA. Se conecta a los punto SB y TB.
-B-TE2: Es un equipo de usuario con una interfaz no estandarizada por la RDSI-BA. Se conecta al punto RB.
-B-TA: Adaptador que permite a los terminales B-TE2 conectarse a una RDSI-BA.
Puntos de referencia
Son los mismos que los de RDSI-BE con el subíndice B, aunque sólo se estandarizaron SB y TB. El punto RB se puede considerar dentro de este conjunto y permite conectar los dispositivos que acceden a través de los adaptadores de terminal de banda ancha ( B-TA ).
ESTRUCTURA DE LA TRANSMISIÓN
En términos de velocidades disponibles para abonados, se definen tres servicios de transmisión
• Servicio Full-duplex a 155´52 Mbps.
• Servicio asimétrico: Abonado-red a 155´52 Mbps y Red-abonado a 622´08 Mbps.
• Servicio Full-duplex a 622´08 Mbps.
La velocidad de 155´52 Mbps puede ya admitir todos los servicios de RDSI-BA. A esta velocidad se pueden incluir uno o varios canales de vídeo, por tanto, el servicio full-duplex a 155´52 Mbps será el servicio RDSI-BA más usado. La velocidad de 622´08 Mbps se necesita para gestionar la distribución de vídeo múltiple ( Videoconferencias simultáneas múltiples ). El abonado que quiera acceder a estos servicios utilizará el servicio asimétrico, dejando el servicio full-duplex a 622´08 Mbps para los suministradores de distribución de vídeo.
PROTOCOLO
El hecho de utilizar ATM en RDSI-BA marca la diferencia en los protocolos de RDSI-BA y RDSI-BE. En efecto, aunque RDSI-BA debe admitir aplicaciones en modo de circuito, estas se realizarán sobre un mecanismo de transporte basado en paquetes, por tanto, podemos decir que RDSI será una red de conmutación de paquetes ya que contiene servicios de banda ancha.
Plano de usuario: Proporciona al usuario transferencia de información, contemplando el control de flujo y control de errores.
Plano de control: Realiza control de llamadas y control de conexión (establecimiento, liberación, etc...).
Plano de gestión: Coordinan todos los planos y controla los recursos que residen en sus entidades de protocolo.
Estos planos se dividen en capas, como muestra la figura anterior, y estas capas se dividen a su vez en subcapas. En la tabla siguiente se contemplan las subcapas existentes y se indican las funciones que realizan cada una de ellas.
INTERCONEXIONES RDSI-BE<>RDSI-BA
Como cualquier red que desee tener aceptación en la industria, un objetivo prioritario es la interconexión con las redes existentes. El caso de la RDSI-BA y su relación con su predecesora, la RDSI-BE, no va a ser una excepción: cuando la RDSI-BA esté comercialmente disponible como servicio público, la RDSI-BE dispondrá de una base instalada considerable y unas infraestructuras relativamente recientes.
Las interconexiones se realizarán, en principio, con gateways entre las dos redes conectadas en cualesquiera de los grupos funcionales LE o TE del modelo de configuración de referencia. La interconexión estará limitada a las facilidades que ambas tengan en común. Por ejemplo, supongamos una conferencia entre un videoteléfono de alta definición conectado a RDSI-BA y un videoteléfono de la RDSI-BE. Es evidente que la resolución de la conexión será la de la RDSI-BE.
6. Jerarquía Digital Sincrónica (SDH)
Synchronous Digital Hierarchy (Jerarquía Digital Sincrónica) es un estándar internacional para redes ópticas de telecomunicaciones de alta capacidad. Un sistema de transporte digital sincrónico diseñado para proveer una infraestructura más sencilla, económica y flexible para redes de telecomunicaciones.
Esencialmente, es un protocolo de transporte basado en la existencia de una referencia temporal común (Reloj primario), que multiplexa diferentes señales dentro de una jerarquía común flexible, y gestiona su transmisión de forma eficiente a través de fibra óptica, con mecanismos internos de protección. Debido a que todos los terminales de la red disponen de una referencia de reloj estable, no es necesario ningún tipo de bits de relleno o de trama durante el multiplexado de señales.
SDH es normalmente considerado un protocolo de la capa física de transporte, y como tal, actúa como portador de tráfico en forma de paquetes de información como ser voz, video, multimedia, paquetes de datos como los que genera ATM, IP, o de aplicaciones tales como PDH.
Para ello, su papel es, esencialmente gestionar la utilización de la infraestructura de fibra, lo que significa gestionar el ancho de banda eficientemente mientras porta varios tipos de tráfico, también detectar fallos y recuperar de ellos la transmisión de forma transparente para las capas superiores.
Origen del SDH
Los sistemas de transmisión síncronos han sido desarrollados a partir de la necesidad de los operadores en solucionar principalmente los problemas que son enumerados a continuación:
a) desplegar redes flexibles y resistentes,
b) definir interfaces estándar entre equipamientos de diferentes fabricantes,
c) facilitar interconexión de redes entre jerarquías de transmisión de Norte América y Europa.
El estándar culminó en 1989 en las recomendaciones de la ITU-T G.707, G.708, y G.709 que definen la Jerarquía Digital Síncrona.
Las recomendaciones definen un número de tasas básicas de transmisión que se pueden emplear en SDH. La primera de estas tasas es 155.52 Mbps, normalmente referidas como un STM-1 (donde STM significa Módulo de Transporte Síncrono). Mayores tasas de transmisión como el STM-4, el STM-16, y el STM-64 (622.08 Mbps, 2488.32 Mbps y 9953.28 Mbps respectivamente) están también definidas.
Las recomendaciones definen una estructura de multiplexación en donde una señal STM-1 transporta o acomoda un número de señales de menor tasa de transmisión, como ser señales PDH de todos los niveles, con el objetivo de transportar las antiguas tramas en la nueva, empaquetándolas en un área de su carga útil (payload), utilizando un proceso multipaso en un número diferente de estructuras.
Ventajas:
a) Operaciones de multiplexión y demultiplexión más sencillas y flexibles, permitiendo extraer e insertar circuitos sin tener que desmontar la señal y utilizando un simple multiplexor, y que permite una rápida provisión de servicios punto a punto a petición.
b) Fácil de migrar hacia órdenes superiores de multiplexación, ya que emplean la misma filosofía de trabajo.
c) La provisión de la capacidad de gestión de la red es definida en el estándar.
d) Las cabeceras permiten mejorar los procedimientos de operación, administración y mantenimiento de la red (OAM).
e) Administración y transporte de una gran variedad de servicios de ancho de banda fijo como son las señales de tráfico PDH a 2 Mbps, 34 Mbps y 140 Mbps, G.702, ATM, Interfaces Ethernet que toman datos IP o datos provenientes de LAN, Interfaces de voz analógicas, Interfaces RDSI/ADSL.
f) Cuenta con mecanismos integrados de protección, con re-enrutamiento automático del tráfico sin interrupción del servicio
g) Define una interfaz eléctrica y óptica estandarizada y abierta para permitir la interconexión con otros equipos.
Características de la red de transporte SDH:
a) Multiplexión digital: Las señales de comunicaciones analógicas son portadas en formato digital sobre la red. El tráfico digital puede ser portado mucho más eficientemente y permite monitorización de errores, para propósitos de calidad.
b) Fibra óptica: Éste es el medio físico comúnmente utilizado en las redes de transporte actuales, debido a su mayor capacidad de portar tráfico, lo que conduce a una disminución de los costes asociados al transporte de tráfico.
c) Esquemas de protección: Éstos han sido estandarizados para asegurar la disponibilidad del tráfico. En eventuales fallas o roturas de fibra, el tráfico podría ser conmutado a una ruta alternativa, de modo que el usuario final no sufriera disrupción alguna en el servicio.
d) Topologías en anillo: Éstas están siendo desplegadas cada vez en mayor número, debido a eventuales pérdidas de enlace, hay un camino de tráfico alternativo por el otro lado del anillo, minimizando el número de enlaces y cantidad de fibra óptica desplegada en la red.
e) Gestión de red: La gestión de estas redes desde un único lugar remoto es una prestación importante para los operadores. Se ha desarrollado software que permite gestionar todos los nodos y caminos de tráfico desde un único computador. Un operador puede gestionar una variedad grande de funciones tales como el aprovisionamiento de la capacidad respondiendo a la demanda de clientes y la monitorización de la calidad de una red.
f) Sincronización: Operadores de red deben proporcionar temporización sincronizada a todos los elementos de la red para asegurarse que la información que pasa de un nodo a otro no se pierda. La sincronización se está convirtiendo en un punto crítico, proveyendo a SDH un camino ideal de filosofía de red.
PROTOCOLO ATM:
El protocolo ATM consiste de tres niveles o capas básicas (Ver figura No 3).
CAPA FÍSICA
La primera capa llamada (Physical Layer), define los interfases físicos con los medios de transmisión y el protocolo de trama para la red ATM es responsable de la correcta transmisión y recepción de los bits en el medio físico apropiado. A diferencia de muchas tecnologías LAN como Ethernet, que especifica ciertos medios de transmisión, (10 base T, 10 base 5, etc.) ATM es independiente del transporte físico. Las celdas ATM pueden ser transportadas en redes SONET (Synchronous Optical Network), SDH (Synchronous Digital Hierarchy), T3/E3, TI/EI o aún en modems de 9600 bps. Hay dos subcapas en la capa física que separan el medio físico de transmisión y la extracción de los datos:
La subcapa PMD (Physical Medium Depedent) tiene que ver con los detalles que se especifican para velocidades de transmisión, tipos de conectores físicos, extracción 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 extracción de información contenida desde la misma capa física. Esto incluye la generación y el chequeo del Header Error Corrección (HEC), extrayendo celdas desde el flujo de bits de entrada y el procesamiento de celdas "idles" y el reconocimiento del límite de la celda. Otra función importante es intercambiar información de operación y mantenimiento (OAM) con el plano de administración.
CAPA ATM
La segunda capa es la capa ATM. Ello define la estructura de la celda y cómo las celdas fluyen sobre las conexiones lógicas 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 información.
Las celdas son transmitidas serialmente y se propagan en estricta secuencia numérica a través de la red. El tamaño 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, vídeo y protocolos sensibles al retardo. A pesar de que no se diseñó específicamente para eso, la longitud de la celda ATM acomoda convenientemente dos Fast Packets IPX de 24 bytes cada uno.
Los comités de estándares han definido dos tipos de cabeceras ATM: los User-to-Network Interface (UNI) y la Network to Network Interface (UNI). La UNI es un modo nativo de interfaz ATM que define la interfaz entre el equipo del cliente (Customer Premises Equipment), tal como hubs o routerss ATM y la red de área ancha ATM (ATM WAN). La NNI define la interfase entre los nodos de la redes (los switches o conmutadores) o entre redes. La NNI puede usarse como una interfase entre una red ATM de un usuario privado y la red ATM de un proveedor público (carrier). Específicamente, la función 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 conmutación de las celdas ATM.
La capa de adaptación de ATM:
La tercer capa es la ATM Adaptation Layer (AAL). La AAL juega un rol clave en el manejo de múltiples tipos de tráfico 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 más altas, tales como emulación de circuitos, (circuit emulation), vídeo, 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 están definidos actualmente.
Esencialmente, es un protocolo de transporte basado en la existencia de una referencia temporal común (Reloj primario), que multiplexa diferentes señales dentro de una jerarquía común flexible, y gestiona su transmisión de forma eficiente a través de fibra óptica, con mecanismos internos de protección. Debido a que todos los terminales de la red disponen de una referencia de reloj estable, no es necesario ningún tipo de bits de relleno o de trama durante el multiplexado de señales.
SDH es normalmente considerado un protocolo de la capa física de transporte, y como tal, actúa como portador de tráfico en forma de paquetes de información como ser voz, video, multimedia, paquetes de datos como los que genera ATM, IP, o de aplicaciones tales como PDH.
Para ello, su papel es, esencialmente gestionar la utilización de la infraestructura de fibra, lo que significa gestionar el ancho de banda eficientemente mientras porta varios tipos de tráfico, también detectar fallos y recuperar de ellos la transmisión de forma transparente para las capas superiores.
Origen del SDH
Los sistemas de transmisión síncronos han sido desarrollados a partir de la necesidad de los operadores en solucionar principalmente los problemas que son enumerados a continuación:
a) desplegar redes flexibles y resistentes,
b) definir interfaces estándar entre equipamientos de diferentes fabricantes,
c) facilitar interconexión de redes entre jerarquías de transmisión de Norte América y Europa.
El estándar culminó en 1989 en las recomendaciones de la ITU-T G.707, G.708, y G.709 que definen la Jerarquía Digital Síncrona.
Las recomendaciones definen un número de tasas básicas de transmisión que se pueden emplear en SDH. La primera de estas tasas es 155.52 Mbps, normalmente referidas como un STM-1 (donde STM significa Módulo de Transporte Síncrono). Mayores tasas de transmisión como el STM-4, el STM-16, y el STM-64 (622.08 Mbps, 2488.32 Mbps y 9953.28 Mbps respectivamente) están también definidas.
Las recomendaciones definen una estructura de multiplexación en donde una señal STM-1 transporta o acomoda un número de señales de menor tasa de transmisión, como ser señales PDH de todos los niveles, con el objetivo de transportar las antiguas tramas en la nueva, empaquetándolas en un área de su carga útil (payload), utilizando un proceso multipaso en un número diferente de estructuras.
Ventajas:
a) Operaciones de multiplexión y demultiplexión más sencillas y flexibles, permitiendo extraer e insertar circuitos sin tener que desmontar la señal y utilizando un simple multiplexor, y que permite una rápida provisión de servicios punto a punto a petición.
b) Fácil de migrar hacia órdenes superiores de multiplexación, ya que emplean la misma filosofía de trabajo.
c) La provisión de la capacidad de gestión de la red es definida en el estándar.
d) Las cabeceras permiten mejorar los procedimientos de operación, administración y mantenimiento de la red (OAM).
e) Administración y transporte de una gran variedad de servicios de ancho de banda fijo como son las señales de tráfico PDH a 2 Mbps, 34 Mbps y 140 Mbps, G.702, ATM, Interfaces Ethernet que toman datos IP o datos provenientes de LAN, Interfaces de voz analógicas, Interfaces RDSI/ADSL.
f) Cuenta con mecanismos integrados de protección, con re-enrutamiento automático del tráfico sin interrupción del servicio
g) Define una interfaz eléctrica y óptica estandarizada y abierta para permitir la interconexión con otros equipos.
Características de la red de transporte SDH:
a) Multiplexión digital: Las señales de comunicaciones analógicas son portadas en formato digital sobre la red. El tráfico digital puede ser portado mucho más eficientemente y permite monitorización de errores, para propósitos de calidad.
b) Fibra óptica: Éste es el medio físico comúnmente utilizado en las redes de transporte actuales, debido a su mayor capacidad de portar tráfico, lo que conduce a una disminución de los costes asociados al transporte de tráfico.
c) Esquemas de protección: Éstos han sido estandarizados para asegurar la disponibilidad del tráfico. En eventuales fallas o roturas de fibra, el tráfico podría ser conmutado a una ruta alternativa, de modo que el usuario final no sufriera disrupción alguna en el servicio.
d) Topologías en anillo: Éstas están siendo desplegadas cada vez en mayor número, debido a eventuales pérdidas de enlace, hay un camino de tráfico alternativo por el otro lado del anillo, minimizando el número de enlaces y cantidad de fibra óptica desplegada en la red.
e) Gestión de red: La gestión de estas redes desde un único lugar remoto es una prestación importante para los operadores. Se ha desarrollado software que permite gestionar todos los nodos y caminos de tráfico desde un único computador. Un operador puede gestionar una variedad grande de funciones tales como el aprovisionamiento de la capacidad respondiendo a la demanda de clientes y la monitorización de la calidad de una red.
f) Sincronización: Operadores de red deben proporcionar temporización sincronizada a todos los elementos de la red para asegurarse que la información que pasa de un nodo a otro no se pierda. La sincronización se está convirtiendo en un punto crítico, proveyendo a SDH un camino ideal de filosofía de red.
PROTOCOLO ATM:
El protocolo ATM consiste de tres niveles o capas básicas (Ver figura No 3).
CAPA FÍSICA
La primera capa llamada (Physical Layer), define los interfases físicos con los medios de transmisión y el protocolo de trama para la red ATM es responsable de la correcta transmisión y recepción de los bits en el medio físico apropiado. A diferencia de muchas tecnologías LAN como Ethernet, que especifica ciertos medios de transmisión, (10 base T, 10 base 5, etc.) ATM es independiente del transporte físico. Las celdas ATM pueden ser transportadas en redes SONET (Synchronous Optical Network), SDH (Synchronous Digital Hierarchy), T3/E3, TI/EI o aún en modems de 9600 bps. Hay dos subcapas en la capa física que separan el medio físico de transmisión y la extracción de los datos:
La subcapa PMD (Physical Medium Depedent) tiene que ver con los detalles que se especifican para velocidades de transmisión, tipos de conectores físicos, extracción 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 extracción de información contenida desde la misma capa física. Esto incluye la generación y el chequeo del Header Error Corrección (HEC), extrayendo celdas desde el flujo de bits de entrada y el procesamiento de celdas "idles" y el reconocimiento del límite de la celda. Otra función importante es intercambiar información de operación y mantenimiento (OAM) con el plano de administración.
CAPA ATM
La segunda capa es la capa ATM. Ello define la estructura de la celda y cómo las celdas fluyen sobre las conexiones lógicas 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 información.
Las celdas son transmitidas serialmente y se propagan en estricta secuencia numérica a través de la red. El tamaño 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, vídeo y protocolos sensibles al retardo. A pesar de que no se diseñó específicamente para eso, la longitud de la celda ATM acomoda convenientemente dos Fast Packets IPX de 24 bytes cada uno.
Los comités de estándares han definido dos tipos de cabeceras ATM: los User-to-Network Interface (UNI) y la Network to Network Interface (UNI). La UNI es un modo nativo de interfaz ATM que define la interfaz entre el equipo del cliente (Customer Premises Equipment), tal como hubs o routerss ATM y la red de área ancha ATM (ATM WAN). La NNI define la interfase entre los nodos de la redes (los switches o conmutadores) o entre redes. La NNI puede usarse como una interfase entre una red ATM de un usuario privado y la red ATM de un proveedor público (carrier). Específicamente, la función 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 conmutación de las celdas ATM.
La capa de adaptación de ATM:
La tercer capa es la ATM Adaptation Layer (AAL). La AAL juega un rol clave en el manejo de múltiples tipos de tráfico 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 más altas, tales como emulación de circuitos, (circuit emulation), vídeo, 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 están definidos actualmente.
7. ATM EN LAS REDES DE AREA LOCAL
En las redes actuales, podemos encontrar los siguientes y principales problemas a partir de la aparición de nuevos equipos más y más potentes:
• Transferencia de datos muy grandes (del orden de Gigabytes)
• Tráfico de red en aumento.
Ante estos problemas, la solución que los administradores de las redes buscan es la ampliación del ancho de banda, lo cual tiene el inconveniente de que no todas las aplicaciones necesitan el mismo ancho de banda, con lo que la asignación fija de un ancho de banda determinado provoca el desaprovechamiento de tan preciado recurso, ya que no todas las aplicaciones necesitan el mismo ancho de banda continuamente, sino que existen picos de información.
Para solucionar este problema aparece el Modo de transmisión asíncrona, ATM , cuyas principales características (según sus proveedores) son:
• Velocidades de ancho de banda mayores de 1Gbps.
• Garantías para desarrollar aplicaciones multimedia.
• Capacidad para diferentes tecnologías de acceso (Ethernet, Frame Relay o FDDI)
A partir de 1996 existen en el mercado nuevos productos y servicios ATM para redes de área local y extendida. Estos productos van desde adaptadores de 25'6 Mbps a conmutadores con puertos Ethernet incorporados.
Sin embargo no será hasta 1998 cuando aparezcan nuevos productos software y hardware que permitan pasar de una red normal a la infraestructura ATM, debido al alto coste de reemplazamiento de lo que sería la espina dorsal de las redes por los equipos ATM.
SOLUCIONES ATM A LOS
“CUELLO DE BOTELLA”
Las redes de área local utilizadas tradicionalmente poseen las siguientes características:
• Utilizan tecnologías “store and forward”.
• Utilizan encaminadores no orientados a la conexión.
De este modo,cuando un usuario desea enviar datos a otro usuario,no existe un circuito específico, sino que se intenta aprovechar al máximo el ancho de banda de la red para esa aplicación.
Así, cuando existen problemas de congestión, debido al aumento del volumen de tráfico en la red, el rendimiento de la red disminuye influyendo en las aplicaciones de todos los usuarios, ya que podemos indicar que el ancho de banda se considera como un servicio compartido, es decir, todo el ancho de banda es compartido por todos los usuarios.
ATM cambia radicalmente de filosofía, en cuanto que se basa en la comunicación orientada a la conexión, permitiendo conexiones más fiables entre los usuarios, y principalmente, permitiendo un mejor ancho de banda, ya que para cada tipo de aplicación se `reserva' una cantidad de ancho de banda según el tipo que sea. De esta manera, aplicaciones como el Correo Electrónico usará un ancho de banda acorde con el tráfico de información que cursa, muy diferente al de una aplicación del tipo Multimedia.
De este modo al reservar el ancho de banda de un circuito virtual, nada de lo que puede ocurrir en el resto de la red durante el transcurso de nuestra comunicación podrá repercutir en la calidad de la misma.
COMO INTEGRAR ATM CON LO YA EXISTENTE
El mejor método para pasar de una red convencional a ATM consiste en proporcionar ATM en primer lugar a aquellos grupos que necesiten un mayor uso de los recursos de la red. Esto se realiza mediante tarjetas adaptadoras ATM, que se conectarán con el resto de tarjetas de red mediante puentes. Estas tarjetas no suponen un gran desembolso económico para la empresa o el cliente, y permite introducir ATM de una manera suave, sin romper con lo ya establecido.
El problema que nos podemos encontrares que hemos pasar de unas tecnologías y protocolos que estaban pensados para unos requisitos específicos, como por ejemplo, Ethernet, a una red como ATM, cuya principal característica es que es asíncrona, además de utilizar comunicaciones orientadas a la conexión.
ATM es capaz de garantizar de que cada protocolo tenga unas determinadas características con las que le sea posible ofrecer los servicios que normalmente ofrece a sus usuarios. Esto lo hace dando para cada tipo de protocolo existente en esa red un circuito virtual ( LANE ) con unas características adecuadas a ese protocolo. De este modo, cualquiera aplicación que utilice cualquier tipo de protocolo existente en el mercado, será capaz de acceder a la red ATM, con todas las ventajas que esta ofrece al usuario.
ATM también permite conexiones vía satélite a través de Comsat World Services, que ofrece dos niveles de servicio.
• Uno de ancho de banda medio y alto para empresas públicas de telecomunicaciones.
• Otro ancho de banda para clientes con redes multinacionales.
•
Estos servicios emplean terminales VSAT que son estaciones terrestres móviles, que son capaces de manejar enlaces de alta capacidad con los satélites del sistema fijo Intelsat.
De este modo, será posible establecer comunicaciones de videoconferencia y multimedia en tiempo real entre dos lugares opuestos del globo, con el consiguiente beneficio para la empresa.
EL FUNCIONAMIENTO DE ATM
La palabra clave en ATM es conexiones, ya que en ATM cuando se envían datos dos usuarios, se establece un circuito virtual que conecta al usuario directamente con el usuario remoto (algo parecido a lo que hace la red telefónica), mientras que las tecnologías de red actuales (FDDI, Token Ring, Ethernet) lo que hacen es unir al usuario con la red, pero no con el usuario destino.
Las ventajas de ATM ( Orientado a la conexión) frente al resto de redes son las siguientes:
Lo que se define como “calidad de servicio”, esto es, ATM mantiene el ancho de banda de una comunicación sin que el resto del tráfico que haya por la red influya lo más mínimo, porque se negocia en la conexión el ancho de banda que se va a utilizar según la aplicación.
La “calidad de servicio” es negociable, contando las especificaciones de ATM con diferentes niveles de servicio. Algunos de ellos son:
• “Velocidad de bits disponible” (ABR). ATM ofrece un ancho de banda, pero no garantiza que en esa conexión no haya interrupciones. Recomendado para transferencia de archivos.
• “Velocidad de bits constante” (CBR). ATM ofrece un ancho de banda, y en este caso lo garantiza durante toda la sesión. Es muy recomendado si se utilizan videoconferencias.
Proporciona un ancho de banda que va desde 25'6 Mbps a 1 Gbps dependiendo de las necesidades.
• • ATM es una tecnología que puede soportar cualquier tipo de datos (voz, texto, imagen ...) en cualquier tipo de red (LAN o WAN).
LOS PROBLEMAS DE ATM
El principal problema que se encuentran las empresas para instalar ATM es el económico. El alto precio de las tarjetas adaptadoras (varían entre 40.000 y 140.000) impiden que las empresas opten por esta tecnología de red, ya que la mayoría de las redes ni siquiera han sido amortizadas.
Otro inconveniente es que hasta mediados de 1995 no existía ningún estándar que especificase cómo se debía pasar de una red clásica a una red ATM, por lo que las empresas que optaban por el cambio a ATM debían realizar un cambio brusco de su red anterior a ATM, con el consiguiente desembolso económico.
Además, mientras ATM se ha ido desarrollando, han ido surgiendo tecnologías paralelas que ofrecen altas velocidades en la transmisión de datos y con un precio más asequible.
o
• Ethernet y Token Ring clásicas usando concentradores. Pueden ofrecer un ancho de banda suficiente para realizar transmisiones multimedia, con límites de 10 y 16 Mbps respectivamente.
• 100VG-AnyLAN: Ofrece una velocidad de entre 10 y 100Mbps y ancho de banda dedicado.
o
• Fast Ethernet: Ofrece velocidad de entre 10 y 100Mbps, pero no ofrece ancho de banda dedicado.
PROGRAMACIÓN EN ATM
Los programas diseñados para ATM deberán manejar datos en tiempo real, además suministrar datos rápidamente a otros ordenadores y todo esto compartiéndolo con señales concurrentes de audio y vídeo, además de ir informando a la red de la prioridad de lo que se envía, así como del ancho de banda requerido.
La programación de estas nuevas aplicaciones es muy complicado para los programadores, ya que no existen todavía las necesarias API´s que les permitan olvidarse del problema de la implementación física y ocuparse únicamente de la programación.
Actualmente no existe una aplicación de este tipo, siendo lo que más se aproxima a esta es Winsock 2.0. Otra aplicación parecida es LANE, proporcionada por la propia ATM, que proporciona una interfaz de MAC para IPx no ATM, NetBEUI.
También existe un protocolo IP que adapta redes TCP/IP a ATM, denominado IP sobre ATM.
Winsock 2.0.
• • Para ser compatible con la versión 1.1. incluye las llamadas Winsock que permiten establecer enlaces, enviar y recibir datos por los enlaces y eliminarlos cuando la comunicación haya finalizado.
• • Para ATM, Winsock 2.0. permite la calidad de servicio, con lo que las aplicaciones pueden negociar el nivel de servicio para un determinado ancho de banda así como prioridades y agrupaciones de socket (conexiones).
• Emulación de Red de Área Local (LANE).
LANE intenta que las aplicaciones que actualmente existen trabajan sobre ATM. Esto lo hace ofreciendo un nivel de servicio MAC complementario al que poseen los concentradores en las LAN.
La capacidad de servicio MAC permite la utilización de los distintos protocolos de comunicación y los controladores existentes.
La desventaja que tiene es que LANE no mejora la calidad de servicio, por lo que no aprovecha ATM al máximo.
LANE también especifica como han trabajado sobre redes ATM las tres características de la norma IEEE 802 (transmisión sin conexión, teleenvío /multienvío de mensajes y direcciones MAC unidas fisicamente).
LANE posee un protocolo de resolución de direcciones que se encarga de relacionar una dirección ATM con una dirección MAC, construyendo el circuito virtual entre los extremos. Para teleenvío / multienvío de mensajes LANE dirige circuitos punto a punto y punto a multipunto salientes.
LANE también define el formato de los paquetes ATM para que ésta trabaje como otra capa física y además, cómo un adaptador ATM en un terminal pueda trabajar como una intefaz lógica con otro protocolo en ese terminal.
IP sobre ATM.
Ha sido necesario especificar cómo colocar paquetes IP en unidades de datos de protocolo y convertirlos en celdas ATM para poder obtener esta aplicación, debido a que IP no reconoce los protocolos de MAC. Ésta es la técnica que se conoce como encapsulamiento.
Estas especificaciones a las que hemos hecho referencia son las siguientes:
• RFC 1483. Define la encapsulación de datagramas IP.
• RFC 1577. Especifica cómo trabajar con direcciones IP en ATM.
Ambas especificaciones tratan ATM, no como lo hace LANE (adaptación de un tipo de aplicaciones hacia ATM), sino como una sustitución de los nodos IP actuales.
IP sobre ATM trabaja mejor que LANE en cuanto a paquetes de datos más grandes y tráfico unidireccional, mientras que es menos eficiente en cuanto al tráfico multidireccional.
ATM Y EL TELETRABAJO.
Cada vez son más las personas que necesitan realizar su trabajo desde un lugar externo a su puesto de trabajo, gracias a la proliferación de los ordenadores portátiles.
Actualmente, la gran mayoría de las centrales telefónicas ya son digitales, lo cual significa que la mayoría de los conmutadores de las oficinas centrales son también digitales, permitiendo un mejor intercambio de datos en las redes.
Existen dos tipos de tecnologías digitales:
o
• DSL (Línea Digital de Abonados). Se está implantando y permite mejorar el rendimiento de la línea en las transmisiones de voz y datos, las cuales son las necesidades más demandadas.
• RDSI, cuyo uso se extiende rápidamente. Posee una velocidad de transmisión mínima de 64Kbps, además de ofrecer hasta 2 tipos de comunicación simultánea.
ATM permite la conexión con estos dos tipos de tecnologías usando las líneas telefónicas que existen en la actualidad, y manteniendo la alta velocidad en la comunicación que ofrece en sus características.
• Transferencia de datos muy grandes (del orden de Gigabytes)
• Tráfico de red en aumento.
Ante estos problemas, la solución que los administradores de las redes buscan es la ampliación del ancho de banda, lo cual tiene el inconveniente de que no todas las aplicaciones necesitan el mismo ancho de banda, con lo que la asignación fija de un ancho de banda determinado provoca el desaprovechamiento de tan preciado recurso, ya que no todas las aplicaciones necesitan el mismo ancho de banda continuamente, sino que existen picos de información.
Para solucionar este problema aparece el Modo de transmisión asíncrona, ATM , cuyas principales características (según sus proveedores) son:
• Velocidades de ancho de banda mayores de 1Gbps.
• Garantías para desarrollar aplicaciones multimedia.
• Capacidad para diferentes tecnologías de acceso (Ethernet, Frame Relay o FDDI)
A partir de 1996 existen en el mercado nuevos productos y servicios ATM para redes de área local y extendida. Estos productos van desde adaptadores de 25'6 Mbps a conmutadores con puertos Ethernet incorporados.
Sin embargo no será hasta 1998 cuando aparezcan nuevos productos software y hardware que permitan pasar de una red normal a la infraestructura ATM, debido al alto coste de reemplazamiento de lo que sería la espina dorsal de las redes por los equipos ATM.
SOLUCIONES ATM A LOS
“CUELLO DE BOTELLA”
Las redes de área local utilizadas tradicionalmente poseen las siguientes características:
• Utilizan tecnologías “store and forward”.
• Utilizan encaminadores no orientados a la conexión.
De este modo,cuando un usuario desea enviar datos a otro usuario,no existe un circuito específico, sino que se intenta aprovechar al máximo el ancho de banda de la red para esa aplicación.
Así, cuando existen problemas de congestión, debido al aumento del volumen de tráfico en la red, el rendimiento de la red disminuye influyendo en las aplicaciones de todos los usuarios, ya que podemos indicar que el ancho de banda se considera como un servicio compartido, es decir, todo el ancho de banda es compartido por todos los usuarios.
ATM cambia radicalmente de filosofía, en cuanto que se basa en la comunicación orientada a la conexión, permitiendo conexiones más fiables entre los usuarios, y principalmente, permitiendo un mejor ancho de banda, ya que para cada tipo de aplicación se `reserva' una cantidad de ancho de banda según el tipo que sea. De esta manera, aplicaciones como el Correo Electrónico usará un ancho de banda acorde con el tráfico de información que cursa, muy diferente al de una aplicación del tipo Multimedia.
De este modo al reservar el ancho de banda de un circuito virtual, nada de lo que puede ocurrir en el resto de la red durante el transcurso de nuestra comunicación podrá repercutir en la calidad de la misma.
COMO INTEGRAR ATM CON LO YA EXISTENTE
El mejor método para pasar de una red convencional a ATM consiste en proporcionar ATM en primer lugar a aquellos grupos que necesiten un mayor uso de los recursos de la red. Esto se realiza mediante tarjetas adaptadoras ATM, que se conectarán con el resto de tarjetas de red mediante puentes. Estas tarjetas no suponen un gran desembolso económico para la empresa o el cliente, y permite introducir ATM de una manera suave, sin romper con lo ya establecido.
El problema que nos podemos encontrares que hemos pasar de unas tecnologías y protocolos que estaban pensados para unos requisitos específicos, como por ejemplo, Ethernet, a una red como ATM, cuya principal característica es que es asíncrona, además de utilizar comunicaciones orientadas a la conexión.
ATM es capaz de garantizar de que cada protocolo tenga unas determinadas características con las que le sea posible ofrecer los servicios que normalmente ofrece a sus usuarios. Esto lo hace dando para cada tipo de protocolo existente en esa red un circuito virtual ( LANE ) con unas características adecuadas a ese protocolo. De este modo, cualquiera aplicación que utilice cualquier tipo de protocolo existente en el mercado, será capaz de acceder a la red ATM, con todas las ventajas que esta ofrece al usuario.
ATM también permite conexiones vía satélite a través de Comsat World Services, que ofrece dos niveles de servicio.
• Uno de ancho de banda medio y alto para empresas públicas de telecomunicaciones.
• Otro ancho de banda para clientes con redes multinacionales.
•
Estos servicios emplean terminales VSAT que son estaciones terrestres móviles, que son capaces de manejar enlaces de alta capacidad con los satélites del sistema fijo Intelsat.
De este modo, será posible establecer comunicaciones de videoconferencia y multimedia en tiempo real entre dos lugares opuestos del globo, con el consiguiente beneficio para la empresa.
EL FUNCIONAMIENTO DE ATM
La palabra clave en ATM es conexiones, ya que en ATM cuando se envían datos dos usuarios, se establece un circuito virtual que conecta al usuario directamente con el usuario remoto (algo parecido a lo que hace la red telefónica), mientras que las tecnologías de red actuales (FDDI, Token Ring, Ethernet) lo que hacen es unir al usuario con la red, pero no con el usuario destino.
Las ventajas de ATM ( Orientado a la conexión) frente al resto de redes son las siguientes:
Lo que se define como “calidad de servicio”, esto es, ATM mantiene el ancho de banda de una comunicación sin que el resto del tráfico que haya por la red influya lo más mínimo, porque se negocia en la conexión el ancho de banda que se va a utilizar según la aplicación.
La “calidad de servicio” es negociable, contando las especificaciones de ATM con diferentes niveles de servicio. Algunos de ellos son:
• “Velocidad de bits disponible” (ABR). ATM ofrece un ancho de banda, pero no garantiza que en esa conexión no haya interrupciones. Recomendado para transferencia de archivos.
• “Velocidad de bits constante” (CBR). ATM ofrece un ancho de banda, y en este caso lo garantiza durante toda la sesión. Es muy recomendado si se utilizan videoconferencias.
Proporciona un ancho de banda que va desde 25'6 Mbps a 1 Gbps dependiendo de las necesidades.
• • ATM es una tecnología que puede soportar cualquier tipo de datos (voz, texto, imagen ...) en cualquier tipo de red (LAN o WAN).
LOS PROBLEMAS DE ATM
El principal problema que se encuentran las empresas para instalar ATM es el económico. El alto precio de las tarjetas adaptadoras (varían entre 40.000 y 140.000) impiden que las empresas opten por esta tecnología de red, ya que la mayoría de las redes ni siquiera han sido amortizadas.
Otro inconveniente es que hasta mediados de 1995 no existía ningún estándar que especificase cómo se debía pasar de una red clásica a una red ATM, por lo que las empresas que optaban por el cambio a ATM debían realizar un cambio brusco de su red anterior a ATM, con el consiguiente desembolso económico.
Además, mientras ATM se ha ido desarrollando, han ido surgiendo tecnologías paralelas que ofrecen altas velocidades en la transmisión de datos y con un precio más asequible.
o
• Ethernet y Token Ring clásicas usando concentradores. Pueden ofrecer un ancho de banda suficiente para realizar transmisiones multimedia, con límites de 10 y 16 Mbps respectivamente.
• 100VG-AnyLAN: Ofrece una velocidad de entre 10 y 100Mbps y ancho de banda dedicado.
o
• Fast Ethernet: Ofrece velocidad de entre 10 y 100Mbps, pero no ofrece ancho de banda dedicado.
PROGRAMACIÓN EN ATM
Los programas diseñados para ATM deberán manejar datos en tiempo real, además suministrar datos rápidamente a otros ordenadores y todo esto compartiéndolo con señales concurrentes de audio y vídeo, además de ir informando a la red de la prioridad de lo que se envía, así como del ancho de banda requerido.
La programación de estas nuevas aplicaciones es muy complicado para los programadores, ya que no existen todavía las necesarias API´s que les permitan olvidarse del problema de la implementación física y ocuparse únicamente de la programación.
Actualmente no existe una aplicación de este tipo, siendo lo que más se aproxima a esta es Winsock 2.0. Otra aplicación parecida es LANE, proporcionada por la propia ATM, que proporciona una interfaz de MAC para IPx no ATM, NetBEUI.
También existe un protocolo IP que adapta redes TCP/IP a ATM, denominado IP sobre ATM.
Winsock 2.0.
• • Para ser compatible con la versión 1.1. incluye las llamadas Winsock que permiten establecer enlaces, enviar y recibir datos por los enlaces y eliminarlos cuando la comunicación haya finalizado.
• • Para ATM, Winsock 2.0. permite la calidad de servicio, con lo que las aplicaciones pueden negociar el nivel de servicio para un determinado ancho de banda así como prioridades y agrupaciones de socket (conexiones).
• Emulación de Red de Área Local (LANE).
LANE intenta que las aplicaciones que actualmente existen trabajan sobre ATM. Esto lo hace ofreciendo un nivel de servicio MAC complementario al que poseen los concentradores en las LAN.
La capacidad de servicio MAC permite la utilización de los distintos protocolos de comunicación y los controladores existentes.
La desventaja que tiene es que LANE no mejora la calidad de servicio, por lo que no aprovecha ATM al máximo.
LANE también especifica como han trabajado sobre redes ATM las tres características de la norma IEEE 802 (transmisión sin conexión, teleenvío /multienvío de mensajes y direcciones MAC unidas fisicamente).
LANE posee un protocolo de resolución de direcciones que se encarga de relacionar una dirección ATM con una dirección MAC, construyendo el circuito virtual entre los extremos. Para teleenvío / multienvío de mensajes LANE dirige circuitos punto a punto y punto a multipunto salientes.
LANE también define el formato de los paquetes ATM para que ésta trabaje como otra capa física y además, cómo un adaptador ATM en un terminal pueda trabajar como una intefaz lógica con otro protocolo en ese terminal.
IP sobre ATM.
Ha sido necesario especificar cómo colocar paquetes IP en unidades de datos de protocolo y convertirlos en celdas ATM para poder obtener esta aplicación, debido a que IP no reconoce los protocolos de MAC. Ésta es la técnica que se conoce como encapsulamiento.
Estas especificaciones a las que hemos hecho referencia son las siguientes:
• RFC 1483. Define la encapsulación de datagramas IP.
• RFC 1577. Especifica cómo trabajar con direcciones IP en ATM.
Ambas especificaciones tratan ATM, no como lo hace LANE (adaptación de un tipo de aplicaciones hacia ATM), sino como una sustitución de los nodos IP actuales.
IP sobre ATM trabaja mejor que LANE en cuanto a paquetes de datos más grandes y tráfico unidireccional, mientras que es menos eficiente en cuanto al tráfico multidireccional.
ATM Y EL TELETRABAJO.
Cada vez son más las personas que necesitan realizar su trabajo desde un lugar externo a su puesto de trabajo, gracias a la proliferación de los ordenadores portátiles.
Actualmente, la gran mayoría de las centrales telefónicas ya son digitales, lo cual significa que la mayoría de los conmutadores de las oficinas centrales son también digitales, permitiendo un mejor intercambio de datos en las redes.
Existen dos tipos de tecnologías digitales:
o
• DSL (Línea Digital de Abonados). Se está implantando y permite mejorar el rendimiento de la línea en las transmisiones de voz y datos, las cuales son las necesidades más demandadas.
• RDSI, cuyo uso se extiende rápidamente. Posee una velocidad de transmisión mínima de 64Kbps, además de ofrecer hasta 2 tipos de comunicación simultánea.
ATM permite la conexión con estos dos tipos de tecnologías usando las líneas telefónicas que existen en la actualidad, y manteniendo la alta velocidad en la comunicación que ofrece en sus características.
8. REDES LAN EN AMBIENTE ATM
Hay una fuerte tendencia a que las actuales redes locales (LAN) con sus protocolos y topologías existentes operen dentro de las tecnologías de Banda Ancha para manejo de servicios multimedia y muchos otros servicios conmutados que demandan una red inteligente con gran ancho de banda.
La Red Digital de Servicios Integrados de Banda Ancha con Modo de Transferencia Asíncrona BISDN/ ATM es la más aplicable a estos servicios conmutados.
Las empresas fabricantes de redes invierten muchos recursos para la investigación y el desarrollo de esta tecnología. Se habla ya de interconexiones ATM/LAN como una realidad. En el Ecuador se están proyectando anillo de fibra óptica para Quito y Guayaquil, que alimentarán nodos de ATM. En algunas ciudades importantes ya existen estos nodos que pueden permitir la integración de muchas redes LAN en este ambiente de banda ancha con gran capacidad de inteligencia.
Redes de Area Local ATM: el esfuerzo más significativo es usar ATM como el medio físico para los protocolos y las aplicaciones existentes de redes LANs. Las estaciones terminales son
conectadas a conmutadores hubs ATM locales con topología de estrella, usando canales virtuales ATM que transportan los paquetes de datos entre las estaciones, según la figura 1.
Este método es descrito en los documentos de estándares de Internet, publicados como RFC 1577 (Request For Comment 1577), que trata de los Protocolos de Internet (IP) clásicos y de los Protocolos con Capacidad de Dirección ARP (Address Resolution Protocol) junto con la serie TCP/IP (Transmision Control Protocol/Internet Protocol) para redes Ethernet comunes, que pueden ser usadas como protocolos de redes sobre interfaces de ATM.
Las estaciones de trabajo se organizan en subredes lógicas con el protocolo de Internet LIS (Logical IP Subnets), con un número simple de subred IP y una máscara de dirección. Dentro de cada LIS las estaciones pueden enviar paquetes a cualquier otra estación. Para enviar los paquetes fuera de la subred lógica LIS se debe usar un enrutador (router).
Capacidad de Dirección de ATM: las redes ATM son orientadas a la conexión, a diferencia
de la mayoría de las redes LAN que usan transferencia de datos sin conexión hacia una arquitectura fija. Entonces la estación debe estar habilitada a encontrar la dirección ATM de la estación de destino y crear un canal virtual para la transmisión de los datos.
En los protocolos IP clásicos, sobre ATM, se realiza la búsqueda de la dirección del destinatario usando el protocolo con capacidad de dirección ARP para ATM (ó ATMARP). Los protocolos ARP tradicionales permiten encontrar una dirección de hardware en control de acceso al medio ó MAC (Media Access Control) para una dirección dada de IP. Así mismo, se usa un ARP Inverso (INARP) para encontrar la propia dirección de IP de origen. Este modelo es extendido para ATMARP y para InATMARP, considerando una dirección ATM como una dirección de hardware. En un ambiente de conexión virtual permanente (PVC) se usa una configuración manual para establecer los canales virtuales entre cada par de estaciones dentro de la subred lógica LIS. Cada estación usa el protocolo con capacidad de dirección inversa InATMARP para determinar a cual dirección IP está conectada. Se envía un mensaje de pedido con la dirección del IP de la estación A: El mensaje de respuesta contiene la dirección IP del receptor B. La figura 2 muestra la operación del protocolo InATMARP sobre conexiones virtuales permanentes.
En un ambiente de conexión virtual conmutada (SVC), la señalización del interface de usuario con la red conmutada establece los canales virtuales entre las estaciones A y B. Un servidor ATMARP se usa para manejar la tabla de ATM y el par de direcciones I P para cada estación en la subred lógica LIS. Este servidor se localiza en una dirección ATM bien conocida, que se configura manualmente con cada estación cliente de la subred LIS.
Cuando un cliente A establece una conexión al servidor ATMARP, el servidor emite un pedido
(request) para determinar la dirección IP del cliente A. Este servidor usa la respuesta (reply) para construir y validar su tabla de direcciones. Si el cliente A necesita enviar un paquete al cliente B, y si A no tiene dirección ATM de B, entonces A debe enviar un pedido ATMARP al servidor, el cual envía la dirección ATM de B como respuesta. Entonces el cliente A utiliza esta dirección para crear el camino virtual usando el mensaje de señalización SETUP. La figura 3 ilustra estos tres pasos para el establecimiento de una conexión virtual conmutada.
El cliente A no siempre tiene que preguntar la dirección de B al servidor, si tiene un canal virtual VC abierto hacia B, o si tiene su propia tabla de direcciones construida en base a respuestas anteriores dadas por el servidor.
Las entrads en la tabla de direcciones del servidor son invalidadas si la conexión ha sido cerrada por más de 20 minutos. Las conexiones abiertas son revalidadas enviando pedidos InATMARP en el canal virtual cada 20 minutos.
Formato de paquete: hay dos métodos para el encapsulado de Paquetes en los Protocolos de
Internet IP clásicos sobre ATM. Cuando se transmiten paquetes IP y ATMARP sobre un simple canal virtual, el protocolo debe ser identificado per un campo de encabezado adicional en cada paquete. De forma alternativa se puede usar multiplexación de los canales virtuales VC con un canal virtual diferente para cada tipo de protocolo. Esta técnica se llama también "encapsulación nula". Los paquetes son encapsulados usando IEEE 802.2 LLC/SNAP, como se describe en los documentos RFC 1483: "Encapsulación de Multiprotocolo sobre la capa de adaptación ATM de nivel
5: AAL-5". Este método requiere de un encabezado de 8 bytes para cada paquete. El encabezado está compuesto per 3 bytes para el LLC (Logical Link Control ó Control de enlace lógico), que identifica que punto de conexión de la subred continúa. El campo SNAP (Sub-Network Attachment Point ó Punto de Conexión de Subred) está compuesto de 3 bytes para el Identificador Unico Organización (OUI) y de 2 bytes para el Identificador del Protocolo (PID) definido por el OUI. El valor OUI: 00-00-00 indica que el PID está en una red tipo Ethernet, y el valor OUI 08-00 significa que el paquete siguiente es un IP; por ejemplo, el valor 08-06 marca que el siguiente paquete es un protocolo con capacidad de direccionamiento ARP.
La figura 4 muestra el encapsulado y la segmentación de un paquete IP a una secuencia de celdas ATM.
Prueba del IP clásico sobre ATM: el Protocolo de Internet IP clásico sobre ATM es relativamente simple, pero las implementaciones deben ser probadas para asegurar una correcta operación e interoperabilidad entre los proveedores de los sistemas. Los procedimientos de encapsulado pueden verificarse simplemente decodificando las tramas capturadas en el enlace ATM. Los encabezados de control del enlace lógico y del punto de conexión de la subred (LLC/SNAP) deberían tener la forma:
AA-AA-03-00-00-00-08-00 para los paquetes de Protocolos de Internet IPs.
La codificación correcta de los paquetes ATMARP es un poco más complicada, ya que el formato del paquete es una modificación del protocolo tradicional ARP. Un punto de interpretación diferente está en como se codifican las direcciones desconocidas. Los paquetes ATMARP tienen una longitud de campo para cada dirección de las estaciones A y B.
Una petición de mensaje podría codificar el campo de la dirección desconocida del cliente B en
una de las dos formas siguientes:
1. Longitud cero y ausencia del campo de dirección.
2. Longitud correcta (por ejemplo 4 bytes para las direcciones IP, y 20 bytes para las direcciones ATM) y, una dirección cero (ejemplo: 0.0.0.0) para IP.
Este tema surgió en las sesiones de pruebas de interoperabilidad de multimarcas conducidas en la Universidad de New Hampshire en Febrero de 1995, y se consulta en el pedido de comentarios de los estándares de Internet RFC 1.577. Las diferentes discusiones entre varios fabricantes concluyen que los mensajes deberían estar codificados usando el último método, pero que los mensajes recibidos puedan usar cualquier codificación que sea interpretada correctamente. Luego de esto, será
propuesta una actualización de la RFC 1.577, de modo que la longitud del campo de direcciones pueda ser interpretada como el número de bytes de dirección a proponerse, en un buffer de longitud fija de 20 ó de 4 bytes. Esto tiene una consecuencia muy significativa en la interoperabilidad ya que las implementaciones de la longitud del campo de direcciones, no la longitud de la dirección determinará el tamaño del buffer o de la memoria temporal requerida.
Otra característica de interoperabilidad que se debe considerar es cómo codificar la respuesta del protocolo con capacidad de dirección, para manejar el reconocimiento negativo ARP-NAK (negative AcKnowledgement). Este mensaje es una nueva extensión para el NTMARP, que indica que la dirección requerida no se puede encontrar. En los protocolos ARP tradicionales, la estación que pregunta esperaría por una respuesta del ARP de la dirección de destino durante un tiempo (time out) antes de considerar como un error la falta de respuesta.
El RFC 1577 establece que el servidor simplemente devuelve una copia del mensaje de pedido, pero con el código de operación cambiando de 1 (pedido de ARP) a 10 (No Reconocimiento de ARP).
Este procedimiento es contrario a una respuesta normal, donde los campos de las direcciones de A y B son cambiadas. Deben escogerse algunas implementaciones para codificar un mensaje de respuesta con direcciones cambiadas, e insertar bien el código de operación para leer exitosamente la dirección. Puede haber problemas en las implementaciones que verifiquen los campos del mensaje ATMARP según el intento inicial del RFC 1577.
Las pruebas de funcionamiento del protocolo de un cliente ó del servidor pueden ser optimizadas utilizando un probador de protocolos para simular un extremo de la conexión. Por ejemplo, el probador puede iniciar la conexión hacia el servidor y responder al pedido inicial de InARP, ó enviar un pedido de ARP usando direcciones diferentes de IP, conocidas o desconocidas. Las respuestas (ARP ó ARPNAK) deberían corresponder a la tabla de direcciones del servidor, que pueden ser examinadas por un terminal conectado al dispositivo.
Resultados de desempeño: Una consideración importante para las implementaciones de la
RFC 1577 es la aplicación final del desempeño. El desempeño es un término relativo, y depende de muchos factores, entre ellos la tasa de transmisión (con o sin congestión), de las implementaciones del protocolo y de la arquitectura del sistema.
El desempeño del protocolo del control de transmisión TCP depende del llamado "Producto de
Ancho de Banda - Retardo". Simplemente indica el ancho de banda multiplicado por el tiempo de retardo en la transmisión de los datos a través del enlace completo. Per ejemplo, la capacidad de un proceso de comunicaciones de un TCP (Pipe) para un canal virtual de 10 Mb/s con un retardo total de 15 ms es de 18.750 bytes. El tamaño de la ventana del TCP corresponde al total de los datos no reconocidos que pueden ser manejados correctamente, y
deberían ser el menos de ese tamaño para lograr un máximo resultado en la transmisión de los
datos comunicados.
El retardo total puede ser medido sobre una conexión por medio del programa conocido como
"ping". Esta herramienta de redes envía paquetes de Eco (ICMP ó Internet Control Message
Protocol) a la dirección. IP de destino y examina la respuesta del paquete Eco desde esa dirección una marca de tiempo de salida, con una precisión de 1 microsegundo, se inserta en el paquete de Eco y se resta del tiempo de la respuesta del Eco recibido para calcular el tiempo de retardo total.
Esta técnica toma en cuenta el tiempo procesamiento del software a cada extremo.
Estas pruebas, llamadas pruebas “ping", podrían ser usadas para medir a groso modo el tiempo de conexión del Setup. El ping inicial puede ser significativamente más largo que los pings remanentes
en un ambiente de canal virtual conmutado SVC, ya que la dirección ATM puede requerir ser obtenida desde el servidor de ATMARP, y el canal virtual debe estar establecido. En este caso, una medición del retardo en la conexión del setup debe hacerse con un probador de protocolo monitoreando la Iínea, como el HPJ2302B: AN LAN E1/ATM Internet Advisor.
TPC sobre redes de alto desempeño: regresando al tema el producto entre el ancho de banda y el retardo podemos observar que cuando el ancho de banda se incrementa, el tamaño de la ventana debe incrementarse para asegurar una máxima calidad de transmisión. El tamaño de la ventana del TPC se forza de un campo de 16 bits a uno de 65.536 bytes. Por lo tanto, la calidad del enlace también se limita, a menos que el tiempo de retardo se reduzca.
Si podemos usar una ventana de tamaño grande para el TCP, lo que significa que podemos tener más datos desconocidos en el proceso de comunicaciones (pipe), y si un paquete se pierde, el TCP borrará normalmente los paquetes desconocidos como parte de su proceso de recuperación. Con una ventana grande, puede lograrse una calidad aceptable en la transmisión. En una red de ATM, la pérdida de una simple celda ocasionaría la pérdida de un paquete en la capa de adaptación ATM (AAL-5); y, el efecto aumentaría el tamaño del protocolo. Una herramienta
para medir el desempeño del protocolo de control de transmisión TCP es el "ttcp", que pera como una fuente de tráfico de TCP en una estación UNIX y actúa como un host ó dispositivo inteligente conectado a la red y mide la eficiencia del enlace que una aplicación podría experimentar. Los diseñadores de redes deberían permitir un ajuste fino de los parámetros configurables del TPC para optimizar la eficiencia del enlace. Un diseñador puede también necesitar la medida de la calidad del enlace, para la aplicación, cuando los errores se introducen en el nivel de ATM.
Un emulador de los deterioros de la red puede insertarse entre los hosts de IP para introducir
errores tales como retardo y pérdida de celdas, como se muestra en la figura 5.
Esta técnica es un modelo de lo que puede pasar cuando los elementos de la red llegan a estar
congestionados. Los resultados del "ttcp" pueden ser usados para diferentes niveles de deterioro, para cuantificar la calidad de servicio necesaria para satisfacer los requerimientos de la aplicación a implementarse.
Algunos experimentos han mostrado que hay un punto en el cual los deterioros de la red causan que el desempeño del TCP caiga dramáticamente. La correlación inicial, entre la pérdida de la celda y la eficiencia en la transmisión del paquete alcanza un valor luego del cual la aplicación llega a ser virtualmente inusable, a pesar de que un significado monto de los datos de la celda sean recibidos correctamente.
El siguiente paso: el IP clásico sobre ATM es una solución eficiente para aplicaciones de
paquetes de datos en un Area local, pero no soporta redes WAN eficientemente. Los paquetes
destinados a direcciones que están fuera de la subred lógica LIS deben ser enrutados, requiriendo un encabezado extra y añadiendo un retardo con cada enrutador.
Esta deficiencia está siendo tratada dentro del IP, sobre el Grupo de Trabajo de ATM, en donde el siguiente protocolo de enrutamiento conocido como NHRP (Next Hop Routing Protocol) ha sido propuesto para reemplazar el ATMARP. Los pedidos de dirección que no han sido resueltos en la subred lógica local LIS pasan a servidores adicionales en otras subredes LIS. Entonces, la dirección ATM de destino retorna y se crea un canal virtual a través de la red. Este enfoque resuelve el problema de retardo, pero puede originar un retardo significativo en el setup o disposición del sistema.
Algunos fabricantes están tratando las limitaciones del TCP en redes de alta velocidad con nuevas opciones, descritas en el RFC 1323: "Extensiones de TCP para Alto Desempeño". Además, usan algunos algoritmos para retransmisión y recuperación más rápidas, que alivian los efectos de las pérdidas de paquetes con ventanas grandes.
Emulación de LANs: mientras que el IP clásico sobre ATM es usado para traer el ATM a las redes de Area local, no permite direccionar bien el conjunto de tecnologías LAN existente. Se necesitan paquetes para ser enrutados entre los diferentes tipos de redes, siendo el IP el único protocolo soportado.
El Foro de ATM reconoció que la interoperabilidad con las redes LAN y las aplicaciones existentes es muy importante para la aceptación de ATM en el mercado. El subgrupo de trabajo para Emulación de LANs definió inicialmente un servicio que emula las características de las redes LAN existentes. Esta emulación tiene lugar en la capa del MAC (Media Access Control), de modo que la red ATM mire efectivamente como a una red LAN tradicional a la aplicación determinada. Un amplio rango de protocolos (tales como el NETBIOS, el IPX y el Appletalk) operaran sobre este interface. El resultado final es que una simple red de Area local puede ser compuesta de segmentos ATM y de segmentos con varias topologías LAN. Al momento, pueden ser emuladas las tecnologías Ethernet y Token-Ring.
La figura 6 muestra una pequeña red con dos LANs emuladas (ELANs).
La mayor diferencia entre las redes LANs y las redes ATM es que las ATM son orientadas a conexión, mientras que las LAN usan un medio comparativo para conectar sus terminales. Los protocolos LAN envían paquetes de datos a todas las estaciones de la red, para que sean recibidos por los destinatarios direccionados y sean ignorados por las demás estaciones.
Una emulación de ATM de este funcionamiento requiere la habilidad de emitir paquetes hacia
múltiples destinos.
Arquitectura de Emulación de LANs: hay varios componentes en la arquitectura de Emulación de LANS. Algunos clientes de emulación de LANs (LECs ó Lan Emulation Clients) se comunican con un servicio de emulación de LANs a través de un interface de red para usuario de emulación LAN (LUNI ó Lan Emulation User to Network Interface). Cada estación terminal ATM es asociada con un LEC ó cliente de emulación de LAN. Esta asociación incluye el interface ATM con el puente hacia la red LAN. El LEC es responsable de proveer la emulación de la capa MAC para niveles mayores de protocolo. El servicio de emulación de LANs por si mismo tiene 3 componentes:
· El servidor de Emulación de LANs (LES ó Lan Emulation Server): responsable de la resolución de la dirección desde los MACs hasta las direcciones de los ATM.
Servidor de Emisión y de Dirección Desconocida (BUS ó Broadcast and Unknown Server): usado para el avance de las tramas desde el cliente de emulación de Lan LEC hacia las direcciones emitidas. Se usa también para enviar una emisión única de tramas a todos los clientes, antes de que se conozca la dirección de destino.
Servidor de Configuración para Emulación de LANs (LECS ó Lan Emulation Configuration Server): Usado por los clientes para su configuración inicial.
La arquitectura del sistema permite a estos componentes estar distribuidos entre varios dispositivos físicos.
Estos tres componentes se comunican entre ellos a través de varios canales en los interfaces de red para usuarios. Algunos de estos canales virtuales son unidireccionales, otros pueden ser implementados como punto a multipunto. La figura 7 muestra las conexiones entre los componentes de emulación de LANs:
Formato de Paquete: los paquetes de Emulación de LANs son codificados usando un formato
nuevo de trama. El Foro de ATM escogió no usar el método de encapsulado LLC/SNAP (Logic Link Control/ SubNetwork Attachment Point) para las tramas IEEE 802.3 de Ethernet ó IEEE 802.5 de Token Ring, conforme a lo descrito en el RFC 1483. En lugar de estos arreglos de entramado, el formato de paquete se definió de modo que compartan un encabezado común inicial entre los paquetes de control y de datos.
Los paquetes de datos empiezan con un campo de 16 bits que identifican al cliente LEC envía los datos. Este valor debe ser menor que OxFF00, ya que se usa para identificar los paquetes de control.
Los paquetes de datos de Ethernet tienen un encabezado diferente que para los de Token Ring. El Token Ring es un protocolo fuente enrutado, que permite también enrutar la información contenida en el encabezado del paquete. Adicionalmente, el ordenamiento de los 48 bits de la dirección del MAC (Media Access Control) es diferente, ya que el Ethernet transmite primero el bit menos significativo y el
Token Ring el más significativo.
Operación de la Emulación de LANs: los protocolos de Emulación de LANs son complejos de
modo que se resumirán a continuación sus pasos de operación:
_
1. Inicialización del Cliente: El cliente LEC debe ser inicializado antes de que pueda enviar los datos a otros LECs. La inicialización empieza cuando el LEC hace una conexión al servidor de configuración LECS. Primero trata de conseguir la dirección ATM para el servidor LECS con un pedido de interface provisional de manejo local (ILMI ó Interim Local Management Interface). Si éste falla, se usara una dirección bien conocida de ATM. El cliente LEC entonces intenta arreglar un canal virtual conmutado SVC bidireccional para esta dirección. Si otra vez falla, el cliente LEC usará un canal virtual permanente PVC como último recurso.
Una vez que ha sido establecida esta conexión de Configuración Directa, el cliente LEC envía su dirección ATM en un mensaje de pedido de configuración al servidor LECS. Este servidor de
configuración contesta con la dirección del servidor de Emulación de LANs ó LES y con el nombre y tipo de red LAN emulada (Ethernet o Token Ring). Algunos parámetros adicionales de configuración (como valores de contador o de tiempo) pueden también formar el mensaje de respuesta del servidor de configuración de las redes de LAN emuladas.
El siguiente paso del cliente LEC es establecer la conexión de Control Directo con el servidor LES. Este canal virtual conmutado SVC es usado para enviar un pedido del cliente LEC para unir la red LAN emulada. Si la conexión es exitosa el servidor LES retornará un identificador único del LEC (LECID) que será incluido en el control futuro y en el envío de los paquetes de datos por parte del cliente. El servidor LES tiene la opción de responder al cliente en la conexión de Control Directo, ó a través de una conexión de Control Distribuido punto multipunto unidireccional a todos los clientes LECs servidos por LES. La figura 8 muestra los pasos de inicialización para unir un cliente LEC en una red LAN emulada (ELAN).
2. Registro y Resolución de la Dirección: cada cliente LEC debe registrar la dirección (ó
direcciones) del control de acceso al medio MAC que representa, en el servidor LES. Este
servidor construye una tabla de direcciones de ATM (pares de direcciones de MACs que usa para responder a los pedidos de resolución de dirección que hará el cliente LEC luego). Este
protocolo es similar al ARP (Address Resolution Protocol) que se usa en las arquitecturas
clásicas de IP sobre ATM, como se vio en la primera parte de este artículo.
Una diferencia clave está en que si el servidor no puede responder al pedido, sí puede decidir el envío del pedido al cliente registrado en esa MAC, ó puede enviar el pedido a todos los clientes a través de la conexión punto - multipunto de Control Distribuido. El cliente que representa la dirección del MAC responderá al cliente que pregunta, enviándole la dirección ATM correspondiente.
_
3. Transferencia de Datos: es este punto, un canal virtual conmutado SVC de Datos Directos
puede ser inicializado entre dos clientes. El encabezado de emulación de la LAN es reclamado
por la trama de control de acceso al medio, y el paquete de datos se envía de cliente a cliente.
Normalmente, cada conexión de Datos Directos termina. Si no se envían paquetes entre los clientes por más de 20 minutos, el canal virtual conmutado se desconecta. Una conexión nueva puede ser establecida entre estos clientes si es necesaria más tarde.
Hay otra alternativa para enviar datos a un cliente. El servidor de emisión y de dirección
desconocida (BUS) puede ser usado para enviar datos a una dirección x antes de recibir una
respuesta. Cada cliente debe establecer una conexión de envío de multiemisión (Multicast Send) hacia el servidor de emisión BUS, que pone al cliente en una conexión unidireccional punto multipunto (Multicast Forward) para los datos de retorno. El cliente obtiene la dirección de ATM del BUS enviando un pedido ARP al servidor, usando la dirección del MAC de emisión (todos "unos").
Cuando el cliente envía un paquete al servidor de emisión BUS, este lo distribuye a todos los
clientes LECS. La dirección de destino en el paquete de datos determina cuál LEC lo procesará.
La figura 9 ilustra la operación del servidor de emisión de dirección desconocida (BUS).
4. Dificultades de implementación: la emulación de las redes LAN es un tema candente para
muchos fabricantes, pero esto conlleva un complejo juego de protocolos. En consecuencia, esta ligada a una implementación difícil. Se han estimado que el software de los servidores de
emulación de LANs toma cerca de 50.000 líneas de códigos en C, y que la implementación de los clientes es del orden de las 20.000 líneas. Como se puede apreciar, la corrección de estos
componentes es una tarea muy admirable y digna de los pacientes diseñadores de software.
Hay algunos puntos posibles de falla en el proceso del protocolo. Hay que tener cuidado para
asegurar que el cliente y el servidor permanezcan sincronizados, aún cuando otros sistemas fallen (como la señalización). Podrían haber problemas imprevistos, tales como condiciones diferentes entre los pesos del proceso de configuración.
5. Desafíos de las pruebas: los componentes de prueba de la emulación de redes LAN pueden ser caracterizados en diferentes niveles. Las pruebas de la capa física y de ATM pueden ser hechas en un dispositivo como un puente. Por ejemplo, el tiempo de espera para el acceso a la red a través del puente, puede ser medido capturando una marca de tiempo en el paquete Ethernet en un lado del puente, y correlacionándolo con la marca de tiempo del paquete capturado en el lado ATM. Se requiere una base de tiempo común entre los dos interfaces físicos. La interoperabilidad entre los protocolos es un tema para la emulación de LANs, ya que muchos fabricantes producen equipos para clientes y servidores. Los fabricantes de los clientes de redes LAN emuladas demandan muchas implementaciones en los servidores. Las pruebas de interoperabilidad y de compatibilidad serán definidas por la Emulación de las redes LAN. Por ahora, los grupos de pruebas de calidad desarrollados, observan manualmente las comunicaciones cliente – servidor para concordar con las especificaciones.
Resumen: se prestaron dos tecnologías para adaptar el modo de transferencia asíncrono ATM a la red de área local LAN. Algunos de los problemas y temas más complicados de estas tecnologías han sido brevemente mencionados. Las herramientas de prueba para explorar estas áreas de comunicación de datos son resumidas en los analizadores de protocolos, algunos con capacidad de emulación de terminales, que permiten realizar pruebas del tráfico en servicio, generan tráfico dentro
de una integración total de redes LAN, WAN y ATM.
El equipo que actualmente está capacitado para atender todos los requerimientos indicados, con nuevas y potentes capacidades para FDDI (Interface digital de fibra distribuida), ATM, Ethernet conmutada y perfiles estadísticos de LAN y WAN es la serie Agilent Advisor, para análisis de protocolos y monitoreo de problemas de redes.
La Red Digital de Servicios Integrados de Banda Ancha con Modo de Transferencia Asíncrona BISDN/ ATM es la más aplicable a estos servicios conmutados.
Las empresas fabricantes de redes invierten muchos recursos para la investigación y el desarrollo de esta tecnología. Se habla ya de interconexiones ATM/LAN como una realidad. En el Ecuador se están proyectando anillo de fibra óptica para Quito y Guayaquil, que alimentarán nodos de ATM. En algunas ciudades importantes ya existen estos nodos que pueden permitir la integración de muchas redes LAN en este ambiente de banda ancha con gran capacidad de inteligencia.
Redes de Area Local ATM: el esfuerzo más significativo es usar ATM como el medio físico para los protocolos y las aplicaciones existentes de redes LANs. Las estaciones terminales son
conectadas a conmutadores hubs ATM locales con topología de estrella, usando canales virtuales ATM que transportan los paquetes de datos entre las estaciones, según la figura 1.
Este método es descrito en los documentos de estándares de Internet, publicados como RFC 1577 (Request For Comment 1577), que trata de los Protocolos de Internet (IP) clásicos y de los Protocolos con Capacidad de Dirección ARP (Address Resolution Protocol) junto con la serie TCP/IP (Transmision Control Protocol/Internet Protocol) para redes Ethernet comunes, que pueden ser usadas como protocolos de redes sobre interfaces de ATM.
Las estaciones de trabajo se organizan en subredes lógicas con el protocolo de Internet LIS (Logical IP Subnets), con un número simple de subred IP y una máscara de dirección. Dentro de cada LIS las estaciones pueden enviar paquetes a cualquier otra estación. Para enviar los paquetes fuera de la subred lógica LIS se debe usar un enrutador (router).
Capacidad de Dirección de ATM: las redes ATM son orientadas a la conexión, a diferencia
de la mayoría de las redes LAN que usan transferencia de datos sin conexión hacia una arquitectura fija. Entonces la estación debe estar habilitada a encontrar la dirección ATM de la estación de destino y crear un canal virtual para la transmisión de los datos.
En los protocolos IP clásicos, sobre ATM, se realiza la búsqueda de la dirección del destinatario usando el protocolo con capacidad de dirección ARP para ATM (ó ATMARP). Los protocolos ARP tradicionales permiten encontrar una dirección de hardware en control de acceso al medio ó MAC (Media Access Control) para una dirección dada de IP. Así mismo, se usa un ARP Inverso (INARP) para encontrar la propia dirección de IP de origen. Este modelo es extendido para ATMARP y para InATMARP, considerando una dirección ATM como una dirección de hardware. En un ambiente de conexión virtual permanente (PVC) se usa una configuración manual para establecer los canales virtuales entre cada par de estaciones dentro de la subred lógica LIS. Cada estación usa el protocolo con capacidad de dirección inversa InATMARP para determinar a cual dirección IP está conectada. Se envía un mensaje de pedido con la dirección del IP de la estación A: El mensaje de respuesta contiene la dirección IP del receptor B. La figura 2 muestra la operación del protocolo InATMARP sobre conexiones virtuales permanentes.
En un ambiente de conexión virtual conmutada (SVC), la señalización del interface de usuario con la red conmutada establece los canales virtuales entre las estaciones A y B. Un servidor ATMARP se usa para manejar la tabla de ATM y el par de direcciones I P para cada estación en la subred lógica LIS. Este servidor se localiza en una dirección ATM bien conocida, que se configura manualmente con cada estación cliente de la subred LIS.
Cuando un cliente A establece una conexión al servidor ATMARP, el servidor emite un pedido
(request) para determinar la dirección IP del cliente A. Este servidor usa la respuesta (reply) para construir y validar su tabla de direcciones. Si el cliente A necesita enviar un paquete al cliente B, y si A no tiene dirección ATM de B, entonces A debe enviar un pedido ATMARP al servidor, el cual envía la dirección ATM de B como respuesta. Entonces el cliente A utiliza esta dirección para crear el camino virtual usando el mensaje de señalización SETUP. La figura 3 ilustra estos tres pasos para el establecimiento de una conexión virtual conmutada.
El cliente A no siempre tiene que preguntar la dirección de B al servidor, si tiene un canal virtual VC abierto hacia B, o si tiene su propia tabla de direcciones construida en base a respuestas anteriores dadas por el servidor.
Las entrads en la tabla de direcciones del servidor son invalidadas si la conexión ha sido cerrada por más de 20 minutos. Las conexiones abiertas son revalidadas enviando pedidos InATMARP en el canal virtual cada 20 minutos.
Formato de paquete: hay dos métodos para el encapsulado de Paquetes en los Protocolos deInternet IP clásicos sobre ATM. Cuando se transmiten paquetes IP y ATMARP sobre un simple canal virtual, el protocolo debe ser identificado per un campo de encabezado adicional en cada paquete. De forma alternativa se puede usar multiplexación de los canales virtuales VC con un canal virtual diferente para cada tipo de protocolo. Esta técnica se llama también "encapsulación nula". Los paquetes son encapsulados usando IEEE 802.2 LLC/SNAP, como se describe en los documentos RFC 1483: "Encapsulación de Multiprotocolo sobre la capa de adaptación ATM de nivel
5: AAL-5". Este método requiere de un encabezado de 8 bytes para cada paquete. El encabezado está compuesto per 3 bytes para el LLC (Logical Link Control ó Control de enlace lógico), que identifica que punto de conexión de la subred continúa. El campo SNAP (Sub-Network Attachment Point ó Punto de Conexión de Subred) está compuesto de 3 bytes para el Identificador Unico Organización (OUI) y de 2 bytes para el Identificador del Protocolo (PID) definido por el OUI. El valor OUI: 00-00-00 indica que el PID está en una red tipo Ethernet, y el valor OUI 08-00 significa que el paquete siguiente es un IP; por ejemplo, el valor 08-06 marca que el siguiente paquete es un protocolo con capacidad de direccionamiento ARP.
La figura 4 muestra el encapsulado y la segmentación de un paquete IP a una secuencia de celdas ATM.
Prueba del IP clásico sobre ATM: el Protocolo de Internet IP clásico sobre ATM es relativamente simple, pero las implementaciones deben ser probadas para asegurar una correcta operación e interoperabilidad entre los proveedores de los sistemas. Los procedimientos de encapsulado pueden verificarse simplemente decodificando las tramas capturadas en el enlace ATM. Los encabezados de control del enlace lógico y del punto de conexión de la subred (LLC/SNAP) deberían tener la forma:
AA-AA-03-00-00-00-08-00 para los paquetes de Protocolos de Internet IPs.
La codificación correcta de los paquetes ATMARP es un poco más complicada, ya que el formato del paquete es una modificación del protocolo tradicional ARP. Un punto de interpretación diferente está en como se codifican las direcciones desconocidas. Los paquetes ATMARP tienen una longitud de campo para cada dirección de las estaciones A y B.
Una petición de mensaje podría codificar el campo de la dirección desconocida del cliente B en
una de las dos formas siguientes:
1. Longitud cero y ausencia del campo de dirección.
2. Longitud correcta (por ejemplo 4 bytes para las direcciones IP, y 20 bytes para las direcciones ATM) y, una dirección cero (ejemplo: 0.0.0.0) para IP.
Este tema surgió en las sesiones de pruebas de interoperabilidad de multimarcas conducidas en la Universidad de New Hampshire en Febrero de 1995, y se consulta en el pedido de comentarios de los estándares de Internet RFC 1.577. Las diferentes discusiones entre varios fabricantes concluyen que los mensajes deberían estar codificados usando el último método, pero que los mensajes recibidos puedan usar cualquier codificación que sea interpretada correctamente. Luego de esto, será
propuesta una actualización de la RFC 1.577, de modo que la longitud del campo de direcciones pueda ser interpretada como el número de bytes de dirección a proponerse, en un buffer de longitud fija de 20 ó de 4 bytes. Esto tiene una consecuencia muy significativa en la interoperabilidad ya que las implementaciones de la longitud del campo de direcciones, no la longitud de la dirección determinará el tamaño del buffer o de la memoria temporal requerida.
Otra característica de interoperabilidad que se debe considerar es cómo codificar la respuesta del protocolo con capacidad de dirección, para manejar el reconocimiento negativo ARP-NAK (negative AcKnowledgement). Este mensaje es una nueva extensión para el NTMARP, que indica que la dirección requerida no se puede encontrar. En los protocolos ARP tradicionales, la estación que pregunta esperaría por una respuesta del ARP de la dirección de destino durante un tiempo (time out) antes de considerar como un error la falta de respuesta.
El RFC 1577 establece que el servidor simplemente devuelve una copia del mensaje de pedido, pero con el código de operación cambiando de 1 (pedido de ARP) a 10 (No Reconocimiento de ARP).
Este procedimiento es contrario a una respuesta normal, donde los campos de las direcciones de A y B son cambiadas. Deben escogerse algunas implementaciones para codificar un mensaje de respuesta con direcciones cambiadas, e insertar bien el código de operación para leer exitosamente la dirección. Puede haber problemas en las implementaciones que verifiquen los campos del mensaje ATMARP según el intento inicial del RFC 1577.
Las pruebas de funcionamiento del protocolo de un cliente ó del servidor pueden ser optimizadas utilizando un probador de protocolos para simular un extremo de la conexión. Por ejemplo, el probador puede iniciar la conexión hacia el servidor y responder al pedido inicial de InARP, ó enviar un pedido de ARP usando direcciones diferentes de IP, conocidas o desconocidas. Las respuestas (ARP ó ARPNAK) deberían corresponder a la tabla de direcciones del servidor, que pueden ser examinadas por un terminal conectado al dispositivo.
Resultados de desempeño: Una consideración importante para las implementaciones de la
RFC 1577 es la aplicación final del desempeño. El desempeño es un término relativo, y depende de muchos factores, entre ellos la tasa de transmisión (con o sin congestión), de las implementaciones del protocolo y de la arquitectura del sistema.
El desempeño del protocolo del control de transmisión TCP depende del llamado "Producto de
Ancho de Banda - Retardo". Simplemente indica el ancho de banda multiplicado por el tiempo de retardo en la transmisión de los datos a través del enlace completo. Per ejemplo, la capacidad de un proceso de comunicaciones de un TCP (Pipe) para un canal virtual de 10 Mb/s con un retardo total de 15 ms es de 18.750 bytes. El tamaño de la ventana del TCP corresponde al total de los datos no reconocidos que pueden ser manejados correctamente, y
deberían ser el menos de ese tamaño para lograr un máximo resultado en la transmisión de los
datos comunicados.
El retardo total puede ser medido sobre una conexión por medio del programa conocido como
"ping". Esta herramienta de redes envía paquetes de Eco (ICMP ó Internet Control Message
Protocol) a la dirección. IP de destino y examina la respuesta del paquete Eco desde esa dirección una marca de tiempo de salida, con una precisión de 1 microsegundo, se inserta en el paquete de Eco y se resta del tiempo de la respuesta del Eco recibido para calcular el tiempo de retardo total.
Esta técnica toma en cuenta el tiempo procesamiento del software a cada extremo.
Estas pruebas, llamadas pruebas “ping", podrían ser usadas para medir a groso modo el tiempo de conexión del Setup. El ping inicial puede ser significativamente más largo que los pings remanentes
en un ambiente de canal virtual conmutado SVC, ya que la dirección ATM puede requerir ser obtenida desde el servidor de ATMARP, y el canal virtual debe estar establecido. En este caso, una medición del retardo en la conexión del setup debe hacerse con un probador de protocolo monitoreando la Iínea, como el HPJ2302B: AN LAN E1/ATM Internet Advisor.
TPC sobre redes de alto desempeño: regresando al tema el producto entre el ancho de banda y el retardo podemos observar que cuando el ancho de banda se incrementa, el tamaño de la ventana debe incrementarse para asegurar una máxima calidad de transmisión. El tamaño de la ventana del TPC se forza de un campo de 16 bits a uno de 65.536 bytes. Por lo tanto, la calidad del enlace también se limita, a menos que el tiempo de retardo se reduzca.
Si podemos usar una ventana de tamaño grande para el TCP, lo que significa que podemos tener más datos desconocidos en el proceso de comunicaciones (pipe), y si un paquete se pierde, el TCP borrará normalmente los paquetes desconocidos como parte de su proceso de recuperación. Con una ventana grande, puede lograrse una calidad aceptable en la transmisión. En una red de ATM, la pérdida de una simple celda ocasionaría la pérdida de un paquete en la capa de adaptación ATM (AAL-5); y, el efecto aumentaría el tamaño del protocolo. Una herramienta
para medir el desempeño del protocolo de control de transmisión TCP es el "ttcp", que pera como una fuente de tráfico de TCP en una estación UNIX y actúa como un host ó dispositivo inteligente conectado a la red y mide la eficiencia del enlace que una aplicación podría experimentar. Los diseñadores de redes deberían permitir un ajuste fino de los parámetros configurables del TPC para optimizar la eficiencia del enlace. Un diseñador puede también necesitar la medida de la calidad del enlace, para la aplicación, cuando los errores se introducen en el nivel de ATM.
Un emulador de los deterioros de la red puede insertarse entre los hosts de IP para introducir
errores tales como retardo y pérdida de celdas, como se muestra en la figura 5.
Esta técnica es un modelo de lo que puede pasar cuando los elementos de la red llegan a estar
congestionados. Los resultados del "ttcp" pueden ser usados para diferentes niveles de deterioro, para cuantificar la calidad de servicio necesaria para satisfacer los requerimientos de la aplicación a implementarse.
Algunos experimentos han mostrado que hay un punto en el cual los deterioros de la red causan que el desempeño del TCP caiga dramáticamente. La correlación inicial, entre la pérdida de la celda y la eficiencia en la transmisión del paquete alcanza un valor luego del cual la aplicación llega a ser virtualmente inusable, a pesar de que un significado monto de los datos de la celda sean recibidos correctamente.
El siguiente paso: el IP clásico sobre ATM es una solución eficiente para aplicaciones de
paquetes de datos en un Area local, pero no soporta redes WAN eficientemente. Los paquetes
destinados a direcciones que están fuera de la subred lógica LIS deben ser enrutados, requiriendo un encabezado extra y añadiendo un retardo con cada enrutador.
Esta deficiencia está siendo tratada dentro del IP, sobre el Grupo de Trabajo de ATM, en donde el siguiente protocolo de enrutamiento conocido como NHRP (Next Hop Routing Protocol) ha sido propuesto para reemplazar el ATMARP. Los pedidos de dirección que no han sido resueltos en la subred lógica local LIS pasan a servidores adicionales en otras subredes LIS. Entonces, la dirección ATM de destino retorna y se crea un canal virtual a través de la red. Este enfoque resuelve el problema de retardo, pero puede originar un retardo significativo en el setup o disposición del sistema.
Algunos fabricantes están tratando las limitaciones del TCP en redes de alta velocidad con nuevas opciones, descritas en el RFC 1323: "Extensiones de TCP para Alto Desempeño". Además, usan algunos algoritmos para retransmisión y recuperación más rápidas, que alivian los efectos de las pérdidas de paquetes con ventanas grandes.
Emulación de LANs: mientras que el IP clásico sobre ATM es usado para traer el ATM a las redes de Area local, no permite direccionar bien el conjunto de tecnologías LAN existente. Se necesitan paquetes para ser enrutados entre los diferentes tipos de redes, siendo el IP el único protocolo soportado.
El Foro de ATM reconoció que la interoperabilidad con las redes LAN y las aplicaciones existentes es muy importante para la aceptación de ATM en el mercado. El subgrupo de trabajo para Emulación de LANs definió inicialmente un servicio que emula las características de las redes LAN existentes. Esta emulación tiene lugar en la capa del MAC (Media Access Control), de modo que la red ATM mire efectivamente como a una red LAN tradicional a la aplicación determinada. Un amplio rango de protocolos (tales como el NETBIOS, el IPX y el Appletalk) operaran sobre este interface. El resultado final es que una simple red de Area local puede ser compuesta de segmentos ATM y de segmentos con varias topologías LAN. Al momento, pueden ser emuladas las tecnologías Ethernet y Token-Ring.
La figura 6 muestra una pequeña red con dos LANs emuladas (ELANs).
La mayor diferencia entre las redes LANs y las redes ATM es que las ATM son orientadas a conexión, mientras que las LAN usan un medio comparativo para conectar sus terminales. Los protocolos LAN envían paquetes de datos a todas las estaciones de la red, para que sean recibidos por los destinatarios direccionados y sean ignorados por las demás estaciones.
Una emulación de ATM de este funcionamiento requiere la habilidad de emitir paquetes hacia
múltiples destinos.
Arquitectura de Emulación de LANs: hay varios componentes en la arquitectura de Emulación de LANS. Algunos clientes de emulación de LANs (LECs ó Lan Emulation Clients) se comunican con un servicio de emulación de LANs a través de un interface de red para usuario de emulación LAN (LUNI ó Lan Emulation User to Network Interface). Cada estación terminal ATM es asociada con un LEC ó cliente de emulación de LAN. Esta asociación incluye el interface ATM con el puente hacia la red LAN. El LEC es responsable de proveer la emulación de la capa MAC para niveles mayores de protocolo. El servicio de emulación de LANs por si mismo tiene 3 componentes:
· El servidor de Emulación de LANs (LES ó Lan Emulation Server): responsable de la resolución de la dirección desde los MACs hasta las direcciones de los ATM.
Servidor de Emisión y de Dirección Desconocida (BUS ó Broadcast and Unknown Server): usado para el avance de las tramas desde el cliente de emulación de Lan LEC hacia las direcciones emitidas. Se usa también para enviar una emisión única de tramas a todos los clientes, antes de que se conozca la dirección de destino.
Servidor de Configuración para Emulación de LANs (LECS ó Lan Emulation Configuration Server): Usado por los clientes para su configuración inicial.
La arquitectura del sistema permite a estos componentes estar distribuidos entre varios dispositivos físicos.
Estos tres componentes se comunican entre ellos a través de varios canales en los interfaces de red para usuarios. Algunos de estos canales virtuales son unidireccionales, otros pueden ser implementados como punto a multipunto. La figura 7 muestra las conexiones entre los componentes de emulación de LANs:
Formato de Paquete: los paquetes de Emulación de LANs son codificados usando un formato
nuevo de trama. El Foro de ATM escogió no usar el método de encapsulado LLC/SNAP (Logic Link Control/ SubNetwork Attachment Point) para las tramas IEEE 802.3 de Ethernet ó IEEE 802.5 de Token Ring, conforme a lo descrito en el RFC 1483. En lugar de estos arreglos de entramado, el formato de paquete se definió de modo que compartan un encabezado común inicial entre los paquetes de control y de datos.
Los paquetes de datos empiezan con un campo de 16 bits que identifican al cliente LEC envía los datos. Este valor debe ser menor que OxFF00, ya que se usa para identificar los paquetes de control.
Los paquetes de datos de Ethernet tienen un encabezado diferente que para los de Token Ring. El Token Ring es un protocolo fuente enrutado, que permite también enrutar la información contenida en el encabezado del paquete. Adicionalmente, el ordenamiento de los 48 bits de la dirección del MAC (Media Access Control) es diferente, ya que el Ethernet transmite primero el bit menos significativo y el
Token Ring el más significativo.
Operación de la Emulación de LANs: los protocolos de Emulación de LANs son complejos de
modo que se resumirán a continuación sus pasos de operación:
_
1. Inicialización del Cliente: El cliente LEC debe ser inicializado antes de que pueda enviar los datos a otros LECs. La inicialización empieza cuando el LEC hace una conexión al servidor de configuración LECS. Primero trata de conseguir la dirección ATM para el servidor LECS con un pedido de interface provisional de manejo local (ILMI ó Interim Local Management Interface). Si éste falla, se usara una dirección bien conocida de ATM. El cliente LEC entonces intenta arreglar un canal virtual conmutado SVC bidireccional para esta dirección. Si otra vez falla, el cliente LEC usará un canal virtual permanente PVC como último recurso.
Una vez que ha sido establecida esta conexión de Configuración Directa, el cliente LEC envía su dirección ATM en un mensaje de pedido de configuración al servidor LECS. Este servidor de
configuración contesta con la dirección del servidor de Emulación de LANs ó LES y con el nombre y tipo de red LAN emulada (Ethernet o Token Ring). Algunos parámetros adicionales de configuración (como valores de contador o de tiempo) pueden también formar el mensaje de respuesta del servidor de configuración de las redes de LAN emuladas.
El siguiente paso del cliente LEC es establecer la conexión de Control Directo con el servidor LES. Este canal virtual conmutado SVC es usado para enviar un pedido del cliente LEC para unir la red LAN emulada. Si la conexión es exitosa el servidor LES retornará un identificador único del LEC (LECID) que será incluido en el control futuro y en el envío de los paquetes de datos por parte del cliente. El servidor LES tiene la opción de responder al cliente en la conexión de Control Directo, ó a través de una conexión de Control Distribuido punto multipunto unidireccional a todos los clientes LECs servidos por LES. La figura 8 muestra los pasos de inicialización para unir un cliente LEC en una red LAN emulada (ELAN).
2. Registro y Resolución de la Dirección: cada cliente LEC debe registrar la dirección (ó
direcciones) del control de acceso al medio MAC que representa, en el servidor LES. Este
servidor construye una tabla de direcciones de ATM (pares de direcciones de MACs que usa para responder a los pedidos de resolución de dirección que hará el cliente LEC luego). Este
protocolo es similar al ARP (Address Resolution Protocol) que se usa en las arquitecturas
clásicas de IP sobre ATM, como se vio en la primera parte de este artículo.
Una diferencia clave está en que si el servidor no puede responder al pedido, sí puede decidir el envío del pedido al cliente registrado en esa MAC, ó puede enviar el pedido a todos los clientes a través de la conexión punto - multipunto de Control Distribuido. El cliente que representa la dirección del MAC responderá al cliente que pregunta, enviándole la dirección ATM correspondiente.
_
3. Transferencia de Datos: es este punto, un canal virtual conmutado SVC de Datos Directos
puede ser inicializado entre dos clientes. El encabezado de emulación de la LAN es reclamado
por la trama de control de acceso al medio, y el paquete de datos se envía de cliente a cliente.
Normalmente, cada conexión de Datos Directos termina. Si no se envían paquetes entre los clientes por más de 20 minutos, el canal virtual conmutado se desconecta. Una conexión nueva puede ser establecida entre estos clientes si es necesaria más tarde.
Hay otra alternativa para enviar datos a un cliente. El servidor de emisión y de dirección
desconocida (BUS) puede ser usado para enviar datos a una dirección x antes de recibir una
respuesta. Cada cliente debe establecer una conexión de envío de multiemisión (Multicast Send) hacia el servidor de emisión BUS, que pone al cliente en una conexión unidireccional punto multipunto (Multicast Forward) para los datos de retorno. El cliente obtiene la dirección de ATM del BUS enviando un pedido ARP al servidor, usando la dirección del MAC de emisión (todos "unos").
Cuando el cliente envía un paquete al servidor de emisión BUS, este lo distribuye a todos los
clientes LECS. La dirección de destino en el paquete de datos determina cuál LEC lo procesará.
La figura 9 ilustra la operación del servidor de emisión de dirección desconocida (BUS).
4. Dificultades de implementación: la emulación de las redes LAN es un tema candente para
muchos fabricantes, pero esto conlleva un complejo juego de protocolos. En consecuencia, esta ligada a una implementación difícil. Se han estimado que el software de los servidores de
emulación de LANs toma cerca de 50.000 líneas de códigos en C, y que la implementación de los clientes es del orden de las 20.000 líneas. Como se puede apreciar, la corrección de estos
componentes es una tarea muy admirable y digna de los pacientes diseñadores de software.
Hay algunos puntos posibles de falla en el proceso del protocolo. Hay que tener cuidado para
asegurar que el cliente y el servidor permanezcan sincronizados, aún cuando otros sistemas fallen (como la señalización). Podrían haber problemas imprevistos, tales como condiciones diferentes entre los pesos del proceso de configuración.
5. Desafíos de las pruebas: los componentes de prueba de la emulación de redes LAN pueden ser caracterizados en diferentes niveles. Las pruebas de la capa física y de ATM pueden ser hechas en un dispositivo como un puente. Por ejemplo, el tiempo de espera para el acceso a la red a través del puente, puede ser medido capturando una marca de tiempo en el paquete Ethernet en un lado del puente, y correlacionándolo con la marca de tiempo del paquete capturado en el lado ATM. Se requiere una base de tiempo común entre los dos interfaces físicos. La interoperabilidad entre los protocolos es un tema para la emulación de LANs, ya que muchos fabricantes producen equipos para clientes y servidores. Los fabricantes de los clientes de redes LAN emuladas demandan muchas implementaciones en los servidores. Las pruebas de interoperabilidad y de compatibilidad serán definidas por la Emulación de las redes LAN. Por ahora, los grupos de pruebas de calidad desarrollados, observan manualmente las comunicaciones cliente – servidor para concordar con las especificaciones.
Resumen: se prestaron dos tecnologías para adaptar el modo de transferencia asíncrono ATM a la red de área local LAN. Algunos de los problemas y temas más complicados de estas tecnologías han sido brevemente mencionados. Las herramientas de prueba para explorar estas áreas de comunicación de datos son resumidas en los analizadores de protocolos, algunos con capacidad de emulación de terminales, que permiten realizar pruebas del tráfico en servicio, generan tráfico dentro
de una integración total de redes LAN, WAN y ATM.
El equipo que actualmente está capacitado para atender todos los requerimientos indicados, con nuevas y potentes capacidades para FDDI (Interface digital de fibra distribuida), ATM, Ethernet conmutada y perfiles estadísticos de LAN y WAN es la serie Agilent Advisor, para análisis de protocolos y monitoreo de problemas de redes.
Subscribe to:
Posts (Atom)
