Memoria_230606 M Puñales

PROYECTO FIN DE CARRERA PLAN 92

Tema: Diseo e implementacin de una red IP con troncal MPLS

Ttulo: MPLS: Aplicacin y funcionalidades. Diseo e implementacin del servicio VPN-MPLS.

Mario Puales Casquero Junio 2006

1

INDICEIntroduccin 4

1. Introduccin a Multiprotocol Label Switching (MPLS) 1.1 Enrutamiento tradicional 1.2 Ingeniera de trfico en MPLS ... 1.3 Componentes de MPLS ..

6 7 8 10

2. Protocolo de distribucin de etiquetas (LDP) .. 2.1 Modo de operacin de LDP ... 2.2 Mensajes LDP

14 14 18

3. VPN-MPLS. Redes Privadas Virtuales MPLS 3.1 Topologa Hub-and-spoke .. 3.2 Topologa Partial o Full-Mesh ... 3.3 Topologas Hbridas ...

20 26 29 31

4. QoS. Calidad de servicio en redes MPLS . 4.1 La necesidad de aplicar una QoS ... 4.2 Condicionantes del trfico: El otro lado de Diff-Serv ... 4.3 IP Bearer Services .. 4.4 MPLS QoS .

33 33 38 43 46

5. MPLS Traffic Engineering 5.1 TE-RSVP 5.2 CR-LDP .. 5.3 Discusin tcnica, iniciativas de ingeniera de trafico en MPLS ... 5.4 Diferencias entre CR-LDP y TE-RSVP . 5.5 Conclusiones a las similitudes y las diferencias 5.6 MPLS TE Conceptos .. 5.7 MPLS TE Configuracin ... 5.8 MPLS TE Operacin ..

50 50 52 53 56 59 59 66 67

6. Escenario real de una red MPLS .. 6.1 Introduccin ... 6.2 Desarrollo ... 6.3 OSPF ..

69 69 70 72 2

6.4 BGP 6.5 Configuracin de LDP 6.6 Introduccin a la configuracin de VPN-MPLS

77 79 82

Conclusiones ... Glosario ... Bibliografa y Referencias . Anexo A: Manual bsico de configuracin MPLS sobre Cisco . Anexo B: Prcticas Propuestas . Anexo C: Automatizacin de la configuracin de la red ....

98 100 106 109 116 141

3

Captulo 1: Introduccin a Multiprotocol Label Switching (MPLS)

IntroduccinEl entorno en el que se basa el proyecto es en el de las redes IP actuales con troncal MPLS y los servicios asociados a MPLS. MPLS (Multi-Protocol Label Switching) es un protocolo que surge para mejorar el enrutamiento de las redes IP sobre ATM, aadir diferentes funcionalidades a estas redes (ingeniera de trfico (TE), parmetros de calidad de servicios (QoS), etc.) y mejorar los retardos en el transporte del trfico en tiempo real y no real. Cabe destacar la clara separacin que hace MPLS de las funciones del control de la informacin sobre la topologa de la red y el trfico sobre la misma, y del envo de datos en s entre los elementos de la propia red. El proyecto comienza con una breve descripcin de los componentes que forman parte del protocolo MPLS con una comparacin del mtodo de routing en MPLS con el routing tradicional. Ms adelante en captulos posteriores se ver como MPLS puede a su vez convivir con los protocolos de routing tradicionales como BGP (Border Gateway Protocol) y OSPF (Open Shortest Path First). Tambin se discuten las ventajas de MPLS para el soporte de procedimientos de encaminamiento y envo de paquetes en la malla central (backbone) de las redes IP, y la posibilidad de proporcionar nuevas aplicaciones y servicios en redes IP. En concreto, se presenta la utilidad del MPLS para el soporte de aplicaciones de ingeniera de trfico, de diferenciacin de servicios en distintas clases (QoS) y de establecimiento de redes privadas virtuales (VPN) sobre una topologa "inteligente", muy superior en prestaciones a las soluciones tradicionales de tneles y circuitos virtuales. Para ello se instaura una topologa de red basada en dos partes: una parte de ncleo o backbone MPLS (core) en el que los equipos encaminan el trfico mediante la conmutacin de etiquetas, y otra parte externa en la que los equipos sustituirn las etiquetas usadas en el encaminamiento dentro del core por las direcciones IP correspondientes. Slo los routers de core tendrn configurado MPLS. El encaminamiento mediante estas etiquetas presenta grandes ventajas en el tiempo de latencia de los equipos y en la simplicidad de la conmutacin, con lo que se reducirn los retardos de la red. Se presta especial atencin a la utilizacin de MPLS en las Redes Privadas Virtuales (VPN), donde las operadoras emplean gran parte de sus recursos para satisfacer las necesidades de sus abonados, tanto particulares como pymes y grandes empresas. De hecho este es el captulo principal del libro, en el que se hace referencia a los diferentes tipos de topologa que se pueden implementar sobre un dominio MPLS (Topologas Hub & Spoke, Partial o Full Mesh, hbridas.). El objetivo final es la implementacin de una maqueta para la realizacin de prcticas cuya topologa y servicios ofrecidos se corresponden con los propios de este tipo de redes.

4


Se identifican cada uno de los pasos a seguir durante el diseo, configuracin, operacin y mantenimiento persiguiendo el que la implementacin de esta maqueta, sea valida en aplicaciones docentes y sirva como un documento didctico para futuras prcticas en algn laboratorio de las asignaturas que se imparten por DIATEL. Otro aspecto interesante es la resolucin de algunos de los problemas mas comunes en la configuracin de interfaces, anlisis de estadsticas del trfico, solucin de problemas de red y gestin, etc. En definitiva lo que se define como troubleshooting de red. Adems para facilitar la configuracin de los diferentes routers de acceso y de core, se ha hecho uso de una aplicacin que se ejecuta a travs de un entorno Web, lo cual implica que se puede ejecutar de forma remota y a la cual se hace referencia en el ltimo cpitulo. En la implementacin de la maqueta descrita en este PFC se han utilizado routers del fabricante Cisco, pudiendo implementarse en routers, que soporten MPLS, de otros fabricantes.

5


1. Introduccin a Multiprotocol Label Switching (MPLS)Con el crecimiento exponencial de Internet en los ltimos aos, la tecnologa ha tenido que adaptarse constantemente a las nuevas demandas de los usuarios de los diferentes servicios que se ofrecen en funcin del incremento del ancho de banda. En definitiva, continuara vindose un grandsimo crecimiento de Internet debido al incremento de la demanda de mas ancho de banda en los servicios domsticos (entre otros) a los que ya se esta llegando mediante servicios de banda ancha. Con la previsin de que haya un incremento de mas de 250 millones de nuevos usuarios en la prxima dcada y con la implementacin del protocolo de Internet versin 6 (IPv6), los proveedores de servicio y las operadoras de telecomunicaciones se esfuerzan en mejorar sus infraestructuras actuales por la inevitable demanda que se avecina sobre los servicios ofrecidos en sus redes. Para alcanzar y poder ofrecer la demanda de ancho de banda debida al aumento de usuarios y de necesidades de los mismos, los proveedores de servicios de Internet (ISP) necesitan mejorar el rendimiento en sus productos de enrutamiento y conmutacin de sus redes. Adems la mayora de los proveedores y operadores de las redes de datos tienen sus grandes redes montadas con tecnologa ATM, la mayora de conexiones a estos proveedores contina siendo mediante Frame Relay y conexiones punto a punto, lo que implica la presencia de latencia y alguna vez cuellos de botella en los puntos de acceso a la red. Los routers del ncleo de red tambin contribuyen al incremento de las latencias en los tiempos, ya que cada uno debe de tomar la decisin de por donde encaminar el trfico que le llega. Tradicionalmente, IP ha sido montado sobre redes ATM, usando IP sobre ATM a travs de circuitos virtuales (VC). Estos mtodos de transporte de datos esta probado que son engorrosos y complicados. La necesidad de un mtodo simple de transporte de datos, uno en el que el trfico sea gestionado mediante las caractersticas de rendimiento normales de un conmutador junto con la inteligencia en el transporte y reenvo de trfico de un router, es absolutamente necesario para las redes de hoy en da. Todas estas necesidades pueden ser cubiertas con el Multiprotocolo de conmutacin de etiquetas (MPLS: Multiprotocol Label Switching) en adelante MPLS. Porque integra las caractersticas clave de las capas 2 y 3 del modelo OSI. Pero lo ms importante es que no limita el uso de ningn protocolo de nivel 2 o 3, ni se ve limitado por alguno de ellos. En particular, MPLS tiene algunas aplicaciones y pueden ser extendidas a travs de mltiples segmentos de producto, por ejemplo, un router MPLS, un conmutador o router IP, un conmutador multiservicio, un switch Ethernet, etc

6


1.1 Enrutamiento tradicionalEn un entorno de routing tradicional, un paquete es transportado a travs de una red mediante el concepto de hop-by-hop, usando un protocolo de enrutamiento interno a la red (IGP: internal gateway protocols), como por ejemplo RIP (Routing Information Protocol), OSPF (Open Shortest Path First), o usando protocolos de routing externo (EGP: external gateway protocols), como por ejemplo BGP (Border Gateway Protocol). El funcionamiento ser en funcin a las referencias de direcciones destino de nivel 3 contra las tablas de enrutamiento que tienen los diferentes equipos de la red, es decir, comprobaran en sus tablas de enrutamiento cual es el siguiente salto para una direccin destino concreta. En definitiva, a cada paquete de datos que atraviesa un router se le comprobara cual es su direccin de destino mediante un campo que aparece en la cabecera IP del mismo. Esta comprobacin debe ser realizada para determinar cual es el siguiente salto de ese paquete hasta llegar a su destino. La direccin destino de nivel 2 es entonces reemplazada con la direccin de nivel 2 del siguiente salto y la direccin origen de nivel 2 ser reemplazada con la direccin de nivel 2 del router donde se encuentra el paquete. Sin embargo las direcciones origen y destino de nivel 3 para que el router del siguiente salto sepa enrutar el paquete hasta su destino. Este proceso debe ser repetido en cada salto del paquete hasta su destino. Se puede ver un ejemplo de funcionamiento del routing tradicional en la siguiente figura, donde se envan paquetes al router F, el router C har referencia solo a la direccin destino del router F. El router C entonces determinara cual es la mejor ruta para llegar al F, basndose en los atributos que estn definidos en funcin del IGP que este funcionando en la red. Si el router estuviese usando RIP, se enviaran los paquetes por el camino que tuviese menos saltos en su trayecto completo, teniendo en cuenta que el numero mximo de saltos nunca puede ser mayor de 15. Sin embargo, si se estuviese usando OSPF, se tendra en cuenta el coste total del camino entre el router origen hasta el destino (por ejemplo, mediante las mtricas, normalmente basadas en el ancho de banda de cada enlace) y se elegira el camino que supusiera el menos coste de toda la red.

