SciELO - Scientific Electronic Library Online

 
vol.16 issue32Optimization of a neural architecture for the direct control of a boost converterKAnBAN allocation in a serial suply chain 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.16 no.32 Bogotá Apr./June 2012

 

Propuesta de interconexión mediante técnicas de entunelamiento de islas IPv6 a través de una infraestructura de core MPLS/IPv4 con enrutadores de distribución doble pila

An interconnection proposal using IPv6-island tunneling techniques over an MPLS/IPv4 core infrastructure - double-stack distribution routers deployment

Danilo López1, Cesar Hernández2, Octavio Salcedo3

1 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
2 Ingeniero Electrónico, Magister en Ciencias de la Información y las Comunicaciones. Docente e investigador de la Universidad Distrital Francisco José de Caldas. Bogotá, Colombia. cahernandezs@udistrital.edu.co
3 Ingeniero en Sistemas, Magister 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

Fecha de recepción: Agosto 18 de 2011 Fecha de aceptación: Febrero 27 de 2012


Resumen

Las técnicas de entunelamiento han sido ampliamente utilizadas para la interconexión de Islas IPv6 a través de infraestructuras de Core nativo MPLS IPv4. Sin embargo, debido a la limitación de escalabilidad, es usual adoptar otras estrategias de interconexión como 6PE o 6VPE, las cuales resultan mucho más complejas de implementar. El presente artículo propone e implementa a nivel de simulación mediante GNS3+Dynamips una solución que hace uso de las técnicas de entunelamiento en los PE (Provider Edge) (del tipo Doble Pila) de la red, reduciendo así los inconvenientes de escalabilidad propios del mallado de túneles en los enrutadores CE (Customer Edge) y sin la mayor complejidad y requerimientos en cuanto a equipos propios de las soluciones 6PE y 6VPE.

Palabras clave: enrutadores de distribución, GNS3+Dynamips, Islas IPv6, Nucleo MPLS/IPv4, Técnicas de entunelamiento.


Abstract

The tunneling techniques have been widely used to interconnect IPv6 islands over native MPLS Core Infrastructure IPv4. However, due to limited scalability, it is usual to adopt other strategies as 6PE or 6VPE interconnection, which are much more complex to implement.

This article proposes and implements level simulation using GNS3+Dynamips, a solution that makes use of tunneling techniques in the PE (Provider Edge) (type double-stack) of the network, reducing the drawbacks of the mesh scalability own tunnels on routers CE (Customer Edge) and without the complexity and requirements regarding proper equipment and solutions 6VPE 6PE.

Key words: distribution routers, GNS3+Dynamips, IPv6 islands, Core MPLS/IPv4, Tunneling techniques


1. Introducción

Las técnicas de entunelamiento han sido una de las estrategias de implementación clave para proveedores de servicio y empresas durante el periodo de coexistencia entre IPv4 e IPv6 [1], sin embargo sus inconvenientes de escalabilidad y su difícil diagnóstico en caso de fallas limitan su utilización a casos en que el número de Islas IPv6 a interconectar no resulta demasiado grande o no se prevé su aumento; momento en el cual se debe, o bien cambiar la solución de interconexión por 6PE o 6VPE [2] (lo cual involucra el cambio de los PE de la red por unos del tipo Doble Pila; además del soporte de VPNv6 en el caso de 6VPE) o la migración a redes con soporte de IPv6 de forma nativa (etapa última de la coexistencia entre IPv4 e IPv6).

Con el fin de mitigar los inconvenientes propios de la solución con túneles en los enrutadores de Acceso (CE) de la red, en este artículo se propone la configuración de los mismos para la interconexión de Islas IPv6 a través de una infraestructura de Core MPLS IPv4, en los enrutadores de Distribución (PE) de la red (Fig. 1), con lo cual se logra reducir el número de túneles (automáticos o manuales) a configurar, además de mejorar la capacidad de diagnóstico de fallos mediante la herramienta de trazado de ruta IPv6, sin los mayores requerimientos en cuanto a configuración propios de las soluciones con 6PE y 6VPE.

Al igual que en el caso de 6PE y 6VPE, el mallado de túneles en los PE de la red necesita que estos sean del tipo Doble Pila, de forma que recibe los enlaces nativos IPv6 de los enrutadores de Acceso y corre IPv4 hacia el Core MPLS de la red.

