UNIVERSIDAD SIMÓN BOLÍVAR Decanato De Estudios Profesionales Coordinación De Ingeniería Electrónica

Transcripción

1 UNIVERSIDAD SIMÓN BOLÍVAR Decanato De Estudios Profesionales Coordinación De Ingeniería Electrónica ESTUDIO Y PRUEBAS DEL COMPORTAMIENTO DE LOS MECANISMOS DE RESERVA EN UNA RED MPLS Por Rocy Y. Martínez Marciales Sartenejas, Abril de 2008

2 UNIVERSIDAD SIMÓN BOLÍVAR Decanato De Estudios Profesionales Coordinación De Ingeniería Electrónica ESTUDIO Y PRUEBAS DEL COMPORTAMIENTO DE LOS MECANISMOS DE RESERVA EN UNA RED MPLS Por Rocy Y. Martínez Marciales Realizado con la asesoría de Prof. Mónica Huerta (Universidad Simón Bolívar) Prof. Xavier Hesselbach Serra (Universidad Politécnica de Cataluña) INFORME FINAL DE CURSOS EN COOPERACIÓN TÉCNICA Y DESARROLLO SOCIAL Presentado ante la Ilustre Universidad Simón Bolívar como requisito parcial para optar al título de Ingeniero Electrónico Sartenejas, Abril de 2008

3 UNIVERSIDAD SIMÓN BOLÍVAR Decanato De Estudios Profesionales Coordinación De Ingeniería Electrónica ESTUDIO Y PRUEBAS DEL COMPORTAMIENTO DE LOS MECANISMOS DE RESERVA EN UNA RED MPLS INFORME FINAL DE CURSOS EN COOPERACIÓN TÉCNICA Y DESARROLLO SOCIAL presentado por Rocy Y. Martínez Marciales RELIZADO CON LA ASESORÍA DE Prof. Mónica Huerta (Universidad Simón Bolívar) Prof. Xavier Hesselbach Serra (Universidad Politécnica de Cataluña) RESUME : Las redes MPLS son una respuesta a la creciente demanda de productos y servicios de Internet. No sólo por la habilidad que posee de aumentar la velocidad de reenvío de paquetes, gracias a su esquema de conmutación de etiquetas, sino que con determinados protocolos de señalización (como RSVP y CR-LDP) aunado a la ingeniería de tráfico, permite ofrecer garantías de Calidad de Servicio. En este informe se describe proceso realizado para diseñar e implementar una red MPLS usando como mecanismos de reserva el protocolo de señalización RSVP-TE. Así como el análisis del rendimiento de dicha red con este protocolo de reserva y su comparación con una red IP. PALABRAS CLAVES: MPLS, LDP, RSVP, Ingeniería de Tráfico Aprobado con mención: Postulado para el premio: Sartenejas, Abril 2008

4 Í DICE GE ERAL Í DICE GE ERAL... i Í DICE DE FIGURAS... iv Í DICE DE TABLAS... vi CAPÍTULO 1. I TRODUCCIÓ Justificación Objetivo Organización del Presente Documento... 3 CAPÍTULO 2. FU DAME TOS DE REDES MPLS CONCEPTOS BÁSICOS DE REDES MPLS La Arquitectura MPLS Etiqueta MPLS Label Switch Router (LSR) Label Switched Path (LSP) Forwarding Equivalence Class (FEC) Operación Básica LABEL DISTRIBUTION PROTOCOL (LDP) LDP Peers Intercambio de Mensajes LDP Estructura del mensaje Open Shortest Path First (OSPF) Formato del paquete OSPF Jerarquía de enrutamiento MECANISMOS DE RESERVA DE RECURSOS i

5 2.4.1 RESOURCE RESERVATION PROTOCOL (RSVP) Formato de los paquetes Operación básica RESOURCE RESERVATION PROTOCOL TRAFFIC ENGINEERING CONSTRAINT-BASED LABEL DISTRIBUTION PROTOCOL (CR-LDP) CAPÍTULO 3. DESARROLLO DE LA RED MPLS DISEÑO DE LA RED Topología de la red PARÁMETROS DE RENDIMIENTO DE UNA RED Ancho de Banda Retardo Jitter Tasa de Pérdidas HERRAMIENTAS DE DESARROLLO Hardware Utilizado Software Utilizado IPERF WIRESHARK CONFIGURACIONES Configuración de interfaces físicas Configuración de una interfaz loopback Configuración de OSPF Configuración Básica MPLS Configurar CEF Activación del protocolo de distribución de etiquetas LDP Configuración RSVP-TE Habilitar túneles MPLS-TE Habilitar señalización y reservar RSVP en las interfaces Crear una ruta explícita ii

6 Crear un túnel MPLS CAPÍTULO 4. A ÁLISIS DE LOS MECA ISMOS DE RESERVA DE LA RED MPLS TIPOS DE PRUEBAS Conectividad Ancho de banda y retardo Monitoreo del tráfico PRUEBAS REALIZADAS PRUEBA 1: Conectividad con un enrutador en red IP PRUEBA 2: Conectividad en una red IP con 3 enrutadores PRUEBA 3: Medidas y acciones llevadas a cabo por el protocolo LDP PRUEBA 4: Medidas y acciones llevadas a cabo por el protocolo RSVP-TE CONCLUSIONES DEL ANÁLISIS CAPÍTULO 5. CO CLUSIO ES Y LÍ EAS FUTURAS CONCLUSIONES LÍNEAS FUTURAS DE TRABAJO REFERE CIAS GLOSARIO DE TÉRMI OS APÉNDICE A CO FIGURACIO ES ACTUALES DE LOS E RUTADORES iii

7 Í DICE DE FIGURAS Figura 1 Referencia del modelo OSI... 5 Figura 2 Ubicación del protocolo MPLS en el modelo OSI... 6 Figura 3 Estructura de una etiqueta MPLS... 7 Figura 4 Estructura de un camino LSP Figura 5 MPLS Nested Domain o dominios MPLS anidados Figura 6 Funcionamiento global de una red MPLS Figura 7 Estructura del protocolo LDP Figura 8 Estructura de los mensajes LDP Figura 9 Paquetes OSPF Figura 10 Sistema Autónomo (AS) Figura 11 Formato de los paquetes RSVP Figura 12 Operación general del RSVP Figura 13 Topología de la red MPLS en estudio Figura 14 Captura de la pantalla de Iperf actuando como cliente Figura 15 Captura de la pantalla de Iperf actuando como servidor Figura 16 Captura de la pantalla del Wireshark Figura 17 Topología para monitorear el tráfico en la red MPLS Figura 18 Topología para conectividad con un enrutador en red IP Figura 19 Ping exitoso Figura 20 Topología para conectividad en red IP con 3 enrutadores Figura 21 Tracert exitoso realizado iv