Figura 1.1. Ejemplo de enrutamiento tradicional.

7


Como se puede ver en la figura 1.1, el router C debe tomar las decisiones de envo de los paquetes que le llegan con destino el router F basndose en las mtricas definidas en el IGP que haya sido implementado en la red. Si ha sido OSPF, las mtricas se podrn basar en diferentes criterios, pero el criterio mas usado es el ancho de banda. Si el IGP que se usa es RIP, en este caso se basara en las mtricas del nmero de saltos, descartando el paquete si alcanza los 15 saltos antes de llegar a su destino como ya se ha indicado antes. Segn la figura 1.1 todos los paquetes que llegan desde los routers A o B con destino el router F, sern enviados por el mismo sitio, a travs del camino seleccionado como el de mejores mtricas. Por lo tanto, si el camino hacia el router F a travs del router D es el de mayor ancho de banda disponible, se usara ese camino a no ser que haya algn fallo en la red que lo impida, en ese caso los paquetes serian enviados a travs del router E.

1.2 Ingeniera de trfico en MPLSSin embargo, MPLS usa un mtodo de envo de paquetes con un alto grado de velocidad en comparacin con el routing tradicional. Combina la velocidad y el rendimiento de la capa 2 con la escalabilidad y la inteligencia IP de la capa 3. Los routers en la frontera de la red, los Label Edge Router, en adelante LER, son los routers que se encuentran en el borde de la zona MPLS y son los encargados de aadir cabeceras MPLS entre las cabeceras de red y de enlace del paquete entrante. Tambin son los encargados de retirar esa informacin cuando el paquete sale de la nube MPLS. Estos routers aaden las etiquetas basndose en conjuntos o flujos de paquetes, denominados Forward Equivalence Class, en adelante FEC, a los cuales se les aade una cabecera en la zona MPLS que hace que sean tratados de la misma forma independientemente de que sean paquetes de distintos tipos de trfico. A efectos prcticos, es el conjunto de paquetes que ingresan por un mismo LER y a los cuales este les asigna la misma etiqueta. Estos FEC son conmutados dentro de la red, es decir, se hace la conmutacin de las etiquetas asociadas a los paquetes dentro de la red, mediante los routers conmutadores de etiquetas o Label Switch Router, en adelante LSR. Bsicamente los LSR son conmutadores de la nube MPLS que interpretan el valor de la cabecera MPLS y la modifican si es necesario. No aade ni elimina cabeceras MPLS solo cambian el valor de la etiqueta en funcin de sus tablas de enrutamiento. La idea ms importante es que aadiendo una simple etiqueta en un LER, el LSR es capaz de conmutar un paquete mucho ms rpido y de forma ms eficiente ya que lo hace en

8


funcin un solo elemento, en contraste con el concepto de hop-by-hop usado en el enrutamiento tradicional. Una etiqueta tiene generalmente significado local nicamente, facilitando de esta forma el anlisis de la cabecera IP de un paquete, que esta ligada a un FEC concreto (como si fuese un prefijo IP), en los LER y en los LSR se comprueba la etiqueta que tiene el paquete que les ha llegado y en funcin de sus tablas de etiquetas enviaran el paquete por un camino o por otro, cambiando el valor de la etiqueta en caso de que sea necesario (en los LSR), estas tablas se llaman LIB, base de datos de informacin de etiquetas (Label information base). Cuando se habla de la LIB no se hace alusin a las verdaderas ventajas con que cuenta la ingeniera de trfico basada en MPLS pero existen mltiples ventajas. Cuando un LSR o un LER construyen su LIB, tienen control total para poder encaminar paquetes hacia la red. La mayor ventaja del algoritmo de enrutamiento que usa MPLS es que el anlisis de la cabecera de los paquetes IP solo se necesita hacer una vez, cuando el paquete llega al LER de entrada a la red MPLS. A partir de ah, el paquete es asociado a un FEC, encaminando el paquete mediante el uso de las etiquetas a travs de un camino conmutado de etiquetas o Label Switch Path, en adelante LSP. Donde el LSP rigurosamente es el camino que describen el conjunto de routers y conmutadores que atraviesan los paquetes de un FEC concreto en la nube MPLS. Todos los paquetes del mismo FEC siguen el mismo LSP siempre, de principio a fin en la nube MPLS. En las figuras 1.2 y 1.3 puede verse un ejemplo de enrutamiento MPLS:

Figura 1.2 Ejemplo de ingeniera de trafico en MPLS.

9


Figura 1.3 LIB del router C.

En la figura 1.2 se puede ver que los paquetes con destino al router F y enviados desde el router A seguirn el camino de color verde o el LSP verde (a travs de los routers A, C, D y F). Los paquetes que se enven desde el router B sern encaminados a travs del camino de la lnea punteada roja o LSP rojo. Esto se hace en funcin de las referencias que haya para las distintas etiquetas en la LIB de cada router, hasta que la etiqueta alcance su valor de salida del dominio MPLS. En la figura 1.3 se ve la LIB del router C como ejemplo. Los paquetes que forman parte de un FEC con destino el router F llegaran al router C por la interfaz S2 con etiqueta 50, el router C en funcin de su LIB mirara por donde tiene que enviar ese paquete y vera que lo tiene que enviar por la interfaz S0 con un nuevo valor de etiqueta, el 12, realiza una conmutacin de etiqueta. La ventaja de controlar los patrones del trafico rpidamente se hace evidente cuando se compara con los IGP tradicionales (como OSPF), los cuales encaminan los paquetes basndose en la direccin destino de la capa de red (capa 3) solo. La mayora de las redes OSPF se disean con varios caminos para un mismo destino, pero usando solo la ruta que tiene el menor coste, lo que implica ms tiempo de computacin para el clculo.

1.3 Componentes de MPLSAunque ya se ha hecho referencia a muchos de los componentes de este protocolo a continuacin se har una breve referencia a ellos de forma un poco ms amplia para su comprensin. MPLS tiene muchas mejoras respecto al enrutamiento IP en lo que al encaminamiento de paquetes se refiere. Muchas de esas mejoras son sobre todo a nivel de ingeniera de trafico y de calidad de servicio (QoS: Quality of Service), tcnicas empleadas en ATM. Otros componentes de MPLS hacen posible que estas tcnicas funcionen con un mayor grado de rendimiento e inteligencia. Tambin proporcionan una manera ms eficiente de encaminar los paquetes desde el origen hasta el destino que el encaminamiento basado en el hop-byhop del enrutamiento tradicional, como ya se describi anteriormente. Muchos de estos

10


componentes son simples extensiones de tecnologas ya existentes, como por ejemplo las extensiones de componentes existentes en protocolos de routing como BGP. Adems las funcionalidades de LSR y de LER pueden ser aadidas a routers IP, conmutadores ATM, etc, normalmente aadindoles una carga de software adicional y en algunos casos algo de hardware que permita a los equipos tener estas funcionalidades. En definitiva, se puede decir que MPLS puede tener componentes que son extensiones de otros componentes porque las funciones de enrutamiento y de control de componentes estn separadas en los dispositivos capaces de trabajar con MPLS. El componente de encaminamiento es responsable de transportar los paquetes basndose en una tabla de routing. Por otro lado el componente de control es el responsable de la construccin y del mantenimiento de la tabla de rutas, as como trabajar con los componentes de control de otros nodos para completar la informacin de encaminamiento en las tablas de routing.

Label La etiqueta es un identificador de la cabecera de un paquete IP, adems dentro de ella esta contenida toda la informacin necesaria para que el paquete sea encaminado. A diferencia de la cabecera IP, la etiqueta no contiene una direccin IP, pero si un valor numrico valido para al menos los dos routers que estn a ambos extremos de un LSP y que ambos han acordado su valor. La etiqueta es de reducido tamao, tiene una longitud fija y tiene normalmente significado local nicamente. Cuando a un paquete se le asigna una etiqueta que a la vez se relaciona a un FEC se hace siempre en funcin de la direccin destino del mismo. En resumen, la etiqueta que se le asigna a un paquete representa el FEC al que se asocia dicho paquete en el dominio MPLS. Dentro de algunos medios de transporte, existen etiquetas que pueden ser usadas por nodos MPLS cuando tienen que tomar decisiones de encaminamiento con el trafico que les llega, como por ejemplo los identificadores de camino virtual / identificadores de circuito virtual (Virtual path identifier / Virtual connection identifier VPI/VCI) en ATM y en el caso de Frame Relay el DLCI (Data Link Connection identifier). Otras tecnologas como Ethernet y los enlaces punto a punto, deben usar lo que se llama una Shim Label, como se muestra en la figura 1.4:

11


Figura 1.4 Campos de una Shim label

La Shim Label esta formada por 32 bits, se usa para identificar localmente un FEC.

Forwarding Equivalence Class (FEC) Un FEC puede ser considerado como un conjunto de paquetes que son encaminados en la misma direccin a travs de la red. Un FEC puede incluir todos los paquetes que compartan una direccin destino con el mismo prefijo IP o paquetes que formen parte de una aplicacin particular entre un host origen y un host destino. Los FEC generalmente se construyen mediante la informacin aprendida a travs del IGP correspondiente, como por ejemplo OSPF o IS-IS (intermediate system to intermediate system). Label Switch Path (LSP) Un LSP es fundamentalmente la ruta predeterminada que un conjunto de paquetes que forman parte de un FEC atraviesan a travs de una red MPLS hasta alcanzar su destino. Cada LSP es unidireccional; por consiguiente, tiene que haber dos LSP diferentes para los dos sentidos del trfico en una misma ruta. Label Stack (Pila de etiquetas) Es un conjunto de etiquetas dispuestas en forma de pila. Se produce cuando existen zonas MPLS dentro de otras zonas MPLS. La pila de etiquetas es LIFO (Last-in, First-out, ltimo en entrar, primero salir). En otras palabras, la etiqueta que esta en la cima de la pila es la del dominio MPLS en el que se encuentra el paquete y la ltima etiqueta es la del dominio MPLS por el que debe salir el paquete de la red MPLS.

12


