• No se han encontrado resultados

Calidad de servicios QOS utilizando MPLS

N/A
N/A
Protected

Academic year: 2020

Share "Calidad de servicios QOS utilizando MPLS"

Copied!
112
0
0

Texto completo

(1)IEM-II-2003-04. CALIDAD DE SERVICIO QoS UTILIZANDO MPLS. IVAN ANTONIO CONTRERAS PINZON. UNIVERSIDAD DE LOS ANDES FACULTAD DE INGENIERÍA DEPARTAMENTO DE INGENIERÍA ELÉCTRICA Y ELECTRÓNICA BOGOTA D.C. 2004.

(2) IEM-II-2003-04. CALIDAD DE SERVICIO QoS UTILIZANDO MPLS. IVAN ANTONIO CONTRERAS PINZON. Trabajo de grado para optar al título de Maestría en Ingeniería Electrónica.. Asesor NESTOR M. PEÑA TRASLAVIÑA, Ph. D.. UNIVERSIDAD DE LOS ANDES FACULTAD DE INGENIERÍA DEPARTAMENTO DE INGENIERÍA ELÉCTRICA Y ELECTRÓNICA BOGOTA D.C. 2004. 2.

(3) IEM-II-2003-04. CONTENIDO. Pag. INTRODUCCIÓN .................................................................................................... 9 1. LIMITACIONES DE IP SOBRE ATM ................................................................ 10 1.1 REDES DE MPLS........................................................................................ 11 1.2 CONMUTACIÓN DE ETIQUETAS: CONCEPTOS BÁSICOS .................... 12 1.2.1 La Clase de Equivalencia Funcional: FEC (Functional Equivalence Class) ............................................................................................................ 13 1.2.2 Funciones de control y reenvío ......................................................... 13 1.2.3 Asociación de Etiquetas a FECs........................................................ 19 2. ARQUITECTURA DE MPLS............................................................................. 21 2.1 TERMINOLOGÍA ......................................................................................... 22 2.2 TIPOS DE NODOS MPLS ........................................................................... 23 2.3 PROTOCOLOS DE DISTRIBUCIÓN DE ETIQUETAS ............................... 24 2.4 FORMATO DE LAS ETIQUETAS ............................................................... 26 2.5 LA PILA DE ETIQUETAS ........................................................................... 27 2.6 CAMINO DE CONMUTACIÓN DE ETIQUETAS (LSP): REGLAS DE APILAMIENTO .................................................................................................. 27 2.7 PROTOCOLOS DE DISTRIBUCIÓN DE ETIQUETAS ............................... 30 2.8 PROTOCOLOS DE ESTADO DURO (HARD-STATE) Y PROTOCOLOS DE ESTADO BLANDO (SOFT-STATE).................................................................. 31 3.

(4) IEM-II-2003-04 3. DISEÑO Y EVALUACION DE LAS REDES CON Y SIN MPLS ....................... 39 3.1 TOPOLOGIAS DE RED .............................................................................. 41 3.2 ESTRUCTURA DE LA RED MPLS UTILIZANDO NS-2 ............................. 43 4. RESULTADOS Y ANALISIS DE LA SIMULACIÓN ......................................... 48 CONCLUSIONES ................................................................................................. 66 GLOSARIO ........................................................................................................... 67 ANEXOS ............................................................................................................... 72 BIBLIOGRAFIA .................................................................................................. 110. 4.

(5) IEM-II-2003-04. LISTA DE FIGURAS. Pag. Figura 1. Funciones de envío y enrutamiento .................................................. 14 Figura2. Arquitectura básica de un nodo MPLS realizando el enrutamiento IP. ....................................................................................................................... 15 Figura 3. Arquitectura de un LSR de Contorno ................................................ 17 Figura 4. Río abajo no solicitado (unsolicited-downstream)........................... 25 Figura 5. Un LSR distribuye asociaciones a LSRs que no lo han solicitado explícitamente .............................................................................................. 25 Figura 6. Encabezado MPLS.............................................................................. 26 Figura 7. Arquitectura de un nodo MPLS en NS ............................................. 39 Figura 8. Estructura de tablas para la conmuitación de paquetes MPLS....... 40 Figura 9. Topologías de red a simular con y sin MPLS.................................... 42 Figura 10. Monitor de Cola con MPLS .............................................................. 48 Figura 11. Monitor de cola de la red sin MPLS ................................................. 49 Figura 12. Monitor de bytes ruta Q1,Q2 y Q3 con MPLS................................. 50 Figura 13. 10 Monitor de bytes ruta Q1,Q2 y Q3 sin MPLS.............................. 50 Figura 14. Utilización de los canales de Q11, Q12 y Q13 con MPLS .............. 52 Figura 15. Anchos de banda de Q21 y Q22 con MPLS.................................... 52 Figura 16. Anchos de banda de Q21 y Q22 sin MPLS ..................................... 53 Figura 17. Anchos de banda Q31, Q32 y Q33 con MPL................................... 53 5.

(6) IEM-II-2003-04 Figura 18. Perdida de paquetes en Q21 y Q22 con MPLS............................... 55 Figura 19. Perdida de paquetes en Q21 y Q22 sin MPLS................................. 55 Figura 20 Tiempo: 016 seg. De simulación ....................................................... 56 Figura 21. Tiempo: 0.872 seg. Tráfico de paquetes......................................... 56 Figura 22. Tiempo: 1.76seg. Flujo de tráfico y colas en las nodos 7,8 y 10. . 57 Figura 23. Tiempo: 2.72seg. Enrutamientos establecidos entre los nodos de acuerdo a los requerimientos de los mensajes LSP................................. 57 Figura 24. Tiempo: 0.16Seg. De simulación...................................................... 58 Figura 25. Tiempo: 0.87Seg. Flujo de tráfico solo en los nodos 4_7_9. ......... 58 Figura 26. Tiempo: 2.72Seg. Acumulación de paquetes en los nodos 4 y 7.. 59 Figura 27. Tiempo: 1.745Seg. Perdida de paquetes en los nodos 4 y 7. ....... 59 Figura 28. Tiempo: 0.01Seg. LDP mapping Messages .................................... 60 Figura 29. Tiempo 0.15Seg. Establecimiento de LSR....................................... 60 Figura 30. Tiempo 0.70Seg. Mensajes CR-LDP para crear ER-LSP. ............... 61 Figura 31. Anchos de banda Topología 2......................................................... 61 Figura 32. Nivel de clases en NS........................................................................ 62 Figura 33. Comienzo simulación topología 3.................................................... 63 Figura 34. Variación del Ancho de banda en la topología 3 ............................ 63 Figura 35. Variación del Ancho de banda en la topología 3 ............................ 64. 6.

(7) IEM-II-2003-04. LISTA DE TABLAS. Pag. TABLA1. VALORES USADOS EN LA SIMULACIÓN PARA LOS NODOS IPMPLS ............................................................................................................. 46 TABLA 2. VALORES UTILIZADOS EN LA SIMULACIÓN ENTRE NODOS MPLS Ó LSR Y CON NODOS IP ............................................................................ 46 TABLA 3. PROMEDIOS DE PAQUETES ENTRE LOS ENLACES ..................... 51 TABLA 4. PROMEDIOS DE UTILIZACIÓN DE CADA ENLACE ......................... 54 TABLA 5. TABLA DE RESULTADOS.................................................................. 64. 7.

(8) IEM-II-2003-04. LISTA DE ANEXOS. Pag. ANEXO A .............................................................................................................. 72 ANEXO B .............................................................................................................. 81 ANEXO C .............................................................................................................. 89 ANEXO D .............................................................................................................. 95 ANEXO E ............................................................................................................ 102 ANEXO F ............................................................................................................ 105. 8.

(9) IEM-II-2003-04. INTRODUCCIÓN. El. crecimiento. imparable. de. la. Internet,. supone. cambios. tecnológicos. fundamentales y nuevas tecnologías de transmisión, basadas en enrutadores con funciones especializadas de transporte de paquetes que hacen surgir varias propuestas para suplir la necesidad de calidad de servicio en las redes IP, entre ellas se encuentran las arquitecturas de Servicios Integrados, Servicios Diferenciados y MPLS . Para garantizar el verdadero potencial de enrutamiento de paquetes se escogió la arquitectura de MPLS como alternativa de solución a la Calidad de Servicio QoS.. Actualmente se tiene acceso a varios simuladores, entre ellos se destaca Network Simulator (NS-2). Este es un poderoso simulador por eventos discretos enfocado a la investigación de redes. Su principal fuerte es la simulación de redes con protocolo TCP, enrutamiento y protocolos multireparto sobre redes cableadas e inalámbricas. Este programa surgió como una variante del REAL Network Simulator desarrollado en 1989 y sus evoluciones subsecuentes. El lenguaje de programación utilizado para crear los subprogramas puede ser TCL o C++.. 9.

