SciELO - Scientific Electronic Library Online

 
vol.15 issue29Virtual platform e-commerce partners author indexsubject indexarticles search
Home Pagealphabetic serial listing  

Services on Demand

Journal

Article

Indicators

Related links

  • On index processCited by Google
  • Have no similar articlesSimilars in SciELO
  • On index processSimilars in Google

Share


Tecnura

Print version ISSN 0123-921X

Tecnura vol.15 no.29 Bogotá July 2011

 

IPv6 sobre ATM

IPv6 over ATM

Octavio Salcedo1, Danilo López2, Lilia Marina Castellanos3

1 Ingeniero en sistemas, magíster en Ciencias de la Información y las Comunicaciones, estudiante de Doctorado. Docente de la Universidad Distrital Francisco José de Caldas. Bogotá, Colombia. ojsalcedop@udistrital.edu.co
2 Ingeniero electrónico, magíster en Teleinformática. Docente e investigador de la Universidad Distrital Francisco José de Caldas. Bogotá, Colombia. dalopezs@udistrital.edu.co
3 Ingeniera en sistemas, estudiante en Ciencias de la Información y las Comunicaciones. Bogotá, Colombia. lilia.castellanos@gmail.com

Fecha de recepción: 16 de febrero de 2011 Fecha de aceptación: 30 de mayo de 2011


Resumen

La provisión de calidad de servicio (QoS) garantizada por parte de las redes de comunicación, en un ámbito global, es actualmente uno de principales campos de investigación, principalmente debido a la creciente importancia de aplicaciones como VoIP, videoconferencia, stream de video y audio, educación a distancia, entre otras.

En este artículo se presenta como tecnología, para proporcionar calidad de servicio, la integración de IPv6 y ATM. El principal objetivo es demostrar y analizar las principales soluciones y consideraciones que existen en la integración de tráfico IP dentro de la tecnología ATM.

Palabras clave: ATM, calidad de servicio, IPv6, red de datos.


Abstract

Providing Quality of Service (QoS) from communication networks in a global environment, is now one of the main fields of research, mainly due to the increasing importance of applications such as VoIP, video conferencing, stream video and ATM. The main objective is to present and and audio, distance education, among others. discuss the main considerations and solutions This article is presented as a technology for pro-that exist in the integration of IP traffic in ATM viding quality service, the integration of IPv6 technology.

Key words: ATM, quality of service, IPv6, data network.


1. Introducción

Un aspecto clave tanto para usuarios como operadores de redes de comunicaciones es garantizar la calidad de servicio (QoS) prestado en las redes de datos y servicios asociados. Una de las principales propuestas que se contemplan a la hora de definir marcos integrados de provisión de QoS propone la utilización de IP sobre ATM, de manera que se aprovechen tanto el control sobre los parámetros de QoS que proporciona ATM, como la gran expansión y conectividad de que goza IP.

Las redes IP y ATM se han desarrollado alrededor de paradigmas opuestos. Las redes IP soportan paquetes de longitud variable que son enrutados utilizando un servicio de datagramas no orientado a la conexión (Cada paquete es enrutado independientemente). Por el contrario, ATM utiliza un paquete pequeño de longitud fija, o celda, y enrutamiento orientado a la conexión de circuitos virtuales (VC). Antes de transferir las celdas se debe establecer un VC entre la fuente y el destino, todas las celdas que pertenecen a un mismo VC siguen la misma ruta. Las celdas son enrutadas usando un identificador de VC, que solo tiene significado local en cada nodo.

ATM ofrece capacidad de conmutación de alta velocidad. Por esta razón, a menudo se utiliza una red ATM o un switch ATM como parte del core de una red IP. Para el caso de IPv4, el principal problema por resolver es la diferencia entre el enfoque no orientado a la conexión de IP y la naturaleza de ATM, al ser orientada a la conexión.

El desarrollo de IPv6 permite la implementación de redes multiservicio, permitiendo a los paquetes ser asociados a un flujo individual, que a su vez pueden pertenecer a una clase particular de tráfico.

Por tanto, en el caso de transportar paquetes Ipv6 sobre redes ATM, la conectividad de red no es la única consideración para tener en cuenta. Si el flujo pertenece a una clase de tráfico que requiere un servicio garantizado, por ejemplo, un flujo asociado con una fuente de audio o video, será necesario mapear las características del flujo IPv6 en los parámetros de tráfico de los canales virtuales ATM (VC), que transportaran el flujo [1].

2. Calidad de servicio en IPv6

La calidad del servicio (QoS) se define como la capacidad de una red para proporcionar diversos niveles de servicio a los diferentes tipos de tráfico.

