• Author / Uploaded
• Luis Diaz

Citation preview

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).