8 Figura 22 Paquete UDP protocolo IP Figura 23 Ancho de banda protocolo IP Figura 24 Porcentaje de pérdidas de paquetes con protocolo IP Figura 25 Paquete UDP encapsulado en MPLS Figura 26 Ancho de banda en la red MPLS LDP Figura 27 Porcentaje de pérdidas de paquetes en la red MPLS-LDP Figura 28 Paquete UDP encapsulado en MPLS. Protocolo RSVP-TE Figura 29 Ancho de banda. Protocolo RSVP-TE Figura 30 Porcentaje de pérdidas de paquetes. Protocolo RSVP-TE Figura 31 Ancho de banda. Redes sin saturar (a 40Mbps) Figura 32 Porcentaje de pérdidas. Redes sin saturar (a 40Mbps) Figura 33 Ancho de banda. Redes saturadas (a 60Mbps) Figura 34 Porcentaje de pérdidas. Redes saturadas (a 60Mbps) v

9 Í DICE DE TABLAS Tabla 1 Extensiones TLV para CR-LDP Tabla 2 Especificaciones del Transmisor Tabla 3 Especificaciones Receptor Tabla 4 Especificaciones de los enrutadores LER Tabla 5 Especificaciones de los enrutadores LSR Tabla 6 Direccionamiento IP del LER Tabla 7 Direccionamiento IP del LSR Tabla 8 Direccionamiento IP del LER vi

10 CAPÍTULO 1 I TRODUCCIÓ 1.1 Justificación Los servicios que tradicionalmente nos ha ofrecido Internet son navegación web, FTP y servicio de correo electrónico. El continuo desarrollo de Internet en los últimos años ha hecho que se convierta en una red de muy alta difusión, con un gran número de usuarios poco más de 527 millones en noviembre de 2007 [1]. Este hecho lleva a su vez a que los proveedores de servicios en internet, ofrezcan una mayor variedad de servicios, entre los que se encuentran telefonía, videoconferencias, televisión, radio, transacciones bancarias, etc. Estos servicios necesitan mayores requerimientos de red que los servicios tradicionales en cuanto a calidad de servicio y seguridad. El tipo de protocolo con el que se realizan los intercambios de paquetes en las redes IP, es denominado Best Effort. Con esta política de envío de paquetes, no se permite garantizar ningún tipo de calidad de servicio (QoS), ya que los paquetes son enviados a la red sin ningún tipo de control, y es la red la que hace el mejor esfuerzo (como su nombre lo indica) para que los paquetes lleguen a su destino. Teniendo así en la red poco control de las pérdidas de paquetes, retardo, jitter (variación de retardo) y ancho de banda. A lo largo del tiempo se han buscado soluciones a los diversos problemas de las redes. Para solucionar el problema de pérdidas de paquetes, nos encontramos con el protocolo TCP, que al perderse los paquetes, los reenvía, de manera de que todos lleguen a su destino. Esto trae a su vez, una mayor congestión de la red, y no es útil a la hora de hacer transmisiones en las que es importante la velocidad de la transmisión, como en audio y videoconferencias. 1

11 A lo largo del tiempo, se han ido proponiendo diferentes modelos, que permitan garantizar QoS en las redes IP. Uno de ellos es el modelo de Servicios Integrados (IntServ) [2]. Este modelo procura establecer para cada flujo, la reserva de los recursos necesarios a lo largo de la red, logrando asegurar la calidad de servicio requerida. El problema de este modelo se encuentra en la poca escalabilidad debido a la reserva de recursos por flujo, ya que en el creciente mundo del internet convergen millones de flujos. De modo que se ha ido dejando de ver como una solución viable a los problemas de prestación de QoS en redes de internet. Un modelo posterior que buscó solucionar los problemas de escalabilidad de Servicios Integrados es Servicios Diferenciados (DiffServ) [3]. Este modelo asigna los flujos en clases, y a cada clase se le trata de proporcionar calidad de servicios, dependiendo de los requerimientos del sistema. De esta manera, DiffServ, se ha convertido en un área importante en el desarrollo del Internet, pero este modelo por sí solo, sobre redes IP, no permite garantizar QoS. Esto es, porque con los protocolos de enrutamiento existentes, existen rutas IP que suelen congestionarse, ya que son las preferidas por gran número de flujos, mientras que existen otras rutas sub-utilizadas. Esto hace que aún con el uso de DiffServ, las clases de alta prioridad puedan ver afectada la calidad de servicio. Se hace necesaria entonces la inclusión de la ingeniería de tráfico (Traffic Engineering TE) que permite organizar la manera en que el flujo de tráfico circula por la red de forma de que se evite la congestión causada por una utilización desigual de la esta [26]. La primera forma en que se aplicó ingeniería de tráfico en las redes de internet, fue usando IP sobre ATM. Los principales problemas de este modelo son: la gestión de dos tipos de redes (IP y ATM), escalabilidad de la red, y desempeño en redes de alta velocidad debido a la adaptación de la capa IP a la ATM. Una de las soluciones que permite implementar TE en redes IP es la arquitectura de redes MPLS (MultiProtocol Label Switching) [4]. Esta es una tecnología de enrutamiento y reenvío de paquetes en redes IP que se basa en la asignación e intercambio de etiquetas que permiten el establecimiento de caminos a través de la red. Uno de los principales objetivos de esta topología de red es aumentar la velocidad de envío de paquetes. Para esto, se usa el esquema de intercambio de etiquetas en vez de analizar las direcciones completas de los paquetes IP y determinar el próximo paso del paquete recibido. Se encuentra entre las 2