(10) IEM-II-2003-04. 1. LIMITACIONES DE IP SOBRE ATM. Las fallas más comunes que se presentan en las redes LANE: - latencia de conexión - mantener los intervalos de restauración. - ayuda limitada a LAN. - intensidad de la CPU. - necesidad de enrutadores entre otras ELANs.. La arquitectura de las redes ATM presenta disparidad entre la alta velocidad de Ethernet, las interfaces de SONET/SDH con las interfaces rápidas de los enrutadores ATM. Los límites de los SAR en ATM afectan el diseño de red y no se puede aumentar su capacidad.. La tendencia tecnológica actual consiste en la consolidación de tipos de tráfico más importantes en el protocolo IP. Las soluciones de telefonía, videoconferencia y las aplicaciones científicas de banda ancha están cada día más solicitadas. Además, los flujos audio y vídeo corresponden a servicios en tiempo real. Pero ello exige tiempos de transporte muy cortos y una transferencia con muy poca inestabilidad. Las aplicaciones tradicionales (web, correo electrónico, transferencia de archivos) admiten retardos importantes pero, en cambio, requieren de una tasa de pérdida de paquetes fiable. Junto a los servicios de punto a punto tradicionales también empiezan a aparecer servicios multipuntos, servicios de difusión y servicios de redes privadas virtuales para los que hay que gestionar la calidad del servicio (QoS).. Dado este contexto, el principio de la “mejor prestación” propio de la pila de protocolos TCP/IP no ofrece garantías suficientes. Para hacer frente a las nuevas 10.

(11) IEM-II-2003-04 condiciones y ofrecer una calidad de servicio adecuada, los ingenieros pueden recurrir a redes de mayor tamaño. No obstante, ésta es una solución a corto plazo ya que el tráfico no para de aumentar y tiende a ocupar rápidamente toda la banda de paso disponible. Incluso en los enlaces muy poco cargados, los picos de tráfico muy cortos ocasionan a veces degradaciones del rendimiento inaceptables para las aplicaciones en tiempo real. Por último, la expansión y la interconexión de las redes hacen que los cuadros de encaminamiento sean cada vez más complejos de gestionar.. 1.1 REDES DE MPLS MPLS es un estándar emergente del IETF que surgió para encauzar diferentes soluciones de conmutación multinivel. Todas las soluciones de conmutación multinivel (incluido MPLS) se basan en dos componentes básicos comunes: - la separación entre las funciones de control (encaminamiento-routing) y de envío-forwarding. - el paradigma de intercambio de etiquetas para el envío de datos.. Esta tecnología, basada en la conmutación de paquetes de datos en función de una etiqueta, o “label”, añadida al encabezamiento, es flexible y ofrece múltiples posibilidades ya que una etiqueta puede caracterizar el camino, el origen, el destino, la aplicación, la calidad del servicio, etc.. En primer lugar, MPLS facilita el encaminamiento de los paquetes par rutas configuradas de antemano, en función de criterios como, por ejemplo, la baja tasa de carga, el reparto de la carga por varias rutas o la necesidad de restaurar un enlaces, etc. Los sistemas intermedios situados en el centro de la red tratan las informaciones primarias que contienen las etiquetas mucho más rápidamente ya que la decisión de encaminamiento está establecida de antemano. Por ello, los paquetes circulan más rápido y los recursos de los enrutadores y de los conmutadores están menos solicitados. 11.

(12) IEM-II-2003-04 Una etiqueta MPLS puede asociarse a un flujo aplicativo específico, lo cual permite distinguirlo de los otros, todo lo contrario que en el protocolo IP, que no diferencia las aplicaciones. Las aplicaciones que exigen una banda de paso garantizada y estable, como vimos antes, pueden recibir un trato prioritario.. Una etiqueta MPLS puede asociarse a un origen o destino y con ello se facilita la creación de circuitos virtuales privados (VPN) que comparten una infraestructura física común. Estos VPN permiten agregar tipos de tráfico que presentan características comunes, lo cual tiene ventajas tanto en lo que se refiere a los recursos de la red como a la seguridad y a la gestión de la facturación. Además, la jerarquía de las etiquetas MPLS permite construir VPN que no necesitan ninguna modificación en el espacio de la dirección IP de los clientes y que coexisten con la red MPLS que algunos clientes podrían establecer entre sus diferentes sitios.. De manera general, la implantación de MPLS en una red de base y en una red de distribución permite mejorar el rendimiento del núcleo de la red y controlar la calidad del servicio, dejando al mismo tiempo que sus miembros gestionen su propio tráfico como deseen.. 1.2 CONMUTACIÓN DE ETIQUETAS: CONCEPTOS BÁSICOS Antes de continuar conviene aclarar un par de términos. Los enrutadores utilizan dos protocolos para retransmitir el tráfico hacia el receptor. Uno retransmite los paquetes hacia su destino y el otro se encarga de encontrar un camino para que los paquetes puedan viajar hacia su destino.. El primero de estos protocolos se llamaba antiguamente encaminamiento y el segundo descubrimiento de la ruta. Actualmente, el término encaminamiento se usa para referirse al segundo protocolo, y los términos reenvío y conmutación para referirse al primero.. 12.

(13) IEM-II-2003-04 1.2.1 La Clase de Equivalencia Funcional: FEC (Functional Equivalence Class) La clase de equivalencia funcional se usa para describir una asociación de paquetes a una dirección destino, o lo que es lo mismo: grupo de paquetes IP que se reenvían de la misma manera. También se puede asociar el valor de la FEC a una dirección destino y a una clase de tráfico. La clase de tráfico esta asociada habitualmente a un número de puerto destino. Uno de los motivos por los que se utiliza la FEC es porque permite agrupar paquetes en clases. Gracias a esta agrupación, el valor de la FEC en el paquete se puede utilizar para establecer prioridades, de tal forma que se da más prioridad a unos FECs sobre otros. Se pueden usar las FECs para dar soporte a operaciones eficientes de QOS (calidad de servicio). Por ejemplo, se pueden asociar FECs de alta prioridad a tráfico de voz en tiempo real, de baja prioridad a correo, etc. Para establecer la relación entre una FEC y un paquete, se usa la etiqueta. Dicha etiqueta identifica una FEC específica. Para diferentes clases de servicio se utilizarán diferentes FECs y sus etiquetas asociadas. Una parte esencial de la tabla de encaminamiento mantenida por un enrutador es la dirección del siguiente enrutador. Un paquete perteneciente a una FEC asociado a una determinada entrada de la tabla se reenviará al siguiente enrutador según esté especificado en dicha tabla. 1.2.2 Funciones de control y reenvío Podemos distinguir claramente dos componentes: el componente de control y el componente de reenvío. Figura 1. El componente de control utiliza los protocolos estándar de encaminamiento, como OSPF y BGP. Utilizando estos protocolos los enrutadores intercambian información de encaminamiento para construir y mantener las tablas de 13.

(14) IEM-II-2003-04 encaminamiento. Además el componente de control debe crear las asociaciones entre etiquetas y FECs y distribuir esta información.. Figura 1. Funciones de envío y enrutamiento El componente de reenvío envía los paquetes desde la entrada hacia la salida. Para reenviar los paquetes, el componente de reenvío examina la información de la cabecera del paquete, busca en la tabla de encaminamiento la entrada correspondiente y reenvía el paquete. Por tanto, el componente de reenvío consiste en el conjunto de procedimientos que usa el enrutador para tomar la decisión sobre el reenvío de un paquete. Estos algoritmos definen la información del paquete que utiliza el enrutador para encontrar una entrada en la tabla de encaminamiento, así como los procedimientos exactos que el enrutador utiliza para encontrar la entrada. Cada enrutador de la red implementa ambos componentes. Podríamos ver el encaminamiento del nivel de red como una composición de ambos componentes (control y reenvío) implementada de una manera distribuida por el conjunto de enrutadores que conforman la red. La ventaja fundamental de separar ambos componentes es la posibilidad de modificar uno de ellos sin modificar el otro. La arquitectura MPLS, asigna etiquetas a los paquetes para su transporte a través de redes basadas en paquetes o celdas. La arquitectura se divide en dos 14.

(15) IEM-II-2003-04 componentes separados: el componente de envío (también denominado plano de datos) y el componente de control (llamado también plano de control). La Figura 2 muestra la arquitectura básica de un nodo MPLS realizando el enrutamiento IP.. Figura2. Arquitectura básica de un nodo MPLS realizando el enrutamiento IP. La componente de control utiliza los protocolos estándar de encaminamiento (OSPF, IS-IS y BGP-4), para el intercambio de información con los otros enrutadores para la construcción y el mantenimiento de las tablas de encaminamiento. Al llegar los paquetes, la componente de envío busca en la tabla de envío, que mantiene la componente de control, para tomar la decisión de encaminamiento para cada paquete. En concreto, la componente de envío examina la información de la cabecera del paquete, busca en la tabla de envío la entrada correspondiente y dirige el paquete desde el interfaz de entrada al de salida a través del correspondiente hardware de conmutación. La diferencia está en que ahora lo que se envía por el interfaz físico de salida son paquetes “etiquetados”. De este modo, se está integrando realmente en el mismo sistema las funciones de conmutación y de encaminamiento. En cuanto a la etiqueta que marca cada paquete, decir que es un campo de unos pocos bits, de longitud fija, 15.

