<?xml version="1.0" encoding="ISO-8859-1"?><article xmlns:mml="http://www.w3.org/1998/Math/MathML" xmlns:xlink="http://www.w3.org/1999/xlink" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<front>
<journal-meta>
<journal-id>2227-1899</journal-id>
<journal-title><![CDATA[Revista Cubana de Ciencias Informáticas]]></journal-title>
<abbrev-journal-title><![CDATA[Rev cuba cienc informat]]></abbrev-journal-title>
<issn>2227-1899</issn>
<publisher>
<publisher-name><![CDATA[Editorial Ediciones Futuro]]></publisher-name>
</publisher>
</journal-meta>
<article-meta>
<article-id>S2227-18992013000100005</article-id>
<title-group>
<article-title xml:lang="es"><![CDATA[VPLS: alternativa de interconexión a través del backbone IP/MPLS de ETECSA]]></article-title>
<article-title xml:lang="en"><![CDATA[VPLS: alternative of interconnection through ETECSA´s IP/MPLS backbone]]></article-title>
</title-group>
<contrib-group>
<contrib contrib-type="author">
<name>
<surname><![CDATA[Barreto Prieto]]></surname>
<given-names><![CDATA[Osmel]]></given-names>
</name>
<xref ref-type="aff" rid="A01"/>
</contrib>
</contrib-group>
<aff id="A01">
<institution><![CDATA[,Centro de Investigación y Desarrollo de Electrónica y Mecánica  ]]></institution>
<addr-line><![CDATA[La Habana ]]></addr-line>
<country>Cuba</country>
</aff>
<pub-date pub-type="pub">
<day>00</day>
<month>03</month>
<year>2013</year>
</pub-date>
<pub-date pub-type="epub">
<day>00</day>
<month>03</month>
<year>2013</year>
</pub-date>
<volume>7</volume>
<numero>1</numero>
<fpage>32</fpage>
<lpage>43</lpage>
<copyright-statement/>
<copyright-year/>
<self-uri xlink:href="http://scielo.sld.cu/scielo.php?script=sci_arttext&amp;pid=S2227-18992013000100005&amp;lng=en&amp;nrm=iso"></self-uri><self-uri xlink:href="http://scielo.sld.cu/scielo.php?script=sci_abstract&amp;pid=S2227-18992013000100005&amp;lng=en&amp;nrm=iso"></self-uri><self-uri xlink:href="http://scielo.sld.cu/scielo.php?script=sci_pdf&amp;pid=S2227-18992013000100005&amp;lng=en&amp;nrm=iso"></self-uri><abstract abstract-type="short" xml:lang="es"><p><![CDATA[La Empresa de Telecomunicaciones de Cuba (ETECSA) maneja en condiciones de exclusividad la infraestructura de telecomunicaciones del país, por lo que el resto de los proveedores necesitan utilizar dicha infraestructura como soporte para la interconexión de los nodos que componen sus redes. Teniendo en cuenta el desarrollo de las tecnologías de las telecomunicaciones, ETECSA ha apostado por la implementación de un backbone Internet Protocol over MultiProtocol Label Switching: Protocolo de Internet sobre Conmutación Multiprotocolo basada en Etiquetas) en su red, el cual se espera absorba todos los servicios actualmente soportados por el backbone Asynchronous Transfer Mode/Frame Relay. Sin embargo, en estos momentos, la red IP/MPLS solamente oferta servicios Virtual Private Network: a nivel de red (nivel tres del modelo OSI), cuestión que, para los otros proveedores, resulta inadmisible. El presente artículo describe una propuesta de implementación de una entidad Virtual Private LAN Service: Servicio de LAN Privada Virtual) como alternativa para la migración de los servicios de Virtual Private Network de nivel dos que actualmente se soportan sobre el backbone ATM/Frame Relay, hacia el backbone Internet Protocol MultiProtocol Label Switching, variante que garantiza la independencia por parte de los proveedores que son clientes de ETECSA en la operación y enrutamiento de su red.]]></p></abstract>
<abstract abstract-type="short" xml:lang="en"><p><![CDATA[The Cuban Telecommunications Enterprise (ETECSA) owns exclusively the whole telecommunication infrastructure in the country. Because of that, other services providers need to use its network as a support for the interconnection of the nodes which form part of its own networks. Attending to the development of telecommunication technologies, ETECSA has invested on the implementation of an IP/MPLS (Internet Protocol over MultiProtocol Label Switching) backbone for its network, which is supposed to absorb all the services that are supported by the ATM (Asynchronous Transfer Mode)/Frame Relay backbone. However, at the moment this network supports level three services (according to OSI model), which is unacceptable for the other providers, due to the management requirements of the routing policies of the services they provide. This article describes a proposal of implementation of a VPLS (Virtual Private LAN Service) entity as an alternative for the migration of the level two VPN services that are supported at present over the ATM/Frame Relay backbone, toward the IP/MPLS backbone. This entity guarantees the operation and routing independence for the service providers that are clients of ETECSA.]]></p></abstract>
<kwd-group>
<kwd lng="es"><![CDATA[IP/MPLS]]></kwd>
<kwd lng="es"><![CDATA[independencia en el enrutamiento]]></kwd>
<kwd lng="es"><![CDATA[migración]]></kwd>
<kwd lng="es"><![CDATA[VPLS]]></kwd>
<kwd lng="en"><![CDATA[IP/MPLS]]></kwd>
<kwd lng="en"><![CDATA[VPLS]]></kwd>
<kwd lng="en"><![CDATA[migration]]></kwd>
<kwd lng="en"><![CDATA[routing independence]]></kwd>
</kwd-group>
</article-meta>
</front><body><![CDATA[ <p align="right"><font face="Verdana, Arial, Helvetica, sans-serif" size="2"><B>ART&Iacute;CULO    ORIGINAL</B></font></p>     <p>&nbsp;</p>     <p><font face="Verdana, Arial, Helvetica, sans-serif" size="4"><b>VPLS: alternativa    de interconexi&oacute;n a trav&eacute;s del backbone IP/MPLS de ETECSA</b></font></p>     <p>&nbsp;</p>     <p><font face="Verdana, Arial, Helvetica, sans-serif"><b><font size="3">VPLS:    alternative of interconnection through ETECSA&acute;s IP/MPLS backbone</font></b></font></p>     <p>&nbsp;</p>     <p>&nbsp;</p>     <P><font face="Verdana, Arial, Helvetica, sans-serif"><b><font size="2">Osmel    Barreto Prieto</font></b> </font>      <P><font size="2" face="Verdana, Arial, Helvetica, sans-serif">Centro de Investigaci&oacute;n    y Desarrollo de Electr&oacute;nica y Mec&aacute;nica &ldquo;CID MECATRONICS&rdquo;    Sitio en 15 esquina 86A, Playa, La Habana, Cuba</font><font face="Verdana, Arial, Helvetica, sans-serif">.    <font size="2">E-mail: <a href="mailto:cid3@reduim.cu">cid3@reduim.cu</a></font></font>      <P>&nbsp;</p>     ]]></body>
<body><![CDATA[<P>&nbsp;</p> <hr>     <P><font size="2" face="Verdana, Arial, Helvetica, sans-serif"><B>RESUMEN</B></font>      <P><font size="2" face="Verdana, Arial, Helvetica, sans-serif">La Empresa de Telecomunicaciones    de Cuba (ETECSA) maneja en condiciones de exclusividad la infraestructura de    telecomunicaciones del pa&iacute;s, por lo que el resto de los proveedores necesitan    utilizar dicha infraestructura como soporte para la interconexi&oacute;n de    los nodos que componen sus redes. Teniendo en cuenta el desarrollo de las tecnolog&iacute;as    de las telecomunicaciones, ETECSA ha apostado por la implementaci&oacute;n de    un backbone Internet Protocol over MultiProtocol Label Switching: Protocolo    de Internet sobre Conmutaci&oacute;n Multiprotocolo basada en Etiquetas) en    su red, el cual se espera absorba todos los servicios actualmente soportados    por el backbone Asynchronous Transfer Mode/Frame Relay. Sin embargo, en estos    momentos, la red IP/MPLS solamente oferta servicios Virtual Private Network:    a nivel de red (nivel tres del modelo OSI), cuesti&oacute;n que, para los otros    proveedores, resulta inadmisible. El presente art&iacute;culo describe una propuesta    de implementaci&oacute;n de una entidad Virtual Private LAN Service: Servicio    de LAN Privada Virtual) como alternativa para la migraci&oacute;n de los servicios    de Virtual Private Network de nivel dos que actualmente se soportan sobre el    backbone ATM/Frame Relay, hacia el backbone Internet Protocol MultiProtocol    Label Switching, variante que garantiza la independencia por parte de los proveedores    que son clientes de ETECSA en la operaci&oacute;n y enrutamiento de su red.</font>      <P> <font size="2" face="Verdana, Arial, Helvetica, sans-serif"><B>Palabras clave:    </B>IP/MPLS, independencia en el enrutamiento, migraci&oacute;n, VPLS. </font>  <hr> <font size="2" face="Verdana, Arial, Helvetica, sans-serif"><B>ABSTRACT</b></font>      <P><font size="2" face="Verdana, Arial, Helvetica, sans-serif">The Cuban Telecommunications    Enterprise (ETECSA) owns exclusively the whole telecommunication infrastructure    in the country. Because of that, other services providers need to use its network    as a support for the interconnection of the nodes which form part of its own    networks. Attending to the development of telecommunication technologies, ETECSA    has invested on the implementation of an IP/MPLS (Internet Protocol over MultiProtocol    Label Switching) backbone for its network, which is supposed to absorb all the    services that are supported by the ATM (Asynchronous Transfer Mode)/Frame Relay    backbone. However, at the moment this network supports level three services    (according to OSI model), which is unacceptable for the other providers, due    to the management requirements of the routing policies of the services they    provide. This article describes a proposal of implementation of a VPLS (Virtual    Private LAN Service) entity as an alternative for the migration of the level    two VPN services that are supported at present over the ATM/Frame Relay backbone,    toward the IP/MPLS backbone. This entity guarantees the operation and routing    independence for the service providers that are clients of ETECSA.</font>      <P> <font size="2" face="Verdana, Arial, Helvetica, sans-serif"><B>Key words:    </B>IP/MPLS, VPLS, migration, routing independence. </font>  <hr>     <p>&nbsp;</p>     <p>&nbsp;</p>     <p><font face="Verdana, Arial, Helvetica, sans-serif" size="3"><b>INTRODUCCI&Oacute;N</b></font>  </p>     <p><font face="Verdana, Arial, Helvetica, sans-serif"><B><font size="2">Descripci&oacute;n    general de las VPNs</font></B></font></p>     ]]></body>
<body><![CDATA[<P><font size="2" face="Verdana, Arial, Helvetica, sans-serif">Una VPN es, como    lo indica su nombre, una Red Privada Virtual, la cual utiliza una tecnolog&iacute;a    de t&uacute;nel para transmitir los datos de usuarios de un lado a otro de la    red del ISP (del ingl&eacute;s, Internet Services Provider) a la que est&aacute;    conectada (Mitchell, 2011). La palabra &quot;t&uacute;nel&quot; se usa para    simbolizar el hecho que los datos est&eacute;n cifrados desde el momento que    entran a la VPN hasta que salen de ella. Gracias a esto, la informaci&oacute;n    transmitida es incomprensible para cualquiera que no se encuentre en uno de    los extremos de la VPN, tal y como si los datos viajaran a trav&eacute;s de    un t&uacute;nel. De esta manera, cuando un usuario necesita acceder a la red    privada virtual, su solicitud se transmite cifrada al sistema de pasarela, que    se conecta con la red remota mediante la infraestructura de red p&uacute;blica    como intermediaria. </font>      <P><font size="2" face="Verdana, Arial, Helvetica, sans-serif">Una VPN basada    en MPLS es aquella que utiliza los LSP (del ingl&eacute;s, Label Switch Path)    como tecnolog&iacute;a de t&uacute;nel para el cifrado de sus datos. Para entender    el funcionamiento de una VPN de este tipo, se hace imprescindible familiarizarse    con los t&eacute;rminos utilizados en el argot t&eacute;cnico. Entre los m&aacute;s    significativos se encuentran: (Rosen and Rekhter, 2006). </font>      <P><font size="2" face="Verdana, Arial, Helvetica, sans-serif">- Router P (Provider:    Proveedor): router interno de la red del proveedor de servicios. </font>      <p><font face="Verdana, Arial, Helvetica, sans-serif" size="2">- Router PE (Provider    Edge: Proveedor de Borde): router del proveedor de servicios que se encuentra    en la frontera de su red. Atiende a uno o varios CEs.</font></p>     <p><font face="Verdana, Arial, Helvetica, sans-serif" size="2">- Router CE (Customer    Edge: Cliente de Borde): router del cliente que se encuentra en la frontera    de su red. Est&aacute; conectado directamente con la red proveedor de servicios    y que se encarga de la distribuci&oacute;n de la informaci&oacute;n de la red    cliente. Pueden existir varios CE para un usuario, pero un CE s&oacute;lo pertenece    a uno de ellos.</font></p>     <p><font face="Verdana, Arial, Helvetica, sans-serif" size="2">- Sitios: subredes    internas de un cliente que se encuentran separadas f&iacute;sicamente pero unidas    l&oacute;gicamente a trav&eacute;s de una VPN.</font></p>     <p><font face="Verdana, Arial, Helvetica, sans-serif" size="2">- Tablas de informaci&oacute;n    de usuario: elemento esencial para lograr privacidad entre VPNs. Estas tienen    car&aacute;cter individual para cada usuario y para cada sitio de usuario. Dichos    sitios se interconectan a trav&eacute;s de LSPs individuales, lo cual permite    dicha privacidad. El contenido de cada una depende del tipo de VPN a la cual    brinda soporte.</font></p>     <P><font size="2" face="Verdana, Arial, Helvetica, sans-serif">La <a href="#f1">Figura    1</a> ilustra tres VPNs basadas en MPLS coexistentes sobre una misma estructura.    En ella se destacan los elementos que garantizan la privacidad de los datos    de las mismas: las tablas de informaci&oacute;n de usuario. </font>      <P align="center"><font face="Verdana, Arial, Helvetica, sans-serif"><a name="f1"></a><img src="/img/revistas/rcci/v7n1/f0105113.jpg" width="518" height="278">    </font>      <P><font size="2" face="Verdana, Arial, Helvetica, sans-serif"><B>M&eacute;todos    cient&iacute;ficos:</B> </font>      ]]></body>
<body><![CDATA[<p><font face="Verdana, Arial, Helvetica, sans-serif" size="2"><em>M&eacute;todos    te&oacute;ricos:</em></font></p>     <p><font face="Verdana, Arial, Helvetica, sans-serif" size="2">- Hist&oacute;rico    l&oacute;gico para investigar el desarrollo hist&oacute;rico de la conmutaci&oacute;n    multiprotocolo basada en etiquetas, con el objetivo de facilitar el an&aacute;lisis    del escenario existente en el backbone IP/MPLS de ETECSA.</font></p>     <p><font face="Verdana, Arial, Helvetica, sans-serif" size="2">- An&aacute;lisis    y s&iacute;ntesis, para arribar a conclusiones mediante el estudio de la bibliograf&iacute;a,    analizar la conmutaci&oacute;n multiprotocolo basada en etiquetas, los elementos    que la componen, caracter&iacute;sticas y facilidades que brinda y adaptarlas    a las necesidades de un proveedor de servicios.</font></p>     <p><font face="Verdana, Arial, Helvetica, sans-serif" size="2">M&eacute;todos    emp&iacute;ricos:</font></p>     <p><font face="Verdana, Arial, Helvetica, sans-serif" size="2">- Entrevistas a    los compa&ntilde;eros del Centro de Gesti&oacute;n de ETECSA para caracterizar    el estado actual de la conexi&oacute;n de los nodos de las redes de los ISPs    clientes de ETECSA y del backbone IP/MPLS, con vista a determinar posibles soluciones    para la utilizaci&oacute;n de este &uacute;ltimo como medio de conexi&oacute;n    para los nodos de dichas redes.</font></p>     <p><font face="Verdana, Arial, Helvetica, sans-serif" size="2">- Observaci&oacute;n    para la acumulaci&oacute;n de datos relacionados con las configuraciones de    los dispositivos de interconexi&oacute;n.</font></p>     <p> <font face="Verdana, Arial, Helvetica, sans-serif" size="2">- Entrevistas    a los compa&ntilde;eros del Centro de Gesti&oacute;n de ETECSA para caracterizar    el estado actual de la conexi&oacute;n de los nodos de las redes de los ISPs    clientes de ETECSA y del backbone IP/MPLS, con vista a determinar posibles soluciones    para la utilizaci&oacute;n de este &uacute;ltimo como medio de conexi&oacute;n    para los nodos de dichas redes.</font></p>     <p><font face="Verdana, Arial, Helvetica, sans-serif" size="2"><B>Materiales y    recursos tecnol&oacute;gicos</B></font></p>     <p><font face="Verdana, Arial, Helvetica, sans-serif" size="2">Para el desarrollo    de la presente investigaci&oacute;n fue necesario contar con recursos tecnol&oacute;gicos,    como computadoras con acceso a Internet para la consulta y b&uacute;squeda de    informaci&oacute;n relacionada con el est&aacute;ndar MPLS y la configuraci&oacute;n    de VPLS. Se necesit&oacute; adem&aacute;s, contar con la posibilidad de intercambiar    informaci&oacute;n con especialistas en la administraci&oacute;n de redes de    proveedores de servicios y de ETECSA, los cuales facilitaron el an&aacute;lisis    de la situaci&oacute;n actual de interconexi&oacute;n de estas redes.</font></p>     <p>&nbsp;</p>     ]]></body>
<body><![CDATA[<p><font face="Verdana, Arial, Helvetica, sans-serif" size="2"><B><font size="3">DESARROLLO</font></B></font></p>     <P><font size="2" face="Verdana, Arial, Helvetica, sans-serif">Las VPN basadas    en MPLS pueden clasificarse de distintas formas. Lo m&aacute;s com&uacute;n    es basar la clasificaci&oacute;n en el nivel del servicio que se est&aacute;    ofreciendo al cliente. Esto da lugar a las siguientes categor&iacute;as: (Doyle,    2008).</font>      <P><font size="2" face="Verdana, Arial, Helvetica, sans-serif">- VPNs capa tres:    son tambi&eacute;n conocidas como Red Privada Virtual Enrutada (VPRN: Virtual    Private Routed Network). El proveedor de servicios participa en el enrutamiento    capa tres del usuario. - VPNs capa dos: el proveedor interconecta los sitios    de usuario a trav&eacute;s de la simulaci&oacute;n de una tecnolog&iacute;a    capa dos (usualmente ATM, Frame Relay o Ethernet) elegida por &eacute;l. El    usuario implementa el protocolo capa tres que desee emplear, sin la participaci&oacute;n    del proveedor de servicios a ese nivel.</font>      <P><font size="2" face="Verdana, Arial, Helvetica, sans-serif">Dentro de las VPNs    capa dos existen dos tipos:</font>      <P><font size="2" face="Verdana, Arial, Helvetica, sans-serif">- VPN capa dos    multipunto: Servicio de Red de &Aacute;rea Local Privada Virtual (VPLS, del    ingl&eacute;s, Virtual Private LAN Service). A trav&eacute;s de este servicio,    desde el punto de vista del usuario, el proveedor act&uacute;a como un switch    Ethernet. El atractivo del mismo para los usuarios radica en que pueden hacer    que su WAN funcione como una red de campus o red LAN, mediante el uso de una    sola tecnolog&iacute;a (Ethernet), que es barata y conocida. </font>      <P><font size="2" face="Verdana, Arial, Helvetica, sans-serif">- VPN capa dos    punto a punto: L&iacute;nea Arrendada Virtual (VLL, del ingl&eacute;s, Virtual    Leased Line). Provee conectividad capa dos punto a punto entre dos sitios. Cualquier    tecnolog&iacute;a de nivel dos (Ethernet, TDM, ATM, etc.) puede ser encapsulada    dentro de dichas l&iacute;neas virtuales. </font>      <P><font size="2" face="Verdana, Arial, Helvetica, sans-serif">A continuaci&oacute;n    se describen brevemente las ventajas que trae consigo la implementaci&oacute;n    de una VPN capa dos basada en MPLS con respecto a la implementaci&oacute;n de    una VPN del mismo tipo, pero de nivel tres: (Networks, 2008). </font>      <P><font size="2" face="Verdana, Arial, Helvetica, sans-serif"><i>- </i>Separaci&oacute;n    de las responsabilidades administrativas: el proveedor de servicios es s&oacute;lo    responsable de la conectividad capa dos, y el usuario, de la conectividad capa    tres, la cual incluye el enrutamiento. Con esta separaci&oacute;n, adem&aacute;s,    las fallas generadas por el usuario quedan aisladas de la red proveedora.</font>      <P><font size="2" face="Verdana, Arial, Helvetica, sans-serif"><i>- </i>Seguridad    y privacidad en el enrutamiento: como la informaci&oacute;n de enrutamiento    no es importada de los PEs, como sucede en las VPN capa tres, &eacute;stos no    pueden procesar ni obtener informaci&oacute;n del enrutamiento dentro de la    VPN del usuario.</font>      <P><font size="2" face="Verdana, Arial, Helvetica, sans-serif"><i>- </i>Soporte    multiprotocolo natural: la red proveedora no participa en el intercambio de    informaci&oacute;n de enrutamiento de los usuarios, por lo cual puede soportar    m&uacute;ltiples protocolos como IP, IPX, SNA, entre otros.</font>      ]]></body>
<body><![CDATA[<P><font face="Verdana, Arial, Helvetica, sans-serif" size="2">entro de las variantes    de VPNs analizadas, las de nivel dos son las que proveen una separaci&oacute;n    completa entre la red del proveedor de servicios y la del usuario, debido a    que no hay intercambio de rutas entre los dispositivos CE y PE. Por tanto, una    VPN de este tipo permitir&aacute; alcanzar la independencia de enrutamiento    que requiere un proveedor de servicios que utilice al backbone IP/MPLS de ETECSA    como medio de interconexi&oacute;n de los nodos de su red. </font>      <P><font face="Verdana, Arial, Helvetica, sans-serif" size="2"><B>MPLS L2 VPN    punto-multipunto: VPLS</B> </font>      <P><font face="Verdana, Arial, Helvetica, sans-serif" size="2">VPLS, tambi&eacute;n    conocido como servicio de LAN transparente (TLS, del ingl&eacute;s, Transparent    LAN Service), es una VPN punto a multipunto de capa dos que permite conectar    m&uacute;ltiples sitios de usuario a trav&eacute;s de la simulaci&oacute;n de    una red de &aacute;rea local (LAN, del ingl&eacute;s, <em>Local Area Network</em>)    <em>Ethernet</em>. Todos los sitios del cliente pertenecientes a una entidad    VPLS parecen estar en la misma LAN, sin importar sus localizaciones, tal y como    si estuvieran interconectadas a trav&eacute;s de un gran conmutador <em>Ethernet</em>.    </font>      <P><font size="2" face="Verdana, Arial, Helvetica, sans-serif">VPLS se basa en    el re-env&iacute;o de tramas <em>Ethernet</em>. La red del proveedor de servicios,    por tanto, puede re-enviar la informaci&oacute;n bas&aacute;ndose solamente    en sus direcciones MAC o teniendo en cuenta adem&aacute;s las etiquetas de LAN    virtual (<em>Virtual LAN Tag</em>, seg&uacute;n su denominaci&oacute;n en ingl&eacute;s).    Es por ello que los <em>routers</em> PE deben soportar todas las prestaciones    &ldquo;cl&aacute;sicas&rdquo; Ethernet, como aprendizaje de direcciones MACs,    inundaci&oacute;n (del ingl&eacute;s, <em>flooding</em>) de tramas, etc. Desde    un punto de vista funcional, esto implica que los PEs deben implementar un puente    o <em>bridge</em> (seg&uacute;n su denominaci&oacute;n en ingl&eacute;s) por    cada instancia VPLS. Este es conocido como puente virtual (VB, del ingl&eacute;s,    <em>virtual bridge</em>). La funcionalidad VB se lleva a cabo en el PE mediante    la asignaci&oacute;n de una VFT para cada entidad VPLS. </font>      <p><font size="2" face="Verdana, Arial, Helvetica, sans-serif">Los elementos necesarios    para constituir una entidad VPLS, como es de esperar, son los mismos que componen    una MPLS L2 VPN de manera general: una red central MPLS, <em>routers</em> CEs    y PEs, circuitos de conexi&oacute;n (AC), puentes virtuales (VB, del ingl&eacute;s,    <em>Virtual Bridge</em>), t&uacute;neles y <em>pseudowires</em>. Los puentes    virtuales no son m&aacute;s que las tablas virtuales de re-env&iacute;o (VFT)    anteriormente mencionadas. Por otra parte, la definici&oacute;n de <em>pseudowire</em>    es utilizada para denominar a una entidad bidireccional de conexi&oacute;n entre    <em>routers</em> PEs compuesta por dos circuitos virtuales (VC) o LSPs unidireccionales    y de sentidos opuestos. El resto de la nomenclatura mantiene su mismo significado.</font></p> <font size="2" face="Verdana, Arial, Helvetica, sans-serif">El AC que posibilita  dicha conexi&oacute;n puede ser tanto un enlace <em>Ethernet</em> f&iacute;sico  o l&oacute;gico, un PVC ATM transportando tramas <em>Ethernet</em> o incluso un  PW <em>Ethernet</em>. Con esto se simplifica la frontera LAN/WAN y se logra un  aprovisionamiento r&aacute;pido y flexible del servicio. La <a href="/img/revistas/rcci/v7n1/f0205113.png">Figura  2</a> muestra la estructura descrita anteriormente.</font>      <p><font face="Verdana, Arial, Helvetica, sans-serif" size="2">El n&uacute;cleo    de la red IP/MPLS interconecta los PEs que intervienen en la entidad VPLS en    cuesti&oacute;n pero no participa realmente en su funcionalidad. El tr&aacute;fico    en este segmento se conmuta simplemente bas&aacute;ndose en etiquetas MPLS.    </font> </p>     <P><font size="2" face="Verdana, Arial, Helvetica, sans-serif">Para el intercambio    de informaci&oacute;n entre dos <em>routers</em> PEs se establecen dos circuitos    virtuales (LSPs), uno en cada direcci&oacute;n. Estos t&uacute;neles internos    son los mencionados PWs. La arquitectura <em>pseudowire</em> est&aacute; normalizada    por Grupo de Trabajo para PWE3 (del ingl&eacute;s, <em>Pseudowire Emulation    Edge to Edge</em>), perteneciente a la IETF, en el RFC 3985. (Bryant and Pate,    2005).</font>      <P><font size="2" face="Verdana, Arial, Helvetica, sans-serif">Para cada entidad    VPLS se crea una malla completa de t&uacute;neles internos (PWs) entre todos    los PEs que participan en la entidad VPLS. Gracias a estos, las tramas pueden    ser transmitidas directamente desde el PE de entrada hacia el de salida sin    pasar por ning&uacute;n otro PE intermedio. No es necesario entonces implementar    ning&uacute;n protocolo de prevenci&oacute;n de bucles, como el <em>Spanning    Tree Protocol</em> (STP, por sus siglas en ingl&eacute;s), <em>Multiple Spanning    Tree Protocol</em> (MSTP, por sus siglas en ingl&eacute;s), o <em>Rapid Ring    Protection Protocol </em>(RRPP, por sus siglas en ingl&eacute;s). Con la aplicaci&oacute;n    de una simple regla conocida como &ldquo;Split Horizon&rdquo; se prev&eacute;    cualquier lazo que pueda ocurrir en una entidad VPLS. Dicha regla plantea que    ning&uacute;n PE debe re-enviar a trav&eacute;s de un PW el tr&aacute;fico que    haya recibido a trav&eacute;s de otro PW.</font>      <P><font size="2" face="Verdana, Arial, Helvetica, sans-serif">En el PE es donde    el VPLS comienza y termina y donde se establecen todos los t&uacute;neles necesarios    para conectar con todos los otros PEs. Sus funcionalidades quedan divididas    en dos planos (Huawei, 2007).</font>      <P><font size="2" face="Verdana, Arial, Helvetica, sans-serif"><B>Plano de re-env&iacute;o:</B>    realiza el encapsulado, re-env&iacute;o y desencapsulado de las tramas Ethernet    desde que entran a la red del ISP y hasta que salen de la misma respectivamente.</font>      ]]></body>
<body><![CDATA[<P><font size="2" face="Verdana, Arial, Helvetica, sans-serif"><B>Plano de control:</B>    lleva a cabo el descubrimiento de miembros de una entidad VPLS, el cual puede    ser implementado a trav&eacute;s de una configuraci&oacute;n manual o de forma    autom&aacute;tica a trav&eacute;s de la utilizaci&oacute;n de determinados protocolos.    Dicho plano adem&aacute;s, se encarga de la se&ntilde;alizaci&oacute;n, a trav&eacute;s    de la cual establece, mantiene y elimina los PWs entre PEs pertenecientes a    una entidad VPLS. Estas funciones pueden implementarse mediante la utilizaci&oacute;n    de dos protocolos: el BGP (del ingl&eacute;s, <em>Border Gateway Protocol</em>)    y el LDP (del ingl&eacute;s, <em>Label Distribution Protocol</em>). Dichas variantes    est&aacute;n reflejadas en los RFC de la IETF 4761 y 4762 respectivamente, dando    lugar a dos clasificaciones: VPLS Kompella y VPLS Martini.</font>      <P><font size="2" face="Verdana, Arial, Helvetica, sans-serif">La implementaci&oacute;n    de una entidad VPLS es la soluci&oacute;n que m&aacute;s se ajusta y es m&aacute;s    factible para la interconexi&oacute;n de los nodos de un red de este tipo a    trav&eacute;s del backbone IP/MPLS de ETECSA. La conexi&oacute;n a nivel dos    que esta variante ofrece, garantizar&aacute; la independencia en el direccionamiento    que algunas empresas requieren desde su condici&oacute;n de proveedor de servicios.    Por otra parte, dicha variante posibilita la comunicaci&oacute;n directa entre    los nodos de una red, sin que ello implique que la informaci&oacute;n tenga    que pasar por el nodo central de la misma. Esto se traducir&aacute; en una reducci&oacute;n    de la carga de operaci&oacute;n de los routers presentes en este, y por tanto,    en un aumento de disponibilidad de ancho de banda para las comunicaciones que    obligatoriamente necesiten utilizar el nodo central como medio de acceso, como    es en algunos casos la navegaci&oacute;n web.</font>      <P><font face="Verdana, Arial, Helvetica, sans-serif" size="2"><B>Descripci&oacute;n    del backbone IP/MPLS de ETECSA</B></font>      <p><font face="Verdana, Arial, Helvetica, sans-serif" size="2">La Empresa de Telecomunicaciones    de Cuba ETECSA ha apostado para su desarrollo futuro, al despliegue de una red    IP/MPLS (IP sobre, del ingl&eacute;s, <em>MultiProtocol Label Switching</em>)    como soporte de sus nuevos servicios, la cual abarca todo el territorio nacional.    La <a href="/img/revistas/rcci/v7n1/f0305113.png">Figura 3</a> describe la estructura    de la misma.</font>      <P><font size="2" face="Verdana, Arial, Helvetica, sans-serif">Dicha red consta    de dos niveles. El primero de ellos es el n&uacute;cleo (<em>core</em>, seg&uacute;n    su denominaci&oacute;n en ingl&eacute;s) de la red, el cual est&aacute; constituido    por 8 <em>routers</em> modelo NE40-8E del fabricante Huawei. Estos desempe&ntilde;an    el papel de <em>routers</em> de n&uacute;cleo (P), o sea, son <em>routers</em>    de conmutaci&oacute;n de alto de rendimiento basado en etiquetas. En un segundo    nivel se encuentran los <em>routers</em> de borde (PE). Estos son igualmente    del fabricante Huawei, modelo NE40-8. Este equipamiento permite la implementaci&oacute;n    de entidades VPLS. (Huawei, 2005). Estos <em>routers</em> no reciben directamente    el tr&aacute;fico de usuario. La informaci&oacute;n de los clientes se concentra    en un flujo &uacute;nico que posteriormente es entregado al NE40-8. Para ello    se utilizan los DSLAMs (<em>Digital Subscriber Line Access Multiplexer</em>).    </font>      <P><font face="Verdana, Arial, Helvetica, sans-serif" size="2"><B>Descripci&oacute;n    de la red de un proveedor de servicios cliente de ETECSA</B></font>      <p><font face="Verdana, Arial, Helvetica, sans-serif" size="2">La redes de los    proveedores de servicios que actualmente utilizan el <em>backbone</em> IP/MPLS    como medio de interconexi&oacute;n de sus nodos cuentan por lo general con un    nodo en cada cabecera de provincia. Estos se encuentran generalmente interconectados    mediante una topolog&iacute;a estrella a trav&eacute;s del <em>backbone</em>    ATM/<em>Frame Relay</em> de ETECSA. Estas redes cuentan adem&aacute;s con un    nodo central desde el que se manejan el resto de los nodos y se accede a servicios    internacionales, como por ejemplo la navegaci&oacute;n web internacional..</font>  </p>     <P><font size="2" face="Verdana, Arial, Helvetica, sans-serif">Los equipos del    fabricante Cisco son extensamente utilizados en los nodos las redes de los proveedores    nacionales. Es por ello que en el estudio se incluy&oacute; la configuraci&oacute;n    requerida en equipos de este tipo, espec&iacute;ficamente en los modelos 3725,    3745, 3825, 3845, 7505 y 7513. Estos tienen una estructura modular que permite    la adici&oacute;n y sustracci&oacute;n din&aacute;mica de interfaces, de forma    tal que este pueda ser adaptado a las necesidades espec&iacute;ficas de sus    usuarios sin que ello implique un cambio total del hardware. Uno de los m&oacute;dulos    posibles a a&ntilde;adir son las tarjetas WIC (WAN<em> Interface Card</em>),    a trav&eacute;s de ranuras de expansi&oacute;n espec&iacute;ficas para este    tipo de tarjetas (Cisco, 2004). </font>      <P><font size="2" face="Verdana, Arial, Helvetica, sans-serif">Los enlaces de    dichos nodos con ETECSA pueden ser tanto <em>Frame Relay</em> como ATM. Estos    pueden ser soportados sobre fibra &oacute;ptica mediante equipos OptiX OSN 3500    que permiten la conexi&oacute;n a la red ASON, o a trav&eacute;s de m&oacute;dem    telef&oacute;nicos de tecnolog&iacute;a xDSL. Estos &uacute;ltimos se conectan    a multiplexores de acceso de l&iacute;nea digital de abonado ATM (DSLAM ATM)    y se encargan de concentrar el tr&aacute;fico de los clientes de la red ATM/Frame    Relay. La <a href="#f4">Figura 4</a> y <a href="#f5">Figura 5</a> ilustra lo    anteriormente planteado: </font>      <P align="center"><font face="Verdana, Arial, Helvetica, sans-serif"><a name="f4"></a><img src="/img/revistas/rcci/v7n1/f0405113.jpg" width="569" height="201">    </font>      ]]></body>
<body><![CDATA[<P align="center"><font face="Verdana, Arial, Helvetica, sans-serif"><a name="f5"></a><img src="/img/revistas/rcci/v7n1/f0505113.jpg" width="552" height="170">    </font>      <P><font face="Verdana, Arial, Helvetica, sans-serif" size="2"><B>Propuestas para    la implementaci&oacute;n de una instancia VPLS</B></font>      <p><font face="Verdana, Arial, Helvetica, sans-serif" size="2"><B>Modificaciones    en la red del usuario</B></font></p>     <p><font face="Verdana, Arial, Helvetica, sans-serif" size="2">El primer punto    a tener en cuenta es si nuestros <em>routers</em> cuentan con interfaces ATM.    En la red de acceso del backbone IP/MPLS son utilizados DSLAMs IP. La comunicaci&oacute;n    con estos est&aacute; basada en tr&aacute;fico ATM. Los DSLAM IP re-ensamblan    las tramas Ethernet a partir de las celdas ATM recibidas de los usuarios, por    lo que resulta imprescindible que nuestros equipos cuenten con interfaces de    este tipo. En caso positivo solo se necesita configurar correctamente dichas    interfaces, de lo contrari&oacute; se necesitar&aacute; adquirir nuevas interfaces.    En los equipos Cisco objetos de estudio, dado su car&aacute;cter modular, resulta    viable la adici&oacute;n de tarjetas de interfaces para redes de &aacute;rea    amplia <em>dual-serial WIC-2T </em>(<em>Wide Area Network Interface Card</em>),    t&iacute;picas del equipamiento Cisco. El autor considera que, mediante la adquisici&oacute;n    de tarjetas WIC con funcionalidades de m&oacute;dem SHDSL es posible conectarse    a los <em>routers</em> PE con una estructura como la descrita en la <a href="#f6">Figura    6</a>:</font>      <P align="center"><font face="Verdana, Arial, Helvetica, sans-serif"><a name="f6" id="f6"></a><img src="/img/revistas/rcci/v7n1/f0605113.jpg" width="534" height="210">    </font>      <P><font size="2" face="Verdana, Arial, Helvetica, sans-serif">Se propone entonces    el uso de la tarjeta Cisco <em>Symmetric High-Bitrate DSL High Speed WAN Interface    Card for Cisco Integrated Services Routers G.SHDSL </em>(HWIC-4SHDSL). La misma    se basa la recomendaci&oacute;n G.991.2 de la UIT-T, utilizada igualmente en    los DSLAM IP de ETECSA. Por otra parte, cumple con las normas establecidas en    el RFC 1483, que estandariza los m&eacute;todos para el encapsulamiento de tramas    Ethernet en celdas ATM. Como cada nodo provincial cuenta con dos enlaces, es    factible utilizar una tarjeta que admita la conexi&oacute;n de m&aacute;s de    una l&iacute;nea DSL. La HWIC-4SHDSL, variante de 4 pares de hilos, permite    la conexi&oacute;n de cuatro l&iacute;neas de dos hilos, o de dos l&iacute;neas    de cuatro hilos. Se logra, mediante la utilizaci&oacute;n de los Anexos A y    B de la recomendaci&oacute;n de la UIT-T G.991.2, alcanzar una velocidad m&aacute;xima    de hasta 2.304 Mbps por cada l&iacute;nea de dos hilos, y hasta 4.608 Mbps por    cada l&iacute;nea de 4 hilos. Es posible incluso, mediante la utilizaci&oacute;n    de los Anexos F y G de la recomendaci&oacute;n mencionada, alcanzar velocidades    desde 768 Kbps hasta 5.696 Mbps por cada l&iacute;nea de dos hilos, y desde    1.563 hasta 11.392 Mbps por cada l&iacute;nea de cuatro hilos. Los DSLAMs IP    de ETECSA permiten la combinaci&oacute;n de dos l&iacute;neas de dos hilos como    una &uacute;nica l&iacute;nea de 4 hilos, logrando as&iacute; velocidades superiores    para un mismo enlace. El precio de esta tarjeta en el mercado oscila alrededor    de los &euro; 600. Lamentablemente, la utilizaci&oacute;n de las mismas s&oacute;lo    es factible en los <em>routers</em> de la serie 3800. Para los pertenecientes    a la serie 3700 deber&aacute; utilizarse, por tanto, otra tarjeta: la <em>Cisco    Symmetric High-Bit-Rate DSL Interface Card</em> (WIC-1SHDSLV3). Esta cuenta    con funcionalidades similares, con la diferencia de que s&oacute;lo permite    la conexi&oacute;n de una l&iacute;nea. El costo de estas tarjetas est&aacute;    alrededor de los &euro; 400.</font>      <P><font size="2" face="Verdana, Arial, Helvetica, sans-serif">Como el env&iacute;o    de informaci&oacute;n en una entidad VPLS est&aacute; basado en tramas Ethernet,    resulta imperante encontrar una manera de ensamblar el tr&aacute;fico IP de    cada nodo de provincia en tramas Ethernet. Por otra parte, dichas tramas deber&aacute;n    ser ensambladas en celdas ATM para su re-env&iacute;o a trav&eacute;s de la    l&iacute;nea DSL. Los IOS de los <em>routers</em> Cisco utilizados cuentan con    una funcionalidad que permiten implementar la tarea anteriormente mencionada.    Es posible, mediante la creaci&oacute;n y configuraci&oacute;n de sub-interfaces    ATM llevar a cabo dichas funciones, utilizando para ello el comando atm route-bridge    ip, el cual las realiza siguiendo el m&eacute;todo recogido en el RFC 2684 de    la IETF. El mismo estandariza el encapsulamiento multiprotocolo sobre la capa    de adaptaci&oacute;n ATM AAL5. Se crear&aacute; una sub-interfaz por cada servicio    de nivel tres, garantizando as&iacute; la gesti&oacute;n de los servicios que    se prestan. De esta forma se satisfacen los requerimientos anteriormente planteados.</font>      <P><font size="2" face="Verdana, Arial, Helvetica, sans-serif">En el caso de que    contemos con una conexi&oacute;n a la red ASON, resulta viable enviar directamente    tr&aacute;fico Ethernet sobre dicha interfaz f&iacute;sica, gracias a las posibilidades    de largas distancias que la misma permite para este tipo de tr&aacute;fico.    Los routers utilizados deber&aacute;n contar con interfaces FastEthernet libres,    que puedan ser conectadas a un equipo OptiX OSN 3500, el cual tambi&eacute;n    debe tener interfaces de este tipo disponibles, y de esta forma enlazarse con    el equipo correspondiente de la red MPLS de ETECSA. Deber&aacute;n crearse adem&aacute;s    sub-interfaces y VLANs (Virtual LANs) asociadas a la entidad VPLS. La <a href="#f7">Figura    7</a> refleja la idea planteada:</font>      <P align="center"><font face="Verdana, Arial, Helvetica, sans-serif"><a name="f7" id="f7"></a><img src="/img/revistas/rcci/v7n1/f0705113.jpg" width="575" height="148">    </font>      <P><font size="2" face="Verdana, Arial, Helvetica, sans-serif">Como el <em>backbone</em>    IP/MPLS utiliza DSLAMs IP para el acceso de usuario, deber&aacute;n crearse    nuevas facilidades en estos &uacute;ltimos que permitan la conexi&oacute;n de    los nodos de nuestra red. Es necesario, adem&aacute;s, que dichos equipos retiren    el encapsulado ATM, re-ensamblen las tramas Ethernet y posteriormente las re-env&iacute;en    hacia los PEs correspondientes. Esto se logra mediante la creaci&oacute;n de    VLANs para la transmisi&oacute;n de informaci&oacute;n capa dos desde el DSLAM    hasta el PE a trav&eacute;s de una interfaz Ethernet. Una vez creadas, se hace    una multiplexaci&oacute;n entre los VPIs/VCIs que se reciben por la l&iacute;nea    de cobre y las VLANs anteriormente creadas.</font>      ]]></body>
<body><![CDATA[<P><font face="Verdana, Arial, Helvetica, sans-serif" size="2"><B>Modificaciones    en la red de acceso de ETECSA</B></font>      <p><font face="Verdana, Arial, Helvetica, sans-serif" size="2">Por otra parte,    de existir en nuestra red un enlace a trav&eacute;s de la red ASON, el equipo    de ETECSA que lo atienda deber&aacute; conectar una de sus interfaces FastEthernet    a un switch Ethernet que se conecte con un PE del backbone IP/MPLS. La <a href="#f8">figura    8</a> ilustra las modificaciones mencionadas:</font></p>     <P align="center"><font face="Verdana, Arial, Helvetica, sans-serif"><a name="f8" id="f8"></a><img src="/img/revistas/rcci/v7n1/f0805113.jpg" width="453" height="180">    </font>      <P><font size="2" face="Verdana, Arial, Helvetica, sans-serif">Pasado este punto,    en los PE deber&aacute;n crearse VLANs que tengan el mismo identificador que    las creadas en los DSLAMs y en los <em>routers</em> de nuestra red, de forma    tal que todo el tr&aacute;fico recibido con una etiqueta VLAN X que identifica    a una VLAN X en el DSLAM o en los <em>routers</em>, se identifique en el PE    como perteneciente a la VLAN X en este &uacute;ltimo. Una vez realizadas las    tareas mencionadas, deber&aacute;n crearse sub-interfaces Ethernet por cada    VLAN creada y realizar la asociaci&oacute;n VLAN/sub-interfaz Ethernet. Se estar&aacute;    entonces en condiciones de asociar dichas sub-interfaces con los VFT. El fabricante    del equipamiento en cuesti&oacute;n, ha denominado a las VFB o VB como entidades    de conmutaci&oacute;n virtual (VSI: <em>Virtual Switch Instance</em>). Por tanto,    en lo que sigue, se adoptar&aacute; dicha nomenclatura para lograr homogeneidad    con los comandos que se utilizan. </font>      <P><font face="Verdana, Arial, Helvetica, sans-serif" size="2"><B>Configuraci&oacute;n    de los dispositivos de la red del usuario</B></font>      <p><font face="Verdana, Arial, Helvetica, sans-serif" size="2">La adici&oacute;n    de las nuevas tarjetas WIC a los <em>routers</em> que las necesiten resulta    extremadamente sencilla gracias a la presencia de las ranuras de expansi&oacute;n    en la estructura de los mismos que permiten conectar tarjetas de este tipo directamente.    Se deber&aacute;n apagar los equipos y posteriormente conectar las tarjetas.    Una vez conectadas se deber&aacute; reiniciar el sistema, configurar la interfaz    ATM y comprobar la configuraci&oacute;n. Una vez realizado este &uacute;ltimo    paso, los <em>routers</em> se encuentran listos para utilizar la tarjeta WIC    insertada.</font></p>     <p><font face="Verdana, Arial, Helvetica, sans-serif" size="2">En los <em>routers</em>    que cuenten con enlaces sobre la red ASON se deber&aacute; crear la sub-interfaz    que se utilizar&aacute; para el intercambio, crear una VLAN y asociarla a la    sub-interfaz creada, y finalmente, asignarle una direcci&oacute;n IP a la misma.</font></p>     <p><font face="Verdana, Arial, Helvetica, sans-serif" size="2"><B>Configuraci&oacute;n    de los dispositivos de ETECSA</B></font> </p>     <p><font face="Verdana, Arial, Helvetica, sans-serif" size="2">Los DSLAM IP deber&aacute;n    ser configurados de modo que re-ensamblen las tramas Ethernet y posteriormente    las env&iacute;en al PE correspondiente. Para ello se hace necesario configurar    la interfaz utilizada para comunicarse con el PE, crear los PVCs en los enlaces    a utilizar, configurar la velocidad de los enlaces y el re-ensamblaje de tramas    Ethernet.</font></p>     <p><font face="Verdana, Arial, Helvetica, sans-serif" size="2">Los PEs del <em>backbone</em>    IP/MPLS de ETECSA utilizan el protocolo LDP para la distribuci&oacute;n de etiquetas,    por lo que debe implementarse una VPLS Martini. Antes de pasar a la configuraci&oacute;n    de la entidad VPLS, deben realizarse algunas tareas previas, tales como: configurar    los identificadores de LSR (LSR ID), habilitar MPLS en el sistema, habilitar    la MPLS L2 VPN en los PEs, establecer sesiones LDP remotas entre los PEs si    estos no se encuentran conectados directamente y chequear las configuraciones    anteriores. Una vez logradas, se estar&aacute; entonces en condiciones de configurar    propiamente la entidad VPLS, lo cual incluye: crear una VSI y configurar la    se&ntilde;alizaci&oacute;n LDP, crear la VLAN que se corresponda a la utilizada    en el DSLAM para transmitir la informaci&oacute;n del ISP cliente, asociar un    VSI con un AC y chequear cada uno de las tareas anteriores.</font></p>     ]]></body>
<body><![CDATA[<p><font face="Verdana, Arial, Helvetica, sans-serif" size="2">Los c&oacute;digos    de configuraci&oacute;n para los equipos Cisco y los equipos de ETECSA aparecen    en la tesis de grado nombrada &ldquo;Propuesta de configuraci&oacute;n de una    entidad VPLS como alternativa de interconexi&oacute;n de los nodos de la red    de CITMATEL a trav&eacute;s del <em>backbone</em> IP/MPLS de ETECSA.&rdquo;    (Barreto, 2011).</font></p>     <p><font face="Verdana, Arial, Helvetica, sans-serif" size="2"><B>Ventajas de    la propuesta planteada</B></font> </p>     <p><font face="Verdana, Arial, Helvetica, sans-serif" size="2">En la mayor&iacute;a    de los casos, la interconexi&oacute;n actual de los nodos que componen la red    de los proveedores de servicios nacionales presupone que todo el tr&aacute;fico    tenga que pasar por su nodo central, incluso si, por ejemplo, un usuario atendido    por el nodo de Matanzas desea acceder a un sitio FTP presente en el nodo de    Villa Clara. Esto implica una sobrecarga innecesaria para el equipamiento del    nodo central. Con la estructura totalmente mallada que se logra con la implementaci&oacute;n    de la entidad VPLS propuesta, este problema es solucionado. Cada nodo tendr&aacute;    la posibilidad de comunicarse directamente con cualquier otro, sin que su tr&aacute;fico    tenga que pasar por el nodo central. Esto influye positivamente en el ancho    de banda disponible para algunos servicios, como por ejemplo, los de navegaci&oacute;n    Web internacional, que por lo general tienen que pasar obligatoriamente por    dicho nodo.</font></p>     <p><font face="Verdana, Arial, Helvetica, sans-serif" size="2">Por otra parte,    la sustituci&oacute;n de los enlaces Frame Relay por nuevos enlaces ATM en la    red de acceso, permitir&aacute; aumentar las velocidades de conexi&oacute;n,    y con ello potenciar los servicios que se prestan como ISP. A esto se suman    las bondades que trae consigo la utilizaci&oacute;n de ATM como tecnolog&iacute;a    de nivel de enlace en la &uacute;ltima milla, como por ejemplo, la clasificaci&oacute;n    del tr&aacute;fico en distintas clases de servicio. Esto permite la priorizaci&oacute;n    de determinados tipos de tr&aacute;fico, garantizando as&iacute; una QoS determinada.</font></p>     <p><font face="Verdana, Arial, Helvetica, sans-serif" size="2"><B>Verificaci&oacute;n    de los resultados</B></font> </p>     <p><font face="Verdana, Arial, Helvetica, sans-serif" size="2">La propuesta de    configuraci&oacute;n recogida en este art&iacute;culo, as&iacute; como los comandos    de configuraci&oacute;n anteriormente referenciados, fueron sometidos a discusi&oacute;n    con ejecutivos del nodo central del backbone IP/MPLS de ETECSA y de la UEB de    Operaciones de Internet de CITMATEL, empresa que solicit&oacute; nuestra propuesta    como base para un proyecto de migraci&oacute;n de las conexiones con las que    cuenta actualmente. Ambas partes validaron la factibilidad y aplicabilidad de    la propuesta, para la cual analizaron tanto las posibilidades reales de implementaci&oacute;n    como la idoneidad de las configuraciones de los equipos que se proponen.</font></p>     <P>&nbsp;</p>     <P><font face="Verdana, Arial, Helvetica, sans-serif" size="3"><B>CONCLUSIONES</B></font>      <P><font size="2" face="Verdana, Arial, Helvetica, sans-serif">La migraci&oacute;n    de la interconexi&oacute;n actual de las conexiones soportadas sobre el backbone    ATM/Frame Relay hacia el <em>backbone</em> IP/MPLS resulta inminente, ya que    ETECSA propone que este &uacute;ltimo asuma todos los servicios que se soportan    actualmente sobre el <em>backbone</em> ATM. El estudio presentado en este art&iacute;culo    constituye un proyecto de dise&ntilde;o que recoge de manera eficiente y certera,    los pasos a seguir por el personal administrativo de la red de ETECSA y de un    proveedor de servicios para la migraci&oacute;n de la interconexi&oacute;n de    los nodos que conforman la red de este &uacute;ltimo a trav&eacute;s del <em>backbone</em>    ATM/Frame Relay de ETECSA, hacia una nueva interconexi&oacute;n de los mismos    a trav&eacute;s del <em>backbone</em> IP/MPLS de dicha empresa. A trav&eacute;s    de la variante propuesta, el equipo de administraci&oacute;n de la red de un    proveedor de servicios podr&aacute; afrontar el proceso de migraci&oacute;n    y cumplir con sus expectativas con respecto al manejo de las rutas. </font>    <font size="2" face="Verdana, Arial, Helvetica, sans-serif">Con el desarrollo    de este trabajo, se comprob&oacute; la posibilidad real de implementar una entidad    VPLS sobre la estructura actual del backbone IP/MPLS de ETECSA. Para ello se    tuvo en cuenta tanto las capacidades del equipamiento actual para asumir dicho    cambio, como la factibilidad de las inversiones necesarias para el mismo. </font>      <p>&nbsp;</p>     ]]></body>
<body><![CDATA[<p><font face="Verdana, Arial, Helvetica, sans-serif" size="3"><B>REFERENCIAS    BIBLIOGR&Aacute;FICAS</B></font></p>     <!-- ref --><P><font size="2" face="Verdana, Arial, Helvetica, sans-serif">BARRETO P., O.    Propuesta de configuraci&oacute;n de una entidad VPLS como alternativa de interconexi&oacute;n    de los nodos de la red de CITMATEL a trav&eacute;s del backbone IP/MPLS de ETECSA.    La Habana: CUJAE; 2011.     </font>      <!-- ref --><P><font size="2" face="Verdana, Arial, Helvetica, sans-serif">BRYANT S., PATE    P. RFC 3985: Pseudo Wire Emulation Edge-to-Edge (PWE3) Architecture. 2005. Disponible    en: <a href="http://tools.ietf.org/html/rfc3985" target="_blank">http://tools.ietf.org/html/rfc3985</a>.        </font>      <!-- ref --><P><font size="2" face="Verdana, Arial, Helvetica, sans-serif">CISCO SYSTEM I.    Cisco 3700 Series Multiservice Access Router. 2004. Disponible en: <a href="http://www.cisco.com/en/US/prod/collateral/routers/ps282/product_data_sheet09186a008009203f.pdf" target="_blank">http://www.cisco.com/en/US/prod/collateral/routers/ps282/product_data_sheet09186a008009203f.pdf</a>.        </font>      <!-- ref --><P><font size="2" face="Verdana, Arial, Helvetica, sans-serif">DOYLE J. Understanding    MPLS VPNs, part I. Revista Digital Network World; 2008 [actualizado 2008; consultado    2011, 12 de febrero]; disponible en: <a href="http://www.networkworld.com/community/node/24781" target="_blank">http://www.networkworld.com/community/node/24781</a>.        </font>      <!-- ref --><P><font size="2" face="Verdana, Arial, Helvetica, sans-serif">HUAWEI T. Quidway    NetEngine 40 Configuration Guide - VPN. 2007.    </font>      <!-- ref --><P><font face="Verdana, Arial, Helvetica, sans-serif" size="2">HUAWEI T. Quidway    NetEngine 40 Series Universal Switching Router. 2005.     </font>      <!-- ref --><P><font face="Verdana, Arial, Helvetica, sans-serif" size="2">MITCHELL B. Virtual    Private Networks Tutorial [consultado el: 12 de febrero de 2011]. Disponible    en: [<a href="http://compnetworking.about.com/od/vpn/a/vpn_tunneling.htm" target="_blank">http://compnetworking.about.com/od/vpn/a/vpn_tunneling.htm</a>].        </font>      <!-- ref --><P><font face="Verdana, Arial, Helvetica, sans-serif" size="2">NETWORKS F. IP/MPLS-Based    VPNs: Layer-3 vs. Layer-2. Foundry Networks Magazine. 2008.    </font>      <!-- ref --><P><font face="Verdana, Arial, Helvetica, sans-serif" size="2">ROSEN E., REKHTER    Y. RFC 4364: BGP/MPLS IP Virtual Private Networks (VPNs). 2006. Disponible en:    <a href="http://www.ietf.org/mail-archive/web/ietf-announce/current/msg02120.html" target="_blank">http://www.ietf.org/mail-archive/web/ietf-announce/current/msg02120.html</a>.    </font>      <P>&nbsp;</p>     ]]></body>
<body><![CDATA[<P>&nbsp;</p>     <P><font size="2" face="Verdana, Arial, Helvetica, sans-serif">Recibido: 15/01/2013        <br>   Aceptado: 05/03/2013</font>       ]]></body><back>
<ref-list>
<ref id="B1">
<nlm-citation citation-type="book">
<person-group person-group-type="author">
<name>
<surname><![CDATA[BARRETO P.]]></surname>
<given-names><![CDATA[O.]]></given-names>
</name>
</person-group>
<source><![CDATA[Propuesta de configuración de una entidad VPLS como alternativa de interconexión de los nodos de la red de CITMATEL a través del backbone IP/MPLS de ETECSA]]></source>
<year>2011</year>
<publisher-loc><![CDATA[La Habana ]]></publisher-loc>
<publisher-name><![CDATA[CUJAE]]></publisher-name>
</nlm-citation>
</ref>
<ref id="B2">
<nlm-citation citation-type="">
<person-group person-group-type="author">
<name>
<surname><![CDATA[BRYANT]]></surname>
<given-names><![CDATA[S.]]></given-names>
</name>
<name>
<surname><![CDATA[PATE]]></surname>
<given-names><![CDATA[P.]]></given-names>
</name>
</person-group>
<source><![CDATA[RFC 3985: Pseudo Wire Emulation Edge-to-Edge (PWE3) Architecture]]></source>
<year></year>
</nlm-citation>
</ref>
<ref id="B3">
<nlm-citation citation-type="">
<collab>CISCO SYSTEM I.</collab>
<source><![CDATA[Cisco 3700 Series Multiservice Access Router]]></source>
<year></year>
</nlm-citation>
</ref>
<ref id="B4">
<nlm-citation citation-type="book">
<person-group person-group-type="author">
<name>
<surname><![CDATA[DOYLE]]></surname>
<given-names><![CDATA[J.]]></given-names>
</name>
</person-group>
<source><![CDATA[Understanding MPLS VPNs, part I]]></source>
<year>2008</year>
<publisher-name><![CDATA[Digital Network World]]></publisher-name>
</nlm-citation>
</ref>
<ref id="B5">
<nlm-citation citation-type="">
<collab>HUAWEI T.</collab>
<source><![CDATA[Quidway NetEngine 40 Configuration Guide - VPN]]></source>
<year>2007</year>
</nlm-citation>
</ref>
<ref id="B6">
<nlm-citation citation-type="">
<collab>HUAWEI T.</collab>
<source><![CDATA[Quidway NetEngine 40 Series Universal Switching Router]]></source>
<year>2005</year>
</nlm-citation>
</ref>
<ref id="B7">
<nlm-citation citation-type="">
<person-group person-group-type="author">
<name>
<surname><![CDATA[MITCHELL]]></surname>
<given-names><![CDATA[B.]]></given-names>
</name>
</person-group>
<source><![CDATA[Virtual Private Networks Tutorial]]></source>
<year></year>
</nlm-citation>
</ref>
<ref id="B8">
<nlm-citation citation-type="book">
<person-group person-group-type="author">
<name>
<surname><![CDATA[NETWORKS]]></surname>
<given-names><![CDATA[F.]]></given-names>
</name>
</person-group>
<source><![CDATA[IP/MPLS-Based VPNs: Layer-3 vs. Layer-2]]></source>
<year>2008</year>
<publisher-name><![CDATA[Foundry Networks Magazine]]></publisher-name>
</nlm-citation>
</ref>
<ref id="B9">
<nlm-citation citation-type="">
<person-group person-group-type="author">
<name>
<surname><![CDATA[ROSEN]]></surname>
<given-names><![CDATA[E.]]></given-names>
</name>
<name>
<surname><![CDATA[REKHTER]]></surname>
<given-names><![CDATA[Y.]]></given-names>
</name>
</person-group>
<source><![CDATA[RFC 4364: BGP/MPLS IP Virtual Private Networks (VPNs)]]></source>
<year></year>
</nlm-citation>
</ref>
</ref-list>
</back>
</article>