Label Distribution Protocol (LDP, Protocolo de distribucin de etiquetas) Para que un LSR al que le llega un paquete, pueda conmutarlo y enviarlo al vecino correspondiente segn su tabla de etiquetas (LIB), debe tener un mtodo de aprendizaje del valor de la etiqueta que debe enviar al par correspondiente. Actualmente, algunos protocolos pueden ser usados para la distribucin de etiquetas entre pares LSR, como por ejemplo LDP (Label Distribution Protocol), CR-LDP (Constraintbased routed-label distribution protocol), RSVP (Resource reservation protocol) y BGP (Border Gateway Protocol). En captulos posteriores se entrar ms en detalle en el funcionamiento de estos protocolos de distribucin de etiquetas. La arquitectura de MPLS, segn la RFC-3031, no especifica que protocolo de distribucin de etiquetas debe usarse entre pares LSR. De hecho, el protocolo usado depender de los requerimientos que se deben cumplir para cada red de forma particular, es decir, lo decidir el administrador de la red en funcin de la ingeniera de red, recursos disponibles, etc El protocolo LDP fue diseado nicamente para este uso, pero el LDP por s solo no rene las necesidades de calidad de servicio (QoS) necesarias para una red en explotacin. Para soportar aplicaciones de calidad de servicio, un protocolo de distribucin de etiquetas, como LDP, debe ser capaz de seleccionar y reservar apropiadamente los recursos de red necesarios para formar los diferentes LSP en la red. Para soportar esto, puede estar usndose un protocolo de reserva de recursos y extenderlo a las funciones de distribucin de etiquetas, como por ejemplo el caso de RSVP, o a la inversa, tener un protocolo de distribucin de etiquetas y extender su uso a funciones de reserva de recursos de red, como por ejemplo BGP o LDP. El Draft draft-ietf-mpls-ldp-07.txt que contiene la especificacin de LDP, define el conjunto de procedimientos y mensajes mediante los cuales los LSR establecen los LSP a travs de la red. Sin embargo, cuando estos LSP son construidos hay que asegurarse de que pueden soportar requerimientos de calidad de servicio y de ingeniera de trafico. En definitiva, existen algunos casos donde se da la necesidad de tener un mtodo de creacin explicita o manual de un LSP, por lo tanto habr dos tipos de LSP en un dominio MPLS: LSP dinmicos que se crean en funcin de los FEC y de las tablas de etiquetas junto con la tabla de routing creada por el IGP que se este usando. LSP estticos que pueden ser creados manualmente por el administrador de la red en funcin de las necesidades o para diferenciar diferentes tipos de trafico, prioridades o servicios

13

Captulo 2: Protocolo de distribucin de etiquetas (LDP)

2. Protocolo de distribucin de etiquetas (LDP).La arquitectura MPLS define un protocolo de distribucin de etiquetas como un conjunto de procedimientos por los cuales los Label Switched Router (LSR) informan a otros LSR del significado de las etiquetas usadas para enviar trfico entre y a travs de ellos. El protocolo de distribucin de etiquetas LDP (Label Distribution Protocol) es un protocolo estndar del IETF de distribucin de parejas para el funcionamiento de MPLS. Es decir, LDP distribuye los paquetes por la red en funcin de la dupla anterior: Si quieres llegar a este prefijo, utiliza esta etiqueta. LDP funciona en paralelo junto a los protocolos de routing internos IP que actan sobre la red, como por ejemplo OSPF. Mediante la tabla de forwarding creada por el protocolo de routing interno, que est configurado en la red troncal, los LSR generarn los LSP (Label Switched Path) en la red. A su vez LDP asociar un FEC (Forwarding Equivalence Class) a cada LSP creado, de esta manera se especificar que tipo de trfico circular por cada LSP de la red. Puede funcionar junto a otros mecanismos de distribucin de etiquetas como por ejemplo BGP-4 (Border Gateway Protocol version 4) o TDP (Tag Distribution Protocol), este ltimo fue el antecesor de LDP y es propietario de Cisco. A continuacin se va a hacer una breve sntesis de la RFC haciendo referencia nicamente a las caractersticas bsicas de mensajes y operacin de LDP para comprender mejor el funcionamiento de una red con troncal MPLS que use como protocolo de distribucin de etiquetas LDP. Se puede encontrar ms informacin tambin en el draft del IETF: draftietf-mpls-ldp-07.txt y en la RFC-3036

Eliminado: e Eliminado: a Eliminado: a Eliminado: a Eliminado: a

Eliminado: h Eliminado: u

2.1 Modo de operacin de LDPEl modo de operacin de LDP se puede definir en tres pasos: 1. Descubrimiento. 2. Establecimiento de la sesin. 3. Anuncio de etiquetas. A continuacin se describen brevemente cada uno de estos pasos.

14


2.1.1 Descubrimiento Se han definido dos mecanismos para la fase de descubrimiento de pares LDP: Mecanismo de descubrimiento bsico: Los LSR descubren a sus vecinos mediante el envo de mensajes Hello. Los mensajes Hello se enviarn a la direccin de broadcast por todas las interfaces del router. Mecanismo de descubrimiento extendido: es utilizado en el caso de LSR que no estn directamente conectados. Un LSR enva peridicamente mensajes Hello dirigidos a una direccin especfica, estos mensajes llevan entre otra informacin el identificador de LDP para el espacio de etiquetas y la interfaz que el LSR est usando. Cuando el LSR destino recibe los mensajes Hello decide si responderlos o ignorarlos; cuando escoge responder, lo hace enviando tambin de forma peridica mensajes Hello al originador, de esta forma se establecer una adyacencia con el LSR originador establecindose una sesin LDP. A diferencia del mecanismo bsico, slo se mandar a una direccin de LSR especifica y no se hace multicast.

Eliminado: a

Eliminado: el Eliminado: a Eliminado: ,

Eliminado: o Eliminado: a

2.1.2 Establecimiento de la sesin. Una vez se han enviado y recibido mensajes Hello, el LSR que tenga la MAC mas alta comenzar a establecer una sesin TCP con su vecino para negociar los parmetros de la sesin LDP mediante el intercambio de mensajes de inicializacin. lLos parmetros a negociar son por ejemplo el rango de etiquetas, modo de anuncio, etc. Los LSR mantienen sus sesiones LDP para la transmisin continuada y peridica de paquetes Hello para indicar la ausencia de problemas en un enlace a nivel fsico. Tambin para la transmisin peridica de mensajes Keepalive en la conexin TCP, para una monitorizacin de la misma, es decir, para saber que el vecino esta manteniendo la sesin TCP operativa. Es importante apreciar que debe de existir una nica sesin TCP por cada sesin LDP entre dos LSR. En el caso de LSR que no estn conectados directamente las sesiones LDP son creadas mediante aplicaciones de ingeniera de trfico usando LSP explcitamente. A continuacin se detalla la maquina de estados del proceso de inicializacin del establecimiento de una sesin LDP, ya que sta es la mejor forma de describir el comportamiento de la negociacin de una sesin LDP. Se tendrn cinco posibles estados que representarn los distintos comportamientos como una transicin entre los estados. Esta mquina de estados est definida en la RFC-3036 en la que adems se explica de una forma ms detallada el proceso de establecimiento de una sesin LDP entre dos LSR.Eliminado: e Eliminado: a Eliminado: a Eliminado: a Eliminado: a Eliminado: a Eliminado: , Eliminado: o

Comentario [RDM1]: No entiendo esta frase

15


NON EXISTENTConexin TCP de sesin establecida. Rx cualquier otro mensaje LDP. Tx mensaje notificacin error. Recibir cualquier otro mensaje LDP.

INITIALIZED(Papel Pasivo) Rx mensaje de inicio aceptable / Tx mensajes inicio y mantenimiento. (Papel Activo) Transmitir mensaje de inicio.

OPENREC

OPENSENTRx cualquier otro mensaje LDP. Tx mensaje de notificacin de error.

Recibir mensaje de mantenimiento

Recibir un mensaje de iniciacin aceptable. Tx mensaje de mantenimiento.

OPERATIONALRx Shutdown msg or Timeout / Tx Shutdown msg Recibir cualquier otro mensaje LDP

Figura 2.1. Maquina de estados LDP.

16


Los eventos que se generan en la transicin entre los diferentes estados se pueden ver brevemente resumidos en la siguiente tabla: ESTADONON EXISTENT

EVENTOConexin TCP de sesin establecida Transmitir mensaje de inicio(papel activo) Recibir mensaje de inicio aceptable (papel pasivo). Accin: transmitir mensajes de inicio y mantenimiento. Recibir cualquier otro mensaje LDP. Accin: transmitir mensaje de notificacin de error (NAK) y cerrar la conexin de transporte Recibir mensaje de mantenimiento Recibir cualquier otro mensaje LDP. Accin: transmitir mensaje de notificacin de error (NAK) y cerrar la conexin de transporte. Recibir un mensaje de iniciacin aceptable. Accin: transmitir un mensaje de mantenimiento. Recibir cualquier otro mensaje LDP. Accin: transmitir mensaje de notificacin de error (NAK) y cerrar la conexin de transporte. Recibir mensaje de finalizacin. Accin: transmitir mensaje de finalizacin y cerrar la conexin de transporte. Recibir cualquier otro mensaje LDP Intervalo de tiempo sobrepasado. Accin: transmitir mensaje de finalizacin y cerrar la conexin de transporte.

NUEVO ESTADOINITIALIZED OPENSENT OPENREC

INITIALIZED INITIALIZED

INITIALIZED OPENREC OPENREC

NON EXISTENT

OPERATIONALNON EXISTENT

OPENSENT

OPENREC

OPENSENT

NON EXISTENT

OPERATIONAL OPERATIONAL OPERATIONAL

NON EXISTENT

OPERATIONALNON EXISTENT

Figura 2.5. Estados de LDP 2.1.3 Anuncio de etiquetas. Para cualquier sesin LDP dada, cada LSR debe ser consciente del mtodo de distribucin de etiquetas usado por su par. Se han definido dos mtodos de anuncio de etiquetas en LDP: Downstream Unsolicited: en el que el LSR anuncia una etiqueta para un prefijo cuando est preparado para recibir paquetes MPLS con destino a dicho prefijo. De

17


esta forma, un LSR puede anunciar su mapeo de etiquetas para un FEC a sus vecinos siempre que haya completado la misma con la conmutacin de etiquetas que se aplique a ese FEC. Existirn respuestas rpidas y de iniciativa local a cambios en las rutas. La ventaja principal de este mtodo es la rpida reaccin a los cambios de routing que se pueden producir porque las etiquetas ya existen. Una desventaja es que los mapeos de etiquetas que no son necesarios tambin se envan a los pares LDP. Downstream on Demand: en el que el LSR anuncia una etiqueta para un prefijo cuando el LSR vecino se lo solicita. El LSR solicitar una etiqueta en el momento que aprenda una nueva ruta para dicho prefijo, de esta forma un LSR puede contestar a una peticin de mapeo de etiquetas inmediatamente, sin esperar al mapeo de etiquetas que le enve algn vecino para completar su tabla de etiquetas, adems el LSR debe mantener un dialogo constante con otros LSR para poder responder adecuadamente a cambios de routing en la red, ya sea por cambios de topologa de la misma o por incidencias en los enlaces. Este mtodo se usa principalmente cuando se quiere conservar el valor de las etiquetas (por ejemplo, en un conmutador ATM). La ventaja principal en este caso es que se asignan slo las etiquetas que se requieren para reenviar paquetes de datos. Una desventaja es que si se producen cambios de routing que afectan al siguiente salto para un destino dado, debe obtenerse una nueva etiqueta para el siguiente salto antes de que los paquetes etiquetados con esa etiqueta puedan enviarse.