12 capas 2 y 3 de OSI. Obteniendo así lo mejor de cada nivel: la inteligencia del enrutamiento con la rapidez de la conmutación de paquetes. En MPLS existen protocolos de señalización que no garantizan calidad de servicio, como el LDP (Label Distribution Protocol), que es un protocolo de distribución de etiquetas que no garantiza QoS. Existen otros protocolos que si ofrecen QoS como lo son: RSVP-TE (Resource ReSerVation Protocol Traffic Engineering) y CR-LDP (Constraint- Based Routing Label Distribution Protocol). 1.2 Objetivo El estudio realizado en el presente trabajo tiene como objetivo principal realizar un análisis y pruebas del comportamiento de los mecanismos de reserva de recursos en redes MPLS reales. Este objetivo se pretende alcanzar mediante la implementación, estudio y análisis del protocolo de señalización RSVP-TE y compararlo con el tráfico en una red MPLS sin protocolo de reserva (MPLS-LDP) y con el tráfico de una red IP. 1.3 Organización del Presente Documento Con base al objetivo de este documento, a continuación se describe como ha sido organizado este documento, incluyendo una breve descripción de lo que se presenta en cada capítulo. CAPÍTULO 2. FUNDAMENTOS DE REDES MPLS: En este capítulo se explican los conceptos teóricos básicos que deben ser conocidos para comprender el resto del trabajo realizado en este Proyecto. Primero se habla de los conceptos básicos de una red MPLS, los protocolos necesarios para su establecimiento y los mecanismos de reserva de recursos que se pueden emplear a la hora de usar este protocolo de red. CAPÍTULO 3. DESARROLLO DE LA RED MPLS: En este capítulo se explican los pasos necesarios para realizar el desarrollo de la red MPLS que se va a proceder a estudiar. Empezando por la descripción de la topología de la red, siguiendo por una breve descripción de tanto el software como el hardware utilizado, y finalizando por una descripción de los comandos necesarios para realizar la configuración de los enrutadores, así como el ejemplo real de configuración. 3

13 CAPÍTULO 4. ANÁLISIS DE LOS MECANISMOS DE RESERVA: En el quinto capítulo se documenta el análisis del comportamiento de los mecanismos de reserva de una red MPLS real. Esto se hace a través de una breve descripción de los parámetros que sirven para evaluar el comportamiento de una red, la metodología utilizada para la realización de las pruebas, los resultados obtenidos y los análisis correspondientes. CAPÍTULO 5. CONCLUSIONES Y LÍNEAS FUTURAS: En este, él último capítulo se establecen las conclusiones logradas luego de desarrollar el proyecto y se muestran las futuras líneas de trabajo que han surgido por medio del trabajo realizado. 4

14 CAPÍTULO 2 FU DAME TOS DE REDES MPLS 2.1 CO CEPTOS BÁSICOS DE REDES MPLS La Arquitectura MPLS Para comenzar a describir la arquitectura MPLS, vamos a ubicarla en el modelo OSI que consiste en 7 capas como se observa en la figura 1. Figura 1 Referencia del modelo OSI La capa 2 es la capa enlace (Data Link) es la que se ocupa del direccionamiento físico, de la topología de la red, del acceso a la red, de la notificación de errores, de la distribución ordenada de tramas y del control del flujo. Ejemplos de protocolos usados en esta capa son Ethernet, PPP, HDLC y Frame Relay. El alcance de la capa de enlace está solo en el enlace entre dos máquinas, pero no más allá. Esto significa que la cabecera de la capa de enlace siempre se reemplaza por la máquina que esté al final del enlace. 5

15 La capa 3 es la capa de red ( etwork) es la que se preocupa por el envío de paquetes del origen al destino. Tiene alcance más allá del enlace. El ejemplo más conocido de un protocolo de capa 3 es IP. Luego, MPLS no es un protocolo de capa 2 porque en la capa 2, el encapsulamiento está presente con los paquetes etiquetados. MPLS tampoco es realmente un protocolo de capa 3, porque en esta capa el protocolo todavía está presente también. De modo que MPLS no encaja muy bien en las capas del modelo OSI, por lo que se ubica MPLS entre las capas 2 y 3 (en la capa 2.5) como se muestra en la figura 2. Figura 2 Ubicación del protocolo MPLS en el modelo OSI MPLS (Multiprotocol Label Switching) es una arquitectura de red diseñada originalmente por un pequeño grupo de trabajo: Ross Callon (Ascend), Arun Viswanathan (IBM), Eric Rosen (Cisco) que está basada en la conmutación de etiquetas y tiene como objetivos principales aumentar la velocidad de conmutación de paquetes y crear redes flexibles y escalables con un incremento en su desempeño y estabilidad. Para su funcionamiento, cada enrutador analiza la cabecera del paquete y ejecuta un algoritmo de enrutamiento, basándose en la información de dicha cabecera. Las cabeceras de los paquetes en las redes IP contienen mucha más información de la necesaria para elegir el siguiente salto. Para realizar esta acción es necesario realizar dos funciones: Particionar el conjunto de paquetes en clases de envío equivalentes (FECs) y asociar cada uno de estos FECs con algún destino. 6

16 En lo que respecta a la decisión de reenvío, diferentes paquetes clasificados dentro de un mismo FEC son considerados idénticos. Por lo que todos los paquetes pertenecientes a un mismo FEC seguirán el mismo camino. En el envío IP, un enrutador considerará a dos paquetes dentro del mismo FEC si algún prefijo de dirección X en la tabla de enrutamiento del enrutador, el cual sea la mayor concordancia para la dirección de destino de los paquetes. A medida que el paquete sigue circulando por la red, cada enrutador realiza la misma operación de asignación en un FEC. En MPLS, esta asignación se efectúa solamente cuando el paquete entra en la red. Tras esto, el FEC al que el paquete ha sido asignado se codifica en un valor llamado Etiqueta. Cuando un paquete va a ser enviado al siguiente nodo, se le añade la etiqueta. En el resto de los nodos del camino, no se necesitará realizar el análisis de la cabecera del paquete. La etiqueta que acompaña al paquete servirá encontrar el siguiente salto y una nueva etiqueta, procediendo así a repetir el proceso de envío Etiqueta MPLS Una etiqueta MPLS es un campo de 32 bits con una cierta estructura [7]. La figura 3 muestra la estructura de una etiqueta MPLS. Figura 3 Estructura de una etiqueta MPLS Los primeros 20 bits son el valor de la etiqueta. Este valor puede ser entre 0 y ó En todo caso, los primeros 16 valores están excluidos del uso normal ya que tienen un significado especial. Los bits 20 al 22 son los tres bits experimentales (EXP). Estos son usados generalmente para calidad de servicio (QoS). Hay que tener en cuenta que estos bits se llaman experimentales por razones históricas. 7

