Tesis Electrónicas UACh - Universidad Austral de Chile
Anuncio
Universidad Austral de Chile Facultad de Ciencias de la Ingeniería Escuela de Ingeniería Civil Electrónica “ARQUITECTURA E IMPLEMENTACION DE MPLS EN UNA RED DE TELEFONÍA MÓVIL BASADA EN IP” Tesis para optar al Título de: Ingeniero Electrónico Profesor Patrocinante: Sr. Néstor Fierro Morineaud. Ingeniero Electrónico, Licenciado en Ciencias de la Ingeniería, Diplomado en Ciencias de la Ingeniería. HUGO ANDRÉS SANTIBÁÑEZ SOTO VALDIVIA – CHILE 2013 1 MIEMBROS COMISIÓN DE TITULACIÓN Profesor Patrocinante Néstor Fierro Morineaud Ingeniero Electrónico Profesor Informante Profesor Informante Franklin Castro Rojas Pedro Rey Clericus Ingeniero Electrónico Ingeniero Electrónico 2 Agradecimientos A mis padres por la educación entregada a lo largo de mi vida y especialmente a mi novia Paola por toda la comprensión, apoyo e infinita paciencia a través de este largo proceso. Quisiera utilizar esta instancia también para agradecer a toda la gente que se involucró de una u otra manera en este trabajo de titulación, ya sea amigos, familia y profesores en especial a Don Néstor Fierro por su apoyo y guía fundamental en este trabajo. Sin ustedes no lo hubiese podido lograr… Muchas Gracias… 3 RESUMEN El presente trabajo de titulación presenta un análisis detallado de la tecnología IP/MPLS presente hoy en día en Redes de Transporte basadas en paquetes (PTN) y su aplicación en una red de Transporte Mobile Backhaul de producción implementada recientemente a Nivel Nacional. Se da en primera instancia una Visión General de la implementación lógica de MPLS en Redes Corporativas y el porqué de la elección de IP‐MPLS para la implementación de este tipo de Redes. Por otro lado, se realiza la investigación de la implementación física de una red real de producción Mobile Backhaul de un Proveedor de Servicios a Nivel Nacional, para realizar el análisis detallado de la arquitectura y el equipamiento utilizado, además de implementar la solución lógica a nivel de protocolos IP. SUMMARY This graduation work presents a detailed analysis of the IP/MPLS technology present today in Packet‐Based Transport Networks (PTN) and its application in a production Mobile Backhaul Transport Network implemented recently Nationwide. In the first instance is given an overview of the logic implementation of MPLS in Corporate Networks and why the choice of IP‐ MPLS for deploying this kind of Networks. Moreover, research is conducted of the physical and logical implementation of a real Mobile Backhaul Production Network Nationwide, to perform a detailed analysis of the architecture and the equipment used, as well the implementation with IP Protocols. 4 OBJETIVOS GENERALES ‐ Analizar la tecnología de transporte de datos MPLS y sus aplicaciones en redes corporativas. ‐ Evaluar los distintos servicios que pueden ser entregados sobre una red de transporte de datos MPLS y el equipamiento disponible para su implementación. ‐ Especificar la arquitectura para la implementación de la tecnología de transporte de datos MPLS en una red de telefonía móvil corporativa basada en IP (IPRAN). OBJETIVOS ESPECÍFICOS ‐ Investigar en qué consiste el mecanismo de transporte de datos MPLS (Multiprotocol Label Switching). ‐ Analizar los distintos tipos de tráfico que pueden ser transportados dentro de una red de transporte de datos MPLS. ‐ Investigar los protocolos que hacen posible el funcionamiento de una red de transporte MPLS. ‐ Analizar la arquitectura de una red de telefonía móvil corporativa basada en la tecnología de transporte de datos MPLS (IPRAN) y los mecanismos de protección frente a fallas proporcionados por el diseño. ‐ Investigar el equipamiento disponible hoy en día para realizar la implementación de redes de transporte MPLS corporativas. 5 INTRODUCCIÓN Desde que las demandas de ancho de banda de los clientes a los proveedores de servicios en Chile desde el año 2000 en adelante se han incrementado drásticamente, las redes troncales de los proveedores de servicios han debido evolucionar conforme a estos nuevos requerimientos. En el caso de las redes fijas los servicios han ido evolucionando desde una conexión simple de telefonía fija a grandes redes de transmisión de datos sobre el mismo par de cobre donde coexisten TvIP, VoIP y acceso de Banda Ancha. En el caso de las redes móviles, desde los primitivos servicios de solo voz y mensajería de texto hasta los actuales servicios de Banda Ancha Móvil 3G y el futuro 4G LTE. Dado que estos nuevos servicios entregados por los proveedores de Telefonía Móvil requieren mayor ancho de banda y capacidades avanzadas de manejo de tráfico se hizo necesario implementar en Chile nuevos mecanismos de transporte de información, debido a que las redes antiguas TDM y ATM se vieron colapsadas por estas crecientes demandas. Es aquí donde surgen las redes IP/MPLS como solución a estas demandas. Si bien es cierto la inversión que hacen las empresas de Telefonía Móvil (Ej: Claro, Movistar) y Acceso de Banda Ancha Hogar (Ej: Telefónica del Sur, Telefónica) en la compra de este equipamiento son muy altas para la implementación de este tipo de redes troncales, las ganancias a mediano y largo plazo son muy altas, pues pueden implementar una red convergente con multitud de servicios sobre la misma red de transporte (VoIP, Datos, TvIP) lo que les permite aumentar la diversidad de servicios que puede entregar a su clientes; como ejemplo VTR ha pasado de ser un proveedor de servicios de TV por Cable y Telefonía Fija a un proveedor de servicios de Televisión, Telefonía Fija y Telefonía Móvil actualmente, realizando modificaciones en su red de transporte de información. Como otro ejemplo tangible Claro Chile ha estado implementando una nueva red de transporte de información para sus servicios de telefonía móvil 3G y futuro LTE 4G hace poco tiempo basados en la tecnología IP/MPLS. 6 Dada esta motivación se ha escogido realizar en el presente trabajo de titulación el análisis en detalle de la implementación y arquitectura física y lógica de una red transporte de Telefonía Móvil basada en IP/MPLS de un proveedor de servicios en Chile y como las directrices técnicas definidas por un proveedor de equipamiento deben dar solución a las necesidades de los proveedores de Servicios. 7 ÍNDICE Agradecimientos .............................................................................................................................. 2 RESUMEN ......................................................................................................................................... 3 OBJETIVOS GENERALES .................................................................................................................... 4 OBJETIVOS ESPECÍFICOS .................................................................................................................. 4 INTRODUCCIÓN ............................................................................................................................... 5 1. Redes de Transporte Basadas en Paquetes de próxima Generación (PTN) y Visión General de IP‐MPLS en Redes Corporativas ................................................................................................. 11 1.1 La creciente demanda de redes de proveedores de servicios ............................................ 13 1.2 Introducción a MPLS ............................................................................................................ 17 1.3 El valor de la Propuesta MPLS ............................................................................................. 19 1.4 MPLS y las redes Convergentes Multi‐Servicios .................................................................. 23 1.5 Servicios de Negocios con MPLS .......................................................................................... 25 1.6 Utilización de la Arquitectura VPN IP/MPLS para cumplir con los requerimientos de una Red de Servicios ..................................................................................................................... 30 1.7 Aplicaciones VPN IP/MPLS ................................................................................................... 35 1.7.1 Red 2G ........................................................................................................................... 36 1.7.2 Core Móvil para 2G ....................................................................................................... 37 1.7.3 Core Móvil para Redes de Datos (2,5G y 3G) ................................................................ 38 1.7.4 El Transporte Mobile Backhaul ..................................................................................... 39 1.7.5 Componentes de una Red Mobile Backhaul ................................................................. 40 1.7.6 Arquitectura General de Acceso de una red Triple Play ‐ ADSL .................................... 43 1.7.6.1 Red‐Hogar .............................................................................................................. 43 1.7.6.2 Red de Acceso ........................................................................................................ 44 1.7.7 La Solución Triple Play ................................................................................................... 45 1.7.8 La Solución de Red de Retorno Móvil ........................................................................... 47 2. Equipamiento y protocolos utilizados para el despliegue de la tecnología MPLS en una Red Corporativa Mobile Backhaul .................................................................................................... 50 8 2.1 Equipamiento ....................................................................................................................... 51 2.2 Descripción del Equipamiento utilizado en la Red Mobile Backhaul .................................. 51 2.2.1 Características del 7705 SAR ......................................................................................... 54 2.2.2 Router de Servicios 7750 SR (Service Router) ............................................................... 54 2.2.2.1 Descripción General del Router 7750‐SR 7 ............................................................ 55 2.3 Protocolos empleados para la implementación de la solución Mobile Backhaul IP‐MPLS .... 59 2.3.1 MPLS ................................................................................................................................. 59 2.3.2 Protección de tráfico de LSP ............................................................................................. 61 2.3.2.1 Protección de camino – LSPs con Camino Secundario Non‐Standby ........................ 61 2.3.2.2 Protección de Camino – LSPs con Camino Secundario Standby ................................ 62 2.3.2.3 Comportamiento de conmutación de LSP con caminos secundarios ........................ 62 2.4 Información General sobre Fast‐Reroute (FRR) ...................................................................... 64 2.4.1 Métodos FRR para realizar la protección de LSP .............................................................. 64 2.4.1.1 Funcionamiento de los distintos métodos ............................................................ 66 2.5 Métodos de detección de errores en los Enlaces ................................................................... 70 2.5.1 BFD .................................................................................................................................... 70 2.6 Agregación de Enlaces ............................................................................................................. 71 2.7 IP Routing/IGP ......................................................................................................................... 73 2.7.1 Diseño de Extremo a Extremo de OSPF ............................................................................ 74 2.7.2 Otras Consideraciones de diseño OSPF en redes IP‐RAN ................................................. 75 2.7.2.1 ID de Área ................................................................................................................... 75 2.7.2.2 Router ID OSPF ........................................................................................................... 76 2.7.2.3 Autenticación de Enlace OSPF (Opcional) .................................................................. 76 2.7.2.4 Selección del tipo de red OSPF ................................................................................... 76 2.7.2.5 Ingeniería de Tráfico OSPF ......................................................................................... 77 2.7.2.6 Métricas y temporizadores OSPF ............................................................................... 77 2.8 Tráfico Móvil – Modelos de Transporte .................................................................................. 78 2.8.1 2G (TDM) / 3G (ATM) ........................................................................................................ 79 2.8.2 3G y LTE (IP) ...................................................................................................................... 79 9 2.9 Calidad de Servicio ................................................................................................................... 80 2.9.1 Necesidad de Calidad de Servicio ..................................................................................... 80 2.9.2 Diseño de la Calidad de Servicio ....................................................................................... 82 2.9.2.1 Objetivos del Diseño .................................................................................................. 82 2.9.2.2 Clases de Servicio ....................................................................................................... 83 2.9.2.2.1 Clase de Servicio CONTROL ................................................................................. 83 2.9.2.2.2 Clase de Servicio USER CONTROL ........................................................................ 84 2.9.2.2.3 Clase de Servicio REALTIME ................................................................................. 85 2.9.2.2.4 Clase de Servicio BUSINESS DATA ....................................................................... 85 2.9.2.2.5 Clase de Servicio STANDARD ............................................................................... 85 2.9.2.3 Política de Calidad de Servicio de Red ....................................................................... 86 2.9.2.4 QoS en el Acceso ........................................................................................................ 87 3. Implementación de MPLS en una red corporativa, y arquitectura de una red Mobile Backhaul ................................................................................................................................................... 89 3.1 Topología Física .................................................................................................................... 89 3.1.1 Última Milla ................................................................................................................... 92 3.1.2 Agregación ..................................................................................................................... 95 3.1.3 Core ............................................................................................................................... 96 3.2 Topología Lógica .................................................................................................................. 98 3.3 Modelo Lógico de Red ......................................................................................................... 99 3.3.1 Topología Lógica de Servicios utilizados en la red ........................................................ 99 3.3.2 Análisis e implementación de la Topología Lógica y protocolos de red empleados en su configuración .................................................................................................................... 100 3.3.2.1 Configuración Base ............................................................................................... 101 3.3.2.2 Implementación Lógica y Configuración de Servicios .......................................... 112 3.3.2.3 Prueba de Conmutación y Packet‐Loss ................................................................ 129 3.4 Gestor SAM5620 y administración remota de equipamiento .............................................. 133 3.4.1 Evaluación de desempeño de la red en Clúster Valdivia ................................................ 135 3.5 Proyección de la tecnología IP/MPLS a MPLS‐TP en redes PTN‐MPLS ................................. 143 10 3.5.1 Plano de Reenvío ............................................................................................................ 144 3.5.2 Plano de Control ............................................................................................................. 145 4. CONCLUSIONES ........................................................................................................................ 148 REFERENCIAS BIBLIOGRÁFICAS ................................................................................................... 150 GLOSARIO .................................................................................................................................... 151 11 CAPÍTULO 1 ‐ Redes de Transporte Basadas en Paquetes de próxima Generación (PTN) y Visión General de IP‐MPLS en Redes Corporativas En este capítulo se darán a conocer los elementos principales de una Red de Transporte Basada en Paquetes de próxima generación, una visión general de qué es IP‐MPLS en redes corporativas y finalmente los parámetros técnicos y definiciones comúnmente utilizadas dentro de una PTN de próxima generación; si bien es cierto la red que se analizará en los próximos capítulos es en sí una PTN de próxima generación resulta interesante conocer cómo se van consolidando las diferentes tecnologías y su correlación con lo que es una red de transporte IP‐ MPLS que es lo que se muestra dentro de esta nota introductoria. La idea principal que se esconde detrás de este tipo de redes es el transporte de paquetes encapsulados de información a través de internet. Estas nuevas redes son construidas a partir del protocolo IP, siendo el término “all‐IP” (todo‐IP) el más comúnmente utilizado para describir dicha solución. Las redes de próxima generación (NGN en inglés) es un amplio término que está referido a la evolución de la actual infraestructura de redes de telecomunicaciones y acceso telefónico, con el objetivo de lograr la convergencia de los nuevos servicios multimedia (voz, video y datos). Según la ITU‐T “Una Red de Siguiente Generación es una red basada en la transmisión de paquetes capaz de proveer servicios integrados, incluyendo los tradicionales telefónicos, y capaz de explotar al máximo el ancho de banda del canal haciendo uso de las Tecnologías de Calidad del Servicio (QoS) de modo que el transporte sea totalmente independiente de la infraestructura de red utilizada. Además, ofrece acceso libre para usuarios de diferentes compañías telefónicas y apoya la movilidad que permite acceso multipunto a los usuarios” Desde un punto de vista más práctico las Redes de siguiente Generación suponen tres cambios fundamentales en lo que es la arquitectura de una red tradicional que deben ser evaluados de forma independiente: 12 ‐ Respecto al núcleo de red, NGN supone la consolidación de varias redes de transporte (dedicadas u overlay) construidas históricamente a partir de diferentes servicios individuales (normalmente basados en protocolos IP y Ethernet). También implica, entre otras muchas cosas, la migración del servicio de voz desde la tradicional arquitectura conmutada (PSTN) a la nueva VoIP además de la sustitución de las redes tradicionales (legacy‐service) como la X.25 o la Frame Relay. Esto supone incluso una migración para el usuario tradicional hacia un nuevo servicio como es el IP VPN o la transformación técnica de las redes tradicionales. ‐ Respecto a las redes de acceso, NGN supone la migración del canal tradicional dual de voz y datos asociado a las redes xDSL hacia instalaciones convergentes en las que las DSLAMs integren puertos de voz o VoIP, permitiendo de esta forma dejar atrás las actuales redes conmutadas que multiplexan voz y datos por diferentes canales. ‐ Respecto a las redes cableadas, la convergencia NGN implica la migración de la tasa constante de flujo de bits a estándares CableLabs PacketCable que suministren servicios VoIP y SIP. Ambos servicios funcionan sobre DOCSIS como estándar para el cableado. En las Redes de Siguiente Generación existe una separación bien definida entre la porción de red de transporte (conectividad) y los servicios que corren por encima de esa red. Esto quiere decir que siempre que un proveedor telefónico desee habilitar un nuevo servicio, puede hacerlo fácilmente definiéndolo desde la capa de servicio directamente sin tener en cuenta la capa de transporte. Como se ha dicho, los servicios proporcionados serán independientes de la infraestructura de red. La tendencia actual es que estos servicios, incluyendo la voz, se inclinen hacia la independencia de red y normalmente residan en los dispositivos de usuario (teléfono, PC, receptores TDT,...). En la figura siguiente se muestra la correlación entre los principales segmentos de mercado actuales (Móvil, Datos y Fijo) y se denota la importancia del Plano de Transporte (marcado en verde) como conector entre las diferentes tecnologías de Acceso y su plano de Control. 13 Figura 1.1 – Modelo de Referencia NGN 1.1 La creciente demanda de redes de proveedores de servicios Las Redes de proveedores de servicios deben evolucionar para mantenerse a la par con los tiempos cambiantes y los mayores ancho de banda demandados. Los proveedores de servicios a menudo se clasifican por la cantidad de infraestructura de acceso regional que poseen, versus la cantidad que debe contratar a otros proveedores: ‐ Operadores Tier 1 (Nivel 1): Los primeros dos proveedores en un país que por lo general son dueños de la infraestructura de acceso (cobre o fibra) dentro de su región de servicio. Los proveedores de servicios de Nivel 1 suelen ser los primeros en establecer infraestructuras en la región ‐ los grandes operadores. ‐ Operadores Tier 2 o Tier 3 (Nivel 2 o Nivel 3): Son proveedores que pueden usar la infraestructura de acceso de algún operador Tier 1 o construir su propia infraestructura 14 en algunas áreas de servicio. Los proveedores Tier 2 utilizan una combinación de su propia infraestructura y algunas infraestructuras de proveedores Tier 1. Los proveedores Tier 3 dependen por completo de acuerdos para utilizar la infraestructura de otros proveedores. Estos proveedores suelen surgir como competidores a los ya establecidos proveedores Tier 1, por lo que están en desventaja con los proveedores incumbentes (Tier 1) para obtener control del mercado. Los proveedores de servicios están clasificados de acuerdo a los tipos de servicios que ofrecen a sus clientes finales: ‐ Telco: Tradicionalmente ofrecen servicios de voz, así como servicios de negocios ‐ Proveedor de Servicios de Internet (ISP): Ofrecen acceso a Internet para clientes residenciales y de negocios ‐ Proveedor de Servicios VPN / Proveedor de Servicios Ethernet: Ofrecen servicios VPN de negocios ‐ Operador Multi‐Sistema de Cable (MSO): Ofrecen servicios residenciales y de negocios Un operador puede ofrecer todos o algunos de estos servicios a sus clientes finales. Ambos tipos de clientes, residencial (consumidor) y empresariales (negocios) demandan constantemente nuevos servicios e innovaciones de sus proveedores de servicios. Los servicios basados en las líneas tradicionales arrendadas, Frame‐Relay (FR) y ATM son característicos de organizaciones que administran sus propias redes empresariales (con sus propios equipos de TI), pero aquellas empresas deben adquirir la infraestructura de conectividad (típicamente líneas arrendadas punto a punto o conexiones virtuales permanentes Frame‐Relay o ATM) de un proveedor de servicio. Impulsados por los objetivos de negocio de la empresa y dirigidos a centrarse en las competencias básicas y reducción de costos, las empresas han comenzado a buscar a los proveedores de servicios para soluciones de conectividad administradas. 15 Las empresas también han estado exigiendo más en términos de velocidades de ancho de banda para la conectividad. La vieja regla del “80/20” (el 80% del tráfico queda dentro del sitio local y el 20% del tráfico está entre sitios remotos) ya no es válida. Debido a que muchas empresas han consolidado sus centros de datos para algunos sitios, la necesidad de una mayor velocidad de conexión a distancia se ha convertido en algo muy importante para los administradores de TI de las empresas. Además, las empresas están ahora en el proceso de implementación de aplicaciones de uso intensivo de ancho de banda como la videoconferencia, conferencia web y uso compartido de imagen electrónica en una zona amplia, lo que provocó la necesidad de más ancho de banda en sus redes de área extensa (WANs). Los servicios residenciales también están evolucionando de la conectividad a Internet marcada a la conectividad de banda ancha. Los servicios para los clientes residenciales están evolucionando para incluir servicios de triple o cuádruple play que incluyen voz, Video on Demand (VoD), televisión y acceso a Internet. Tradicionalmente, un proveedor de servicios contaba con redes separadas para ofrecer servicios de voz y datos. Dentro de una red de datos, un proveedor de servicio tradicional tendría típicamente redes separadas para ofrecer servicios basados en Líneas Arrendadas, Frame‐Relay y ATM para clientes de negocios y una red separada ofreciendo servicios basados en Internet (Acceso a Internet y conectividad segura basada en Internet) para clientes residenciales y de negocios. En áreas residenciales, los contenidos de TV para clientes son usualmente entregados por MSOs los cuales tienen su propia infraestructura dedicada (casi siempre instalaciones de cable). Las empresas casi siempre utilizan switches Ethernet y routers IP para construir sus propias LAN y obtienen servicios de Líneas Arrendadas de los operadores para conectarse a sus locaciones remotas. 16 Teniendo en cuenta el escenario siempre cambiante de las demanda de los clientes, las redes de proveedores de servicios deben mantener el ritmo por mantener la competitividad y aumentar la rentabilidad. Es evidente que el enfoque de la construcción de redes separadas no es rentable cuando el proveedor de servicios deberá ofrecer múltiples servicios. La forma ideal de abordar el diseño de la red es una solución en la que varios servicios pueden ser convergentes en una única infraestructura de red. Esta es la razón por la cual MPLS como tecnología para redes de proveedores de servicios ha cobrado impulso rápido en el mercado. La tendencia más obvia es el rápido crecimiento del tráfico IP y Ethernet en la red. Debido al auge de Internet, y la invención de Gigabit Ethernet, el tráfico IP/Ethernet es ahora dominante en las redes de telecomunicaciones. Los clientes residenciales requieren servicios más rápidos de acceso a Internet y una mejor calidad de servicio IP para soportar voz sobre IP (VoIP). Los clientes empresariales están llevando a cabo más y más de sus negocios por vía electrónica a través de ubicaciones muy separadas geográficamente. Muchas aplicaciones de uso intensivo de ancho de banda y aplicaciones basadas en IP sensibles al tiempo están siendo ampliamente utilizadas para misiones críticas para los negocios. Los Datos IP se están incrementando en importancia estratégica en las redes inalámbricas. Los usuarios móviles están deseando servicios multimedia basados en IP de manera creciente. Los proveedores de servicios también quieren ofrecer contenidos de televisión a través de aplicaciones de IPTV, que requieren rendimiento de la red con gran ancho de banda y baja latencia. Está claro que la construcción de una red óptima para la entrega de tráfico IP/Ethernet es crucial para los proveedores de servicios. Debido a que las empresas están empezando a utilizar cada vez más aplicaciones basadas en IP/Ethernet, necesitan que sus infraestructuras de IT tengan un alto rendimiento y sean lo más confiables, seguras y rentables. Esto genera una gran demanda de los proveedores de servicios para ofrecer VPN. Las VPN permiten que el proveedor de servicios pueda prestar servicios a diferentes clientes con la 17 misma red troncal, mientras que se aíslan los clientes mediante instancias virtuales de servicios para garantizar la privacidad y la seguridad. Durante las últimas dos décadas, ya había muchas empresas que utilizan la VPN enrutada RFC2547bis para lograr la conectividad de intranet. Ahora, con el rápido crecimiento de la tecnología Ethernet, cada vez más clientes empresariales requieren servicios VPN Ethernet Capa 2. Los servicios VPN Capa 2 entregan a los clientes un control completo de sus dominios de enrutamiento y menos complicaciones de interconexión contra los proveedores de servicios. Los proveedores de servicios también buscan soluciones de redes que consoliden voz, datos y video en una misma infraestructura de red y que les permita atender a los clientes residenciales y de negocios desde la misma red. La red debe ser rentable y robusta. La red también debe ser capaz de proporcionar calidad de servicio diferenciada (QoS) en el servicio proporcionado para adaptarse a diferentes Acuerdos de Nivel de Servicios (Service Level Agreements ‐ SLAs). Con estas nuevas tendencias y demandas, los proveedores de servicios intentarán migrar sus redes a redes de Core IP/MPLS, entregando varios servicios VPN a sus clientes. 1.2 Introducción a MPLS La Conmutación Multi‐protocolo mediante Etiquetas es un mecanismo de conmutación de etiquetas utilizado por switches y routers (capaces de “hablar” en MPLS) para el intercambio de tráfico. En el plano de control, los dispositivos MPLS realizan la asignación de etiquetas que serán utilizadas para ciertos tipos de tráfico y distribuyen las etiquetas a través de ciertos protocolos de distribución de etiquetas. Cada dispositivo distribuye las etiquetas asignadas localmente hacia los otros dispositivos MPLS y recibe la información de distribución de etiquetas desde otros equipos. Cada equipo construye una Base de Información de Etiquetas (LIB – Label Information Base) que almacena la información de las etiquetas. En el plano de datos, cada equipo realiza la encapsulación MPLS sobre el tráfico de datos antes de enviarlo a otros dispositivos MPLS. Cuando un dispositivo recibe el tráfico encapsulado, realiza decisiones de 18 renvío basado en el valor de la etiqueta MPLS en el encabezado de encapsulación MPLS. En la encapsulación de datos MPLS, el encabezado MPLS (32 bits de largo, que contiene un valor numérico de 20 bits utilizado como el valor de la etiqueta) está insertado entre el encabezado de Capa 2 y el encabezado de Capa 3 del dato que va a ser encapsulado. Por lo tanto, MPLS a veces se denomina protocolo de Capa 2.5, y el encabezado MPLS a veces se denomina encabezado de cuña. Antes de que los dispositivos MPLS puedan renviar el tráfico encapsulado a otro equipo se debe completar la distribución de etiquetas MPLS en el plano de control. Cuando se está intercambiando la información de las etiquetas, cada dispositivo MPLS almacena la etiqueta, como también la información de mapeo de la etiqueta para el tipo de tráfico que utiliza cada etiqueta. Todo el tráfico que utiliza la misma etiqueta se denomina como Clase Equivalente de Reenvío (FEC – Forwarding Equivalent Class). El proceso de distribución de etiquetas distribuye la información de mapeo de etiquetas‐FEC entre dispositivos MPLS. Por lo tanto, los dispositivos MPLS forman una Ruta o Camino de Distribución de Etiquetas (LSP – Label Switched Path) para cada FEC. El LSP es una conexión de extremo a extremo para el tráfico perteneciente a la misma FEC que será reenviado. MPLS construye un camino orientado a la conexión en una red no orientada a la conexión. MPLS fue introducido por primera vez para mejorar el rendimiento del enrutamiento en Capa 3 de enrutadores Capa 3 normales. Para un router MPLS o switch Capa 3, el intercambio de etiquetas MPLS que el ruteo de paquetes IP. En una red IP ruteada, los paquetes IP son ruteados desde su origen a su destino salto a salto. Cuando cada router encamina un paquete IP, este quita el encabezado de Capa 2 (usualmente un encabezado Ethernet), luego chequea el encabezado IP para encontrar la dirección IP de destino. Luego el router debe realizar una búsqueda en su tabla de enrutamiento para encontrar la dirección IP de la interfaz para el próximo salto y la información de encapsulación de la interfaz de egreso de Capa 2. Después de que la búsqueda de que se completa la búsqueda del próximo salto, el router re‐escribe el paquete añadiendo el nuevo encabezado de encapsulación de Capa 2 al paquete y luego re‐ envía el paquete a la interfaz del próximo salto. Este procedimiento es realizado por cada 19 paquete IP en cada salto. Con la introducción de la tecnología MPLS los routers pueden construir LSPs MPLS para cada FEC. Todo el tráfico perteneciente a la misma FEC es conmutado por etiquetas MPLS hacia su destino en vez de ruteado. Cuando un Router de Conmutación de Etiquetas (LSR – Label Switched Router) realiza la conmutación MPLS sobre un paquete encapsulado en MPLS, la operación de intercambio de etiquetas MPLS es mucho más simple. Por lo tanto, el proceso de búsqueda de la IP de destino es reemplazado por el relativamente menos costoso proceso de intercambio de etiquetas. La utilización de la conmutación MPLS para remplazar el ruteo IP se denomina a veces atajo de ruteo. Además, el Protocolo de Gateway Fronterizo (BGP – Border Gateway Protocol) puede ser quitado desde el core de la red debido a que los routers LSR en el core de la red no tienen necesidad de encaminar estos paquetes. Siempre que el proceso de distribución de etiquetas MPLS construya el LSP para cada router en el core para alcanzar todos los routers de borde que tienen pares BGP con routers fuera del Sistema Autónomo (AS – Autonomous System), el tráfico a través de la red de core puede ser conmutado a través de MPLS en vez de ruteado a través de IP. El router de core utiliza la etiqueta MPLS para conmutar el tráfico hacia el router de frontera correcto. Se puede quitar también BGP de malla completa (full‐mesh) dentro del sistema autónomo. Solo los routers en la frontera necesitan tener pares BGP contra otros routers. El proceso de distribución de etiquetas utilizado por los dispositivos capaces de interpretar MPLS es en la mayoría de los casos el Protocolo de Distribución de Etiquetas (LDP – Label Distribution Protocol). 1.3 El valor de la Propuesta MPLS MPLS ha evolucionado substancialmente desde los primeros días de su despliegue. Las razones para utilizar MPLS en una red también han cambiado. MPLS ya no ha sido usado para entregar un atajo al ruteo IP. Los dos cambios más grandes en la tecnología MPLS son: El Protocolo de Reserva de Recursos (RSVP) está extendido para soportar la distribución de etiquetas MPLS – RSVP‐TE (donde TE significa ingeniería de tráfico) entrega muchas 20 características de ingeniería de tráfico y características de resiliencia a la tecnología de tunelización MPLS. La VPN Capa2 basada en pseudowire MPLS está implementada en muchos proveedores de routers y switches MPLS. Con estas evoluciones en la tecnología MPLS, MPLS está ahora ampliamente desplegado en las redes troncales de los proveedores de servicios para entregar servicios VPN a sus clientes. La introducción de RSVP‐TE en la distribución de etiquetas MPLS entrega a MPLS flexibilidad excepcional y confiabilidad que las redes tradicionales ruteadas y conmutadas no pueden tener: MPLS entrega capacidades de ingeniería de tráfico para controlar el camino de renvío en la red. Utilizando RSVP‐TE, los routers MPLS pueden señalizar un LSP ruteado explícitamente. El operador puede manualmente especificar el camino y los saltos a lo largo de la ruta del LSP de extremo a extremo. Por lo tanto los operadores pueden manipular el camino del tráfico de datos en la red de la siguiente manera: o En una red solo IP, los paquetes que viajan desde los nodos origen a sus nodos de destino utilizan un camino que está determinado por la información de enrutamiento entregada por los routers IP. Una red sólo IP entrega una pequeña flexibilidad para entregar caminos alternativos al flujo de datos. Una red basada en MPLS soporta ingeniería de tráfico por lo cual un camino MPLS (conexión lógica) puede ser definida para usar enlaces de red que son diferentes al camino normal tomado por los paquetes IP. Esto ayuda a la mejor utilización de los enlaces dentro de una red empresarial. o Con la ayuda de las extensiones de ingeniería de tráfico de los protocolos OSPF (se verá en capítulos posteriores en detalle) e IS‐IS, RSVP‐TE permite el uso del cálculo de túneles MPLS basados en CSPF. Cuando se está realizando el cálculo de la ruta, CSPF puede considerar otros criterios distintos de la métrica de ruteo entregada por el IGP, como la reserva de ancho de banda del enlace y la pertenencia a un grupo de miembros administrativos (coloreo de enlaces) 21 MPLS entrega un excepcional rendimiento en el re‐enrutamiento. Las infraestructuras de red basadas en FR/ATM o redes Ethernet antiguas no pueden ofrecer la rápida convergencia durante la recuperación de una falla. MPLS utiliza mecanismos como el LSP secundario (o de Respaldo) y Fast‐Reroute (FRR) que puede entregar tiempos de re‐ enrutamiento en el orden de los milisegundos: o LSP Secundario – RSVP‐TE soporta el concepto de LSP y LSP‐Path. Este permite hasta ocho caminos LSP que pueden ser aprovisionados dentro del mismo LSP. En circunstancias normales el LSP‐Path (Camino‐LSP) primario reenvía activamente el tráfico; si el LSP‐Path primario falla, uno de los LSP‐Paths secundarios asume el control del tráfico. Cuando se provisiona un LSP‐Path secundario activo, el rendimiento en la recuperación de la falla está en el rango de las decenas de milisegundos. o FRR (Fast Re‐Route) – Cuando se utiliza RSVP‐TE para señalizar un LSP, todos los routers tienen identificada la ruta completa que atraviesa el LSP. Por lo tanto cada router puede señalizar un LSP de protección para tomar un camino lejos del punto potencial de falla. Si ocurre una falla de red, los router MPLS cerca de la falla utilizan el camino de protección pre‐señalizado para proteger el LSP. Esto se denomina MPLS FRR. FRR puede entregar tiempos de recuperación de falla del orden de decimas de milisegundos después de que una falla es detectada. o Las implementación de VPN basadas en pseudowire IP/MPLS hacen posible tomar completa ventaja de la flexibilidad entregada por la MPLS. El nuevo modelo de VPN desacopla el procesamiento nativo de servicios de la encapsulación VPN y permite a los servicios con diferentes características compartir la misma troncal IP/MPLS. Las entidades de acceso de servicios de los servicios específicos del cliente son los encargados de proporcionar tráfico en formato nativo para satisfacer los requisitos del cliente, y las entidades de red de servicios VPN se encargan de realizar la encapsulación VPN y la de‐encapsulación para transportar los servicios a través de la red troncal. 22 Las características de resiliencia como la conmutación de pseudowire y la redundancia de pseudowire aseguran la entrega del servicio de extremo a extremo con la calidad deseada. Con las mejoras de MPLS y los nuevos servicios VPN basados en pseudowire, el proveedor de servicios puede ahora desplegar diferentes tipos de servicios para diferentes clientes en una sola red troncal convergente utilizando la tecnología IP/MPLS. Las redes VPN IP/MPLS tienen las siguientes ventajas: Eficiencia en el costo – Elimina el requerimiento para los proveedores de servicios de construir redes separadas para diferentes tipos de servicios. Todos los servicios están compartidos en la misma infraestructura de la red troncal. Utilizando una red IP/MPLS con infraestructura de Capa 2 Gigabit Ethernet o 10 Gigabit Ethernet se reducen significativamente los costos comparados con las tecnologías antiguas como ATM o FR. Flexibilidad – Todos los servicios VPN basados en pseudowire MPLS utilizan una arquitectura común de servicios, diferenciándose solo en el circuito de conexión de cara al cliente. Cuando se implementa un nuevo tipo de servicio, este puede ser fácilmente desplegado en la red troncal IP/MPLS existente simplemente añadiendo el nuevo tipo de interfaz de acceso en el router PE (provider‐edge). La capacidad de implementación de TE entregada por IGP‐TE y CSPF permite a los operadores controlar fácilmente los caminos de re‐envío de tráfico de servicios en la red core. Confiabilidad – Los pseudowires utilizados por los router VPN PE y el túnel de transporte LSP MPLS soportan redundancia y rápida recuperación ante una falla. La arquitectura de servicios permite al operador redistribuir los servicios a más de un router PE para alcanzar la redundancia de pares para un servicio. Con la suma de características de resiliencia MPLS que poseen rápida recuperación frente a fallas, la red de servicios puede ser construida con alta disponibilidad. Escalabilidad – Los servicios VPN IP/MPLS son altamente escalables. La arquitectura de servicios VPN IP/MPLS permite a los routers de core (P routers) realizar la conmutación del tráfico de servicios sin saber qué instancias de servicios existen. Solo los router PE en 23 el borde de la red troncal conocen cada instancia de servicio. Solo los routers PE con circuitos de conexión de cara al cliente están involucrados en el aprovisionamiento de servicios. Todas las instancias de servicios compartiendo el mismo router PE están aisladas por la encapsulación VPN. LDP es uno de los protocolos MPLS utilizados para realizar la señalización. Con LDP, los router MPLS distribuyen las etiquetas y establecen automáticamente los LSPs. LDP distribuye etiquetas mapeadas con prefijos IP. Por lo tanto, el rendimiento en la convergencia es dependiente de los protocolos de enrutamiento subyacentes. La introducción de RSVP‐TE en la señalización LSP MPLS brinda mejoras significativas a la flexibilidad, confiabilidad y rendimiento del mecanismo de transporte de servicios en la red IP/MPLS. Con un túnel de transporte LSP con señalización RSVP‐TE, una red IP puede ahora entregar rendimiento en la convergencia a nivel de carrier utilizando las características de resiliencia como FRR y el LSP secundario. La nueva y mejorada tecnología MPLS permite a los operadores entregar flujos de tráfico para muchos clientes utilizando diferentes tipos de servicios en una sola red convergente. Es hoy en día la nueva tecnología de redes troncales WAN. 1.4 MPLS y las redes Convergentes Multi‐Servicios Por muchas décadas las redes de computadores han sido generalmente categorizadas como LAN, MAN y WAN. Cada tipo de red tiene su propia arquitectura y mecanismos de entrega de tráfico. Sus velocidades, costos y confiabilidad difieren también. Diferentes tipos de proveedores de servicios utilizan diferentes tipos de redes para entregar los servicios para estas redes. Con la innovación tecnológica y el incremento en las demandas de los consumidores, los requerimientos para la creación de redes están cambiando constantemente: El amplio despliegue de conmutadores Ethernet y pequeños routers IP de alto rendimiento y relativamente baratos trajeron la primera oleada en la evolución de las redes. Muchos computadores pueden ser conectados por estos dispositivos de trabajo 24 en red orientados a LAN y ganan gran velocidad en aplicaciones sensibles al tiempo o aplicaciones de tráfico intenso. La invención de Internet trajo la segunda ola en la evolución. Las redes de computadores alrededor del mundo pueden ser conectadas por la red troncal compartida de Internet. Esta ola trajo consigo la demanda de routers de red troncal de alto rendimiento y alta disponibilidad. Hoy en día, la tercera ola de la evolución ha llegado. Con la invención de la VoIP, IPTV y otras aplicaciones multimedia basadas en IP, los ISPs no solo entregan el acceso a Internet, sino también necesitan entregar estos servicios con beneficios adicionales sobre su infraestructura de red troncal. Estos servicios requieren ancho de banda y accesibilidad global, como también la garantizada QoS de extremo a extremo. Para alcanzar estas metas se utiliza el concepto de router de servicios. Los router de servicios localizan sus recursos de acuerdo a los requerimientos de diferentes servicios y entregan los servicios con la calidad deseada. Por lo tanto se desean las redes convergentes multi‐ servicio por los proveedores de servicios para cumplir con los nuevos requerimientos. La Figura 1.2 muestra una red convergente con múltiples servicios. En la Figura 1.2, la red de entrega de servicios, brinda múltiples servicios en una simple red troncal que contiene a los router de servicios. La red de entrega de servicios proporciona varios servicios a muchas empresas y clientes residenciales. Esta red se basa en la nueva y evolucionada tecnología de servicios VPN IP/MPLS. 25 Figura 1.2 – Red Convergente Multi‐Servicios 1.5 Servicios de Negocios con MPLS Hoy en día, muchas nuevas aplicaciones ejecutándose en redes residenciales y empresariales generan nuevas demandas para las redes troncales de telecomunicaciones: VPN compleja en Capa 3 – Muchos clientes empresariales requieren servicios VPN de conectividad compleja. Conectar simplemente todos los routers no es adecuado. Una VPN en Capa 3 es usualmente denominada como una Red Privada Virtual Ruteada (VPRN). Los clientes necesitan diferentes topologías de VPN como: 26 o Extranet – Algunas empresas necesitan compartir parte de sus redes con sus partners para mejorar la productividad mientras se aíslan las otras partes de sus redes. o VPN Hub‐Spoke – Algunos clientes requieren que sus sucursales sean conectadas con sus sedes y necesitan que el tráfico pase forzadamente a través del firewall de la sede central. o VPN de Superposición – Clientes que necesiten acceso a Internet a través de alguno de sus sitios mientras se aísla el resto de su red de Internet. VPN Capa 2: Servicio de Lan Privada Virtual (VPLS) y Línea Arrendada Virtual (VLL) – Muchos clientes necesitan tomar ventaja de la simplicidad de la Capa 2 junto al proveedor de servicios. Ellos necesitan comprar los servicios de conectividad en Capa 2 (punto a punto o punto a multipunto) desde el proveedor de servicios mientras manejan su propio enrutamiento en Capa 3. A los proveedores de servicios también les gusta el hecho de que no necesitan lidiar con el enrutamiento en Capa 3 con sus pares y la aislación de diferentes clientes y solo se enfocan en tener accesibilidad en Capa 2. Con la introducción de Gigabit Ethernet y Ethernet 10G en las redes de clientes y redes troncales, las VPLS y los servicios Ethernet VLL se han hecho muy populares. La VLL también se conoce como VPWS o Servicio de Cable Privado Virtual (Virtual Private Wire Service). Infraestructura de IPTV MPLS – con la nueva generación de soluciones de IPTV, la entrega de contenidos de televisión (de definición normal y alta definición (HD)) sobre redes IP se han hecho posibles y muy rentables. Muchos proveedores de servicios quieren usar su red troncal IP para entregar contenidos de TV y competir con los proveedores tradicionales de televisión por cable. La entrega de contenidos por IPTV necesita que la red troncal tenga un gran ancho de banda y alta calidad de servicio. Infraestructura de Servicios Móviles MPLS y Red de Retorno Móvil (Mobile Backhaul) – La nueva generación de redes móviles entregan voz servicios de datos de alto ancho de banda a través de servicios celulares. Los proveedores de servicios móviles buscan una 27 solución eficiente en el costo y óptima de uso de la red convergente para entregar voz y servicios de datos en la red troncal. Tecnologías de Acceso Mejoradas – El crecimiento significativo de tecnologías de acceso entrega más ancho de banda hacia los suscriptores finales. Las tecnologías DSL (Digital Subscriber Line) y PON (Red Óptica Pasiva) pueden entregar al usuario final 10‐Mbps, 100‐Mbps o incluso mayor rendimiento. Las aplicaciones de uso intensivo de ancho de banda como IPTV, TV Personal, descargas rápidas y juegos en línea pueden ser desplegados de extremo a extremo a través de la red troncal. Todos los cambios anteriores y las nuevas demandas desafían a los proveedores de servicios a construir una red troncal convergente de alto rendimiento, alta confiabilidad y eficiente en el costo para cumplir con los requerimientos de diferentes clientes. También, los proveedores de servicios están buscando más servicios de generación de ingresos para vender a los consumidores. La frontera entre los carriers y los proveedores de contenidos se ha vuelto ambigua. Los proveedores de TV Cable ahora están entregando acceso a Internet y servicios de telefonía VoIP. Los ISPs están entregando contenidos de TV hacia sus clientes a través de IPTV y utilizan las tecnologías DSL y PON para proveer de servicios de Internet y voz. Los proveedores de celulares están entregando también servicios de datos móviles y la entrega de contenidos de TV a teléfonos celulares a través de tecnologías 2G o 3G junto con los servicios de voz móviles. La evolución de la tecnología de VPNs IP/MPLS proporciona una solución para todos estos tipos de proveedores de servicios. Con la tecnología de VPNs IP/MPLS, todos los tipos de servicios pueden ser entregados en una simple red troncal convergente de servicios MPLS, como sigue: La red troncal de alto rendimiento (usualmente conectada a Gigabit Ethernet o 10 Gigabit Ethernet) proporciona el ancho de banda suficiente para entregar aplicaciones de alta demanda de ancho de banda como IPTV. 28 La tecnología de VPNs IP/MPLS flexibles permite múltiples servicios como voz, datos, transmisión de TV, red de retorno móvil y circuitos ATM/FR sean aprovisionados en la misma red. Las funciones avanzadas de QoS permiten la diferenciación entre diferentes tipos de servicios y clientes y tratan los diferentes tipos de flujos de tráficos basados en sus características únicas. La entrega garantizada de calidad de servicio para cumplir con los SLAs mientras se utilizan los recursos disponibles en la red para servir a subscriptores estáticamente multiplexados puede ser alcanzada de manera simultánea. El altamente seguro motor de enrutamiento de servicios proporciona redundancia en caliente en el plano de control. La resiliencia MPLS entrega rendimiento en la convergencia a nivel de carrier para proteger los servicios de fallas en la red. Los cortes de servicio pueden ser minimizados. La Figura 1.2 muestra una red de servicios VPN IP/MPLS. La invención e implementación de solución VPN IP/MPLS basadas en pseudowire les entrega a los proveedores de servicios una propuesta segura y escalable para entregar servicios a múltiples clientes utilizando la misma red troncal mientras se aísla eficientemente el tráfico de los clientes. Las VPN basadas en pseudowire desacoplan el rol de los routers de borde que están frente al cliente (PE) y el rol de los routers de la red troncal (P). Los pseudowires MPLS conectan los routers PE a las instancias de servicio de cara al cliente. La red troncal MPLS solo hace transitar el tráfico encapsulado de las VPN de extremo a extremo escondiendo los detalles de la topología de red de core del servicio en sí mismo. Por lo tanto los router PE de servicios pueden estar enfocados solo en proveer acceso a los dispositivos del cliente, multiplexando y demultiplexando el tráfico desde múltiples servicios y tomando decisiones de re‐envío de VPN. Los routers P se encargan de entregar alta disponibilidad y alto rendimiento “re‐enviando tubos” con QoS garantizada. El modelos de VPNs IP/MPLS basadas en pseudowires entrega diferentes tipos de servicios utilizando la misma red troncal IP/MPLS. Dentro de estos servicios se incluyen: 29 Figura 1.3 – VPN Punto a Punto Capa 2, Línea arrendada virtual o VLL – Servicio de entubamiento punto a punto altamente escalable que acarrea el tráfico del cliente entre dos sitios de clientes. Los servicios VLL soportan muchas tecnologías antiguas como ATM, FR Ethernet y CES (Servicio de Emulación de Circuitos) 30 o VPLS – Servicio Ethernet de puenteo punto a multipunto que puentea al tráfico Ethernet del cliente entre ubicaciones geográficamente separadas o VPRN – Servicio de ruteo IP punto a multipunto que encamina el tráfico IP entre diferentes sitios e intercambia las rutas del cliente entre estos sitios. Los servicios VPRN pueden entregar varias topologías de servicios como Intranet, Extranet, VPN de superposición (Overlay VPN) o una VPN Hub‐Spoke. El modelo de VPN basadas en pseudowire unifica el despliegue de la arquitectura de servicios en la red. Diferentes tipos de servicios VPN utilizan la misma infraestructura de VPN: Las instancias de servicios en cada router PE de cara al cliente, están conectadas por los pseudowires de extremo a extremo, y los routers PE están conectados hacia los demás por las Rutas de Distribución de Servicios (SDPs) utilizando encapsulación GRE o tunelización MPLS. Los diferentes tipos de servicios comparten la misma red troncal MPLS con una configuración similar de cara al core o núcleo de la red. Los servicios solo se diferencian en la configuración de los SAP (Puntos de Acceso al Servicio) en las instancias de servicios de los routers PE locales. Esta visión modular unificada de despliegue de servicios hace que la red troncal o backbone sea más fácil de mantener y expandir. Los servicios VPN IP/MPLS basados en pseudowire están estandarizados y soportados por múltiples proveedores (Cisco, Alcatel‐Lucent, etc) y por lo tanto se puede alcanzar la interoperabilidad multi‐proveedor. 1.6 Utilización de la Arquitectura VPN IP/MPLS para cumplir con los requerimientos de una Red de Servicios Para la entrega de servicios VPN mencionados anteriormente (VLL, VPLS, VPRN, etc.) el proveedor de servicios debe construir una red troncal capaz de entregar esos servicios. 31 Una red de VPNs IP/MPLS es una red VPN de ruteo por IP, orientada a los servicios y de conmutación. La evolución de la tecnología MPLS es la base de una re VPN IP/MPLS. El equipamiento para construir una red de este tipo debe: Dar soporte a protocolos de enrutamiento IP¨, incluyendo IGP (Protocolo de Pasarela Interior) y BGP. EL equipamiento debe soportar también Ingeniería de Tráfico y resiliencia avanzada MPLS. Ser capaz de realizar la conmutación MPLS en el plano de datos y la señalización de etiquetas MPLS en el plano de control. Para tomar ventaja de la resiliencia avanzada MPLS el equipo debe soportar RSVP‐TE con protocolo de distribución de etiquetas. Para implementar los servicios VLL y VPLS, debe soportar Target‐LDP (T‐LDP) para señalizar los pseudowires utilizados por estos servicios. Soportar el despliegue de QoS basada en servicios, accounting y políticas de seguridad. La implementación de calidad de servicio, QoS, debe ser orientada al servicio. Para servicios compartiendo el mismo equipamiento físico, la QoS debe entregar granularidad para la administración por servicio. Ser diseñada para entregar alta disponibilidad. Se requiere el diseño redundante del plano de control y del plano de datos para alcanzar el rendimiento y confiabilidad a nivel de carrier (carrier‐class). Dar soporte a características avanzadas de resiliencia MPLS y VPN para alcanzar la escalabilidad, resiliencia y estabilidad deseadas. Soportar una solución de administración de red para que los proveedores de servicios puedan desplegar, modificar y monitorear todos los servicios en tiempo real. La solución de administración de red debe ser también inteligente por lo cual las interferencias manuales deben ser reducidas al mínimo. Una red de VPNS IP/MPLS es una red IP ruteada. Para que MPLS trabaje apropiadamente, todos los dispositivos de red deben ser capaces de dar soporte a protocolos de enrutamiento escalables. OSPF o IS‐IS deben ser usados como IGP en la red backbone debido a este tipo de necesidades (escalabilidad y confiabilidad). En la red troncal o backbone el IGP realiza la 32 comunicación de la topología de red y la ubicación de todos los routers PE y P hacia los elementos de red. También para dar soporte a la conmutación y enrutamiento avanzado IP/MPLS, se necesitan las extensiones de ingeniería de tráfico (TE) del IGP. Estas extensiones de TE de los protocolos de enrutamiento llevan la información relacionada a TE en las actualizaciones de ruteo para permitir a cada router en la red construir una Base de Datos de Ingeniería de Tráfico (TED). La utilización de TE y CSPF permiten al sistema tomar más factores (recursos reservados por el sistema y políticas administrativas) en cuenta cuando se realiza el enrutamiento del tráfico. Con la ayuda de TE, los operadores pueden realizar el enrutamiento del tráfico a través de un camino que no sea la mejor ruta por IGP. Además, con la ayuda de TE y CSPF, RSVP‐TE entrega características de resiliencia como Fast‐Reroute y LSP Secundario en los LSPs MPLS. Esto hace que los túneles de transporte de servicios sean más seguros y se mejore significativamente el rendimiento en la convergencia del backbone IP/MPLS. 33 La Figura 1.4 muestra la arquitectura global de una red multi‐servicios IP/MPLS Figura 1.4 – Visión General de la Arquitectura de Red de Servicios VPN IP/MPLS En la Figura 1.4, hay dos routers de servicios conectados al backbone IP/MPLS y tienen definidas instancias de servicios VPN. Las instancias de servicios que pertenecen al mismo servicio VPN están conectadas por pseudowires. Cada instancia de servicio contiene Puntos de Acceso a Servicio (SAPs) para entregar acceso al cliente. Las instancias de servicios son entidades de software virtuales que residen dentro del mismo router. Para redes que comparten múltiples servicios, se deben desplegar políticas relacionadas a los servicios con granularidad por‐servicio. En una red troncal compartida, los proveedores de servicios necesitan desplegar políticas de calidad de servicio para diferentes flujos de tráfico en el mismo servicio, y para diferentes flujos de tráfico que pertenecen a diferentes servicios. Estas políticas de QoS aseguran que los diferentes tipos de servicios que están siendo comprados por diferentes tipos de clientes están siendo entregados como lo comprometió el SLA. Las políticas de contabilización entregan estadísticas relacionadas a los servicios y las políticas de seguridad deben entregar la protección requerida por los clientes. Para cumplir estos requerimientos, el despliegue de políticas en una red de VPNs IP/MPLS debe ser orientada al servicio. Las políticas deben ser capaces de ser aplicadas a cada entidad lógica individual de servicios, pero no al 34 hardware (por ejemplo a los puertos). Este es un diferenciador clave entre una red orientada a los servicios y una red orientada al hardware. La figura 1.5 muestra las diferencias entre una red orientada a los servicios y una red orientada al hardware. Figura 1.5 – Redes orientadas a los Servicios versus Redes orientadas al Hardware En el despliegue de políticas orientadas al hardware de la Figura 1.5, las políticas (QoS, seguridad y contabilización) son desplegadas en una base por‐puerto. Las conexiones que pertenecen a diferentes servicios y que comparten el mismo puerto deben compartir las mismas políticas. El router no tiene visión de los servicios; solo sabe que algunas conexiones están asociadas con otras. El proveedor de servicios no puede especificar una política para un SAP individual o servicio. En el despliegue de políticas orientadas al servicio, cada servicio es la entidad actual de software en el router de servicios. Cada servicio utiliza un SAP para conectarse al cliente y cada SAP posee sus propias políticas de QoS, seguridad y contabilización. Los switches y routers MPLS deben soportar también características de alta disponibilidad (HA ‐ High Availability). La HA necesita de un enfoque holístico y no puede ser una idea tardía. Los atributos de alta disponibilidad deben incluir planos de renvío distribuidos, 35 equipamiento redundante para el control, diseños de tarjetas de línea modulares, redundancia de protocolos en Capa 2 y Capa 3 y protección de conmutación por error de tarjetas de línea y puertos del equipo. Desde el punto de vista de servicios MPLS, la capacidad de Non‐Stop Routing (NSR – Enrutamiento sin detención) es un pre‐requisito clave debido a que una de las primeras metas de un proveedor de servicios es tener la mínima interrupción de sus servicios, especialmente durante actualizaciones de software. NSR proporciona a los sistemas la habilidad de soportar Non‐Stop‐Service (NSS). Una red de VPNs IP/MPLS es orientada a los servicios. Cuando los protocolos de enrutamiento de capas inferiores y los túneles de re‐envío de tráfico son robustos, los servicios utilizando la infraestructura son también robustos. La redundancia en el diseño del plano de control y del plano de datos garantiza la máxima disponibilidad de servicios para alcanzar el más alto nivel de SLAs. Con NSS, cada componente perteneciente a una instancia de servicio mantiene su estado en el evento de una falla. En muchas condiciones, en una actualización de sistemas en servicio (ISSU) se puede realizar para eliminar un corte de servicio durante la actualización de un router. Las redes de proveedores de servicios necesitan soportar cientos de VPNs de clientes concurrentemente. Por lo tanto, es importante que el equipamiento MPLS desplegado deba soportar simultáneamente miles de instancias de servicios para una VPN IP/MPLS como lo son los servicios Triple Play servicios de red de retorno móvil (Mobile Backhaul) de manera de cumplir con los criterios de rendimiento establecidos. 1.7 Aplicaciones VPN IP/MPLS Las redes VPN basadas en IP/MPLS ayudan a habilitar una gran variedad de aplicaciones y servicios. Servicios VPN Empresariales – Se pueden incluir servicios VPN Capa 2 y Capa 3 Servicios de Internet mejorados (IES) con mecanismos de clasificación de QoS avanzados, Contabilización y Políticas de seguridad – El servicio IES es un servicio IP 36 enrutado y se puede utilizar una VPN Capa 2 como mecanismo para retornar el tráfico de un circuito de acceso Ethernet, FR o ATM. Servicios Triple‐Play – BTV, VoD, VoIP y acceso a Internet. Todos los servicios están diferenciados por una política de QoS avanzada para asegurar la entrega de calidad de servicio y el uso efectivo del ancho de banda disponible. Servicios de Red de Retorno Móvil – Se puede utilizar una VPLS o una VLL para habilitar la conectividad entre las estaciones base y el core móvil. Para comprender de mejor manera la interconexión que se realiza entre las distintas topologías de redes de acceso se analizarán de manera general distintos tipos de redes y su interconexión con la red de conmutación; comenzaremos analizando en detalle desde el equipo del usuario final o cliente final (en una red empresarial) quien es el que paga una cuenta telefónica de red celular o su servicio triple‐play residencial con el cual posee TV digital, canales HD, VoIP etc, hasta donde necesitemos avanzar y entregar la petición de información que realizan los dispositivos del usuario final. Si bien es cierto las topologías de acceso son muy similares, el manejo de la información debe ser diferente en cada uno de los escenarios; comenzaremos analizando el caso de telefonía móvil en una red 2G: 1.7.1 Red 2G: 2G es la abreviación para la segunda generación de tecnología de telefonía inalámbrica. La tecnología digital 2G reemplaza a la tecnología analógica 1G. Existen varios sistemas 2G entre los cuales IS‐95 CDMA (cdmaOne) y GSM son los más populares. CDMA (Acceso Múltiple por división de código) es una tecnología norteamericana en la cual todos los usuarios comparten la misma banda de frecuencia. El estándar del Sistema Global para comunicaciones Móviles (GSM) es el estándar más popular para los sistemas de telefonía móvil. GSM fue desarrollado originalmente dentro del 37 Instituto Europeo de Estándares de Telecomunicaciones. Soporta Acceso Múltiple por división de tiempo con 8 usuarios cada 200KHz. La red GSM es una red de conmutación de circuitos, ideal para la entrega de servicios de voz pero con limitaciones para el envío de datos. La primera llamada sobre una red GSM fue hecha en 1991 por Radiolinja en Finlandia. Con el paso del tiempo GSM y el sistema móvil 2G se han convertido en sinónimos. 1.7.2 Core Móvil para 2G: La red 2G está constituida de los siguientes elementos (siguiente figura): Figura 1.6 – Arquitectura de Red 2G Donde cada uno de los elementos corresponden a: ‐ UE: (User Equipment) Equipamiento del Usuario (en este caso un teléfono móvil 2G) ‐ BTS: (Base Transceiver Station) Estación Base Transceptora. Un sitio donde existe una celda utilizada para facilitar la comunicación inalámbrica entre el UE y la red. ‐ BSC: (Base Station Controller) Controlador de Estaciones Base. La BSC proporciona el control de muchas BTS’s y actúa como un concentrador hacia el (MSC – Mobile Switching Center) Centro de Conmutación Móvil. La BSC maneja la distribución de canales de radio y controla los handover entre BTS y BTS 38 ‐ MSC: (Mobile Switching Center) Centro de Conmutación Móvil. El MSC maneja la administración de movilidad de llamadas de voz y el Servicio de Mensajes Cortos (SMS) ‐ HLR: (Home Location Register) Registro de Localización. El HLR es la Base de Datos central que contiene los detalles de cada subscriptor de telefonía móvil. ‐ PSTN: (Public Switched Telephone Network). Red Conmutada de Telefonía Pública. Es un sistema de comunicación público que entrega servicios de telefonía En este escenario se puede observar que la red conmutada en aquel entonces correspondía a un backbone sólo TDM; este backbone respondía a los requerimientos de ancho de banda para las redes de aquél entonces. 1.7.3 Core Móvil para Redes de Datos (2,5G y 3G) Con el tiempo, se identificó la necesidad de entregar tráfico IP. En el año 2000, el Servicio General de Paquetes vía Radio (GPRS) fue añadido al existente sistema GSM para ofrecer la entrega de servicios de datos sobre una red de paquetes conmutados. No hubo cambios sobre la red de voz. Los sistemas 2G fueron extendidos a 2.5G. Con el GPRS, los usuarios finales podían tener acceso al servicio de Internet y MMS sobre sus teléfonos móviles. La arquitectura del packet‐core fue diseñada sobre un protocolo de tunelización denominado GTP (Protocolo de Tunelización GPRS). GTP corría sobre IP entre la SGSN y la GGSN. Los sistemas 2.5G se mejoraron aún más hacia sistemas 3G y 3.5G ofreciendo altas tasas de transmisión para soportar características adicionales en los teléfonos móviles. La red GPRS está constituida por los siguientes elementos (siguiente figura): 2. UE: Equipamiento del usuario. 3. NodeB: (Nodo B). Término utilizado para denominar a un sitio celular 3G. Es equivalente al término BTS utilizado en GSM. 39 4. RNC: (Radio Network Controller) Controlador de la Red Radio. La RNC es la responsable de controlar los Nodos B que están conectados a ella 5. SGSN: (Serving GPRS Support Node) Nodo de Soporte a los Servicios GPRS. El SGSN maneja la administración de movilidad del 3G y es el responsable de entregar paquetes de datos desde y hacia la estación móvil. 6. GGSN: (Gateway GPRS Support Node) Nodo de soporte a la puerta de enlace GPRS. El GGSN entrega conectividad hacia las redes de paquetes conmutados externas como Internet. Este convierte los paquetes GPRS que vienen de la SGSN a paquetes IP y los envía hacia la red de paquetes de datos correspondiente. El GGSN también mantiene el enrutamiento necesario para tunelizar los paquetes IP hacia la SGSN que está sirviendo a una estación móvil en particular. 7. HLR: Registro de Localización. 8. PDN: (Packet Data Network). Red de paquetes de Datos. Figura 1.7 ‐ Red Core Móvil para Datos (2,5G, 3G) En la figura anterior ya se muestra un backbone más complejo que maneja a la red 2G y 3G. En este punto y como se menciona anteriormente, se hace visible la necesidad de tener un centro de conmutación IP que maneje a gran velocidad los paquetes provenientes de la red 3G y la voz de 2G (GPRS Backbone). 1.7.4 El Transporte “Mobile Backhaul” 40 De acuerdo a lo definido por la NGNM (Next Generation Mobile Networks Alliance) “Una red backhaul sirve de medio de transporte para una Red de Acceso por Radio (RAN) y conecta las estaciones base a sus controladores pertinentes.” Dicho de otra manera, el transporte Mobile Backhaul une las estaciones Base de sitios celulares 2, 3 y 4G/LTE y la Oficina de Conmutación de Telefonía Móvil (MTSO), controladores de Red (NC) y los demás elementos relacionados utilizando soluciones de transporte como la mostrada en este trabajo de titulación (entre otras). La única vía hacia LTE es una red de paquetes. Como las redes inalámbricas fueron construidas para servicios de voz antiguos y SMS, rápidamente fueron saturadas con la web, el video, la mensajería multimedia, P2P de música y video y la explosión de datos continuó sin detenerse, por lo tanto estas redes necesitaron evolucionar y cambiar. Este cambio está ocurriendo hacia redes inalámbricas bajo un paradigma de transporte hacia IP. Con el transporte Mobile Backhaul IP/MPLS, los proveedores de servicios inalámbricos móviles pueden actualizar eficiente y económicamente sus RAN y sus redes inalámbricas de paquetes de core (Núcleo de la Red) hacia una red IP/Ethernet más plana mientras se incrementa su ancho de banda para dar soporte a los emergentes nuevos servicios de banda ancha inalámbrica. Con el transporte Mobile Backhaul IP/MPLS, los proveedores de servicios adquieren la capacidad de entregar nuevos servicios inalámbricos de venta al por mayor y ampliar sus oportunidades de venta en el mercado. 1.7.5 Componentes de una Red Mobile Backhaul La imagen siguiente muestra a grandes rasgos tres áreas funcionales de una red de transporte backhaul. Estas son: 41 Figura 1.8 – Red Mobile Backhaul El sitio celular – Donde las estaciones base móviles (BS) y el router Agregador de Sitios Celulares (CSA) se encuentran 2 Las Estaciones Base (BS) (hacia donde se conectan los teléfonos celulares): Las estaciones Base son las BTS 2G (GSM), Nodos B 3G (UMTS o CDMA) y los e‐Nodos B 4G/LTE 3 El agregador de sitios Celulares (CSA – o CSR en este trabajo de titulación): El CSA es el primer dispositivo de demarcación en donde el tráfico del usuario entra y sale a través de la red de transporte. También es denominado Cell Site Gateway (CSG – Puerta de Enlace del sitio celular). El CSA suma el tráfico de los potenciales cientos de usuarios (UE), y da soporte a estaciones base TDM, ATM y Ethernet. El Transporte Backhaul – En el transporte físico de la red backhaul pueden estar incluidas las DS1/E1 o las DS3/E3, SONET/SDH, Ethernet sobre SONET (EoS), o sólo Ethernet, o una combinación de algunas de éstas. La alimentación de estos circuitos pueden ser estaciones base Ethernet, ATM o TDM y redes de acceso inalámbricas por microondas, DSL o Ethernet. La red de transporte acepta tráfico de control, voz y datos y entrega este tráfico bidireccionalmente desde 42 y hacia las estaciones base y la MTSO. En una red 4G/LTE el transporte físico es todo mediante Ethernet, lo cual habilita la comunicación directa entre estaciones base (BS – BS). 4 La Interfaz de Red de Usuario (EoS UNI) – Esta sirve como puerta de enlace del CSA hacia la red de transporte Metro Ethernet, SONET/SDH, TDM o ATM. En el ejemplo anterior, la EoS UNI acepta el tráfico Ethernet desde el CSA y transporta estas tramas y su carga útil sobre el anillo de la red Metro ETHERNET SONET/SDH 5 La Red Metro Ethernet (MEN) – entrega el transporte óptico resiliente del tráfico de servicios backhaul IP/MPLS 6 La Plataforma de Aprovisionamiento Multiservicio (MSPP) – Entrega el tráfico hacia los routers puerta de enlace MTSO sobre enlaces redundantes Ethernet o SONET/SDH Como se mostraba en la Figura 1.8, la red de transporte ofrece QoS orientada al servicio, y servicios de transporte punto a punto y multipunto físicos y virtuales, los cuales mueven portadoras y señalizan el tráfico a través de la EoS MEN. Los router CSA y los servicios Capa 2 reenvían el tráfico de los sitios celulares en la red de transporte, y los routers Gateway de agregación MSP entregan este tráfico hacia los controladores de red (NC). Las BS, CSA, MTSO y la red de transporte podrían pertenecer al Proveedor de Servicios Móvil, o de otra forma el MSP podría solicitar acceso al MEN desde un proveedor de Transporte Backhaul. Los componentes de la red de transporte aseguran la sincronización precisa de las BS, circuitos TDM y elementos de red y la diferenciación del tráfico por servicio. Como se puede observar, la conexión a la red de conmutación de paquetes se hace solo mediante un teléfono móvil que de acuerdo a los avances de la tecnología utiliza las bandas de frecuencia asignadas para 2G, 3G o 4G según sea el caso. De manera similar existe la solución Triple‐Play en la cual se unifican los servicios de voz (VoIP) datos (FTTH) y TV (TVIP) sobre una infraestructura de red de paquetes conmutados. En el siguiente apartado se detallará Una red Hogareña y la Red de Acceso; lo correspondiente al Core se detalla en el punto 1.7.1 43 1.7.6 Arquitectura General de Acceso en una red Triple Play ‐ ADSL La red Triple‐Play en sus dos primeras etapas está conformada por una pequeña Red Hogareña que se encuentra en las dependencias de los clientes y una red de Acceso que al igual que en las redes Mobile Backhaul, debe soportar las diferentes tecnologías de acceso que vienen desde las Redes Hogareñas. Como ejemplo tomaremos en primer lugar la Red‐Hogar. 1.7.6.1 Red‐Hogar: Figura 1.9 – Esquema general de una Red‐Hogar La función primaria es la de interconectar a los dispositivos de los usuarios residenciales a la red del proveedor de servicios a través de un Gateway Residencial (RG); esta red contiene varios tipos de dispositivos que requieren voz, video y servicios de datos (Notebooks, Estaciones de Trabajo (PC), Teléfonos Celulares vía Wi‐Fi, Teléfonos IP, etc). El RG entrega el direccionamiento IP y sirve de Gateway (o pasarela) para la información hacia la red de Acceso del proveedor de servicios. Como se mencionó anteriormente, todos estos dispositivos (incluido el RG) se encuentran en las dependencias del usuario final (hogar del usuario); son los típicos router ADSL de tecnologías actualmente en uso o las ONT (Terminación 44 Óptica de la Red) nuevas que manejan fibra y altos anchos de banda hacia el hogar en una arquitectura GPON. 1.7.6.2 Red de Acceso: Figura 1.10 – Esquema General de una Red de Acceso La función primaria de una red de Acceso (ejemplo en la Figura 1.10) es dar soporte a diferentes tecnologías físicas de acceso hacia la red Hogar. La red de Acceso está constituida de los dispositivos (BSAN – Nodo de Acceso a Servicios de Banda Ancha). Los dispositivos BSAN están constituidos por tarjetas de Terminación de Líneas (LT) y tarjetas de terminación de Red (NT). Las tarjetas de terminación de línea van de frente a los usuarios finales mientras que las tarjetas NT van de cara hacia el flujo de datos de la red de Agregación en el Core (hacia arriba o aguas arriba). Cada puerto de acceso en una tarjeta BSAN LT se puede conectar a un RG en la Red‐Hogar. Por lo tanto una LT de 48 puertos puede conectar hasta 48 Gateways Residenciales; las configuraciones típicas en los equipos DSLAM actuales son tarjetas ADSL 2+ de 48 puertos y ONT para la arquitectura GPON. Con la introducción de la solución de VPN Capa 2 IP/MPLS se han agregado muchas nuevas aplicaciones y estas se han hecho disponibles a los proveedores de servicios. Los proveedores de servicios pueden construir una red convergente sirviendo a una gran cantidad de clientes con 45 diferentes requerimientos de servicios. Las dos nuevas y últimas soluciones son la solución Triple Play y la solución de Red de Retorno Móvil (tema de este trabajo de titulación) que se detallan a continuación. 1.7.7 La Solución Triple Play Con la entrega de muchos servicios disponibles y una fuerte implementación de mecanismos de QoS se muestra a continuación una visión general de la entrega de Servicios Triple‐Play (voz, datos y vídeo); una red Triple Play entrega IPTV, VoIP, acceso a Internet y otras aplicaciones basadas en IP para el público en general. La clasificación de QoS intensiva, contabilización y políticas de seguridad pueden ser desplegadas para cada suscriptor y asegurar la calidad de servicio y seguridad. La solución Triple‐Play es una nueva forma de entregar voz, datos y aplicaciones de vídeo a una gran cantidad de consumidores. La Figura 1.11 muestra una visión general de la solución Triple Play para proveedores de servicios. 46 Figura 1.11 – Visión General de la Solución Triple‐Play La arquitectura Triple‐Play está basada en dos grandes elementos de red, optimizados para sus respectivos roles – el agregador de servicios de banda ancha (BSA) y el router de servicios de banda ancha (BSR). Una característica importante de los BSAs y BSRs es que ellos conforman de forma efectiva un nodo virtual distribuido, con los BSAs realizando funciones específicas hacia los subscriptores en las cuales, varias funciones pueden ser escaladas, y los BSRs entregando la inteligencia de enrutamiento donde sea más conveniente. Los BSAs son dispositivos Capa 2 que re‐envían tráfico utilizando mecanismos Capa 2 pero tienen la inteligencia de filtrado y QoS para forzar a las políticas de capas superiores. Los 47 BSAs son el punto de terminación del tráfico en Capa 2 y encamina el tráfico sobre IP/MPLS, con soporte para un completo set de protocolos de enrutamiento IP y MPLS. El BSR soporta cientos de puertos de subida GE Y SONET (para despliegues a gran escala) y sofisticados mecanismos de QoS para la diferenciación de fuentes por‐contenido y por‐servicio. Para la conectividad entre BSAs y BSRs se debe construir un modelo de re‐envío en Capa 2 utilizando una infraestructura de VPLSs segura y resiliente. Las interconexiones BSA‐BSR forman una red Ethernet multipunto con extensiones de seguridad para prevenir la comunicación no autorizada, denegación de servicio y robo de servicio. Este enfoque soporta todos los modelos de operación, incluyendo múltiples modelos de home‐gateways, simple o múltiples bordes de red IP, y simples o múltiples circuitos en la última milla. Como fue descrito, MPLS habilita la entrega de servicios de negocios y residenciales y por lo tanto es una adecuada elección para el despliegue de infraestructuras de red multi‐ servicios. 1.7.8 La Solución de Red de Retorno Móvil Hoy en día, los clientes móviles necesitan más que transmisión de voz inalámbrica y servicios de mensajería de los proveedores de servicios móviles. La introducción del despliegue de redes de tercera generación (3G) y muchas aplicaciones móviles basadas en IP han incrementado significativamente la demanda de transporte de datos sobre redes móviles. Los proveedores de servicios móviles deben encontrar el balance entre la atracción y satisfacción de sus consumidores, y la rentabilidad de sus redes. Para reducir los costos de transporte, los proveedores de servicios móviles han empezado a desplegar una solución de red de retorno móvil basada en VPNs IP/MPLS construyendo un core multi‐servicio IP/MPLS. La solución de red de Retorno Móvil reduce los costos, integra las redes actuales GSM y UMTS e incluye las tecnologías HSPA y HSPA+, con un fuerte camino de inversión protegida hacia LTE (Long Term Evolution). Esto entrega a los proveedores de servicios la flexibilidad de 48 desplegar diferentes opciones de medios de retorno simultáneamente (incluyendo fibra, cobre y transporte inalámbrico), con la configuración más apropiada para abordar óptimamente los requisitos de la red. La Figura 1.12 muestra una visión general de una solución de Red de Retorno Móvil. Figura 1.12 – Ejemplo de la Solución de Mobile Backhaul La solución de red de retorno móvil entrega una flexible evolución de red de Retorno Móvil soportando todas las tecnologías de transporte – desde TDM, ATM, DSL y microondas a IP, MPLS y pseudowires. Con la entrega de garantizadas políticas de QoS para todos los servicios 49 móviles, la solución de red de Retorno Móvil asigna eficientemente los escasos recursos de la red Backhaul entregando los siguientes beneficios: Entrega una Red de Acceso de Radio (RAN) escalable y eficiente que es capaz de reducir el costo de transporte por Mbps (megabits por segundo). Permite aumentar los ingresos medios por usuario (ARPU – Average Revenue per User) dando soporte a voz, video, multimedia y nuevos servicios de banda ancha con QoS garantizada de extremo a extremo. Aprovecha la tecnología IP/MPLS y pseudowire para soportar la evolución de las interfaces RAN y los estándares 3GPP2 y 3GPP/LTE. 50 CAPÍTULO 2 ‐ Equipamiento y protocolos utilizados para el despliegue de la tecnología MPLS en una Red Corporativa Mobile Backhaul Antes de comenzar este capítulo se debe hacer hincapié en el porqué, cuándo y cómo se realiza un proceso de migración hacia la tecnología MPLS. En el proceso de cambio resulta imprescindible comenzar valorando cuidadosamente las necesidades de la red corporativa, solicitar y evaluar después las propuestas de diversos proveedores (Cisco, Alcatel‐Lucent, Juniper) y, sólo una vez completadas estas fases, proceder a la implementación de los servicios. Este es el camino que siguen los grandes proveedores de servicios a Nivel Nacional ya que ven en MPLS un nicho de negocios muy grande debido a su escalabilidad, flexibilidad y rentabilidad (pueden coexistir múltiples tecnologías sobre la misma infraestructura). Dentro del análisis de necesidades de la empresa, ésta debe preocuparse de los siguientes puntos: ‐ Ancho de Banda: como se hará la distribución de ancho de banda sobre la infraestructura existente o la nueva infraestructura (definición de clústers de red en este caso) ‐ Dispositivos a emplear: Los dispositivos que serán adquiridos por la empresa y los pro y los contra de su manejo (configuración, consumo eléctrico, etc.) ‐ Aplicaciones: para qué necesita la compañía de telecomunicaciones la adquisición de este equipamiento; se considera en este caso la implementación de una red Mobile Backhaul para servicios 2G, 3G y LTE (otra compañía podría haber utilizado la misma red para implementar TvIP u otros servicios) ‐ Características de la Aplicación: si la aplicación para la que se va a utilizar es sensible a la latencia, los retardos en la transmisión y el ancho de banda que consumen Una vez que se tienen estos lineamientos claros por parte de la Compañía de Telecomunicaciones, se procede a realizar la elección del proveedor idóneo para implementarla. 51 En este caso la compañía de telecomunicaciones sobre la cual se realiza el estudio realizó la elección del equipamiento de Alcatel‐Lucent de las líneas 7705 y 7750 para la implementación de la red de transporte de información. 2.1 Equipamiento El siguiente Capítulo describe las características y capacidades de los componentes utilizados para realizar la solución de transporte Mobile Backhaul sobre IP/MPLS. Se describirá la solución con la serie de routers de Alcatel‐Lucent 7705 SAR y 7750 SR disponibles en varias grandes redes corporativas a nivel nacional. La solución de transporte MPLS descrita en este trabajo de titulación está implementada a nivel Nacional en una de las empresas del rubro de las telecomunicaciones y es la base para el análisis de la solución. 2.2 Descripción del Equipamiento utilizado en la Red Mobile Backhaul Para el despliegue de la red IP‐RAN que será descrita en este trabajo de titulación se han utilizado distintos tipos de routers dependiendo de su ubicación en la topología lógica a la cual se verán enfrentados; se utilizan los equipos SARF SARM y SAR8 de la línea 7705 de Alcatel‐ Lucent para agregar servicios (Nodos B o Estaciones Base) sobre la red de Acceso. Se ha realizado la elección de estos equipos por parte de la empresa de telecomunicaciones debido a las consideraciones de ahorro de costos, su facilidad de despliegue, escalabilidad y flexibilidad que son inherentes a MPLS. Los routers de agregación de servicios (SAR ‐ Service Acces Routers) 7705 responden a los requerimientos de desempeño de las aplicaciones de agregación RAN (Radio Access Network) y de las soluciones basadas en IP de la nueva generación (4G). Se debe destacar que la implementación de esta nueva red, con este equipamiento responde a los requerimientos de ancho de banda para nodos B 3G y cubren las necesidades para la implementación de LTE en un 52 futuro cercano sobre esta misma arquitectura IP/MPLS. A continuación se muestra la vista frontal de los equipos utilizados: Figura 2.1 – SAR 8 Figura 2.2 – SAR F Figura 2.3 – SAR M Cada uno de estos equipos es utilizado en la red IP‐RAN para la conformación de anillos lógicos con la planta externa que permiten tener redundancia a nivel físico en sus extremos. 53 En la siguiente figura se muestra la instalación física de un SARM en la red analizada para lo cual se realizó la visita a sitio para corroborar su correcta instalación: Figura 2.4 – Instalación Física de SARM en sitio (sitio de acceso) Como se puede apreciar en la fotografía a la izquierda se encuentran los puertos 1/1/1 y 1/1/2 que son los que se conectan contra las interfaces de otros routers vecinos para conformar los anillos físicos; la idea de conformar anillos físicos en la red es que no se pierda conectividad contra los Nodos B en el caso de que un enlace de fibra por cualquier motivo (accidente o falla en la interfaz) falle. A la derecha los conectores de ‐48VDC que proveen la alimentación necesaria a las dos fuentes de energía redundantes para proveer alta disponibilidad en caso de alguna falla de energía. Se puede observar también que este equipo posee interfaces ATM para la conexión de Nodos que posean este tipo de interfaz física. 2.2.1 Características del 7705 SAR 54 El 7705 SAR está basado en el Sistema Operativo de Routers de Servicios (TiMOS) de Alcatel‐Lucent, puede funcionar de manera homogénea con la familia de Routers 7750‐SR desplegado en la red móvil Core (que se verá más adelante). Debido a las consideraciones dadas por la empresa de telecomunicaciones, se necesita redundancia y alta disponibilidad de sus servicios para lo cual cada uno de estos routers viene equipado con dos fuentes de alimentación y dos enlaces “uplink” hacia cada uno de los extremos del anillo; no es deseable que por cualquier tipo de falla en la red el router quede no gestionable o sin la capacidad de seguir entregando servicios. Este equipo soporta también múltiples opciones de sincronización que se adapta mejor a los requerimientos de los sitios celulares. El sistema ofrece un reloj Stratum 3, adaptivo y referencia de la línea de interfaces T1/E1/OC3 y STM1 y además soporta IEEE 1588 v2. Con el objeto de suministrar emulación de circuitos (trafico TDM) el sistema soporta capacidades de CESoPSN y SAToP así como buffers configurables para controlar retrasos (delay) y jitter. La sincronización de red y la fuerte emulación de circuitos permiten a los operadores aprovechar una red convergente para el tráfico Mobile Backhaul. El 7705 SAR participa en soluciones totalmente integradas para operadores móviles; es administrada por el 5620 SAM Gestor de Servicios Pro‐activo (Service Aware Manager en inglés) que permite una administración de extremo a extremo, desde el punto de acceso de primera milla hasta el Core IP Móvil. 2.2.2 Router de Servicios 7750 SR (Service Router) Para la implementación de la red de Core y agregación en la Red Mobile Backhaul se necesitan routers más potentes que permitan manejar gran cantidad de tráfico proveniente desde las estaciones bases hacia los RNC (Radio Network Controller). Es por esto que la compañía de telecomunicaciones escogió el router 7750‐SR7 debido a su alta capacidad de manejo de tráfico y flexibilidad en la implementación y manejo de servicios. Cabe destacar que 55 estos routers están presentes en las zonas medulares de la compañía de telecomunicaciones por lo tanto agregan gran cantidad de tráfico proveniente de los Nodos B y deben estar siempre disponibles y siempre encendidos. La necesidad de soluciones orientadas al servicio para redes convergentes está conduciendo la demanda de una nueva clase de router, el llamado Router de Servicios (SR). Un router de servicios es un router escalable para servicios de datos que ofrece servicios Internet tipo Best‐Effort (BE) y que permite la migración de los servicios tradicionales de voz y datos sobre una plataforma única. Sin embargo, este dispositivo debe soportar un extenso rango de servicios diferenciados de datos privados, voz y video, etc. sobre una infraestructura de red única y de bajo costo. Estos servicios, tales como las Líneas Virtuales Dedicadas Punto a Punto (VLLs), LAN privada Virtual Multipunto (Virtual Private LAN Services VPLS tipo multipunto) e IP‐ VPNs permiten al operador atraer y conservar una base de suscriptores mayor con un costo de red más bajo, al mismo tiempo que aumenta su oferta en flexibilidad y calidad para el usuario final. 2.2.2.1 Descripción General del Router 7750‐SR 7 El chasis 7750 SR‐7 es un sistema totalmente redundante que cuenta con un total de siete ranuras con acceso frontal. Dos ranuras de tarjetas están dedicadas a equipamiento común redundante, cada uno de los cuales alberga un Módulo Procesador Switch Fabric/Control (SF/CPM). Sólo se requiere de un SF/CPM para una operación a 200 Gbps sin bloqueo. El segundo SF/CPM proporciona redundancia completa de los procesadores de fabric y control. Cuando dos SF/CPMs SR7 están instalados el tráfico es compartido entre los switch fabric. El 7750 SR‐7 puede ser desplegado inicialmente con un módulo fabric de 200 Gbps el cual otorga una ruta de crecimiento hasta 200 Gbps en caso que las nuevas IOMs de 40 Gbps sean requeridas. Las restante cinco ranuras están reservadas para tarjetas Módulos de Entrada/Salida (Input / Output Module IOM). 56 El chasis SR‐7 soporta alimentación redundante y bandejas de ventiladores. La Figura 2.5 muestra al 7750‐SR7 Figura 2.5 – 7750 SR7 Las opciones de alimentación para el SR‐7 incluyen ‐48V DC o 120/240V AC, con soporte de redundancia 1+1. Todas las conexiones de energía están realizadas en la parte posterior a través de 2 Módulos de Entradas de Alimentación separadas (PEMs). Adicionalmente a las PEMs se deben instalar en el frente del chasis condiciones de línea DC o entradas de alimentación AC. El sistema de enfriamiento del SR‐7 utiliza flujo de aire desde la parte posterior. Dos (2) bandejas separadas de ventiladores entregan redundancia de enfriamiento 1+1. Ambas bandejas de ventiladores se encuentran insertadas en la parte trasera del chasis SR‐7. La dimensiones del SR‐7 son 14”H x 17.5”W x 23.5”D, es decir que cinco (5) SR‐7s entrarán en un Rack Telco de 7 pies, con un compartimiento para un panel de interruptores Breakers. La labor principal de este equipo es por una parte en la capa de agregación realizar la interconexión (agregación) de los distintos SARM, SARF y SAR8 conectados en los anillos a los clúster y la interconexión a nivel de acceso contra los RNC. Son los equipos más importantes dentro de los llamados clúster de la red de telecomunicaciones pues se encuentran distribuidos en pares (un par en la capa de Core y un par en la capa de Agregación); esto significa que si falla 57 un par de equipos 7750 ya sea en la capa de Agregación o en la capa de Core se pierde la gestión y el manejo de tráfico de una gran cantidad de estaciones base de la empresa en cuestión. En la siguiente fotografía se muestra la instalación física de un equipo MR en un sitio; se pueden apreciar las conexiones hacia los anillos y el frente de equipo característico que está compuesto por tres tarjetas MDA una para la agregación de anillos desde la planta externa (tarjeta de 10 puertos de 1Gbps; MDA 1/1; en este caso está agregando los anillos 1 y 3), otra tarjeta para la conexión redundante con su par (MDA 2/2; tarjeta de un puerto de 10Gbps) y otra tarjeta para la conexión contra el HR (tarjeta de un puerto de 10Gbps); la conexión hacia la fuentes de alimentación van en la parte posterior del chasis. Estos equipos van en pares y se encuentran instalados en el mismo sitio. Figura 2.6 – Instalación Física de un 7750 – SR7 Capa de Agregación o Mid‐RAN (MR) En la siguiente fotografía se muestra la instalación física de un equipo HR en el cual se pueden apreciar las conexiones hacia su par (el HR – B, desde la tarjeta MDA 2/2 a 10Gbps), 58 contra el MR de la Figura 2.6 desde el puerto 1/1/1 a 10Gbps y las interfaces contra el o los RNC disponibles en la sala (desde los puertos 1/1/3 en adelante en la MDA 1/1). Figura 2.7 – Instalación Física de un 7750 – SR7 (Capa de Core) Se debe mencionar que existe una cros‐conexión (fibra desde un puerto hacia el otro) en la capa de Core entre los puertos 1/1/1 y 1/1/2, 2/1/1 y 2/1/2 denominada hair‐pinning que es la que permite el traspaso de información desde la VPLS de acceso hacia la VPRN de gestión de Nodos (se verá más adelante en el Capítulo 3) 2.3 Protocolos empleados para la implementación de la solución Mobile Backhaul IP‐MPLS 59 En este apartado se dará una visión detallada de los protocolos utilizados y las características clave que hacen posible implementar lógicamente la solución Mobile Backhaul IP‐MPLS de la empresa. Todos estos protocolos son utilizados en los router 7705 y 7750 vistos anteriormente menos VRRP que solo es ocupado en la VPRN en los 7750‐SR7 de la Capa de Core. 2.3.1 MPLS MPLS es utilizado como el protocolo de transporte en la red de transporte Mobile Backhaul. La función básica de MPLS es extendida a través del despliegue de las extensiones MPLS con Traffic Engineering (TE). TE es requerido para manipular el comportamiento de la red de manera de poder dirigir el tráfico por diversos caminos basados en ciertas condiciones, entre los que se encuentran disponibles: ‐ Especificación del camino salto‐a‐salto ‐ Límite en el número de saltos ‐ Reserva de ancho de banda ‐ Grupos Administrativos (o coloreado de enlaces) ‐ Reenvío basado en clase de servicio ‐ Prioridad RSVP‐TE permite especificar el camino (path) salto‐a‐salto, de esta manera se tiene la ventaja de disponer de un control total sobre el camino que el tráfico seguirá, pero con la desventaja administrativa de configurar y mantener dichos caminos. En otras situaciones limitar la cantidad máxima de saltos que un camino puede tener ofrece la posibilidad de mantener el retardo en un nivel controlado y en última instancia con un límite, justamente al acotar la cantidad de saltos que un LSP puede contener. En cuanto a la opción de reserva de ancho de banda existen dos mecanismos, a saber: 60 ‐ Fixed Filter (FF): Si un LSP tiene un camino secundario en standby, existe una reserva separada por cada camino. El ancho de banda total reservado para un LSP será la suma del primario más todos los secundarios que existan. ‐ Shared Explicit (SE): Si un LSP tiene uno o más caminos secundarios en standby, el monto total de ancho de banda reservado es el del camino con mayor reserva de ancho de banda. El grupo administrativo o coloreado de enlaces permite incluir o excluir un enlace del camino que puede tomar un LSP, requiriendo configuración manual. Así se puede disponer de un camino sobre enlaces de alta velocidad que puede ser indicado para clientes con alta demanda de tráfico, como los clientes con acceso a Internet, por otro lado, se pueden disponer de enlaces de baja velocidad y muy poco retardo que pueden resultar útiles para el transporte de VoIP. Así se pueden crear dos LSPs uno para cada tipo de tráfico con las opciones de incluir/excluir enlaces. El reenvío basado en la clase de servicio permite tener caminos alternativos dependiendo en la tipo de tráfico a transportar, o como aquel sea clasificado. Esto permite asociar las diferentes clases de servicio según son marcadas en el punto de acceso al servicio con caminos distintos, de manera de cumplir los objetivos de SLA. Finalmente, los LSPs pueden recibir trato prioritario, con valores de 0 a 7, siendo el valor menor el correspondiente a la más alta prioridad, de esta manera se establece una jerarquía en los LSPs sobre cuáles serán establecidos de acuerdo a la disponibilidad de recursos en la red. Cabe destacar que el mecanismo implementado en la línea de equipos Alcatel‐Lucent 7750 SR es el de construir antes de interrumpir (MBB, make‐before‐break), de esta manera cuando se crean los LSPs en combinación con los mecanismos anteriores, se analiza la disponibilidad de recursos de red, y las características solicitadas en la configuración de los LSPs. Así, si por un enlace están pasando varios LSPs, y un nuevo LSP con alta prioridad es creado con cierta configuración de reserva de ancho de banda que no está disponible en la red, los LSPs con menor prioridad serán removidos del enlace y enrutados por otros caminos. 61 2.3.2 Protección de tráfico de LSP RSVP‐TE también puede ser utilizado para ofrecer protección del tráfico ante un corte de un enlace o la salida de servicio de un nodo. Entre los tipos de protección de caminos se disponen de los siguientes: ‐ LSP Primario con LSP Secundario. ‐ LSP Primario con LSP Secundario en modo stand‐by. ‐ Fast Reroute ‐ Método Uno‐a‐Uno (One‐to‐One Method) ‐ Método de Respaldo de Instalaciones (Facilities Backup Method) Los anteriores métodos permiten resolver los problemas asociados con protocolos de routing tradicionales, tales como: ‐ Las fallas no son rápidamente detectadas. ‐ Lleva tiempo calcular una ruta alternativa. ‐ Lleva tiempo señalizar un LSP (Label Switch Path) alternativo y actualizar las tablas de rutas. A continuación se describen los mecanismos indicados. 2.3.2.1 Protección de camino – LSPs con Camino Secundario Non‐Standby El camino Primario y Secundario pueden ser configurados con saltos (hops) estrictos o sin definir (loose), o incluso sin especificar ningún salto, en este último caso RSVP‐TE comporta como LDP, donde el LSP sigue la mejor métrica (camino más corto) determinada por el IGP (OSPF). LSP Primario: Se define un único camino. 62 LSP Secundario: Presenta las siguientes características: ‐ Es un camino alternativo utilizado si el camino del LSP Primario no está disponible. ‐ Intenta continuamente de volver al camino Primario. ‐ Hasta 8 caminos Secundarios pueden ser definidos. ‐ Todos los caminos Secundarios son considerados iguales y el primero disponible es utilizado. ‐ La implementación en equipos Alcatel no conmuta entre los caminos Secundarios, únicamente intenta regresar al camino Primario. 2.3.2.2 Protección de Camino – LSPs con Camino Secundario Standby LSP Primario: Se define un único camino. LSP Secundario en stand‐by: Presenta las siguientes características: ‐ Es una opción únicamente disponible para el LSP Secundario. ‐ Asegura que el camino del LSP Secundario esté señalizado y mantenido indefinidamente, activo y listo para recibir tráfico inmediatamente después de detectar una falla en al camino Primario. ‐ Cuando el camino Primario es restablecido entonces el tráfico es conmutado nuevamente al LSP del camino Primario. 2.3.2.3 Comportamiento de conmutación de LSP con caminos secundarios ‐ Camino Primario sin definir, camino Secundario no está en stand‐by: Cuando una falla afecta el camino Primario, el nodo head‐end determina un nuevo camino Primario y re‐señaliza el LSP en este nuevo camino. El camino Secundario no es nunca pre‐señalizado y mucho menos empleado. 63 ‐ Camino Primario sin definir, camino Secundario se encuentra en modo stand‐by: Cuando una falla afecta el camino Primario, el nodo head‐end conmuta el LSP al camino Secundario, y determina un nuevo camino para el Primario. Si encuentra un nuevo camino Primario, entonces conmuta el LSP nuevamente al camino Primario. ‐ Camino Primario estricto, camino Secundario no está en stand‐by: Cuando una falla afecta el camino Primario, el nodo head‐end señaliza el camino Secundario y conmuta el LSP. Cuando la red se recupera de la falla el LSP revierte al camino Primario. ‐ Camino Primario estricto, camino Secundario en stand‐by: El comportamiento es el mismo que el caso anterior, excepto que el camino Secundario se encuentra señalizado y establecido. Implementar alguna de estas técnicas presenta las siguientes ventajas: ‐ Flujo de datos determinístico durante cualquier punto en el camino Primario. ‐ Múltiples fallas a lo largo del camino Primario puede ser resuelta por el mismo camino Secundario. ‐ Cuando el LSP se configura estáticamente, ningún nodo o enlace debe ser compartido entre los caminos Primario y Secundario, de otra manera si el nodo o enlace sale de servicio, ambos LSPs son afectados por la falla. ‐ El camino extremo a extremo es protegido Mientras que se exhiben las siguientes desventajas: ‐ La falla de un enlace o nodo podría llevar cierto tiempo en alcanzar el extremo del túnel, y de esta manera afectarse el tiempo de conmutación, ya que es este nodo el que ordena la conmutación al camino de protección. ‐ Los recursos de red son reservados en ambos caminos Primario y Secundario, resultando en una doble reserva. Consideraciones de escalabilidad deben tenerse en cuenta ante esta situación, especialmente ante un número grande de LSP protegidos. ‐ Protección selectiva de un nodo o enlace no es posible, se protege todo el camino. 64 2.4 Información General sobre Fast‐Reroute (FRR) FRR define la manera de pre‐configurar y señalizar rutas de respaldo antes de que una falla ocurra, permitiendo ofrecer conmutación sub‐50ms (equivalente a redes SDH). Utiliza LSP establecidos mediante RSVP‐TE, aplicando la protección lo más cerca posible del punto de falla. ‐ En caso de fallo de un enlace o LSP entre dos nodos, el tráfico se desvía inmediatamente en el LSP de respaldo pre‐calculado, reduciendo así al mínimo de pérdida de paquetes. ‐ Cada nodo Upstream crea un LSP de respaldo que evita sólo el nodo intermedio inmediato, y se une de nuevo en el camino original del LSP protegido. ‐ El LSP de respaldo puede tomar uno o más saltos antes de la fusión de nuevo en el camino LSP principal, y sólo pueden fusionarse en el eLER (egress Label Edge Router). ‐ Cuando el nodo Upstream es informado que un router intermedio utiliza el LSP de respaldo, el router de entrada (iLER o ingress Label Edge Router) conmuta el tráfico a una ruta stand‐by si se ha establecido una para la LSP. ‐ El iLER señaliza todos los routers intermedios mediante RSVP para iniciar los LSPs de respaldo. En cuanto a los recursos que pueden ser protegidos se cuentan enlaces y nodos. 2.4.1 Métodos FRR para realizar la protección de LSP Como se indicó más arriba, se disponen básicamente dos métodos de protección, que son los que se muestran a continuación: One‐to‐One Backup Facility Backup Diagrama de Protección de Enlace: 65 Figura 2.8 – Protección de Enlace El respaldo debe ser creado y señalizado antes de que la falla ocurra. El PLR (Point‐of‐Local‐ Repair) debe estar preparado para reenviar el tráfico del camino primario (primary path) y el MP (Merge‐Point) debe estar listo para devolver el tráfico de regreso al camino primario. El LSP de respaldo es llamado Detour en caso de protección 1:1 (One‐to‐One) ó Bypass en caso de protección N:1 (Facility) Figura 2.9 – Señalización Fast‐Reroute 66 El método One‐to‐one backup crea un detour LSPs (desvío LSP) para cada LSP protegido en cada PLR potencial. En cambio, el método Facility backup crea un túnel bypass para proteger un punto potencial de falla tomando ventaja del apilado de etiquetas MPLS (MPLS label stacking). Es túnel bypass puede proteger un conjunto de LSPs que tiene similares restricciones de respaldo. Con ambos métodos, los LSPs de respaldo puede ser establecidos para bien proveer protección de enlace o protección de nodo. 2.4.1.1 Funcionamiento de los distintos métodos One‐to‐one backup: Cada router por donde transita el LSP establece un detour LSP que es el mejor camino hacia el nodo destino, que evita el nodo y/o enlace en el punto de falla. Por cada LSP que es respaldado, un LSP de respaldo es establecido. Con este método, para proteger completamente un LSP que atraviesa N nodos, pueden existir tantos detour LSP como N‐1. Facility backup: Cada router por donde transita el LSP establece un LSP bypass (túnel) que es el mejor camino hacia el próximo‐salto (next‐hop) en caso de protección de enlace o próximo próximo‐salto (next‐next‐hop) en caso de protección de nodo, que evita el enlace ó el nodo próximo en el punto de falla. Todo LSPs que atraviese el mismo enlace o nodo para el cual un túnel bypass ha sido creado, puede ser protegido por este túnel de bypass. Con este método, para proteger completamente un LSP que atraviesa N nodos, pueden existir tantos túneles bypass como N‐1, con la diferencia que sí otro LSP atraviesa los mismos nodos/enlaces, puede ser protegido con este túnel de bypass, no siendo necesaria la creación de otro. Facility backup con protección de enlace: Esta técnica emplea el apilado de etiquetas (MPLS label stack). En lugar de crear un LSP separado para cada LSP a proteger, un único LSP es creado que sirve como respaldo a un conjunto de LSPs. Este LSP recibe el nombre de bypass tunnel. El túnel de bypass debe intersectar el camino original en algún punto downstream del PLR. 67 Figura 2.10 – RSVP TE – Facility Backup – Intercambio de etiquetas Con el método Facility backup, el PLR inserta (push) la etiqueta recibida por su vecino, el cual no está disponible ahora por la falla del enlace. En el diagrama de más abajo, R3 propagó la etiqueta 32 hacia R2 antes que el enlace falle. Esta etiqueta 32 es ahora insertada en la pila de etiquetas (label stack) del paquete además de la etiqueta obtenida por el nodo vecino de respaldo en el sentido Upstream, R7 en este caso. El resultado es una pila de etiquetas mayor, donde generalmente se emplean dos, aquí se obtiene un stack de tres etiquetas. El MP (Merge Point), R3 es este caso, quita la etiqueta superior y examina la etiqueta que sigue. Esta etiqueta es la misma que hubiera recibido directamente de R2 si el enlace no hubiera fallado. La única diferencia es que recibe esta etiqueta en una interface diferente, salvo este punto, el paquete MPLS luce como si hubiera sido enviado por R2. 68 Figura 2.11 – RSVP TE – Facility Backup – Falla de Enlace Facility Backup con protección de nodo: Requiere que el PLR conozca la dirección del MP (obtenida de los registros RRO) y que el PLR conozca la etiqueta propagada por el MP Upstream para proteger el nodo (obtenida del registro RRO con el uso del flag “label recording desired”) 69 Figura 2.12 ‐ RSVP TE – Facility Backup – Intercambio de Etiquetas Protección de Nodo Atendiendo al tipo de servicio a proteger se recomienda el uso de LSPs primario con FRR y secundario con señalización stand‐by para servicios de voz, señalización, valor agregado y protección con enlaces de terceros usando el método one‐to‐one. De esta manera el tráfico se puede recuperar rápidamente de la falla y luego conmutar a un camino más óptimo y controlado mediante el uso del LSP secundario. Debido a la señalización y demanda de recursos al emplear este tipo de protecciones no se recomienda proteger a los servicios del tipo best‐ effort. 70 Figura 2.13 – Facility Backup – Falla de Nodo 2.5 Métodos de detección de errores en los Enlaces 2.5.1 BFD El protocolo más comúnmente empleado para la detección de fallas es el Bi‐Directional Forwarding Detection (BFD). BFD tiene por objetos proporcionar una sobrecarga mínima en la red y ofrecer la detección de fallas de corta duración en el plano de datos. Es un protocolo de baja complejidad. El principal modo de operación de BFD se conoce como modo asincrónico. En este modo, BFD utiliza mensajes periódicos de control para comprobar la ruta de acceso entre los sistemas. Si un número de paquetes consecutivos no se reciben, la sesión es terminada y la falla se propaga a cualquier protocolo asociado a la sesión BFD como ISIS, OSPF, PIM, ó LDP. 71 Figura 2.14 – Bi‐Directional Forwarding Detection Debido a BFD es un protocolo ligero, puede ser implementado en las tarjetas de línea, la frecuencia de envío del mensaje “hello” puede ser inferior al segundo sin afectar ninguna actividad del plano de control. El router 7750 SR soporta intervalos en la frecuencia del “hello” tan bajos como 100 milisegundos con un factor de multiplicación de 3 en la detección de “hellos” perdidos (es decir, la pérdida de 3 mensajes “hello” consecutivos) la falla se detectará en un tiempo inferior a los 300 milisegundos. Mientras BFD es un mecanismo de detección de fallos excelente, tiene algunas desventajas: En el modo BFD asincrónico, las fallas en sentido unidireccional no se detectan. Para detectar un fallo unidireccional requiere soporte para el modo bajo demanda (mensajes del tipo “are you there”; “yes I am”) o de la función echo, ambos de los cuales es poco probable que se implementen en los sistemas de reenvío en los sistemas distribuidos. BFD exige la vinculación con cada protocolo que requiere la detección de fallos rápidamente. 2.6 Agregación de Enlaces Sobre la base del estándar IEEE 802.3ad un Grupo de Agregación de Enlaces (Link Aggregation Group ‐ LAG) puede ser utilizado para agrupar hasta ocho puertos físicos en un único enlace lógico. Esta agregación de múltiple enlaces físicos permite repartir la carga entre los enlaces miembros, también permite una recuperación rápida del tráfico ante la falla de un 72 enlace miembro del LAG. La carga de tráfico es compartida sobre todos los enlaces miembros mediante un algoritmo que determina el direccionamiento (hashing), este último toma las variaciones de entrada y deriva una salida en 20 bits que es utilizado para determinar que miembro LAG a utilizar. El algoritmo Hash siempre utilizará el puerto fuente y la dirección IP sistema como valor base para iniciar el cálculo del hash, sin embargo el resto de las entradas hash dependerán de si el 7750‐SR, que soporta el LAG (donde los pseudowires y VPLS utilizan el ID de servicio como dato de entrada), es de ingreso o de tránsito (cuando la pila de etiquetas MPLS se utiliza como entrada). En el caso que la empresa desee utilizarlos, los LAGs serán aprovisionados en los puertos de acceso, cuando se necesite más de 1 GE o también pueden ser en los puertos de red al interconectar equipos SR para el transporte de tráfico, en este caso se usará para los nodos B hacia el RNC que le corresponda. Es sin embargo recomendable configurar esto desde el inicio ya que en este caso la incorporación de más GE en el LAG no será disruptiva. El 7750‐SR puede soportar hasta ocho puertos en cada LAG y hasta 200 LAGs por chasis. Cada enlace físico dentro de un grupo LAG debe tener la opción de auto‐negociación deshabilitada y estar configurado con la misma velocidad y dúplex. Se recomienda la utilización de Grupos de Agregación de Enlaces LAG para suministrar aumentos de ancho de banda graduales. Se recomienda utilizar el Protocolo de Control de la Agregación de Enlaces (Link Aggregation Control Protocol LACP) que permite incorporar y borrar enlaces físicos de un LAG dinámicamente. En la red IP‐RAN que estamos analizando se configura un grupo LAG para proteger la cros‐conexión o “hair‐pinning” visto anteriormente; este LAG se configura para respaldar el envío de información desde la VPLS de acceso hacia la VPRN por lo tanto si falla el puerto 1/1/1 queda como respaldo automático el puerto 2/1/1 (definidos en el LAG‐1) y viceversa; si por algún otro motivo falla el puerto 1/1/2, queda como respaldo automático el puerto 2/1/2 y viceversa (ambos puertos definidos como LAG‐2) 73 2.7 IP Routing/IGP Puesto que el diseño de la solución se basa en IP y protocolos sobre IP, como MPLS, es necesario tener conectividad entre todos los equipos involucrados en las decisiones de enrutamiento, en este caso los routers propuestos. La conectividad puede lograrse ya sea utilizando OSPF o ISIS (enrutamiento dinámico), así como también enrutamiento estático (para despliegues pequeños). Dentro de una red MPLS, el IGP (o estático) es necesario que direcciones del sistema (Loopback addresses) sean alcanzables entre los routers habilitados por MPLS. Una vez que se ha establecido la accesibilidad de la capa IP entre las direcciones del sistema de los routers adyacentes y no adyacentes, los protocolos de señalización MPLS entran en juego. En la implementación de este tipo de Redes, la infraestructura del Protocolo Gateway Interior (Interior gateway protocol ‐ IGP) proporciona el transporte subyacente para el pseudowire superpuesto. Esto forma la base para la conectividad entre el sitio celular móvil y el sito central (core) móvil (a saber la ubicación RNC). El diseño IGP se basa en las siguientes consideraciones claves: La zona de cobertura se divide en diversas regiones donde el tráfico agregado del sitio celular es entregado al sitio central (core) móvil correspondiente a dichas regiones. Esto significa que el tráfico irá al HR que está directamente conectado al RNC (Radio Network Controller) vía Gigabit Ethernet o ATM (STM‐1). Todo el tráfico que va a otros elementos móviles (principalmente el de la Red Central (core) Móvil, donde residen los sistemas SGSN y GGSN) será transportado vía el backbone IP/MPLS Central (Core). Un enfoque simple ha sido adoptado, el cual permite satisfacer una gran cantidad de sitios celulares. En la mayoría de las redes MPLS a lo largo de Chile se utiliza el protocolo IGP OSPF y es el utilizado en este trabajo de titulación. 74 2.7.1 Diseño de Extremo a Extremo de OSPF OSPF es un protocolo Gateway interior (IGP) usado dentro de los sistemas autónomos (ASs) grandes. El dispositivo OSPF intercambia con su vecindad el estado, costo y otras informaciones relevantes de la interfaz. El intercambio de información permite a todos los elementos de red participantes establecer un mapa de la topología de red. Cada dispositivo aplica el algoritmo Dijkstra para calcular la ruta más corta para cada destino en la red. El resultado de la tabla de forwarding OSPF es presentado al administrador de la tabla de enrutamiento (Route Table Manager ‐ RTM) para calcular la tabla de enrutamiento. Las implementaciones en 7705 SAR y 7750 SR para OSPF conforman la Versión 2 del OSPF de las especificaciones presentadas en el RFC 2328. El diseño de OSPF necesita ajustarse a los límites teóricos siguientes: Tabla 2.1 – Límites teóricos de OSPF Para este tipo de redes, la arquitectura de la red consiste en clúster por regiones, donde cada equipo de Core se conecta a uno o más agregadores, es necesario para cada región desplegar áreas. El resultado de la topología IGP conformará la base del establecimiento de las sesiones MPLS LDP y/o RSVP‐TE entre los nodos centrales. 75 2.7.2 Otras Consideraciones de diseño OSPF en redes IP‐RAN 2.7.2.1 ID de Área En los routers IPRAN habrá un área backbone 0.0.0.0 y un área por Cluster de acuerdo a cada zona y al 7750 SR‐7 en la capa de agregación que actúa como Router de Borde de Área (Area Border Router ABR) y los CSRs como stub‐áreas con el fin de disminuir el tamaño de la base de datos topológica. Un área Stub corresponde a un área designada que no permite publicar rutas externas. Los routers en las áreas Stub no mantienen rutas externas. Una ruta por defecto, única hacia un ABR reemplaza todas las rutas externas. Esta implementación OSPF soporta la opción de supresión de publicación de ruta resumen (tipo 3) de otras áreas dentro de un área Stub. Esta facilidad reduce todavía más el tamaño de las bases de datos de topologías así como también el tráfico de protocolo OSPF, el uso de memoria y el tiempo de procesador ocupado en el cálculo de rutas. Las áreas Stub deben ajustarse a los atributos siguientes: ‐ Las áreas deben ser sin salida. Es decir que la única razón para ingresar a un área será para acceder a la red que se encuentra dentro de esta misma. El tráfico no debería pasar a través de un área para alcanzar otra locación. ‐ Los enlaces virtuales (virtual links) no están soportados. ‐ LSAs de tipo 4 y tipo 5 están bloqueados por el ABR y en su lugar se publica una ruta por defecto dentro del área ‐ Sin embargo, LSAs de tipo 3 (resúmenes) se mantienen publicados. Área Stub, sin resumen deben asignar los atributos siguientes: ‐ Todos los atributos de un área Stub son los mismos 76 ‐ Al agregar “sin resumen”, el ABR bloquea los LSAs de tipo 3, 4 y 5; en su lugar publica una ruta por defecto. El ABR origina un LSA de tipo 3 dentro del área Stub. El estado del enlace es 0.0.0.0, y la máscara de red es puesta en 0.0.0.0. ‐ El término utilizado en la industria es “totalmente stubby” (“totally stubby”). 2.7.2.2 Router ID OSPF El router ID es un número de 32 bits que identifica unívocamente el router dentro del Sistema Autónomo (AS). El router ID estará basado en la interfaz‐de sistema que es un sistema virtual siempre operacional “always up”. Si no hay un router ID especificado, por defecto el router ID utilizará la interfaz sistema, en caso que no exista tomará los últimos octetos de la MAC del chasis. 2.7.2.3 Autenticación de Enlace OSPF (Opcional) La autenticación MD5 puede ser habilitada opcionalmente para todos los intercambios de protocolo OSPF (Autenticación basada en el enlace). 2.7.2.4 Selección del tipo de red OSPF Hay una combinación de interfaces de las tarjetas de 1 Gigabit, 10 Gigabit, STM‐1 que conectan ya sea la Red Móvil Core o la red de transporte backhaul. Aunque OSPF considera los puertos Ethernet como red broadcast por defecto, habrá enlaces en los routers que serán configurados explícitamente como de punto a punto para reflejar la conexión real punto a punto entre routers. En caso que un enlace común sea compartido por al menos dos routers este será configurado como broadcast. Se debe tomar en cuenta que la arquitectura de 77 transporte físico subyacente puede no ser punto a punto, aunque lógicamente el router de interconexión lo sea. Configurar la interfaz como OSPF punto a punto mejorará los tiempos de convergencia ya que el router no tiene que seleccionar un Router Designado (DR) y un Router Designado de Respaldo (BDR), proceso que normalmente ocurriría en una red broadcast. Otro beneficio es que el tamaño de la base de datos OSPF será menor ya que no se requiere almacenar LSA de red (LSA tipo‐2) y por lo tanto se reduce la cantidad de propagación de mensajes LSA (Link State Advertisement). Los LSA de red son generados por un Router Designado en la red de broadcast. 2.7.2.5 Ingeniería de Tráfico OSPF Para la distribución de etiquetas se utilizará RSVP‐TE por lo tanto es necesario habilitar la extensión de Ingeniera de Tráfico OSPF. 2.7.2.6 Métricas y temporizadores OSPF Las métricas de costos OSPF son utilizadas para calcular cual es la mejor ruta para el tráfico; las métricas están basadas en el ancho de banda configurado en los enlaces. Se recomienda dejar la métrica OSPF por defecto para reflejar el ancho de banda real configurado en el enlace (estos pueden ser enlaces GE o LAGs), sin embargo existen casos donde el enlace de interconexión entre nodos IP‐RAN es provisto por terceros (microondas, ROADM, DWDM), con un ancho de banda que corresponde a una fracción de la velocidad del puerto, en tales casos la métrica OSPF será modificada para reflejar la situación real de este caso. Los temporizadores OSPF deberían ser dejados por defecto. 78 2.8 Tráfico Móvil – Modelos de Transporte 2.8.1 2G (TDM) / 3G (ATM) Se hace común utilizar MC‐APS (multichassis APS) para ambos servicios en conjunto con la característica PW Redundacy, este mecanismo provee protección tanto en el acceso (BTS/NodoB) como del lado MTSO (BSC/RNC). El esquema es el siguiente, siendo para el caso ATM muy similar. Figura 2.15 – MC‐APS con Pseudowire Redundancy Para el caso TDM se debe utilizar en los equipos 7750 tarjetas del tipo CES (Circuit Emulation Services), mientras que para ATM se requiere tarjetas del tipo ASAP (Any Service Any Port). Las primeras permiten utilizar canalización hasta nivel de DS0 (timeslot en tarjetas STM‐1) o hasta nivel DS1 (E1 completo en tarjetas STM‐4/STM‐1) dependiendo del servicio que se ofrezca. En cambio, del lado acceso, para el caso TDM se debe transportar el tráfico mediante PW CES (Cpipe) utilizando PW Redundancy originado en el router de acceso (por ejemplo, en un equipo Alcatel‐Lucent 7705 SAR‐F/M/8), proveyéndose un PW por cada circuito E1 a transportar. En cambio para el caso ATM, por lo general los nodos B utilizan grupos IMA (Inverse Multiplexing over ATM) agrupando lógicamente varios circuitos E1, terminando este grupo en el router de 79 acceso, y de allí se pueden configurar un PW ATM (Apipe) con redundancia por cada par de VPI/VCI requerido, o transportar todo el VP en un solo PW ATM. 2.8.2 3G y LTE (IP) El modelo de bakchauling es el presentado en la siguiente figura, donde el tráfico desde los NodosB/eNodeBs es transportado mediante un PW Ethernet (Epipe ó L2 VLL) originado en el router de acceso (por ejemplo, Alcatel‐Lucent 7705 SAR‐F/M/8) y terminado en una interface IP (L3) en un IP‐VPN (VPRN) en los equipos 7750 de borde de la red MetroEthernet o simplemente agregandolo en una VPLS para después subirlo a la capa 3 a través de un hair‐pinning. Figura 2.16 – Arquitectura Lógica de Red para tráfico 3G y LTE Este modelo presenta la ventaja de simplificar el plano de control, ya que no se requiere un sesión MP‐BGP (para el intercambio de prefijos IP de la IP‐VPN) entre todos los equipos 80 (sesiones full‐mesh) de Acceso, Agregación (ME edge) y MTSO, sino únicamente entre los equipos del Core, es decir, los HRs y MTSO. Igualmente en este esquema se recomienda el uso de Route Reflector (RR) para optimizar el plano de control, requiriendo únicamente dos sesiones entre los equipos HRs y MTSO contra los RR (primario y backup). Para el caso particular de LTE este escenario debe resolver las necesidades de comunicación entre los e‐node Bs y entre estos y el EPC (Evolved Packet Core), las interfaces y flujos se muestran en el siguiente gráfico, donde en particular se crearán dos servicios IP‐VPN que podrían ser diferentes a la IP‐VPN actual de para los servicios 3G, uno para la comunicación entre e‐NodoBs (interface X2) y otra para la comunicación con el EPC (Interfaces S1‐MME, S1U). 2.9 Calidad de Servicio La Calidad de Servicio (QoS) se define en términos de los requisitos subyacentes para las aplicaciones que se pueden clasificar en términos de Service Level Agreement (SLA) según: delay, jitter, packet loss, throughput, service availability y per‐flow sequence preservation. 2.9.1 Necesidad de Calidad de Servicio El concepto fundamental de la calidad de servicio es que no todos los paquetes requieren un tratamiento igualitario. Las tecnologías de QoS en una red de conmutación de paquetes le permiten a diferentes aplicaciones lidiar desigualmente de los recursos de red y aplicaciones en tiempo real como voz y video, que podría ser objeto de un tratamiento preferencial con respecto a otras aplicaciones que no tienen tales requerimientos de calidad. Es imprescindible comprender que el despliegue de las tecnologías de QoS optimiza la utilización del ancho de banda disponible. No genera ancho de banda y no sustituye la falta de capacidad disponible. 81 Incluso con una gran cantidad de ancho de banda, pueden existir eventos que causan la congestión transitoria de un enlace de red: 1. Falla en la planificación de capacidad, lo que puede ocurrir si el ancho de banda no ha sido adecuadamente aprovisionada ante una falla no planeada de un nodo o enlace. 2. Falla en múltiples nodos/enlaces, la planificación de la capacidad es un trade‐off entre la capacidad y el costo, y por lo general el modelo de planificación empleado usualmente es para garantizar la supervivencia contra falla única, tanto de nodo como de enlace. En un fallo múltiple de enlace/nodo, la naturaleza determinista y el modelo de la carga de tráfico ofrecido puede cambiar drásticamente. 3. Aumento no planificado del patrón de tráfico, en condiciones normales de funcionamiento puede haber peaks en la carga de tráfico ofrecido que tiene una estrecha relación con la congestión de los períodos transitorios. Además, puede haber aumentos imprevistos del patrón de tráfico que no han sido modelados con precisión que causa que un enlace individual se encuentre congestionado por un período corto de tiempo. Un ejemplo de las demandas de tráfico inesperados que pueden causar la congestión es un ataque distribuido de denegación de servicio (DDoS). Los mecanismos de QoS queuing/scheduling deben ser desplegados en la red troncal IP / MPLS para proteger las aplicaciones que sufren en caso de congestión transitorias y no anticipadas. La aplicación evidente donde esto se aplica es al tráfico en tiempo real sensible al retardo que es transportado a través de la red, el cual requiere garantías de servicio independientemente de las condiciones de la red. Tan pronto como una forma de tráfico es transportada con un tratamiento preferencial (por ejemplo, Voz), entonces se vuelve necesario proteger los recursos utilizados por este tráfico y comprender el impacto sobre otras fuentes de tráfico que son menos exigentes en recursos de la red (por decir, una transferencia de archivos 82 de datos). Además de tráfico de voz, tráfico de control crítico es llevado a través de la red IP / MPLS incluyendo el tráfico del plano de control (como, BGP, RSVP). Aunque no tan exigente como el tráfico de tiempo real, es fundamental que este tráfico reciba la garantía de la entrega oportuna de tal manera que en el caso de una congestión temporal, este tráfico recibe un mínimo ancho de banda en cada enlace del router. 2.9.2 Diseño de la Calidad de Servicio 2.9.2.1 Objetivos del Diseño Los objetivos de diseño del despliegue de QoS (Quality of Service) dentro de la red IP/MPLS son los siguientes: 1. La funcionalidad QoS será empleada en cada nodo en el camino de un flujo de tráfico de datos de cliente con el fin de proporcionar un tratamiento coherente de paquetes de extremo a extremo a través de la red. 2. Minimizar el número de colas necesarias en los nodos P y PE para satisfacer los requerimientos de demanda de aplicaciones diversas. 3. Los paquetes de tráfico de clientes se clasificarán sólo una vez durante su transmisión a través de la red. 4. En general, se asegurará que el IP precedente (IPP), el marcado DSCP, o el marcado 802.1p establecidos por las redes de clientes se conservarán en toda la red y será restaurado en el egreso de la misma. Casos de excepción incluyen cuando el PE realiza un remarcado IPP / DSCP / 802.1p del tráfico en los límites de la red externa (por ejemplo Internet). 5. Se asegurará que el tráfico del plano de control del router cuenta con un ancho de banda mínimo en cada uno de los P y PE, con independencia de las cargas de tráfico en otras clases. 83 6. Se asegurará que el tráfico en tiempo real que requieran una clase de servicio en particular, se proporcionará con un PHB del tipo expedite forwarding con el fin de minimizar el delay y jitter experimentado. 7. Se proporcionará una clase de servicio del tipo assured que proporcione un servicio mejor que la del tipo best‐effort (es decir, de baja pérdida y de bajo retardo). 8. Se asegurará que el router que originó el tráfico del tipo OAM cuenta con un ancho de banda mínimo en cada uno de los P y PEs a lo largo del camino, con independencia de las cargas de tráfico en otras clases. 2.9.2.2 Clases de Servicio Una clase de servicio representa un tipo de tráfico que demanda un tratamiento especial sobre un conjunto de características tales como retardo end‐to‐end, delay, pérdida de paquetes y jitter con un comportamiento coherente y definido salto a salto (per‐hop behaviour). Conceptualmente, se da una clase de servicio a las aplicaciones de similares características y requisitos de funcionamiento. Nuestra red IPRAN en cuestión es capaz de soportar las siguientes clases de servicio: 1. CONTROL 2. USER CONTROL 3. REALTIME 4. BUSINESS DATA 5. STANDARD 2.9.2.2.1 Clase de Servicio CONTROL Esta clase de servicio se utiliza para el tráfico de señalización de los protocolos entre los routers. La señalización entre los routers es responsable de mantener la topología lógica de la 84 red; estos protocolos son los más importantes que atraviesan la red IP/MPLS, aún más importante que el tráfico de voz (VoIP) de clientes. Si los protocolos de señalización entre routers se ven afectados, entonces esto puede afectar a todo el tráfico que pasa por un router P/PE. Esta clase de servicio de alta prioridad asegura que la congestión en la red no afecta la capacidad de señalización de los protocolos de red para gestionar la entrega del resto de los servicios. Las aplicaciones que puede utilizar la clase de servicio CONTROL son el tráfico del plano de control que se origina por la red en sí misma (es decir, BFD, RSVP), o el tráfico del plano de control que atraviesa por lo menos un nodo P o PE (MP‐BGP, T‐LDP). También el tráfico OAM se asigna en esta clase. 2.9.2.2.2 Clase de Servicio USER CONTROL Esta clase de servicio se utiliza para el tráfico de señalización de los protocolos procedentes de dispositivos de cliente. Normalmente, esta clase contendrá los siguientes protocolos: a) Paquetes de los protocolos PE‐CE originados desde el CE (por ejemplo: OSPF, BGP, RIPv2) b) El tráfico de gestión de los dispositivos CE (por ejemplo, telnet, SSH, SNMP, etc.) c) Señalización móvil para los Nodos B Aunque estas aplicaciones tienen que ser entregados con una prioridad muy alta, deben usar una clase diferente de la señalización de los protocolos de enrutamiento entre los clientes, ya que no deben tener ninguna posibilidad de enviar este tráfico con la misma prioridad que los protocolos de red. 85 2.9.2.2.3 Clase de Servicio REALTIME Esta clase de servicio se utiliza para aplicaciones que requieren tanto un retardo, como jitter y pérdida de paquetes muy bajo para fuentes relativamente constante de tasas de tráfico. Es mandatorio que las siguientes aplicaciones utilicen esta clase de servicio para asegurar la calidad: a) Voz sobre IP (VoIP) b) Video bajo Demanda (VoD) c) Difusión de Señales de Televisión (Broadcast TV – BTV) 2.9.2.2.4 Clase de Servicio BUSINESS DATA Esta clase de servicio tiene por objetivo servir a las aplicaciones de negocios que deben recibir acceso prioritario al ancho de banda disponible por sobre las aplicaciones estándar. Es posible configurar una tasa de suscripción sobre una interfaz (muy probablemente hacia un CPE/MTU de cliente), tal que si el cliente sobrepasa dicha tasa, aún su tráfico puede ser clasificado como parte de esta clase de servicio, pero deberá ser marcados como fuera de perfil (out‐of‐profile). Esta marca debe ser mantenida en todo el dominio DiffServ. Sólo en el caso de congestión este tráfico fuera de perfil podrá ser objeto de descarte, en las redes móviles se puede definir el tráfico de datos que tiene mayor prioridad que los datos normales, como es el caso de HSPDA+, que define dos tipos de tráfico de datos. 2.9.2.2.5 Clase de Servicio STANDARD La clase de servicio STANDARD se usa para transportar todos los tipos de tráfico no servidos por las clases anteriores. Este remanente de tráfico generalmente es utilizado por 86 protocolos que son capaces de mantener alguna forma de conectividad aún durante períodos de congestión. Esta clase de servicio es configurada para proporcionar un pequeño porcentaje de los recursos de red como para asegurar que los paquetes son transportados. Esta asignación mínima de recursos de transmisión (es decir, ancho de banda disponible vinculado a una cola) garantiza que, en caso de congestión en una interfaz, el ancho de banda de esta clase de servicio se ajustará a la menor cantidad de ancho de banda disponible entre todas las clases de servicios. La cantidad real de ancho de banda (según lo determinado por el tamaño de enlace), así como la carga ofrecida determinará el desempeño de esta clase bajo estas condiciones. Se recomienda que las siguientes aplicaciones utilicen la clase de servicio STANDARD o best‐effort: a) Todo el tráfico hacia y desde Internet b) Todo tráfico no clasificado en las clases anteriores de servicio 2.9.2.3 Política de Calidad de Servicio de Red Hay una clara diferencia entre la granularidad de comportamiento por salto (PHB) en las interfaces de cliente y la granularidad de PHB en interfaces de red. En las interfaces de red donde hay un gran número de clientes agregados, los flujos de cola y la programación (scheduling) es menos granular para reducir la complejidad de la red. Por el contrario, en las interfaces de los clientes existe la posibilidad de tener mucho más granularidad en las colas (queues) para obtener el tratamiento necesario para el transporte de las diferentes clases de tráfico. Sólo cinco clases de servicio de red se definen: Control, User Control, Real‐time, Business Data y Standard. En el network edge, políticas de Ingress QoS mapean el tráfico de las aplicaciones en una de las ocho categorías definidas en el Forwarding Class (FC). La política de calidad de servicio de red define un mapeo de muchos‐a‐una de las FC a las cuales se asignan las aplicaciones y las cinco clases de servicio de red. 87 Clases de Servicios (colas, prioridad, CIR/PIR) Clases de Servicios Cola de Red Prioridad CIR PIR CONTROL 8 High 10% 100% USER CONTROL 4 High 25% 100% Voz ‐ VoIP o TDM 6 High 100% 100% Vídeo 5 High 100% 100% BUSINESS DATA 3 Low 25% 100% STANDARD 1 Low 0% 100% Tabla 2.2 – Tipos de Colas y asignaciones de PIR/CIR 2.9.2.4 QoS en el Acceso Como un recordatorio de los objetivos de diseño de QoS, por un lado, el QoS de entrada en el acceso se asocia con un punto de acceso de servicio (SAP) y es responsable de la clasificación de tráfico en el FC basado en criterios relacionados con Capa 2 (como, MAC address, 802.1p, Ethertype), de Capa 3 (como, IP de origen/ destino, protocolo, DiffServ Codepoint/IP precedence) o de la Capa 4 (tal como puerto de origen/ destino). Las colas de ingreso (ingress queues) son posteriormente asociados a cada FC y los recursos relacionados, como el buffer de paquetes, los valores de tasas de transferencia permitidas para el tráfico in‐ profile/out‐of‐profile, y la prioridad de programación (hacia el fabric switch) se asignan a cada cola. Por otro lado, de igual manera se asocia la QoS de salida en el acceso con un punto de acceso de servicio (SAP) para la asignación de tráfico en colas de salida basadas en FC o DSCP. Los recursos, como el buffer de paquetes, las tasas de tráfico permisibles, y la prioridad de programación (hacia el fabric switch) se asignan a cada cola. 88 En nuestra red IPRAN se van a tener cuatro tipos de servicios serán configurados para la red Móvil 3G/2G: ‐ Punto a Punto (point‐to‐point), pseudowires para 2G/3G. ‐ L2 VPN Punto a Multipunto (point‐to‐multipoint) ó Hub and Spoke ‐ L2 VPN Multipunto a Multipunto (multipoint‐to‐multipoint) ó Full Mesh ‐ L3 VPN (sin soporte para multicast) En la mayoría de los equipos es posible crear plantillas de calidad de servicio, que pueden ser reutilizadas para varios los demás equipos y en caso de nuevos servicios se deberá crear los perfiles necesarios. Por otra parte, en el momento que la plantilla se aplica a un SAP particular, es posible remplazar los siguientes parámetros: CIR, PIR, MBS, CBS. Todos los demás parámetros se heredan de la plantilla de QoS (es decir, número de colas, los criterios de clasificación, remarcado dot1p, etc). 89 CAPÍTULO 3 ‐ Implementación de MPLS en una red corporativa, y arquitectura de una red Mobile Backhaul Para realizar la implementación de una nueva red de transporte de información dentro de una empresa de telecomunicaciones es necesario contar con la disponibilidad de una red de fibra óptica (planta externa) y/o red de transmisión capaz de soportar anchos de banda de 1Gbps en los anillos que unen a los CSR (SARM, SAR8, SARF) en la Capa de Acceso y de 10Gbps sobre la Capa de Agregación; sin la disponibilidad de una red de fibra óptica sería casi imposible cumplir con los requerimientos de ancho de banda para interconexión de estos routers. En este módulo se analizará la arquitectura de una red IPRAN (IP – Radio Access Network) basados en los criterios de redundancia y lineamientos definidos para los ISP descritos en el capítulo 1 y en las consideraciones especiales de diseño de protocolos de routing, switching y MPLS establecidas en el Capítulo 2; además se definirá la instalación de un router de ejemplo (CSR) dos MR y dos HR que concentrarán el tráfico proveniente de Nodos B para realizar su configuración lógica completa y explicación detallada. Se abordará también el análisis de la arquitectura lógica de la red y la implementación de una solución con los protocolos descritos en el Capítulo 2 y así cumplir con los requerimientos de una red de servicios escalable y rentable. 3.1 Topología Física La topología física analizada corresponde a la de una empresa de telecomunicaciones del rubro dentro de la cual se han hecho visitas en terreno para revisar su instalación, configuración física del equipamiento, mostrado en el Capítulo 2 (distribución de tarjetas sobre los equipos; IOM y MDA) 90 La topología Física de la red IPRAN que analizaremos corresponde a la que se muestra en la Figura 3.1; el objetivo de este capítulo es abordar los criterios de diseño que nos llevarán a definir los distintos puntos de la red como son: ‐ Última milla ‐ Agregación ‐ Core Se debe instalar donde sea necesario un 7705 en cada sitio celular para la agregación del tráfico TDM proveniente de las estaciones base y agregación de tráfico Ethernet/E1 proveniente tanto de las BTSs como de los Nodos B (UMTS), cada sitio donde se realice al nodo se le llamará CSR (Cell Site Router). Figura 3.1 – Clúster de red IPRAN Básicamente la Figura 3.1 muestra los distintos niveles de agregación de tráfico (Acceso, Distribución y Core) presentado por las estaciones base, en los cuales el tráfico E1/Ethernet es agregado por los CSRs. El CSR puede conectarse directamente a los equipos siguientes: 91 ‐ Otros CSRs en los anillos de 1Gbps, agregados en la capa de Distribución por los nodos 7750 SR‐7 MR, configurados en alta disponibilidad de manera tal que en caso de fallas se minimice el impacto en los servicios suministrados por la red. ‐ 7750 SR‐7 (como router de agregación central HR) conectado a la capa de Core en 10Gbps. El HR también se conecta al RNC vía nxSTM‐1 (1+1)/nxGBE (1+1) cada uno protegido. Este escenario será el utilizado en este tema de tesis donde todo el tráfico presentado por las Estaciones Base será entregado al RNC. La conexión variará entre ATM, cuando la conexión del Nodo B sea a través de nxE1 con a‐pipe PWs de servicio redundantes (PSW Redundancy), y conexiones Ethernet cuando el Nodo B esté conectado al CSR vía un cable Ethernet, es decir que los e‐pipes PWs de servicio redundantes serán agregadas en VPRN del HR (L3VPN) con objeto de asegurar la conectividad IP entre en Nodo B y el RNC. La topología de red es de tipo anillo donde cada 7705 SAR‐F/7705 SAR‐M actúa como CSR, cada anillo soportaría hasta 5 nodos que estarían conectados con enlaces de fibra oscura a 2 x 7750 SR7 actuando como punto de agregación MR, y a la capa Core donde 2x7750 servirán como punto principal de agregación HR. Esta conectividad depende de la ubicación del nodo y de la proximidad con otros nodos intermediarios y de agregación. En estas etapas, se consideran rutas de respaldo para proveer alta disponibilidad; en este caso solo se considerará la utilización de fibra para la verificación de funcionalidad de la topología. La arquitectura para esta empresa de telecomunicaciones se define en base a los siguientes criterios: ‐ 5 x CSR por Anillo de acuerdo a los cálculos de Ancho de Banda (BW) (se verá más adelante) ‐ 31 x Anillos en la Capa de Agregación; el cálculo BW máximo es alrededor de 80% permitiendo la expansión de la red ‐ Por cada sitio donde están ubicados los RNC existen un máximo de 3 MRs por cada pareja de HRs 92 3.1.1 Última Milla Para la red IPRAN se consideran Anchos de Banda para soportar los servicios actuales 2G/3G y futuros servicios como LTE (Long Term Evolution), con el fin de preparar las redes para los nuevos requerimientos. Por ejemplo, para el tráfico 3G se consideran servicios HSPA+ con segunda portadora con las siguientes consideraciones: Tabla 3.1 – Consideraciones de Ancho de Banda para servicios 3G/2G/LTE De acuerdo a la Tabla 6, significa que cada sitio CSR presentará en promedio 251 Mbps. Ahora, es necesario definir el factor de sobre venta y para esto en las redes de transporte Backhaul (MBH) es de un factor de OB=4 para la capa de acceso y un factor de OB=2 en la capa de agregación. PIR define la tasa de Información máxima que corresponde a una tasa máxima permitida donde el consumo puede sobrepasar, durante periodos de tiempo breves, los umbrales especificados por sobre el CIR y PIR define la Tasa de Información Comprometida que corresponde a la tasa y velocidad de información garantizada. Con los parámetros anteriores se hace necesario calcular el Ancho de Banda que es agregado por anillo, esto se puede estimar aplicando la formula siguiente: 93 Figura 3.2 – Fórmula de Cálculo de Ancho de Banda Donde n será la cantidad de nodos por anillo (5 nodos). El Ancho de Banda máximo resultante debe ser menor o igual a una ocupación del 70% de los recursos a nivel de acceso y un 80% máximo de ocupación a nivel de agregación. Con esta información y los factores de sobre venta, OB=4 para la red de acceso y de OB=2 para la capa de agregación. La topología creada para la conformación de los Clúster está compuesta por dos elementos importantes: 1. Anillo Físico: El anillo físico consiste básicamente en la malla de fibra óptica existente para la Red HFC y la red corporativa, sobre la cual se realizan análisis de convergencia, acceso y factibilidad de interconexión con los sitios móviles donde se encuentran las estaciones Bases 2G, 3G y LTE (en un futuro muy cercano). 2. Anillos Lógicos La conformación de anillos lógicos se basa en las principales premisas de diseño: i) Anillos Lógicos: La conformación de anillos lógicos se realiza para lograr una distribución balanceada y homogénea de equipos en la red, tomando como premisa 5 CSR por anillos lógico para un límite de tráfico de 1GB por anillo 94 ii) Definiciones de Ancho de banda: Para el caso de la FO no se recomienda aplicar ningún valor iii) Vulnerabilidad: Los anillos lógicos son conformados por 2 o más anillos físicos que no pertenezcan a la misma ruta de la red física para evitar la pérdida del anillo ante cualquier falla de la red de cables ópticos Corporativos o de HFC Respecto a la capa de acceso los CSRs son equipos 7705SARM y el análisis de ancho de banda es el siguiente: Tabla 3.2 – Análisis de Ancho de Banda en red de Acceso De acuerdo a lo anterior, las consideraciones a nivel de diseño en función del ancho de banda son las siguientes: ‐ 5 x CSRs por anillos con un OB=4 a nivel de acceso, el tope máximo es 51,2% de ocupación por anillo ‐ Se deja BW disponible en la red para futuros servicios adicionales en caso que sea necesario ‐ 2 interfaces 1Gbps de cada CSR en el anillo a nivel de acceso ‐ No hay condiciones limites en cuanto a throughput debido a que el BW es de 1Gbps por cada anillo 95 3.1.2 Agregación En lo que respecta en la capa de agregación para la arquitectura Hub, los MRs son equipos 7750‐SR7 y el análisis de ancho de banda es el siguiente: Tabla 3.3 – Análisis de Ancho de Banda en red de Agregación De acuerdo a lo anterior, las consideraciones a nivel de diseño en función del ancho de banda son las siguientes: ‐ 31 anillos por MR considerando un OB=2 a nivel de agregación, el tope máximo es 79,4% de ocupación por enlace de uplink de 10Gbps ‐ Se deja BW disponible en la red para futuros servicios adicionales en caso que sea necesario ‐ Los MRs se conectarán hacia los HRs a través de enlaces de 10Gbps protegidos ‐ 2 interfaces 10Gbps de cada MRs, una hacia el uplink, es decir, hacia los HRs y otra entre ellos (MR‐A/MR‐B) ‐ No hay condiciones limites en cuanto a throughput debido a que el BW es de 10Gbps en la capa de agregación 96 3.1.3 Core El Core se encuentra definido como el sitio en el cual se encuentran los RNCs de la red 3G; desde el punto de vista del Core se tienen los siguientes escenarios: ‐ Clúster Simple (no anillado): que consiste en la mayoría de los casos donde está conformado por 1xRNC y una pareja de 7750SR7. La interfaces entre el RNC y el HR son: o 2xGBE en modalidad activa/stand‐by o 2xSTM‐1 en modalidad working/protection usando MC‐APS entre los HRs El diagrama corresponde a la siguiente figura: Figura 3.3 – Clúster Simple ‐ Clúster en Anillo de 1Gbps: que consiste en los casos que se especificará a continuación, se tendrá conexión entre la pareja de HRs el cual cada clúster está conformado por 1xRNC y una pareja de 7750SR7. La interfaces entre el RNC y el HR son: 97 o 2xGBE en modalidad activa/stand‐by o 2xSTM‐1 en modalidad working/protection usando MC‐APS entre los HRs o La conexión de 1Gbps entre los HRs en anillo será a través de la red DWDM y servirá para poder realizar redistribuciones, es decir, Nodos B que por temas de vecindad a nivel de RF deberán pertenecer al RNC remoto El diagrama corresponde a la siguiente figura: Figura 3.4 ‐ Clúster de Anillo en Nivel HR – 1 Gbps ‐ Clúster en Anillo de 10Gbps de 2 o más HRs: que consiste en los casos que se especificará a continuación, se tendrá conexión entre la pareja de HRs el cual cada clúster está conformado por 2xRNC y una pareja de 7750SR7. La interfaces entre el RNC y el HR son: o 2xGBE en modalidad activa/stand‐by por cada RNC 98 o 2xSTM‐1 en modalidad working/protection por cada RNC usando MC‐APS entre los HRs o La conexión de 10Gbps entre los HRs en anillo será a través de la red ROADM o FO y servirá para poder realizar redistribuciones, es decir, Nodos B que por temas de vecindad a nivel de RF deberán pertenecer al RNC remoto 3.2 Topología Lógica La red IPRAN en cuestión es una red compuesta por familias de equipos Alcatel‐Lucent 7750SR y 7705SAR, los últimos diseñados para redes móviles MBH; el modelamiento de los servicios está basado en el protocolo MPLS (Multi Protocol Label Switching) y específicamente el uso de RSVP‐FRR con el fin de minimizar al máximo los tiempos de afectación de los servicios, donde además se han aplicado varios tipos de protecciones en los diferentes niveles de la red, por ejemplo, a nivel de acceso se dispone de una topología en anillo que permite fallas a nivel de enlace de FO; en la capa de agregación se dispone de enlaces redundantes y alta disponibilidad entre los equipos MR/HR y en el Core, los equipos HRs están en modalidad 1+1 con el fin de tener alta disponibilidad permitiendo soportar fallas a nivel de hardware. El hecho de tener corriendo MPLS y RSVP, se deberá disponer de la conectividad IP entre los distintos nodos, para ello se usa el protocolo OSPF como protocolo IGP de la red IPRAN. Desde el punto de vista de arquitectura lógica, la red IPRAN basa sus diferentes servicios en MPLS, donde se necesita conectividad IP entre los nodos de la red, para lo cual se hace necesario un protocolo de ruteo interior (IGP) para poder desplegar los servicios, el usado en la red es OSPF. Finalmente con el fin de disminuir al máximo los tiempos de afectación (aprox. 50msg), se usa RSVP con FRR en la red. Adicionalmente, en la red IPRAN están conectados los Nodos B directamente al CSR. Los servicios son enviados a través de PSWs (e‐pipes) usando la configuración de redundancia (PSW Redundancy) en caso de falla a nivel del HR que esté conectado con el puerto activo hacia el RNC. Los PSW son recibidos en una VPLS de Capa 2 que a su vez están conectados a la VPRN y como se dispone de redundancia de HW en los HRs se 99 configura VRRP. Dentro de la VPRN van a estar las interfaces IP hacia los Nodos B y hacia el RNC. Para el caso del RNC también se usa VRRP y los puertos del RNC que trabajan en modalidad activo/stand‐by, son agregados primero en una VPLS diferente con el fin de cumplir con el funcionamiento del RNC. Los servicios 3G en modalidad ATM usan a‐pipes, son bastante simples, ya que son conexiones punto a punto, entre el Nodo B y el RNC, y lo que se aprovecha en los PSW es en configurar la redundancia (PSW Redundancy) y la conexión entre el HR y RNC se configura MC‐ APS. Finalmente, cabe destacar que los servicios para 3G (e‐pipes/a‐pipes) están protegidos en toda la red a través de FRR (Fast Re‐Route) usando el protocolo RSVP que permite pre‐ señalizar las conexiones ante falla de nodos y/o Fibra Óptica. 3.3 Modelo Lógico de Red 3.3.1 Topología Lógica de Servicios utilizados en la red Las topologías de servicios configurados para una red 3G, obedecen a la mostrada en la Figura 3.5 (ejemplo): Figura 3.5 – ePipes terminados sobre una VPLS (de cara al acceso) 100 El enfoque utilizado en la Figura 3.5 es terminar los distintos tráficos de los Nodos B en una VPLS (switch Virtual). En el caso de la topología de la red IPRAN los CSR proveen los Puntos de Acceso a los Servicios (SAPs). Los spoke‐sdp acarrean el tráfico a través de los routers P y terminan en la VPLS del HR. La VPLS está unida a una interfaz de la VPRN a través de una cross‐conexión física denominada hair‐pinning. El hair‐pinning conecta un SAP Ethernet de la VPLS hacia un puerto de la VPRN utilizando un jumper entre ambos puertos físicos. Para la localización de direcciones IP cada ePipe actúa como una extensión del puerto de la VPLS. Dado que la VPLS es un servicio en Capa 2, esta toma decisiones de reenvío basadas en las direcciones MAC. Por lo tanto, cada nodo B está direccionado sobre la misma subred, y la conexión de la interfaz de hair‐pinning de la VPRN se convierte en la interfaz de puerta de enlace (Gateway) del nodo B. Comenzaremos el análisis de la topología completa desde el nivel del acceso recorriendo los protocolos e interfaces hasta los equipos HR; revisaremos su configuración sobre equipos Alcatel‐Lucent y a través de su línea de comandos. 3.3.2 Análisis e implementación de la Topología Lógica y protocolos de red empleados en su configuración La topología a analizar corresponde a la de la Figura 3.6 (ejemplo típico de una red corporativa IP en anillo; topología Lógica de la figura 3.3) que se muestra a continuación: 101 Figura 3.6 ‐ Topología Lógica de un Clúster de Red Esta es una topología de red en anillos sobre los equipos de acceso o CSRs y los concentradores o MR como agregadores de anillos; los equipos CSR SARM y la configuración base de cada uno de ellos es la que se detalla a continuación. 3.3.2.1 Configuración Base Se deben configurar los puertos que miran hacia cada uno de los extremos como modo network para poder realizar etiquetado de tramas MPLS como sigue (se hará en un solo router (CSR 1) pues es la misma configuración en los otros puertos de network); en este caso puerto 1/1/1 que indica IOM 1 MDA 1 Puerto 1. 102 La escritura del comando “configure port 1/1/1” nos indica que a través de ese puerto estamos configurando físicamente la interfaz que va conectada al MR1, modo ethernet “network” y “no shutdown” para habilitar ese puerto: A:CSR1>config>port# info ‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐ description "TO_MR1" ethernet mode network exit no shutdown ‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐ Sobre ese puerto irá un enlace de fibra por lo cual necesitaremos un SFP inserto; se debe configurar de manera análoga el puerto 1/1/2 que mira hacia el MR2. Una vez habilitados ambos puertos de red crearemos las interfaces de red; utilizaremos las redes 172.27.74.48/30 y 172.27.74.52/30 y una ip de cada uno de los segmentos para ser asignada en cada interfaz; la configuración es la siguiente: A:CSR1>config>router# info #‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐ echo "IP Configuration" #‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐ interface "TO_MR1" address 172.27.74.50/30 port 1/1/1 bfd 100 receive 100 multiplier 3 exit interface "TO_MR2" address 172.27.74.53/30 103 port 1/1/2 bfd 100 receive 100 multiplier 3 exit interface "system" address 172.26.57.13/32 exit router‐id 172.26.57.5 #‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐ En este ejemplo se realizó la asignación de la IP 172.27.74.50 para el CSR1 del segmento de red 172.27.74.48/30 en el puerto 1/1/1, lo cual quiere decir que una vez definido este segmento de red, solo podemos utilizar dos IP del segmento, la asignada y la .49 que será utilizada en el equipo MR1 mirando hacia el CSR1; las otras IPs (la .48 y la .51) corresponden a la red y broadcast propiamente tal. De la misma manera se asignó la IP 172.27.74.53 en el puerto 1/1/2 mirando hacia el MR 2. Un parámetro muy importante es la configuración de bfd sobre las interfaces. Este protocolo no es un protocolo de enrutamiento sino que es un protocolo de red de detección de errores en un enlace (explicado en el capítulo 2; sección 2.5). En este caso está configurado en las interfaces creadas sobre los puertos 1/1/1 y 1/1/2 con los parámetros 100 100 y 3; 100 milisegundos para la transmisión de los mensajes bfd, 100 milisegundos para la recepción de mensajes bfd y el multiplicador 3; el multiplicador nos permite especificar el número de mensajes bfd consecutivos que deben perderse y que son enviados (en este caso o desde el CSR2 o del MR1) por otro router para declarar una interfaz no operativa. En palabras simples si no se reciben 3 mensajes bfd de manera consecutiva desde el MR1 se declara la interfaz “TO_MR1” down. Otro dato que es muy importante destacar es que este protocolo, al no ser un protocolo de enrutamiento, puede estar atado a protocolos de enrutamiento de capas superiores como OSPF, lo cual nos indica que si bfd declara una sesión contra otro router conectado, en este caso directamente a él, down, hace que el protocolo OSPF converja nuevamente (en este caso con la interfaz down) y actualice su tabla de enrutamiento. 104 Se realizará la configuración de la interfaz de sistema (o IP de sistema /32) que utilizará el protocolo OSPF como identificador de router dentro de nuestro clúster. Este es un valor muy necesario pues nos permite conocer al router dentro de nuestra red y más importante aún conocer su ubicación dentro de una topología lógica de routers (número de saltos) o dominio de routing. Si no se especifica un valor se utiliza la dirección MAC del chassis del router. La configuración vista anteriormente se denomina configuración base y es la que se utiliza para enlazar los routers CSR1 con MR 2, MR 2 con HR 2, HR1 con HR2, MR1 con MR2 y así sucesivamente; debe estar enlazado de igual manera el CSR1 con el MR1 y el y también el HR1 con el MR1 y el HR2 con el MR2 para tener conectividad completa a nivel de enlaces ópticos. Se puede realizar el chequeo entre interfaces mediante un ping a ambos routers conectados directamente al CSR1; por ejemplo contra el MR1: A:CSR1# ping 172.27.74.49 PING 172.27.74.49 56 data bytes 64 bytes from 172.27.74.49: icmp_seq=1 ttl=64 time=0.579ms. 64 bytes from 172.27.74.49: icmp_seq=2 ttl=64 time=0.597ms. 64 bytes from 172.27.74.49: icmp_seq=3 ttl=64 time=0.690ms. 64 bytes from 172.27.74.49: icmp_seq=4 ttl=64 time=0.827ms. 64 bytes from 172.27.74.49: icmp_seq=5 ttl=64 time=0.726ms. ‐‐‐‐ 172.27.74.49 PING Statistics ‐‐‐‐ 5 packets transmitted, 5 packets received, 0.00% packet loss round‐trip min = 0.579ms, avg = 0.683ms, max = 0.827ms, stddev = 0.093ms En este caso el router MR1 responde a los cinco paquetes ICMP enviados y no hay pérdida de paquetes. De la misma manera contra el MR 2: A:CSR1# ping 172.27.74.54 PING 172.27.74.54 56 data bytes 64 bytes from 172.27.74.54: icmp_seq=1 ttl=64 time=1.09ms. 105 64 bytes from 172.27.74.54: icmp_seq=2 ttl=64 time=0.714ms. 64 bytes from 172.27.74.54: icmp_seq=3 ttl=64 time=0.673ms. 64 bytes from 172.27.74.54: icmp_seq=4 ttl=64 time=0.714ms. 64 bytes from 172.27.74.54: icmp_seq=5 ttl=64 time=0.721ms. ‐‐‐‐ 172.27.74.54 PING Statistics ‐‐‐‐ 5 packets transmitted, 5 packets received, 0.00% packet loss round‐trip min = 0.673ms, avg = 0.782ms, max = 1.09ms, stddev = 0.155ms Aquí también se recibe respuesta desde el MR 2 y no hay pérdida de paquetes. Con esto se chequea que ambas interfaces se encuentran operativas y ambos enlaces físicos se encuentran en condiciones óptimas. Esto también puede ser demostrado con el comando “show router interface” el cual nos muestra la tabla de interfaces operativas: A:CSR1# show router interface =============================================================================== Interface Table (Router: Base) =============================================================================== Interface‐Name Adm Opr(v4/v6) Mode Port/SapId IP‐Address PfxState ‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐ TO_MR1 Up Up/Down Network 1/1/1 172.27.74.50/30 n/a TO_MR2 Up Up/Down Network 1/1/2 172.27.74.53/30 n/a system Up Up/Down Network system 172.26.57.13/32 n/a ‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐ Interfaces : 3 106 Aquí se ven declaradas las interfaces y su estado administrativo y operativo (Up); también se puede chequear que por defecto se está utilizando la versión del protocolo IP versión 4 (IPv4) (IPv6 se muestra Down pues no se está utilizando). Podemos chequear también el crecimiento de la tabla de rutas con el comando “show router route‐table protocol local”. A:CSR1# show router route‐table protocol local =============================================================================== Route Table (Router: Base) =============================================================================== Dest Prefix Type Proto Age Pref Next Hop[Interface Name] Metric ‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐ 172.26.57.13/32 Local Local 95d07h02m 0 system 0 172.27.74.48/30 Local Local 95d03h24m 0 TO_MR1 0 172.27.74.52/30 Local Local 24d22h51m 0 TO_MR2 0 ‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐ No. of Routes: 3 El comando nos indica que redes se encuentran activas, el prefijo de destino (la red) y el próximo salto para cada uno de los paquetes que necesiten ser reenviados. Una vez realizada la configuración base del equipo se procede a realizar la habilitación de los protocolos que nos permitirán conocer al router dentro de la topología lógica y los protocolos que nos permitirán realizar el manejo de los servicios; empezaremos por la configuración del protocolo OSPF; debemos saber qué es lo que deseamos publicar dentro de la tabla de enrutamiento; en este caso necesitamos rápida convergencia y la mínima afectación de servicios, además de conocer al router por su IP de sistema y sus interfaces, por lo tanto ambas 107 interfaces “TO_MR1” y “TO_MR2” deben ser agregadas al dominio del protocolo y la interfaz “system” como sigue: A:CSR1>config>router>ospf# info ‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐ router‐id 172.26.57.13 traffic‐engineering area 0.0.14.1 interface "system" exit interface "TO_MR1" interface‐type point‐to‐point bfd‐enable exit interface "TO_MR2" interface‐type point‐to‐point bfd‐enable exit exit ‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐ Es una buena práctica definir a los routers de nuestro clúster dentro de un área diferente como se mencionó en el Capítulo 2 Sección 2.7.2 al área 0.0.0.0; en este caso se definirán en el área 0.0.14.1, recordando que será el aréa de la Región de los Ríos (XIV) donde podrían ser emplazados los routers de nuestro diseño. En la configuración base del protocolo OSPF se debe habilitar el “router‐id” que es la IP por la cual conoceremos remotamente a nuestro router (para administrarlo y realizar los chequeos a través de un sistema de gestión de routers remoto SAM5620); en este caso la IP 172.26.57.13. También se debe definir la extensión de ingeniería de tráfico (explicada en el Capítulo 2) para la dirección del tráfico basado en las condiciones mencionadas en ese apartado. 108 Las interfaces son agregadas bajo el área 0.0.14.1 por lo cual nuestro router bajo el cluster de Valdivia (área 0.0.14.1) publicarán esa información bajo esa área, por lo tanto los routers pertenecientes a otras áreas estarán imposibilitados de conocer a los routers de esta área; los beneficios de realizar esta configuración es de reducir el tamaño de la base de datos topológica (muy necesario en grandes redes corporativas, con gran cantidad de routers >> 1000 routers); en este caso podríamos haber agregado el router en la misma área 0.0.0.0 al ser una red pequeña, pero al crecer nuestra red será necesario disminuir el tamaño de nuestra base de datos; por ejemplo si empezamos a crecer hacia Temuco o Puerto Montt sería necesario agregar los otros routers (CSR) al área 0.0.9.1 y 0.0.10.1 (un caso hipotético). Las interfaces que miran hacia el MR1 y el CSR2 son definidas como punto a punto (interface‐type point‐to‐point), ya que están conectadas única y exclusivamente a otra interfaz (contra el MR1 o contra el CSR2), en caso contrario debe ser definida como interfaz de broadcast (interface‐type broadcast) por ejemplo si esta estuviese conectada a un switch y tuviera que alcanzar otros routers por medio de ese switch; además se habilitan la asociación con el protocolo bfd, lo que significa que este protocolo puede “avisar” a OSPF la operación inadecuada de un enlace y dar de baja la interfaz que no está operando correctamente; si ocurre esto la tabla de enrutamiento OSPF eliminará esta interfaz y se eliminarán las trazas hacia esa interfaz hasta que se restaure la comunicación por el enlace con fallas y se actualizará la tabla de enrutamiento. Con la configuración de nuestro CSR1 hasta aquí podemos tener nuestro router visible desde un sistema de gestión y alcanzable para poder realizar trabajos sobre él, pero esto no significa que ya pueda manipular información; para esto se deben habilitar los protocolos MPLS, LDP y RSVP que son los cuales nos permiten realizar el etiquetado del tráfico en Capa 2,5 (o MPLS), manejar las extensiones de Ingeniería de Tráfico y realizar la distribución de etiquetas a través de una red MPLS; primero se debe activar el etiquetado MPLS y agregar las tres interfaces a MPLS como sigue (similar a OSPF): A:CSR1>config>router>mpls# info ‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐ 109 interface "system" exit interface "TO_MR1" exit interface "TO_MR2" exit no shutdown ‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐ No está demás mencionar que hasta el momento en la configuración básica solo estamos realizando las habilitaciones de las funciones necesarias para el funcionamiento correcto de los servicios; aún no hemos creado servicios ni túneles de transporte. Para chequear el correcto funcionamiento del protocolo podemos escribir el comando “show router mpls status” como sigue: A:CSR1# show router mpls status =============================================================================== MPLS Status =============================================================================== Admin Status : Up Oper Status : Up Oper Down Reason : n/a FR Object : Enabled Resignal Timer : Disabled Hold Timer : 1 seconds Next Resignal : N/A Dynamic Bypass : Enabled User Srlg Database : Disabled Least Fill Min Thd.: 5 percent LeastFill ReoptiThd: 10 percent Sec FastRetryTimer : Disabled Static LSP FR Timer: 30 seconds LSP Counts Originate Transit Terminate ‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐ Static LSPs 0 0 0 110 Dynamic LSPs 0 0 0 Detour LSPs 0 0 0 =============================================================================== En esta pantalla se puede apreciar que el protocolo está administrativamente y operacionalmente activos (Up) y que aún no tenemos túneles configurados para el transporte de tráfico (No hay LSPs Dinámicos configurados). Se debe realizar la activación del protocolo LDP y RSVP como sigue: Para LDP: A:CSR1 # configure router ldp no shutdown Para RSVP: A:CSR1>config>router>rsvp# info ‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐ interface "system" exit interface "TO_MR1" bfd‐enable exit interface "TO_MR2" bfd‐enable exit no shutdown ‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐ En este punto es importante aclarar que se debe asociar bfd al protocolo RSVP; esto es muy importante porque en caso de una falla RSVP permite hacer converger el tráfico de manera mucho más rápida (en el orden de los milisegundos como se verá más adelante) en las rutas alternativas de direccionamiento del tráfico con pérdidas muy bajas de paquetes, pues como su 111 nombre lo dice, se reservan recursos de red disponibles adicionales para re direccionar el tráfico. Si revisamos el protocolo bfd nos indica su asociación a los protocolos de capas superiores antes mencionados (OSPF y RSVP) con el siguiente comando: A:CSR1# show router bfd session =============================================================================== BFD Session =============================================================================== Interface State Tx Intvl Rx Intvl Multipl Remote Address Protocol Tx Pkts Rx Pkts Type ‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐ TO_MR1 Up (3) 100 100 3 172.27.74.49 ospf2 rsvp 82544795 82548182 iom TO_CSR2 Up (3) 100 100 3 172.27.74.54 ospf2 rsvp 21901486 21901477 iom ‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐ No. of BFD sessions: 2 =============================================================================== Aquí finaliza la configuración base y activación de protocolos; en esta instancia el router se encuentra disponible para poder manejar servicios; todos los demás routers, MR1, MR2, HR1 y HR2 deben tener la misma configuración; los HR (1 y 2) deben tener su interfaz de sistema en área 0.0.0.0 (o backbone) y las interfaces que miran hacia los MR en el área del cluster (0.0.14.1) 112 3.3.2.2 Implementación Lógica y Configuración de Servicios De acuerdo a lo visto en la Figura 3.6 a comienzos del Capítulo, configuraremos un servicio e‐pipe de ejemplo desde nuestro CSR1 con un respectivo SAP en el puerto donde tendremos conectado nuestro nodo B (en este caso el puerto 1/1/5, puerto fast‐ethernet) y lo terminaremos en la vpls (switch virtual) de ambos HR1 y HR2; cabe destacar que sobre este puerto podemos conectar lo que nosotros tengamos disponible (un PC, etc.) y que emplee el protocolo IP. Para la configuración e implementación de este servicio necesitamos primero crear dos caminos de conmutación de etiquetas; estas dos rutas nos servirán para crear nuestros caminos virtuales hacia los Nodos HR1 y HR2. Denominaremos a estos caminos TO_HR1 y TO_HR2; la configuración es la siguiente: A:CSR1>config>router>mpls# info ‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐ interface "system" exit interface "TO_MR1" exit interface "TO_CSR2" exit path "IGP" no shutdown exit lsp "TO_HR1" to 172.26.57.1 cspf fast‐reroute one‐to‐one exit primary "IGP" exit 113 no shutdown exit lsp "TO_HR2" to 172.26.57.2 cspf fast‐reroute one‐to‐one exit primary "IGP" exit no shutdown exit no shutdown ‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐ Como se puede observar, se crean ambos caminos apuntando hacia ambos HR; tiene la facilidad de cspf y fast‐reroute que nos permiten re‐encaminar el tráfico hacia cada uno de los nodos HR y disminuir los tiempos de conmutación ante una falla como se verá más adelante; se configuran estas rutas dentro de la opción del router mpls (configure router mpls). También se debe configurar explícitamente un camino (path) para que los lsp sigan o una ruta predefinida (configurada manualmente) o una ruta dinámica. En este caso se configura una ruta por defecto denominada IGP; si no se define un camino explícito la ruta automáticamente toma el protocolo IGP configurado en el router (en este caso OSPF) y define los saltos de acuerdo a la topología lógica en la base de datos de este protocolo. Primero chequeamos el estado de ambos LSP: A:CSR1# show router mpls lsp =============================================================================== MPLS LSPs (Originating) =============================================================================== LSP Name To Fastfail Adm Opr 114 Config ‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐ TO_HR1 172.26.57.1 Yes Up Up TO_HR2 172.26.57.2 Yes Up Up ‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐ LSPs : 2 =============================================================================== Luego chequeamos las trazas seguidas por ambos LSP (el comando es similar a un traceroute normal por IGP; en este caso es una herramienta para localizar dirección de tráfico MPLS). Estos LSP son unidireccionales por lo tanto solo necesitan que el punto final o endpoint esté activo para poder crear el túnel, si no se encuentra activo el HR1 o el HR2 no levantaran operacionalmente o el LSP TO_HR1 o el LSP TO_HR2. EL chequeo de ambas trazas nos arroja el siguiente resultado: A:CSR1# oam lsp‐trace TO_HR1 lsp‐trace to TO_HR1: 0 hops min, 0 hops max, 116 byte packets 1 172.26.57.3 rtt=0.924ms rc=8(DSRtrMatchLabel) 2 172.26.57.1 rtt=1.05ms rc=8(DSRtrMatchLabel) A:CSR1# oam lsp‐trace TO_HR2 lsp‐trace to TO_HR2: 0 hops min, 0 hops max, 116 byte packets 1 172.26.57.4 rtt=1.11ms rc=8(DSRtrMatchLabel) 2 172.26.57.2 rtt=1.04ms rc=8(DSRtrMatchLabel) Las trazas nos indican que se están siguiendo los siguientes caminos (recordar que automáticamente definen los caminos por el protocolo IGP configurado) Para el LSP TO_HR1: CSR1 ‐> MR1 ‐> HR1 Para el LSP TO_HR2: CSR1 ‐> MR2 ‐> HR2 115 Este será el camino que seguirá la información hacia los HR (o aguas arriba). Se debe destacar que la implementación de dos caminos hacia los HR es para tener la pre‐configuración de dos rutas lógicas (una primaria y otra de respaldo) para alcanzar el servicio vprn en Capa 3. En ambos HR también deben ser configurados LSPs a su vez para alcanzar el destino final, que en este caso sería el CSR1; se debe configurar uno en cada HR de la manera siguiente: A:HR_1>config>router>mpls# info ‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐ interface "system" exit interface "TO_MR_A" exit interface "TO_HR_B" exit interface "TO_MR" exit path "IGP" no shutdown exit lsp "TO_HR_B" to 172.26.57.2 cspf fast‐reroute one‐to‐one exit primary "IGP" exit no shutdown exit lsp "TO_CSR_1" to 172.26.57.13 cspf 116 fast‐reroute one‐to‐one exit primary "IGP" exit no shutdown exit no shutdown ‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐ Se debe observar que en este HR va configurado un también un lsp hacia el HR B, que es el que nos permitirá más adelante realizar la configuración e interconexión lógica de la vpls y vprn en ambos HR. La traza nos indica que la información desde el HR A hacia el CSR (aguas abajo) recorre el camino MR A ‐> CSR1 y desde el HR B hacia el CSR MR B ‐> CSR1; con esto ya se encuentran predefinidos los caminos para el servicio e‐pipe a configurar. A:HR_A# oam lsp‐trace TO_CSR_1 lsp‐trace to TO_CSR_1: 0 hops min, 0 hops max, 116 byte packets 1 172.26.57.3 rtt=16.2ms rc=8(DSRtrMatchLabel) 2 172.26.57.13 rtt=10.8ms rc=8(DSRtrMatchLabel) A:HR_B# oam lsp‐trace TO_CSR_1 lsp‐trace to TO_CSR_1: 0 hops min, 0 hops max, 116 byte packets 1 172.26.57.4 rtt=16.2ms rc=8(DSRtrMatchLabel) 2 172.26.57.13 rtt=10.8ms rc=8(DSRtrMatchLabel) Una vez finalizada la configuración de túneles en nuestro CSR1 se procede a realizar la configuración de los servicios en Capa 2 y Capa 3 en los HR. Primero se realiza la configuración de servicios Capa 2 denominados VPLS que será la encargada de servir de punto final de terminación de los servicios de acceso contra la última milla o los Nodos B y de acceso desde el Core de la Red contra nuestro RNC. 117 La configuración de este servicio es bastante simple y debe ser replicada en ambos HR; el propósito de crear una VPLS en los equipos HR es la de utilizar una capacidad avanzada de ésta y es la de poder extenderse a través de distintos equipos sobre una red MPLS; esto significa que al ser un servicio en Capa 2 aprende las direcciones MAC y los puertos desde los cuales ingresan esas direcciones MAC y los almacena en su tabla FDB (Forwarding DataBase – Base de Datos de Reenvío). La extensión de este servicio se realiza a través de un mesh‐sdp (podría ser un spoke‐ sdp) y es el cual replica a través de un mesh todo lo que aprende por sus distintos puntos de acceso (SAP o spoke‐sdp) menos lo que aprende por el mismo mesh u otros mesh configurados dentro de la VPLS. Con esto se logra evitar los loops a nivel de Capa 2 evitando el reenvío de las MAC aprendidas por esta misma entidad lógica. En el caso de nuestra red IP en los equipos HR deben configurarse dos VPLS en cada equipo (un total de 4 VPLS); la primera VPLS que queda en la Capa de Core realizará el aprendizaje de MAC del RNC y lo replicará a través de un mesh‐sdp a la VPLS en el otro HR; la VPLS aprenderá esa MAC por el puerto 1/1/3 y lo replicará a través de la cross‐conexión o hair‐ pinning definida como LAG‐1. Se utiliza un LAG (Link Aggregation Group – Grupo de Agregación de Enlaces) para realizar la redundancia a nivel de hardware (se pueden definir dos puertos en distintas tarjetas), en el caso de que falle un puerto queda activo el otro puerto definido en la conexión LAG. La configuración de un LAG (LAG‐1) es la siguiente: A:HR_A>config>lag# info ‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐ description "LAG_1_VPLS_ACCEDE_A_LA_VPRN" mode access encap‐type dot1q port 1/1/1 port 2/1/1 no shutdown ‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐ 118 La configuración para el LAG‐2 es la siguiente: A:HR_A>config>lag# info ‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐ description "LAG_2_VPRN_ACCEDE_A_LA_VPLS" mode access encap‐type dot1q port 1/1/2 port 2/1/2 no shutdown ‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐ Esta configuración nos indica que el LAG‐1 tiene encapsulación dot1q (o tag simple de VLAN) con la cual identificaremos la conexión contra el RNC; la protección está dada por los puertos 1/1/1 y 2/1/1 y nos indica que si falla la conexión en el puerto 1/1/1 queda activa la conexión en el puerto 1/1/2. El LAG‐1 lo identificaremos como la conexión por la cual la VPLS de cierta manera “entrega” los datos en Capa 2 hacia la VPRN. De la misma manera se configura el LAG‐2 con los puertos 1/1/2 y 2/1/2; en este caso la VPRN “accede” a la información entregada en Capa 2 y la mantiene en su tabla ARP (Address Resolution Protocol). Volviendo a la configuración de la VPLS de Acceso contra el RNC (Capa de Core), esta VPLS tiene dos puntos principales de acción con los cuales realizará la interconexión física de los servicios; posee un SAP hacia el puerto 1/1/3 y otro SAP hacia el LAG‐1 como sigue: A:HR_A>config>service>vpls# info ‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐ description "CONEXION_ETH_L2_CONTRA_RNC" stp shutdown exit sap 1/1/3:100 create ingress qos 100 119 exit egress qos 100 exit exit sap lag‐1:100 create ingress qos 100 exit egress qos 100 exit exit mesh‐sdp 200:200 create exit no shutdown ‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐ Esta VPLS nos indica que conocerá la VLAN 100 (VLAN de nuestro RNC) por los puertos 1/1/3 y LAG‐1 (Puertos 1/1/1 y 2/1/1) y a su vez realizará la extensión de este servicio VPLS a través del mesh‐sdp 200:200 (200:200 indica el circuito virtual a seguir para llegar al otro HR se explicará la configuración de SDP más adelante.) La misma configuración debe ser replicada en el otro HR. Por otro lado en la capa de agregación se necesita otra VPLS que concentrará las MAC de los Nodos B que vayamos agregando a nuestra red de servicios; esta VPLS solo posee un SAP hacia el LAG‐1 (pues solo necesita replicar y transmitir la información en Capa 2 de los Nodos B hacia esos puertos); su configuración es la siguiente: A:HR_A>config>service>vpls# info ‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐ description "SEG_VLAN_500" 120 split‐horizon‐group "SHG_TEST" create exit stp shutdown exit sap lag‐1:500 create ingress qos 100 exit egress qos 100 exit exit mesh‐sdp 200:300 create exit no shutdown ‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐ De acuerdo a lo visto en esta VPLS se observa que también posee un SAP al LAG‐1 y un mesh‐sdp 200:300 que realiza la comunicación con la otra VPLS de agregación de Nodos en el otro equipo HR (para que ambas VPLS puedan disponer de la misma información en Capa 2 de las estaciones Base). Se define también la vlan 500 de acceso para la estación base que utilizaremos. Una vez que tenemos definida la Capa 2 procedemos a configurar los elementos de Capa 3. Esta es una VPRN de gestión de Nodos y realizará la gestión de información de los Nodos B y el RNC; esta vprn (o router virtual) realiza la comunicación entre las interfaces configuradas sobre ella y replica la información en Capa 3 de acuerdo a su tabla de enrutamiento. No se debe confundir con la tabla de enrutamiento del router base; esta es una vprn de gestión de servicios y realiza su gestión sobre los gateways asignados en el Plano de Datos y no sobre el Plano de 121 Control (OSPF, MPLS, RSVP y LDP corresponden al plano de control). Su configuración es la siguiente: A:HR_A>config>service>vprn# info ‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐ description "VPRN_ACCEDE_AL_LAG_2" route‐distinguisher 65200:30145001 vrf‐target target:65200:30145001 interface "TO_RNC" create address 172.17.176.5/29 mac 00:00:00:30:14:00 vrrp 1 backup 172.17.176.1 priority 250 ping‐reply traceroute‐reply init‐delay 300 exit sap lag‐2:100 create ingress qos 100 exit egress qos 100 exit exit exit interface "TO_NODO_B" create description "NODO_B_VLAN_500" address 172.17.176.125/26 mac 00:00:00:30:14:02 122 vrrp 2 backup 172.17.176.65 priority 250 ping‐reply traceroute‐reply init‐delay 300 exit sap lag‐2:500 create ingress qos 100 exit egress qos 100 exit exit spoke‐sdp 200 create exit no shutdown ‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐ En esta VPRN tendremos dos interfaces configuradas, TO_RNC y TO_NODO_B; la interfaz contra el RNC y la interfaz que mirará de cara a la agregación; estos corresponden a dos gateways virtuales que se encuentran configurados con VRRP definido en la RFC3768 y se utiliza para aumentar la disponibilidad de la puerta de enlace realizando la agregación de equipos (extensión del servicio al igual que en la VPLS) pero en Capa 3. Esto quiere decir que si el equipo HR A por alguna falla deja de Funcionar la puerta de enlace contra los Nodos B y el RNC se encuentra extendida en el HR B y por lo tanto no se pierde la conectividad entre los Nodos y el RNC. La vprn también debe tener comunicación con su homóloga en el HR B a través de un spoke‐sdp (no se necesita el mesh‐sdp pues el protocolo IP automáticamente detecta la duplicación de IP) 123 La configuración de las interfaces con vrrp se asume en este ejemplo como vrrp1 contra el RNC y vrrp2 contra los Nodos B para mayor facilidad de identificación. Las puertas de enlace que miran hacia el RNC y hacia los Nodos B respectivamente son: 172.17.176.1 y 172.17.176.65 (son los gateways o pasarelas para realizar la comunicación de las estaciones Base contra el RNC) Para realizar la comprobación de vrrp no s aseguramos de que cada HR tenga en cada uno de los vrrp prioridades diferentes; en este caso configuramos el HR A como Master (priority 250) y el HR B como Backup (priority 240): A:HR_A# show router 400 vrrp instance =============================================================================== VRRP Instances =============================================================================== Interface Name VR Id Own Adm State Base Pri Msg Int IP Opr Pol Id InUse Pri Inh Int ‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐ TO_RNC 1 No Up Master 250 1 IPv4 Up n/a 250 No Backup Addr: 172.17.176.1 TO_NODO_B 2 No Up Master 250 1 IPv4 Up n/a 250 No Backup Addr: 172.17.176.65 ‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐ Instances : 2 =============================================================================== Una vez que tenemos conectado el RNC podemos revisar si se está aprendiendo la dirección MAC a través del servicio VPRN como sigue: A:HR_A# show router 400 arp 124 =============================================================================== ARP Table (Service: 400) =============================================================================== IP Address MAC Address Expiry Type Interface ‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐ 172.17.176.1 00:00:5e:00:01:01 00h00m00s Oth[I] TO_RNC 172.17.176.2 00:40:43:67:48:8f 03h47m26s Dyn[I] TO_RNC 172.17.176.5 00:00:00:30:14:00 00h00m00s Oth[I] TO_RNC 172.17.176.65 00:00:5e:00:01:02 00h00m00s Oth[I] TO_NODO_B 172.17.176.125 00:00:00:30:14:02 00h00m00s Oth[I] TO_NODO_B ‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐ No. of ARP Entries: 11 =============================================================================== Aquí aparece la MAC del RNC marcada en negrita y nos indica que ya tenemos conectividad contra el acceso en la Capa de COR; aún no tenemos configurado el Nodo B en la última milla por lo tanto no vemos MAC desde la estación Base. Volviendo a la última milla necesitamos dar de alta el servicio que aprovisionaremos para la estación Base y que comenzará a tener conectividad contra el RNC. En el CSR1 realizamos la configuración de dos sdp; el sdp1 será el 555 y el sdp2 será numerado con el 666; ambos sdp realizan la conexión lógica del servicio e‐pipe desde el CSR1 hacia ambos HR A y B respectivamente. Estos sdp nos permiten recorrer los túneles de conmutación de etiquetas anteriormente definidos, pero acotando su accionar sólo al servicio que corresponde. Estos servicios son configurados de la manera siguiente (nos dará una idea intuitiva de que recorre el camino MPLS LSP que creamos anteriormente): A:CSR1>config>service# info ‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐ customer 1 create 125 description "Default customer" exit sdp 555 create far‐end 172.26.57.1 lsp "TO_HR1" keep‐alive shutdown exit no shutdown exit sdp 666 create far‐end 172.26.57.2 lsp "TO_HR2" keep‐alive shutdown exit no shutdown exit ‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐ El sdp 555 recorre el camino indicado por el LSP TO_HR1 y el sdp 666 recorre el camino indicado por el LSP TO_HR2; las trazas mencionadas son: Para el LSP TO_HR1 (sdp 555): CSR1 ‐> MR1 ‐> HR1 Para el LSP TO_HR2 (sdp 666): CSR1 ‐> MR2 ‐> HR2 Con esto tenemos definidos el punto inicial y final del transporte a través de la red MPLS; solo nos queda configurar el servicio e‐pipe (o pseudowire) en el CSR y definir su llegada a las VPLS de acceso a los Nodos B para tener la conectividad deseada. La configuración del servicio e‐pipe es la siguiente: epipe 9999 customer 1 create 126 description "E‐PIPE_NODO_B_DE_PRUEBA" endpoint "master" create revert‐time 120 standby‐signaling‐master exit sap 1/1/5:500 create ingress qos 100 exit egress qos 100 exit exit spoke‐sdp 555:9999 endpoint "master" create precedence primary exit spoke‐sdp 666:9999 endpoint "master" create precedence 1 exit no shutdown exit La configuración de este servicio nos muestra que a través de la puerta 1/1/5 tenemos conectado un Nodo que va con encapsulación dot1q y está configurado con la vlan 500; este nodo tiene como camino principal el indicado por el sdp 555 y como camino secundario el indicado por el sdp 666. Los circuitos virtuales son el 555:9999 y el 666:9999. Estos circuitos virtuales como lo indicaba la Figura 3.5 deben ser terminados en la vpls de acceso para lograr la comunicación a través de los routers P y PE y así terminar la comunicación contra el RNC. Volviendo a la Capa de Core se configuran las vpls de acceso con los spoke‐sdp correspondientes en cada una; el spoke‐sdp 555:9999 en el HR A y el spoke‐sdp 666:9999 en el HR B como sigue: 127 A:HR_A>config>service>vpls# info ‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐ description "SEG_VLAN_500" split‐horizon‐group "SHG_NODO_TEST" create exit stp shutdown exit sap lag‐1:500 create ingress qos 100 exit egress qos 100 exit exit mesh‐sdp 200:300 create exit spoke‐sdp 555:9999 split‐horizon‐group "SHG_NODO_TEST" create exit no shutdown ‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐ En esta vpls del HR A se agrega el spoke‐sdp 555:9999 y se cierra el circuito MPLS desde el acceso en el CSR en la última milla; de manera análoga se agrega el spoke‐sdp 666:9999 en la vpls del HR B para terminar el circuito MPLS de respaldo. Si chequeamos ahora la conectividad contra el Nodo B deberíamos tener respuesta a un ping desde el HR A y nos indica que la configuración se encuentra correcta y tanto el RNC como el Nodo B se encuentran operativos y enviando tráfico a través de nuestra red MPLS. 128 A:HR_A# ping router 400 172.17.176.66 PING 172.17.176.66 56 data bytes 64 bytes from 172.17.176.66: icmp_seq=1 ttl=255 time=29.6ms. 64 bytes from 172.17.176.66: icmp_seq=2 ttl=255 time=5.14ms. 64 bytes from 172.17.176.66: icmp_seq=3 ttl=255 time=5.09ms. 64 bytes from 172.17.176.66: icmp_seq=4 ttl=255 time=4.40ms. 64 bytes from 172.17.176.66: icmp_seq=5 ttl=255 time=4.36ms. ‐‐‐‐ 172.17.176.66 PING Statistics ‐‐‐‐ 5 packets transmitted, 5 packets received, 0.00% packet loss round‐trip min = 4.36ms, avg = 9.71ms, max = 29.6ms, stddev = 9.93ms Observando la tabla ARP de la vprn se puede verificar que tenemos a la Estación Base (Nodo B) siendo reconocida por la interfaz TO_NODO_B de la vprn: A:HR_A# show router 400 arp =============================================================================== ARP Table (Service: 400) =============================================================================== IP Address MAC Address Expiry Type Interface ‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐ 172.17.176.1 00:00:5e:00:01:01 00h00m00s Oth[I] TO_RNC 172.17.176.2 00:40:43:67:48:8f 03h52m07s Dyn[I] TO_RNC 172.17.176.5 00:00:00:30:14:00 00h00m00s Oth[I] TO_RNC 172.17.176.65 00:00:5e:00:01:02 00h00m00s Oth[I] TO_NODO_B 172.17.176.66 00:40:43:a0:02:89 03h59m54s Dyn[I] TO_NODO_B 172.17.176.125 00:00:00:30:14:02 00h00m00s Oth[I] TO_NODO_B ‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐ No. of ARP Entries: 6 =============================================================================== 129 Con esta secuencia de acciones se tiene configurada una red MPLS protegida en capa 3 mediante VRRP y extendida en capa 2 con VPLS mesh contra la capa de agregación y de cara al RNC además de un servicio e‐pipe o pseudowire capaz de conmutar rápidamente en caso de falla de un equipo de borde (HR 1 o HR 2). 3.3.2.3 Prueba de Conmutación y Packet‐Loss Para comprobar la rápida conmutación entregada por fast‐reroute realizaremos un corte de fibra ficticio en una de las interfaces del base‐router. La prueba consistirá en realizar un ping extendido de categoría “rapid” para comprobar la afectación de tráfico en porcentajes. La ráfaga de ping será de diez mil paquetes y por lo tanto un paquete perdido corresponderá a un 0,01% de packet‐loss; 10 paquetes perdidos corresponderán a 0,1% de packet‐loss y así sucesivamente. El procedimiento consistirá en chequear la traza primaria seguida por el servicio, en segundo lugar iniciar una ráfaga de ping desde el HR A y tercero realizar el corte de fibra mientras se está ejecutando la ráfaga. La primera verificación nos indica que dentro de la topología el tráfico toma la dirección: Para el LSP TO_HR1 (sdp 555): CSR1 ‐> MR1 ‐> HR1 EL chequeo de la traza primaria nos arroja el siguiente resultado: A:CSR1# oam lsp‐trace TO_HR1 lsp‐trace to TO_HR1: 0 hops min, 0 hops max, 116 byte packets 1 172.26.57.3 rtt=0.924ms rc=8(DSRtrMatchLabel) 2 172.26.57.1 rtt=1.05ms rc=8(DSRtrMatchLabel) 130 Lo cual nos indica que debemos realizar el corte de fibra por el lado del MR1. Una vez establecido esta condición ejecutamos el comando “ping router 400 172.17.176.66 rapid” desde el HR A lo cual nos arroja la siguiente salida (este primer comando es de demostración): A:HR_A# ping router 400 172.17.176.66 count 10000 rapid PING 172.17.176.66 56 data bytes !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!! . . . salidas adicionales son omitidas ‐‐‐‐ 172.17.176.66 PING Statistics ‐‐‐‐ 10000 packets transmitted, 10000 packets received, 0.00% packet loss round‐trip min = 0.431ms, avg = 5.59ms, max = 12.2ms, stddev = 4.51ms El cual nos indica que de los diez mil paquetes enviados, diez mil paquetes fueron recibidos correctamente y por lo tanto no hubo pérdidas (porque no se ha realizado ningún corte). En el caso de nuestro Nodo B conectado en el puerto 1/1/5 se realiza el monitoreo del puerto para ver la tasa de tráfico que está generando a través de la red con el comando “monitor port 1/1/5 interval 5 rate” como sigue: A:CSR1# monitor port 1/1/5 interval 5 rate =============================================================================== Monitor statistics for Port 1/1/5 =============================================================================== Input Output 131 ‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐ ‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐ At time t = 0 sec (Base Statistics) ‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐ Octets 737165640289 1912293098019 Packets 6916394541 7731985073 Errors 0 0 ‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐ At time t = 5 sec (Mode: Rate) ‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐ Octets 88604 264677 Packets 767 660 Errors 0 0 Utilization (% of port capacity) 0.83 2.22 ‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐ At time t = 10 sec (Mode: Rate) ‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐ Octets 73521 273353 Packets 642 646 Errors 0 0 Utilization (% of port capacity) 0.69 2.29 Lo cual nos da una idea del porcentaje de utilización de este puerto (cercano al 2,4%). Una vez que procedemos a realizar la prueba debemos quitar la fibra que mira hacia el MR1 y la salida de nuestras interfaces nos da el siguiente resultado (en el CSR1): A:CSR1# show router interface =============================================================================== 132 Interface Table (Router: Base) =============================================================================== Interface‐Name Adm Opr(v4/v6) Mode Port/SapId IP‐Address PfxState ‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐ TO_MR1 Down Up/Down Network 1/1/1 172.27.74.50/30 n/a TO_MR2 Up Up/Down Network 1/1/2 172.27.74.53/30 n/a system Up Up/Down Network system 172.26.57.13/32 n/a ‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐ Interfaces : 3 La interfaz contra el MR1 se encuentra en estado Down y las ráfagas de ping desde el HR A nos muestran los siguientes resultados (se ven puntos para los paquetes no recibidos y no confirmados en el puerto 1/1/5, se encuentran marcados en plomo): A:HR_A# ping router 400 172.17.176.66 count 10000 rapid PING 172.17.176.66 56 data bytes !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!.!!.!!!.!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!! . . . salidas adicionales son omitidas ‐‐‐‐ 172.17.176.66 PING Statistics ‐‐‐‐ 133 10000 packets transmitted, 9997 packets received, 0.03% packet loss round‐trip min = 0.431ms, avg = 5.59ms, max = 12.2ms, stddev = 4.51ms Esta prueba nos da una idea de la velocidad de conmutación del diseño topológico IP y el significado implícito; cualquier corte de fibra hacia cualquiera de los extremos de la red anillo nos proporciona la mínima afectación de servicios en una red corporativa ya sea de voz o datos y proporciona la fiabilidad suficiente para poder montar sobre ella cualquier tipo de servicios de alto rendimiento (video‐conferencias, juegos on‐line etc.). La prueba se realizó sobre el anillo que conforma el MR1, el CSR1 y el MR2 por ser más demostrativa, pero incluso cortando dos enlaces que no dejen aislados a un router proporcionan resultados muy similares; en este caso se tenía una tasa de ocupación del puerto de acceso cercana a un 2,4%, por lo tanto se obtiene un 0,03% * 2,4% = 0,072% de perdida de paquetes dentro del flujo normal operativo del nodo B. 3.4 Gestor SAM5620 y administración remota de equipamiento Dentro de los objetivos primordiales de cualquier proyecto de implementación de nuevas tecnologías, se encuentra la monitorización de las alarmas entregadas por el equipamiento instalado y la visualización de los enlaces y la creación de la topología dentro de un gestor gráfico. Para realizar este tipo de monitorización existen herramientas de software libre que pueden ser utilizadas para la visualización de la ocupación de anchos de banda en los enlaces como la herramienta Cacti (www.cacti.net), utilizada para monitorizar el nivel de ocupación de enlaces en redes, entre otras y herramientas propietarias que entregan los mismos proveedores de equipamiento (por el precio de licencias). Este es el caso del Gestor SAM5620 (Service Aware Manager), encargado de monitorizar las alarmas, servicios y estado de los enlaces entre los equipos agregados a su gestión; sin un sistema de gestión gráfico estaríamos imposibilitados de manejar el equipamiento de manera fácil. La pantalla de acceso al gestor gráfico es la siguiente: 134 Figura 3.7 – Pantalla de Acceso a gestor gráfico SAM5620 En este apartado realizaremos la evaluación del clúster de Valdivia de la red de producción real de la empresa de telecomunicaciones a la cual hemos obtenido acceso mediante este gestor. La pantalla principal nos muestra los elementos principales para la gestión de los equipos: 135 Figura 3.8 – Pantalla Principal del gestor SAM5620 En la Figura 3.8 se muestran los elementos principales del gestor que son la administración de la Red (1), la Visualización de la topología Física (2) y Ventana de Alarmas (3). Dentro de las capacidades avanzadas de este gestor se encuentra la visualización gráfica de la topología de los servicios implementados sobre la red para obtener un fácil acceso al equipamiento y realizar troubleshooting para verificar la correcta operación de los servicios de transporte de información. 3.4.1 Evaluación de desempeño de la red en Clúster Valdivia Para la evaluación del desempeño de la red utilizaremos el gestor SAM5620 y nos enmarcaremos en el clúster de Valdivia definido en la ventana de Topología Física mostrada en la Figura 3.8. El clúster de Valdivia está conformado por 17 routers actualmente instalados en las ubicaciones de las siguientes figuras: 136 Figura 3.9 – Routers Distribuidos sobre Valdivia (1) Figura 3.10 – Routers Distribuidos sobre Valdivia (2) En ambas figuras anteriores se pueden apreciar las localidades en las cuales han sido emplazados los router para lograr la conectividad a nivel de fibra óptica a través de nuestra ciudad (Calle‐Calle, Huachocopihue, Hospital Valdivia, etc), definidos sobre un plan estratégico privado de la empresa de telecomunicaciones. Se debe recordar que por cada router instalado 137 (en la capa de acceso) existe al menos un sitio celular entregando cobertura para la red de telefonía móvil; si revisamos cuanto tráfico está manejando una BTS vamos a un router cualquiera de la capa de acceso y monitorizamos el SAP asociado al puerto en cuestión; como ejemplo tomaremos el CSR de Huachocopihue correspondiente al anillo tres del clúster de Valdivia e iniciaremos una sesión de telnet a través del gestor como lo muestra la siguiente figura: Figura 3.11 – Inicio de sesión de Telnet en Gestor SAM Lo cual nos abrirá automáticamente una sesión en la cual nos pedirá un nombre de usuario y contraseña previamente definidos por el administrador de la Red como se muestra en la Figura siguiente (el equipo tiene asignado el router‐id 172.26.56.139): 138 Figura 3.12 – Inicio de sesión Telnet en equipo SARM Realizaremos el monitoreo de tráfico proveniente del Nodo B (en la capa de acceso) conectado en el puerto 1/1/5 para lo cual revisaremos el correspondiente punto de acceso al servicio o SAP con el comando “show service sap‐using” como lo muestra la Figura 3.13; en esta se puede apreciar que se encuentran definidas las Vlan 3765 y 3766 para realizar el etiquetado dot1q de las tramas de acceso. El monitoreo del puerto 1/1/5 (Fast‐Ethernet) Figura 3.14 nos muestra que existe una ocupación cercana al 1,35% (Input) de entrada de datos en el puerto que es lo correspondiente al tráfico normal de un nodo en un escenario no congestionado; para el caso de un escenario de nodo 3G congestionado se obtienen ocupaciones cercanas al 7%; esto indica congestión a nivel de acceso en el Nodo pero no en el puerto del router. Recordemos que el puerto es Fast‐Ethernet por lo tanto es capaz de manejar a su máxima capacidad 100Mbps y por lo tanto una tasa de ocupación de un 1,32% es igual 1,32Mbps y una de un 7% de 7Mbps. 139 Figura 3.13 – Identificación del puerto de Acceso en el router SARM Huachocopihue Si seguimos monitoreando hacia los extremos del anillo nos comenzaremos a dar cuenta que el aporte de tráfico de este Nodo B (denominado como Nodo B Huachocopihue) de la red 3G de la empresa de telecomunicaciones es cercano a 1,3Mbps en un rango de operación normal lo cual de ningún modo hace colapsar los puertos GbEthernet que van contra los demás routers de la topología. Es más, la ocupación de ambos puertos GbEthernet (1/1/1 y 1/1/2) es de 0,06% y 0,40% respectivamente, como lo muestra la Figura 3.15 lo que nos indica que el router no está realizando demasiado trabajo para procesar la información de ese Nodo B. Además los valores están muy alejados de los 251 Mbps definidos a inicios de Capítulo por cada CSR (SARM) ya que en estos momentos no se encuentra integrada la red 2G ni la red LTE sobre estos equipos. 140 Figura 3.14 ‐ Monitoreo de tráfico en puerto de acceso 1/1/5 Si continuamos creciendo hacia la Capa de Agregación (hacia los MR) podemos darnos cuenta de cómo se va incrementando el tráfico a medida que subimos a través de los distintos niveles de nuestra topología. Como segundo paso nos ubicaremos sobre la capa de Agregación y contra la capa de Core para observar el flujo de tráfico proveniente de los Nodos B conectados al clúster de Valdivia (figura 3.16); en este punto podemos observar el tráfico total de la red 3G de nuestro clúster; los equipos sobre los cuales realizaremos el monitoreo se denominan VALDIVIA_MR_A y VALDIVIA_MR_B El monitoreo de tráfico en los puertos contra los HRs nos dan un porcentaje de ocupación de 0,94% en MR B y un 2,20% en MR A. Esto nos da como resultado un valor cercano a 22Mbps + 9,4Mbps = 31,4Mbps de tráfico total de uso de red en Valdivia; se debe destacar que estas mediciones se hicieron durante un período de mantenimiento (cerca de las 3 a.m). 141 Figura 3.15 – Monitoreo de tráfico en puertos GbEthernet en SARM Huachocopihue Si bien es cierto la cantidad de tráfico que aporta la red 3G de Valdivia es poco comparado a grandes localidades como la localidad de Ñuñoa o Independencia en Santiago, la solución empleada IP/MPLS está dimensionada para realizar el transporte de tráfico de los Nodos 2G de la red paralela (ATM) a la red 3G mostrada; además se debe integrar en un futuro cercano la red LTE de la compañía con lo cual la utilización de ancho de banda de la red troncal IP/MPLS se verá incrementado drásticamente. 142 Figura 3.16 – Capa de Agregación Figura 3.17 – Monitoreo de tráfico MR‐B Valdivia 143 Figura 3.18 – Monitoreo de tráfico en MR‐A Valdivia 3.5 Proyección de la tecnología IP/MPLS a MPLS‐TP en redes PTN‐MPLS Si bien es cierto la tecnología IP‐MPLS es madura y es suficiente para soportar varios escenarios de aplicación por el hecho de entregar muy poderosas capacidades de ingeniería de tráfico, su equipamiento y costos operacionales han impedido que los proveedores de servicios de despliegue a gran escala entren a las redes “metro” y redes de agregación. Los ingenieros de mantenimiento de redes de transporte y técnicos que están familiarizados con operaciones y procedimientos de operación de redes SONET/SDH requerirían entrenamientos adicional para aprender la administración y planificación de redes IP/MPLS. De manera adicional IP/MPLS carece de componentes clave de operación, administración y 144 funciones de mantenimiento para el monitoreo de rendimiento y administración de fallas de redes SONET‐SDH. MPLS‐TP (TP – Transport Profile) es un perfil de transporte de MPLS cuya definición ha sido manejada por el IETF. Está diseñada para su uso como Tecnología de Capa de Red en redes de transporte. Su diseño será una continuación del trabajo empezado por los expertos en transporte de red del ITU‐T, específicamente del SG15. Esta es una aplicación de paquetes conmutados orientados a la conexión que entregará una implementación MPLS dedicada la cual quitará características que son irrelevantes a aplicaciones orientadas a la conexión y añadirá mecanismos que darán soporte para funcionalidades de transporte críticas. MPLS‐TP simplifica los escenarios de MPLS con un decremento en la utilización de equipamiento, operación y costos de mantenimiento. El plano de datos está separado del plano de control, lo cual conduce a una estabilidad muy alta de la red, confiabilidad y flexibilidad. Con inteligentes capacidades de operación, administración y mantenimiento y funciones conmutadas de protección, las PTN basadas en MPLS pueden alcanzar la misma confiabilidad y nivel de resiliencia de una SDH de próxima generación (NG‐SDH). Dentro de las mejoras en las características que son aplicadas a MPLS‐TP se encuentran: ‐ Restricciones y mejoras en el plano de reenvío MPLS ‐ Plano de Control: estático o dinámico ‐ Funcionalidades mejoradas de OAM (Operación, Administración y Mantenimiento) 3.5.1 Plano de Reenvío Para mejorar el transporte de Red y las capacidades de administración, se han ajustado algunos elementos de MPLS en MPLS‐TP los cuales son: ‐ No existe unión de LSP: Las arquitecturas basadas en IP/MPLS permiten a los LSP unir los paquetes que atraviesan el mismo camino, lo cual ayuda a mejorar la eficiencia en el transporte del tráfico pero da como resultado la pérdida de información de la cabecera. 145 La información de cabecera es crítica para entregar capacidades de OAM mejoradas (las cuales los proveedores de servicio desean). MPLS‐TP no permite la unión de LSP lo cual nos guía a una capacidad de OAM mejorada de extremo a extremo. ‐ No se quita el último salto (Penultimate Hop Popping – PHP): La extracción de la etiqueta de egreso MPLS, permitida en las redes basadas en IP/MPLS, causaban la pérdida del contexto en el router P adyacente. La etiqueta MPLS de egreso es utilizada como un identificador de OAM para las capacidades mejoradas de OAM entregadas por MPLS‐TP, pero no es permitida en rede MPLS‐TP. También PHP no entrega beneficios aparentes para las VPN en Capa 2. ‐ No hay Balanceo de Carga/ECMP (Equal Cost Multi Path): ECMP es un mecanismo de reenvío para el enrutamiento de paquetes a lo largo de múltiples caminos de igual costo para alcanzar una distribución casi igual de la carga en los enlaces. Sin embargo este mecanismo conduce a problemas para la detección de fallas debido a que los caminos actuales de la ruta del tráfico varía entre los paquetes. ‐ LSP Bidireccional Congruente: Este elemento permite a las redes basadas en MPLS‐TP la emulación de las clásicas redes de transporte – la transmisión y la recepción siguen el mismo camino a través de la red. Esta simplifica las operaciones para la conectividad bidireccional, la cual mejora el rendimiento en el “jitter” debido a la reducida variabilidad en el retardo de los paquetes. Esto también simplifica la detección de fallas y mejora la utilización delas mejoras en OAM entregadas por MPLS‐TP. 3.5.2 Plano de Control Dentro del contexto de MPLS‐TP, el plano de control es el mecanismo utilizado para ajustar un LSP automáticamente a través de un dominio de red de paquetes conmutados. El uso de un protocolo de plano de control es opcional en MPLS‐TP. Algunos operadores pueden preferir configurar los LSPs y PWs utilizando un Sistema de Administración de Red de la misma manera en la cual se realiza el aprovisionamiento de SONET. En este caso no se utiliza IP o 146 protocolos de enrutamiento. De manera inversa es posible utilizar un plano de control dinámico con MPLS‐TP con lo cual los lSPs y PWs son ajustados por la red utilizando G‐MPLS (MPLS Generalizado) y el Protocolo de Distribución de Etiquetas Dirigido (Targeted‐LDP ‐ T‐LDP), respectivamente. G‐MPLS está basado en las extensiones de Ingeniería de Tráfico (TE) a MPLS (MPLS‐TE). También puede ser utilizado para ajustar las funciones de OAM y definir mecanismos de recuperación. T‐LDP es parte de la arquitectura del PW y es ampliamente utilizado hoy en día para señalizar PWs y su estado. Por lo tanto a modo de resumen se puede decir que en un futuro muy cercano lo único que atravesarán las redes mundiales serán paquetes y se necesita definir nuevos estándares y arquitecturas para el transporte de estos. MPLS‐TP representa un nuevo desarrollo en la larga lista de protocolos de la suite MPLS. Este entrega una arquitectura evolucionada para redes de transporte basadas en TDM y está optimizada para el transporte de paquetes. Esta tecnología conserva cuidadosamente las características de OAM y administración que los grupos de transporte han venido utilizando en el pasado y permite una integración completa de extremo a extremo con las infraestructuras IP/MPLS existentes y futuras. Con la utilización de IP/MPLS y MPLS‐TP, los proveedores de servicio tendrán una manera consistente de realizar el aprovisionamiento, administración y troubleshooting en la totalidad de los puntos extremos de la red. El siguiente diagrama extraído de la página web www.cisco.com (Figura 3.19) ilustra de mejor manera la definición del significado de MPLS‐TP y su gran importancia. En el caso de nuestra red Mobile Backhaul Corporativa mostrada en la Figura 3.6 los equipos utilizados desde el core IP hasta el acceso son equipos IP/MPLS; esto significa que ninguno de estos equipos podrá tener relación directa o de par a par con un medio de transmisión como SDH, ROADM o DWDM; solo serán vistos como una nube en el caso de que se realice la interconexión contra ellos, pero no se podrá realizar ninguna operación de mantenimiento. Esta funcionalidad será la nuevamente implementada en un futuro muy cercano en las redes a nivel Nacional y permitirá la comunicación con estos equipos y permitirá la mejor administración de recursos de la red, 147 mantenimiento y como se ha mencionado extensamente en este trabajo de titulación, la detección de fallas. Figura 3.19 – Integración de IP‐MPLS y MPLS‐TP Se puede observar también la acotación de las funciones realizadas por IP‐MPLS y MPLS.TP. IP‐MPLS será la encargada de trabajar sólo en el core multiservicio realizando solo la función de conmutación de etiquetas contra la red MPLS‐TP y el segmento de control de los equipos de Acceso de la red NGN; por su parte la red MPLS‐TP realizará la conmutación de etiquetas contra el acceso y también contra los distintos medios de transmisión mencionados anteriormente (CWDM, ROADM DWDM, etc.) 148 CAPÍTULO 4 ‐ CONCLUSIONES El mercado móvil hoy en día es muy cambiante y para seguir siendo competitivo los proveedores de servicios móviles deben entregar servicios a un bajo costo. Las demandas de los usuarios móviles han ido evolucionando desde los servicios básicos de datos como la mensajería instantánea y el e‐mail hacia aplicaciones mucho más sensibles a los retardos en la transmisión de datos como lo son las aplicaciones multimedia en tiempo real, las videoconferencias, etc. Las redes de transporte móvil (y redes de transporte en general) como la analizada en este trabajo de titulación deben ser escalables y soportar las futuras demandas de ancho de banda de tecnologías futuras como son LTE o WiMAX. Mientras más suscriptores comiencen a adoptar servicios avanzados 3G las demandas de ancho de banda en Chile comenzarán a ser más altas y por lo tanto la necesidad de los clientes de los ISP de obtener más servicios comenzará también a crecer exponencialmente. Si bien es cierto la red Mobile Backhaul IP‐MPLS analizada cumple con los requerimientos de una red escalable y rentable ya que puede mantener distintos tipos de servicios sobre la misma red (ATM, FR, Ethernet) las demandas de ancho de banda seguirán incrementándose y la red en algún momento deberá agregar más enlaces o incluso modificar su configuración para adaptarse a los nuevos requerimientos de ancho de banda. Es por esto que las tecnologías van en continuo desarrollo y el mercado de las telecomunicaciones es tan cambiante y dinámico. Hoy en día y por mucho tiempo más la mejor opción para la implementación de redes escalables es la utilización de equipos MPLS debido a su flexibilidad y compatibilidad con diversas tecnologías. La evolución en diez años ha sido tal que se ha ido creciendo casi a un nivel exponencial permitiendo hoy en día tener Estaciones Base capaces de manejar hasta 100Mb/s y la gran 149 mayoría de las redes de transporte a nivel mundial para poder soportar tales tasas de tráfico utilizan la tecnología de pseudowires IP/Ethernet con equipamiento MPLS. Se puede concluir también que este trabajo de titulación tuvo como finalidad abarcar de la manera más extensa la tecnología de transporte IP‐MPLS y su evolución MPLS‐TP las cuales son hoy en día el presente y el futuro en el camino evolutivo hacia “all‐IP”, por lo cual tendremos a estos medios de transportes de información presentes en las redes troncales de todos los proveedores de servicios a nivel nacional e internacional por un largo tiempo. Para finalizar y de manera personal, este trabajo de titulación me permitió conocer y entender conceptos estudiados durante mi estadía en la Universidad de manera más profunda sobre todo en lo relacionado a las Telecomunicaciones y Comunicaciones Modernas y poder visualizar e implementar de manera práctica la implementación de una solución. También espero que este material sirva de aporte y de apoyo a cualquier estudiante de la carrera de Ingeniería Electrónica que desee profundizar en el estudio de redes de próxima generación y a quien desee también indagar en el desarrollo, implementación y configuración de soluciones de transporte de información basadas en la tecnología IP/MPLS, ya sea en cualquiera de las áreas en las cuales desee desempeñarse como futuro profesional. 150 REFERENCIAS BIBLIOGRÁFICAS [1] http://es.wikipedia.org/wiki/Multiprotocol_Label_Switching ‐ (Conmutación Multi‐Protocolo mediante etiquetas) [2] http://www.alcatel‐lucent.com – Router MPLS. [3] Designing and Implementing IP/MPLS‐Based Ethernet Layer 2 VPN Services: An Advanced Guide for VPLS and VLL – Zhuo Xu [4] Alcatel‐Lucent Scalable IP Networks – Kent Hudley [5] Advanced QoS for Multi‐Service IP/MPLS Networks – Ram Balakrishnan [6] Red de siguiente Generación http://es.wikipedia.org/wiki/Red_de_siguiente_generaci%C3%B3n [7] Next‐Generation Packet‐Based Transport Networks (PTN) – Reza Vaez‐Ghaemi, Ph.D. [8] Understanding MPLS‐TP and its Benefits – Cisco Systems ‐ http://www.cisco.com/en/US/technologies/tk436/tk428/white_paper_c11‐562013.pdf 151 GLOSARIO 2G: Segunda Generación de Telefonía Móvil. 3G: Abreviación de tercera generación de transmisión de voz y datos a través de telefonía móvil mediante UMTS. AS: Sistema Autónomo; grupo de redes IP que poseen una política de rutas propia e independiente. ATM: El Modo de Transferencia Asíncrona o Asynchronous Transfer Mode (ATM) es una tecnología de telecomunicación desarrollada para hacer frente a la gran demanda de capacidad de transmisión para servicios y aplicaciones BGP: Border Gateway Protocol; es un protocolo mediante el cual se intercambia información de encaminamiento entre sistemas autónomos. CES: Servicio de Emulación de Circuitos; es una tecnología de telecomunicaciones utilizada para transmitir servicios TDM como las líneas digitales tradicionales y los circuitos de portadora E sobre redes ATM. CSPF: Constrained Shortest Path First; Primera ruta más Corta restringida. Es un algoritmo de estado‐enlace utilizado en el cómputo de rutas, para rutas de conmutación de etiquetas que están sujetas a múltiples restricciones. DOCSIS: Son las siglas de data over cable service interface specification (en castellano, «especificación de interfaz para servicios de datos por cable»); estándar no comercial que define los requisitos de la interfaz de comunicaciones y operaciones para los datos sobre sistemas de cable. 152 DSLAM: Son las siglas de Digital Subscriber Line Access Multiplexer (Multiplexor de línea de acceso de abonado digital). El DSLAM es un multiplexor localizado en la central telefónica que proporciona a los abonados acceso a los servicios DSL sobre cable de par trenzado de cobre. FEC: Una Clase Equivalente de Reenvío es un término utilizado en MPLS para describir un conjunto de paquetes con características idénticas o similares, los cuales pueden ser reenviados de la misma forma. FR: Frame Relay o (Frame‐mode Bearer Service) es una técnica de comunicación mediante retransmisión de tramas para redes de circuito virtual, introducida por la ITU‐T a partir de la recomendación I.122 de 1988. Consiste en una forma simplificada de tecnología de conmutación de paquetes que transmite una variedad de tamaños de tramas o marcos (“frames”) para datos, perfecto para la transmisión de grandes cantidades de datos. FRR: Fast Reroute es una tecnología de resiliencia MPLS que entrega una rápida recuperación en el caso de falla de los enlaces. IES: Internet Enhanced Service ‐ Servicio de Internet Mejorado; Servicio que entrega hacia el cliente una interfaz en Capa 3 para enviar y recibir tráfico desde y hacia Internet. IGP: Interior Gateway Protocol (IGP, protocolo de pasarela interno) hace referencia a los protocolos usados dentro de un sistema autónomo. IP: Internet Protocol (en español Protocolo de Internet) o IP es un protocolo de comunicación de datos digitales clasificado funcionalmente en la Capa de Red según el modelo internacional OSI. IPTV: Internet Protocol Television (IPTV) es la denominación más común para los sistemas de distribución por subscripción de señales de televisión o vídeo usando conexiones de banda ancha sobre el protocolo IP. 153 IS‐IS: El protocolo IS‐IS es un protocolo de estado de enlace, o SPF (shortest path first), por lo cual, básicamente maneja una especie de mapa con el que se fabrica a medida que converge la red. ISP: Un proveedor de servicios de Internet (o ISP, por la sigla en inglés de Internet Service Provider) es una empresa que brinda conexión a Internet a sus clientes. ITU: La Unión Internacional de Telecomunicaciones (UIT) es el organismo especializado de Telecomunicaciones de la Organización de las Naciones Unidas encargado de regular las telecomunicaciones a nivel internacional entre las distintas administraciones y empresas operadoras. LAN: Una red de área local, red local o LAN (del inglés local area network) es la interconexión de una o varias computadoras y periféricos. LDP: Protocolo de Distribución de Etiquetas; es un protocolo en el cual los routers MPLS intercambian información de mapeo de etiquetas. LIB: Base de Información de Etiquetas; es la tabla mantenida por los routers MPLS utilizada para almacenar los detalles del puerto y la correspondiente etiqueta del router MPLS que va a ser puesta o sacada sobre los paquetes MPLS. LSP: Intercambio de rutas por etiqueta, LSP del inglés Label Switched Path, es una ruta sobre una red MPLS, establecida por un protocolo de señalización como LDP, RSVP o CR‐LDP. LTE: LTE (Long Term Evolution) es un nuevo estándar de la norma 3GPP. Nuevo concepto de arquitectura evolutiva (4G). MAN: Una red de área metropolitana (Metropolitan Area Network o MAN, en inglés) es una red de alta velocidad (banda ancha) que da cobertura en un área geográfica extensa, proporciona capacidad de integración de múltiples servicios mediante la transmisión de datos, voz y vídeo, sobre medios de transmisión tales como fibra óptica y par trenzado. 154 MPLS: MPLS (Multi‐Protocol Label Switching) es una red privada IP que combina la flexibilidad de las comunicaciones punto a punto o Internet y la fiabilidad, calidad y seguridad de los servicios Prívate Line, Frame Relay o ATM. MSO: Operador de Sistemas Múltiples es un operador de múltiples sistemas de televisión por cable o de transmisión directa por satélite. NGN: Red de Siguiente Generación o Red Próxima Generación (Next Generation Networking o NGN en inglés) es un amplio término que se refiere a la evolución de la actual infraestructura de redes de telecomunicación y acceso telefónico con el objetivo de lograr la convergencia tecnológica de los nuevos servicios multimedia. PC: Una computadora personal u ordenador personal, también conocidas como PC (sigla en inglés de personal computer), es una microcomputadora diseñada en principio para ser usada por una sola persona a la vez. PE: Un router PE (Provider‐edge) es un router entre un área de un proveedor de servicios y áreas administradas por otros proveedores de servicios. PON: Una red óptica pasiva (del inglés Passive Optical Network, conocida como PON) permite eliminar todos los componentes activos existentes entre el servidor y el cliente introduciendo en su lugar componentes ópticos pasivos (divisores ópticos pasivos) para guiar el tráfico por la red, cuyo elemento principal es el dispositivo divisor óptico (conocido como splitter). PSTN: Red Telefónica Conmutada; conjunto de elementos constituido por todos los medios de transmisión y conmutación necesarios para enlazar a voluntad dos equipos terminales mediante un circuito físico que se establece específicamente para la comunicación y que desaparece una vez que se ha completado la misma. PTN: Red de transporte de Paquetes. QoS: QoS o Calidad de Servicio (Quality of Service, en inglés) son las tecnologías que permiten aplicar un tratamiento específico a un determinado tipo de tráfico. 155 RAN: Red de Acceso por Radio; es parte de un sistema de telecomunicaciones móviles, la cual implementa la tecnología de acceso por radio. RSVP: El protocolo de reserva de recursos (RSVP o Resource Reservation Protocol), descrito en RFC 2205, es un protocolo de la capa de transporte diseñado para reservar recursos de una red bajo la arquitectura de servicios integrados. SAP: Un Punto de Acceso a Servicio es una etiqueta utilizada para identificar los puntos finales de red. SDP: Punto de Distribución del Servicio; representación lógica del túnel de transporte que será utilizado para entregar los datos del servicio al próximo router. SIP: Session Initiation Protocol (SIP o Protocolo de Inicio de Sesiones) es un protocolo desarrollado por el grupo de trabajo MMUSIC del IETF con la intención de ser el estándar para la iniciación, modificación y finalización de sesiones interactivas de usuario donde intervienen elementos multimedia como el video, voz, mensajería instantánea, juegos en línea y realidad virtual. SLA: Un acuerdo de nivel de servicio o Service Level Agreement, también conocido por las siglas ANS o SLA, es un contrato escrito entre un proveedor de servicio y su cliente con objeto de fijar el nivel acordado para la calidad de dicho servicio. TDM: Multiplexación por división de tiempo (Time Division Multiple Access o TDMA) es una técnica que permite la transmisión de señales digitales y cuya idea consiste en ocupar un canal (normalmente de gran capacidad) de transmisión a partir de distintas fuentes, de esta manera se logra un mejor aprovechamiento del medio de transmisión. TDT: Televisión digital terrestre (TDT) es la transmisión de imágenes en movimiento y su sonido asociado (televisión) mediante una señal digital (codificación binaria) y a través de una red de repetidores terrestres. 156 VLL: Servicio de cable virtual privado; servicio punto a punto que emula una línea arrendada; se utiliza también VPWS. VPLS: Servicio de LAN privada virtual (VPLS) es una forma de proporcionar Ethernet multipunto a multipunto basado en la comunicación sobre redes IP / MPLS. VPN: Una red privada virtual, RPV, o VPN de las siglas en inglés de Virtual Private Network, es una tecnología de red que permite una extensión segura de la red local sobre una red pública o no controlada como Internet. VPRN: Red Privada Virtual Enrutada; es un servicio de Capa 3 que conecta múltiples sitios en el dominio de enrutamiento sobre una red IP/MPLS. VPWS: Servicio de cable virtual privado; servicio punto a punto que emula una línea arrendada. WAN: Una red de área amplia, o WAN, por las siglas de wide area network en inglés, es una red de computadoras que abarca varias ubicaciones físicas, proveyendo servicio a una zona, un país, incluso varios continentes. xDSL: Se conoce como xDSL a la familia de tecnologías de acceso a Internet de banda ancha basadas en la digitalización del bucle de abonado telefónico (el par de cobre).