Eliminado: e Eliminado: a

2.2 Mensajes LDPLos mensajes LDP se dividen en cuatro categoras: Los mensajes Discovery, con estos mensajes los LSR anuncian su presencia en la red mandando mensajes Hello peridicamente. Todos los mensajes Discovery son enviados sobre una conexin TCP. Los mensajes Session, se usan para establecer, mantener y terminar sesiones entre pares LDP. Cuando un LSR establece una sesin con otro LSR lo har mediante el procedimiento de inicializacin sobre transporte TCP que se explicar ms adelante. Cuando el proceso de inicializacin se completa satisfactoriamente se dice que los LSR son un par LSR y podrn intercambiar mensajes Advertisement. Los mensajes Advertisement, se usan para crear, modificar y anular el mapeo de informacin en los FEC. Los mensajes Notification, se usan para proporcionar informacin preventiva y de error.

Eliminado: a Eliminado: a

Los diferentes tipos de mensajes incluidos en cada una de estas categoras se pueden consultar en la RFC-3036

18


2.2.1 Formato de los mensajes LDP Todos los mensajes LDP tendrn el mismo formato, puede verse en la siguiente figura:

2 Bytes

2 Bytes

U

Tipo del mensaje

Longitud del mensaje

Identificador del mensaje Parmetros obligatorios

Parmetros opcionales

Figura 2.2 Formato de los mensajes LDP Donde los diferentes campos que aparecen en la figura anterior significan lo siguiente: Bit U: Mensaje desconocido. Si el bit U tiene como valor 0 se enva una notificacin al originador del mensaje, en el caso de que el bit U tenga como valor 1, el mensaje ser ignorado. Tipo Mensaje: como su propio nombre indica es el tipo de mensaje. Longitud Mensaje: como su propio nombre indica es la longitud del mensaje incluyendo el identificador y los parmetros opcionales del mensaje. Identificador mensaje: es el identificador del mismo. Parmetros obligatorios del mensaje: Tiene longitud variable. Hay mensajes LDP que no tienen parmetros obligatorios. Parmetros opcionales del mensaje: Campo de longitud variable.Con formato: Sangra: Izquierda: 17,85 pto, Sangra francesa: 17,85 pto, Con vietas + Nivel: 1 + Alineacin: 18 pto + Tabulacin despus de: 36 pto + Sangra: 36

Eliminado: i

19

Captulo 3: VPN-MPLS. Redes privadas virtuales MPLS

3. VPN-MPLS. Redes Privadas Virtuales MPLS.A continuacin se van a introducir los principales conceptos e implementaciones de redes privadas virtuales (VPN) utilizando MPLS. Una VPN se puede definir como un conjunto de sites que comparten una informacin de routing comn (tabla de routing). Un site puede pertenecer a varias VPN como se ve en la figura siguiente:

Site-1

Site-2

VPN-A

VPN-B

Site-3

VPN-C

Site-4

Figura 3.1. Correspondencia Sites-VPN. Las VPN son utilizadas por las empresas para desplegar y administrar en sus redes servicios de valor aadido incluyendo aplicaciones, servicios de telefona, etc La funcionalidad de IP VPN para MPLS permite en una red desarrollar servicios de VPN a nivel 3 en un backbone nicamente IP, en el que los clientes pueden disponer de una red privada, de una forma escalable y segura para su comunicacin interna. Tambin se pueden necesitar VPNs de gestin por parte del proveedor de servicio para controlar el servicio a sus clientes pero en las que no se pueden conectar los clientes. La seguridad es un aspecto primordial en las VPN. En redes IP tradicionales existen dos tecnologas que se emplean para establecer tneles que pueden coexistir con la conmutacin de etiquetas mediante MPLS: IP Security: proporciona autenticacin del cliente en la red y cifrado de datos opcional. Su principal desventaja es que slo soporta protocolo IP.

20


Generic Route Encapsulation: es ms rpido y sencillo y adems soporta mltiples protocolos adems de IP (IPX,...). Sin embargo no proporciona seguridad con lo que no es muy adecuado para servicios VPN que discurren a travs de Internet.

A continuacin se va a describir la arquitectura MPLS VPN, las principales opciones de diseo, operaciones posibles a realizar en estas redes y terminologa relacionada. Las redes tradicionales de routers se implementaron originalmente con enlaces punto a punto dedicados, que conectaban los sitios de los clientes. El coste de tales redes era alto debido a que: Los enlaces dedicados punto a punto no permiten cualquier infraestructura que comparta el proveedor de servicio asignando estadsticamente un tiempo a cada uno de los diferentes clientes, lo que resulta en altos costes para el cliente final. Cada enlace requiere un puerto dedicado en un router, con el coste que ello supone.

Las redes VPN se introdujeron con X.25 y Frame Relay, tecnologas que utilizan circuitos virtuales para establecer conexiones extremo a extremo sobre una infraestructura en un Internet Service Provider compartido. Los circuitos virtuales pueden ser: PVC: Circuitos Virtuales Permanentes. Previamente establecidos manualmente o mediante herramientas de gestin de red (por ejemplo Conection Manager en Cisco). Siempre estar activo. SVC: Circuitos virtuales conmutados. Se configuran bajo demanda a travs de una solicitud de establecimiento de llamada del dispositivo CE con el que se crear un circuito no permanente entre el dispositivo CE y el PE.

Las ventajas que se obtienen con el modelo de VPN MPLS frente a los modelos tradicionales son: Es una plataforma que permite un rpido y poco costoso despliegue de los servicios IP de valor aadido, entre los que se incluyen intranets, extranets, voz, servicios multimedia y comercio electrnico. Es decir, mayor flexibilidad que las VPN de nivel 2 (Intranets o Extranets) Privacidad y seguridad, al igual que en las VPN de Capa 2, pero limitando la distribucin de las rutas de las VPN, estas solo se distribuirn a los routers que pertenezcan a cada VPN. Es decir, soporte de direccionamiento privado (ver RFC 1918) en las redes de los clientes permitiendo el solapamiento del espacio de direccionamiento de los clientes. Se mejora la escalabilidad del provisionamiento para el proveedor. Es mucho ms sencillo provisionar un nuevo cliente ya que simplemente hay que configurar un nico enlace entre su router y un router PE para permitir el acceso a la red MPLS. En las VPN tradicionales se tendra que establecer un enlace entre la nueva sede y todas las dems sedes. Esto permite implementar escenarios en los que existan miles de sites para cada VPN y las VPN clasificadas segn las clases de servicio IP (QoS) proporcionadas, y

21


con diferentes prioridades. Estas clasificaciones por clases de servicio pueden darse tanto para servicios ofrecidos por una VPN entre sus diferentes sites, como entre VPN. Existencia de mecanismos IP QoS. Simplificacin del routing para el cliente.

Sin embargo las VPN tradicionales todava comparten aspectos con las VPN actuales: Los enlaces dedicados se reemplazan con una infraestructura comn que emula enlaces punto a punto para el cliente, resultando en una comparticin estadstica del proveedor de servicio. Esta comparticin de infraestructura habilita al proveedor de servicio para ofrecer conectividad a bajo precio, con lo que los costes operacionales de los clientes disminuyen.

A continuacin se va a ver un ejemplo para estudiar la terminologa:

Figura 3.2. Terminologa VPN MPLS.

22


Se pueden definir los siguientes elementos dentro de un servicio VPN sobre una nube MPLS: Red P: Red del proveedor del servicio. Infraestructura que el proveedor de servicio utiliza para ofrecer servicios VPN a los clientes. Red C: Red del cliente. Es la parte de toda la red del cliente que est exclusivamente bajo el control del cliente. Sitios de clientes (VPN Sites): Equipos propios de la red del cliente.

Y en cuanto a los dispositivos que habilitan a la VPN para que funcione: Router CE: Router del cliente que conecta el site del cliente a la red del proveedor de servicio. Dispositivos PE: Dispositivos del proveedor de servicio en los que se conectan los dispositivos del cliente. Por ejemplo en redes WAN suelen ser Switches de Frame Relay. Dispositivos P: Pertenecen al proveedor de servicio y slo proporcionan transporte de datos a travs del backbone MPLS y no poseen conexiones directas con los clientes.

Los servicios VPN MPLS pueden ofrecerse basndose en dos modelos principales: VPN overlays: El proveedor de servicio proporciona enlaces virtuales punto a punto entre los sites de los clientes pero no participa en el routing de cliente. Este modelo presentar diversos problemas como el de ancho de banda, sobrecarga de encapsulacin, y una necesidad de un mallado completo (full mesh) para implementar las rutas ptimas. VPN peer-to-peer: El proveedor de servicio participar en el routing del cliente. Se utilizarn filtros de paquetes en los routers PE para aislar a los clientes. El proveedor de servicio asignar parte de su espacio de direcciones y gestionar los filtros en los PE para asegurar que todos los equipos de cliente tienen conectividad.

La filosofa de las VPN se debe basar en la presencia fundamental del protocolo IP entre las distintas sedes de un cliente. Cada sede debe saber encaminar su trfico hacia las dems con lo que lgicamente debe existir un protocolo de routing que distribuya la informacin de los diferentes prefijos pero que no permita que se inmiscuya trfico perteneciente a redes de otros clientes. Si existe un cliente con dos sedes que quieran crear una VPN entre ellas se debe actuar de la siguiente manera: Las sedes de los clientes tendrn asignado previamente un rango de direcciones privadas (por ejemplo 47.x.y.z) que pueden estar incluso reutilizadas en las distintas sedes para reducir el nmero de direcciones IP que necesita el cliente. Los equipos del ncleo MPLS no van a encaminar los paquetes en base a direcciones IP puras y adems no sera lgico

23


desde el punto de vista del cliente que se le ofreciera un nuevo servicio en el que el cliente tuviera que modificar su direccionamiento para poder aceptar este servicio. Las direcciones de los clientes slo las van a conocer los equipos PE. Si los dems routers MPLS no pueden ver el direccionamiento de los clientes los equipos PE tienen que saber de alguna manera hacia qu VPN est dirigido cada paquete. En este momento es cuando entra en juego la facilidad de apilar etiquetas existentes en MPLS. Haciendo uso de la figura anterior se va a explicar el funcionamiento bsico del servicio VPN en una nube MPLS, por ejemplo si se enva trfico entre las sedes de la VPN A, el PE 4 introduce en el paquete la etiqueta que indique cul es la VPN y despus introduce la etiqueta bsica MPLS que le indica cmo llegar al PE 3. La etiqueta de VPN le dir a PE 4 por qu interfaz debe sacar el paquete. La pila de etiquetas quedara de la siguiente manera.