17 El bit 23 es el Bottom of Stack (BoS). Tiene el valor de 0 (cero), a menos que este sea la etiqueta del fondo de la pila. Si es así, el bit está en 1. La pila es la colección de etiquetas que se encuentran en el tope del paquete. La pila puede ser de una sola etiqueta o más. El número de etiquetas (que está en el campo del bit 32) que se puede encontrar en la pila no tiene límites. Los bits del 24 al 31 son los 8 bits usados para Time To Live (TTL). Este TTL tiene la misma función que el TTL que se encuentra en la cabecera IP. Simplemente decrece en 1 en cada salto, y su función principal es evitar que un paquete se quede estancado en un loop de enrutamiento. Si sucede un loop y no hay un TTL presente, el paquete se queda en el loop por siempre. Por el contrario, cuando sí existe el campo TTL y este llega a 0, el paquete es descartado Label Switch Router (LSR) Un LSR (Label Switch Router) es un enrutador que soporta MPLS. Es capaz de entender las etiquetas MPLS y de recibir y transmitir un paquete etiquetado en un enlace. Existen 3 clases de LSRs en una red MPLS. Ingress LSRs Los LSR de ingreso reciben un paquete que todavía no está etiquetado, le insertan una etiqueta (pila) al paquete, y lo envían por la red. También son denominados LER (Layer Edge Router), por ser un LSR frontera entre una red IP y una red MPLS. Egress LSRs Los LSR de egreso reciben los paquetes etiquetados, remueven la(s) etiqueta(s) y los envían. De la misma manera que los ingress LSRs, los egress LSRs son llamados LERs, por ser dispositivos que se encuentran en la frontera de IP y MPLS. Intermediate LSRs Los LSRs intermedios reciben un paquete etiquetado entrante, realizan una operación en él, conmuta el paquete, y lo envían por el enlace correcto. Un LSR puede hacer 3 tipos de operaciones: pop, push o swap. 8

18 Pop: Esta operación consiste en remover una o más etiquetas del tope de la pila de etiquetas antes de enviar el paquete fuera de la red. El que realiza esta acción es un egress LSR. Un LSR que quita todas las etiquetas del paquete etiquetado antes de enviarlo a la red es un disposing LSR por ser el último en quitar las etiquetas. Push: Esta operación consiste en introducir una o más etiquetas en el paquete recibido en la pila de etiquetas. Cuando un LSR recibe un paquete que ya está etiquetado, la operación push consiste en agregar una o varias etiquetas al paquete y luego enviarlo a través de la red. Esta acción la realiza un ingress LSR. Si el paquete recibido por el LSR no está etiquetado, el push consiste en crear la pila de etiquetas, introducirlas en el paquete y luego enviarlas a través de la red. Un LSR que realiza este tipo de push se denomina imposing LSR por ser el primero en ponerle etiquetas al paquete. Swap: Esta operación se da cuando un LSR recibe un paquete etiquetado y la etiqueta del tope de la pila es intercambiada (swapped) con una nueva etiqueta y luego el paquete es enviado a la red Label Switched Path (LSP) Un LSP (Label Switched Path) es una secuencia de LSRs que conmutan un paquete etiquetado a través de una red MPLS o parte de ella. El primer LSR de un LSP es el ingress LSR para ese LSP, donde el último LSR del LSP es el egress LSR. Todos los LSR entre ellos son los intermediate LSRs. En la figura 4 se muestra la dirección del LSP con la flecha azul, porque un LSP es unidireccional. El flujo de los paquetes en la otra dirección (de abajo a arriba) entre los mismos LSRs se realizaría a través de otro LSP. 9

19 Figura 4 Estructura de un camino LSP El ingress LSR de un LSP no es necesariamente el primer enrutador en etiquetar un paquete. El paquete puede estar etiquetado ya por un LSR precedente. Como es el caso de un LSP anidado (que es un LSP adentro de otro LSP). En la figura 5 [19], se observa un caso como este. En el que el primer enrutador que recibe el paquete, introduce la etiqueta MPLS L1 en el paquete por medio de un push, el segundo enrutador intercambia L1 por L2, y el tercer enrutador, como es el ingrees LSR de otro dominio LSP agrega una nueva etiqueta L3 a la pila. El paquete tiene así dos etiquetas mientras están dentro del dominio anidado. La del tope pertenece al LSP anidado y la del fondo pertenece al LSP que se extiende por toda la red MPLS. Luego al salir del dominio MPLS anidado, el enrutador le quitará la etiqueta que corresponde al LSP (L4) y el enrutador por el que sale del la red MPLS le quitará la última etiqueta (L2) y enviará el paquete a la red IP. 10

20 Figura 5 MPLS Nested Domain o dominios MPLS anidados Forwarding Equivalence Class (FEC) Una FEC (Forwarding Equivalence Class) es un grupo o flujo de paquetes que se envían a través del mismo camino y son tratados de la misma manera. Todos los paquetes pertenecientes a la misma FEC tienen la misma etiqueta. Sin embargo, no todos los paquetes que tienen la misma etiqueta pertenecen a la misma FEC, porque sus valores de EXP podrían diferir. El tratamiento de envío podría ser diferente, y ellos podrían pertenecer a una diferente FEC. El enrutador que decide que paquete pertenece a que FEC es el LSR de ingreso (ingress LSR). Esto es porque el LSR de ingreso es el que clasifica y etiqueta los paquetes en la entrada de la red. A continuación se presentan algunos ejemplos de FECs: Paquetes con direcciones IP de destino de capa 3 que concuerden con cierto prefijo. Paquetes multicast que pertenezcan a determinado grupo. Paquetes con el mismo tratamiento de envío, basado en la precedencia o el campo DSCP en el protocolo de DiffServ. 11

21 2.1.2 Operación Básica El esquema global de funcionamiento es el que se muestra en la figura 6 [10], donde quedan reflejadas las diversas funciones en cada uno de los elementos que integran la red MPLS. Es importante destacar que en el borde de la nube MPLS tenemos una red convencional de routers IP. El núcleo MPLS proporciona una arquitectura de transporte que hace aparecer a cada par de routers a una distancia de un sólo salto. Funcionalmente es como si estuvieran unidos todos en una topología mallada (directamente o por PVCs ATM). Ahora, esa unión a un solo salto se realiza por MPLS mediante los correspondientes LSPs (puede haber más de uno para cada par de routers). La diferencia con topologías conectivas reales es que en MPLS la construcción de caminos virtuales es mucho más flexible y que no se pierde la visibilidad sobre los paquetes IP. Todo ello abre enormes posibilidades a la hora de mejorar el rendimiento de las redes y de soportar nuevas aplicaciones de usuario. Figura 6 Funcionamiento global de una red MPLS Un aspecto importante en la operación de MPLS es la manera en que se realiza la distribución de etiquetas. La primera etiqueta es impuesta en el ingress LSR y esta etiqueta corresponde a un único LSP. El camino del paquete a través de la red MPLS está vinculado 12