(16) IEM-II-2003-04 que se añade a la cabecera del mismo y que identifica una “clase equivalente de envío” (Forwarding Equivalente Class, FEC), una. FEC es un conjunto de. paquetes que se envían sobre el mismo camino a través de una red, aun cuando sus destinos finales sean diferentes. El algoritmo de intercambio de etiquetas permite así la creación de “caminos virtuales” conocidos como LSP (LabelSwitched Paths). La base del MPLS está en la asignación e intercambio de etiquetas ya expuesto, que permiten el establecimiento de los caminos LSP por la red. Los LSPs son enlaces simples por naturaleza (se establecen para un sentido del tráfico en cada punto de entrada a la red); el tráfico dúplex requiere dos LSPs, uno en cada sentido. Cada LSP se crea a base de concatenar uno o más saltos (hops) en los que se intercambian las etiquetas, de modo que cada paquete se envía de un “conmutador de etiquetas” (Label-Swiching Router) a otro, a través del dominio MPLS. Un LSR no es sino un enrutador especializado en el envío de paquetes etiquetados por MPLS.. La Figura 3 muestra la arquitectura de un LSR de contorno. Un LSR de contorno amplía la arquitectura del nodo MPLS de la Figura 2 con componentes adicionales en el plano de datos. La tabla de envío IP se construye sobre la base de la tabla de enrutamiento IP y se amplía con información de etiquetado. Los paquetes IP entrantes se pueden enviar como paquetes IP puros hacia nodos que no son MPLS, o pueden ser etiquetados y enviarse como paquetes etiquetados a otros nodos MPLS; los paquetes etiquetados entrantes se pueden enviar como paquetes etiquetados a otros nodos MPLS. Para los paquetes etiquetados destinados a nodos que no son MPLS, se elimina la etiqueta y se realiza una consulta de capa 3(envío IP) para encontrar el destino que no es MPLS. Para realizar esta función, un LSR de contorno debe comprender dónde se ha encabezado el paquete y qué etiqueta, o pila de etiquetas, se debería asignar al paquete. En un envío de etiqueta de Capa 3 convencional, cada salto en la red realiza una consulta en la tabla de envíos IP para la dirección de destino IP almacenada en la cabecera de Capa 3 del paquete. Selecciona una dirección IP. 16.

(17) IEM-II-2003-04 de siguiente salto para el paquete en cada iteración de la consulta y, eventualmente, envía el paquete fuera de una interfaz hacia su destino final.[6]. Figura 3. Arquitectura de un LSR de Contorno Alternativas para el transporte de la etiqueta: La decisión del reenvío se basa en uno o más campos del paquete. El protocolo IP y los números de puerto se usan en la FEC y en las decisiones de reenvío. Estos campos identifican el tipo de tráfico que reside en la parte de datos del datagrama IP, por lo que son muy importantes en redes que admiten diferentes servicios de QOS para diferentes tipos de tráfico. 17.

(18) IEM-II-2003-04 ATM y Frame Relay (tecnologías del nivel de enlace) llevan la etiqueta en la cabecera del paquete. ATM puede llevar la etiqueta en el campo VCI o en el VPI de la cabecera, mientras que en Frame Relay estará en el campo DLCI de la cabecera. En DWDM la etiqueta puede asociarse con una longitud de onda en la fibra. Si esta fuera la única opción, en tecnologías como ethernet que no disponen de un campo para poder llevar la etiqueta en la cabecera del nivel de enlace, no se podría emplear la conmutación de etiquetas. La solución a este problema consiste en transportar la etiqueta en un campo específico para la etiqueta, que se inserta entre la cabecera del nivel de enlace y la cabecera del nivel de red. Esta cabecera se denomina "cabecera shim" (algo así como cabecera de relleno). De este modo se permite cualquier tecnología o combinación de tecnologías del nivel de enlace. Ej: conmutación de etiquetas en redes ethernet. El hecho de llevar la etiqueta en el campo VCI de las células ATM permite que un conmutador ATM funcione como un LSR siempre que tenga el software de control apropiado. La cabecera shim está situada en una posición donde la mayoría de los enrutadores pueden procesarla por software, por lo que los enrutadores convencionales pueden convertirse en LSRs siempre que tengan el software apropiado. LA TABLA DE ENCAMINAMIENTO Una tabla de encaminamiento está constituida por múltiples entradas. Cada entrada consta de: •. Etiqueta de entrada. •. Una o más subentradas: Etiqueta de salida, Interfaz de salida, Dirección del siguiente salto.. Puede haber más de una subentrada, puesto que hay que tratar los paquetes de difusión. De esta forma se puede enviar un paquete por múltiples interfaces de salida. Puede existir una tabla de encaminamiento única o por interfaz, en. 18.

(19) IEM-II-2003-04 cuyo caso a la hora de encaminar un paquete habrá que saber la interfaz por donde ha entrado el paquete. La tabla está indexada por el valor de la etiqueta, de tal forma que la búsqueda en la tabla es inmediata. Necesitaremos un solo acceso a memoria, lo que se traduce en un acceso rápido. La tabla o tablas de encaminamiento son mantenidas por el LSR. ETIQUETAS LIBRES: Un LSR mantiene un repositorio de etiquetas libres. Cuando se inicializa un LSR el repositorio contiene todas las etiquetas que el LSR puede usar para asociaciones locales. Cuando un LSR crea una asociación coge una etiqueta del repositorio y cuando la destruye la vuelve a depositar en el repositorio. Si el LSR tiene una tabla de encaminamiento por interfaz, tendrá que tener un repositorio con etiquetas por interfaz.. 1.2.3 Asociación de Etiquetas a FECs. Asociación local y asociación remota Asociación local: el enrutador local establece la asociación entre la etiqueta y la FEC. Por tanto, la etiqueta pertenecerá al enrutador. - Asociación remota: un enrutador vecino será el que establezca la asociación, por lo que el enrutador local recibirá la asociación de la etiqueta. - El componente de control usa ambos tipos de asociaciones para poblar su tabla de encaminamiento con etiquetas de entrada y salida. Asociación de etiquetas dirigida por control o por datos Un LSR crea o destruye asociaciones entre etiquetas y FECs en respuesta a un evento. Este evento puede deberse a que recibe información de control o a que debe reenviar 19.

(20) IEM-II-2003-04 paquetes. La asociación de etiquetas a FECs dirigida por control se establece de antemano. La asociación de etiquetas a FECs dirigida por los datos ocurre dinámicamente, a medida que fluyen los paquetes. Normalmente, ambos tipos de asociaciones se usan conjuntamente.. 20.

(21) IEM-II-2003-04. 2. ARQUITECTURA DE MPLS Una vez vistos los conceptos fundamentales de la conmutación de etiquetas, veamos los beneficios de MPLS. En MPLS, la asignación de un paquete a una FEC se realiza cuando el paquete entra en la red asignándole a dicho paquete una etiqueta. En los siguientes saltos sólo se usará la etiqueta para determinar la interfaz por donde reenviar el paquete, por lo que no será necesario analizar la cabecera del nivel de red. La etiqueta se usa como índice en la tabla de encaminamiento donde se obtiene el siguiente salto y la nueva etiqueta con la que sustituir la anterior. Hay que recordar que las etiquetas son locales a los enrutadores. En MPLS los conmutadores pueden realizar el reenvío, pero éstos no tienen necesidad de analizar las cabeceras del nivel de red. Ventajas de basar el reenvío en las etiquetas en vez de en la cabecera del nivel de red: Dado que un paquete se asigna a una FEC cuando entra en la red, el enrutador frontera que encapsula el paquete podrá usar toda la información que tenga sobre el paquete. Incluso información que no esté en la cabecera del nivel de red. Por ejemplo podrá usar información del nivel de transporte, como los números de puerto, para asignar paquetes a FECs. Por tanto, gran parte del trabajo se realiza antes de que el tráfico entre en la red. Con el encaminamiento convencional sólo se puede examinar la cabecera del nivel de red. Un paquete que entra en la red por un determinado enrutador puede etiquetarse de distinta forma que si hubiera entrado por otro. Por tanto, se pueden tomar decisiones dependientes del enrutador frontera que encapsula el paquete. Esto no se puede hacer en el encaminamiento convencional porque la identidad del enrutador frontera que introdujo el paquete en la red no viaja con el paquete. 21.

(22) IEM-II-2003-04 Se podría forzar a un paquete a seguir una ruta elegida explícitamente antes o en el momento que el paquete entre en la red, en vez de elegirse por el algoritmo dinámico de encaminamiento a medida que el paquete fluye por la red. Esto podría hacerse para permitir la ingeniería de tráfico. En el encaminamiento convencional el paquete tendría que llevar la información de la ruta (encaminamiento fuente). En MPLS se puede usar una etiqueta para representar la ruta, de tal forma que el paquete no tiene por qué llevar la información de la ruta. Algunos enrutadores analizan la cabecera del nivel de red para determinar la clase de servicio a la que pertenece el paquete así como para determinar el siguiente salto. Con la información de la clase de servicio el enrutador podrá o no aplicar alguna disciplina planificada a los paquetes. MPLS permite, pero no impone, que la clase de servicio se infiera total o parcialmente de la etiqueta. Así podremos decir que una etiqueta representa la combinación de una FEC y una clase de servicio. Según los conceptos básicos de la conmutación de etiquetas, MPLS se llama así porque soporta cualquier protocolo de nivel de red así como cualquiera de nivel de enlace. Por tanto, MPLS puede o no, usar tecnologías subyacentes de backbone como ATM, Frame Relay, SDH y DWDM. 2.1 TERMINOLOGÍA Fusión de etiquetas (label merging): reemplazo de múltiples etiquetas de entrada para una FEC particular por una sola etiqueta de salida. Salto de conmutación de etiquetas (label switched hop): salto entre dos nodos MPLS en los que el reenvío se hace usando etiquetas. Pila de etiquetas (label stack): conjunto ordenado de etiquetas Punto de fusión (merge point): nodo en el que se realiza la fusión de etiquetas.. 22.