Al contar con QoS es posible asegurar una correcta entrega de la información, dando preferencia a aplicaciones de desempeño crítico, donde se comparten simultáneamente los recursos de red con otras aplicaciones no críticas. QoS hace la diferencia, al proveer un uso eficiente de los recursos en caso de presentarse congestión sobre la red, seleccionando un tráfico específico de la red, priorizándolo según su importancia relativa, y utilizando métodos de control y evasión de la congestión, para darles un tratamiento preferencial. Implementando QoS en una red se logra un rendimiento de la red más predecible y una utilización de ancho de banda más eficiente.

El protocolo IPv6 tiene dos campos que pueden ser utilizados como herramientas para implementar QoS: Etiqueta de flujo y Clase de tráfico [2], [3].

El campo Etiqueta de flujo de 20 bits en la cabecera IPv6 se agrega para permitir el etiquetado de paquetes que pertenecen a flujos de tráfico particulares y puede ser usado por el origen para etiquetar secuencias de paquetes para los cuales solicita un manejo especial por parte de los enrutadores IPv6, tal como la calidad de servicio no estándar o el servicio en tiempo real. Se exige a los hosts o a los enrutadores que no dan soporte a las funciones del campo Etiqueta de flujo poner el campo a cero al enviar un paquete, pasar el campo inalterado al reenviar un paquete, e ignorar el campo al recibir un paquete.

El campo de 8 bits Clase de tráfico en la cabecera IPv6 es utilizado por los nodos origen y/o enrutadores intermedios para identificar y distinguir entre las diferentes clases o prioridades de paquetes IPv6. Su función es similar al campo ToS de IPv4 [4].

3. Qos en atm

ATM tiene la cualidad de poder establecer contratos de tráfico entre la red y el usuario para garantizar QoS en una comunicación. La función que se utiliza para esto se conoce como Control de admisión para una conexión (CAC) y es la que determina si una nueva petición de conexión debe aceptarse o rechazarse. En caso de aceptarse se realiza el contrato que incluye los requisitos de QoS, descriptores de tráfico y la categoría de servicio ATM. [5].

3.1 Parámetros de QoS de red

Fijan el compromiso de la red frente a una conexión determinada:

  • CER (Cell Error Ratio). Proporción de celdas con uno o más bits erróneos, pero excluyendo los bloques de celdas severamente erróneos.

  • CMR (Cell Minsinsertion Ratio). Rata de celdas/Segundo que se envían hacia una conexión de destino equivocada. También se excluyen los bloques de celdas severamente erróneos.

  • SECBR (Severely-Errored Cell Block Ratio). Se entiende por bloque de celdas severamente erróneo cuando se presentan M celdas perdidas por error o se encuentran erróneamente en un bloque de N celdas recibidas. M y N son definidos por el operador de red. SECBR es la proporción de tales bloques en el total de bloques transmitidos en una conexión.

3.2 Parámetros de QoS de usuario

Son los que se negocian entre el usuario y la red durante el establecimiento de la conexión:

  • CLR (Cell Loss ratio). Rata de celdas perdidas con respecto al número total de celdas transmitidas. Está en el rango 10-1 a 10-15.

  • CTD (Cell Transfer Delay). Es el retardo total de la celda desde que sale del origen hasta que llega al destino. Debido a que generalmente celdas de una misma conexión experimentan retardos diferentes, el CTD se define mediante una función de densidad de probabilidad. Los estándares permiten la negociación del máximo CTD.

  • CDV (Cell Delay Variation). Mide la variación del retardo total de las celdas de una conexión.

3.3 Descriptores de tráfico del origen

La red debe estar en capacidad de determinar si el usuario está cumpliendo con el contrato establecido para determinada conexión. Para este fin se usan los siguientes parámetros:

  • PCR (Peak Cell Rate). Velocidad de celdas/ segundo que el origen nunca podrá exceder. De aquí se determina el intervalo mínimo de celdas como T=1/PCR.

  • SCR (Sustainable Cell Rate). Velocidad media de celdas/segundo, a la que se compromete transmitir el origen durante un periodo de tiempo.

  • MBS (Maximum Burts Size). Corresponde a la máxima cantidad de celdas consecutivas durante la velocidad máxima - PCR.

  • MCR (Minimum Cell Rate). Velocidad mínima en celdas/segundo a que se compromete transmitir el origen.

  • CDVT (Cell Delay Variation Tolerance). Especifica el nivel de variación del retardo de celdas que debe ser tolerado por la conexión.

3.4 Categorías de servicio en ATM