Etiqueta MPLS Etiqueta VPNDatagrama IP Figura 3. 3. Pila de etiquetas VPN MPLS Lgicamente debe existir un protocolo (LDP u otro) para intercambiar estas etiquetas VPN y que ser independiente o no del protocolo que se utilice para distribuir las etiquetas MPLS bsicas. El backbone MPLS slo ver la etiqueta MPLS. El problema de la seguridad no es tal en las VPN MPLS ya que se asegura que slo cada cliente va a ver su direccionamiento. Los routers PE tienen que comprobar que los prefijos de cada VPN slo se enviarn hacia las dems sedes de la VPN y no se mezclarn con los otras VPN. Los identificadores ID de las VPN (se vern en el captulo de diseo prctico de un escenario real) no pueden ser objeto de spoofing (que algn intruso simule que es un cliente), ya que las etiquetas se asignan dinmicamente. El modelo VPN tambin permite, dependiendo de las restricciones que se impongan, que parte del trfico de una de las VPN se vea en otra pero en las dems no,... Por lo tanto se podr permitir que las sedes de la VPN B reciban todos o parte de los paquetes de la VPN A y a su vez impedir que este trfico llegue a las sedes de la VPN C. Como puede apreciarse, el modelo tiene gran flexibilidad. La construccin de las VPN se basa principalmente en el intercambio de las communities. Las communities van a ser parmetros identificadores de cada conexin. Este concepto proviene de BGP, protocolo de routing externo entre diferentes sistemas autnomos, en el que mediante la combinacin de estas communities se puede conseguir mltiples restricciones, permisos, filtros,... a la hora de enviar trfico entre dos sistemas autnomos.

24


Una extensin de BGP (Multiprotocol BGP) va a ser de hecho el protocolo de distribucin de las etiquetas VPN y los ID van a ser communities. Las communities principales de las VPN son: Route Distinguiser RD y Route Target RT. Route Target se encargar de controlar el routing de la VPN. Se pueden colocar varios RT en cada router. Route Distinguiser sirve para evitar la duplicidad de las direcciones IP. Cada router slo importar los prefijos que vea con su RD y no podr importar rutas con otros RD. El funcionamiento bsico es que el RD se usa para generar un prefijo VPNMPLS que distingue unas VPN de otras, de forma que cada VPN tenga un prefijo nico y univoco dentro de la nube MPLS.

El proceso de distribucin de routing comienza entonces con MBGP entre los routers PE, mientras que para la distribucin desde el router CE al PE se utilizar algn IGP (OSPF, RIP,...), BGP o sencillamente routing esttico. Para llegar desde un PE a otro se utilizar MPLS va IGP atravesando los routers P. Por ltimo los PE egress importarn el routing desde MBGP y a su vez lo enviarn al CE va IGP, routing esttico o BGP.

Figura 3.4. Distribucin de routing entre PE-CE.

En las VPN se suele utilizar el Penultimate Hop Popping, para comprender mejor este concepto se usar un ejemplo basado en la figura 3.2, si se quiere enviar trfico desde CE2 a CE3 por ejemplo a travs de PE3 P - P se puede hacer que PE3 le indique a P que si quiere entregarle un paquete antes le suprima la etiqueta. Si la ruta fuese la PE3 P, que por otra parte sera la ruta de camino ms corto, no interesara habilitar PHP porque slo se tendra un router P y entonces el envo de paquetes se convertira en IP puro. En cada router PE se van a crear una serie de instancias de routing diferentes para cada VPN llamadas tablas de routing virtuales (VRF). Sera como crear dentro de cada router PE mltiples routers virtuales. Podemos ver un ejemplo de configuracin de una VRF en el captulo de escenario real de una red MPLS.

25


Los pasos a seguir para la configuracin de una VRF son: Definir las VRF. Configurar las listas de importacin / exportacin. Asignacin de las interfaces a VRF. Configuracin de los contextos de routing. Configuracin del Multiprotocol BGP para la distribucin de las rutas BGP.

Cada VPN est asociada a una o ms tablas VPN routing/forwarding (VRF). Una VRF define a cada miembro de una VPN que cuelga de cada router PE. Es decir, una VRF consiste en una tabla de rutas IP, un conjunto de interfaces que usan esta tabla de forwarding y un conjunto de reglas y parmetros del protocolo de routing que gestionan la informacin que est incluida en la tabla de routing. Las VRF se generan a partir de la tabla de forwarding que se ha creado al activar el protocolo de routing interno en la nube MPLS. Un site, como se vi al comienzo de este documento, no tiene por que pertenecer a una nica VPN, sino que puede pertenecer a varias VPN. Sin embargo un site solo puede tener asociada una nica VRF donde vendrn reflejadas todas las rutas disponibles para los paquetes que se generan hacia y desde ese site.

3.1 Topologa Hub-and-spokeEn una topologa Hub and Spoke todas las sedes de una empresa actan como spokes enviando todo el trfico que quieren intercambiar entre ellas hacia la sede central de la empresa que actuara como Hub, esta ltima, distribuir el trfico que le llega hacia sus destinos segn sus polticas de routing. Normalmente se suele utilizar esta topologa de red para VPN cuando se tiene un acceso Internet de empresa, firewalls, granjas de servidores, etc, todo ello sito en la sede central, de ah que sea esta sede la que acte como Hub. Es similar a una topologa en estrella. En cualquier caso, cuando se implementa esta topologa de red para una VPN/MPLS es necesario que la sede que acta como Hub conozca todas las rutas para poder llegar a todos y cada uno de los spokes que pertenecen a esa VPN. Esto se consigue haciendo que los spokes exporten sus rutas hacia el Hub y este a su vez hace que el resto de spokes puedan importar las rutas de los dems, es decir, el Hub exporta las rutas que ha importado de un spoke a los dems spokes de la misma VPN. De esta forma, con esta topologa se asegura que todo el trfico que se genere entre spokes pase siempre por el Hub. Esto se hace mediante los Route Target y Route Distinguiser que se han explicado anteriormente. Normalmente no existir conectividad directa entre spokes sino que solo tendrn conectividad con el Hub y este ltimo tendr conectividad con todos, debido a las tablas de rutas y a la VRF de la VPN a la que pertenecen el Hub y los spokes.

26


Sede Central (HUB)

Sede Remota (Spoke)

Red MPLS

Sede Remota (Spokes)

Sede Remota (Spokes)

Figura 3.5. Topologa Hub & Spoke

Existe la posibilidad de que el router que tiene la funcionalidad de Hub en esta topologa de red pueda sufrir algn tipo de incidencia que lo pueda dejar total o parcialmente fuera de servicio. Esto se puede prevenir con alguna de las soluciones siguientes: Una topologa Hub and Spoke simple como la de la figura anterior se puede mejorar aadiendo un router mas en la sede central que acte como Hub, es decir, desdoblando esta funcionalidad, de esta forma se tendr redundancia ganando sobre todo seguridad en el servicio, se puede ver un ejemplo en la figura 3.6. Otra alternativa que ofrece la topologa Hub and Spoke es con un router de backup para la sede central, en este caso se enlazara con la sede central (duplicando los enlaces que tiene en el acceso a la nube MPLS) mediante conexiones de alta velocidad y con un elevado ancho de banda como se puede apreciar en la figura 3.7.

-

La forma mas simple de configurar una VPN-MPLS con topologa Hub and Spoke sera asignando el mismo RD (Route Distinguiser) a cada VRF de cada una de las sedes que acten como spoke. De esta forma el spoke no intercambiar informacin de routing directamente con el resto de spokes y tampoco sus Route Targets.

27


HUB 1

Sede Central

HUB 2

Red MPLS

Sede Remota (Spoke)

Sede Remota (Spokes) Sede Remota (Spokes)

Figura 3.6. Topologa Hub & Spoke con dos routers centrales.

Sede Central (HUB)

Sede Central (HUB)

Red MPLS

Sede Remota (Spoke)

Sede Remota (Spokes) Sede Remota (Spokes)

Figura 3.7. Topologa Hub & Spoke con dos Sites centrales.

28


A continuacin se enumeran los pasos que se deben seguir para llevar a cabo la configuracin de una topologa bsica Hub and Spoke: En todas las sedes que componen la VPN, se configurara una ruta esttica entre los equipos CE y los equipos PE, esto implica que todo el routing se har entre los equipos PE asociados a cada sede de la VPN. Una vez se han creado todas las rutas estticas para que el trafico de las sedes remotas pueda ser enrutado por la nube MPLS, se crea la VRF asociada a la VPN, esto se hace en los equipos PE que como se ha indicado anteriormente son los encargados del routing de los paquetes pertenecientes a la VPN. De esta forma las subredes que unen a los equipos PE con los equipos CE han pasado a la tabla de routing de la propia VRF, con lo que est asegurada la conectividad local. En este tipo de VPN cada equipo PE debe tener una ruta esttica apuntando a aquello que tiene localmente accesible a travs de su propio CE. Pero una vez que se configuran los equipos PE hay que tener en cuenta que no todos tienen la misma funcionalidad, pues ya se sabe que al menos uno de ellos tiene funcionalidad de Hub y el resto de Spokes. Por lo tanto en los equipos que tienen funcionalidad de Spoke hay que configurar una ruta esttica entre este y el CE local para tener conectividad total entre ellos. En el caso del PE que tiene funcionalidad de Hub, hay que tener en cuenta que todo lo que no le propaguen sus vecinos iMBGP (los otros equipos con funcionalidad PE) supondr que se podr alcanzar a travs del CE local. Recordar que previamente a la configuracin de la VPN ha habido que configurar OSPF y BGP (aunque podran haberse utilizado otros protocolos de routing interno). Por ultimo para asegurarse de que todos los prefijos pertenecientes a cada una de las sedes que forman parte de la VPN puedan ser propagados entre los equipos PE con funcionalidad spoke y el/los equipos PE con funcionalidad Hub, hay que configurar iMBGP en todos ellos. Una vez establecidas las sesiones iMBGP con el resto de equipos PE y verificada la conectividad local con los integrantes de la VPN faltara propagar los prefijos locales de los respectivos clientes al resto de equipos PE para que stos sepan encaminar los paquetes hacia dichos prefijos. Como cada equipo PE conoce el prefijo del equipo CE local mediante una ruta esttica entonces bastar con redistribuir dicha ruta esttica en el iMBGP.

3.2 Topologa Partial o Full-MeshLos servicios de redes privadas virtuales estn orientados claramente hacia el cliente, por y desde el punto de vista de cliente, pero no en todos los casos se puede implementar cualquier tipo de topologa de red por motivos estructurales de la empresa, distribucin de

29