(23) IEM-II-2003-04 Fusión de circuitos virtuales (VC merge): fusión de etiquetas en donde la etiqueta MPLS se transporta en el campo ATM VPI/VCI. De esta forma se permite que múltiples circuitos virtuales se fusionen en un único circuito virtual. Fusión de caminos virtuales (VP merge): fusión de etiquetas en donde la etiqueta MPLS se transporta en el campo ATM VPI. De esta forma se permite que múltiples caminos virtuales se fusionen en uno sólo. Dos células con el mismo valor VCI se han originado en el mismo nodo.. 2.2 TIPOS DE NODOS MPLS Los LSRs frontera son los encargados de etiquetar los paquetes que entran en la red. Para poder realizar este trabajo estos LSRs deben implementar el componente de control y el componente de reenvío tanto del encaminamiento convencional como de la conmutación de etiquetas. Si un paquete entra en la red, el enrutador frontera utilizará el componente de reenvío de la conmutación de etiquetas para determinar la etiqueta que ponerle al paquete. Si el siguiente salto no es un LSR y el paquete no tiene etiqueta, entonces el LSR deberá reenviar el paquete usando el componente de reenvío del encaminamiento convencional. Cuando el paquete va a salir de la red MPLS, el LSR que recibe el paquete le quitará la etiqueta y lo reenviará al siguiente salto usando el componente de reenvío del encaminamiento convencional. Dicho LSR sabrá que el paquete quiere abandonar la red simplemente porque el siguiente salto no es un LSR. Los tipos de nodos MPLS son [RFC3301]: LSR de entrada (ingress LSR): LSR que recibe tráfico de usuario (por ejemplo datagramas IP) y lo clasifica en su correspondiente FEC. Genera una cabecera MPLS asignándole una etiqueta y encapsula el paquete junto a la cabecera 23.

(24) IEM-II-2003-04 MPLS obteniendo una PDU MPLS (PDU = Protocol Data Unit o unidad de datos del protocolo). LSR de salida (egress LSR): LSR que realiza la operación inversa al de entrada, es decir, desencapsula el paquete removiendo la cabecera MPLS. LSR intermedio o interior: LSR que realiza el intercambio de etiquetas examinando exclusivamente la cabecera MPLS (obteniendo la etiqueta para poder realizar la búsqueda en la tabla de encaminamiento).. 2.3 PROTOCOLOS DE DISTRIBUCIÓN DE ETIQUETAS Un protocolo de distribución de etiquetas es un conjunto de procedimientos por los que un LSR le informa a otro de las asociaciones de etiquetas a FECs que ha hecho. A dos LSRs que utilizan un protocolo de distribución de etiquetas para intercambiar información de asociaciones de etiquetas a FECs se les conoce como un par de distribución de etiquetas (label distribution peers) respecto a la información de las asociaciones que intercambian. MPLS no asume que haya sólo un protocolo de distribución de etiquetas. De hecho, se están normalizando distintos protocolos de distribución de etiquetas. También se están definiendo nuevos protocolos como el LDP (Label Distribution Protocol). Distribución y asignación de etiquetas: En MPLS, la decisión correspondiente a la asignación de una etiqueta a una FEC la realiza el LSR que está río abajo (downstream) con respecto a la asociación. El LSR que está río abajo informa al LSR que está río arriba de la asociación. Por tanto, las etiquetas se asignan o asocian río abajo y se distribuyen en el 24.

(25) IEM-II-2003-04 sentido que va del LSR que está río abajo al LSR que está río arriba. MPLS permite variaciones en al asociación río abajo: Río abajo solicitado (downstream-on-demand) Figura 4. Un LSR le solicita explícitamente a su siguiente salto una asociación de una etiqueta a una FEC.. Figura 4. Río abajo no solicitado (unsolicited-downstream). . Figura 5. Un LSR distribuye asociaciones a LSRs que no lo han solicitado explícitamente Estas aproximaciones se pueden usar por separado o conjuntamente. En caso de usarlas conjuntamente en una adyacencia de distribución de etiquetas (es decir, cuando tenemos dos LSRs que son pares de distribución de etiquetas) ambos LSRs se tendrán que poner de acuerdo en la técnica a usar.. 25.

(26) IEM-II-2003-04 2.4 FORMATO DE LAS ETIQUETAS En la figura 6 se representa el esquema de los campos de la cabecera genérica MPLS y su relación con las cabeceras de los otros niveles. Según se muestra en la figura 6, los 32 bits de la cabecera MPLS se reparten en: 20 bits para la etiqueta MPLS, 3 bits para identificar la clase de servicio en el campo EXP (experimental, anteriormente llamado CoS), 1 bit de stack para poder apilar etiquetas de forma jerárquica (S) y 8 bits para indicar el TTL (time-to-live) que sustenta la funcionalidad estándar TTL de las redes IP.. Figura 6. Encabezado MPLS Etiqueta: valor de la etiqueta Exp: uso experimental. No está definido totalmente. Algunos artículos sobre servicios diferenciados (DiffServ) discuten su uso. S: bit de apilamiento (Stacking bit). Se usa para apilar etiquetas. TTL: tiempo de vida (Time To Live). Número de nodos (saltos) que puede atravesar el paquete MPLS. Se necesita porque los LSRs intermedios no analizan el campo IP TTL.. 26.

(27) IEM-II-2003-04 2.5 LA PILA DE ETIQUETAS En MPLS un paquete puede tener más de una etiqueta, organizadas éstas a modo de pila (FIFO). A esto se le conoce como pila de etiquetas. Aunque MPLS soporte una jerarquía gracias a la pila de etiquetas, el procesamiento de un paquete etiquetado es completamente independiente del nivel de la jerarquía. Siempre que se procese una etiqueta, ésta será la de la cima, sin importar cuántas etiquetas pueda haber debajo. Se puede considerar a un paquete no etiquetado como un paquete con una pila de etiquetas vacía. Si la profundidad de la pila de etiquetas de un paquete es m, a la etiqueta que está al fondo de la pila se le llama etiqueta de nivel 1, a la que está encima etiqueta de nivel 2, y así sucesivamente [RFC3301].. 2.6 CAMINO DE CONMUTACIÓN DE ETIQUETAS (LSP): REGLAS DE APILAMIENTO Un LSP de nivel m para un paquete P es una secuencia de enrutadores <R1,...,Rn> con las siguientes propiedades [RFC3301]: R1, el LSR de entrada, es un LSR que apila una etiqueta en la pila de etiquetas de P, resultando una pila de etiquetas de profundidad m. Para todo i, 1<i<n, P tendrá una pila de etiquetas de profundidad m cuando lo reciba el LSR Ri. Mientras P se encuentre entre R1 y Rn-1 su pila de etiquetas nunca tendrá una profundidad menor que m.. 27.

(28) IEM-II-2003-04 Para todo i, 1<i<n: P es transmitido desde Ri hasta Ri+1 por medio de MPLS, por ejemplo usando la etiqueta de la cima de la pila como índice de una ILM (Incoming Label Map). Para todo i, 1<i<n: si un sistema S recibe y reenvía P después de que P sea transmitido por Ri pero antes de que P sea recibido por Ri+1 (por ejemplo, Ri y Ri+1 pueden estar conectados vía una subred conmutada de enlace de datos, y S puede ser un conmutador de enlace de datos), entonces la decisión del reenvío de S no está basado en la etiqueta de nivel m, o en la cabecera del nivel de red. Esto puede ser debido a que: - La decisión no se basa en absoluto en la pila de etiquetas o en la cabecera del nivel de red. - La decisión se basa en una pila de etiquetas en la que se han apilado etiquetas adicionales (ejemplo: en un nivel de etiquetas m+k con k>0). En resumen, cuando un LSR etiqueta un paquete ya etiquetado, la nueva etiqueta corresponde a una FEC cuyo LSR de salida es el LSR que asignó la etiqueta que ahora está en la segunda posición en la pila. Consideremos el conjunto de nodos que pudieran ser el LSP de entrada para una FEC F. Entonces hay un LSP para la FEC F que empieza con cada uno de esos nodos. Si alguno de esos LSPs tiene el mismo LSP de salida, entonces podríamos considerar que el conjunto de esos LSPs forma un árbol, cuya raíz es el LSP de salida. Podríamos entonces hablar de un árbol LSP para una FEC F. Extracción en el penúltimo salto: Si <R1,...,Rn> es un LSP de nivel m para el paquete P, P puede ser transmitido desde Rn-1 a Rn con una pila de etiquetas de profundidad m-1. Se puede extraer de la pila de etiquetas en el penúltimo LSR del LSP, en vez de en el LSP de salida [RFC3301].. 28.