Las categorías de servicio ATM permiten a los usuarios un acceso flexible a los recursos de red y la posibilidad de alcanzar un compromiso satisfactorio entre desempeño y costo.

Las cinco categorías de servicios definidas por ATM Forum [6] y por ITU-T son las siguientes:

3.4.1 CBR (Velocidad binaria constante)

CBR corresponde ante todo a las aplicaciones que necesitan un suministro de ancho de banda constante. Este servicio provee un circuito virtual de transmisión de ancho de banda constante, como por ejemplo, el tráfico de video y voz en tiempo real.

3.4.2 VBR (Velocidad binaria variable)

El servicio está destinado para tráfico en ráfagas, tal como aplicaciones de procesamiento de transacción e interconexión de redes locales. Las aplicaciones pueden enviar información a velocidades de ráfagas más altas, en tanto las velocidades de información global no excedan un promedio determinado. VBR incluye las clases de servicio en tiempo real y en tiempo no real (RT-VBR y NRT-VBR).

3.4.3 ABR (velocidad binaria disponible)

Hace uso de cualquier ancho de banda disponible, sin embargo, la inteligencia incorporada en la red la protege contra la pérdida de información, mediante instrucciones que envían las estaciones hacia el origen cuando la red se congestiona. También, el servicio de ABR provee un mínimo de ancho de banda que garantiza la permanencia de las aplicaciones (running).

3.4.4 UBR (Velocidad binaria no especificada)

No tiene garantías de ancho de banda, es decir, que sólo se le asigna ancho de banda según la disponibilidad de éste, siendo usado principalmente en la transferencia de archivos.

4. Modelos de ip sobre atm

ATM e IP son tecnologías estructuralmente diferentes. Estas diferencias dan como resultado dos problemas: uno de adaptación y uno de direccionamiento. Para resolver el primero se necesita de una capa ubicada sobre ATM que realice el proceso de segmentar los paquetes IP en celdas y de reensamblarlos nuevamente durante el proceso inverso. Dicha función la realiza la Capa de adaptación ATM.

Además, el pasar de un servicio no orientado a la conexión a uno orientado a conexión y viceversa, requiere de un intercambio de mensajes entre ambos protocolos para una adecuada sincronización, lo cual hace parte también del problema de adaptación.

El problema de direccionamiento, por su parte, se debe a la diferencia de tamaño de las direcciones manejadas por ambas tecnologías y a la diferencia en la estructura de éstas, con lo cual el paso de un tipo de dirección a otro no puede darse de manera funcional. De forma que se necesita de un mecanismo para realizar el paso de un tipo de dirección a otro [7].

4.1 LANE (LAN Emulation)

LANE es una especificación del Foro ATM con el fin de acelerar la implementación de ATM en las redes empresariales. Estas redes generalmente implementan IP sobre una red LAN estandarizada (como Ethernet o Token Ring). LANE es en términos sencillos una capa que se monta sobre ATM con el fin de ofrecer a IP una interfaz idéntica a la de las LAN. De esta manera, cualquier software que se ejecuta sobre una red LAN, lo hará sobre la capa LANE sin necesidad de modificación alguna. Como resultado tenemos una red LAN emulada (ELAN), la cual está compuesta de clientes (LEC), un servidor de emulación (LES), un servidor de difusión y desconocidos (BUS) y un servidor de configuración LECS. Puede decirse que LANE resuelve entre direcciones MAC y direcciones ATM. Cada elemento de la red tiene una dirección ATM única. Cuando un LEC de origen necesita comunicarse con una dirección MAC perteneciente a un LEC de destino, el LEC de origen realiza una solicitud de resolución de direcciones al servidor LES, el cual responde con la dirección ATM del destino, finalmente, se establece la VCC (Virtual Channel Conection) entre origen y destino. Mientras transcurre todo este proceso, el tráfico de datos en cuestión es atendido por BUS. LECS permite la asignación de nuevos LECs a la ELAN y su asociación con el LES. LANE resulta una solución óptima para conexiones UBR y ABR, sin embargo, al mantener ocultos los detalles de la red ATM, impide que los atributos de QoS de ATM estén disponibles a los protocolos de la capa de red [8].

4.2 IP sobre ATM clásico (CLIP)

Es una especificación de la IETF, RFC 2225 [9], según la cual IP trata a ATM como otra subred en la que se tienen computadoras (host), así como enrutadores. Múltiples subredes IP, en adelante LIS (Logical IP Subnetwork), componen la red ATM. Una LIS se caracteriza por que todos sus host usan el mismo prefijo de red IP (los mismos números de red y los mismos números de subred).