22 a ese único LSP. Todo lo que cambia es que la etiqueta en el tope de la pila de etiquetas es intercambiada (swapped) en cada salto. Los LSR intermedios intercambian la etiqueta del tope de la pila (la etiqueta entrante) del paquete etiquetado recibido por otra etiqueta (la etiqueta saliente). El egress LSR del LSP quita las etiquetas de este LSP y reenvía el paquete. Si por ejemplo se tiene una red de IP sobre MPLS que tiene como IGP IS-IS (Intermediate System-to-Intermediate System), y EIGRP (Enhanced Interior Gateway Routing Protocol), el ingress LSR mira la dirección de destino IP del paquete, impone la etiqueta y reenvía el paquete. El siguiente LSR (y cualquier otro intermediate LSR) recibe el paquete, realiza un swap de la etiqueta entrante por la etiqueta saliente y reenvía el paquete. El egress LSR elimina la etiqueta y reenvía el paquete IP sin las etiquetas de salida. Para que esto funcione, los LSRs adyacentes deben estar de acuerdo en que etiqueta usar para cada prefijo de un IGP. Por lo tanto, cada LSR debe estar en la capacidad de identificar cual etiqueta de salida y cual etiqueta de entrada deben ser intercambiadas. Esto significa que se necesita un mecanismo para decirle al router cuales etiquetas usar cuando se reenvía un paquete. Las etiquetas son locales para cada par de routers adyacentes. Las etiquetas no tienen significados globales a través de la red. Para que los routers adyacentes estén de acuerdo en que etiquetas usar, se necesita alguna forma de comunicación entre ellos. De otra forma los routers no saben que etiquetas de salida se necesita que haga par con la etiqueta de entrada. Es por esto que se necesita un protocolo de distribución de etiquetas. Se puede distribuir las etiquetas de dos formas: Hacer Piggyback de las etiquetas con un protocolo IP existente. Tener un protocolo separado de distribución de etiquetas. El método del Piggyback tiene la ventaja de que no se corre un nuevo protocolo en los LSRs, pero cada protocolo existente necesita ser extendido para poder llevar las etiquetas, y esto no siempre es algo fácil de hacer. La gran ventaja de tener al protocolo de enrutamiento llevando las etiquetas es que el enrutamiento y la distribución de etiquetas siempre están sincronía, lo que significa que no se va a tener una etiqueta sin prefijo o viceversa. También elimina la necesidad de correr otro protocolo en el LSR para hacer la distribución de etiquetas. La implementación de los protocolos de enrutamientos por 13

23 vector-distancia (como EIGRP) se realizan hacia adelante, ya que cada router origina un prefijo a partir de su tabla de enrutamiento. El router simplemente une una etiqueta a ese prefijo. Los protocolos de estado de enlace (como IS-IS u OSPF) no funcionan de esta manera. Cada router origina actualizaciones de estado de enlace que luego son reenviadas sin cambios por todos los routers dentro de un área. El problema es que para que MPLS funcione, cada router necesita distribuir una etiqueta para cada prefijo IGP, incluso los routers que no originan ese prefijo. Los protocolos de enrutamiento de estado de enlace necesitan ser mejorados de manera intrusiva para poder lograr hacer esto. El hecho de que un router necesite notificar una etiqueta para un prefijo que él no origina va en contra de la manera en que estos protocolos trabajan. Es por esto que para protocolos de enrutamiento de estado de enlace, es preferible usar un protocolo separado para distribuir las etiquetas. El segundo método (tener un protocolo separado para la distribución de etiquetas) tiene la ventaja de ser un protocolo independiente. Cualquiera que sea el protocolo de enrutamiento IP, sea capaz de distribuir etiquetas o no, un protocolo separado distribuye las etiquetas y deja al protocolo de enrutamiento distribuir los prefijos. La desventaja de este método es que se necesita incluir un nuevo protocolo en los LSR. La elección de todos los vendedores de routers fue tener un nuevo protocolo de distribución para distribuir las etiquetas para los prefijos IGP. Este suele ser LDP, sin embargo, no es el único protocolo que puede distribuir etiquetas MPLS. 2.2 LABEL DISTRIBUTIO PROTOCOL (LDP) Uno de los fundamentos de MPLS es que lo paquetes son etiquetados y cada LSR debe realizar un intercambio de etiquetas para reenviar el paquete. Lo que significa que las etiquetas necesitan ser distribuidas. En MPLS se define un protocolo de distribución como un conjunto de procedimientos mediante que permite realizar este proceso. De forma que es independiente del protocolo de enrutamiento y por lo tanto puede trabajar con cualquier IGP. El protocolo LDP es uno de estos. LDP se define como el conjunto de procedimientos y mensajes mediante los cuales los LSRs crean LSPs a través de una red, mapeando la información de enrutamiento 14

24 directamente a caminos conmutados. Estos caminos podrán acabar en vecinos conectados entre sí directamente o pueden acabar en un nodo de salida de la red, activando entonces la conmutación entre todos los nodos intermedios. Así mismo, los LDPs asocian una FEC con cada camino LSP que crean. Los FEC asociados a cierto camino, especifican qué paquetes IP van a ir por ese camino. Para que los paquetes circulen en un LSP a través de la red MPLS, todos los LSRs deben correr un protocolo de distribución de etiquetas e intercambiar vínculos de etiquetas. Cuando todos los LSRs tienen etiquetas para una particular FEC, los paquetes pueden ser reenviados por el LSP por medio de la conmutación de etiquetas de los paquetes en cada LSR. La operación de etiquetas (swap, push, pop) es conocida por cada LSR mirando en la LFIB. La LFIB (que es la tabla que reenvía los paquetes etiquetados), es alimentada por los vínculos de etiquetas encontrados en la LIB. La LIB es alimentada por los vínculos de etiquetas recibidos por el protocolo de distribución de etiquetas. Los LSR conectados directamente deben establecer una relación de pares LDP o una sesión LDP entre ellos. Los pares LDP intercambian los mensajes de vínculos de etiquetas a través de la sesión LDP. Un vínculo de etiqueta es una etiqueta que está vinculada a una FEC LDP Peers Se llaman LDP peers a dos LSRs que emplean el protocolo LDP para intercambiar información de asociación de etiquetas (FEC), manteniéndose entre ellos una sesión LDP. Una sesión LDP permite a cada par aprender la información de las etiquetas del otro. El protocolo es bidireccional Intercambio de Mensajes LDP Existen 4 categorías de mensajes: Mensajes de descubrimiento: empleados para anunciar y mantener la presencia de un LSR en la red. Mensajes de sesión: empleados para establecer, mantener y analizar las sesiones entre los pares. 15