(29) IEM-II-2003-04 Desde una perspectiva arquitectónica, esto es apropiado. El propósito de la etiqueta de nivel m es hacer llegar el paquete a Rn. Una vez que Rn-1 ha decidido mandar el paquete a Rn, la etiqueta ya no tiene ninguna funcionalidad y por tanto no es necesario transportarla. La extracción en el penúltimo salto tiene una ventaja: si no se hace, cuando el LSP de salida reciba el paquete, éste mirará la etiqueta de la cima de la pila y determinará que es el LSP de salida. Entonces deberá hacer una extracción de la pila y examinar lo que quede del paquete. Si hubiera otra etiqueta en la pila, el LSP de salida miraría esta etiqueta y reenviaría el paquete basándose en la información que ha obtenido. (En este caso, el LSP de salida para el paquete del LSP de nivel m es también un nodo intermedio para un LSP de nivel m-1). Si no hubiera etiquetas en la pila, entonces se reenviaría el paquete utilizando la dirección de destino del nivel de red. Esto obliga a que el LSR de salida haga dos consultas: bien dos consultas de etiquetas o una consulta de etiqueta seguido de una consulta de dirección. Con esta técnica, el LSR de salida sólo tiene que hacer una consulta y requiere que el penúltimo nodo haga una consulta. La creación del "camino rápido" del reenvío en un producto de conmutación de etiquetas puede ser muy favorecedor si se sabe que sólo requerirá una consulta: Se puede simplificar el código si se asume que sólo se necesitará una consulta. Se puede basar el código en un "presupuesto de tiempo" que asuma que sólo se necesitará una consulta. De hecho, cuando se usa la extracción en el penúltimo salto, el LSP de salida puede incluso no ser un LSR.. 29.

(30) IEM-II-2003-04 No obstante, algunos motores hardware de conmutación pueden no ser capaces de extraer de la pila de etiquetas, por lo que esto no puede ser requerido universalmente. También pueden haber situaciones en las que no es deseable la extracción en el penúltimo salto. Por tanto, el penúltimo nodo extraerá la etiqueta de la pila de etiquetas si el LSR de salida se lo pide explícitamente, o si el siguiente nodo en el LSP no soporta MPLS. (Si el siguiente nodo en el LSP no soporta MPLS, y no hace tal petición, el penúltimo nodo no tendrá manera de saber que es el penúltimo nodo). Un LSR que es capaz de extraer de la pila de etiquetas deberá realizar la extracción en el penúltimo salto cuando se lo pida el LSR del mismo nivel (su "igual" o peer) que está río abajo. Las negociaciones iniciales del protocolo de distribución de etiquetas deben permitir a cada LSR determinar si sus LSRs vecinos son capaces de extraer de la pila de etiquetas. Un LSR no le debe pedir a su "igual" de distribución de etiquetas que extraiga de la pila de etiquetas a no ser que sea capaz de hacerlo. Un nodo de salida siempre podrá interpretar la etiqueta de la cima de un paquete recibido cuando se utiliza la extracción en el penúltimo salto si se cumplen las reglas de alcance y unicidad expuestas en el apartado anterior.. 2.7 PROTOCOLOS DE DISTRIBUCIÓN DE ETIQUETAS A medida que se crean y destruyen asociaciones de etiquetas, los LSRs deberán notificarlo a sus vecinos. Para este propósito se utilizan los protocolos de distribución de etiquetas.. 30.

(31) IEM-II-2003-04 La arquitectura MPLS define el protocolo de distribución de etiquetas como el conjunto de los procedimientos gracias a los cuales un LSR le informa a otro del significado de las etiquetas usadas para reenviar el tráfico a través de ellos. La arquitectura no impone ningún protocolo específico para la distribución de etiquetas. De hecho se están normalizando distintos protocolos de distribución de etiquetas. A grandes rasgos se puede distinguir entre los protocolos nuevos definidos exclusivamente para la distribución de etiquetas y los que incorporan la etiqueta encima de protocolos existentes de encaminamiento. Las desventajas de utilizar protocolos nuevos de distribución de etiquetas son la dificultad de evitar las condiciones de carrera y el hecho de estar añadiendo más mensajes en el sistema, por lo que aumenta su complejidad. La ventaja de utilizar protocolos nuevos de distribución de etiquetas es poder dar soporte a dicha distribución de etiquetas.. 2.8 PROTOCOLOS DE ESTADO DURO (HARD-STATE) Y PROTOCOLOS DE ESTADO BLANDO (SOFT-STATE) Protocolos de estado blando: Con este tipo de protocolos si no se reciben los mensajes de actualización (update) o refresco de la información de estado, se marcará dicho estado como no válido y se descartará la información. Estos protocolos son adecuados en entornos no fiables. El protocolo de reserva de recursos RSVP (Resource ReSerVation Protocol) es un protocolo de estado blando. Protocolos de estado duro: En ausencia de eventos que disparen una respuesta del protocolo, el estado del protocolo permanecerá sin cambio alguno durante un periodo de tiempo ilimitado. La información de estado deberá cambiarse explícitamente. Este tipo de protocolos requieren una total fiabilidad y por tanto no es de extrañar que la mayoría de estos protocolos se basen en el protocolo 31.

(32) IEM-II-2003-04 de control de transmisión TCP (Transmisión Control Protocol). Como es sabido, TCP es un protocolo fiable orientado a conexión.BGP (Border Gateway Protocol: Protocolo de pasarela externa) y LDP utilizan TCP. BGP: BGP es un protocolo de encaminamiento usado entre sistemas autónomos. Está siendo utilizado ampliamente para conectar grandes redes de proveedores. El protocolo utiliza mensajes que se envían utilizando conexiones TCP. Los distintos tipos de mensajes que maneja este protocolo son: Open: se utiliza para establecer una relación de vecindad con otro enrutador. Actualización (Update): se utiliza para transmitir información a través de una ruta y/o enumerar múltiples rutas que se van a eliminar. Mantenimiento (Keepalive): utilizado para confirmar un mensaje Open y para confirmar periódicamente la relación de vecindad. Notificación: este tipo de mensajes se envían cuando se detecta una condición de error. Los procedimientos funcionales de BGP son: Adquisición de vecinos: ocurre cuando dos enrutadores situados en diferentes sistemas autónomos se ponen de acuerdo para intercambiar información de encaminamiento regularmente. Un enrutador le enviará a otro un mensaje Open. Si el destino acepta la solicitud le devolverá un mensaje de mantenimiento. Detección de vecino alcanzable: una vez realizada la adquisición de vecinos se utiliza este procedimiento para mantener la relación. Periódicamente ambos dispositivos de encaminamiento se envían mensajes de mantenimiento para asegurarse que su par sigue existiendo y desea continuar con la relación de vecindad.. 32.

(33) IEM-II-2003-04 Detección de red alcanzable: cada enrutador mantiene una base de datos con las redes que puede alcanzar y la ruta preferida para alcanzar dichas redes. Cuando se realiza un cambio a esta base de datos, el enrutador enviará un mensaje de actualización por difusión. De esta forma el resto de los enrutadores BGP podrán construir y mantener la información de encaminamiento. MPLS-BGP En MPLS se puede utilizar BGP para distribuir la información de asociación de etiquetas para cada ruta que se anuncie. Esto es posible gracias a las extensiones multiprotocolo (MPEs: Multiprotocol Extensions) de BGP versión 4 [RFC2283]. Para distribuir las etiquetas se utilizan los mensajes de actualización (utilizando piggybacking), los cuales también se utilizan para distribuir la información de las rutas. La etiqueta se codifica en el campo NLRI (Network Layer Reachability Information: información de alcanzabilidad del nivel de red) y para indicar que el campo NLRI contiene una etiqueta, se utiliza el campo SAFI (Subsequent Address Family Identifier: identificador de familias de direcciones consecutivas). Un hablante BGP no podrá utilizar BGP para la distribución de etiquetas hacia un igual a no ser que dicho igual le indique que puede procesar mensajes de actualización con el campo SAFI especificado. Ventajas de la utilización de MPLS-BGP: Si dos LSRs adyacentes también son hermanos BGP (peers), entonces la distribución de etiquetas se puede realizar sin necesidad de tener otro protocolo de distribución de etiquetas. Supongamos una red con dos clases de LSRs: LSRs exteriores, que hacen de interfaz con otras redes, y LSRs interiores, los cuales sólo transmiten tráfico entre los LSRs exteriores. Si los LSRs exteriores también son hablantes BGP y distribuyen etiquetas MPLS con la información de encaminamiento, entonces los. 33.

(34) IEM-II-2003-04 LSRs interiores no necesitan recibir ninguna de las rutas BGP de los hablantes BGP. Las etiquetas se transportan como parte del campo NRLI en los atributos de extensión multiprotocolo. El AFI indica la familia de direcciones de la ruta asociada. Si el campo NLRI contiene una etiqueta, se le dará un valor de cuatro al campo SAFI para identificar esta situación. LDP El protocolo de distribución de etiquetas LDP (Label Distribution Protocol) se ejecuta sobre TCP, por tanto, es un protocolo de estado duro. Dado que se ejecuta sobre TCP, éste le proveerá de fiabilidad en el envío de mensajes. La definición según [RFC3036] es la siguiente: el protocolo de distribución de etiquetas es el conjunto de procedimientos mediante los cuales un LSR se comunica con otro para notificarle el significado de las etiquetas para reenviar el tráfico entre ellos. El uso más sencillo de LDP consiste en establecer enlaces unitarios de LSPs. Para hacer esto se puede usar la distribución de etiquetas río abajo no solicitado o río abajo por demanda y es compatible con el control ordenado y con el control independiente. Se podrá usar el modo de retención de etiquetas conservador o el liberal. Pero habrá combinaciones no factibles. Si los LSRs vecinos utilizan la distribución de etiquetas río abajo no solicitado y el LSR local utiliza el modo conservador de retención de etiquetas, habrá mucho tráfico de liberación de etiquetas. Si los LSRs vecinos utilizan la distribución de etiquetas río abajo por demanda y el LSR local utiliza el modo liberal de retención de etiquetas habrá mucho tráfico de petición de etiquetas. LDP es un protocolo muy útil para los casos en los que se desea establecer un LSP a través de LSRs que no soporten piggybacking (básicamente esta es la única ventaja de LDP). LDP es bidireccional y podrá operar entre LSRs adyacentes o no adyacentes.. 34.