Dicha propuesta de interconexión se implementó en una red emulada mediante GNS3+Dynamips (haciendo uso de túneles Manuales, GRE, 6to4 e IPv6 Compatible IPv4) [3], y se comparó su rendimiento para la misma red interconectada con el mallado de túneles en los CE de la red.

2. Metodología

A partir del esquema de diseño de tres capas (Core, Distribución y Acceso), se propone la interconexión de cinco Islas IPv6 (Redes 11::/64, 22::/64, 33::/64, 44::/64, 55::/64 interconectadas a través de interfaces Fast Ethernet a CE1, CE2, CE3, CE4 y CE5 respectivamente), conformando así la capa de Acceso. En la Fig. 2 se detallan las direcciones LAN asignadas a tales interfaces en los CE de la red.

2.1 Core MPLS/IPv4

El Core MPLS de la red (rectángulo detallado en la Fig. 2) está conformado por tres enrutadores de Distribución (PE1, PE2 y PE3, los cuales son el punto de entrada a la red MPLS) y dos enrutadores de Core (P1 y P2).

Los cinco enrutadores de acceso y los tres de distribución se interconectaron (es decir a nivel WAN) mediante enlaces Seriales con un reloj configurado a 128 Kbps en los enrutadores de Distribución (DCE) y con encapsulación PPP; a las cuales se le asignaron direcciones IPv6 mostradas en la Fig. 2 (interfaces seriales en los CE y PE). Las interconexiones MPLS entre los enrutadores de Distribución y Core se emularon por medio de enlaces GigaEthernet con LDP para la distribución de etiquetas MPLS.

Para el direccionamiento en el Core y Distribución MPLS se hizo uso de un rango privado (P1 y P2; y PE1, PE2 y PE3 respectivamente) con las redes 172.16.1.X/30, así como la asignación de direcciones de Loopback a los enrutadores de Core y Distribución de la forma 172.20.20.X/32 de acuerdo a la Fig. 2.

Como protocolo de ruteo IPv4 de la red se escogió OSPF, pretendiendo así no limitar el tipo de enrutadores en la red (a sólo Cisco al hacer uso de EIGRP) y al mismo tiempo asegurando la escalabilidad de la red.

2.2 Direccionamiento y Protocolos de Ruteo IPv6 en la Red

2.2.1 Túneles Manuales y GRE

Dadas las semejanzas de los túneles Manuales y GRE, se asignó el mismo direccionamiento y protocolos de ruteo IPv6 para estas dos técnicas. Cabe mencionar que las direcciones fuente y destino en cada túnel configurado (del tipo IPv4) fueron las IPv4 de Loopback de cada PE; además, dado que este tipo de túneles requiere de una IPv6 por cada extremo configurado, se asignaron 6 direcciones de forma manual (ya que con este tipo de solución para la interconexión es necesaria la creación de un túnel en cada enrutador (en este caso cada PE) por cada par de enrutadores a interconectar). Particularmente, para conocer el número de Túneles Manuales o GRE necesarios para interconectar determinado número de Islas IPv6 se puede utilizar la siguiente expresión:

Donde n es el número de PE's a los cuales se vinculan las Islas IPv6 a interconectar. Las direcciones IPv6 configuradas en los extremos de cada Túnel se muestran en la Tabla 1.

Los tipos de túneles Manuales y GRE (es decir manuales) equivalen para el IOS en el que se configuran a un enlace IPv6 (tal como un enlace Ethernet, Serial, etc) y por tanto permiten correr cualquier protocolo de ruteo IPV6 soportado por el IOS sobre el túnel. En el caso de IS-ISv6, sólo es soportado mediante GRE [4] sin mecanismos adicionales, o bien haciendo uso de BGP4+ en cualquiera de las técnicas de entunelamiento.