25 Mensajes de anuncio: empleados para crear, cambiar y borrar asociaciones de etiquetas con FECs. Mensajes de notificación: empleados para dar información de aviso o de error. Los mensajes de descubrimiento anuncian la presencia de un LSR en la red, por medio de un mensaje Hello que se envía periódicamente. Cuando un LSR desea establecer una sesión con otro LSR, aprendido gracias al mensaje Hello, empleará el procedimiento de inicialización LDP sobre TCP. Si se lleva a cabo de forma correcta el procedimiento de inicialización LDP, los dos LSRs son ya pares LDP, y pueden intercambiar mensajes de anuncio. Cuándo pedir o anunciar cierta etiqueta, será decisión local de cada LSR. Por lo general, el LSR pide una etiqueta a su vecino cuando la necesita, y la anuncia cuando desea que el vecino la comience a utilizar. El funcionamiento correcto del protocolo LDP requiere una recepción fiable y ordenada de los mensajes. Es por esto que se emplea el protocolo TCP para mensajes de sesión, de anuncio y de notificación. Es decir, para todo el proceso, menos para los mensajes de descubrimiento, que viajan sobre el protocolo UDP Estructura del mensaje Todos los mensajes LDP tienen una estructura común que emplea una metodología de codificación. En la figura 7 se muestra la estructura del protocolo LDP [9]. Figura 7 Estructura del protocolo LDP Versión Es el número de versión de LDP. El número presente es 1 PDU Length El largo total del PDU (Protocol Data Unit) excluyendo la versión y el campo PDU length. 16

26 LDP identifier Este campo únicamente identifica el espacio de la etiqueta del LSR para el que aplica el PDU. Los primeros cuatro bytes codifican la dirección IP asignada al LSR. Los últimos 2 bytes indican el espacio de la etiqueta dentro del LSR. LDP mesagges Es el campo donde se encuentran los mensajes LDP. La estructura de los mensajes se muestra en la figura 8. Figura 8 Estructura de los mensajes LDP U Este bit es un bit desconocido del mensaje. Message type Es el campo donde se define el tipo de mensaje. Los siguientes tipos de mensajes existen: Notification, Hello, Inicialization, Keep Alive, Address, Address Withdraw, Label Request, Label Withdraw, Label Release, nombre de mensaje desconocido. Message Length La longitud en bytes del ID del mensaje, de los parámetros obligatorios y de los parámetros opcionales. Message ID Valor de 32 bits usado para identificar el mensaje. Parameters Los parámetros contienen los TLVs. Existen parámetros obligatorios y opcionales. Algunos mensajes no tienen parámetros obligatorios, y algunos no tienen parámetros opcionales. 17

27 2.3 PROTOCOLO DE E RUTAMIE TO Para establecer una red MPLS es necesario algún protocolo de enrutamiento (RIP, IS-IS, OSPF, entre otros). En el estudio realizado en el presente trabajo, el protocolo utilizado es OSPF (Open Shortest Path First) Open Shortest Path First (OSPF) OSPF (Open Shortest Path First) es un protocolo de enrutamiento definido como estándar de la IETF en el RFC 2328 [11]. Está diseñado para ser un IGP (Internal Gateway Protocol). Este protocolo tiene dos características principales [12]. La primera es que el protocolo es abierto, es decir, que es del dominio público. La otra es que está basado en el algoritmo SPF (Shortest Path First), que también es conocido como el algoritmo de Dijkstra (nombrado así en honor a la persona acreditada con su creación). OSPF es un protocolo de enrutamiento de estado de enlace, llamado así por enviar avisos de estado de enlace (link-state advertisements LSAs ) a todos los otros enrutadores en la misma área jerárquica. Información de las interfaces adjuntas, la métrica usada y otras variables se incluyen en los LSAs OSPF. Como un enrutador OSPF acumula la información de estado de enlace, usan el algoritmo SPF para calcular el camino más corto a cada nodo. Como protocolo de estado de enlace, OSPF contrasta con IGRP y RIP, que son protocolos de enrutamiento de vector-distancia. Los enrutadores corriendo un algoritmo de vector-distancia envían todo o una porción de sus tablas de enrutamiento en mensajes de actualización de enrutamiento a sus vecinos Formato del paquete OSPF Todos los paquetes OSPF comienzan con una cabecera de 24 bytes, como se muestra en la figura 9, que contiene 9 campos. 18

28 Field length 1 1 (bytes) version number Type Packet length Router ID Area ID Check-sum Authintication type Authentication Variable Data Figura 9 Paquetes OSPF Versión number Identifica la versión del OSPF usado. Type Identifica el tipo de paquete OSPF como uno de los siguientes: o Hello Establece y mantiene relaciones entre vecinos. o Database description Describe el contenido de una base de datos de la topología de red. Estos mensajes son intercambiados cuando se inicializa la adyacencia. o Link-state request Solicita extractos de la base de datos topológica a los enrutadores vecinos. Estos mensajes son intercambiados después que el enrutador descubre (al examinar los paquetes de database-description) que parte de su base de datos topológica está desactualizada. o Link-state update Responde a un paquete de tipo link-state request. Estos mensajes también son usados para la distribución regular de LSAs. Varios LSAs se pueden incluir en un solo paquete de tipo link-state update. o Link-state acknowledgment Reconoce los paquetes de tipo linkstate update. Packet length Especifica la longitude del paquete, incluyendo la cabecera OSPF, en bytes Router ID Identifica la fuente del paquete. Area ID Identifica el área a la cual el paquete pertenece. Todos los paquetes OSPF están asociados a una sola área. 19