(35) IEM-II-2003-04 El protocolo de distribución de etiquetas asocia una FEC con cada LSP que crea. Dos LDPs serán pares LDP (LDP peers) cuando ambos LSRs intercambien información de asociaciones de etiquetas y FECs. Para intercambiar dicha información establecerán una sesión LDP. Identificadores LDP Un identificador LDP se utiliza para identificar el espacio de etiquetas de un LSR. Se compone de seis octetos, de los cuales los cuatro primeros identifican al LSR y los dos últimos identifican el espacio de etiquetas de dicho LSR. El espacio de etiquetas puede ser por interfaz o por plataforma. Si los dos últimos octetos tienen un valor de cero el espacio de etiquetas será por plataforma. Sesión LDP Cuando un LSR utiliza LDP para anunciar más de un espacio de etiquetas a otro LSR, utilizará diferentes sesiones LDP para cada espacio de etiquetas. LDP utiliza TCP. Cuando dos LSRs requieren múltiples sesiones LDP, se establecerán sesiones TCP distintas para cada sesión LDP.. RSVP El protocolo de reserva de recurso (RSVP: Resource reSerVation Protocol, Protocolo de Reserva de Recursos) se utiliza para reservar recursos para una sesión en un entorno de red IP. Es un protocolo de estado blando. RSVP pretende proporcionar calidad de servicio estableciendo una reserva de recursos para un flujo determinado. Un host hace una petición de una calidad de servicio específica sobre una red para un flujo particular de una aplicación. Características de RSVP Se diseña para trabajar con cualquier servicio de QoS (los objetos propios de la QoS no están definidos por el protocolo). Permite Unicast y Multicast. No es un protocolo de encaminamiento, sino que está pensado para trabajar conjuntamente con éstos. No transporta datos de usuario. 35.

(36) IEM-II-2003-04 Los protocolos de encaminamiento determinan dónde se reenvían los paquetes mientras que RSVP se preocupa por la QoS de los paquetes reenviados de acuerdo con el enrutamiento. Es un protocolo simplex: petición de recursos sólo en una dirección, diferencia entre emisor y receptor. El intercambio entre dos sistemas finales requiere de reservas diferenciadas en ambas direcciones. Reserva iniciada por el receptor (protocolo orientado al receptor). Mantenimiento del estado de la reserva (estado blando) en los enrutadores. El mantenimiento de la reserva es responsabilidad de los usuarios finales. Permite diferentes tipos de reservas. Protocolo transparente para los enrutadores no RSVP. Soporta IPv4 e IPv6 aunque no sea un protocolo de transporte. Existen dos tipos fundamentales de mensajes RSVP: Mensajes Path: estos mensajes los generan los emisores. Describen el flujo del emisor y proporcionan la información del camino de retorno hacia el emisor. Este mensaje lo utilizan los emisores para establecer el camino de la sesión. Estos mensajes pueden atravesar enrutadores que no entiendan RSVP puesto que tienen una dirección IP origen y una dirección IP destino. Mensaje Resv: estos mensajes los generan los receptores y sirven para hacer una petición de reserva de recursos. Crean el "estado de la reserva" en los enrutadores. Generalmente, una petición de recursos implicará una reserva de éstos en todos los nodos del camino del flujo de datos. Estos mensajes siguen exactamente el camino inverso al de los datos.. 36.

(37) IEM-II-2003-04 CR-LDP Antes de desarrollar CR-LDP (Constraint-based Routing LDP: encaminamiento basado en restricciones LDP) conviene aclarar lo que se entiende por encaminamiento basado en restricciones. Encaminamiento basado en restricciones: Con el encaminamiento convencional, es decir, con IP, la elección de un camino se basa en algún algoritmo que optimice alguna métrica escalar. Por ejemplo, con RIP la métrica que se usa es el número de saltos. RIP elige el camino que minimice el número de saltos. Con el encaminamiento basado en restricciones, entre cada par de nodos se deberán satisfacer una serie de restricciones. Las restricciones entre nodos diferentes podrán ser diferentes. Por supuesto, además de satisfacer dichas restricciones, también existirá una métrica particular como sucedía en el encaminamiento. convencional.. Una. vez. establecido. el. camino,. el. encaminamiento basado en restricciones será el responsable de establecer y mantener el estado del reenvío a través de dicho camino. Las restricciones podrán ser de rendimiento, calidad de servicio como retardo, variación de retardo o tasa de pérdidas, administrativas o una mezcla entre ellas. El grupo de trabajo sobre MPLS del IETF ha definido extensiones para que el protocolo LDP soporte el encaminamiento basado en restricciones. A esta extensión del protocolo se le denomina CR-LDP. Cuando un LSR de entrada decide usar un camino explícito, añadirá la TLV ER (Explicit Route TLV: TLV de camino explícito) al mensaje LDP de petición de etiquetas. El uso de esta TLV para establecer un LSP requiere el uso de la distribución de etiquetas río abajo por demanda y el modo de control ordenado. Cada LSR enviará el mensaje de petición de etiquetas a través del camino especificado en dicha TLV. Cuando el mensaje llegue al LSR de salida, éste responderá con un mensaje de asociación de etiquetas, donde habrá incluido la 37.

(38) IEM-II-2003-04 etiqueta de la asociación. Estos mensajes se van enviando hacia el LSR de entrada por el camino inverso por donde se mandaron los mensajes de asociación de etiquetas. Por supuesto, en cada nodo se realizará la correspondiente asociación incluyéndose la etiqueta en el mensaje que se envía río arriba. Cuando al LSR de entrada le llegue un mensaje de asociación de etiquetas para una etiqueta pedida, el LSP estará establecido. Para la reserva de recursos en el LSP se ha definido un nuevo objeto: el objeto de parámetro de tráfico. Actualmente hay definidos siete parámetros de tráfico: Peak data Rate (PDR: velocidad de pico de datos) Peak burst size (PBS: tamaño de pico de la ráfaga) Commited data rate (CDR: velocidad de datos garantizada) Commited burst size (CBS: tamaño de ráfagas garantizada) Excess burst size (EBS: tamaño de la ráfaga en exceso) Frequency (frecuencia) Weight (peso) Las limitaciones de CR-LDP en la actualidad son las siguientes [RFC3213]: Sólo soporta LSPs punto a punto. Sólo soporta el establecimiento unidireccional de LSPs. Sólo soporta una única etiqueta por LSP. Lógicamente, se está trabajando para encontrar soluciones a las presentes limitaciones. 38.

(39) IEM-II-2003-04. 3. DISEÑO Y EVALUACION DE LAS REDES CON Y SIN MPLS La simulación de la Red MPLS ha sido implementada con el software Network Simulator(NS)versión 2.26b, bajo el sistema operativo LINUX SuSe 8.2, el propósito de estas simulaciones es proporcionar un modelo bajo el protocolo MPLS que garanticé calidad de servicio QoS, permitiendo aprovechar las posibilidades de de este mismo y garantizar parámetros globales de red como anchos de banda, retardos, utilización, etc. La arquitectura de un nodo MPLS en NS, consiste de agentes y clasificadores. Un agente es el. que envía/recibe. objetos del protocolo, el clasificador es el responsable de la clasificación de paquetes para el envió de estos mismos al siguiente nodo. Para nuestro caso un Nodo MPLS, un clasificador MPLS y un agente LDP son insertados dentro del nodo IP. En la figura 7. Se muestra la arquitectura de un nodo MPLS con NS-2.. Figura 7. Arquitectura de un nodo MPLS en NS 5 3 4. 961 0 0. 7 5. 065. 43. 39. 5 5. 5 4 5 5. 5 6.

(40) IEM-II-2003-04 ‘Node entry’ Es el punto de entrada del nodo. Es el primer elemento que maneja los paquetes en el nodo. ‘Entre_’ almacena lo referente a este elemento. El ‘MPLS Classifier’, el cual es el primero en clasificar si el paquete esta o no esta etiquetado, el ‘Clasifier_’almacena lo referente al clasificador de MPLS, el ‘Addr Classifier’ es el responsable de enviar los paquetes de acuerdo alas direcciones IP de destino y por último el ‘Port Clasifier’ es el responsable de seleccionar un agente.. Un nodo MPLS hace el manejo de tres tablas de información relacionadas con un LSP; una tabla de envío Parcial (PFT Partial Forwarding Table), una basada en la Información de etiqueta (LIB Label Information Base) y una basada enla información explicita de enrutamiento (ERB Explicit Routing information Base); al figura 8 muestra la estructura de estas tres tablas y un algoritmo para el envio de paquetes. El ‘LIBptr’ es un puntero hacia el punto de entrada LIB.. Figura 8. Estructura de tablas para la conmuitación de paquetes MPLS 3 4. 5 5. 961 0 0. 7 065. 43 40. 5 5. 5 4 5 5. 5 6.

(41) IEM-II-2003-04 La creación de la red MPLS conlleva las siguientes características:. 3.1 TOPOLOGIAS DE RED La Figura 9 muestra las redes experimentales que se usaron en las simulaciones.. TOPOLOGIA 1. 41.