Se tiene un servidor ATM ARP (ATM Resolution Protocol) para resolver direcciones IP a direcciones ATM dentro de la LIS. En caso de una nueva conexión el host de origen conoce la dirección IP del destino, solicita al servidor ATM ARP resolver esta dirección a la correspondiente dirección ATM para proceder finalmente a establecer una VCC directa a través de ATM.

La principal desventaja de este método consiste en que una VCC entre usuarios de diferentes LIS debe pasar obligatoriamente por cada enrutador, en el cual se hace un nuevo análisis de la dirección IP. Esto limita las posibilidades de QoS ofrecidas por ATM.

4.3 El módelo NHRP (Next-Hop Resolution Protocol)

Definido en el RFC 2332 [10] puede admitir rutas de atajo para eliminar los saltos adicionales que se necesitan en el modelo clásico. Puede emplearse, tanto sobre subredes NBMA no orientadas a conexión (SMDS) como sobre subredes NBMA orientadas a conexión (ATM), de modo que no incluye mecanismos para el establecimiento de la conexión.

En este modelo los host se conocen como NHC (Next Hop Client), también se tienen servidores NHS (Next-Hop server) montados sobre los mismos enrutadores usados en el modelo CLIP. NHRP busca cubrir la desventaja del modelo CLIP, permitiendo encontrar la dirección ATM del NHC destino, de manera que se pueda establecer una VCC directa con el NHC origen. Durante el establecimiento de una comunicación, el NHC origen comienza solicitando a su NHS, mediante el protocolo NHRP, la resolución de la dirección IP del NHC destino a una dirección ATM. El NHS, en caso de no tener a cargo el LIS con el NHC destino, reiniciará el paquete de solicitud de resolución NHRP al siguiente NHS a lo largo del camino de destino. El NHS final resuelve la dirección ATM del NHC destino y la devuelve por el mismo camino mediante el protocolo NHRP. Finalmente, el NHC rigen podrá establecer una VCC directa con el NHC destino.

4.4 MPoA (Multiprotocol over ATM)

Este modelo busca usar las ventajas de NHRP para la comunicación entre LISs (capa 3 modelo OSI) y las de LANE para la comunicación dentro de un mismo LIS (capa 2 del modelo OSI). Los elementos de una red MPoA son los siguientes: los clientes de la red se conocen como MPC (MPoA Client); los enrutadores tienen funciones de servidores y se conocen como MPS (MPoA Server). Estos atienden las solicitudes de resolución de direcciones que llegan en el protocolo NHRP. Los MPCs se comunican con el MPS dentro de una misma LIS a través una ELAN. Es muy normal encontrar una red de datos conectada a la red MPoA para lo cual se usa un dispositivo de borde ED (Edge Device), el cual juega el papel de MPC.

El proceso de establecimiento de una conexión es muy similar al visto en el modelo NHRP. Si una computadora 1 desea establecer una comunicación con una computadora 2, conociendo la dirección IP de ésta, procede a comunicarse con el ED de origen, el cual es a su vez un MPC. Si el MPC-origen detecta que se trata de un flujo con larga vida intentará establecer una VCC con el MPC-destino para lo cual solicitará la resolución de la dirección IP a una dirección ATM usando el protocolo NHRP que viajará por una cadena de servidores MPS hasta llegar al MPS de destino. Este último devolverá al MPC-origen la dirección ATM del MPC-destino, el cual es a su vez un ED para la red LAN que contiene a la computadora 2. En caso de una comunicación con paquetes de corta duración, no se establecerá una VCC directa, sino una conexión similar al modelo CLIP [11].

5. Modelos de ip sobre atm en ambientes multicast

Inicialmente, el IP sobre ATM clásico no ofrecía soporte multicast. Esto fue introducido posteriormente con la introducción del servidor MARS (Multicast Address Resolution Server). MARS ofrece soporte para la traducción de direcciones IP multicast en un conjunto de direcciones ATM unicast, ya que la tecnología ATM no proporciona direcciones multicast. Cuando un nodo quiere enviar un mensaje a una dirección IP multicast de la que no sabe la correspondiente dirección ATM unicast, el nodo debe realizar una consulta a un servidor MARS.

El estándar MARS define dos posibles escenarios. El centralizado está basado en la existencia de un servidor de multicast (Multi Cast Server, MCS), y todos los emisores que envían tráfico a un grupo multicast establecen una conexión con una misma máquina, que es raíz de un único circuito multipunto compartido hacia los miembros del grupo. El segundo escenario es el distribuido (VC mesh), donde cada emisor realiza una consulta al servidor de MARS para obtener las direcciones ATM de los miembros del grupo, abriendo posteriormente un circuito multipunto directamente con ellos.