29 Checksum Revisa el contenido completo del paquete por cualquier daño sufrido en el camino. Authentication type Contiene el tipo de autenticación. Todos los intercambios del protocolo OSPF son autenticados. El tipo de autenticación es configurable por área. Authentication Contiene la información de la autenticación. Data Contiene encapsulada información de la capa superior Jerarquía de enrutamiento A diferencia de RIP, OSPF puede operar por jerarquía. La entidad más grande en la jerarquía es el sistema autónomo (autonomous system AS ), que es el conjunto de redes bajo una administración común y comparten una misma estrategia de enrutamiento. OSPF es un protocolo de enrutamiento interno (IGP) intra-as, aunque es capaz de recibir rutas desde y enviar rutas hacia otros ASs. Un AS puede dividirse en un número de áreas, que son grupos de redes continuas y hosts adjuntos. Los enrutadores con múltiples interfaces pueden participar en múltiples áreas. Estos enrutadores, que son denominados Area Border Routers, mantienen bases de datos topológicas separadas para cada área. Una base de datos topológica es esencialmente un dibujo general de las redes en relación a los enrutadores. La base de datos topológica contiene el conjunto de LSAs recibidos desde todos los enrutadores de la misma área. Debido a que los enrutadores dentro de una misma área comparten la misma información, ellos tienen bases de datos topológicas idénticas. El término dominio (domain) a veces es usado para describir una porción de la red en la cual todos los enrutadores tienen bases de datos topológicas idénticas. Frecuentemente se observa que se intercambian los términos dominio con AS. 20

30 La topología de un área es invisible a los elementos afuera del área. Por medio de mantener las topologías de cada área separadas, OSPF envía menos tráfico de enrutamiento del que enviaría si los AS no estuvieran particionados. Las particiones de área crean dos tipos diferentes de enrutamiento OSPF, dependiendo de si la fuente y el destino están en la misma o diferentes áreas. Enrutamiento intra-area sucede cuando la fuente y el destino se encuentran en la misma área; el enrutamiento inter-area ocurre cuando la fuente y el destino se encuentran en áreas distintas. El backbone OSPF es responsable por distribuir la información de enrutamiento entre las áreas. Éste está formado por todos los Area Border Routers, redes no contenidas en ninguna área, y sus enrutadores adjuntos. En la figura 10 se muestra un ejemplo de una red con varias áreas. Los enrutadores 4, 5, 6, 10, 11 y 12 conforman el backbone. Si el host H1 en el área 3 quiere enviarle un paquete al host H2 en el área 2, el paquete es enviado al enrutador 13, que reenvía el paquete al enrutador 12, el cual envía el paquete al enrutador 11. El enrutador 11 entonces envía el paquete a través del backbone al Area Border Router 10, que envía el paquete a través de dos enrutadores intra-area (9 y 7) para que sean reenviados al host H2. 21

31 Figura 10 Sistema Autónomo (AS) que consiste en múltiples áreas enlazadas por enrutadores El backbone en sí mismo es un área OSPF, así que todos los enrutadores pertenecientes al backbone usan los mismos procedimientos y algoritmos para mantener la información de enrutamiento dentro del backbone que cualquier enrutador de área usaría. La topología del backbone es invisible a todos los enrutadores intra-area, como lo son todas las topologías de área individuales al backbone. Las áreas se pueden definir de manera que el backbone no sea continuo. En ese caso la conectividad del backbone debe ser restaurada a través de enlaces virtuales. Los enlaces virtuales son configurados a entre cualquier enrutador de backbone que comparten un enlace con un área no perteneciente al backbone y funcionan como si fueran enlaces directos. 22

32 2.4 MECA ISMOS DE RESERVA DE RECURSOS RESOURCE RESERVATIO PROTOCOL (RSVP) El RSVP (Resource ReSerVation Protocol) es un protocolo de señalización diseñado a reservar recursos a través de las redes de internet de manera que garantiza calidad de servicio. RSVP no transporta datos de aplicación, es más un protocolo de control de Internet, como ICMP, IGMP o protocolos de enrutamiento [15]. RSVP provee reservas de recursos para flujos de datos multicast o unicast con robustez y escalabilidad. RSVP se pude usar por enrutadores o host que solicitan o entregan niveles específicos de calidad de servicio (QoS) para aplicaciones de stream de datos o flujos. RSVP define como las aplicaciones realizan las reservas y como pueden renuncias a los recursos reservados una vez que la necesidad de ellos ha terminado. La operación de RSVP generalmente se convertirá en recursos siendo reservados en cada nodo a lo largo del camino. RSVP no es por sí mismo un protocolo de enrutamiento y ha sido diseñado para operar en conjunto con los protocolos de enrutamientos actuales y futuros. Usa los protocolos de enrutamiento IGP (Interior Gateway Protocol) para determinar los caminos. En este protocolo existen dos tipos principales de mensajes: Mensajes Path El mensaje de Path se envía desde el host transmisor a través del camino de datos y guarda un estado de path en cada nodo a lo largo del camino. El estado path incluye la dirección IP del nodo anterior y algunos objetos de datos: o La plantilla del transmisor para describir el formato de los datos del transmisor. o El tspec del transmisor para describir las características del tráfico del flujo de datos o Adspec que lleva datos de publicidad. 23

33 Mensajes Resv El mensaje resv es enviado desde el receptor al transmisor a través del camino de datos en reversa. En cada nodo la dirección IP del destino del mensaje resv cambiará a la dirección del siguiente nodo en el camino en reversa y la dirección IP de la fuente cambiará a la dirección del nodo anterior del camino en reversa. El mensaje resv incluye el objeto flowspec data, que identifica los recursos que el flujo necesita Otros tipos de mensajes que se encuentran en el protocolo RSVP son los siguientes: Path tear Eliminar el camino path. Son enviados al enrutador de egreso. Resv tear Eliminar el camino resv. Son enviados al enrutador de ingreso PathErr Error a path. Enviados al enrutador de ingreso. ResvErr Error a resv. Enviado al enrutador de egreso. ResvConf Mensaje de confirmación de reserva Formato de los paquetes En la figura 11 se puede observar el formato de los paquetes RSVP que está formado por una cabecera común y un número de objetos de longitud variable. Figura 11 Formato de los paquetes RSVP: a. Formato general del paquete; b. Formato de la cabecera común; c. Formato de la cabecera del objeto. 24