(42) IEM-II-2003-04. TOPOLOGIA 2. TOPOLOGIA 3 Figura 9. Topologías de red a simular con y sin MPLS 42.

(43) IEM-II-2003-04 La primera topología nos describe los nodos 0,1,2,3,15,14,13,12,11 como nodos IP; los demás nodos 4,5,6,7,8,9 y 10 son nodos MPLSo nodos LSRs, cuatro nodos fuentes y 4 nodos destinos, además basado en esquemas del camino más corto, tres rutas de paquetes que son LSR 4_5_8_9, LSR 4_7_9 y LSR4_6_10_9. La segunda topología trae los nodos 0,1,9,10 como nodos IP y los otros nodos 2,3,4,5,6,7 y 8 nodos MPLS o LSR. Por último la topología tres que contiene nodos 0 y 4 como nodos IP y los demás nodos 1,2 y 3 LSRs.. 3.2 ESTRUCTURA DE LA RED MPLS UTILIZANDO NS-2 Las siguientes instrucciones se deben tener en cuenta para la creación de la Red MPLS. - crear una simulación de objeto set ns [new Simulator] - creacion de los nodos IP y MPLS set node0 [$ns node] set LSR4 [$ns MPLSnode] set LSR5 [$ns MPLSnode] set node15[$ns node] - Configurar todos los nodos como agentes LDP $ns configure-Idp-on-all-rnpLs-nodes - Habilitar el manejo del control, envío y demanda $ns enable-control-driven $ns enable-data-driven $ns enable-on-demand - envió de mensajes LDP , mapeo y flujo agregado $MPLSnode send-ldp-release-msg $fec $MPLSnode send-ldp-withdraw-msg $fec 43.

(44) IEM-II-2003-04 $MPLSnode aggregate-flows $fec1 $fec2 - Creación de los enlaces entre los nodos $ns duplex-link $node0 $LSR5 10Mb 10ms DropTail - Instalación de tráfico y su conexión a UDP set udp [new Agent/UDP] $ns attach-agent $node $udp - Creación Fuentes de tráfico a nodos destinos set src0 [attach-expoo-traffic $node0 $sink0 200 0 0.0060 300800k] - Configuración de CBQs - $qlim: tamaño de la cola en paquetes - $cbc: tipo de objeto de cola - $okborrow: Indicador booleano que indica el ancho de banda pemitido - $bw $maxidle: la máxima cantidad de tiempo de clase requerida - $extradelay: retardo de clase $ns cfg-cbq-for-HBTS $qlim $cbq_qtype $okborrow $bw $maxidle $extradelay $ns bind-flowid-to-SBTS $id1 [$id2] $ns bind-flowid-to-HBTS $id1 [$id2] $ns bind-flowid-to-STS $id1 [$id2] $ns bind-ldp-to-SBTS $ns bind-ldp-to-HBTS $ns bind-ldp-to-STS $MPLSnode setup-crlsp $fec $er $lspid $TRate $BSIze $PSize $SPrio $HPPrio -Creación de rutas $ns at [expr [$ns now]] "[$LSR4 get-module MPLS] make-explicit-route 9 4_6_10_9 $k -1"; $ns at [expr [$ns now]+0.11] "[$LSR4 get-module MPLS] flow-erlsp-install 12 -1 $k" -otros parámetros - $fec: valor dela fec 44.

(45) IEM-II-2003-04 - $er: ruta explicita - $lspid: valor del LSPID - $TRate: Valor de la tasa de tráfico - $BSize: Valor del tamaño del buffer - $PSize: Valor del tamaño del paquete - $SPrio: valor del prioridad del menú - $HPrio: valor de prioridad alta - Envió de mensajes CRLDP $MPLSnode send-crldp-release-msg $lspid $MPLSnode send-crldp-withdraw-msg $status $lspid $tr - Definición y llamado de procedimientos Enrutamientos, registros, tráfico y final - trazo de los paquetes de MPLS $MPLSnode trace-mpls - trazo de los paquetes LDP en un nodo MPLS $MPLSnode trace-ldp - visualizar la tabla PFT, ERB y LIB $MPLSnode pft-dump $MPLSnode erb-dump $MPLSnode lib-dump - Color para los mensajes $ns ldp-request-color $color - Mapeo de un mensaje $ns ldp-mapping-colo $color $ns ldp-withdraw-color $color $ns ldp-release-color $color $ns ldp-notification-color $color 45.

(46) IEM-II-2003-04. La tabla 1, muestra los valores de los enlaces entre nodos IP y los nodos MPLS .. TABLA1. VALORES USADOS EN LA SIMULACIÓN PARA LOS NODOS IP-MPLS TIPO TOPOLOGIA 1 Enlaces Ancho de banda Retardo Tipo de cola TOPOLOGIA 2 Enlaces Ancho de banda Retardo Tipo de cola TOPOLOGIA 3 Enlaces Ancho de banda Retardo Tipo de cola. VALOR Dobles 10Mb 10ms DropTail Dobles 1Mb 10ms DropTail Dobles 2Mb y 1Mb 10ms DropTail. La tabla 2 muestra los valores utilizados para cada conexión entre los nodos MPLS ó LSRs.. TABLA 2. VALORES UTILIZADOS EN LA SIMULACIÓN ENTRE NODOS MPLS Ó LSR Y CON NODOS IP TIPO VALOR TOPOLOGIA 1 Enlaces Ancho de banda. Dobles 0.5Mb 1.5Mb LSR 5-7 0.1Mb LSR 6-7 0.6Mb LSR 9-7 1Mb LSR 9-nodo IP destino 10ms DropTail. Retardo Tipo de cola TOPOLOGIA 2 Enlaces Ancho de banda Retardo Tipo de cola. Dobles 1Mb 10ms DropTail. 46.

(47) IEM-II-2003-04 TOPOLOGIA 3 Enlaces Ancho de banda Retardo Tipo de cola. Dobles 1Mb 10ms CBQ. Lo siguiente es el llamado de los procedimientos tales como de finalización y grabación; el tipo de tráfico que se generó para las simulaciones es una mezcla de tráfico en tiempo real, tráfico constante. CBR (Constant Byte Rate), tráfico. exponencial y tráfico UDP(User Datagram Protocol) , que pueden simular el tráfico de voz a una tasa de 256 Kbps y tráfico IP. El tráfico es generado desde las fuentes cada determinado tiempo, por ejemplo para la topología numero 1. en la simulación cada proceso se genera desde las fuentes cada 0.01 Seg., se registra cada procedimiento cada 0.1 seg., los procedimientos de enrutamientos se graban cada 0.2 seg. y el tiempo simulación total es de 3, 4 y 5 seg. para cada topología.. 47.

(48) IEM-II-2003-04. 4. RESULTADOS Y ANALISIS DE LA SIMULACIÓN. Los primeros gráficos y datos obtenidos en la simulación, hacen referencia a la topología 1. primero se obtiene el monitor de cola (LM), este gráfico indica la cantidad de Bytes que llegan por segundo al nodo destino(12) a través del nodo LSR9 con una frecuencia de 0.1seg de muestreo.. Las figuras 10 y 11 que corresponden al monitor de cola primero simulada la red con MPLS y por consiguiente la red sin MPLS.. Figura 10. Monitor de Cola con MPLS. 48.

(49) IEM-II-2003-04. Figura 11. Monitor de cola de la red sin MPLS Las figuras 12 y 13 representan la utilización de los siguientes enlaces: Q11: enlace entre LSR 4-5 Q12: enlace entre LSR 5-8 Q13: enlace entre LSR 8-9 Q21: enlace entre LSR 4-7 Q22: enlace entre LSR 4-5 Q31: enlace entre LSR 4-5 Q32: enlace entre LSR 4-5 Q33: enlace entre LSR 4-5 Q1=Q11+Q12+Q13 Q2=Q21+Q22 Q3=Q31+Q32+Q33. 49.

(50) IEM-II-2003-04. Figura 12. Monitor de bytes ruta Q1,Q2 y Q3 con MPLS Esta gráfica es muy importante pues es la que representa el balanceo de carga que se hace cuando se hace uso de MPLS, después de un pico en la ruta Q1, las rutas Q2 y Q3 balancean las cargas.. Figura 13. 10 Monitor de bytes ruta Q1,Q2 y Q3 sin MPLS 50.

(51) IEM-II-2003-04 Como conclusión de la gráfica, se puede decir que la ruta Q2 se proyecta por la congestión de paquetes, las rutas Q1 y Q3 permanecen sin congestión, ya que la ruta Q2 es el camino más corto, por lo tanto no hay balanceo de cargas.. Los promedios obtenidos fueron recolectados al final de la simulación sobre las rutas y son los siguientes: TABLA 3. PROMEDIOS DE PAQUETES ENTRE LOS ENLACES RUTA. CON MPLS(BytesX103). SIN MPLS(BytesX103). Q1. 665,20=3326 paquetes. 52,94=265 paquetes. Q2. 2982,10=14910 paquetes. 24149,10=120745 paquetes. Q3. 990,12= 4951 paquetes. 76,54=383 paquetes. Ahora se observan los anchos de banda de la Red con y sin MPLS; es necesario aclarar la sintaxis para la observación de las graficas:. BWM11— Enlace entre los nodos LSR 4-5 BWM12— Enlace entre los nodos LSR 5-8 BWM13— Enlace entre los nodos LSR 8-9 BWM21— Enlace entre los nodos LSR 4-7 BWM22— Enlace entre los nodos LSR 7-9 BWM31— Enlace entre los nodos LSR 4-6 BWM32— Enlace entre los nodos LSR 6-10 BWM33— Enlace entre los nodos LSR 10-9. La figura 14 corresponde a la utilización de los enlaces de red con MPLS esta dado en bps y con frecuencia de muestreo de 0.1Seg.. 51.

