CALIDAD DE SERVICIO EN REDES MPLS CON VPNs MARIA ISABEL SERRANO GÓMEZ Tesis de grado presentada como requisito para optar al título de Magíster en Ingeniería de Sistemas y Computación Asesor: ING. HUGO SINN TRIANA Jurados: ING. BEATRIZ ACOSTA, ING. RAFAEL CAMERANO, ING. JUAN PABLO SEGURA SANTAFÉ DE BOGOTÁ UNIVERSIDAD DE LOS ANDES FACULTAD DE INGENIERÍA 2003
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
CALIDAD DE SERVICIO EN REDES MPLS CON VPNs
MARIA ISABEL SERRANO GÓMEZ
Tesis de grado presentada como requisito para optar al título de Magíster en Ingeniería de
Sistemas y Computación
Asesor: ING. HUGO SINN TRIANA
Jurados: ING. BEATRIZ ACOSTA, ING. RAFAEL CAMERANO, ING. JUAN PABLO SEGURA
4.1 OBJETIVO GENERAL ......................................................................................................................... 8 4.2 OBJETIVOS ESPECÍFICOS .................................................................................................................. 8
5. MARCO TEÓRICO ............................................................................................................................... 9
5.1 CALIDAD DE SERVICIO ..................................................................................................................... 9 5.1.1. Modelos End to End de QoS..................................................................................................... 12
5.1.1.1. Servicio del mejor esfuerzo.............................................................................................................13 5.1.1.2. Servicios Integrados........................................................................................................................13 5.1.1.3. Servicios Diferenciados ..................................................................................................................15
5.1.2. Mecanismos de QoS.................................................................................................................. 17 5.1.2.1. Control de Admisión.......................................................................................................................17 5.1.2.2. Clasificación y Marcación de Paquetes...........................................................................................18 5.1.2.3. Administración de Congestión ........................................................................................................21 5.1.2.4. Abolición de Congestión.................................................................................................................31 5.1.2.5. Mecanismos de Regulación de Tráfico ...........................................................................................35 5.1.2.6. Señalización ....................................................................................................................................43 5.1.2.7. Mecanismos de Eficiencia de Enlace ..............................................................................................44 5.1.2.8. Administración, Aprovisionamiento y Monitoreo...........................................................................45
5.2 MPLS ............................................................................................................................................ 47 5.2.1. Qué es MPLS? .......................................................................................................................... 49 5.2.2. Bloques Constitutivos ............................................................................................................... 50 5.2.3. Modo de Funcionamiento ......................................................................................................... 52
5.2.3.1. Componentes de la Arquitectura MPLS..........................................................................................53 5.2.3.2. Operación Básica ............................................................................................................................54
5.2.4. Características Adicionales ...................................................................................................... 56 5.2.4.1. Ingeniería de Tráfico .......................................................................................................................56 5.2.4.2. Servicios de ancho de banda garantizados en MPLS ......................................................................58 5.2.4.3. Rápido Reenrutamiento (FRR)........................................................................................................58 5.2.4.4. Any Transport over MPLS (AToM) ...............................................................................................58
5.3.1. Protocolos de VPN ................................................................................................................... 60 5.3.2. Clasificación de los servicios VPN........................................................................................... 61
5.4 CALIDAD DE SERVICIO EN REDES MPLS........................................................................................ 65 5.5 SOPORTE DE CALIDAD DE SERVICIO EN REDES MPLS CON VPN................................................... 68 5.6 IMPLEMENTACIÓN DE MPLS QOS ................................................................................................. 70
5.6.1. LSRs de Borde (Edge LSRs)...................................................................................................... 71 5.6.2. LSRs en el núcleo de la red MPLS (Core LSRs) ....................................................................... 72
6. JUSTIFICACIÓN Y PROYECCIONES ............................................................................................ 73
8.1 ESTÁNDAR DE INTERNET................................................................................................................ 78 8.2 REQUISITOS PARA EL PROVEEDOR DEL SERVICIO ........................................................................... 80
8.2.1. Definición de un SLA ................................................................................................................ 81 8.2.2. Implementación de MPLS VPNs............................................................................................... 84 8.2.3. Técnicas de QoS ..................................................................................................................... 100
8.2.3.1. Clasificación y Marcación de Paquetes.........................................................................................102 8.2.3.2. Regulación de tráfico y Administración de Congestión ................................................................105
8.3 REQUISITOS PARA EL USUARIO .................................................................................................... 109 8.4 ASPECTOS ADICIONALES.............................................................................................................. 110
8.4.1. Implementación de Extranets y Acceso a Internet .................................................................. 110 8.5 QOS EN REDES MPLS CON VPNS ................................................................................................ 112
Este servicio proporciona un nivel de ancho de banda y un límite en el retardo,
garantizando la no existencia de pérdidas en colas. Está pensado para aplicaciones
con requerimientos en tiempo real, tales como aplicaciones de audio y vídeo. Cada
router caracteriza el servicio garantizado para un flujo específico, asignando un
ancho de banda y un espacio en buffer.
• Servicio de Carga Controlada (Controlled-Load Service) (RFC2212):
A diferencia del anterior, este servicio no ofrece garantías en la entrega de los
paquetes. Esta definido para aquellas aplicaciones que toleran una cierta cantidad de
pérdidas y un retardo mantenidos en un nivel razonable. Los routers que
implementen este servicio deben verificar que el tráfico recibido cumpla con ciertas
especificaciones dadas, de forma que cualquier tráfico que no las cumpla será
reenviado por la red como tráfico best-effort.
Existen dos tipos de mensajes fundamentales en RSVP: Resv y Path. Una aplicación
solicita participar en una sesión RSVP como emisor, enviando un mensaje Path en el
mismo sentido que el flujo de datos, por las rutas unicast o multicast proporcionadas por el
protocolo de enrutamiento. Al recibir este mensaje, el receptor transmite un mensaje Resv
dirigido hacia el emisor de los datos, siguiendo exactamente el camino inverso al de los
mismos, en el cual se especifica el tipo de reserva a realizar en todo el camino.
No se ha logrado implementar ampliamente el protocolo RSVP, a pesar de sus ventajas en
cuanto a garantías de calidad de servicio, debido a tres problemas fundamentales que
afectan al funcionamiento del mismo: la escalabilidad, el enrutamiento y la imposibilidad
de lograr una interacción con redes que no pueden implementar RSVP.
15
El problema de la escalabilidad existe, dada la necesidad de mantener en cada elemento de
red a lo largo del camino de comunicación, la información de estado de cada reserva, lo que
se dificulta o aumenta en exigencias de memoria, a medida que crece el número de flujos
reservados a lo largo del núcleo de red. Adicionalmente, conforme la red vaya aumentando
de tamaño, u ocurran cambios en la topología de red por caídas de nodos, se incrementa la
cantidad de señalización que aparecerá en ésta, tanto en cuanto a rutas como en cuanto a
usuarios, puesto que es necesario refrescar de manera periódica las reservas realizadas. En
este último punto se corre el riesgo adicional de que los paquetes de refresco de rutas se
pierdan en el camino y por tanto se pierda o liberen los recursos reservados para una
comunicación, por parte de los dispositivos de red.
El enrutamiento se convierte en un problema, dado que el proceso de encaminamiento se
realiza en el instante de establecer la sesión y enviar el mensaje Path. En este punto, los
algoritmos de encaminamiento utilizados no tienen en cuenta cuales van a ser las
características de reserva solicitadas por el receptor, con lo cual puede que la decisión
adoptada para establecer la ruta, no sea la más adecuada teniendo en cuenta sólo los
parámetros de caracterización del tipo de QoS elegido.
Finalmente, RSVP exige que todos los nodos intermedios en el camino de transmisión
implementen el protocolo, de forma que se pueda efectuar de manera real la reserva de
recursos. Cuando algún dispositivo intermedio no implementa el protocolo, no se podrá
asegurar la disponibilidad de los recursos requeridos por el servicio, o posiblemente se
realize la reserva sobre un ancho de banda mayor al ancho de banda efectivo del canal.
Es por estas limitaciones que fue definido el modelo de servicios diferenciados, sobre el
cual se enfoca el desarrollo del presente trabajo.
5.1.1.3. Servicios Diferenciados
Este modelo de QoS propuesto por la IETF3 se diferencia del modelo de servicios
integrados en que las aplicaciones no informan explícitamente a la red antes de enviar los
3 RFC 2474 y RFC 2475
16
datos, sino que ésta trata de proveer un tipo particular de servicio basada en la QoS
especificada para cada paquete. Dicha especificación puede realizarse por ejemplo al
seleccionar los bits de precedencia IP, o con las direcciones fuente o destino, etc. La red
utiliza la QoS especificada para clasificar, marcar, dar forma, aplicar políticas de tráfico y
desarrollar colas inteligentes.
Para proporcionar los diferentes niveles de servicio, utiliza el campo type of service (TOS)
o differentiated services code point (DSCP)4 de la cabecera del estándar Ipv4 e Ipv6, para
dividir el tráfico en un número pequeño de clases. Así, con el uso de los 6 bits DSCP, se
obtiene un máximo de 64 clases de servicio a las cuales se asignan los recursos según su
nivel de preferencia. Los elementos de red o hops a lo largo del camino, examinan el valor
del campo DSCP y determinan la QoS requerida por el paquete (PHB o per-hop behavior).
De esta forma se define el nivel de Expedited Forwarding (EF) PHB5 como el servicio de
mínimo retardo y bajas pérdidas con la más alta prioridad y los niveles de Assured
Forwarding (AF) PHB6 como clases de servicio asegurado con diferentes niveles de
preferencia de descarte (cuatro clases diferentes de transmisión, cada una con tres niveles
de posibilidad de descarte), a las cuales se les asigna los recursos basándose en el nivel de
servicio acordado entre el proveedor y el usuario.
El PHB por defecto, o servicio del mejor esfuerzo, corresponde a un DSCP = ‘000000’. El
DSCP estándar para EF PHB es el 101110 (DSCP 46) y los niveles AF PHB, toman los
valores que se muestran en la siguiente tabla.
Clase 1 Clase 2 Clase 3 Clase 4 Preferencia de descarte bajo
001010 (10D)
010010 (18D)
011010 (26D)
100010 (34D)
Preferencia de descarte medio
001100 (12D)
010100 (20D)
011100 (28D)
100100 (36D)
Preferencia de descarte alto
001110 (14D)
010110 (22D)
011110 (30D)
100110 (38D)
Tabla 1. DSCPs para las clases AF PHB
4 RFC 2474, “Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers” 5 RFC 2598, “An Expedited Forwarding PHB” 6 RFC 2597, “Assured Forwarding PHB Group”
17
Diffserv es un protocolo simple, flexible y hasta el momento bastante aceptado por los
usuarios, fabricantes y los proveedores de servicios, convirtiéndose en una de las mejores
opciones para la obtención de QoS extremo a extremo.
A continuación se definen algunos mecanismos que implementan calidad de servicio dentro
de una red de comunicaciones.
5.1.2. Mecanismos de QoS
Algunos mecanismos y/o herramientas utilizadas en la obtención de calidad de servicio en
los nodos de una red y algunas técnicas de coordinación de QoS extremo a extremo entre
dichos nodos incluyen: control de admisión, clasificación de tráfico, administración de
congestión, abolición de congestión, policing y shaping, señalización, mecanismos de
eficiencia de enlace y administración, aprovisionamiento y monitoreo. A continuación se
especificarán cada una de éstos en más detalle. [5], [20].
Se debe anotar que el funcionamiento básico de la mayoría de estos mecanismos se ve
restringido en interfaces de túneles o sobre paquetes encriptados, puesto que fueron
diseñados para aprovechar información de las cabeceras de los paquetes para realizar la
clasificación de los mismos. Es por ello que para su aplicación en redes MPLS el
reconocimiento del tráfico se debe basar, en primera instancia al ingreso de la red MPLS,
en alternativas adicionales como por ejemplo la interfaz de entrada o la clasificación
desarrollada por el usuario y almacenada en la cabecera del paquete encriptado (en
cualquier caso, la clasificación del tráfico quedaría bajo la entera responsabilidad del
cliente). Una vez dentro de la red MPLS, el funcionamiento de los mecanismos se
fundamentaría en la clasificación almacenada dentro de la etiqueta MPLS asignada a cada
paquete, como se explicará posteriormente.
5.1.2.1. Control de Admisión
El control de admisión determina si una petición de conexión puede ser llevada a cabo por
la red. Las principales consideraciones tras esta decisión son la carga del tráfico actual, la
calidad de servicio que se puede lograr, el perfil de tráfico pedido, la calidad de servicio
solicitada, el precio, entre otras. Es por tanto una herramienta resultante de la aplicación de
18
las políticas de calidad de servicio definidas en la compañía proveedora de servicios de
comunicación, y por tanto requiere de una correcta monitorización del sistema de forma
que se pueda visualizar en cada momento el estado del mismo para poder aplicar la política
de admisión definida.
5.1.2.2. Clasificación y Marcación de Paquetes
La clasificación de los paquetes es un paso muy importante en la implementación de
esquemas de calidad de servicio, puesto que permite ofrecer un mejor servicio a los
usuarios al asignar prioridades a los tráficos individuales, a la vez que se disminuye la
intensidad de procesamiento requerido en el núcleo (donde la carga de tráfico es mayor
comparada con los bordes de la red). Una vez clasificados y marcados los paquetes, es
posible aplicar en el núcleo de la red técnicas como control de congestión o colas de
prioridad, que refuercen los compromisos adquiridos en los acuerdos de nivel de servicio o
SLA, para tráfico específico. La clasificación de los paquetes y el tratamiento adecuado de
los mismos en el núcleo de la red, permite usar de forma eficiente los recursos y disminuir
los retardos de transmisión.
Es de interés del usuario mismo el realizar una adecuada clasificación de su tráfico con los
niveles de prioridad pactados en el SLA, como se definirá en una sección posterior. Pero
muchas veces los proveedores de servicios reclasifican los paquetes al ingreso de su red, de
acuerdo con políticas especificadas para el servicio. Los equipos encargados de ésta tarea
realizan la clasificación de acuerdo con diferentes características especificadas en las
cabeceras de los protocolos7; por ejemplo, se pueden clasificar los paquetes por puerto
físico, por aplicación, por dirección de red y/o dirección MAC fuente o destino, por el tipo
de protocolo TCP/IP, en fin por cualquiera de las características que se encuentren en las
cabeceras de los paquetes.
Un ejemplo de clasificación y marcación de paquetes es el siguiente:
7 Los dispositivos que no permitan el marcado de paquetes, pueden ser remplazados o se pueden implementar
técnicas de no-marcado como la Generic Traffic Shaping de Cisco.
19
Con precedencia IP 0 y 2 (DSCP 0–7 y DSCP 16-32), se marca el tráfico normal o de mejor
esfuerzo, que no es sensible a la latencia, pero puede ser un poco sensible a la pérdida de
paquetes.
La precedencia IP 3 y 4 (DSCP 24–31 y DSCP 32-39), tiene mayor prioridad que la
anterior y puede ser usada para aplicaciones administrativas u otro tráfico de valor.
La mayor prioridad se asigna a la Precedencia IP 5 (DSCP 40-47) reservada para
aplicaciones de video y voz sobre IP, con la menor latencia y el más alto ancho de banda
efectivo posible.
La mayoría de los equipos identificadores de tráfico, pueden controlar el tráfico en las
capas de red y transporte, de manera que pueden dar forma a dicho tráfico a nivel de red,
cuando se especifican direcciones IP o subredes determinadas; y a nivel de transporte, para
puertos conocidos como el puerto 80, 25, etc8. Pero si se desea identificar tráfico que no
tiene asignado un puerto “bien conocido”, se debe analizar las cabeceras de las capas
superiores al nivel de transporte.
Las aplicaciones de Internet varían considerablemente en el método de comunicación entre
hosts. La tabla 2 muestra como se clasifican algunos protocolos en el modelo de referencia
OSI y en la arquitectura TCP/IP.
Aunque muchos protocolos de nivel de aplicación realizan la comunicación sobre puertos
bien conocidos, por ejemplo las comunicaciones http se llevan a cabo sobre el puerto 80,
existen algunos protocolos que negocian de forma dinámica los puertos de comunicación,
lo que hace difícil reconocerlos y prioritizarlos adecuadamente. La compañía Morenet, en
su reporte investigativo “QoS Customers Edge Devices” de abril del 2001, realizó una
comparación entre cuatro equipos respecto a sus capacidades para identificar tráfico por
aplicación, limitar tráfico agregado, marcar paquetes y dar forma al tráfico de acuerdo con
políticas preestablecidas. Es necesario resaltar que el rendimiento de la red es afectado por
8 La lista completa de puertos se puede encontrar en: http://www.iana.org/assignments/port-numbers
20
los procesos adicionales que estos productos realizan para el reconocimiento de
aplicaciones.
Aplicación
Presentación
Sesión
Proceso / Aplicación host a host
FTP
Tel
net
SMT
P
H.3
23 S
tart
Nap
ster
DN
S
SNM
P
TFT
P
RT
P, R
TC
P
Transporte Inter-red TCP UDP
Red Acceso a Red IP & ICMP
Enlace de Datos IEEE 802.2, Token Ring, FDDI
Físico
Ethernet, Líneas Arrendadas, UTP
Tabla 2. Clasificación de Protocolos en el modelo de referencia OSI y en la arquitectura TCP/IP. Tomado de
“QoS Customers Edge Devices – Research Report”, Morenet, abril del 2001.
Según el reporte, dos de los cuatro equipos evaluados son capaces de identificar y
monitorear flujos de tráfico por sesión, de forma que pueden seguir una transmisión aún
cuando se asignen los puertos de manera dinámica durante la conversación. Igualmente, son
capaces de examinar la porción de datos de un paquete en busca de la “firma” que identifica
ciertas aplicaciones como Napster, según lo especifican. Estos equipos son dimensionados
tanto para uso de Proveedores de Servicio, como de usuarios finales y son capaces de
realizar la marcación de los paquetes de acuerdo con el grupo en el que fueron clasificados,
en la Precedencia IP o en los bits DSCP.
El campo de la clasificación de paquetes esta siendo todavía ampliamente estudiado y
diariamente nacen nuevos modelos y algoritmos de clasificación que buscan contribuir al
reconocimiento de aplicaciones y por tanto al desempeño de la red, sin sacrificar lo anterior
en tiempos de procesamiento.
Una vez clasificados los paquetes, es necesario realizar la marcación de los mismos que
puede hacerse a nivel de los tres bits de Precedencia IP o del byte de Servicios
Diferenciados (DSCP) en la cabecera del paquete IP. El contexto del servicio DiffServ para
cada clase, que incluye el PHBs a aplicar sobre cada clase, es almacenado en una base de
21
datos en cada nodo de red, conocida como la Forwarding Information Base. Dicha tabla es
consultada en cada nodo tanto para aplicar el PHB adecuado a los datos del encapsulado del
paquete entrante, como para marcar nuevamente el paquete saliente según el PHB que le
pertenezca y transmitirlo al hop adecuado. Es necesario anotar que los mapeos entre la
clasificación del paquete y el PHB adecuado a la misma, están sujetos a la configuración
que cada administrador de red realice en sus equipos.
La clasificación y marcación de los paquetes dentro de grupos de calidad de servicio se
convierte en el primer paso para soportar calidad de servicio end to end en toda red de
comunicaciones; pero a partir de éste punto es necesario llevar a cabo una serie de tareas
tanto en el borde como en el núcleo de la red, que aseguren el cumplimiento bilateral del
acuerdo de nivel de servicio.
5.1.2.3. Administración de Congestión
Las redes actuales transportan diferentes tipos de tráfico sobre un medio común, lo que
genera la necesidad de prioritizar los paquetes con el fin de satisfacer a las aplicaciones
sensibles a retardos, a la vez que se cubren las necesidades de aquellas que no tienen gran
dependencia del tiempo, como las transferencias de archivos.
La congestión de un sistema no se explica únicamente como el hecho de que las tasas de
tráfico alcanzaron cierto nivel, permanecieron allí un tiempo y luego disminuyeron. Debido
a que no es predecible el periodo de alto tráfico, es difícil especificar adecuadamente el
tamaño de una red de forma que se reduzca la congestión; un incremento lineal del tamaño
del buffer no necesariamente resulta en un decremento de la tasa de pérdida de paquetes,
puesto que al poder incrementar el número de conexiones activas se puede incurrir en un
aumento de la perdida de paquetes.
Las técnicas de administración de congestión operan sobre el control de la congestión una
vez ésta ocurra, asegurando equidad en el tratamiento de los distintos tipos de tráfico y
permitiendo controlar la congestión al determinar el orden en el cual los paquetes son
enviados fuera de la interfaz de salida, basados en las prioridades asignadas previamente a
dichos paquetes. Este mecanismo se debe implementar tanto en el borde como en el núcleo
de la red.
22
Una forma en que los elementos de red manejan el sobreflujo de tráfico es por medio del
uso de un algoritmo de colas para ordenar el tráfico y luego determinar algún método de
prioritizarlo en los enlaces de salida. Cada algoritmo de colas fue diseñado para resolver un
problema específico de tráfico de red y tiene un efecto particular sobre el desempeño de la
misma.
Los esquemas de control de congestión se pueden clasificar según la capa en el modelo OSI
en la cual el esquema opera. Existen esquemas de control que aplican en la capa de enlace,
en la de red y en la de transporte; dependiendo de la severidad y la duración de la
congestión, se aplica uno u otro esquema o una combinación de los mismos. En la
siguiente figura se muestra como afecta la duración de la congestión a la escogencia del
método de control.
Figura 2. Técnicas de control de congestión según la duración de la misma. [14]
Así, para redes que permanecen casi constantemente congestionadas, la mejor opción es
instalar enlaces de alta velocidad y rediseñar la topología, de forma que cubra el patrón de
demanda. En las redes con congestión esporádica se puede enrutar de acuerdo con el nivel
de carga de los enlaces y rechazar nuevas conexiones si el camino se encuentra altamente
cargado; esto se denomina Control de Admisión de la conexión.
Cuando la congestión dura poco tiempo, se utilizan algoritmos que dan forma al tráfico
(traffic shaping) por ejemplo al iniciar una nueva conexión, o se informa dinámicamente a
los nodos (nivel de enlace) o a los extremos del enlace (nivel de transporte) de forma que
disminuyan su tasa de transmisión.
Duración de la Congestión Mecanismo de Control
Larga Planeamiento de capacidad y diseño de red Control de admisión a la conexión Enrutamiento Dinámico Compresión Dinámica End-to-end feedback Link-by-link feedback Corta Almacenamiento
23
Para niveles bajos de carga en los enlaces, el mejor mecanismo implica tener buffers lo
suficientemente profundos en los enrutadores.
Cuando se trabaja sobre redes ATM, por ejemplo, se utiliza el bit CLP (cell loss priority)
para marcar las celdas que fueron admitidas en la conexión pero que pueden ser descartadas
en casos de congestión; adicionalmente, se pueden emplear los bits del campo Tipo de
Carga para indicar a los nodos que existe congestión en el enlaces, de forma similar a la del
bit FECN (Forward explicit congestion notification) para redes Frame Relay.
En la implementación de servicios diferenciados sobre redes IP, los algoritmos de control
de congestión o algoritmos de colas deben cumplir mínimo con cuatro requisitos: asignar
equitativamente el ancho de banda entre las distintas clases de servicio, según su nivel de
prioridad o su peso; brindar protección a las distintas clases de servicio, de forma que el
tráfico en exceso de una clase no impacte el ancho de banda y el retardo asignado a las
otras colas que se encuentran en el mismo puerto de salida. Igualmente deben permitir que
se utilice el ancho de banda asignado a una clase por las demás, cuando el nivel de tráfico
de ésta no es lo suficientemente alto para copar sus recursos. Y por último, el algoritmo
debe poder implementarse en hardware, de forma que sea efectivo en las interfaces de
enrutamiento de alta velocidad, ya que un algoritmo implementado en software no es lo
suficientemente rápido para controlar el acceso en los enlaces de alta velocidad.
Las disciplinas tradicionales de programación de colas para redes IP se describen a
continuación. Se debe aclarar que los fabricantes de enrutadores implementan muchas
veces combinaciones de estos métodos en sus equipos, de forma que se debe examinar
cuidadosamente cada implementación para que se entienda claramente como opera y si
cumple con las características necesarias para soportar los requerimientos de los usuarios.
[15]
Colas FIFO (First In – First Out): Es el método más básico en el que no existe prioridad
para los paquetes, sino que todos ellos son tratados de igual manera y colocados en una
única cola de salida de acuerdo con el orden de llegada. Su implementación agrega poca
carga computacional al sistema y su comportamiento es bastante predecible, por lo que se
24
puede calcular aproximadamente los tiempos de retardo para los paquetes. Es un método
útil en sistemas poco congestionados.
Figura 3. Colas FIFO: First In – First Out [15]
Entre sus limitaciones se tiene el que no diferencia entre clases de tráfico sino que trata a
todos los paquetes con la misma prioridad, lo que lo hace ineficiente para tráfico de tiempo
real. Adicionalmente, cuando se presentan picos de tráfico, se puede llenar la longitud de la
cola y se produce negación de servicio para el tráfico adicional que intente pasar por el
canal.
Este mecanismo generalmente se encuentra configurado por defecto en los enrutadores,
algunas veces con la variación en el número de colas: por ejemplo se utiliza una segunda
cola de alta prioridad para el tráfico de control.
Colas de Prioridad o PQ: Método básico que soporta clases de servicio diferenciables, en
el cual los paquetes clasificados son colocados en diferentes colas según su prioridad. Las
colas de más alta prioridad son servidas primero que las de más baja prioridad, pero dentro
de una misma cola, se tiene un comportamiento FIFO para los paquetes.
Se puede prioritizar flexiblemente de acuerdo con el protocolo de red (IP, IPX o
AppleTalk), la interfase de entrada, tamaño del paquete, direcciones fuente/destino, etc.
25
Figura 4. Colas de Prioridad [15]
Aunque este método adiciona baja carga computacional a los sistemas de enrutamiento
basados en software, tiene el problema de que si no se limita y politiza adecuadamente el
tráfico de alta prioridad en los extremos de la red, el tráfico de baja prioridad experimentará
retardos extensos puesto que no será servido sino hasta el momento que las colas con
mayor prioridad se encuentren desocupadas, hasta el punto en que se puede llegar a negar el
servicio al tráfico de baja prioridad porque se llena la cola.
Adicionalmente y puesto que el flujo que comparte una misma cola es tratado en orden
FIFO, se puede aumentar el retardo para cierto flujo de paquetes debido a que otra fuente se
encuentra enviando alto flujo de tráfico marcado con nivel de prioridad alta.
Típicamente la implementación de este mecanismo se basa en dos modelos. El primero
ofrece colas de prioridad estricta que garantiza que los paquetes en la cola de alta prioridad
sean siempre programados antes que los paquetes en las colas de baja prioridad. El
segundo implementa colas de prioridad con tasa controlada, en el cual se limita la cantidad
de paquetes de la cola de alta prioridad a un máximo configurado por el usuario, respecto al
ancho de banda del puerto de salida. De esta forma, si la cantidad de tráfico del alta
prioridad es superior a éste nivel, los paquetes en las otras colas pueden ser servidos antes
que los de la cola de alta prioridad.
El buen funcionamiento de este mecanismo depende en gran medida de las políticas que se
implementen en los bordes de la red para la cantidad de tráfico de alta prioridad que es
aceptado. El problema de esto radica en la dificultad de predecir la cantidad de tráfico que
26
se generará por ciertas aplicaciones, como video interactivo, y que dificulta un buen
aprovisionamiento de los recursos de red.
Fair Queuing (FQ): es una disciplina diseñada para asegurar que cada flujo tenga un
acceso equitativo a los recursos de red y prevenir así que flujos pico consuman más del
ancho de banda de puerto de salida de lo que realmente merecen. Aquí los paquetes se
clasifican en colas según al flujo al que pertenecen y cada cola es servida en orden circular
(round robin) de un paquete al tiempo.
Figura 5. Fair Queuing (FQ) [15]
Con este método se da acceso igualitario a todos los flujos que acceden a un mismo puerto
de salida, sin verse afectado un flujo por los demás, sino únicamente por la cantidad de
paquetes dentro de su misma cola.
La clasificación por flujos de los paquetes, no es una tarea fácil de conseguir en redes IP.
Los resultados varían de acuerdo con el esquema de clasificación que se utilice; por
ejemplo, si se clasifica por dirección fuente, todo el tráfico generado por una misma
estación de trabajo se le asignaría la misma cantidad de recursos de red. Si se buscara
clasificar por conexión TCP, se requeriría leer dentro de la cabecera nivel 4 del paquete y
afrontar los problemas que surgirían en caso de que exista fragmentación o encripción de
tráfico. En general, sería necesario analizar el mejor esquema que se adapte a las
necesidades de la red.
27
Otras limitaciones que presenta, incluyen el hecho de que al asignar la misma cantidad de
ancho de banda a todos los flujos, no soporta flujos con diferentes requerimientos de ancho
de banda, excepto cuando el tamaño de los paquetes en un flujo es muy grande, es decir,
asigna el ancho de banda por ancho de paquete. Adicionalmente, por la forma circular
como sirve a las diferentes colas, si un paquete llega a una cola vacía que acaba de ser
servida, tiene que esperar el tiempo necesario para que las demás colas sean servidas hasta
recibir su turno de transporte. Es por esto que no es muy útil para servicios de tiempo real.
Típicamente su implementación se basa en la clasificación de los paquetes en colas de 256,
512 o 1024 paquetes, en un esquema de clasificación que lee las direcciones pares
fuente/destino, los números de puerto TCP/UDP fuente/destino y el byte ToS de la cabecera
IP [15]. Cuando se utiliza FQ basado en clases, el puerto de salida es dividido en un
número de diferentes clases de servicio, donde a cada clase se le asigna un porcentaje del
ancho de banda de salida y los flujos pertenecientes a una misma clase son servidos en un
esquema FQ sobre el ancho de banda asignado.
Figura 6. Class–Based Fair Queuing [15]
Weighted Fair Queuing (WFQ): Realiza mejoras a FQ al soportar flujos con diferentes
requerimientos de ancho de banda y paquetes de longitudes variables. Para el primer
aspecto proporciona a cada cola con un peso que implica una asignación diferente del
ancho de banda de salida; para el segundo, se añade complejidad al algoritmo de
28
programación de colas de forma que se asegure que el ancho de banda asignado a los flujos
con paquetes largos, no sea mayor que el asignado a flujos con paquetes pequeños. [15]
Adicionalmente entre sus beneficios se tiene el que da protección a cada clase de servicio al
asegurar un nivel mínimo del ancho de banda de salida, independiente del comportamiento
de las otras clases de servicio y que al combinarlo con un acondicionador de tráfico en el
borde de la red, WFQ garantiza una asignación equitativa al peso del ancho de banda de
salida para cada clase de servicio.
Pero dada la complejidad del algoritmo, mayor al ser implementado en software, es difícil
escalarlo para soportar varias clases de servicio en interfaces de alta velocidad, donde
adicionalmente se introducen altos retardos que no justifican la implementación de éste
esquema de administración de colas.
Entre las mejoras realizadas a WFQ, se tiene el WFQ basado en clases (CBWFQ), que
asigna los paquetes a las colas basado en criterios de clasificación de paquetes definidos por
el usuario; por ejemplo, según los bits de precedencia IP. Una vez asignados a las colas, los
paquetes reciben un servicio prioritizado según los pesos configurados por el usuario y
asignados a las diferentes colas.
Al implementar este algoritmo, se puede configurar de forma que clasifique los paquetes en
diferentes colas según el par direcciones fuente/destino, los puertos UDP/TCP
fuente/destino y el byte ToS o que utilice las clases de servicio y los porcentajes de ancho
de banda asignados por el usuario en un esquema CBWFQ.
Class-based Queuing (CBQ) o Weighted Round Robin (WRR): Protocolo dirigido a
mejorar las limitaciones de los modelos FQ y PQ en cuanto a soportar flujos con
requerimientos diferentes de ancho de banda y asegurar que no se niegue el acceso al canal
a las colas de baja prioridad.
Inicialmente los paquetes son clasificados en clases de servicios y asignados a la cola
adecuada a la clasificación. Cada cola es servida en orden circular, como en PQ y FQ, con
el aditamento que las colas que requieren mayor ancho de banda son visitadas más
continuamente o atendidas en un mayor número de paquetes que las demás colas.
29
Figura 7. Colas WRR. [15]
WRR cuenta con parámetros de control que sintonizan el comportamiento de cada cola en
cuanto al retardo y jitter experimentado por lo paquetes en la cola, y la cantidad de
paquetes perdidos en las mismas. Adicionalmente, es un modelo que puede ser empleado
en interfaces de alta velocidad, que soporta clases de servicio diferenciadas y que asegura
un ancho de banda mínimo a todas las colas para que no se produzca negación de servicio a
ningún flujo. El problema que enfrenta es que depende de la igualdad en el tamaño de los
paquetes para proporcionar el porcentaje de ancho de banda adecuado a cada clase de
servicio. Si no hay equidad o si no se conoce el tamaño medio de los paquetes por
adelantado (una clase contiene paquetes con un mayor tamaño promedio que las otras
clases), la clase de servicio con el mayor tamaño promedio de paquetes obtiene un mayor
ancho de banda que el que le ha sido configurado.
Deficit Weighted Round Robin (DWRR): Desarrolla mejoras a las limitaciones de WRR
y WFQ en cuanto a soportar una asignación equitativa del ancho de banda, según la clase
de servicio, para colas con paquetes de longitudes variables y definir una disciplina con
menor complejidad, que puede ser implementada en hardware y que por tanto es efectiva en
interfaces de alta velocidad. Adicionalmente asegura que todas las clases de servicio tengan
acceso a por lo menos una mínima cantidad configurada del ancho de banda del canal.
En este algoritmo, se configura para cada cola un peso que define el porcentaje del ancho
de banda de salida al que tiene acceso la cola y un contador de deficiencia (Déficit Counter)
que especifica el número total de bytes que puede transmitir la cola cada vez que es
30
visitada, de forma que soporte paquetes con diferentes tamaños sin asignar un mayor ancho
de banda que el especificado. [15]
Entre sus limitaciones se cuenta el hecho de que este algoritmo no proporciona garantías
precisas de retardo end-to-end, como lo hacen otras disciplinas de programación de colas.
Adicionalmente a los anteriores esquemas de colas, existen otros dedicados
específicamente a tráfico sensible al tiempo y que se utilizan en conjunto con alguno de los
algoritmos básicos de encolamiento:
1. Prioridad IP RTP (Real-time Transport Protocol): esquema de prioritización de
colas que permite que datos sensibles a retardo, como el tráfico de voz, sea sacado
de la cola y enviado antes que los paquetes de otras colas, hasta un máximo de
ancho de banda. Esta característica puede ser usada en interfaces seriales y en los
PVCs de Frame Relay, junto con WFQ o CBWFQ, sobre la misma interfase de
salida. Se especifica según el intervalo de puertos UDP.
2. Colas de baja latencia (LLQ: Low Latency Queuing): proporcionan con colas de
prioridad estrictas para ATM VCs e interfases seriales, permitiendo que datos
sensibles a retardo sean decolados y enviados antes que los paquetes en las otras
colas. Permite configurar el estatus de prioridad a clases dentro de CBWFQ y no
esta limitado a números de puertos UDP, aunque tienen menor precedencia que el
tráfico IP RTP.
Algunos aspectos que se deben considerar al determinar cuando se debería establecer e
implementar políticas de colas en una red, incluyen:
• Determinar si la WAN está congestionada, que ocurre cuando los usuarios de ciertas
aplicaciones perciben una degradación en el desempeño de la red.
• Determinar los objetivos y las metas, basadas en la mezcla de tráfico, que se desean
administrar en la topología y el diseño de la red. Esto implica la determinación de lo
que se desea lograr respecto a:
31
o El establecimiento de una distribución equitativa del ancho de banda entre
todos los tipos de tráfico identificados.
o Garantizar prioridad estricta a cierto tipo de tráfico (como aplicaciones
multimedia interactivas) posiblemente a expensas de un tráfico menos
estricto que también se transporte.
o La repartición personalizada de los recursos compartidos de red entre las
distintas aplicaciones, de forma que se cumplan con los requerimientos
específicos de anchos de banda identificados.
o La configuración efectiva de colas, dependiendo del análisis realizado sobre
los diferentes tipos de tráfico.
• Configurar la interfaz para el tipo de estrategia de cola escogida según los criterios
anteriores y observar los resultados.
5.1.2.4. Abolición de Congestión
El objetivo de las técnicas de abolición de congestión, consiste en predecir y evitar la
congestión en zonas reconocidas como cuellos de botella dentro de una red, descartando
paquetes de manera preventiva, de forma que se actúa antes de que la congestión se
convierta en un problema. Estas técnicas son diseñadas para proporcionar tratamiento
preferencial, bajo situaciones de congestión, al tráfico Premium o de prioridad, a la vez que
maximizan el rendimiento y la capacidad de utilización de la red y minimizan la pérdida de
paquetes y el retardo.
La técnica de Tail Drop o descarte de cola, es el mecanismo por defecto en muchos
enrutadores para el manejo de la profundidad de una cola, e implica una ausencia absoluta
de administración sobre la memoria de la cola. Los mecanismos activos que administran la
memoria de una cola, como RED (Random Early Detection), WRED (Weighted RED) y
ECN (Explicit Congestion Notification), permiten a un router responder pro-activamente a
la congestión, a medida que la longitud de su cola comienza a incrementarse. A
continuación se detalla cada mecanismo.
32
5.1.2.4.1. Tail Drop
Cuando un paquete llega al final de una cola cuyos recursos están completamente agotados,
el paquete es descartado junto con todos los paquetes siguientes que lleguen hasta que
exista espacio en la cola.
Figura 8. Tail Drop [18]
Tail Drop es una metodología fácil de implementar, que puede reducir el número de
paquetes descartados cuando se utiliza suficiente memoria para la cola; el problema de
incrementar la memoria consiste en que también se aumenta el retardo experimentado por
los flujos que atraviesan la red. Adicionalmente, este esquema realiza un manejo ineficiente
de los recursos, puesto que solo hasta cuando la cola se encuentra completamente llena,
comienza a descartar paquetes y por tanto no puede absorber ráfagas de tráfico posteriores
sino hasta cuando haya desocupado suficiente espacio en la cola.
Otra limitación del descarte de cola, con el tráfico basado en TCP, es que suele generar la
sincronización global de TCP puesto que al descartar paquetes por orden de llegada, todas
las sesiones TCP reducirán al mismo tiempo sus tasas de transmisión y las incrementarán
de igual manera, ocasionando que existan oleadas de congestión y momentos de bajo
tráfico, con alta pérdida de paquetes.
Es por estas limitaciones, que se desarrollaron algoritmos para el manejo activo de colas,
que buscan eliminar la sincronización global de TCP utilizando más eficientemente los
recursos de red; poder absorber ráfagas de tráfico, evitando que los sistemas disminuyan
sus tasas de transmisión; y disminuir los retardos en la cola de un enrutador, al controlar el
tamaño de la misma.
33
5.1.2.4.2. Random Early Detection (RED)
Es una técnica basada en el hecho que un equipo generador de tráfico TCP, asume que
existe congestión en la red cuando observa un paquete descartado de su flujo de datos, y
como respuesta a esto, disminuye su velocidad de transmisión. De esta forma se evita que
la memoria de cola en el enrutador se llene por completo y se previene la sincronización
global al descartar selectivamente los paquetes.
Para el proceso de descarte de paquetes de RED, se define un intervalo de probabilidades
de descarte según el tamaño de ocupación de la cola. Así, si la cantidad de paquetes en la
cola del enrutador permanece debajo de un umbral mínimo, no se realiza descarte de
paquetes. Para un tamaño de cola superior al umbral máximo definido, se utiliza el
esquema Tail Drop. Y para tamaños de cola entre estos dos umbrales, se descartan los
paquetes de acuerdo con la probabilidad de descarte que tengan y que es definida por el
usuario.
Los umbrales mínimo y máximo dependen de parámetros configurados en el algoritmo, que
buscan medir de la manera más eficiente posible, la ocupación de la cola según el nivel de
congestión. 9
Con este mecanismo se logra prevenir posibles congestiones de red, disminuyendo la
posibilidad de alcanzar un estado de negación de servicio, reduciendo los tiempos de
retardo, además de poder aceptar ráfagas de tráfico al no mantener la cola en el enrutador
completamente llena.
Entre sus limitaciones se encuentra el que es complejo de configurar en cuanto a sus
parámetros y que puede ocasionar comportamientos peores que con Tail Drop, si se realiza
una mala configuración. Adicionalmente es un esquema diseñado para flujos basados en
TCP, que respondan adecuadamente al descarte preventivo de paquetes. Con otro tipo de
flujos, como el tráfico de VoIP basado en UDP, se recomienda no implementar éste
9 Ver la referencia [19] para una descripción más detallada de los parámetros de funcionamiento de RED.
34
mecanismo, sino utilizar el esquema de Tail Drop, con colas cortas para disminuir los
retardos.
Figura 9. Probabilidad de descarte en RED [18]
5.1.2.4.3. Weighted Random Early Detection (WRED)
Define mejoras al mecanismo RED, en cuanto a la posibilidad de asignar diferentes perfiles
de descarte RED a diferentes tipos de tráfico, soportando en mejor medida las distintas
clases de servicio. Por ejemplo, se marcan según las políticas los paquetes que están fuera
de perfil con una probabilidad de descarte alta y los paquetes que permanecen conformes al
nivel de servicio pactado con una probabilidad de descarte baja. De esta forma se aplica el
perfil de descarte RED adecuado a la marca transportada por el paquete.
Igualmente se pueden definir perfiles de descarte diferentes para cada cola en un mismo
puerto de salida, como se muestra en la figura 10. De esta forma se soportan no solo las
distintas clases de servicio, sino se refuerzan los SLA contratados.
WRED puede ser configurado para usar los valores DSCP (IP Differentiated Services Code
Point en el byte de ToS) cuando calcula la probabilidad de soltar un paquete, permitiéndole
así ser compatible con los servicios diferenciados (DiffServ) de la IETF.
35
Figura 10. Perfiles de descarte RED según el tipo de cola [18]
La característica de compatibilidad de WRED con DiffServ, permite a los usuarios
implementar Assured Forwarding (AF) Per Hop Behavior (PHB), al definir distintas
prioridades para los paquetes según los valores DSCP y luego asignar probabilidades
preferenciales de descarte a dichos paquetes.
Existe un tercer mecanismo para el manejo activo de colas, denominado Notificación
explícita de congestión (Explicit Congestion Notification), que busca implementar a nivel
de red el mecanismo de notificación de congestión que permiten tecnologías de nivel de
enlace como Frame Relay (FECN y BECN10). Para ello se basa en el uso de dos bits del
campo DS en la cabecera IP (bits 6 y 7), para especificar condiciones de congestión en la
red, a sistemas que son capaces de manejar este tipo de indicadores ECN.
5.1.2.5. Mecanismos de Regulación de Tráfico
A medida que la demanda de los suscriptores por ancho de banda aumenta, se hace
necesaria la determinación por parte de los proveedores de servicios, de la manera en la
cual los recursos compartidos de red serán distribuidos entre los diferentes suscriptores,
usuarios y aplicaciones; porque si el proveedor no tiene la capacidad de administrar el
volumen y la tasa a la cual el tráfico entra en el núcleo de su red, le será muy difícil
administrar el nivel de servicio que entrega a cada suscriptor. Para ello las herramientas de
limitación de tasa y de politización de tráfico le permiten determinar que tráfico entra en su
red, el volumen y la tasa a la cual el tráfico es admitido en la red y el PHB que seguirán los
enrutadores a medida que el nivel de congestión de red cambia con la carga de tráfico.
Los requisitos generales para la administración de tráfico incluyen el desarrollo de la
habilidad de identificar, prioritizar, limitar y restringir flujos de tráfico específicos. Cada
día las compañías buscan poder aplicar políticas de negocios corporativas a sus redes,
respecto a la administración del ancho de banda, de los muros cortafuegos (firewalls), del
almacenamiento, enrutamiento y de equipos VPNs, de forma que cumplan con las
decisiones de negocios tomadas, como:
• Seleccionar que usuarios tienen acceso a que recursos de red
• Prioritizar que aplicaciones son críticas para la operación de la compañía
• Proporcionar servicios diferenciables y ancho de banda adecuado a cada usuario de
acuerdo con sus necesidades
• Administrar las demandas de voz, datos y video en los enlaces LAN y WAN
corporativos
• Administrar la totalidad del flujo de tráfico que transita por las redes internas y
externas de la compañía.
Existen dos métodos fundamentales para proteger los recursos compartidos en el núcleo de
una red: Traffic Shaping y Traffic Policing. El primero busca reducir la posibilidad de una
congestión en la red, al colocar paquetes dentro de una cola que cuenta con una herramienta
que suaviza los flujos de paquetes y regula la tasa y el volumen de tráfico admitido en la
red. Dos herramientas fundamentales se encargan de limitar la tasa de tráfico: una de ellas
suaviza el tráfico, eliminando las ráfagas y presentando un flujo estable de tráfico a la red;
es usualmente implementada con un algoritmo de cubeta de goteo. Y la otra herramienta,
permite ciertos tamaños predeterminados de ráfagas y presenta un flujo regulado de ráfagas
37
de tráfico a la red (usualmente implementada con un algoritmo de cubeta de tokens),
manteniendo una tasa de transmisión promedio a largo plazo.
Figura 11. Suavización de tráfico usando un algoritmo de cubeta de goteo [16]
Figura 12. Delimitación de ráfagas usando un algoritmo de cubeta de tokens. [16]
Las herramientas de Traffic Policing permiten examinar el flujo de tráfico del suscriptor y
descartar o marcar los paquetes que exceden el SLA. Son usualmente implementadas con
un algoritmo de cubeta de Tokens, en el cual en vez de encolar el tráfico para transmitirlo,
se implementa la función de marcación o descarte de paquetes. El marcar un paquete como
fuera de perfil implica que tiene la posibilidad de ser transportado por la red, pero que una
vez se presenten situaciones de congestión, o que la red lo considere necesario con las
herramientas de abolición de congestión, dicho paquete tendrá una mayor preferencia de
descarte que los que permanecen dentro del perfil señalado en el SLA. De esta forma se
permite al tráfico adaptarse a las condiciones cambiantes de la red, protegiendo los recursos
de la misma.
38
5.1.2.5.1. Traffic Policing
Antes de comenzar a detallar el funcionamiento de esta herramienta, es necesario definir lo
que significa una política. Las políticas denotan la regulación unificada del acceso a los
recursos de red y a los servicios, basados en criterios administrativos. Consisten de dos
componentes: un conjunto de condiciones bajo las cuales las políticas se aplican y que
incluyen parámetros como el nombre de usuario, direcciones, protocolos y tipos de
aplicaciones y un conjunto de acciones que se aplican como consecuencia de satisfacer o no
las condiciones, incluidas garantías de ancho de banda, control de acceso, balanceo de
carga, redireccionamiento de caché y enrutamiento inteligente.
Estas condiciones y acciones trabajan sobre componentes administradores de las políticas y
equipos encargados de hacerlas cumplir a través de toda la red, como un enrutador.
Específicamente el enrutador se encargará de hacer la conversión entre la información
transportada en la etiqueta del paquete (su clasificación) y la política adecuada a la misma.
Por ejemplo, una política puede decir que “cualquier cosa que provenga de un usuario
específico con prioridad 3, tendrá garantizado un ancho de banda mínimo de 100k”.
Una infraestructura de policing corresponde a un conjunto de protocolos, modelos de
información y servicios que permiten trasladar las intenciones administrativas en
tratamientos diferenciales para paquetes en los flujos de tráfico en las redes.
Una política puede ser vista desde diferentes niveles: a nivel de la red, se encarga de regular
los objetivos de la política y los requerimientos en los distintos nodos de red. Esto a su vez
está compuesto por las reglas de la política a través de las cuales se controlan los distintos
nodos de red, de forma que cumplan con los objetivos de calidad de servicio. Por último,
cada nodo de red cuenta con mecanismos de distribución de recursos específicos al
fabricante, de forma que se debe trasladar las decisiones tomadas en los dos niveles
anteriores a instrucciones específicas al dispositivo.
39
Figura 13. Jerarquía Conceptual de una Política. Tomado de [13]
Una herramienta que permite hacer Policing o limitar la tasa de tráfico, administrando el
ancho de banda de un canal se denomina CAR o Committed Access Rate. En general
permite controlar la tasa de tráfico enviado o recibido en una interfaz, definir límites al
ancho de banda usado por tráfico agregado o granular, entrante o saliente y especificar las
políticas de manejo de tráfico para cuando el tráfico permanece conforme o excede los
límites especificados.
CAR examina el tráfico recibido en una interfaz y lo compara con la tasa de tráfico
configurada con una cubeta de tokens, tomando las acciones adecuadas según los resultados
obtenidos. Puede ser aplicado no solo sobre el tráfico recibido en una interfaz, sino
también sobre parte de dicho tráfico, como todo el tráfico IP, tráfico de una clase específica
definida en una política de acceso (por ejemplo, por Precedencia IP), según direcciones
MAC o por políticas de acceso específicas.
Un ejemplo del uso de las capacidades de limitar la tasa CAR, se da sobre las tasas basadas
en aplicación, en las que se limita el tráfico http a un 50% del ancho de banda, lo cual
asegura la capacidad para tráfico no-Web, incluyendo las aplicaciones de misión crítica.
Las acciones de limitación de tasa se basan en la tasa promedio de transmisión de largo
plazo, el tamaño de las ráfagas de tráfico y el tamaño de las ráfagas en exceso de tráfico.
Así, si el tráfico excede alguno de los parámetros especificados, será remarcado o
descartado según las acciones configuradas y el parámetro violado. Es posible configurar
40
múltiples políticas de limitación de tasa sobre una misma interfaz, que corresponden a
diferentes tipos de tráfico; por ejemplo el tráfico de baja prioridad puede estar limitado a
una tasa inferior que el tráfico de alta prioridad.
Cuando hay múltiples políticas, el router examina cada una de ellas en el orden en que
fueron ingresadas, hasta que encuentra la que se ajusta a las características del paquete
examinado o lo transmite en caso contrario (política configurada por defecto). Las políticas
pueden ser independientes, es decir que cada una se aplica a un tipo de tráfico distinto, o en
cascada, cuando un paquete es comparado con diferentes políticas seguidas. Este último
caso permite que una serie de limitaciones de tasa sean aplicadas sobre un mismo paquete,
obteniendo así una política más granular o una mayor limitación sobre un tipo específico de
paquetes: por ejemplo, se puede limitar el tráfico total en un enlace de acceso a una
proporción del ancho de banda disponible y posteriormente limitar nuevamente el tráfico
http a una sub-proporción del ancho anteriormente permitido.
CAR es una herramienta optimizada para correr en enlaces de alta velocidad, como enlaces
DS3 (44.7 Mbps) y puede ser implementado en interfaces o subinterfaces de entrada o
salida, incluso sobre Frame Relay y ATM. Está limitado a tráfico IP y se dificulta su
aplicación sobre paquetes encriptados o en túneles, puesto que requiere leer características
de las cabeceras de red o transporte de los paquetes.
La herramienta de Traffic Policing tiene como función limitar las tasas de transmisión de
entrada o salida de cierta clase de tráfico, basados en criterios definidos por el usuario, y de
marcar paquetes en sus valores de precedencia IP, en el grupo de QoS al que pertenecen o
en los valores DSCP.
5.1.2.5.2. Traffic Shaping
Como se mencionó anteriormente, Traffic Shaping permite controlar el tráfico que llega a
una interfaz de forma que permanezca conforme a la velocidad del flujo que puede manejar
la interfaz de destino en el siguiente hop y a las políticas contratadas para dicho tráfico. Es
útil para controlar el acceso al ancho de banda estipulado en una política, aún cuando los
recursos de la red superen dicho límite, para controlar la velocidad cuando las tasa de
acceso de los nodos son diferentes y para ofrecer servicios a tasas menores que las del
41
enlace (un enlace T1 o T3 se puede partir en canales mas pequeños). Adicionalmente, con
ésta herramienta se puede disminuir la perdida de paquetes, aunque en algunos casos se
aumenta el retardo en la transmisión del tráfico.
Existen varios mecanismos de regulación de tráfico que se diferencian en el tipo de colas
que utilizan y en las características que permiten configurar. Por ejemplo, Generic Traffic
Shaping (GTS) proporciona con un mecanismo para el control de flujo del tráfico saliente
en interfaces y subinterfaces a través de listas de acceso, utilizando como mecanismo de
colas WFQ por subinterfaz. Para ello, reduce el flujo de tráfico de salida a una tasa de bits
particular, limitando tráfico específico. El tráfico que se adhiera a un perfil particular,
puede ser amoldado para cumplir con los requerimientos de salida, eliminando cuellos de
botella en topologías con diferentes tasas de datos.
Class-Based Shaping permite configurar GTS por interfaz y por clases y no únicamente por
listas de acceso, utilizando CBWFQ como mecanismo de colas. Adicionalmente permite
configurar tasas de tráfico promedio y pico por interfaz o por clase, para dar un mejor uso
al ancho de banda disponible.
Distributed Traffic Shaping (DTS) a diferencia de GTS, puede ser configurado en
interfaces o subinterfaces según criterios seleccionados en listas de acceso, o por la
marcación de los paquetes, o por puertos de entrada, entre otros, adicional al hecho de que
permite el uso de varios mecanismos de colas, como PQ, CBQ y WFQ. Además, permite
administrar el ancho de banda de una interfaz para evitar la congestión, cumplir con
requerimientos de sitios remotos y adecuarse a la tasa de servicio proporcionada por la
interfase.
Y finalmente Frame Relay Traffic Shaping (FRTS) es un mecanismo similar a GTS
diseñado para adaptarse en mejor medida a interfaces PVC o SVC de Frame Relay.
Proporciona con los parámetros de CIR (Committed Information Rate), FECN/BECN
(Forward and Backward explicit congestion notification) y el bit de Discard Elegible (DE),
útiles en la administración de congestión de tráfico en red.
42
En la siguiente tabla se especifican las diferencias entre los dos mecanismos de regulación
de tráfico, de forma que sirva como criterio de selección según las necesidades de la red.
Hay que aclarar que es posible y algunas veces deseable aplicar los dos mecanismos sobre
una misma red, aunque en diferentes partes de ella.
Shaping Policing
Objetivo Almacenar y encolar los paquetes que exceden las tasas comprometidas.
Descartar o marcar (no almacenar) los paquetes que exceden las tasas comprometidas.
Valor del Token en Bits por segundo Bytes
Opciones de configuración
- Permite implementar regulación basada en clases. - Regula tráfico en interfaces Frame Relay. - Permite implementar GTS (Generis Traffic Shaping).
- Permite implementar regulación basada en clases. - Permite implementar CAR (Committed Access Rate).
¿Se puede aplicar en tráfico entrante?
No Si
¿Se puede aplicar en tráfico saliente?
Si Si
Ráfagas Controla las ráfagas suavizando la tasa de salida
Propaga las ráfagas, no las suaviza.
Ventajas Menor probabilidad de descartar paquetes en exceso puesto que permite almacenarlos en una cola hasta una máxima profundidad, disminuyendo así la necesidad de retransmisiones ocasionadas por paquetes descartados.
Controla la tasa de salida al descartar paquetes, evitando los retardos en las colas. Permite utilizar en mejor medida los recursos del sistema, al implementar marcación de paquetes.
Desventajas Puede introducir retardos al implementar las colas, particularmente cuando éstas son de gran longitud.
El descarte de paquetes en exceso reduce el tamaño de la ventana TCP, afectando la tasa de transmisión de tráfico.
¿Permite remarcar paquetes?
No Si
Tabla 3. Comparación entre Shaping y Policing.
El resultado final, después de aplicar las herramientas de regulación de tráfico se observa
en la figura 14, donde se muestra como al implementar Traffic Policing se permite propagar
ráfagas de tráfico hasta una máxima tasa configurada, descartando el tráfico en exceso,
mientras que con Traffic Shaping se suaviza la tasa de salida de paquetes.
43
Figura 14. Policing vs. Shaping [17]
5.1.2.6. Señalización
Para obtener la QoS requerida por una comunicación, los sistemas extremos necesitan
poder indicar sus necesidades a la red, para ello se usan los protocolos de señalización. La
señalización es útil para coordinar las técnicas de manejo de tráfico proporcionadas por
otros mecanismos de QoS. Juega un papel importante en la configuración exitosa de todo
el servicio de QoS extremo a extremo a lo largo de la red.
Las señalizaciones en banda (Precedencia IP y DSCP) y fuera de banda (RSVP), son usadas
para indicar que un servicio de QoS particular es deseado para una clasificación de tráfico
específica. La precedencia IP y el byte DSCP señalizan para QoS diferenciada, mientras
que RSVP señaliza para QoS garantizada (IntServ). Por ejemplo, una red IP puede usar
parte de la cabecera IP para solicitar un manejo especial de alta prioridad para tráfico
sensible al tiempo. En ATM y FR, los beneficios de la señalización se consiguen con las
interfases UNI (User to Network Interface) e LMI (Local Management Interface)
respectivamente.
44
La verdadera QoS extremo a extremo requiere que cada elemento en el camino del tráfico
por la red (switches, routers, firewalls, hosts, etc.) cumpla con ciertos requisitos asignados
para mantener la QoS total, y todo ello debe ser coordinado mediante técnicas de
señalización. Es ahí donde está el desafío para encontrar un protocolo robusto que pueda
operar extremo a extremo sobre redes heterogéneas.
5.1.2.7. Mecanismos de Eficiencia de Enlace
Las redes LAN y WAN transportan diferentes tipos de tráfico en cuanto a longitud de
paquetes, requerimientos de ancho de banda, sensibilidad a retardos, entre otras. Es por esto
que se han diseñado mecanismos que trabajan a nivel de la capa de enlace, que al ser
implementados junto con los algoritmos de colas y de regulación de tráfico, mejoran la
eficiencia y predictibilidad de las aplicaciones.
Uno de estos mecanismos consiste en la fragmentación de paquetes y el entremezclado
(LFI: Link Fragmentation and Interleaving), que busca fragmentar los paquetes largos que
transportan los enlaces de baja velocidad (56 Kbps de Frame Relay o 64 Kbps de canales
B-ISDN), como las transferencias de archivos FTP, de forma que puedan ser
entremezclados con paquetes cortos, sensibles a retardos, como el tráfico Telnet o de VoIP,
reduciendo así el retardo total y el jitter. [5]
Esta herramienta fue diseñada especialmente para enlaces de poca velocidad en los que el
retardo al serializar es significativo. LFI es equivalente al borrador del IETF denominado
Multiclass Extensions to Multilink PPP (MCML)11.
Otro mecanismo que mejora la eficiencia de los enlaces consiste en la compresión de las
cabeceras de los paquetes RTP (Real-Time Protocol) de forma que se evite el consumo
innecesario del ancho de banda disponible. El Protocolo de Transporte en Tiempo Real es
un protocolo host-to-host usado para llevar las nuevas aplicaciones multimedia, incluyendo
audio y vídeo, sobre redes IP.
11 “QoS Mapping Extensions to Multilink PPP”, draft-ietf-pppext-mp-qos-00.txt
45
El mecanismo de compresión de cabeceras RTP, fue desarrollado dada la relación entre el
tamaño de las cabeceras en los paquetes RTP (aproximadamente 40 bytes de cabecera
IP/UDP/RTP) y el tamaño de la carga, que para aplicaciones de audio oscila entre 20 bytes
y 160 bytes. [5]. Dado el tamaño de las cabeceras de RTP y de IP/UDP, es ineficaz
transmitir una cabecera no comprimida. La compresión ayuda a RTP a ejecutarse más
rápidamente, sobre todo en enlaces de baja velocidad, lo que es muy beneficioso para los
paquetes más pequeños (como el tráfico de voz sobre IP) en enlaces lentos (385 Kbps y
menores), donde la compresión puede reducir significativamente el retraso.
La compresión de la cabecera RTP es soportado en enlaces seriales usando Frame Relay,
HDLC (High Level Data Link Control) [9] o encapsulación PPP. También es soportado
sobre interfaces ISDN. Este mecanismo se convirtió en un estandar de Internet,
denominado “Compressing IP/UDP/RTP Headers for Low-Speed Serial Links”, RFC 2508.
Los dos mecanismos anteriores buscan disminuir el retardo en el transporte de paquetes e
incrementar la eficiencia en el uso del ancho de banda disponible. Su aplicación es útil en
enlaces de baja velocidad, inferiores a velocidades T1 (1.544 Mbps).
5.1.2.8. Administración, Aprovisionamiento y Monitoreo
La administración de red se puede definir como el desarrollo y la coordinación de recursos
con el fin de planear, operar, administrar, analizar, evaluar, diseñar y expandir la red para
que cumpla con los objetivos de nivel de servicio en todo momento, a un costo y con una
capacidad rasonables. El administrar la calidad de servicio en una red permite supervisar y
controlar los recursos de red, de forma que se asegure que las propiedades de QoS deseadas
sean conseguidas y mantenidas. Los objetivos de la administración de calidad de servicio,
incluyen la posibilidad de proveer a los usuarios con un medio para demandar y monitorear
QoS, y negociar y soportar la QoS solicitada.
La administración de red es un servicio que emplea una variedad de herramientas,
aplicaciones y dispositivos para asistir a los administradores de red en el monitoreo y
manteniemiento de las redes. La estructura básica de un sistema administrador de red,
incluye programas clientes instalados en las estaciones finales que están siendo
monitoreadas, que las habilitan para detectar fallas y enviar alertas a los equipos
46
administradores, informando del problema. Dichas entidades administradoras ejecutan
entonces una serie de tareas cuyo fin es solucionar la falla y guardar un historial de la
misma.
Igualmente, las entidades administradoras pueden solicitar a las estaciones finales la
realización de un autochequeo que verifique e informe el desempeño de la red, la
configuración de la misma (en cuanto a compatibilidad entre las distintas versiones de
hardware y software), el porcentaje de utilización de la red tanto por usuarios individuales
como por grupos de usuarios, la ocurrencia de fallas y el nivel de seguridad al acceso de los
recursos de red.
Con el fin de mantener actualizados a los administradores de red del nivel de calidad de
servicio proporcionado por la red, se implementan programas que monitorean la calidad de
servicio, en el borde y núcleo de la red. Cuando se desea monitorear el desempeño de un
servicio, desde el punto de vista del usuario final, la mejor ubicación para implementar el
programa de monitoreo se consituye en el borde de red; esto se debe a que un operador de
red tiene acceso a la información del estatus de los equipos y enlaces en su propia red, pero
no del tipo de servicio que experimentan los usuarios. Luego, aunque una información
detallada del estatus de la red es valiosa para la administración de la misma, no permite
conocer el nivel de satisfacción del usuario con el estado de la red.
Los programas de monitoreo pueden realizar medidas a bajo nivel, que indiquen como es el
comportamiento individual de los paquetes en una transmisión, o realizar medidas a nivel
de aplicación para conocer el tiempo que le toma a una aplicación en responder a una
solicitud. Estos últimos parámetros indican la experiencia del usuario.
Para los usuarios finales, el poder monitorear la calidad del servicio les ofrece ventajas en
el momento de tomar decisiones sobre las mejores ofertas de comunicación en el mercado;
y para los proveedores de servicios, les permite administrar la calidad de servicio que estan
entregando en sus redes.
47
La capacidad de monitoreo permite medir la QoS actualmente proporcionada, mientras que
las características de aprovisionamiento posibilitan un suministro sencillo de nuevas
definiciones de calidad, rápida adaptación a las demandas y cambios en el ambiente.
El aprovisionamiento de red se enfoca en la administración y movilización efectiva de los
recursos de red, de forma que se cubran las necesidades del negocio y las ofertas de
servicios.
En la realización de un esquema de aprovisionamiento eficiente, es necesario contar con
información actualizada del inventario con el fin de activar nuevos servicios en la red. Un
registro exacto de los servicios proporcionados a cada usuario y del correspondiente
inventario de red, es crítico al administrar la configuración de la misma y facilitar la
escalabilidad.
5.2 MPLS
Antes de entrar en detalle a definir las características y el funcionamiento de esta nueva
tecnología, es necesario clarificar el porque fue creada [4].
En el transporte tradicional de paquetes IP en redes no orientadas a conexión, cada
enrutador por el que cruza un datagrama toma una decisión sobre el paquete para el envío
del mismo a su destino final, basado en la dirección IP destino contenida en la cabecera de
la capa de red que el paquete lleva. Cada router analiza la dirección IP destino de forma
independiente en cada salto en la red, y basado en las tablas de enrutamiento, escoge el
siguiente salto para el paquete. Este método de transporte de datos, ampliamente difundido,
adolece de ciertas restricciones que disminuyen su escalabilidad y flexibilidad, como son:
[4]
1. No realiza Balanceo de Cargas: El transporte tradicional de paquetes IP, se basa en la
información proporcionada por los protocolos de enrutamiento de capa de red
(estáticos o dinámicos), para tomar la decisión de enrutamiento de forma independiente
en cada router de la red. Dicha decisión se basa únicamente en la dirección IP destino;
por lo que todos los paquetes dirigidos a un mismo destino, seguirán el mismo camino
48
a lo largo de la red, si no existe otro camino de “igual costo”. Además, el hecho de que
la toma de decisión se realice en forma repetida en cada uno de los enrutadores que
cruza el paquete, de forma independiente de los demás enrutadores, ocasiona que
hayan muchas tareas redundantes y se disminuya la velocidad del tráfico en la red.
2. Al cruzar redes LAN o WAN capa 2 (ATM o Frame Relay), se presentan problemas de
enrutamiento, ya que los switches capa 2 no tienen la capacidad de realizar
enrutamiento capa 3; es decir, no pueden seleccionar el camino que debe seguir un
paquete a través del análisis de su dirección destino capa 3. En este caso, el diseñador
de la red debe establecer los caminos capa 2 manualmente, a lo largo de la red WAN, a
los que se conectan físicamente los enrutadores.
3. Adicionalmente, en la interconexión con redes WAN ATM o Frame Relay, cada vez
que un nuevo router se conecta al núcleo de la red WAN, se debe establecer un circuito
virtual entre éste y todos los demás routers conectados a la red, si se requiere
enrutamiento óptimo. Además, para cumplir con la redundancia deseada, cada router
debe intercambiar las tablas de enrutamiento con cada uno de los enrutadores
conectados al núcleo de la red, resultando en la generación de una gran cantidad de
tráfico de enrutamiento y en la necesidad de que cada router tenga en memoria todos
los protocolos de enrutamiento necesarios para comunicarse con sus vecinos.
4. En el transporte tradicional de paquetes IP, no se puede optimizar el flujo de tráfico, ya
que no existen técnicas escalables en las que sea posible seleccionar la ruta completa
que un paquete puede tomar a lo largo de la red, hasta su destino final. Las técnicas
actuales que en cierta medida permiten esto, implican la reducción del desempeño del
router, haciéndolo entonces poco escalable. Este punto es deseable para proveer a los
usuarios con servicios de paquetes diferenciados.
5. Tradicionalmente, cualquier cambio en la información que controla el transporte de
paquetes es comunicado a todos los dispositivos del dominio de enrutamiento. Este
cambio implica siempre un periodo de convergencia con el algoritmo de transporte. Es
entonces deseable desarrollar un mecanismo que pueda cambiar la forma como un
paquete es transportado, sin afectar otros dispositivos en la red.
49
La tecnología MPLS fue diseñada para solventar los anteriores problemas al integrar las
características del switcheo capa 2, con las del enrutamiento capa 3, que conlleva a una
serie de beneficios como:
ü Establecer una independencia entre el plano de control del protocolo de enrutamiento y
el plano de transmisión de datos, de forma que el núcleo MPLS desarrolla únicamente
una función de transmisión, completamente independiente del contenido del paquete;
este método permite que las decisiones de enrutamiento y de aplicación de políticas
sean realizadas únicamente una vez en el borde de la red.
ü Permitir implementar Ingeniería de Tráfico, para un manejo eficiente de los recursos
de red y un desempeño óptimo de la misma, al poder realizar balanceo de cargas,
definición de rutas explicitas para ciertas conexiones y rápida recuperación de
conexiones ante situaciones de falla.
ü Facilitar el control preciso de los recursos de red, por ejemplo al definir diferentes
clases de servicio.
ü Simplificar el aprovisionamiento de nuevas conexiones por parte del proveedor del
servicio.
ü Permitir una rápida evolución de la red, al poder ser implementada sobre cualquier
tecnología capa 2 (por ejemplo ATM, Frame Relay, Ethernet y PPP), sin tener que
modificar el protocolo de enrutamiento.
En las secciones posteriores, con la descripción del funcionamiento de ésta tecnología y de
sus características, se aclarará el porque de cada uno de los anteriores beneficios.
5.2.1. Qué es MPLS?
Es un estándar propuesto por la IETF12, diseñado para incrementar la velocidad del flujo de
tráfico en la red y mejorar la administración del mismo. MPLS viene de Multiprotocol
router o switch que implemente el proceso de distribución de etiquetas y que pueda
transportar paquetes, basado en dichas etiquetas. La función básica de la distribución de
etiquetas es la de permitir al LSR que distribuya a los demás LSR sus label bindings, que se
definen mas adelante.
Labels: Las etiquetas son unos pequeños identificadores que se le adicionan al tráfico y son
insertados por el LSR de ingreso. Para MPLS en modo trama, las etiquetas se insertan
51
antes de la cabecera IP. Para ATM en modo celda, la etiqueta es la misma dirección
VPI/VCI. Para Frame Relay, la etiqueta es el DLCI.
Figura 15. Posición de la etiqueta MPLS en una trama capa 2. [4]
Como lo muestra la figura 16, la etiqueta esta conformada por un label de 20 bits para la
identificación MPLS, con significado local al LSR, representando una FEC (Forwarding
Equivalence Class que se define posteriormente) particular; 3 bits de experimentación que
se usan para definir la clase de servicio (CoS); un bit que representa la profundidad de la
pila (S), e implementa la pila de etiquetas: es 0 para la última etiqueta o para etiquetas
únicas; y 8 bits de tiempo de vida (Time To Live), que se usan para detectar loops o para
registrar el número de LSR que el paquete atraviesa.
Figura 16. Estructura de la etiqueta MPLS [4]
Label Switched Path (LSP): Es el camino que sigue un paquete a través de uno o más LSR,
para ir desde un LSR de ingreso a uno de egreso en la red MPLS
Bindings: La decisión de asignar una etiqueta particular a un paquete o grupo de paquetes,
depende del siguiente LSR al que saltaría el paquete (downstream LSR), dentro de una
negociación. Es decir, el downstream LSR informa al upstream LSR acerca de la forma de
asignar etiquetas. Un ejemplo de esto es que un nodo (downstream LSR) le informa a los
demás (upstream LSR), qué etiquetas le deben poner a los paquetes que le van a enviar a él,
dependiendo de ciertas condiciones como tipo de servicio o destino final.
Etiqueta (Label) Exp S TTL
3 bits 1 bit 8 bits 20 bits
32 bits
Cabecera y datos capa 3 (paquete IP) Etiqueta MPLS Cabecera capa 2
Trama capa 2
52
Label Distribution Protocol (LDP): Conjunto de procedimientos por medio de los cuales un
LSR informa a otros LSRs las label bindings que él ha realizado.
Forwarding Equivalence Class (FEC): Conjunto de todos los paquetes que son
transmitidos por un mismo camino, bajo el mismo tratamiento; puede corresponder por
ejemplo, a una subred IP de destino.
5.2.3. Modo de Funcionamiento
Similar a las redes capa 2 (ATM o Frame Relay), MPLS asigna etiquetas o labels a los
paquetes para transportarlos a lo largo de la red. El mecanismo de transporte que
implementa dentro de la red se basa en la conmutación de etiquetas, en el cual unidades de
datos como celdas o paquetes, llevan una etiqueta corta de longitud fija que le dice a los
nodos que cruza, como procesar y transportar dichos datos.
La diferencia básica entre MPLS y las tecnologías WAN tradicionales es la forma como
son asignados los labels y la capacidad de transportar una pila de labels junto con el
paquete, para el desarrollo de nuevas aplicaciones como Ingeniería de Tráfico, VPNs,
rápido enrutamiento en caso de fallas de enlaces o nodos, entre otras [4].
Figura 17. Red MPLS
53
5.2.3.1. Componentes de la Arquitectura MPLS
La arquitectura MPLS se divide en dos planos separados: El plano de datos y el plano de
control. El plano de datos es el encargado de continuar con el transporte de los datos entre
dos LSR o, para el caso de los LSR de borde, hacia un enrutador u otros dispositivos que se
encuentren fuera del dominio MPLS y que no manejen etiquetas. En éste plano se utiliza
una base de datos de etiquetas (Label Forwarding Table ó Label Forwarding Information
Base LFIB) para realizar el transporte de paquetes de datos basados en las etiquetas que
ellos mismos llevan. Los nodos de borde mantienen además en el plano de datos la tabla de
forwardeo IP tradicional de todo enrutador (Forwarding Information Base), que les permite
transportar paquetes de datos desde o hacia dispositivos que no manejan etiquetas.
Figura 18. Componentes de la Arquitectura MPLS [4]
El plano de control es el responsable de crear y mantener la información de etiquetas
asignadas (bindings) entre un grupo de LSR (Label Switches Routers) interconectados
(adyacentes). Para ello, cada nodo MPLS debe correr uno o mas protocolos de
enrutamiento que le permita intercambiar con otros nodos en la red (nodos LSR para los del
Protocolos de enrutamiento IP
Control enrutamiento IP MPLS
Tabla enrutamiento IP
Label Bindings intercambiada con otros routers
Plano de Control
Forwarding Information Base
Paquetes etiquetados salientes
Información de enrutamiento intercambiada con otros routers
Paquetes etiquetados entrantes
Label Information Base (LIB)
Label Forwarding Information Base
Paquetes no etiquetados entrantes
Paquetes no etiquetados salientes
Plano de Datos
54
núcleo y nodos LSR y tradicionales para los del borde) la información de enrutamiento y de
bindings que almacena en la tabla de enrutamiento IP y en la Label Information Base
respectivamente. Con estas dos tablas puede realizar el transporte de paquetes rotulados o
no, a nivel del plano de datos. La negociación de etiquetas en MPLS se realiza usando
distintos protocolos como el Label Distribution Protocol (LDP) o el RSVP-TE (con
ingeniería de tráfico)
5.2.3.2. Operación Básica
A medida que el tráfico transita por la red MPLS, las tablas de etiquetas (LFIB) son
consultadas en cada dispositivo MPLS. Dependiendo de la etiqueta y del puerto de entrada
del paquete (en caso de los nodos de borde, depende del puerto de entrada y de la dirección
IP de destino principalmente), se decide la interfaz de salida del paquete (puerto de salida)
y la etiqueta a asignar o a sustituir. La tabla 4 muestra un ejemplo de una LFIB para el caso
de un enrutador de núcleo, que se utiliza en el ejemplo de la figura 19. Para el caso de los
enrutadores de borde, los campos de etiqueta de entrada o etiqueta de salida se encuentran
vacíos, cuando el paquete es recibido desde un dispositivo no perteneciente a la red MPLS
o cuando debe ser enviado a un dispositivo fuera de la red MPLS, respectivamente.
Tabla 4. Ejemplo tabla de etiquetas (LFIB) contenida en cada dispositivo MPLS de núcleo
Las etiquetas tienen únicamente significado local, esto quiere decir que la etiqueta es útil y
relevante a un único enlace entre LSRs adyacentes. Si el trafico no se encuentra rotulado
(en los extremos de la red MPLS), se realiza un proceso tradicional de enrutamiento en el
cual o se transfiere el paquete a otro nodo basado en la cabecera IP, o se le asigna una
etiqueta.
Etiqueta de entrada
Interfaz de entrada
Prefijo dirección IP
Interfaz de salida
Etiqueta de salida
4 2 128.89 0 9 8 3 128.89 0 10 5 2 171.69 1 7
… … … … …
55
Figura 19. Transporte de Paquetes MPLS. Tomado de “Enabling Business IP Services with Multiprotocol
Label Switching”, Rob Redford, Cisco Systems, 1999.
Veamos un ejemplo concreto:
La figura 20 muestra dos flujos de datos desde un equipo X, hasta los equipos Y y Z.
Existen entonces dos Label Switched Paths LSP distintos:
1. El LSR A es el punto de ingreso a la red MPLS, para los datos provenientes del
equipo X. Cuando se recibe un paquete proveniente de X, el LSR A clasifica el
paquete dentro de una FEC y lo rotula con la pila de etiquetas correspondientes a
dicha FEC. Por ejemplo, para enrutamiento IP basado en destinos unicast, la FEC
corresponde a una subred de destino y la clasificación del paquete se realiza
mediante una revisión tradicional de la tabla de forwardeo según la cabecera capa 3.
A continuación, el LSR envía el paquete por la interfase de salida apropiada a su
LSP hacia el siguiente LSR; en éste caso un LSR B de núcleo.
2. El LSR B recibe el paquete etiquetado y utiliza el par {interfaz de entrada, etiqueta
de entrada} para decidir el par {interfaz de salida, etiqueta de salida} con los cuales
reenviar el paquete. Esta información la encuentra en la Label Forwarding Table o
LFIB. En el ejemplo, cada paquete con la etiqueta 21 será reenviado hacia el LSR
D con la etiqueta 47; mientras que los paquetes con la etiqueta 17, serán re-
etiquetados con el label 11 y enviados hacia el LSR C.
56
Figura 20. Operación Básica MPLS. Tomado de “MPLS Virtual Private Networks”, Paul Brittain, Adrian
Farrel, Data Connection, Noviembre del 2000.
3. Los LSR C y D, actúan como LSR de egreso para la red MPLS. Estos LSRs realizan
la misma revisión de etiquetas que los LSRs intermedios, pero en éste caso el par
{interfaz de salida, etiqueta de salida} marcan que el paquete va a salir de la red
MPLS, por lo cual retiran la etiqueta del paquete y realizan un enrutamiento capa 3
tradicional sobre el mismo, para transmitirlo a su destino final.
5.2.4. Características Adicionales
Algunas de las características adicionales que habilita la tecnología MPLS incluyen
Ingeniería de Tráfico, Servicios de ancho de banda garantizados, Rápido Reenrutamiento,
Any Transport over MPLS, MPLS VPNs y MPLS QoS, que se describirán a continuación.
5.2.4.1. Ingeniería de Tráfico
La ingeniería de tráfico reúne muchos aspectos del desempeño de red, como el
aprovisionamiento de calidades de servicios garantizadas, la mejora en la utilización de los
recursos de red al distribuir el tráfico equitativamente entre los enlaces de red y la facilidad
de permitir una rápida recuperación ante fallas. Fue desarrollada como respuesta al
desperdicio en ancho de banda ocasionado por los protocolos de enrutamiento que no
balanceaban cargas en enlaces con diferentes costos o con alto tráfico ofrecido.
Inicialmente se manipularon las métricas de enlaces utilizadas por los protocolos de
enrutamiento como OSPF, para soportar balanceo de carga sobre caminos de diferente
57
costo. Pero estos métodos no consideraban las características del tráfico ofrecido y las
limitaciones en la capacidad de la red al tomar las decisiones de enrutamiento. Con la
ingeniería de tráfico, se permite a los proveedores de servicios definir caminos explícitos a
lo largo de la red (incluyendo caminos redundantes) y dirigir tráfico a través de éstos,
combinando así la sintonización automática con la manual en el enrutamiento, para
optimizar la utilización de los recursos de red.
En las redes MPLS, la ingeniería de tráfico permite enrutar los flujos de tráfico IP a lo largo
de la red, basado en los recursos que dicho flujo requiere y en los recursos disponibles en la
red. Adicionalmente utiliza enrutamiento basado en limitaciones, de forma que el camino
seleccionado para el flujo de tráfico es el camino más corto que cumple con los
requerimientos de recursos o las limitaciones en términos de ancho de banda,
requerimientos del medio y prioridades. También habilita la definición manual de caminos
explicitos para la transmisión de flujos de tráfico determinado. Otra ventaja es que se
recupera dinámicamente ante fallas en enlaces o nodos, aún cuando algunos caminos hayan
sido precalculados fuera de línea (offline). Además, tiene en cuenta el ancho de banda del
enlace y el tamaño del flujo de tráfico para determinar las rutas explícitas a lo largo del
backbone y remplaza la necesidad de configurar manualmente los dispositivos de red para
crear rutas explícitas, puesto que la ingeniería de tráfico para redes MPLS entiende la
topología del núcleo y el proceso de señalización automática.
Su implementación en redes MPLS requiere del uso de protocolos como RSVP, para
establecer y mantener automáticamente un túnel a lo largo del núcleo. La información de
recursos de red disponibles es alimentada por medio de extensiones a los protocolos de
enrutamiento IGP basados en estado de enlaces, como OSPF o IS-IS. Así los túneles LSP
son calculados en el enrutador fuente (cabecera del túnel) basados en la correspondencia
entre los recursos requeridos y los disponibles en la red (enrutamiento basado en
limitaciones) y establecidos unidireccional mente.
La ingeniería de tráfico en MPLS establece y mantiene dinámicamente túneles LSP a lo
largo del camino LSP, usando protocolos de señalización. Los dos mecanismos de
señalización utilizados para distribuir etiquetas a lo largo del dominio MPLS, en el contexto
de ingeniería de tráfico y calidad de servicio, son constraint-based routing label
58
distribution protocol (CR-LDP)13 y Resource Reservation Protocol con extensiones de
ingeniería de tráfico (RSVP-TE)14. Los dos protocolos determinan el camino a lo largo del
cual el túnel LSP es establecido, basándose en los requerimientos de recursos y en la
disponibilidad de los mismos.
Puesto que en este trabajo, dada la brevedad del tiempo de desarrollo, no se desarrollarán
las características de Ingeniería de Tráfico para las redes MPLS con VPNs estudiadas, no se
realizará un estudio más profundo de éstos protocolos de señalización.
5.2.4.2. Servicios de ancho de banda garantizados en MPLS
Con esta mejora realizada a los mecanismos de ingeniería de tráfico, se combina la
tecnología de QoS de IP con MPLS para proporcionar servicios como garantías de ancho de
banda punto a punto en una red MPLS. Al garantizar el ancho de banda, se habilita la
distribución de recursos de QoS para ingeniería de tráfico en todo tipo de tráfico, desde el
Premium (voz) hasta el de mejor esfuerzo (datos) [3].
5.2.4.3. Rápido Reenrutamiento (FRR)
La ingeniería de tráfico es esencial en los backbones de los Telcos y los proveedores de
servicios, puesto que deben soportar alto uso de capacidad de transmisión y sus redes deben
ser resistentes a fallas de nodos o enlaces. FRR habilita la posibilidad de una rápida
recuperación ante fallas, previniendo que las aplicaciones de usuario lleguen al punto de
time out, o que se pierdan datos [3].
5.2.4.4. Any Transport over MPLS (AToM)
Los mecanismos de conmutación de etiquetas empleados en el núcleo de la red MPLS,
pueden ser explotados para transportar cualquier protocolo como Frame Relay, ATM,
Ethernet, etc., entre dos sitios a lo largo de la red del proveedor de servicios. Esta
característica les permite a los proveedores de servicio, ofrecerles a sus usuarios el
13 RFC 3212: “Constraint-Based LSP Setup using LDP” 14 RFC 3209: “RSVP-TE: Extensions to RSVP for LSP Tunnels”
59
transporte de servicios de datos tradicionales como Frame Relay y ATM, sobre una red
basada en MPLS.
5.3 MPLS VPN
Una red privada virtual se puede definir como una red en la cual se habilita la conectividad
de un usuario con múltiples sitios sobre una infraestructura compartida, pero con el mismo
acceso y políticas de seguridad de una red privada [4]. Dado que este es un punto clave en
el desarrollo del presente trabajo de grado, se realizará inicialmente una revisión del
funcionamiento y de los servicios que ofrecen las VPNs básicas, para luego continuar con
las VPNs basadas en MPLS.
Una Red Privada Virtual (VPN) consiste básicamente de dos máquinas (un servidor y uno o
mas clientes) y una ruta o túnel que se crea dinámicamente sobre una red pública o privada.
Para asegurar la privacidad de esta conexión los datos transmitidos entre ambos equipos
son encriptados y posteriormente enrutados sobre una conexión segura, previamente
establecida. De esta forma, es posible compartir y transmitir información entre un círculo
cerrado de usuarios que están situados en diferentes localizaciones geográficas. Las VPNs
son redes de datos de alta seguridad que permiten la transmisión de información
confidencial entre la empresa y sus sucursales, socios, proveedores, distribuidores,
empleados y clientes, utilizando Internet o redes privadas como medio de transmisión.
Las VPNs permiten administrar y ampliar la red corporativa al mejor costo-beneficio,
además de brindar facilidad y seguridad a los usuarios remotos al conectarse a las redes
corporativas. Para un montaje de VPNs es indispensable desarrollar políticas de seguridad,
e implementar servidores de acceso y auntenticación que aseguren que el compartir datos,
aplicaciones o recursos sea una tarea confiable y que mantenga la integridad de los datos.
El Servidor VPN es usualmente un componente de hardware, aunque también existen en
software, que permanece activo esperando a que los clientes VPN se conecten a él. Los
Clientes VPN, son en su mayoría componentes de software, aunque pueden ser también
componentes hardware, que realizan una llamada al servidor, para que una vez desarrollado
un proceso de autorización y autenticación, se establezca un túnel de comunicación VPN
60
entre los dos dispositivos sobre la red pública, de forma que se permite al usuario remoto la
conexión a la red corporativa. Una vez establecida la conexión, el cliente y el servidor VPN
se encuentran en la misma red virtual.
5.3.1. Protocolos de VPN
Existen varios protocolos de red para el uso de las VPNs, cuya función primordial es
brindar con altos niveles de seguridad a los datos transmitidos. Entre estos se encuentran:
1. Point-to-Point Tunneling Protocol (PPTP): es una especificación de protocolo
desarrollada por varias compañías, aunque normalmente se asocia con Microsoft
puesto que Windows incluye soporte para este protocolo. La mejor característica de
PPTP radica en su habilidad para soportar protocolos no IP. Sin embargo, el
principal inconveniente de PPTP es su fallo a elegir una única encriptación y
autentificación estándar: dos productos que acceden con la especificación PPTP
pueden llegar a ser completamente incompatibles simplemente porque la
encriptación de los datos sea diferente.
2. Layer Two Tunneling Protocol (L2TP): El principal competidor de PPTP en
soluciones VPN fue L2F, desarrollado por Cisco. Con el fin de mejorar L2F, se
combinaron las mejores características de PPTP y L2F para crear un nuevo estándar
llamado L2TP. L2TP existe en el nivel de enlace de datos del modelo OSI. L2TP, al
igual que PPTP soporta clientes no IP, pero también presenta problemas al definir
una encriptación estándar.
3. Internet Protocol Security (IPsec): IPsec es en realidad una colección de múltiples
protocolos relacionados. Puede ser usado como una solución completa de protocolo
VPN o simplemente como un esquema de encriptación para L2TP o PPTP. IPsec
existe en el nivel de red en el modelo OSI, para extender IP en cuanto al soporte de
servicios más seguros basados en Internet.
61
5.3.2. Clasificación de los servicios VPN
Con la introducción de nuevas tecnologías en la red de los proveedores de servicios y la
generación de nuevos requerimientos de usuarios (ejemplo, calidad de servicio), el
concepto de VPN ha llegado a ser cada vez más complejo. Los servicios modernos de
VPNs pueden abarcar gran variedad de tecnologías y topologías. Para facilitar el
entendimiento de los diferentes casos de aplicación, se debe introducir una clasificación en
la VPN, respecto a [4]:
1. El problema de negocio que la VPN trata de resolver: Intranet, Extranet o Internet,
en los que el nivel de seguridad requerido en cada implementación es diferente.
Así, las comunicaciones Intranet, requieren de altos niveles de aislamiento y
seguridad, así como de calidad de servicio end-to-end garantizada para las
aplicaciones de misión crítica. Para las comunicaciones Extranet, los niveles de
seguridad y calidad de servicio se disminuyen y es muy común que se implementen
sobre la Internet pública. Por último, las comunicaciones Internet, permiten acceso
a usuarios móviles a la red de la compañía por medio de VPDNs (Virtual Private
Dialup Networks), requiriendo de los más altos niveles de seguridad punto a punto,
que se implementan con los protocolos L2F (Layer 2 Forwarding) o L2TP (Layer 2
Transport Protocol) sobre IP.
2. La capa OSI en la que el proveedor de servicio intercambia la información de
topología con el usuario; en este punto se encuentra dos modelos: el modelo
Overlay, donde el proveedor de servicios proporciona al usuario con un conjunto de
enlaces punto a punto (o multipunto) entre los sitios de usuario (emulación de líneas
dedicadas) y el modelo Peer, donde el proveedor de servicios y el usuario
intercambian información de enrutamiento capa 3. En el modelo Overlay, las
garantías en calidad de servicios se expresan usualmente en términos del ancho de
banda garantizado en ciertos circuitos virtuales (CIR: Committed Information Rate)
y del máximo ancho de banda disponible en ciertos circuitos virtuales (PIR: Peek
Information Rate), mientras que en el modelo Peer, puesto que el proveedor de
servicio cuenta con la información de enrutamiento del usuario, se pueden aplicar
diferentes mecanismos para garantizar la calidad del servicio.
62
3. Tecnología de Capa 2 o Capa 3 utilizada para implementar el servicio de VPN
dentro de la red del proveedor de servicios, ya sea Frame Relay, ATM, IP, etc.
4. La topología de red implementada: Hub and Spoke o Full mesh. La topología Hub
and Spoke es aquella en la que un número de oficinas remotas (spokes), se conectan
a un sitio central (hub), con un mínimo intercambio de tráfico entre oficinas
remotas. En la topología Full mesh o Partial mesh los sitios en la VPN son
conectados por circuitos virtuales según los requerimientos de tráfico (interconexión
total directa entre todos los sitios o parcial entre algunos).
El montaje de VPNs sobre redes MPLS soluciona el problema que enfrentaban los
proveedores de servicios en las implementaciones Peer de VPNs, respecto al manejo de
direcciones IP privadas que se sobrelapan (2 o mas clientes usan el mismo conjunto de
direcciones IP privadas). Con MPLS, cada VPN tiene su propia tabla de enrutamiento y
forwardeo en el router de borde del proveedor, de forma que se le proporciona a cualquier
usuario o sitio que pertenezca a cierta VPN, acceso único al conjunto de rutas contenidas
dentro de dicha tabla. Luego cada enrutador de borde, en la red MPLS VPN del proveedor
(PE: Provider Edge Router), contiene un número de tablas por VPN y una tabla de
enrutamiento global usada para alcanzar a otros enrutadores de la red interna del proveedor
y a destinos externos (ej. Internet). Es decir, se crea un número de routers virtuales dentro
de un único enrutador físico.
A la combinación de tablas de enrutamiento IP VPN con su asociada tabla de forwardeo IP
VPN, se denomina “VPN routing and forwarding instance” (VRF). Una VRF contiene
todos los sitios que comparten la misma información de enrutamiento (pertenecen al mismo
conjunto de VPNs), que pueden comunicarse directamente entre si y que están conectados a
el mismo enrutador del borde de red del proveedor (PE). Se recomienda por simplicidad en
la configuración de los enrutadores PE, que el número de VRFs se mantenga en un mínimo.
Con el fin de lograr que un router sepa que rutas debe insertar dentro de cada VRF, se
introdujo en la arquitectura MPLS VPN, el concepto de Route Targets. La distribución de
la información de enrutamiento VPN trabaja de la siguiente forma: Cuando una ruta VPN
aprendida de un enrutador del borde de la red del usuario (CE: Customer Edge Router) es
introducida en el MP-IBGP (Multiprotocol Internal-BGP), una lista de comunidades
63
extendidas objetivos de la VPN, o Route Targets, es asociada con dicha ruta al ser
exportada de una VRF local para ser presentada a otras VRFs. De esta forma se difunde la
información de enrutamiento VPN y las VRFs reconocen el nuevo sitio que pertenece a su
VPN y que deben adicionar en su tabla de enrutamiento VRF.
Figura 21. Routers Virtuales creados en un enrutador PE [4]
Propagación de la Información de enrutamiento de VPNs en la red del proveedor:
El intercambio de información entre routers PE acerca de los usuarios de las VPNs y de las
rutas VPNs, se realiza por medio de un único protocolo de enrutamiento que intercambia
todas las rutas VPNs. Adicionalmente, con el fin de soportar el sobrelapamiento de
espacios de direcciones entre los usuarios de las VPNs, la dirección IP utilizada por dichos
usuarios es aumentada con información adicional de forma que se convierta en una
dirección única. Así, las subredes IP que son anunciadas por los enrutadores del usuario
(CE) a los routers PE, son aumentadas con un prefijo de 64 bits denominado el “route
distinguisher”, que las hace únicas. La dirección resultante de 96 bits es intercambiada
entre los routers PE usando el protocolo MP-BGP (Multiprotocol BGP).
Transmisión de Paquetes VPN:
Router Virtual para Cliente 1
Tabla enrutamiento IP virtual- cliente 1
Router Virtual para Cliente 2
Tabla enrutamiento IP virtual- cliente 2
Router IP Global
Tabla enrutamiento IP Global
Cliente 1 Sitio 1
Cliente 1 Sitio 2
Cliente 2 Sitio 1 Enrutador de
borde. Red del Proveedor
Enrutador de núcleo. Red del Proveedor
64
Similar al caso anterior, cuando los paquetes IP de las VPNs son transmitidos a través del
núcleo de la red del proveedor de servicios, debe ser posible reconocerlos de forma única.
Para ello, se les añade en el router PE de ingreso, una etiqueta que identifica de forma única
el router PE de egreso y se envían por la red.
Cada router de borde (PE) requiere un identificador único (usualmente la dirección IP de
loopback) que es propagado por los routers del núcleo. Cada uno de éstos, asigna una
etiqueta a dicho identificador (host route) y la propaga a sus vecinos. Finalmente, todos los
enrutadores de borde reciben una etiqueta asociada con el router PE de egreso, que es
incluida en la tabla de enrutamiento IP global.
Sin embargo, ésta información no les indica a los enrutadores del borde, la VPN a la cual
está destinado un paquete, por lo que se introduce una segunda etiqueta. Para ello, los
routers PE distribuyen una etiqueta única a cada ruta en cada instancia VRF; estas etiquetas
son propagadas junto con las correspondientes rutas a través de MP-BGP a todos los demás
routers PE. Cuando los enrutadores de borde reciben la actualización MP-BGP, instalan las
rutas recibidas en sus tablas VRF y también instalan allí, las etiquetas asignadas por los
routers de egreso.
Funcionamiento:
Se recibe un paquete VPN en el router PE de ingreso, se examina la VRF correspondiente y
se inserta en el paquete la etiqueta asociada con la dirección destino del paquete en el router
PE de egreso. Una segunda etiqueta que apunta al router PE de egreso es obtenida de la
tabla de forwardeo global y es añadida al paquete, para ser posteriormente enviado al
núcleo de la red. Cada enrutador del núcleo examina e intercambia la etiqueta de primer
nivel del paquete VPN, que apunta al router PE de egreso y finalmente, éste último recibe
el paquete etiquetado, descarta la etiqueta de primer nivel15 y revisa la etiqueta de segundo
15 Se introdujo una variación a la arquitectura MPLS denominada Penultimate Hop Popping (PHP), con el fin
de evitar que el LSR de egreso realizara una doble revisión sobre el paquete etiquetado, que disminuía el
desempeño del nodo; con PHP, el LSR de borde solicita a los nodos anteriores vecinos retirar la etiqueta de
nivel superior y transmitirle el paquete resultante para su procesamiento.
65
nivel, que identifica de forma única la VRF objetivo y de aquí, la interfaz de salida del
router PE, de forma que el paquete es enviado al router CE correspondiente.
5.4 Calidad de Servicio en Redes MPLS
MPLS no define una nueva arquitectura de calidad de servicio, sino que se basa en los
modelos especificados por la IETF para redes IP; dichos modelos se pueden implementar
de forma transparente sobre redes MPLS, capacitando así al proveedor de servicio a ofrecer
distintos niveles de QoS end-to-end en un ambiente IP. Para el caso del modelo de
Servicios Integrados, la implementación que MPLS realiza de éste se fundamenta en el
hecho de que RSVP puede hacer reservas para tráfico agregado. De esta forma, MPLS
asocia etiquetas a los flujos que tienen reservas RSVP y los agrupa dentro de FECs
específicas, con el fin de evitar la necesidad de analizar las cabeceras IP y de transporte de
los paquetes. Adicionalmente, al asignar todos los paquetes asociados con una FEC a un
LSP particular, se puede conseguir que un único LSP proporcione garantías de calidad de
servicio a un gran número de flujos de tráfico.
Para ello, se añadieron dos objetos al protocolo RSVP específicos para el manejo MPLS:
los objetos LABEL_REQUEST y LABEL. Estos permiten asignación de etiquetas
downstream16, usando los mensajes PATH y RESV. Sin embargo, estas extensiones son
comúnmente usadas para implementar reserva de recursos para flujos agregados en
Ingeniería de Tráfico para MPLS y no tanto para QoS por flujo, dada la limitada
escalabilidad que se tiene con ella dentro del backbone de un proveedor de servicios
(requiere gran número de etiquetas no disponibles en muchos equipos).
Es por los problemas de escalabilidad y complejidad en la implementación, que se adoptó
el modelo de clasificación de la IETF a través de los bits de Precedencia IP, visto
anteriormente. Los paquetes clasificados en una de las 8 clases, son descartados en
situaciones de congestión de acuerdo con su nivel de precedencia, dándose mayor prioridad
16 El método de distribución es downstream cuando un LSR asigna una etiqueta que otros LSRs (upstream
LSRs) pueden usar para enviarle paquetes etiquetados.
66
a los de alto nivel de precedencia. Una desventaja de este tipo de clasificación resulta del
hecho que no existen acuerdos respecto a la implementación de la precedencia IP entre los
múltiples fabricantes, lo que ocasiona que se puedan generar problemas de
interoperabilidad al implementar QoS end-to-end. Es por esto que un paso importante en el
establecimiento de los acuerdos de calidad de servicio (SLA) entre clientes y proveedores o
entre proveedores, consiste en la definición clara y concisa de las clases de servicio en las
que se dividirá el tráfico y la marcación que se asignará a cada una de ellas. Algunas
sugerencias para la definición de los SLA, se proporcionarán más adelante en el capítulo
ocho.
Para el caso de los servicios diferenciados (DiffServ), MPLS cuenta, desde Mayo del 2002,
con un estándar de Internet denominado “Multi-Protocol Label Switching (MPLS) Support
of Differentiated Services”, RFC 3270, que define una solución para el soporte de Servicios
Diferenciados sobre redes MPLS. En dicho estándar se definen dos métodos para la
señalización del nivel de QoS. El primero, denominado EXP-LSP o E-LSP, consiste de un
LSP en el cual los nodos infieren el tratamiento de QoS (clase y nivel de precedencia de
descarte) para el paquete MPLS exclusivamente de los bits EXP en la cabecera MPLS. De
esta forma, muchas clases de tráfico pueden ser multiplexadas dentro de un único LSP
(Label Switched Path) usando la misma etiqueta, o lo que es equivalente, un solo LSP
puede soportar hasta ocho clases de tráfico en éste campo de 3 bits. Aquí, los bits de
Precedencia IP o los 3 primeros bits del campo DSCP, son mapeados en el campo Exp en
los extremos de la red y cada LSR a lo largo del LSP da un tratamiento adecuado al paquete
(PHB) según los bits Exp. El número máximo de clases de tráfico puede ser menor que
ocho si se reservan algunos valores para el tráfico de control o para especificar la
precedencia de descarte asociada con clases específicas. E-LSPs no se puede implementar
dentro del ATM-LSR ya que en estos dispositivos, los paquetes MPLS utilizan la
encapsulación original de las celdas ATM y no existe el campo Experimental en la cabecera
de la celda.
Cuando se desea implementar más de 8 clases de servicio u 8 PHBs en la red MPLS, se
utiliza el segundo método de señalización de QoS en MPLS denominado Label-LSP o L-
LSP. Un L-LSP es un LSP en el cual el nodo infiere el tratamiento de QoS para los
67
paquetes MPLS de la etiqueta del paquete y de los bits EXP (o de los bits CLP para el caso
de MPLS en modo celda). En particular, la etiqueta es usada para codificar la clase a la cual
el paquete pertenece y los bits EXP (o CLP) definen el nivel de precedencia de descarte del
paquete. Un LSP por separado puede ser establecido para cada combinación de FEC y
clase; por ejemplo, tres LSP separados serán establecidos para un único destino si se tienen
paquetes dirigidos allí, que pertenezcan a tres clases diferentes. La clase asociada con un L-
LSP necesita ser señalizada explícitamente durante el establecimiento de la etiqueta, de
forma que cada LSR puede posteriormente inferir la clase del paquete de la etiqueta.
Figura 22. Modelos de QoS en redes MPLS. Tomado de “MPLS QoS and Traffic Engineering”, Don Fedyk,
Nortel Networks, 2001.
El modelo E-LSP es más eficiente que el L-LSP puesto que se limita el número total de
LSP creados y por lo tanto se ahorran etiquetas (recurso escaso, según el dispositivo de red
utilizado).
Se debe tener presente que el RFC 3270 parte del hecho que ya ha sido asignado un DSCP
a los paquetes, es decir, que ya cuentan con un PHB definido. De acuerdo con el estándar,
el mapeo entre el valor del encapsulado (el EXP para E-LSP o los valores CLP o DE para
L-LSP) y el PHB: Encaps ↔ PHB, puede ser señalizado al ser establecido el LSP (creación
de la etiqueta), o se puede basar en datos preconfigurados por el administrador de red que
sean consistentes para todos los LSP. Adicionalmente, se cuenta con valores por defecto
estándares para dichos mapeos.
El contexto del servicio DiffServ para cada etiqueta, que incluye el tipo de LSP (E-LSP o
L-LSP), los PHBs soportados y el mapeo de encapsulado a PHBs para etiquetas entrantes o
68
de PHBs a encapsulados (marcación) para etiquetas salientes, es almacenado en la ILM
(Incoming Label Map)17 o en la FTN (FEC-to-NHLFE) al ser establecido el LSP.
5.5 Soporte de Calidad de Servicio en Redes
MPLS con VPN
Calidad de servicio por VPN se logra al implementar diferentes políticas de QoS de ingreso
para diferentes VPNs en los LSRs de borde. En una red MPLS, todo el conocimiento de
VPNs reside en los dispositivos de borde; después de que el tráfico es insertado dentro del
núcleo de red MPLS, no se realiza diferenciación de tráfico por VPN, es decir, en el núcleo
de la red no se implementan colas o descarte de tráfico por VPN. Las mismas políticas de
QoS son aplicadas para todos los paquetes si importar la VPN a la cual pertenezcan,
logrando así una alta escalabilidad en la solución de QoS sin importar el número de VPNs.
Se utilizan dos modelos para especificar la forma en que se implementan las garantías de
calidad de servicio entre dos sitios en un contexto de VPNs: el modelo pipe o punto a punto
y el modelo hose o punto – red.
MODELO PIPE DE MPLS VPN QoS
En este modelo el proveedor de servicio proporciona al usuario VPN con ciertas garantías
de calidad de servicio para flujos de tráfico entre un router CE y otro dentro de la misma
VPN. Los enrutadores PE a los extremos de la “chimenea” especifican los flujos de tráfico
que tiene permitido utilizar la misma. Este modelo es unidireccional, permitiendo
asimetrías en los patrones de tráfico y da la posibilidad de existencia de más de una pipe o
chimenea originándose o finalizando en un enrutador CE.
17 La ILM mapea cada etiqueta entrante a un conjunto de NHLFE (Next Hop Label Forwarding Entries) que
contiene el siguiente hop del paquete y la operación a realizar sobre la pila de etiquetas del paquete. Ver RFC
3031 [2].
69
Con el fin de implementar adecuadamente este modelo, el usuario debe tener un buen
conocimiento de su modelo de tráfico y debe desarrollar un análisis del tráfico de red con
capacidades de planeación adecuadas. Aquí, LSP con anchos de banda garantizados son
usados para soportar el modelo, mejorando la escalabilidad de la MPLS VPN QoS puesto
que el proveedor del servicio no tiene que configurar “chimeneas” CE-a-CE para cada
usuario individual (se pueden configurar LSPs con anchos de banda garantizados entre PEs
que soporten los LSPs acumulados de los usuarios).
Figura 23. Modelo Pipe o Punto a Punto. Tomado de “Quality of Service for Multi-Protocol Label Switching
Networks”, Cisco Systems, 2001
MODELO HOSE DE MPLS VPN QoS
En este modelo el proveedor del servicio le proporciona ciertas garantías al usuario sobre el
tráfico que un enrutador CE particular va a enviar o recibir de otros enrutadores CE en la
misma VPN. Este modelo es más sencillo de implementar por parte del usuario puesto que
no requiere desarrollar un análisis de tráfico detallado o una planeación de capacidad, ni
especificar la distribución de tráfico entre varios routers CE.
Se definen dos parámetros dentro del modelo hose, la tasa de ingreso comprometida o ICR
(Ingress Committed Rate) y la tasa de egreso comprometida o ECR (Egress Committed
70
Rate). El ICR representa la tasa de tráfico a la cual los CEs en la VPN pueden recibir
información de la red y la ECR representa la tasa de tráfico a la cual los CEs en la VPN
pueden enviar información hacia la red.
Un proveedor de servicios puede ofrecerle a un usuario de VPNs cualquiera de los dos
modelos o una combinación de los mismos al proporcionarle distintos niveles de calidad de
servicio. La implementación de ello implica configurar clases de tráfico para clasificar los
paquetes IP de acuerdo con varios criterios, configurar políticas de servicio y configurar las
interfaces de entrada con dichas políticas de servicio.
Figura 24. Modelo Hose o Punto – Red. Tomado de “Quality of Service for Multi-Protocol Label Switching
Networks”, Cisco Systems, 2001
5.6 Implementación de MPLS QoS
Para facilitar la implementación de modelos de calidad de servicio en una red MPLS, se
dividirá la red en dos partes: la primera esta conformada por los dispositivos del borde de
red o edge, que serán los encargados de clasificar el tráfico, prioritizándolo dentro de los
niveles de calidad de servicio acordados con los clientes en los SLA (4 niveles de tráfico
71
máximo: Tiempo Real, Oro, Plata y Bronce o de mejor esfuerzo, de acuerdo con lo definido
en la sección 5.1 de calidad de servicio), y de asegurarse que el tráfico ofrecido al núcleo de
red permanezca conforme a los requerimientos del mismo, a su nivel de servicio y a los
recursos de red disponibles.
Dentro de la segunda parte se incluyen los dispositivos propios del núcleo de red o core,
encargados de proporcionar el nivel de calidad de servicio requerida por el flujo de tráfico,
al mismo tiempo que evita o controla posibles congestiones en la red.
Posteriormente, se podría entrar a implementar políticas de ingeniería de tráfico en el
núcleo de la red. Para finalizar, se considerará la implementación del modelo de calidad de
servicio en MPLS VPNs.
5.6.1. LSRs de Borde (Edge LSRs)
Las tareas que realizan los LSRs sobre los paquetes al ingreso de una red MPLS incluyen:
1. Implementar mecanismos de clasificación como CAR, para clasificar los paquetes
IP que ingresan a la red, estableciendo el valor de precedencia IP o el DSCP del
mismo. Es posible recibir los paquetes IP ya clasificados por parte del cliente si se
desea.
2. Realizar una “revisión” de la dirección IP de cada paquete, para determinar el
siguiente LSR al cual el paquete será dirigido (next-hop LSR).
3. Insertar la etiqueta apropiada en el paquete y copiar la clasificación en los bits EXP
de la cabecera MPLS, para el caso de E-LSP o en una nueva etiqueta para L-LSP.
4. Dirigir el paquete etiquetado a la interfase de salida apropiada para su
procesamiento.
5. Dar un tratamiento adecuado al paquete dependiendo de su clasificación.
6. Adicionalmente, se deben implementar técnicas de control de admisión, policing y
shaping y mecanismos de eficiencia de enlace (como LLQ) en los routers de
72
ingreso para asegurar que se pueda ofrecer el nivel de servicio requerido por los
paquetes y controlar el que el tráfico permanezca conforme al nivel de servicio
pactado (SLA).
Al egreso de la red MPLS, los LSRs deben:
1. Remover la etiqueta MPLS y si es necesario, reclasificar los paquetes IP
2. Revisar la dirección IP de cada paquete para determinar el destino del mismo y
poder enviarlo a la interfase de salida apropiada.
3. Dar un tratamiento adecuado al paquete dependiendo de su precedencia IP.
5.6.2. LSRs en el núcleo de la red MPLS (Core LSRs)
En el núcleo de la red MPLS, los LSRs deben:
1. Revisar la etiqueta MPLS para determinar el siguiente LSR (next-hop LSR)
2. Intercambiar la etiqueta MPLS apropiada al paquete, copiando los bits EXP.
3. Enviar el paquete a la interfase de salida apropiada
4. Dar un tratamiento adecuado al paquete de acuerdo con el valor de los bits EXP
5. Implementar técnicas de abolición de congestión (como WRED), administración de
congestión (como WFQ) y control de acceso para asegurar que el tráfico
permanezca conforme al servicio especificado y se le ofrezca el servicio apropiado a
su clase.
73
6. Justificación y Proyecciones
6.1 Justificación
Una de las falencias que observaban los procesos de tunneling y de encripción, radicaban
en el hecho de imposibilitar que los mecanismos de calidad de servicio examinaran las
cabeceras de los paquetes con el fin de clasificarlos de forma adecuada según sus niveles de
prioridad. Ello conllevaba a que en los momentos de congestión y puesto que todos los
paquetes transportados por un mismo túnel tenían el mismo encabezado, los paquetes
fueran tratados de forma idéntica, perdiendo así la posibilidad de ofrecer servicios acordes
con la calidad esperada.
Con el crecimiento en popularidad de los dispositivos VPNs, como lo muestran estudios del
IDC, la necesidad de clasificar los paquetes dentro de un túnel de tráfico, se hizo evidente.
Por ello se desarrolló una nueva característica de preclasificación de paquetes, con la cual
se clasifica el tráfico antes de ingresar en un túnel o de pasar por el proceso de encripción.
De esta manera, el flujo de tráfico en el interior del túnel, puede ser prioritizado en
ambientes de congestión. El resultado es un túnel de paquetes de características eficientes.
Al desarrollar e implementar un nuevo protocolo, que presupone mejoras en los procesos de
transmisión de información, no solo se deben mantener los niveles de calidad preexistentes,
sino se debe justificar con nuevas ventajas la actualización de la tecnología. Sobre esta
base se desarrolla el presente trabajo, en el cual se expone una guía metodológica de
implementación de calidad de servicio sobre redes MPLS con VPNs, proyectada a ser un
documento base que les permita a los proveedores de servicio contratar con sus clientes
diferentes acuerdos de nivel de servicio.
74
6.2 Proyecciones
Actualmente muchas compañías proveedoras de servicios de comunicaciones están
migrando sus redes a MPLS, dadas las ventajas que ofrece esta tecnología para el transporte
de servicios integrados (voz, datos-IP y video). Al realizar esta migración, las compañías
se enfrentan a la necesidad de implementar calidad de servicio sobre sus redes MPLS VPN,
con el fin de poder establecer acuerdos de nivel de servicio con sus clientes. Actualmente
en Colombia, la implementación de redes MPLS en empresas es muy poca, pero cada vez
más compañías están interesadas en la migración.
El análisis que se presentará en el presente trabajo de grado, servirá de base tanto para las
compañías que se encuentran planificando la migración, como para aquellas que ya tienen
la tecnología implementada, puesto que les facilitará la tarea de implementar diferentes
niveles de servicio sobre un túnel de conexión en MPLS, al presentarles las ventajas,
posibilidades y la forma de implementación del servicio.
75
7. Delimitación del Trabajo
Uno de los objetivos de este trabajo consiste en la formulación de una guía metodológica
para la implementación de calidad de servicio en redes MPLS con VPNs, basada en los
estándares de la industria, de forma que no se vea atada a un fabricante específico. Dado
que MPLS no define una nueva arquitectura de calidad de servicio, sino que se basa en los
modelos especificados por la IETF para calidad de servicio sobre redes IP, fue necesario
realizar una búsqueda de documentos que describieran aplicaciones de los modelos de
calidad de servicio en redes MPLS. El resultado de dicha búsqueda se constituyó en el
estándar RFC 3270, “Multi-Protocol Label Switching (MPLS) Support of Differentiated
Services” que define una solución flexible para el soporte de Servicios Diferenciados (Diff-
Serv) sobre redes MPLS en cuanto a la forma de mapear BAs (Behavior Aggregates) en
LSPs (Label Switched Paths) (relación entre el campo EXP y el PHB).
Dicho documento proporciona entonces, una base genérica referente a la aplicación de la
clasificación y marcación de paquetes IP en redes MPLS, pero deja sin definir los demás
mecanismos que contribuyen con una calidad de servicio extremo-a-extremo. Para éstos
últimos, es necesario basarse en las implementaciones que cada fabricante desarrolla en sus
equipos, teniendo como base la capacidad de manejar el protocolo MPLS. Es por ello que
muchos aspectos de implementación y ejemplos desarrollados en esta guía, son relativos a
fabricantes específicos, especialmente a las capacidades de los productos Cisco sobre los
cuales se pudo obtener mayor información detallada de sus características y formas de
empleo.
76
De otro lado, y teniendo presente la descripción desarrollada en el marco teórico respecto a
los múltiples mecanismos de implementación de calidad de servicio, la clasificación de los
servicios de VPNs18 y otros casos a que se enfrentan tanto clientes como proveedores -
como es la interconexión entre más de un proveedor o la necesidad de ofrecer diferentes
niveles de servicio a los clientes - se presentó la necesidad de delimitar el trabajo de grado
de forma que además de ajustarse al tiempo de desarrollo, los resultados presentados
tuvieran la profundidad necesaria para facilitar su implementación por parte de las
compañías proveedoras de servicios de comunicación.
Por este motivo, se asumirá en el transcurso del proyecto que el proveedor de servicios ya
cuenta con una red MPLS19 sobre la cual desea ofrecer servicios de VPNs con cuatro
niveles de servicio (voz, oro, plata y bronce) que son, como se encontró en artículos de
implementaciones específicas y en entrevistas realizadas a personal tanto de empresas
proveedoras de servicios de comunicación como de empresas clientes20, los que usualmente
requieren los usuarios. Adicionalmente, se asume que las capacidades de los equipos (según
fabricante) permiten implementar algunos de los mecanismos de calidad de servicio vistos
en el marco teórico.
Por último, de acuerdo con una encuesta realizada por IDC respecto a las preferencias en
servicios de telecomunicaciones de empresas pequeñas, medianas y grandes, se tiene que en
su mayoría las empresas usuarias de Internet están tendiendo a migrar sus redes LAN a
redes Ethernet por su facilidad de implementación; es por ello que se analizará la forma de
mapear la calidad de servicio ofrecida en el backbone del proveedor sobre este tipo de redes
en la última milla, cuando se presenta el caso de un único proveedor de servicios.
Para el caso en el cual es necesario interconectar múltiples proveedores de servicios, se
deben analizar diferentes situaciones que incluyen la forma de mapear los niveles de
servicio sobre la misma tecnología MPLS o sobre tecnologías distintas (ATM, Frame
18 Ver secciones 5.1.2 y 5.3.2 respectivamente. 19 Los ejemplos desarrollados en la presente guía no indican el proceso requerido para la habilitación de la red
MPLS. La forma de habilitación depende del fabricante de los equipos enrutadores. 20 “AT&T Enhanced Virtual Private Network – Private IP Option” y Anexo 1.
77
Relay, Redes enrutadas, entre otras), la capacidad de ofrecer diferentes niveles de servicio –
como los niveles de tasas de bits constantes (CBR), variables (VBR), no especificados
(UBR) y de tasa de bits disponibles (ABR) que permiten las redes ATM o la
implementación de servicios diferenciados o servicios integrados en redes enrutadas – los
esquemas de seguridad empleados y la forma de interconexión entre los proveedores. Se
sugiere desarrollar este aspecto en futuros trabajos de grado, que complementen la guía
aquí descrita.
78
8. Descripción
Contando con la base teórica desarrollada anteriormente, es momento de entrar a definir
explícitamente los procedimientos que se deben llevar a cabo tanto por parte del proveedor
del servicio como en la red de los usuarios para poder implementar servicios end to end con
diferentes niveles de calidad. Puesto que la investigación desarrollada se enfocó
inicialmente en los protocolos y servicios estándares de la industria, se realiza a
continuación una descripción del significado de un estándar de Internet.
8.1 Estándar de Internet
“Se puede definir un estándar de Internet como una especificación que es estable y bien
entendida, que es técnicamente competente, tiene múltiples implementaciones
independientes entre si e ínteroperables, con experiencia operacional sustanciosa y que
disfruta de un soporte público significativo, además de ser reconocidamente útil en alguna o
todas las partes de Internet”. [9]
Dichas especificaciones se dividen en dos categorías: Especificaciones Técnicas (TS) y
Comunicados de Aplicabilidad (AS). Las especificaciones técnicas describen protocolos,
servicios, procedimientos, convenciones o formatos ya sea total o parcialmente, incluyendo
información acerca de su área de cubrimiento y de su uso o aplicabilidad, aunque no
especifican los requerimiento para su uso dentro de Internet. Estos requerimientos, que
dependen del contexto particular en el cual sea incorporada la TS por diferentes
configuraciones de sistemas, son definidos en los Comunicados de Aplicabilidad.
Un Comunicado de Aplicabilidad especifica cómo y bajo que circunstancias se pueden
aplicar uno o más TS para soportar una capacidad particular de Internet. Éstos identifican
79
las TS relevantes y la forma específica como deben ser combinadas; igualmente pueden
especificar valores particulares o intervalos de parámetros de TS o subfunciones de un
protocolo TS que pueden ser implementados. También definen las circunstancias en las
cuales una TS particular es requerida, recomendada o electiva.
Las especificaciones de Internet pasan por diferentes estados de desarrollo, pruebas y
aceptación, denominados “niveles de madurez”:
- Proposed Standard: Comprenden las especificaciones que son generalmente
estables, que resuelven temas conocidos específicos, son reconocidas y
consideradas valiosas por parte de la comunidad, pero pueden ser alteradas o
incluso canceladas, por implementaciones, pruebas, experiencias o validaciones
futuras.
- Draft Standard: Incluyen las especificaciones que han desarrollado por lo menos
dos implementaciones independientes e ínter operables de diferentes fuentes y para
las cuales se han obtenido experiencias operacionales exitosas.
- Internet Standard: Son las especificaciones que se caracterizan por su alto grado de
madurez técnica y por una creencia generalizada de que el protocolo o el servicio
especificado proporciona beneficios significativos a la comunidad de Internet.
La Internet Architecture Board (IAB), recomienda que el proceso de estandarización sea
usado en la evolución de una suite de protocolos para maximizar la interoperabilidad y
prevenir el surgimiento de incompatibilidades entre los requerimientos de los protocolos.
La IETF desarrolla estos estándares con la meta de coordinar la evolución de los protocolos
de Internet; esta coordinación a llegado a ser bastante importante a medida que los
protocolos de Internet han incrementado su uso comercial general.
Con esta base, se comenzará a desarrollar la guía metodológica propuesta tanto para el
proveedor de servicios de comunicaciones, como para los usuarios de los mismos.
80
8.2 Requisitos para el Proveedor del Servicio
MPLS ofrece beneficios de desempeño reales, pero se enfrenta a dos problemas principales:
- Sobre-utilización: en el cual el camino óptimo no permanece siendo así por mucho
tiempo. Esto se debe a que la definición de caminos para cierta clase de tráfico es
únicamente efectiva a medida que se cuente con la habilidad de distinguir entre
aplicaciones. Pero ¿cómo se puede asegurar que cada tipo de tráfico obtenga la
etiqueta correcta? La mayoría de los equipos encargados de la clasificación de
paquetes observan características específicas en las cabeceras de los protocolos de
red y transporte, pero muy pocos pueden diferenciar entre aplicaciones específicas,
más cuando éstas son de naturaleza aleatoria respecto al puerto de comunicación.
Este aspecto requiere especial atención por parte de usuarios y proveedores, en el
momento de realizar un acuerdo de servicio.
- Cuellos de Botella: el punto de entrada a la red MPLS se convierte usualmente en
un cuello de botella en donde MPLS puede no proporcionar ventajas de desempeño
al tráfico crítico. El enlace entre la red LAN y el núcleo MPLS es típicamente una
porción de baja capacidad en la red, donde se generan largas colas que introducen la
mayor latencia en la red. En estos sitios se hace necesario implementar políticas de
control de congestión, abolición de congestión y colas de baja latencia, que
disminuyan el tiempo de espera para transmisión y eviten la generación de cuellos
de botella.
Adicionalmente, se deben continuar implementando prácticas en el núcleo de la red,
que eviten la degradación en la calidad de servicio de acuerdo con la prioridad de
los paquetes.
Estos dos problemas serán analizados en las secciones siguientes, para los enrutadores de la
red del proveedor de servicios de comunicación.
De otro lado, para que un proveedor de servicios pueda ofrecer a un cliente un servicio de
calidad, debe conocer detalladamente las necesidades de éste con el fin de corroborar que la
red pueda cubrirlas y que sea posible plantear un negocio llamativo para las dos partes.
81
Dicho conocimiento se adquiere a través de visitas al usuario donde se definan clara y
detalladamente los servicios requeridos, consignando los resultados en un acuerdo de nivel
de servicio que se contrate entre las dos partes. A continuación se describirán algunos
aspectos útiles en la definición de los acuerdos de nivel de servicio.
8.2.1. Definición de un SLA
De acuerdo con IDC21, un SLA demuestra el compromiso de calidad que maneja un
proveedor de servicios, siendo éste un factor diferenciador entre varios proveedores.
Actualmente las empresas usuarias de servicios de comunicación están buscando poder
definir distintos niveles de calidad de servicio y de seguridad para sus conexiones y
aplicaciones, que se acoplen al nivel de importancia que éstas tengan en el funcionamiento
de la empresa y al servicio que buscan contratar. Por ejemplo, en el montaje de una
Intranet, una empresa puede requerir altas velocidades de transmisión para el acceso a una
base de datos, mientras que los servicios multimedia como VoIP no le son tan críticos.
Igualmente, una empresa enfocada a negocios B2B, requiere buena disponibilidad en sus
conexiones Extranet y altos niveles de seguridad en las mismas.
La especificación de un SLA entre el proveedor y el usuario varía en el nivel de
profundidad y detalles técnicos que definan el servicio. Los siguientes parámetros definen
de forma detallada el tipo de servicio ofrecido y se deberían incluir en todo SLA:
- La disponibilidad del servicio, con el tiempo garantizado de funcionamiento y su
latencia.
- Los niveles de servicios ofrecidos
- Las garantías para cada clase de servicio, como su rendimiento, tasa de pérdidas,
retardo, variación del retardo y posibilidad de manipular las clases de servicios.
21 Net Reality, “Application SLAs”, Noviembre del 2000
82
- Las responsabilidades, que incluyen las consecuencias al no cumplir las reglas del
contrato y el tipo de soporte o servicio al usuario que será prestado por el proveedor
(ej, 24 x 7).
- La forma de auditar el servicio, para asegurar el cumplimiento del contrato.
- El precio.
Dichas especificaciones se deben realizar de forma detallada y acordes a la realidad: por
ejemplo, “la empresa garantiza un retardo promedio mensual en el núcleo de la red, menor
o igual a 70 ms roundtrip. En caso de no cumplir con esta garantía, se acreditará al usuario
con un 10% del cargo mensual por puerto”.
Para cumplir con los requisitos pactados, se definen tasas de información comprometidas
(CIR) para aplicaciones específicas, en las que el ancho de banda sea repartido por
aplicación tan pronto como ésta comience a generar tráfico, y niveles de seguridad distintos
según las necesidades. Por ejemplo, para un servicio IP VPN, se puede garantizar la
latencia de un servicio (tiempo promedio de transmisión ida y vuelta) como: “120
milisegundos o menos entre los routers de borde de la red del usuario para una IP VPN con
todas sus sucursales dentro del país, o 300 milisegundos o menos para IP VPNs con
sucursales dentro y fuera del país”.
Aunque la tecnología MPLS permite 8 clases de servicio diferentes, cuando se emplea el
esquema E-LSP, o más al utilizar L-LSP, se sugiere que el número de niveles de servicio
definidos sea mantenido en un mínimo (dos a cuatro niveles), de manera que la
implementación del servicio sea sencilla y fácil de evolucionar, según las necesidades y los
desarrollos del mercado. Adicionalmente, un número limitado de clases aumenta la
percepción del usuario de la calidad del servicio en cada una, que es la base para facilitar el
pago de un precio adecuado por ellas.
La capacidad de auditar el servicio por parte del usuario es útil no solo para comprobar que
se cumplan los términos del contrato, sino también para monitorear y obtener reportes
detallados de congestión, rendimiento por aplicación y por conversaciones, retardos y
pérdidas de paquetes, tasas de envío de paquetes, valores MTBF (Mean Time Between
83
Failure) y MTTR (Mean Time To Recovery) y reportes históricos y de tiempo real, útiles en
contabilidades internas o en la evaluación de futuros cambios a la red.
Por su parte, el proveedor de servicios busca al auditar una comunicación, verificar las
quejas puestas por el usuario, detectar posibles violaciones al acuerdo y asegurar que el
usuario no esté sobre utilizando el servicio.
Un proveedor de comunicaciones debe tener presente que los usuarios actualmente están
buscando características de auto-administración, rápido aprovisionamiento y ofertas
flexibles, en las cuales se pague únicamente por lo que se usa. Si la compañía de
comunicaciones cuenta con la capacidad de proveer estos servicios, dichos aspectos deben
ser consignados detalladamente en el SLA. Un ejemplo de esto es: “Se garantiza que la
instalación y activación de un nuevo canal solicitado por el usuario, será completado dentro
de los siguientes 40 días hábiles para Frame Relay, en canales de 56 K o T1 y 60 días
hábiles para canales T3”.
Con ésta base se debe evaluar la red del proveedor, de forma que se garantize el poder
cubrir los compromisos adquiridos en los SLAs, antes de realizar la firma del acuerdo y
adicionalmente, evaluar la posibilidad de ofrecer nuevos servicios que se conviertan en
ventajas competitivas. Así, al momento de la negociación, se puede definir detalladamente
con el usuario un SLA que contenga los niveles de disponibilidad requeridos, el perfil del
tráfico del cliente, las métricas de desempeño que la red debe proporcionar (por ejemplo en
cuanto al retardo, el rendimiento y las pérdidas), la definición de la forma como se tratará el
tráfico fuera de perfil, de las sanciones bilaterales y los costos y la forma de facturación.
Este acuerdo sirve adicionalmente para que el proveedor pueda distribuir los recursos
adecuadamente para cumplir con las demandas pactadas en los SLAs.
Algunos ejemplos de SLA ofrecidos por 6 empresas se detallan en el documento “Sample
SLAs for IP VPNs”, desarrollado por el grupo de trabajo de QoS de la IETF, en el año
2001.
A continuación se mostrará un ejemplo de cómo implementar una red privada virtual sobre
la red MPLS y se describirá una forma como los proveedores de servicios pueden reforzar
84
la red MPLS, para cumplir con los SLAs pactados, de tal manera que consigan QoS
extremo a extremo.
8.2.2. Implementación de MPLS VPNs
Uno de los objetivos en los que se enfoca este trabajo, consiste en la seguridad de la
comunicación que se va a efectuar a través de la red MPLS, utilizando para ello redes
privadas virtuales. En la sección 5.3 se explicó detalladamente el funcionamiento de una
VPN dentro de una red MPLS; en este punto se ejemplificará la configuración de MPLS
VPNs basadas en redes de paquetes, para equipos Cisco. Para ello se utilizará un ejemplo
desarrollado en el libro de Vivek Alwayn, “Advanced MPLS Design and Implementation”22
[7]. Se debe tener presente que cada fabricante exige unos prerrequisitos mínimos para
configurar MPLS y MPLS con VPNs en sus equipos. Por ejemplo, Nortel Networks exige
[21], para configurar MPLS sobre sus equipos Passport (equipos ATM), que cada nodo este
corriendo el software IP y el software ATM MPE (WAN_DTE) que configura LANs sobre
ATM.
Para equipos Cisco, por las exigencias del ejemplo, tanto los equipos de borde como los del
núcleo de la red del proveedor, deben estar corriendo el protocolo MPLS y CEF (Cisco
Express Forwarding), al igual que el protocolo BGP en todos los routers que
proporcionarán el servicio VPN.
Los pasos a seguir para la configuración y verificación de MPLS VPNs son los siguientes:
[7]
1. Configurar las interfaces y el protocolo de enrutamiento interior (IGP)
2. Definir las VPNs
3. Configurar las sesiones de enrutamiento PE-a-PE
4. Configurar las sesiones de enrutamiento PE-a-CE
22 Los ejemplos incluidos en este trabajo no fueron comprobados en el laboratorio; se basan en los datos
expuestos por el autor del libro referenciado.
85
5. Configurar los enrutadores del núcleo (P)
6. Configurar los enrutadores CE
Paso 1. Configuración de las Interfaces y del IGP.
Este es un paso básico que se realiza sobre todos los enrutadores de la red del proveedor,
para indicarles cuales son las interfaces que deben activar y cual es el protocolo de
enrutamiento interior que va a utilizar al comunicarse con los demás routers. Puesto que en
este caso de estudio la configuración que se va a realizar sobre los enrutadores del núcleo es
básica, el paso 6 es equivalente al paso 1 y no se detallará nuevamente. Las etapas a seguir
en esta configuración son las siguientes:
a. Habilitar el router Cisco en modo CEF, para poder correr MPLS: Router (config)# ip cef
b. Configurar la dirección IP de la interfaz de loopback para usarla como identificador
en el proceso de enrutamiento IGP: Router (config)# interface loopback n
Router (config-interface)# ip address dirección-ip mascara
c. Configurar el protocolo IGP. En este caso se usa OSPF: Router (config)# router ospf ospf-process-id
d. Definir una interfaz en la cual OSPF va a correr y definir el identificador de área para
esa interfaz: Router (config-router)# network dirección wildcard-mask area area-
id
e. Configurar las interfaces que conectan los enrutadores PE con la dirección IP. Para
este ejemplo se configura una interfase serial DS3: Router (config)# interface Serial slot/adaptador/puerto
Router (config-interface)# ip address dirección-ip mascara
f. Habilitar MPLS para la interfase (Cisco utiliza MPLS en vez de Label Switching): Router (config-interface)# mpls ip
86
Paso 2. Definir las VPNs.
Cada VPN de usuario se asocia con una instancia de enrutamiento que se definen en los
enrutadores PE de la siguiente forma:
a. Definir las diferentes instancias de enrutamiento y forwardeo para cada VPN
asignando nombres a las VRFs, únicos para cada usuario VPN. Los enrutadores CE
conectados a los enrutadores PE deben tener definidas sus VRFs. Router (config)# ip vrf vrf-name
b. Crear las tablas de enrutamiento para el usuario VPN, identificando la VPN con un
Route Distinguisher (RD). El RD añade un valor de 64 bits a la dirección IPv4 de 32
bits, creando un prefijo VPN IPv4 de 96 bits único para la VPN. El RD puede ser
relativo al sistema autónomo23 o a la dirección IP; en cualquier caso estaría además
conformado por un número arbitrario único para la VPN. Un ejemplo para el primer
caso (relativo a ASN) es 100:1 y para el segundo, 192.168.10.1:1 Router (config-vrf)# rd route-distinguisher
c. Crear una route target para la VRF con la que se especifica la comunidad extendida
de la VPN y definir si es para importar o exportar datos. Router (config-vrf)# route-target {import | export | both} route-
target-ext-community
d. Asociar la VRF con una interfaz o subinterfase. Este paso borra la dirección IP de la
interfaz, por lo que es necesario después de este punto, reconfigurar dicha dirección
nuevamente. Router (config-if)# ip vrf forwarding vrf-name
Paso 3. Configurar el enrutamiento PE-a-PE.
Este paso configura las sesiones MP-BGP para el intercambio de etiquetas internas y de los
label bindings:
23 ASN: número asignado por la IANA (Internet Assigned Numbers Authority), único para cada proveedor de
servicios.
87
a. Configurar el proceso de enrutamiento IBGP, pasando el número del sistema
autónomo a los demás enrutadores PE: Router (config)# router bgp sistema-autónomo
b. Desactivar la difusión de las direcciones unicast IPv4, con el fin de que MP-BGP
transporte únicamente sesiones VPN-IPv4: Router (config-router)# no bgp default ipv4-unicast
c. Especificar las direcciones IP de los enrutadores PE vecinos: Router (config- router)# neighbor {dirección-ip | peer-group-name}
remote-as número
d. Activar la difusión de direcciones IPv4 hacia los IBGP vecinos: Router (config- router)# neighbor dirección-ip activate
Paso 4. Configurar el enrutamiento PE-a-CE
El objetivo de este paso es que los enrutadores PE puedan asociar a la VRF particular
cualquier información de enrutamiento aprendida de la interfaz del usuario. Para ello se
utilizan protocolos de enrutamiento estándares interiores como RIPv2 y OSPF, o exteriores
como BGP4, o se configura enrutamiento estático en los enrutadores PE y los enrutadores
CE. Para el caso de estudio se va a utilizar enrutamiento estático para la red en Chicago,
RIPv2 para Seattle y BGP4 para San Diego:
Para configurar el enrutamiento estático se deben definir rutas estáticas para cada subred IP
de destino en la VRF del router PE conectado al router CE, para ello:
a. Se definen los parámetros del enrutamiento estático para cada sesión PE-a-CE: Router (config)# ip route vrf vrf-name
b. Definir los parámetros del enrutamiento estático para cada sesión de enrutamiento
San Diego No esta presente No esta presente No esta presente
Tabla 5. Esquema de direccionamiento IP VPN
Figura 25. Caso de Estudio: Red del Proveedor de Servicios
93
El desarrollo de los seis pasos descritos anteriormente en el caso de estudio analizado,
comenzará mostrando como se configuran los dos enrutadores del núcleo de red para
switcheo de etiquetas, utilizando OSPF como protocolo IGP.
Configuración del Router P1
! hostname P1 ! ip cef ! Habilitar CEF es prerrequisito para el manejo de etiquetas en ! enrutadores Cisco ! interface loopback0 ip address 10.10.6.1 255.255.255.255 ! Esto configura la dirección IP de loopback de P ! interface Serial2/0/0 ! Configura el DS3 para switcheo de etiquetas ip unnumbered loopback0 encapsulation ppp framing c-bit cablelength 3 dsu bandwidth 44210 clock source internal mpls ip ! interface Serial2/0/1 ! Configura el DS3 para switcheo de etiquetas ip unnumbered loopback0 encapsulation ppp framing c-bit cablelength 3 dsu bandwidth 44210 clock source internal mpls ip ! router ospf 100 network 10.10.6.1 0.0.0.0 area 0 !
Configuración del Router P2
! hostname P2 ! ip cef ! Habilitar CEF es prerrequisito para el manejo de etiquetas en ! enrutadores Cisco ! interface loopback0 ip address 10.10.7.1 255.255.255.255
94
! Esto configura la dirección IP de loopback de P ! interface Serial2/0/0 ! Configura el DS3 para switcheo de etiquetas ip unnumbered loopback0 encapsulation ppp framing c-bit cablelength 3 dsu bandwidth 44210 clock source internal mpls ip ! interface Serial2/0/1 ! Configura el DS3 para switcheo de etiquetas ip unnumbered loopback0 encapsulation ppp framing c-bit cablelength 3 dsu bandwidth 44210 clock source internal mpls ip ! interface Serial3/0/0 ! Configura el DS3 para switcheo de etiquetas ip unnumbered loopback0 encapsulation ppp framing c-bit cablelength 3 dsu bandwidth 44210 clock source internal mpls ip ! router ospf 100 network 10.10.7.1 0.0.0.0 area 0 !
Como se mencionó en el paso 4, la configuración de los routers PE y CE se basará en
diferentes protocolos de enrutamiento, manteniendo el mismo para la conectividad entre el
enrutador PE y los diferentes usuarios CE.
Configuración del Router PE1 en Chicago: con sesiones de enrutamiento estático:
! hostname Chicago_PE1 ! ip cef ! Habilitar CEF es prerrequisito para el manejo de etiquetas en ! enrutadores Cisco ! ip vrf vrf1 ! Define la instancia de enrutamiento vrf1 para la VPN del usuario A rd 100:1 ! Configura el Route Distinguisher para la vrf1
95
route-target both 100:1 ! Configura route-targets de importación y exportación para la vrf1 ! ip vrf vrf2 ! Define la instancia de enrutamiento vrf2 para la VPN del usuario B rd 100:2 ! Configura el Route Distinguisher para la vrf2 route-target both 100:2 ! Configura route-targets de importación y exportación para la vrf2 ! interface loopback 0 ip address 10.10.1.1 255.255.255.255 ! Esto configura la dirección IP de loopback de PE ! interface Serial9/0/0 ! Configura el DS3 para switcheo de etiquetas al núcleo ip unnumbered loopback0 encapsulation ppp framing c-bit cablelength 3 dsu bandwidth 44210 clock source internal mpls ip ! interface Ethernet4/0/0 ! Inicia la interface Ethernet como un enlace VRF al router CE-A ip vrf forwarding vrf1 ip address 172.16.254.1 255.255.255.252 ! interface Serial 5/0/0 ! Inicia un PVC de Frame Relay como un enlace VRF al router CE-B encapsulation frame-relay frame-relay lmi-type ansi ! interface Serial 5/0/0.1 point-to-point ip vrf forwarding vrf2 ip address 172.17.254.1 255.255.255.252 frame-relay interface-dlci 101 ! router ospf 100 network 10.10.1.1 0.0.0.0 area 0 ! router bgp 64512 ! Configura sesiones BGP no synchronization no bgp default ipv4-activate ! Desactiva las publicaciones por defecto de IPv4 neighbor 10.10.2.1 remote-as 64512 ! Define sesiones IBGP con PE2 neighbor 10.10.2.1 update-source loopback0 neighbor 10.10.3.1 remote-as 64512 ! Define sesiones IBGP con PE3 neighbor 10.10.3.1 update-source loopback0 !
96
address-family vpnv4 unicast ! Activa el intercambio PE de VPNv4 NLRI24 neighbor 10.10.2.1 activate neighbor 10.10.2.1 send-community extended neighbor 10.10.3.1 activate neighbor 10.10.3.1 send-community extended exit-address-family ! address-family ipv4 unicast vrf vrf1 redistribute static ! Publica rutas estáticas VRF a través de IBGP a los routers PE no auto-summary exit-address-family ! address-family ipv4 unicast vrf vrf2 redistribute static ! Publica rutas estáticas VRF a través de IBGP a los routers PE no auto-summary exit-address-family ! ! Define una ruta estática VRF para VRF1 ip route vrf vrf1 172.16.10.0 255.255.255.0 e4/0/0 ! ! Define una ruta estática VRF para VRF2 ip route vrf vrf2 172.17.10.0 255.255.255.0 S5/0/0 !
Configuración del Router CE del usuario A en Chicago: con sesiones de enrutamiento
estático:
! hostname Chicago_CE1 ! interface ethernet0/0 ip address 172.16.10.254 255.255.255.0 ! interface ethernet0/1 ip address 172.16.254.2 255.255.255.252 ! ip route 0.0.0.0 0.0.0.0 172.16.254.1 !
Configuración del Router CE del usuario B en Chicago: con sesiones de enrutamiento
estático:
24 Sistemas autónomos separados de diferentes proveedores de servicio, se pueden comunicar intercambiando
información IPv4 de acceso a capa de red (Network Layer Reachability Information o NLRI) en la forma de
direcciones VPN-IPv4 (o VPNv4), de forma que sea transparente para el usuario.
97
! hostname Chicago_CE2 ! interface ethernet0/0 ip address 172.17.10.254 255.255.255.0 ! interface Serial 5/0/0 ! Inicia un PVC de Frame Relay como un enlace al router PE encapsulation frame-relay frame-relay lmi-type ansi ! interface Serial 5/0/0.1 point-to-point ip address 172.17.254.2 255.255.255.252 frame-relay interface-dlci 100 ! ip route 0.0.0.0 0.0.0.0 172.17.254.1 !
Configuración del Router PE2 en Seattle: con sesiones de enrutamiento RIPv2 para la
conexión entre PE y CE:
! hostname Seattle_PE2 ! ip cef ! Habilitar CEF es prerrequisito para el manejo de etiquetas en ¡ enrutadores Cisco ¡ ip vrf vrf2 ¡ Define la instancia de enrutamiento vrf2 para la VPN del usuario B rd 100:2 ¡ Configura el Route Distinguisher para la vrf2 route-target both 100:2 ¡ Configura route-targets de importación y exportación para la vrf2 ¡ interface loopback 0 ip address 10.10.2.1 255.255.255.255 ¡ Esto configura la dirección IP de loopback de PE ¡ interface Serial9/0/0 ¡ Configura el DS3 para switcheo de etiquetas al núcleo ip unnumbered loopback0 encapsulation ppp framing c-bit cablelength 3 dsu bandwidth 44210 clock source internal mpls ip ! interface Ethernet4/0/0 ! Inicia la interface Ethernet como un enlace VRF al router CE-B ip vrf forwarding vrf2 ip address 172.17.253.1 255.255.255.252 ! router ospf 100
98
network 10.10.2.1 0.0.0.0 area 0 ! router rip version 2 network 172.17.0.0 ! address-family ipv4 vrf vrf2 version 2 network 172.17.0.0 redistribute bgp 64512 metric 1 no auto-summary exit-address-family ! router bgp 64512 ! Configura sesiones BGP no synchronization no bgp default ipv4-activate ¡ Desactiva las publicaciones por defecto de Ipv4 neighbor 10.10.1.1 remote-as 64512 ! Define sesiones IBGP con PE1 neighbor 10.10.1.1 update-source loopback0 neighbor 10.10.3.1 remote-as 64512 ! Define sesiones IBGP con PE3 neighbor 10.10.3.1 update-source loopback0 ¡ address-family vpnv4 unicast ¡ Activa el intercambio PE de VPNv4 NLRI neighbor 10.10.1.1 activate neighbor 10.10.1.1 send-community extended neighbor 10.10.3.1 activate neighbor 10.10.3.1 send-community extended exit-address-family ! address-family ipv4 unicast vrf vrf2 redistribute rip no auto-summary no synchronization exit-address-family ¡
Configuración del Router CE del usuario B en Seattle: con sesiones de enrutamiento
RIPv2:
! hostname Seattle_CE2 ! interface ethernet0/0 ip address 172.17.20.254 255.255.255.0 ! interface ethernet0/1 ip address 172.17.253.2 255.255.255.252 ! router rip version 2 network 172.17.0.0
99
¡
Configuración del Router PE3 en San Diego: con sesiones de enrutamiento BGP4 para la
conexión entre PE y CE:
! hostname San_Diego_PE3 ! ip cef ! Habilitar CEF es prerrequisito para el manejo de etiquetas en ¡ enrutadores Cisco ¡ ip vrf vrf1 ¡ Define la instancia de enrutamiento vrf1 para la VPN del usuario A rd 100:1 ¡ Configura el Route Distinguisher para la vrf1 route-target both 100:1 ¡ Configura route-targets de importación y exportación para la vrf1 ¡ interface loopback 0 ip address 10.10.3.1 255.255.255.255 ¡ Esto configura la dirección IP de loopback de PE ¡ interface Serial9/0/0 ¡ Configura el DS3 para switcheo de etiquetas al núcleo ip unnumbered loopback0 encapsulation ppp framing c-bit cablelength 3 dsu bandwidth 44210 clock source internal mpls ip ! interface Ethernet4/0/0 ! Inicia la interface Ethernet como un enlace VRF al router CE-A ip vrf forwarding vrf1 ip address 172.16.253.1 255.255.255.252 ! router ospf 100 network 10.10.3.1 0.0.0.0 area 0 ! router bgp 64512 ! Configura sesiones BGP no synchronization no bgp default ipv4-activate ¡ Desactiva las publicaciones por defecto de Ipv4 neighbor 10.10.1.1 remote-as 64512 ! Define sesiones IBGP con PE1 neighbor 10.10.1.1 update-source loopback0 neighbor 10.10.2.1 remote-as 64512 ! Define sesiones IBGP con PE2 neighbor 10.10.2.1 update-source loopback0 ¡ address-family vpnv4 unicast ¡ Activa el intercambio PE de VPNv4 NLRI
- Especificar el máximo número de paquetes que pueden ser encolados para una clase
de tráfico:
Router(config-pmap-c)# queue-limit paquetes
116
- Habilitar WRED con descarte de paquetes, para una clase de tráfico que tiene
garantías de ancho de banda:
Router(config-pmap-c)# random-detect
- Seleccionar en 1 el bit CLP de ATM:
Router(config-pmap-c)# set atm-clp
- Especificar el valor o valores de CoS que se deben asociar a un paquete:
Router(config-pmap-c)# set cos valor-cos
- Especificar el valor IP DSCP de los paquetes dentro de una clase de tráfico:
Router(config-pmap-c)# set ip dscp valor-ip-dscp
- Especificar la precedencia IP de los paquetes dentro de una clase de tráfico:
Router(config-pmap-c)# set ip precedence valor-precedencia-ip
- Designar los valores que se deben colocar en los bits EXP de MPLS, si los paquetes
están de acuerdo con un policy map específico:
Router(config-pmap-c)# set mpls experimental valor
Por ejemplo, para configurar una política que coloque el valor del campo EXP de MPLS en
4 para todos los paquetes que pertenezcan a la clase critica diseñada anteriormente, se usa:
Router(config)# policy-map set_experimental_4 Router(config-pmap)# class crítica Router(config-pmap-c)# set mpls experimental 4 Router(config-pmap-c)# end
Paso 3. Configurar la política de servicio que se va a adicionar a una interfaz
Para configurar una interfaz con una política de servicio, se especifica la dirección en la
cual la política debe ser aplicada (interfaz de entrada o salida) y se le añade la política
especificada, previamente creada:
Router(config)# interface nombre-interfaz
117
Router(config-int)# service-policy input nombre-policy-map Router(config-int)# end
Por ejemplo, para adicionar la política set_experimental_4 a una interfaz de entrada
Ethernet, se escribe:
Router(config)# interface ethernet 1/0/0 Router(config-int)# service-policy input set_experimental_4 Router(config-int)# end
Adicional. Configuración de CAR en el router PE de ingreso.
Cuando se hace necesario politizar la tasa de ingreso a la red, se puede utilizar la
herramienta CAR para clasificar los paquetes IP que ingresan a la red MPLS. De esta
forma, se seleccionan los bits EXP de MPLS basados en la acción de conformidad de la
política CAR. Es posible entonces configurar una lista de acceso de limitación de tasa en el
router PE de ingreso, que clasifique los paquetes IP de acuerdo con su nivel de precedencia
IP y configurar un limitador de tasa en la interfaz de entrada, que cree los paquetes MPLS
escribiendo la clasificación del paquete en el campo EXP:
Para clasificar los paquetes de acuerdo con la tasa de llegada, se utiliza el código:
Router(config)# access-list rate-limit indice-acl precedencia Router(config-int)# end
Por ejemplo, para configurar una lista de acceso limitadora de tasa 25 a todos los paquetes
con nivel de precedencia IP 5, se usa:
Router(config)# access-list rate-limit 25 5 Router(config-int)# end
La configuración de los bits EXP de MPLS en una interfaz de entrada según la
preclasificación IP, especifica la interfaz de entrada y la acción a tomar sobre los paquetes
A continuación se complementará el ejemplo desarrollado en la sección 8.2.2, que se
detalla en la siguiente figura, al añadirle la configuración de cuatro clases de servicio
definidas según el valor del campo Exp en la cabecera MPLS (5, 4, 3, 2), donde la clase 5
tiene mayor precedencia que la clase 4 y así sucesivamente. Todo el tráfico perteneciente a
una misma VPN recibirá el mismo nivel de servicio, es decir, se contarán con dos clases de
tráfico distintas, una para el usuario A y la otra para el usuario B.
Figura 27. Caso de Estudio: Red del Proveedor de Servicios
119
En la implementación de QoS en los enrutadores MPLS, se utilizarán los servicios de CAR
(Committed Access Rate) para clasificar paquetes de acuerdo con las tasas de transmisión
de entrada o salida, WRED para prevenir congestión descartando paquetes según el campo
EXP de MPLS y CBWFQ como algoritmo de colas que asegura la asignación del ancho de
banda adecuado a las diferentes clases de tráfico de red.
Se habilitará a los routers CE para seleccionar los bits de precedencia IP o los bits DSCP.
Dichos bits son mapeados al campo EXP de la etiqueta MPLS, en el momento de ingresar a
los enrutadores PE y allí se construye una etiqueta E-LSP.
En los enrutadores del núcleo a lo largo del camino LSP (Label Switched Path), se
implementa un PHB (Per-hop Behavior) basado en el valor del campo EXP de la etiqueta.
Los pasos a seguir en la configuración del caso de estudio son:
1. Crear las clases de tráfico
2. Crear las políticas de servicio y asociarles las clases de tráfico
3. Relacionar las políticas de servicio con las interfaces de entrada
Paso 1. Crear las clases de tráfico en los PE LSRs de ingreso, para la MPLS VPN.
Configuración del Router PE1: De acuerdo con la figura 27, se cuenta con una red MPLS
VPN definida sobre un backbone de enrutadores (red basada en paquetes), en la que los
usuarios A y B en Chicago van a ser provistos de servicios QoS para varias clases de
tráfico. Las clases de tráfico de QoS serán configuradas en los PE LSRs de ingreso.
En el PE1, el usuario A utiliza la interfaz E4/0/0 como interfaz de entrada al backbone
MPLS, mientras que el usuario B usa la interfaz de entrada S5/0/0. De esta forma, el
proveedor de servicios diferenciará los paquetes de los usuarios A y B y aplicará los
mecanismos de QoS apropiados a ellos. Los paquetes son clasificados como pertenecientes
a VPN_A y VPN_B respectivamente. Adicionalmente, el usuario B mantiene su propia
política interna de QoS usando los bits ToS de precedencia IP en la cabecera IP; estas
políticas deben ser mapeadas a los bits EXP de MPLS en el backbone de red. Se usa el
120
comando match-all para asignar a los paquetes que cumplan con ambos criterios a la clase
de tráfico VPN_B
PE1(config)# class-map VPN_A PE1(config-cmap)# match input interface Ethernet4/0/0 PE1(config-cmap)# end PE1(config)# class-map match-all VPN_B PE1(config-cmap)# match input interface Serial5/0/0 PE1(config-cmap)# match ip precedence 5 PE1(config-cmap)# end
Configuración del Router PE2 en Seattle: En este router el usuario B utiliza la interfaz de
ingreso E4/0/0 al backbone MPLS y mantiene sus propias políticas de QoS usando los bits
ToS de precedencia IP en la cabecera IP; estas políticas deben ser mapeadas a los bits EXP
de MPLS en el backbone de red. Se usa el comando match-all para asignar a los paquetes
que cumplan con ambos criterios a la clase de tráfico VPN_B.
PE2(config)# class-map match-all VPN_B PE2(config-cmap)# match input interface Ethernet4/0/0 PE2(config-cmap)# match ip precedence 5 PE2(config-cmap)# end
Configuración del Router PE3 en San Diego: En este enrutador el usuario A utiliza la
interfaz de ingreso E4/0/0 al backbone MPLS. Los paquetes que ingresen por dicha interfaz
serán clasificados como pertenecientes a la clase de tráfico VPN_A
PE3(config)# class-map VPN_A PE3(config-cmap)# match input interface Ethernet4/0/0 PE3(config-cmap)# end
Configuración del P-LSR: El MPLS LSR del núcleo puede manejar hasta siete clases de
tráfico, a las que puede asignar una QoS basada en los bits EXP de la etiqueta MPLS. En
este ejemplo se definirán cuatro clases en las que el criterio de selección se basa en el valor
del campo EXP de MPLS para determinar los recursos requeridos para el flujo de tráfico.
Los PHBs serán configurados en los P-LSRs.
P(config)# class-map class1 P(config-cmap)# match mpls experimental 5 P(config-cmap)# end P(config)# class-map class2 P(config-cmap)# match mpls experimental 4
121
P(config-cmap)# end P(config)# class-map class3 P(config-cmap)# match mpls experimental 3 P(config-cmap)# end P(config)# class-map class4 P(config-cmap)# match mpls experimental 2 P(config-cmap)# end
Las cuatro clases de tráfico anteriores deben ser configuradas en todos los P-LSRs (P1 y
P2).
Paso 2. Crear las políticas de servicio y asociarles las clases de tráfico para las distintas
VPNs.
Política de servicio para la VPN A: Se especifica que un mínimo ancho de banda
garantizado de 256 Kbps será entregado ante una eventual congestión, a todo el tráfico en la
clase de tráfico VPN_A. La cola para esta clase de tráfico podrá tener un máximo de 60
paquetes antes de comenzar a descartar con tail drop. Se asignará un valor de 4 a los bits
MPLS EXP para los paquetes que cumplan con la política de esta clase de tráfico
(VPN_A_policy).
Adicionalmente, se configurará una política para la clase por defecto, incluida dentro del
policy-map VPN_A_policy. Dicha clase tendrá configuradas 20 colas hash para el tráfico
que no cumpla con los criterios de conformidad de las clases asociadas a la policy-map
VPN_A_policy y un máximo de 40 paquetes por cola antes de que se descarten paquetes
por el mecanismo tail drop.
PE(config)# policy-map VPN_A_policy PE(config-pmap)# class VPN_A PE(config-pmap-c)# bandwidth 256 PE(config-pmap-c)# queue-limit 60 PE(config-pmap-c)# set mpls experimental 4 PE(config-pmap-c)# exit PE(config-pmap)# class class-default PE(config-pmap-c)# fair-queue 20 PE(config-pmap-c)# queue-limit 40 PE(config-pmap-c)# end
La política de servicio para la clase VPN_A debe ser implementada en todos los PE LSR
donde la VPN A tenga presencia (PE1 y PE3).
122
Política de servicio para la VPN B: Se especifica que un mínimo ancho de banda
garantizado de 128 Kbps será entregado ante una eventual congestión, a todo el tráfico en la
clase de tráfico VPN_B. Para abolición de congestión, se implementará el mecanismo de
descarte de paquetes de WRED, en vez de tail drop, con un factor de peso26 de 10 usado
para calcular el tamaño promedio de la cola. Se asignará un valor de 3 a los bits MPLS
EXP para los paquetes que cumplan con la política de esta clase de tráfico
(VPN_B_policy).
Adicionalmente, se configurará una política para la clase por defecto, incluida dentro del
policy-map VPN_B_policy. Dicha clase tendrá configuradas 20 colas hash para el tráfico
que no cumpla con los criterios de conformidad de las clases asociadas a la policy-map
VPN_B_policy. Para abolición de congestión se utilizara el mecanismo WRED de descarte
de paquetes, en lugar de tail drop, con un factor de peso de 15 usado para calcular el
tamaño promedio de la cola.
PE(config)# policy-map VPN_B_policy PE(config-pmap)# class VPN_B PE(config-pmap-c)# bandwidth 128 PE(config-pmap-c)# random-detect exponential-weighting-constant 10 PE(config-pmap-c)# set mpls experimental 3 PE(config-pmap-c)# exit PE(config-pmap)# class class-default PE(config-pmap-c)# fair-queue 20 PE(config-pmap-c)# random-detect exponential-weighting-constant 15 PE(config-pmap-c)# end
La política de servicio para la clase VPN_B debe ser implementada en todos los PE LSR
donde la VPN B tenga presencia (PE1 y PE2).
Política de servicio para los P-LSRs: se configuran las políticas de servicio para las
diferentes clases de tráfico que atraviesan el núcleo P-LSRs.
Política de servicio para la clase de tráfico class1: Se especifica un mínimo ancho de banda
garantizado de 512 Kbps para todo el tráfico en la clase de tráfico class1. La cola reservada
para esta clase de tráfico podrá tener un máximo de 90 paquetes antes de comenzar a
26 Ver referencia [19]
123
descartar con tail drop. La clase por defecto tendrá configuradas 20 colas hash con un
máximo de 40 paquetes antes de que actúe el mecanismo de tail drop.
Política de servicio para la clase de tráfico class2: Se especifica un mínimo ancho de banda
garantizado de 256 Kbps para todo el tráfico en la clase de tráfico class2. La cola reservada
para esta clase de tráfico podrá tener un máximo de 60 paquetes antes de comenzar a
descartar con tail drop. La clase por defecto tendrá configuradas 20 colas hash con un
máximo de 40 paquetes antes de que actúe el mecanismo de tail drop.
Política de servicio para la clase de tráfico class3: Se especifica un mínimo ancho de banda
garantizado de 128 Kbps para todo el tráfico en la clase de tráfico class3. La cola reservada
para esta clase de tráfico podrá tener un máximo de 30 paquetes antes de comenzar a
descartar con tail drop. La clase por defecto tendrá configuradas 20 colas hash con un
máximo de 40 paquetes antes de que actúe el mecanismo de tail drop.
Política de servicio para la clase de tráfico class4: Se especifica un mínimo ancho de banda
garantizado de 64 Kbps para todo el tráfico en la clase de tráfico class4. La cola reservada
para esta clase de tráfico podrá tener un máximo de 30 paquetes antes de comenzar a
descartar con tail drop. La clase por defecto tendrá configuradas 20 colas hash con un
máximo de 40 paquetes antes de que actúe el mecanismo de tail drop.
P(config)# policy-map class_PHB_policy P(config-pmap)# class class1 P(config-pmap-c)# bandwidth 512 P(config-pmap-c)# queue-limit 90 P(config-pmap-c)# exit P(config-pmap)# class class2 P(config-pmap-c)# bandwidth 256 P(config-pmap-c)# queue-limit 60 P(config-pmap-c)# exit P(config-pmap)# class class3 P(config-pmap-c)# bandwidth 128 P(config-pmap-c)# queue-limit 30 P(config-pmap-c)# exit P(config-pmap)# class class4 P(config-pmap-c)# bandwidth 64 P(config-pmap-c)# queue-limit 30 P(config-pmap-c)# exit P(config-pmap)# class class-default P(config-pmap-c)# fair-queue 20 P(config-pmap-c)# queue-limit 40 P(config-pmap-c)# end
124
La política de servicio para la clase de tráfico class_PHB_policy debe ser implementada en
todos los P-LSR (P1 y P2).
Paso 3. Relacionar las políticas de servicio con las interfaces de entrada
2. Como protocolo de última milla, ¿que es lo más empleado por las empresas PIME
clientes, o a que tienden al interconectarse con su proveedor de comunicaciones?
ATM, Frame Relay, IP, o DSL.
3. ¿De que tamaño son estas empresas clientes, respecto al número de empleados?
4. Ejemplos de solicitudes específicas que hagan los clientes para calidad de servicio
en sus interconexiones, ya sea con otras sucursales o hacia Internet, y como se están
proveyendo dichos servicios actualmente.
5. Respecto a MPLS, ¿que fabricante de equipos se esta empleando principalmente?
131
11. Anexo 2. Guía Metodológica
Los pasos básicos necesarios por parte del proveedor de servicios para la implementación
de calidad de servicio en redes MPLS con VPNs, se enumeran a continuación.
1. Conocimiento y dimensionamiento de su red para realizar ofertas de calidad de
servicio acordes a sus posibilidades: Página 82
2. Definición de acuerdos de nivel de servicio: Página 82
3. Implementación de VPNs sobre la red MPLS: Página 85
a. Configuración de las interfaces y del protocolo de enrutamiento interior:
página 86
b. Definición de las VPNs: página 87
c. Configuración de las sesiones de enrutamiento PE – PE: página 87
d. Configuración de las sesiones de enrutamiento PE – CE: página 88
e. Configuración de los enrutadores del núcleo: página 91
f. Configuración de los enrutadores del usuario: página 91
4. Implementación de los mecanismos de calidad de servicio sobre la MPLS VPN:
páginas 101 y 113:
a. Definición y configuración de las clases de tráfico. Incluye clasificación y
marcación de los paquetes: páginas 103 y 113.
b. Creación de las políticas de servicio, asociándolas con la clase de tráfico
respectiva. Incluye la definición de los mecanismos de control de admisión,
132
de administración de congestión y de abolición de congestión: páginas 106 y
115.
c. Relacionar las políticas de servicio con las interfaces de entrada y salida:
página 117
5. Aspectos Adicionales: Implementación de Extranets y acceso a Internet: página 111
133
12. Anexo 3. Opciones de Implementación
Vieneclasificado
por el usuario
Clasifica elProveedor
Control deAcceso
¿El paquetecumple con la
política deservicio?
Etiquetarsegún
clasificación
Descartar
Asignar prioridadde descarte y
etiquetar elpaquete según
políticas
Consultar laLBIF y dirigir ala Interfaz de
salida
No
1
Si
No
Ingresa elpaquete
1 2
2
Transmitir
Encolar yProgramar
transmisión segúnla clasificación
Figura 28. Comportamiento al Ingreso de la red MPLS (LSR de Borde)
134
Revisión dela etiqueta
¿El paquetecumple con la
política deservicio?
Descartar
Asignar prioridadde descarte y
etiquetar el paquetesegún políticas y
los datos de la LFIB
Dirigir a laInterfaz de salida
No
No
Llega el paqueteal router P
Transmitir
Encolar yProgramar
transmisión segúnla clasificación
Etiquetar elpaquete según la
LFIB
Aplicar técnicas deabolición de
congestión (RED)
Si
Figura 29. Comportamiento en el núcleo de la red
135
Revisión dela etiqueta
Llega el paqueteal router PER
¿El paquetesale de la red
MPLS?
Aplican políticasde calidad de
servicio según laclasificación del
paquete IP
Retira laEtiqueta
Si
EnrutamientoTradicional
Consulta laLFIB No
Aplicar políticas decalidad de servicio
según laclasificación en la
etiqueta
Volver aetiquetar el
paquete
TransmitirEnrutar segúnla etiqueta
Figura 30. Comportamiento en el borde de egreso de la red MPLS
136
13. Anexo 4. Tabla comparativa
En la siguiente tabla se resume las caracterísiticas adicionales que se consiguen al
implementar calidad de servicio, VPNs, MPLS y QoS para MPLS con VPNs sobre las
redes de comunicación tradicionales IP.
Servicio de comunicación Tradicional IP
Tradicional + Calidad de Servicio
Tradicional + VPNs
Tradicional + MPLS
QoS en redes MPLS con VPNs
§ Proporciona con mínimas garantías de servicio § Bajo nivel de
seguridad § Dificulta el
balanceo de cargas § Se revisa la
cabecera del paquete en cada nodo de red para tomar decisiones de enrutamiento
§ Requiere implementar IntServ o DiffServ o soportarse sobre tecnologías capa dos como ATM, que garanticen QoS. § Permite soportar
tráfico sensible a pérdidas o retardos § Soporte limitado
sobre redes enrutadas.
§ Adiciona características de seguridad al tráfico usuario sobre conexiones públicas, sin necesidad de contratar conexiones dedicadas, o de establecer nuevos PVCs difíciles de escalar.
§ Facilita la transmisión de paquetes al permitir manejar etiquetas. § Permite
Implementar ingeniería de tráfico § Facilita el
balanceo de cargas § Hace posible un
rápido reenrutamiento y recuperación ante fallas. § Une las mejores
características de enrutamiento IP con transmisión ATM.
§ Permite ofrecer diferentes niveles de QoS al tráfico usuario § Ofrece altos niveles de
seguridad a las conexiones de los clientes. § Habilita el
reconocimiento de tráfico crítico, aun cuando este se encuentre encriptado o dentro de un túnel. § Hace posible
implementar Ingeniería de tráfico. § Es un servicio fácil de
escalar y con una excelente relación costo – beneficio tanto para los clientes como para los proveedores de servicios de comunicación.
137
14. Glosario de Acrónimos
AF-PHB. Assured Forwarding PHB
AS. Applicability Statement
AToM. Any Transport Over MPLS
BGP. Border Gateway Protocol
BGP4. Border Gateway Protocol Version 4
CAR. Committed Access Rate
CBQ. Class Based Queuing
CBWFQ. Class Based WFQ
CE. Customer Edge Router
CEF. Cisco Express Forwarding
CIR. Committed Information Rate
CLP. Cell Loss Priority: bit de prioridad de pérdida de celdas en la cabecera ATM
CoS. Class of Service
CQ. Custom Queuing
CR-LDP. Constraint-based Routing Label Distribution Protocol
CRTP. Compressed Real-Time Protocol
DE. Discard Elegible: bit en la cabecera ATM
DiffServ. Differentiated Services
138
DLCI. Data Link Connection Identifier: campo en la cabecera Frame Relay