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.
Subscribe to:
Posts (Atom)