34 Los campos de la cabecera común son: Ver versión del protocolo RSVP. Flags no definido. Message Type Tipo del mensaje. RSVP checksum campo de verificación Send TTL indica el tiempo de vida (Time To Live) del mensaje. RSVP length longitud total del mensaje expresado en bytes, incluyendo cabecera y cuerpo. Los campos de los objetos son: Length longitud total del objeto expresada en bytes. Su valor debe ser siempre un múltiplo de cuatro. Class_Num identifica la clase del objeto. Todas las implementaciones de RSVP reconocen las siguientes clases: o NULL o SESSION o RSVP_HOP o TIME_VALUES o STYLE o FLOWSPEC o FILTER_SPEC o SENDER_TEMPLATE o SENDER_TSPEC o ADSPEC o ERROR_SPEC o POLICY_DATA o INTEGRITY o SCOPE o RESV_CONFIRM C_Type tipo de objeto. Identifica el tipo de objeto dentro de la clase 25

35 Operación básica Un host RSVP que necesita enviar un flujo de datos con una calidad de servicio (QoS) específica transmitirá un mensaje RSVP path que va a viajar a lo largo de rutas unicast o multicast pre-establecidas por el protocolo de enrutamiento que se encuentre funcionando. Si el mensaje path llega a un enrutador que no entiende RSVP, ese enrutador reenvía el mensaje sin interpretar el contenido del mensaje y no reserva recursos para el flujo. Cuando el enrutador de destino recibe el mensaje path realizará las siguientes acciones: Hacer una reserva basada en los parámetros requeridos. Para esto, el control de admisión y el control de políticas procesan los parámetros solicitados y pueden bien, instruir al clasificador de paquetes a manejar correctamente los paquetes de datos seleccionados o bien, negociar con la capa superior como se debe realizar el manejo de los paquetes. Reenviar la solicitud upstream (en dirección del transmisor). En cada nodo el flowspec del mensaje resv puede ser modificado (por ejemplo en el caso de las reservas de un flujo multicast, las solicitudes de reservas se pueden fusionar). Cada nodo en el camino puede aceptar o rechazar la solicitud de reserva de recursos. Este protocolo está compuesto por flujos unidireccionales, es decir, las reservas se hacen en una sola dirección. Para las comunicaciones bidireccionales, será necesaria una reserva para cada sentido de la comunicación. Este protocolo, como se puede ver en la figura 12 está orientado al receptor, ya que es este el encargado de decidir cuáles son los recursos que se van a reservar e iniciar la reserva a través de los mensajes resv. La solicitud viaja del receptor al transmisor y se va construyendo el árbol de reservas. Además, el protocolo es soft state, lo que quiere decir que los caminos y recursos se mantienen dinámicamente y pueden cambiar durante la vida de una sesión RSVP. 26

36 Figura 12 Operación general del RSVP RESOURCE RESERVATIO PROTOCOL TRAFFIC E GI EERI G (RSVP-TE) RSVP-TE es una extensión del protocolo RSVP diseñada para los casos en los que existen requerimientos de ingeniería de tráfico. Es usado por lo general para proveer QoS y balanceo de carga a través de la red. RSVP permite el uso de fuente de enrutamiento donde el router de ingreso determina el camino completo a través de la red. El router de ingreso puede usar un calculador CSPF (Constrained Shortest Path First) para determinar el camino al destino, asegurando que cualquier requerimiento de calidad de servicio está garantizado. El camino resultante es usado para establecer el LSP. El nodo de ingreso de un LSP usa un número de métodos para determinar a qué paquetes se le asigna a una determinada etiqueta. Una vez que la etiqueta es asignada a un grupo de paquetes, la etiqueta define el flujo a través del LSP. Se puede hacer referencia a un LSP como túnel LSP debido a que el tráfico a través de él, no es visible a los nodos intermedios del LSP. Una nueva sesión RSVP, un transmisor y objetos Filter Spec, llamados túnel LSP IPv4 y túnel LSP IPv6 [13] han sido definidos para soportar las características de los túneles LSP. La perspectiva de un nodo perteneciente al LSP, es que el tráfico vinculado al túnel LSP se identifica únicamente dependiendo de los paquetes que llegan desde el salto anterior (previuos hop o PHOP) con el valor particular de la etiqueta asignada por este nodo a transmisores upstream de la sesión. De hecho, IPv4(v6) que aparece en el nombre del objeto solo indica que la dirección de destino es una dirección IPv4(v6). Cuando se hace referencia a estos objetos, por lo general, el calificador de túnel LSP está siendo usado. 27

37 En algunas aplicaciones es útil asociar grupos de túneles LSP. Esto puede ser útil durante las operaciones de re-enrutamiento o de propagación de tráfico troncal sobre múltiples caminos. En la aplicación de ingeniería de tráfico, estos grupos son llamados túneles de ingeniería de tráfico (TE tunnels). Para habilitar la identificación y asociación de esos túneles LSP, se llevan dos identificadores (ID). La ID de un túnel es parte del objeto de la sesión. El objeto de sesión únicamente define un túnel con ingeniería de tráfico. El transmisor y los objetos Filter Spec llevan un ID LSP. El objeto del transmisor (o Filter Spec) junto con el objeto de sesión únicamente identifican un túnel LSP. Las extensiones añadidas soportan el establecimiento y mantenimiento de los LSPs. Estos se mantienen mediante el protocolo de Hello que es usado para la conectividad de enrutador a enrutador. Estas extensiones incluyen la distribución de etiquetas MPLS. Los objetos de los mensajes Path y Resv en estas extensiones son: Objeto de ruta explícita (Explicit Route Object o ERO). Label request object Label object Record router object Session Attribute Object Tspec Object. Explicit Route Object: Es usado para especificar las rutas que los mensajes RSVP Path toman establecer un LSP. Pueden especificar rutas estrictas o sueltas. Las rutas sueltas dependen de la tabla de enrutamiento para encontrar el destino. Las rutas estrictas especifican el siguiente enrutador directamente conectado. Una ruta puede tener ambos componentes (estrictos y sueltos) CO STRAI T-BASED LABEL DISTRIBUTIO PROTOCOL (CR-LDP) Para entender este protocolo es necesario entender que es el encaminamiento basado en restricciones (constraint-based routing). Con el encaminamiento convencional, la 28