sedes de la misma, tipo de aplicaciones y servidores utilizados y su disposicin en las distintas sedes de la empresa, etc. En resumen, por los elevados costes que puede significar la implementacin o no de un tipo de topologa de red determinado, como puede ser el caso de la topologa Hub and Spoke que se ha descrito brevemente en el apartado anterior. Por estos y otros motivos, en muchos casos, se buscan otras soluciones topolgicas para implementar el servicio VPN en una empresa. Estas soluciones son topologas totalmente o parcialmente malladas. Existe una topologa Full-Mesh cuando cada nodo de una red tiene conectividad directa con el resto de nodos de la red. Normalmente estas topologas se implementan en los backbones de las redes. Existe una topologa Partial-Mesh cuando solo algunos nodos de la red tienen conectividad directa con el resto de nodos de la red, es decir, algunos de los nodos tendrn conectividad directa con el resto de nodos y otros nicamente estarn conectados a uno o dos nodos en la red de forma directa. Una topologa Partial Mesh normalmente se implementa en redes de acceso que a su vez estn conectadas a redes con topologa Full-Mesh. Podemos ver un ejemplo de red con topologa Partial-Mesh en la figura 3.8 y de red con topologa Full-Mesh en la figura 3.9.

B A

C

D H G E F

Figura 3.8. Topologa parcialmente mallada o Partial-Mesh.

30


CE CE

PE PE

CE

CE P P

P

P

PE CE CE CE PE

Figura 3.9 Topologa totalmente mallada o Full-Mesh. Hay que hacer notar, que una topologa en Full-Mesh lleva inherente un alto coste debido al gran nmero de enlaces que son necesarios para su implementacin. Viene expresado por la siguiente formula. Donde VCs es el nmero de enlaces y n es igual al nmero de routers que pertenecen a la red: VCs = [(n-1) x n] / 2] Tanto en las redes totalmente malladas como en las parcialmente malladas el nmero de problemas e incidencias en la red es directamente proporcional al crecimiento de la misma. Es labor de los departamentos de ingeniera de red de las empresas que gestionan las redes el dimensionar las mismas en funcin del trfico y de las necesidades de la empresa, para as evitar tanto costes innecesarios como problemas de red.

3.3 Topologas HbridasUna topologa de red se dice que es hbrida cuando combina diferentes tipos de topologa en una misma red. Una topologa de red de este tipo es muy comn en grandes redes, en redes WAN por ejemplo. Debido a que cada topologa de red tiene sus ventajas y sus inconvenientes se pueden combinar diferentes topologas para intentar recoger las ventajas de cada una en una nica topologa, es decir, en una nica red.

31


Por lo general cuando se implementa el servicio VPN sobre una red de grandes dimensiones lo que se hace es combinar diferentes tipos de topologas de red, es decir, se puede usar una topologa Hub and spoke sobre una topologa parcialmente o totalmente mallada. Cara a las diferentes sedes, la topologa del backbone de la red es transparente para ellas y les es independiente si est parcialmente o totalmente mallado. Las sedes nicamente sabrn que se comunican unas con otras. Para evitar costes innecesarios se suele configurar la parte de acceso al backbone con una topologa Hub and Spoke y el propio backbone con una topologa total o parcialmente mallada dependiendo del nmero de routers que lo formen y el nmero de enlaces que sean necesarios. A continuacin se puede ver una figura de una red con topologa hbrida en la que conviven dos topologas diferentes, para la parte de acceso al backbone habr una topologa totalmente mallada y para el backbone se ha optado por una topologa parcialmente mallada. De esta forma se limita el trfico que circulara por el backbone de la red pero a costa de un mayor nmero de enlaces en la parte de acceso, con el consecuente incremento de coste que ello puede suponer. Este es solo un ejemplo pero existen mltiples combinaciones de topologas de red aunque siempre se usara la que ms se adecue a las necesidades econmicas y de red en cada caso. En la figura 3.10 se muestra un ejemplo de una organizacin como la mencionada anteriormente:

1 2

A

B

C

4

5 H G 3 F E 6 D

Figura 3.10 Ejemplo de topologa Hbrida.

32

Captulo 4: QoS. Calidad de servicio en redes MPLS

4. QoS. Calidad de servicio en redes MPLS.4.1 La necesidad de aplicar una QoSLa aparicin de nuevas aplicaciones en las redes actuales como la creacin de redes corporativas entre clientes, el trfico en tiempo real de videoconferencias, la transmisin de video de alta definicin,... hace necesario establecer una diferencia en el tratamiento del trfico para los operadores. Ya no existe slo el tpico trfico relacionado con el paradigma de best effort, es decir, sin restricciones ni parmetros mnimos de calidad y que se enva cuando se puede, como las consultas normales a pginas web, las solicitudes de transferencia de ficheros va FTP o el envo de correo electrnico, con lo que es necesario asignar unos compromisos de niveles de servicio que garanticen una determinada fiabilidad de la red, independientemente de si la cantidad de trfico es elevada o no e incluso de los fallos de la red. En este captulo se tratarn los sucesivos pasos que se han dado para dotar de distintas calidades de servicio al trfico de las redes IP y la funcionalidad que presenta MPLS para asignar o no prioridad a segn qu tipo de trfico. En la tabla siguiente se pueden ver los diferentes requerimientos dependiendo del tipo de aplicacin:

Caracterstica/ Tipo trfico Ancho de banda Sensibilidad de eliminacin de paquetes Sensibilidad al retardo Sensibilidad al jitter

de Voz Entre bajo y moderado Bajo Alto Alto

FTP Entre bajo y moderado Alto Bajo Bajo

ERP (Enterprise Resource Planning) y trfico crtico

Bajo Entre bajo y moderado Entre bajo y moderado Moderado

Figura 4.1. Requerimientos en funcin del trfico. El trfico de voz necesitar un retardo bajo, una mnima variacin de este retardo para que la conversacin se pueda entender, mientras que la prdida de algunos paquetes no afecta demasiado a la calidad de la conversacin. El trfico de datos puede presentar un retardo y una variacin del retardo sensiblemente mayor al trfico de voz, mientras que es tolerante a la variacin del ancho de banda. El trfico de vdeo puede soportar un retardo mayor que el de voz, pero la prdida de paquetes puede afectar considerablemente a la calidad del servicio.

33


Por tanto para conseguir que la red opere de manera eficiente, cada aplicacin se debe considerar en trminos de sus requerimientos de calidad de servicio y agruparse en un nmero determinado de clases. Una de estas clases no tendr mayores requerimientos que los tradicionales del trfico best effort, pero con trfico como el de vdeo,... existirn otras clases que requieran una calidad de servicio mayor. En la figura siguiente se puede ver la evolucin temporal de las diferentes tcnicas para aplicar QoS a las redes:

Figura 4.2. Pndulo QoS IP Las primeras tecnologas que se crearon para dotar de cierto control de QoS a las redes fueron TOS (Tipo de servicio) e Int-Serv (Servicio Integrado). Las limitaciones de estas tecnologas restringieron bastante su uso, y han sido incapaces de proporcionar un adecuado entorno de trabajo para provisionar servicios que cumplan los SLA (Service Level Agreements). Una de estas primeras tecnologas permiti a las redes distinguir entre el trfico de control y el trfico de usuario. Esta tcnica proporcionaba una clasificacin de servicio y un nmero reducido de clases de servicio, basndose en el campo TOS (tipo de servicio) definido en la cabecera de los paquetes IP. Lo que sucedi fue que estas clases de servicio se definieron sin tener muy claras las necesidades reales de los usuarios. Otra tcnica que se desarroll posteriormente fue Int-Serv. Int-Serv proporciona un servicio extremo a extremo entre los hosts para aplicaciones punto a punto y punto a multipunto. En Int-Serv, la aplicacin inicia una sesin bajo demanda con la red utilizando el protocolo RSVP (Resource Reservation Signaling Protocol). Esta sesin identifica los requerimientos de servicio de la aplicacin, incluyendo informacin como el ancho de banda, el retardo y el origen de los datos.

34


El objetivo de Int-Serv ha influido en las propiedades del protocolo RSVP tradicional, como el estado de las conexiones o las solicitudes de recursos. Mientras estos aspectos de Int-Serv lo hicieron un protocolo potente, habilitndolo para garantizar los requerimientos mnimos de cada aplicacin, tambin haba que pagar un alto precio en trminos de procesamiento y sealizacin. El RSVP tradicional requiere una mquina de estados que incluye temporizadores para cada sesin y clasificadores para cada router, lo que hace que la capacidad de memoria y procesamiento sea muy alta. En un router de backbone Internet pueden establecerse muchas sesiones RSVP con otros hosts, y estos routers no tienen los recursos necesarios para tratar todas las sesiones. Esta limitacin restringe generalmente el empleo de Int Serv a los routers frontera de la red. Esto reduce la efectividad, ya que no se asegura que los dems routers, aparte de los routers frontera, cumplan los mismos requisitos para conseguir una calidad de servicio extremo a extremo. La principal ventaja de Int-Serv/RSVP es que el establecimiento de la QoS se realiza automticamente. El nico parmetro a provisionar manualmente es el ancho de banda asignado por RSVP en las interfaces. Por el contrario, presenta varios inconvenientes: La sobrecarga correspondiente a la sealizacin para la QoS y a la informacin de estado en el caso de redes de gran tamao es muy alta. Se deben enviar mensajes constantes de refresco de la informacin de estado.

Ms adelante se desarroll el mecanismo Diff-Serv. Al contrario que en Int-Serv, el objetivo de Diff-Serv no es proporcionar un servicio extremo a extremo para la aplicacin, sino crear un conjunto de building blocks que sirvan como base para los servicios extremo a extremo. Diff-Serv parte como una aproximacin similar al TOS pero est mejor dirigido a las necesidades de las aplicaciones actuales. Es lo suficientemente escalable como para poderse configurar tanto en los routers frontera como en los routers de core. En vez de establecer estados para cada sesin, cada paquete lleva la informacin sobre cada clase de servicio. Se pueden combinar los building blocks para conseguir un servicio final hacia el cliente. Diff-Serv define un nmero determinado de modelos de tratamiento de datos, conocidos como Per Hop Behaviour PHB (los PHB son un tipo de building blocks), que pueden aplicarse a los paquetes en cada nodo. El PHB se usa para identificar el tratamiento que se le va a dar en cada nodo. Este tratamiento incluye la seleccin del tipo de cola donde se van a almacenar los paquetes, la disciplina de planificacin que se aplicar en el interfaz de egress (ingreso en la red), y los umbrales de congestin. Por ejemplo, un determinado modelo de tratamiento de datos puede seleccionar una cola con una prioridad alta y sin embargo un umbral de congestin bajo, y con un esquema para gestionar las congestiones. Si se le da a un paquete un tratamiento similar a ste en cada uno de los nodos a travs de la red, puede conseguirse un efecto extremo a extremo. Los paquetes se marcan para identificar el tipo de tratamiento

35