(52) IEM-II-2003-04. Figura 14. Utilización de los canales de Q11, Q12 y Q13 con MPLS Los gráficos 15 y 16 muestran la utilización de los enlaces, es decir los enlaces LSR4 -7 y LSR7-9.. Figura 15. Anchos de banda de Q21 y Q22 con MPLS 52.

(53) IEM-II-2003-04. Figura 16. Anchos de banda de Q21 y Q22 sin MPLS. Así mismo el gráfico 17 muestra el enlace restante, para los LSR4-6, LSR6-10 y LSR10-9.. Figura 17. Anchos de banda Q31, Q32 y Q33 con MPL 53.

(54) IEM-II-2003-04 Los promedios de cada uno de los enlaces se detallan en la siguiente tabla:. TABLA 4. PROMEDIOS DE UTILIZACIÓN DE CADA ENLACE ENLACE. CON MPLS (bps). SIN MPLS(bps). Q11. 7489888. 158. Q12. 12294400. 14856. Q13. 386212. 235314. Q21. 295877. 509787. Q22. 571678. 761078. Q31. 63482. 126. Q32. 63458. 89. Q33. 334542. 509787. Por último se tienen la perdida de paquetes, los gráficos 18 y 19 representan la perdida de paquetes, el interés se centra en los enlaces LSR4-7 y LSR7-9 pues en los otros enlaces para la red con MPLS no hay perdidas en ninguno de los enlaces, mientras que la red sin MPLS en los otros enlaces no presenta perdida pero para los enlaces LSR4-7 y LSR7-9 sí, como se muestra a continuación.. 54.

(55) IEM-II-2003-04. Figura 18. Perdida de paquetes en Q21 y Q22 con MPLS. Figura 19. Perdida de paquetes en Q21 y Q22 sin MPLS La Media de paquetes perdidos para la Red sin MPLS es de 6 paquetes. Una muestra de la simulación de la red con y sin MPLS, generada por el Network Simulator y ejecutada en NAM se observa a continuación: 55.

(56) IEM-II-2003-04 Los siguientes cuadros ilustran en determinados tiempos como transcurre la simulación de la red con MPLS. En la figura 20 se observa el comienzo de la simulación y los mensajes LDP, la figura 21 ilustra el tráfico de paquetes entre los nodos MPLS o LSR, la figura 22 muestra unas colas de paquetes en los LSR 7, 8 y 10. La figura 23 se observa el enrutamiento por el nodo LSR 4_5 y una cola en el LSR 7 pero sin perdida.. Figura 20 Tiempo: 0160000 seg. De simulación.. Figura 21. Tiempo: 0.872000 seg. Tráfico de paquetes. 56.

(57) IEM-II-2003-04. Figura 22. Tiempo: 1.76400seg. Flujo de tráfico y colas en las nodos 7,8 y 10.. Figura 23. Tiempo: 2.72000seg. Enrutamientos establecidos entre los nodos de acuerdo a los requerimientos de los mensajes LSP. Subsecuentemente, la simulación de la red sin MPLS se observa en las siguientes figuras.. 57.

(58) IEM-II-2003-04. Figura 24. Tiempo: 0.160000Seg. De simulación.. Figura 25. Tiempo: 0.873379Seg. Flujo de tráfico solo en los nodos 4_7_9.. 58.

(59) IEM-II-2003-04. Figura 26. Tiempo: 2.725379Seg. Acumulación de paquetes en los nodos 4 y 7.. Figura 27. Tiempo: 1.745379Seg. Perdida de paquetes en los nodos 4 y 7.. 59.

(60) IEM-II-2003-04 La topología 2, los cuadros muestran como se desarrolla la simulación paso a paso, el primer cuadro figura 28. Muestra el inicio de la simulación los LDP Mapping Messages son enviados para la etiqueta de control y distribución.. Figura 28. Tiempo: 0.01Seg. LDP mapping Messages La Figura 29, es el resultado de pues cada LSR es establecido en toda la red. Figura 29. Tiempo 0.15Seg. Establecimiento de LSR. Luego de hacer la operación Swap y establecer las FECs la figura 30 describe los requerimientos de mensajes CR-LDP, para crear los ER-LSP o rutas explicitas entre los LSRs.. 60.

(61) IEM-II-2003-04. Figura 30. Tiempo 0.70Seg. Mensajes CR-LDP para crear ER-LSP.. Los anchos de banda que muestran la Figura 31, demuestra después de configurarse las CR-LDP el balanceo de cargas hace que la Calidad de Servicio mejorando el desempeño de la red.. Figura 31. Anchos de banda Topología 2.. 61.

(62) IEM-II-2003-04 La topología 3, Se estableció para la comparación con el trabajo realizado por Gaeil Ahn y Woojik Chun, hace referencia a tres clases de nivel y cuatro tipos de servicio (ST, RT, HBT y SBT) Figura 32, se configuran por medio del tipo de cola CBQ, es decir dando prioridades. Se distribuyo de la siguiente manera, SBT(simple Best-effort Traffic), HBT (High Priority Best-effort Traffic) y dos RT (Real time Traffic). SBT y HBT están generando tráfico CBR a 250Kbit/s, RT1 Y RT2 generan tráfico CBR a 350Kbit/s y 459 Kbit/s respectivamente. Figura 32. Nivel de clases en NS Fuente: Gaeil Ahn, Woojik Chun. Desig and Impletantion of MPLS Network Simulator.pdf. Se creo el código para la simulación en NS-2 y con los parámetros establecidos según el Gaeil y Chun se obtuvo lo siguiente: la figura 33 muestra la topología de red.. 62.

(63) IEM-II-2003-04. Figura 33. Comienzo simulación topología 3. La figura 34. Muestra que el total del ancho de banda entre los 11Seg. y 30 Seg. Es casi igual al ancho de banda del enlace, es decir, la eficiencia del enlace es muy alta. RT1 y RT2 pueden obtener el ancho de banda requerido, SBT y HBT usan el resto de ancho de banda del enlace y HBT sirve mejor que SBT. Con esta simulación podemos validar que no hay errores en los procesos de simulación y toma de muestras de las otras topologías a simular.. Figura 34. Variación del Ancho de banda en la topología 3 63.

(64) IEM-II-2003-04 La figura 35, describe un esquema con prioridades RT1 tiene mas alta prioridad que RT2, a los 11seg. RT1 sirve como tráfico de Mejor esfuerzo, HBT, SBT y RT1 utilizan el resto del enlace, pero HBT es mejor que SBT y RT1.. Figura 35. Variación del Ancho de banda en la topología 3. TABLA 5. TABLA DE RESULTADOS TOPOLOGIA 1. CON MPLS. SIN MPLS. PAQUETES ENVIADOS. 636. 636. PAQUETES RECIBIDOS. 636. 481. PAQUETES PERDIDOS %. 0%. 24.37%. RETARDO. 0.0828 seg.. 0.3788 seg. JITTER. 0.06002 ms.. 15.910 ms.. 2.45 Mbps. 537.218 Kbps. THROUGHPUT. 64.

(65) IEM-II-2003-04 TOPOLOGIA 2. CON MPLS. PAQUETES ENVIADOS. 190. PAQUETES RECIBIDOS. 190. PAQUETES PERDIDOS %. 0%. RETARDO. 0.07758 seg.. JITTER. 208.737 µs.. THROUGHPUT. 489 Kbps. TOPOLOGIA 3. CON MPLS. PAQUETES ENVIADOS SBT. 3733. HBT. 4904. RT1. 8530. RT2. 5343 Total = 26060. PAQUETES RECIBIDOS. 22510. PAQUETES PERDIDOS %. 13.62%. RETARDO. 0.06598seg.. JITTER. 208.737 µs.. THROUGHPUT. 280.89 Kbps. 65.

Referencias

Documento similar

If certification of devices under the MDR has not been finalised before expiry of the Directive’s certificate, and where the device does not present an unacceptable risk to health

In addition to the requirements set out in Chapter VII MDR, also other MDR requirements should apply to ‘legacy devices’, provided that those requirements

The notified body that issued the AIMDD or MDD certificate may confirm in writing (after having reviewed manufacturer’s description of the (proposed) change) that the

Cedulario se inicia a mediados del siglo XVIL, por sus propias cédulas puede advertirse que no estaba totalmente conquistada la Nueva Gali- cia, ya que a fines del siglo xvn y en

Products Management Services (PMS) - Implementation of International Organization for Standardization (ISO) standards for the identification of medicinal products (IDMP) in

Products Management Services (PMS) - Implementation of International Organization for Standardization (ISO) standards for the identification of medicinal products (IDMP) in

This section provides guidance with examples on encoding medicinal product packaging information, together with the relationship between Pack Size, Package Item (container)

Package Item (Container) Type : Vial (100000073563) Quantity Operator: equal to (100000000049) Package Item (Container) Quantity : 1 Material : Glass type I (200000003204)