Los entornos MCSs son más eficientes y ofrecen un control centralizado. Cuando se presenta un cambio en un grupo de multidifusión solo se necesitan actualizar las conexiones con los MCS.

Por otra parte, el uso de MCS puede ser decisivo cuando se presenta tráfico sensible al retardo.

La principal diferencia entre IPv4 e Pv6 sobre redes ATM, radica en el hecho de que IPv6 realiza traducción de direcciones unicast de capa 3 a capa 2, de forma contraria a IPv4 que delega este proceso a otros módulos como el Address Resolution Protocol (ARP) o ATMARP.

Por otro lado, IPv6 asume una tecnología de red subyacente broadcasty no orientada a la conexión [12].

6. Conclusiones

La integración de IPv6 y ATM permite garantizar la QoS en una red, de manera que se aprovecha el control sobre los parámetros de QoS que proporciona ATM, como la gran expansión y conectividad de que goza IP.

IPv6 proporciona mayor facilidad de clasificar los paquetes con identificadores de tráfico. Los paquetes o flujos son diferenciados a través de varios parámetros tales como la dirección de origen o destino, DSCP, o los valores de precedencia IP y los tipos de protocolos de nivel superior. Por tanto, si el flujo pertenece a una clase de tráfico que requiere un servicio garantizado, será necesario mapear las características del flujo IPv6 en los parámetros de tráfico de los canales virtuales ATM (VC), que transportaran el flujo.


Referencias

[1] K. Basu, F. Ball and D. Kouvatsos. "Simulation Study of IPv6 to ATM Flow Mapping Techniques," Simulation Symposium, Seattle. July. 2002.        [ Links ]

[2] Internet Engineering Task Force, "IP Version 6 Working Group (IPv6)," IETF. [En línea]. Disponible en: http://www.ietf.org/html.charters/ipv6-charter.html        [ Links ]

[3] S. Deering and R. Hinden. "RFC 2460. Internet Protocol, Version 6 (IPv6) Specification," [En línea]. Disponible en: http://www.ietf.org/rfc/rfc2460.txt        [ Links ]

[4] C. Popoviciu, E. Levy-Abegnoli and P. Grossetete. Deploying IPv6 Networks, Indianapolis: Cisco Press, 2006.        [ Links ]

[5] H. Ortega, C. Villabona y W. Castellanos. "IP sobre ATM -clave en la convergencia de las comunicaciones," I Seminario Convergencia: El nuevo escenario de las telecomunicaciones. Universidad Industrial de Santander. Bucaramanga, Mar. 2002 [En línea]. Disponible en: http://www.geocities.ws/jhiguera/IP_o_ATM.pdf.        [ Links ]

[6] The ATM Forum. [En línea]. Disponible en: http://www.atmforum.com        [ Links ]

[7] Y. Donoso y A. López. "Características de la interconexión entre ATM e IP utilizando IP clásico," Ingeniería & Desarrollo. Universidad del Norte, vol.5, pp. 15-26, Mar. 1999 [En línea]. Disponible en: http://ciruelo.uninorte.edu.co/pdf/ingenieria_desarrollo/5/caracteristicas_de_la_interconexion.pdf        [ Links ]

[8] ATM and T. Ring LANE. [En línea]. Disponible en: http://www.cisco.com/univercd/cc/td/doc/product/lan/trsrb2/atmelan.htm        [ Links ]

[9] M. Laubach. "RFC 2225. Classical IP and ARP over ATM," Newbridge Networks. [En línea]. Disponible en: ftp://ftp.rfc-editor.org/in-notes/rfc2225.txt        [ Links ]

[10] Red Grupo de Trabajo G. Armitage, RFC 2269. NBMA Next Hop Resolution Protocol (NHRP), [En línea]. Disponible en: http://www.faqs.org/rfcs/rfc2269.html        [ Links ]

[11] H. Vatiainen, J. Harju, H. Koivisto, S. Saaristo and J. Vihervaara "Multi-Protocol Over ATM (MPOA): Performance Test," Department of Information Technology, [En línea]. Disponible en: http://www.atm.tut.f/faster/mpoa/eunice-final.pdf.        [ Links ]

[12] J. Silva, S. Duarte, N. Veiga and F. Boavida, "MEDIA -An approach to an efficient integration of IPv6 and ATM multicast environments," Universidade de Coimbra, Departamento de Engenharia Informática. [En línea]. Disponible en: http://cisuc.dei.uc.pt/lct/dlfle.php?fin=171_pub_SaSilva.pdf        [ Links ]

Creative Commons License All the contents of this journal, except where otherwise noted, is licensed under a Creative Commons Attribution License