que van a recibir utilizando el byte DS. Este byte DS reemplaza al byte de TOS de la cabecera IP. Fue elegido este byte debido a que originalmente se usaba para indicar cul era la informacin de servicio, pero como se ha dicho antes, su uso ha estado limitado. Dentro de este byte DS se define un campo llamado DSCP (Diff-Serv CodePoint) que identifica el comportamiento o el tratamiento que se debe aplicar al paquete dentro de cada nodo de la red. Para conseguir un comportamiento efectivo cada nodo aplicar el mismo tratamiento.

Figura 4.3. Byte DS en un paquete Ipv4. El campo DSCP ser de 6 bits, mientras que los otros 2 bits actualmente no se utilizan (bits CU en la figura 4.3) y estn reservados para el futuro. Los 6 bits se emplean como una tabla indexada para identificar el PHB, con lo que se pueden obtener hasta 64 cdigos independientes que se mapean en cada nodo para determinar qu tratamiento se va a aplicar. Dependiendo de este mapeo es posible tener mltiples cdigos que seleccionan el mismo comportamiento. Los primeros 3 bits de estos 6 forman el CSC (Class Selector Codepoint).

36


A continuacin se detallan los PHB definidos en Diff-Serv: Expedited Forwarding (EF): El PHB EF proporciona bajas prdidas, bajo jitter y un retardo bajo dentro de cada nodo. Para lograr este retardo se define que la tasa agregada de recepcin de datos mxima no debe ser mayor que la tasa de transmisin mnima disponible para este PHB. Con este requerimiento se asegura que no se completar la cola para este servicio dentro del nodo y que el retardo y la variacin del retardo sean mnimos. Los valores de DSCP recomendados para EF son 101110. Assured Forwarding (AF): El grupo de PHB define N clases independientes de encaminamiento (actualmente se encuentran definidas 4) denominadas AF1 hasta AFn. Dentro de cada una de las clases de encaminamiento aparecen M subclases (actualmente 3 definidas) que representan los niveles de la probabilidad de entrega. El nivel ms alto de probabilidad de entrega debe tener una probabilidad de entrega mayor que el segundo nivel para hacer frente a casos de congestin. Cada clase de encaminamiento dentro de este grupo se configura independientemente: espacio de buffer, capacidad de entrada mnima de los routers egress,... Los niveles de probabilidad de entrega se pueden ver tambin como niveles de probabilidad de eliminacin de paquetes (drop), como se observa en la figura siguiente perteneciente a la tecnologa Cisco. En situaciones especiales, como cuando el trfico excede el CIR configurado (en caso de estar configurado Frame Relay por debajo de MPLS por ejemplo) los nodos se basarn en estos niveles de prioridad de drop o de entrega para descartar o no los paquetes.

Figura 4.4. Definicin de grupos AF PHB. Default Behaviour (DE): El PHB DE identifica el trfico best effort existente. Este comportamiento define que el nodo entregar tantos paquetes best effort como sea posible, tan pronto como sea posible. Por supuesto, otros comportamientos definidos presentan mejores requerimientos en cuanto a la fiabilidad de entrega, con lo que las frases tantos paquetes como sea posible y tan pronto como sea posible estn supeditadas a los dems tipos de PHB.

37


Otros PHB: Las dems combinaciones de bits de Class Selector (CS) crean un conjunto de cdigos de comportamiento PHB, adems de los que ya se han comentado, para conseguir una compatibilidad hacia atrs con el byte TOS de IPv4 que se utiliza como byte DS. Estos tipos de PHB aseguran que los routers que implementen TOS proporcionarn un comportamiento compatible con los routers que implementen Diff-Serv con los mismos valores. Algunas otras combinaciones de los bits CSC todava no se han asignado a ningn PHB, a la espera de crear nuevos PHB en un futuro con restricciones de seguridad y probabilidades de entrega todava mayores. Otros se han establecido para usos locales al equipo o experimentales.

Figura 4.5. Correspondencia TOS de IP vs DSCP.

4.2 Condicionantes del trfico: El otro lado de Diff-ServYa se ha visto que el DSCP identifica el comportamiento que se debe aplicar en cada nodo. En un dominio Diff-Serv, el DSCP debe establecerse en cada paquete para los nodos para determinar el comportamiento requerido. Por tanto, el nodo en extremo de entrada a la red Diff-Serv (Ingress) debe asegurarse de que este campo DSCP se ha establecido apropiadamente para cada paquete. El nodo debe decidir cmo los paquetes de los diferentes PHB tienen que ser encaminados fuera del enlace. Los mecanismos de planificacin pueden considerar rdenes de prioridad entre las clases, pero deben controlar el acceso al ancho de banda de cada enlace para cada clase. El trfico de las clases de mayor prioridad se enva antes que el de clases de menor prioridad, con lo que se podra correr el peligro de inanicin de las clases de menor prioridad, y que el trfico perteneciente a estas clases nunca se llegue a enviar, con lo que

38


es necesario aplicar un shapping (limitacin del ancho de banda utilizado) a los niveles de trfico. Se utilizan diversos mecanismos para obtener estas limitaciones. FIFO (First in First Out): Es el mecanismo ms sencillo de implementar. Sin embargo, en FIFO puede ocurrir que un paquete con prioridad alta se acumule detrs de miles de paquetes pertenecientes a trfico best-effort. RR (Fair Queing o Round Robin): Se trata de una planificacin sencilla round robin para colas mltiples. Esto hace que el ancho de banda disponible se reparta de manera justa entre las diferentes colas. Uno de los problemas de este tipo de mecanismos es que las rfagas de un gran nmero de paquetes requieren una comparticin muy grande del ancho de banda disponible. Weighted Round Robin (WRR): Con este mecanismo se consigue un acceso ponderado (weighted) al ancho de banda disponible para cada clase organizndose la distribucin de ancho de banda en round-robin. Weighted Fair Queing (WFQ): Ayuda de manera similar a WRR a distribuir el ancho de banda disponible sobre las clases definidas. Utiliza una combinacin de informacin de temporizacin y ponderacin para seleccionar a qu cola debe entregarle paquetes. La distribucin del ancho de banda est en todo momento controlada por el sistema de ponderacin, que tambin se encarga de en caso de necesidad hacer variar el retardo si hubiera clases infrautilizadas. Class Based Queing (CBQ): CBQ es un trmino general que se refiere a cualquier mecanismo basado en clases. CBQ puede permitir que la capacidad no utilizada se distribuya segn un algoritmo diferente al de menor peso de ancho de banda. Por ejemplo, podra haber un tipo de peso diferente que se configure para una capacidad mayor que la media, o puede depender de la carga de trfico en cada clase, o de la prioridad,... Las clases agrupan trfico con alguna caracterstica comn: interfaz de entrada o salida, lista de control de acceso, trfico en tiempo real, bits EXP MPLS, valor de precedencia IP o DSCP,...

Existen otras condiciones que se pueden aplicar al uso de los diferentes PHB. Por ejemplo, el PHB EF tiene un requerimiento en el que la capacidad de salida de un enlace para este comportamiento es mayor que la tasa de entrada. Ya que la definicin de un PHB puede especificar distintos perfiles de trfico, el nodo de entrada hacia el dominio Diff-Serv debe proporcionar ms funciones adems del simple marcado (marking) del byte DS. Estas condiciones o funciones adicionales se reflejan a continuacin.

4.2.1 ClassifierLos datos tienen que clasificarse para los PHB en la frontera del dominio Diff-Serv en relacin a una funcin de clasificacin. La clasificacin considera normalmente los campos de la cabecera IP, como protocolo, direcciones IP fuente y destino, puertos fuente y destino. El classifier aplica un filtro a cada paquete. Este filtro define las condiciones que la

39


cabecera debe cumplir para ser aceptada. Si el filtro acepta el trfico entonces el perfil asociado a ese filtro se aplica a ese trfico. Algunos ejemplos de filtros de clasificacin son: Trfico bsico entre dos nodos corporativos: La direccin destino est dentro del rango de la red corporativa mediante una mscara de red. Trfico de un servidor de correo: La direccin fuente ser la del host o el servidor. El protocolo utilizado es UDP.

4.2.2 MeterDespus de que los datos han atravesado el mdulo classifier, pasan a travs de un mecanismo de metering que calcula el nivel de trfico y lo compara con el perfil de SLA del cliente. El perfil de trfico puede incluir aspectos tales como las tasas de datos medias acordadas con el cliente, la tasa de datos mxima y el tamao de la rfaga de datos mxima. El mdulo de metering aplica la poltica establecida a los niveles de trfico para cada clase de servicio y puede tomar parte y realizar modificaciones si el nivel excede los parmetros acordados.

4.2.3 MarkerCuando los datos han sido clasificados y se ha determinado la tasa, el PHB seleccionado se marca en el byte DS. La razn por la que el PHB no se marca directamente desde el mdulo classifier es que el PHB no es independiente de la tasa de datos. En el caso de la tecnologa Cisco el proceso de marking se realiza asignando un nmero de bits variable segn el tipo de marking: Tipo de marking Precedencia IP DSCP MPLS EXP bits Ethernet QoS bits ATM CLP bit FR DE bit # de bits 3 6 3 3 1 1 Localizacin de los bits Los 3 bits ms significativos del byte TOS en las cabeceras Los 6 bits ms significativos del byte TOS en las cabeceras Parte de la etiqueta MPLS de 20 bits Cabecera 802.1 q/p Cabecera de celda ATM Cabecera FR

Figura 4.6. Tipos de marking en Cisco. Un ejemplo de configuracin sencilla de un router Cisco sera: Router(config)# policy-map access-in Router(config)# class Silver Router(config)# set ip dscp 26 Router(config)# exit 40


El valor de DSCP en el ejemplo sera 26. Silver es un tipo de clase en Cisco (se definen las clases Gold, Silver, Bronze,... segn el tipo de trfico). A continuacin se puede ver cmo se divide el trfico en clases y se trata en la frontera de los dominios Diff-Serv:

Figura 4.7. Diff-Serv en Cisco.

4.2.4 ShaperUna vez que los datos han atravesado los mdulos meter y marker el router sabe si la tasa de datos est dentro del perfil de trfico permitido o si ste se ha superado. Si la tasa de datos est dentro del perfil los datos pueden enrutarse hacia el destino. Si por el contrario la tasa de datos excede el perfil se pueden tomar dos posibles acciones. La primera es limitar (shape) el trfico. Los datos se encaminan mediante los procesos normales de routing a una tasa definida por el perfil de trfico del cliente. Como esta tasa es menor que la tasa con la que se han recibido los datos, es necesario almacenar en un buffer este exceso de datos y enviarlo ms tarde cuando el perfil lo permita. En un router Cisco se configurara de la siguiente forma: Router(config)# policy-map access-out Router(config-pmap)# class Silver Router(config)# shape {average | peak} cir bc be Router(config)# exit 41