En aras de estandarizar la red diseñada, la cual cuenta con OSPF como protocolo de ruteo IPv4, se optó por OSPFv3 como protocolo de ruteo IPv6 en la red, el cual se configuró en dos áreas, así (ver Fig. 3:

  • Área 0 en las interfaces túnel configuradas.
  • Área 1 en las interfaces Fast Ethernet (LAN) de los CE's y a nivel WAN en las interfaces seriales de los CE's y PE's.

Enseguida se detalla el equivalente punto a punto IPv6 entre PE1 y PE2 (en este caso interconectando CE1 con CE3), así como la asignación de áreas para OSPFv3 de acuerdo con el esquema de direccionamiento en la Tabla 1 para el caso de Túneles Manuales y GRE:

2.2.2 Túneles Automáticos/Dinámicos (6to4 e IPv6 compatibles IPv4)

A diferencia de los túneles Manuales y GRE (del tipo Punto a Punto), los túneles dinámicos 6to4 e IPv6 Compatibles IP tienen la característica de ser del tipo Punto a Multipunto y por ende no es necesario configurar un mayado de n•(n-1) túneles, como en el caso Punto a Punto para la interconexión de Islas IPv6 (Ec. 1), sino únicamente n Túneles (siendo n el número de PE's de la red), los cuales necesitan solamente una dirección fuente IPv4 (en este caso la dirección IP de Loopback del enrutador), y utilizan las direcciones IPv4 embebidas en las direcciones IPv6 de los túneles para encontrar el otro extremo del túnel dinámico (direcciones del prefijo 2002::/16 con 6to4y del pref jo 0::/96).

Al hacer uso de túneles 6to4, dichas direcciones IPv6 deben ser configuradas manualmente y a partir de la conversión a hexadecimal de las direcciones IPv4 fuente de los túneles configurados; mientras que con túneles IPv6 Compatibles IPv4 estas direcciones son obtenidas automáticamente a partir de las direcciones IPv4 fuente asignadas a los túneles(para la topología implementada se requieren de 3túneles en cada caso, uno por cada PE).A continuación se muestra el direccionamiento resultante de las implementaciones con túneles 6to4 e IPv6 Compatibles IPv4:

Cabe indicar que el segundo y tercer cuarteto de las direcciones IPv6 asignadas en la solución con túneles 6to4 resultan de la conversión de las direcciones fuente de cada túnel (en este caso las de Loopback en los PE) a hexadecimal, y el prefijo /45 se debe al número de bits en binario iguales de las direcciones fuente de los túneles a que harán parte de la solución, siendo este el mayor prefijo conectado para proveer conectividad a las tres IPv6 relativas a la solución (también es posible la asignación de los prefijos menos específicos como /44, /43, etc.).

Dado que los IGP's (Interior Gateway Protocols) IPv6 como OSPFv3, RIPng e EIGRPv6 intercambian actualizaciones de ruteo entre las interfaces Link Local IPv6, el esquema de encapsulación 6to4 (y de forma similar con Túneles IPv6 Compatibles IPv4) con direcciones derivadas IPv4 no permite correr dichos protocolos de ruteo; no obstante, los procesos de encaminamiento de BGP utilizan pares TCP para intercambiar los actualizaciones de ruteo y las sesiones TCP se pueden establecer entre cualquier dirección IPv6, por lo que BGP sí puede correr en este tipo de solución y redistribuir rutas de las Islas a interconectar.

A pesar de que las soluciones dinámicas, además de funcionar mediante BGP4+ (Extensiones Multiprotocolo de BGP) [5], [6], funciona con rutas por default, se optó por implementar la solución con BGP4+ y distribuir rutas de OSPFv3 en cada PE (Fig. 4), pretendiendo así contar con las ventajas del ruteo dinámico para los dos escenarios de interconexión mediante túneles dinámicos.

Por tanto se configuraron los sistemas autónomos (AS) 65001, 65002 y 65003 en los enrutadores PE1, PE2 y PE3 respectivamente para la utilización de BGP.

A continuación se muestra el equivalente IPv6 de la red (omitiendo las direcciones IPv6 de los túneles) para el caso de la interconexión entre CE1 y CE3 (a través de PE1 y PE2) con túneles dinámicos de acuerdo a la asignación de Sistemas Autónomos y mostrando la vecindad EBGP a través de la cual se distribuyen rutas de OSPFv3 del área 1 (ver Fig. 4).

3. Resultados

La implementación de la propuesta de interconexión a partir del mallado de túneles en los enrutadores de Distribución PE con sus 4 variantes requirió el uso de 2 tipos de enrutadores Cisco soportados por GNS3+Dynamips; los cuales fueron el Cisco 3745 (con IOS c3745-adventerprisek9mz.124-18.bin) para los 5 enrutadores de Acceso (CE's) y el Cisco 7206VXR NPE-400 (con IOS c7200-jk9s-mz.124-13b.bin) para los 5 enrutadores de Core + Distribución (2 de Core [P1 y P2] y 3 de Distribución [PE's]).

En cuanto a requerimientos de configuración fue necesario el uso de 6 Túneles Manuales y GRE (reemplazar n por 3 en la Ec. 1) frente a 3 Túneles 6to4 e IPv6 Compatibles IPv4 para garantizar la conectividad de las cinco Islas IPv6 dispuestas en la topología de prueba.

Haciendo uso de los accesos por consola a los CE se realizaron pruebas de ping IPv6 (con tamaño de 1280 bytes, equivalente al mínimo tamaño de link MTU de IPv6) a las LAN (FastEthernet0/0) de cada sitio remoto tomando como dirección fuente la LAN de cada CE.A continuación se muestran los resultados de dichas pruebas para el caso del enrutador CE1 (en las cuatro topologías implementadas) (Tabla 4).

Para ambos casos se realizaron 2000 y 6000 repeticiones en los Ping LAN a LAN de 2 Saltos y 4 Saltos respectivamente (entre CE1 y CE2, y entre CE1 y: CE3, CE4 y CE5).

Cabe resaltar que los resultados obtenidos para el caso de la configuración de túneles en los enrutadores de Acceso CE se obtuvieron a partir de una infraestructura de Core MPLS IPv4 idéntica a la utilizada en el diseño del presente artículo, y sólo difieren a nivel WAN, siendo del tipo IPv6 en el caso del mallado de túneles en los PE de la red, e IPv4 nativa en el caso del mallado de túneles en los CE de la red [7].

Por último, se realizaron mediciones del Jitter en la red a partir de un debug en CE1 durante la realización de pruebas de ping IPv6 (50 paquetes de 1280 bytes, 25 y 25 hacia CE3 y CE4 respectivamente para cada técnica de entunelamiento). A continuación se muestran las gráf cas de Jitter, así como una tabla con el Jitter mínimo, promedio y máximo de acuerdo a las figuras:

El rendimiento en cuanto a retardos de la red propuesta (Tabla 4) mejora en el caso de pings LAN a LAN con distancia de 2 saltos entre sí (entre CE1 y CE2) hasta en un 33% frente a la solución con túneles en los CE de la red, debido a que ahora este tipo de conexión es IPv6 nativa y no se requiere encapsular en los CE de la red; sin embargo al comparar estas mismas mediciones en el caso de pings LAN a LAN con distancia de 4 saltos entre sí, se observa un descenso en el rendimiento (alrededor de un 7% superior), lo cual resulta contradictorio con el hecho de que el overhead debido a los túneles ahora no se experimenta en toda la red sino solamente en el tránsito entre PE's, además de adjudicarle la encapsulación a equipos más poderosos que los que antes realizaban la encapsulación ( 7200 con 256 MB de RAM frente a 3745 con 128 MB de RAM) en el caso de la solución con túneles en los CE de la red); aunque en este caso se presume que se debe al hecho de que procesos similares en enrutadores con diferentes RAM por defecto (o incluso gamas de enrutadores diferentes) en el emulador conducen a mayores procesamientos en el sistema que se emulan los equipos y por tanto el efecto en el rendimiento de la red.

Al analizar las gráficas de la Fig. 5 se observa que el Jitter IPv6 de la red tiene un comportamiento en su mayor parte del tipo tranciente [8], el cual se asocia al intercambio de información de ruteo, y caracterizado por variaciones significativas en su magnitud y que afectan a no más de un paquete consecutivo.

Finalmente, al comparar el Jitter IPv6 (Tabla 5) resultante de la propuesta de interconexión con el obtenido del mallado de túneles en los CE de la red [7], se encontró que tanto los valores máximos como mínimos del Jitter en ambos caso no varían significativamente, mientras que los valores promedio en el primer caso se mejoran al hacer uso de GRE e IPv6 Compatible IPv4 (21,9 ms vs 24,8 ms y 28,9 ms vs 29,3 ms respectivamente), y se empeoran al hacer uso de túneles Manuales y 6to4 (28,8 ms vs 26,4 ms y 31,6 vs 28,7 ms respectivamente), aunque no empeoran lo suficiente como para salirse del rango recomendado de 100 ms para VoIP en un solo sentido en la red(con el fin de ser compensado efectivamente en el receptor mediante el uso de búferes Jitter [9]). Cabe mencionar que los valores de variación del retardo se obtuvieron a partir de los tiempos de ida y vuelta en la red, por ende en el mejor de los casos el Jitter en un sentido sería la mitad de los valores obtenidos (suponiendo un aporte igual en el recorrido de ida como de vuelta al Jitter total).

4. Conclusiones

Se implementó una propuesta para la interconexión de Islas IPv6 a través de una infraestructura de Core MPLS IPv4 partiendo del mallado de túneles en los enrutadores de Distribución PE (del tipo Doble Pila) de la red, con lo cual se mitigan los inconvenientes de la excesiva configuración de túneles en los enrutadores de Acceso CE de la red, así como se mejora la capacidad de diagnóstico de la red al hacer uso de la herramienta de Traceroute IPv6 (ahora no sólo retorna un único salto [dirección final para un trazado a las LAN de las Islas IPv6 a interconectar], sino tres saltos [WAN PE, extremo final del túnel, y por último la dirección LAN buscada]).

El número de túneles configurados con la solución propuesta se reducen de 20 a 6 túneles en el caso Manual, y de 5 a 3 túneles en el caso Automático/Dinámico (con la misma reducción de sistemas autónomos a configurar al utilizar ruteo dinámico) para la topología de red implementada. La solución propuesta conduce a reducciones en la configuración de túneles (frente a la solución con túneles en los enrutadores de Acceso CE de la red) siempre y cuando el número de CE's sea mayor al número de PE's en la red, e involucra la misma cantidad de túneles configurados en el caso de que exista un PE por cada CE (Isla IPv6) a interconectar en la red.

La propuesta de interconexión que hace uso del mallado de túneles en los PE de la red conduce en general a implementaciones en redes reales más baratas en cuanto a equipos (suponiendo costos similares en PE's y PE's Doble Pila), debido a que los requerimientos de soporte de BGP4+ (en el caso de túneles dinámicos con soporte de ruteo dinámico) involucran en el caso de la solución con túneles en los CE de la red, equipos de Acceso de gamas medias o altas; requerimientos que ahora son suplidos por los PE de la red (usualmente en dichas gamas) y los CE de la red ahora sólo requieren el soporte de IPv6 (mientras el mallado de túneles en los CE de la red requiere que estos sean del tipo Doble Pila).


Referencias

[1] M. Tatipamula, P. Grossetete, H. Esaki, "IPv6 Integration and Coexistence Strategies for Next-Generation Networks". On Communications Magazine, IEEE. Volume 42 Issue 1, (January 2004), pp. 88-96.        [ Links ]

[2] P. Grossetete, "IPv6 over MPLS Cisco IPv6 Provider Edge Router (6PE) Cisco IPv6 VPN Provider Edge Router (6VPE)". Cisco Exposition, 2006, [En linea], Disponible en: http://www.cisco.com/en/US/prod/collateral/iosswrel/ps6537/ps6553/prod_presentation0900aecd80311df4.pdf, pp. 4-9.        [ Links ]

[3] Técnicas de Tunneling para la interconexión de Islas IPv6 sobre una estructura de Core IPv4, [En linea], Disponible en: http://www.cisco.com/en/US/docs/ios/ipv6/coniguration/guide/ip6-tunnel.html        [ Links ]

[4] Cisco Files. "Interconnecting IPv6 Domains Using Tunnels", [En linea]. Disponible en: http://www.ipv6-tf.com.pt/implementacoes/files/cisco/ipv6_InterconnectingIPv6DomainsUsingTunnels.pdf        [ Links ]

[5] P. Marques, F. Dupont, "Use of BGP-4 Multiprotocol Extensions for IPv6 Inter-Domain Routing" RFC 2545, March 1999.         [ Links ]

[6] D. López, N. Gelvez, L. Pedraza, "Modelo para la integración de redes IPv4-IPv6 basado en túneles", Tecnura, Vol. 13, no. 27, pp. 52-59, dic. 2010.        [ Links ]

[7] J.P Gil, "Interconexión de Islas IPv6 a través de una Infraestructura de Core MPLS/ IPv4 a partir de técnicas de Entunelamiento mediante el emulador GNS3+Dynamips".         [ Links ]

[8] VoIP Troubleshooter LLC. "Indepth: Jitter", [en línea], consultado en Marzo 2011. Disponible: http://www.voiptroubleshooter.com/indepth/jittersources.html        [ Links ]

[9] Voip-Info.org. "VOIP Quote. VOIP QoS Requirements", [en línea]. Disponible en: http://www.voip-info.org/wiki/view/QoS.        [ Links ]

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