Esta configuracin correspondera a un enlace FR, en el que se ajustan los valores medios de los parmetros relativos a la conexin FR: Bc: Committ burst (rfaga acordada) Be: Excess burst (rfaga de exceso) shape peak limita la tasa al valor cir * (1+be/bc)

4.2.5 DropperLa segunda accin a realizar en caso de excederse el perfil la lleva a cabo el mdulo dropper (descartador). En este caso, el exceso de datos simplemente se puede descartar. Esto ocurre cuando el buffer del mdulo shaper est lleno. En algunos casos el propio servicio no puede tolerar ningn exceso en la tasa de datos, con lo que podra suceder que prcticamente todo el trfico exceda el perfil con lo que se descartara, a no ser que los buffers fueran de gran tamao. Aunque esta accin pudiera parecer drstica, puede ser necesario para algunos tipos de PHB como por ejemplo EF, para el que se tienen requerimientos estrictos en los niveles de trfico. En las siguientes figuras se ve cmo se realiza el proceso de los diferentes mdulos:

Clasification/ Marking

Drop Policy

Scheduling Policy

Red de Conmutacin Cola de Recepcin Cola de Transmisin

Figura 4.8. Buffering entre los diferentes mdulos condicionantes del trfico en Diff-Serv.

42


Se aplica Diff-Serv Accesos de cliente

Edge Router Accesos de cliente

Core Routers

Core Router

Edge Router Edge Router

Pares de Red Se aplican condicionantes de trfico y Diff-Serv Entrada de datos Classifie Mete Marke Shape Droppe Salida de datos

Condicionantes de Trfico

Figura 4.9. Secuencia de aplicacin de los mdulos condicionantes del trfico en Diff-Serv.

4.3 IP Bearer ServicesDentro de cada nodo de la red de la figura anterior se puede definir lo que se conoce como IBS (IP Bearer Services), mediante la combinacin de los PHB con los condicionantes del trfico que se han visto. Se puede combinar el mismo PHB con parmetros diferentes con los condicionantes del trfico para obtener un servicio portador (bearer service) distinto con caractersticas diferentes. Adems de los diferentes condicionantes de trfico, los diferentes IBS tambin dependen la ingeniera que se aplique a cada servicio. Por ejemplo, incrementar la capacidad ofrecida a un IBS ms all de su nivel de trfico asignado puede proporcionar al servicio una latencia menor. Dependiendo de la capacidad de los buffers tambin se puede lograr una probabilidad de congestin menor. A continuacin se describe brevemente la evolucin de los mecanismos que se aplican para reducir la congestin. Los primeros mecanismos de congestin eran muy simples, se basaban en descartar los paquetes cuando los buffers alcanzaban un nivel umbral definido. Este sistema protega a los routers pero incrementaba la posibilidad de aparicin de un fenmeno no esperado conocido como sincronizacin global. Cuando los paquetes TCP se descartan, el algoritmo de planificacin de TCP responde disminuyendo su tasa de transmisin. Cuando los routers de core se sobrecargan, descartan paquetes procedentes de muchos hosts haciendo que se

43


cancelen muchas sesiones TCP y/o incrementando simultneamente las tasas de transmisin de otras con lo que se pueden producir patrones de dientes de sierra de infrautilizacin y congestin. Para incrementar la utilizacin media de los enlaces, se introdujo un mecanismo denominado RED (Random Early Detection) para evitar el efecto de sincronizacin indicado anteriormente. En vez de descartar todo el trfico cuando se supere el umbral, se pone en marcha un mecanismo que descarte de manera aleatoria los paquetes segn los buffers se van llenando, para conseguir una mayor proporcin en el nmero de sesiones TCP canceladas frente a las que se le aumenta la tasa de transmisin. Actualmente se han propuesto muchas variantes de RED, como por ejemplo Weighted RED (WRED), Fair RED (FRED), RED with In-Out (RIO) y RED adaptativo. No est excesivamente claro cul de estas variantes proporcionar los mejores resultados a un backbone determinado pero s est claro que un backbone debe poseer alguno de estos mecanismos para proporcionar una diferenciacin de clases respecto a la posibilidad de descarte de los paquetes. La combinacin de estos mecanismos de congestin con los PHB facilitan que el proveedor de la red pueda establecer diferentes niveles de servicio y por tanto proporcionar a los clientes diferentes SLA y con ello diferentes IBS. Los IBS ms comunes que se crean son ELL (Emulated Leased Line), EVLL (Emulated Virtual Leased Line), BBE (Better than Best Effort), BE (Best Effort) y otros servicios.

4.3.1 ELL (Emulated Leased Line)El principal objetivo de este servicio es proporcionar un enlace equivalente a una lnea alquilada en un entorno VPN o en cualquier otro entorno con requerimientos estrictos de QoS como throughput, retardo o jitter como por ejemplo los enlaces de Voz sobre IP (VoIP) entre los diferentes GateWays deVoz (VoGW). El servicio ELL proporciona garantas cuantitativas de retardo y congestin y utiliza el PHB EF.

4.3.2 EVLL (Emulated Virtual Leased Line)El objetivo de este servicio es similar al del servicio ELL pero con requerimientos de retardo, prdida de paquetes y jitter ms permisivos. Este servicio se puede utilizar por ejemplo en cadenas de trfico pertenecientes a aplicaciones en tiempo real interactivas. Este servicio utiliza un PHB AF y los condicionantes de trfico se definen punto a punto como en el servicio ELL. EVLL permite trfico de datos a rfagas bajo un modelo similar al token bucket, y se permite el exceso de datos. Sin embargo elimina los paquetes en caso de congestin.

44


4.3.3 BBE (Better than Best Effort)Este servicio crea una o ms clases de servicios a las que se le da un trato preferencial comparado con el servicio bsico best effort. A cada clase se le asigna parte de los recursos de red y se proporciona un mejor servicio que en el caso del trfico Best Effort (retardo ms bajo, tasa de descarte menor). BBE tpicamente utiliza uno o ms PHB del grupo de AF. Los condicionantes de trfico permiten un perfil a rfagas para el usuario y tambin el exceso de datos, pero al trfico se le aplica una gran probabilidad de descarte.

4.3.4 BE(Best Effort)Este es el servicio tradicional que se ofrece en las redes IP actualmente. No hay garantas en los parmetros (retardo, throughput,...) y los datos hacia cualquier destino se envan de la mejor manera que la red pueda hacerlo. Este servicio utiliza tpicamente el PHB DE y los condicionantes de trfico son similares a los de BBE.

4.3.5 Otros serviciosLos operadores de red pueden crear otras clases de servicio para una aplicacin especfica que deseen proporcionar y que requiera condiciones ms rigurosas. Por ejemplo, una aplicacin de voz tiene unos requerimientos de retardo y jitter muy rigurosos, por lo que el operador de la red puede crear un servicio nuevo llamado por ejemplo voz. Este servicio podr tener restricciones similares al servicio ELL, pero el operador de red puede diferenciarlos basndose en otras caractersticas como la garanta de fallo de la red. Adems hay que tener en cuenta en Diff-Serv ciertos aspectos: Ser necesario establecer estos mecanismos en ambos extremos de la sesin y marcar tambin los paquetes que se envan de vuelta con la misma clase de servicio que tengan los paquetes que se han enviado anteriormente. A los paquetes de asentimiento del protocolo TCP obviamente tambin se les debe aplicar los mismos mecanismos de congestin, planificacin,... ya que no servira de nada aplicar una determinada clase de servicio a un tipo de trfico IP mientras que el trfico a nivel superior (por ejemplo los asentimientos TCP) sufre los retardos. Hasta ahora slo se han considerado los condicionantes de trfico en el router ingress (ver figura 4.7), pero estos condicionantes son tan importantes en los routers ingress como en los routers receptores (egress). En casos de enlaces de baja velocidad como accesos mviles o en enlaces de alta utilizacin el control puede proporcionarse por el receptor de los datos, que podra rebajar la rigurosidad de los condicionantes del router ingress para evitar por ejemplo ataques perniciosos como intentos de flooding del enlace,... Esto quiere decir que los clientes pueden aplicar

45


filtros en la red para decidir cules de los paquetes que le llegan son ms crticos y no descartarlos en caso de principio de congestin. En caso de que el trfico atraviese distintos dominios (dos sistemas autnomos diferentes) puede ser necesario volver a aplicar el mdulo de marker en la frontera de un dominio para decidir cul va a ser el PHB para el siguiente dominio.

4.4 MPLS QoSMPLS puede combinar las tcnicas de Diff-Serv con los mecanismos de ingeniera de trfico que aparecen en el captulo de MPLS Traffic Engineering para ofrecer una determinada QoS. MPLS crea rutas dirigidas a travs de una red IP. Estas rutas (los LSP) permiten que el trfico IP entre dos nodos se enrute slo en el router de entrada (ingress) del dominio MPLS. Cada LSP que se crea a travs de la red se establece por sealizacin. Esta sealizacin transporta la informacin sobre las caractersticas requeridas para cada LSP, que pueden ser: Ancho de banda: Tasas de datos sostenidas, pico y tamao mximo de las rfagas. Retardo y variacin del retardo. Seleccin de ruta.

Los LSP que transportan la informacin de ancho de banda, retardo, seleccin de ruta, etc, se denominan de sealizacin, y son independientes de los que se crean para transportar servicios de clientes. Dentro de un dominio MPLS se pueden crear mltiples LSP entre dos nodos. Un motivo para tener varios LSP entre dos nodos es proporcionar algunas de las funcionalidades del traffic engineering al enlace, para obtener redundancia y distribucin de carga con otros enlaces. Por ejemplo, se puede crear un LSP para proporcionar un servicio de lnea alquilada que soportar el trfico utilizando un PHB EF, mientras que se puede crear otro LSP para tener una subclase dentro del servicio BBE que pueda llevar un tipo de trfico acorde con el PHB AF. El router ingress va a controlar a qu tipo de trfico se le permite utilizar cada LSP. En el caso de un router de acceso a un sistema autnomo, el trfico perteneciente a un tipo de PHB de alta prioridad ser el nico que atraviese este router. Este control se va a realizar de manera idntica al funcionamiento de Diff-Serv. En el caso de Cisco se deben seguir los siguientes pasos para establecer un mapa de clases segn el tipo de trfico:

46


1. Crear una Class Map. Router(config)# Class-map [match-any | match-all] class-name Una class map es una clase de trfico que se crea en relacin a un parmetro determinado (lista de acceso, el interfaz de entrada, el byte DSCP, el bit EXP de la etiqueta MPLS,...). Por ejemplo: Router(config)# class-map class1 Router(config-cmap)# match ip precedence 5 Router(config-cmap)# exit 2. Crear una P

Memoria_230606 M Puñales

Documents

Transcript of Memoria_230606 M Puñales