CALIDAD DE SERVICIO EN REDES MPLS CON VPNs
142
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
Transcript of CALIDAD DE SERVICIO EN REDES MPLS CON VPNs
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
2
Tabla de Contenido
1. INTRODUCCIÓN .................................................................................................................................. 4
2. METODOLOGÍA ................................................................................................................................... 6
3. USUARIOS DIRECTOS Y FORMAS DE UTILIZACIÓN DE LOS RESULTADOS
ESPERADOS .................................................................................................................................................... 7
4. OBJETIVOS............................................................................................................................................ 8
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 MPLS VPN.................................................................................................................................... 59
3
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
6.1 JUSTIFICACIÓN ............................................................................................................................... 73 6.2 PROYECCIONES .............................................................................................................................. 74
7. DELIMITACIÓN DEL TRABAJO .................................................................................................... 75
8. DESCRIPCIÓN..................................................................................................................................... 78
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
9. CONCLUSIONES............................................................................................................................... 126
10. ANEXO 1. PREGUNTAS FORMULADAS A CLIENTES Y EMPRESAS PROVEEDORAS
DE SERVICIOS DE COMUNICACIÓN ................................................................................................... 130
11. ANEXO 2. GUÍA METODOLÓGICA......................................................................................... 131
12. ANEXO 3. OPCIONES DE IMPLEMENTACIÓN.................................................................... 133
13. ANEXO 4. TABLA COMPARATIVA ......................................................................................... 136
14. GLOSARIO DE ACRÓNIMOS.................................................................................................... 137
15. BIBLIOGRAFÍA Y FUENTES DE INFORMACIÓN ............................................................... 141
4
1. Introducción
La actual demanda de aplicaciones relacionadas con información multimedia, como son la
video-conferencia, audio-conferencia y video bajo demanda (VoD) entre otros y su
coexistencia con aplicaciones clásicas como bases de datos, transferencias de archivos y
WWW, han obligado a las compañías proveedoras de servicios de comunicación a buscar e
implementar tecnologías y estrategias que les permitan atacar agresivamente los nuevos
mercados, ofreciendo servicios fácilmente escalables y administrables, con altos estándares
de seguridad y diferentes niveles de calidad de servicio, que cumplan con los
requerimientos del cliente para sus interconexiones privadas y públicas (Intranet, Extranet e
Internet), de forma que obtengan la mejor relación costo-beneficio.
Las redes de computadores actuales, basadas en enrutadores, adolecen de la capacidad para
proporcionar implícitamente unos niveles de calidad de servicio necesarios para la
transmisión del tráfico multimedia (ofrecen un servicio Best Effort o de mejor esfuerzo).
Otras redes, como ATM (Asynchronous Transfer Mode), aunque si fueron diseñadas para
proporcionar con distintos niveles de calidad de servicio, se enfrentan al problema de la
dificultad para escalar la red a nuevas interconexiones, lo que las hace costosas de
implementar. Es por esto que se han diseñado nuevos protocolos y políticas de gestión de
los recursos de red, en un esfuerzo por obtener una calidad de servicio extremo a extremo y
garantizar la compatibilidad de las distintas tecnologías a causa de la heterogeneidad de las
redes.
MPLS es una tecnología reciente, desarrollada para extender los servicios proporcionados
por las redes IP, en ingeniería de tráfico, calidad de servicio (QoS) y redes privadas
5
virtuales (VPNs: Virtual Private Networks). Es un estándar propuesto por la IETF (Internet
Engineering Task Force)1, 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 Label
Switching, donde Multiprotocol se refiere al hecho de poder ser aplicado a cualquier
protocolo de red de capa 3, aunque su interés principal es el tráfico IP, como será el
enfoque de ésta tesis.
Con el desarrollo del presente trabajo de grado, se busca proporcionar a las empresas
proveedoras de servicios de comunicación con las bases teóricas necesarias para entender el
funcionamiento de las redes MPLS, sus características y ventajas, y la forma de
implementar calidad de servicio sobre redes MPLS con VPNs, de modo que puedan entrar
a competir con ventaja en el nuevo mercado.
1 RFC 3031, “Multiprotocol Label Switching Architecture”, 2001
6
2. Metodología
Para el desarrollo de este trabajo de grado, se inició con una etapa de investigación y
profundización en los mecanismos de calidad de servicio y su forma de implementación.
Igualmente, se estudiaron algunos trabajos desarrollados respecto a la implementación de
calidad de servicio en redes MPLS y calidad de servicio en VPNs. Con esta información,
se desarrolló en forma teórica una guía metodológica que conlleva a implementar QoS en
redes MPLS con VPNs de forma que, teniendo en cuenta los estándares de Internet, se
especificaron los requerimientos de red, las ventajas y limitaciones de la aplicación para
diferentes tipos de redes y clases de servicio, así como el tipo de acuerdos de servicios que
se podrían llegar a establecer entre proveedores y clientes.
El trabajo concluye con un documento guía metodológico que especifica los procesos del
montaje de redes MPLS con VPNs, aprovisionados con los mecanismos de Calidad de
Servicio. Para ello, se ha organizado el trabajo de la siguiente forma: en el capítulo 3 se
indican los usuarios directos del trabajo y la forma como pueden implementar los
resultados mostrados en el mismo. En los capítulos 4, 5 y 6 se describen los objetivos del
trabajo, la justificación y proyecciones del mismo y el marco teórico necesario para la
comprensión de los aspectos básicos de calidad de servicio y de la tecnología MPLS.
Los capítulos 7 y 8 delimitan y describen la guía metodológica propuesta para la
implementación de servicios con diferentes niveles de calidad sobre redes MPLS con
VPNs. En el capítulo 9 se encuentran las conclusiones obtenidas con el desarrollo del
proyecto.
Por último, algunos anexos que complementan esta investigación se desarrollan en los
capitulos 10 al 15.
7
3. Usuarios Directos y Formas de Utilización
de los Resultados Esperados
La guía metodológica desarrollada en este trabajo de grado sirve como base a empresas
proveedoras de servicio en el proceso de implementación de QoS en redes MPLS con
VPNs. En ella se incluye un análisis de las ventajas que ofrece dicha implementación, de
los tipos de servicio que se podrían ofrecer a los clientes y de los requisitos necesarios en
éstos últimos.
8
4. Objetivos
4.1 Objetivo General
Realizar una guía metodológica donde se indiquen los pasos básicos necesarios para el
montaje de Calidad de Servicio en redes MPLS con VPNs, indicando las ventajas, los
requerimientos, la forma de implementación y los niveles de servicio que el proveedor
puede ofrecer a sus clientes. Para ello, se realizó una investigación acerca de las
características que se deben cumplir en calidad de servicio y su aplicación a las redes
MPLS con VPN.
4.2 Objetivos Específicos
1. Estudiar a fondo los mecanismos de implementación de calidad de servicio, su
definición, área de cubrimiento y modo de empleo.
2. Profundizar en el conocimiento de la aplicación de calidad de servicio para redes
MPLS.
3. Investigar acerca de los estándares de la industria para calidad de servicio en redes
MPLS.
4. Analizar los métodos de implementación de calidad de servicio en VPNs, sus
características, ventajas y falencias.
5. Analizar los procesos de implementación de calidad de servicio en redes MPLS con
VPN, tanto si son estándares de la industria, como si son ofrecidos por compañías
particulares.
6. Proponer una guía metodológica para la implementación de servicios de calidad,
según los requerimientos de los clientes.
9
5. Marco Teórico
El desarrollo e implementación del presente trabajo exige tener conocimientos tanto de
Calidad de Servicio, como de la tecnología MPLS y MPLS con VPNs. Es por esto que a
continuación se resumen las bases teóricas necesarias para cubrir dichos campos. Es
necesario aclarar que en la actualidad el tema de calidad de servicio esta siendo sujeto a una
profunda investigación, y por ende, los planteamientos aquí realizados pueden cambiar
rápidamente.
5.1 Calidad de Servicio
La definición de calidad de servicio depende del ámbito en el cual se implemente. Para el
caso de las telecomunicaciones, se puede definir calidad de servicio como “el efecto
colectivo del rendimiento de un servicio que determina el grado de satisfacción del usuario
de dicho servicio” [20]. En el ámbito de la telemática, QoS es la capacidad de un elemento
de red – ya sea una aplicación, un servidor, un enrutador, o cualquier elemento que tome
parte en la comunicación – de asegurar que su tráfico y los requisitos del servicio
previamente establecidos puedan ser satisfechos; habilitarla requiere además la cooperación
de todas las capas de la red, así como de cada elemento de la misma (arquitectura de
sistema punto-a-punto). Desde este punto de vista, la QoS también suele ser definida como
un conjunto de tecnologías y mecanismos que permiten a los administradores de red
manejar los efectos de la congestión del tráfico y controlar la mezcla de ancho de banda,
retardo, jitter y pérdida de paquetes en una red, usando óptimamente los diferentes recursos
de la misma.
10
QoS se refiere a la habilidad de una red de proporcionar servicio mejorado a un tráfico de
red seleccionado sobre varias tecnologías soportadoras, incluyendo Frame Relay, ATM,
redes Ethernet y 802.1, SONET, redes enrutadas IP, entre otras.
Toda arquitectura de calidad de servicio en redes heterogéneas, debe implementar:
- QoS en cada elemento de red, incluyendo características de colas, programación
(scheduling) y traffic shaping.
- Técnicas de señalización de QoS para coordinar la QoS en la entrega end-to-end
entre los elementos de red.
- Funciones de administración y políticas de QoS para controlar y administrar el
tráfico end-to-end a lo largo de la red.
La tarea de mantener un nivel de calidad de servicio adecuado a cada tipo de tráfico, es
realizada en su mayoría por los nodos de red como Switches y Routers; en ellos, la
implementación de las técnicas de calidad de servicio, depende de la función que cumplan
dentro de la red, ya que no desempeñan las mismas operaciones. En general los routers de
borde desempeñan las siguientes funciones de calidad de servicio:
- Clasificación de paquetes
- Control de admisión
- Administración de congestión
Mientras que las funciones de QoS para los enrutadores del núcleo, core o backbone
incluyen:
- Administración de congestión
- Abolición de congestión
Es necesario diferenciar el término calidad de servicio (QoS), de los términos Clase de
Servicio (CoS) y Tipo de Servicio (ToS), puesto que éstos dos últimos se refieren a dos
técnicas utilizadas para obtener QoS. Así, CoS implica la prioritización de los distintos
11
tipos de tráfico definidos a través de la red y la definición de las clases de servicio que se
aplicarán a los tipos de tráfico diferenciados. CoS, a diferencia de QoS, no garantiza ancho
de banda o latencia para tráfico específico, sino que permite a los administradores de red
solicitar prioridad para el tráfico basándose en la importancia de éste.
El tipo de servicio o ToS es una técnica que permite reservar el ancho de banda con
antelación a la transmisión, de modo que el tráfico preferencial, como es el tráfico de voz o
una CoS con prioridad, pueda utilizar el ancho de banda reservado. ToS no implica ningún
tipo de garantías. El protocolo IP Versión 4 incluye un campo en el paquete IP para el tipo
de servicio (IP TOS). En este campo se pueden especificar los atributos de confiabilidad,
capacidad de procesamiento y retardos del servicio.
Figura 1. Campo ToS en IPv4. [20]
Como requisito adicional a la definición y diferenciación de calidad de servicio, es
necesario realizar una clasificación de la misma según la sensibilidad del tráfico para el
cual se aplicará la asignación de recursos de la red, tal y como se indica a continuación.
Teniendo en cuenta la variedad de tráfico existente y los requerimientos de retardo, latencia
y ancho de banda para cada tipo, se pueden definir cuatro niveles de calidad de servicio,
que son los que se implementarán en esta guía:
1. QoS muy sensible al retardo para tráfico de tiempo real. En este nivel se incluye
el tráfico de vídeo comprimido, que requiere altas garantías de disponibilidad
del canal, gran cantidad de ancho de banda reservado y un valor de retardo
mínimo que asegure la correcta transmisión del mismo. Para conseguirlo será
Precedencia ToS MRZ
Ver IHL IP ToS Long… Datos
IP ToS
Paquete IP
Trama Ethernet P DA SA T/L Datos CRC
12
necesario utilizar mecanismos de prioridad, definidos posteriormente, así como
encolar adecuadamente los flujos de datos.
2. QoS algo sensible al retardo para tráfico tipo Oro. Al igual que en el caso
anterior, en este nivel se garantiza hasta una cierta cantidad de ancho de banda,
aunque en menor valor. De la misma manera, será necesario asignar prioridades
para la transmisión de los datos.
3. QoS muy sensible a pérdidas para tráfico tipo Plata. En este nivel se clasifica el
tráfico tradicional, que requiere niveles muy bajos (cercanos a cero) de pérdidas
de paquetes. Para ello se deben implementar buffers de almacenamiento de datos
diseñados con la suficiente profundidad para que se minimice el descarte de
paquetes y se evite el desbordamiento del mismo.
4. QoS nada sensible para tráfico tipo Bronce o de Mejor Esfuerzo. En este campo
se clasifica por ejemplo el tráfico de servicios de noticias, que no requiere
garantías de retardos o de pérdidas. Aquí se usa cualquier oportunidad de
transmisión que se presente y se asume que la capacidad de los buffers es
suficiente para llevarla a cabo. A este tipo de tráfico se le asigna la prioridad
más baja.
A continuación se describen algunos modelos de servicio definidos por la IETF para
implementar QoS extremo-a-extremo en una red.2
5.1.1. Modelos End to End de QoS
Un modelo de servicio describe un conjunto de capacidades end-to-end que se requieren
para implementar QoS entre dos extremos de una red; entre ellos se encuentran los modelos
de mejor esfuerzo, servicios integrados y servicios diferenciados, que se diferencian en la
forma en que habilitan a las aplicaciones para enviar datos y en el camino o la forma en la
que la red intenta enviar los mismos.
2 RFC 2475: “An Architecture for Differentiated Services” y RFC 1633: “Integrated Services in the Internet
Architecture: an Overview”.
13
5.1.1.1. Servicio del mejor esfuerzo
En este modelo, una aplicación envía datos cada vez que lo requiera, y en cualquier
cantidad, sin solicitar permiso ni informar inicialmente a la red. En este servicio, la red
envía los datos si puede, sin asegurar nada respecto a la confiabilidad, rendimiento ni
retardos. El principal problema de este modelo se presenta al tener una ráfaga de paquetes
dentro de uno de los múltiples flujos de datos que se manejan, puesto que ésta afectará a
todos los demás flujos retardando su transmisión. Es decir, que el tiempo de llegada de los
paquetes de un flujo puede verse afectado por otros flujos.
5.1.1.2. Servicios Integrados
En el modelo de servicios Integrados, la aplicación solicita un tipo de servicio específico a
la red, antes de enviar los datos. Para ello, la aplicación le informa a la red del perfil de su
tráfico, solicitando un servicio que cumpla con sus requerimientos de ancho de banda y
retardo. Se espera que el envío de datos inicie una vez se haya recibido confirmación por
parte de la red. La red a su vez, realiza control de admisión basado en la información de la
aplicación y en los recursos disponibles de red y se compromete a mantener la calidad de
servicio, mientras que el perfil del tráfico permanezca dentro de los límites especificados.
El Protocolo de Reserva de Recursos o RSVP (por sus siglas en ingles) [RFC2205, Versión
1 Functional Specification] es un componente clave de la arquitectura de los Servicios
Integrados en Internet IETF (IntServ) en la que se define el funcionamiento y la forma de
petición e intercambio de información entre y para cada elemento de la red, de forma que se
realiza un control de la calidad de servicio. RSVP es un protocolo de señalización que
proporciona un control para la reserva de recursos de red, orientado fundamentalmente a
redes IP. [20]
La reserva de recursos se realiza en todos los routers situados a lo largo del camino que
seguirán los datos de la aplicación. La tarea del protocolo consiste en establecer y mantener
las reservas de recursos a lo largo de dicho camino.
14
El grupo de trabajo Integrated Services del IETF ha considerado la existencia de varias
clases de QoS; si bien actualmente sólo dos de éstas han sido formalmente especificadas
para ser utilizadas con RSVP:
• Servicios garantizados (Guaranteed Service) (RFC2211):
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
10 Forward/Backward explicit congestion notification
36
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
12 RFC 3031, “Multiprotocol Label Switching Architecture”, 2001
50
Label Switching, donde Multiprotocol se refiere al hecho de poder ser aplicado a cualquier
protocolo de red de capa 3, aunque su interés principal es el trafico IP. MPLS no remplaza
el enrutamiento IP, sino que extiende los servicios que pueden ser proporcionados por las
redes IP, en Ingeniería de Tráfico, Calidad de Servicio (QoS) y VPNs.
Tácitamente implica la inserción de una nueva capa entre las capas 2 y 3 del modelo OSI,
que las haga funcionar mejor, de forma que toma las mejores características de cada una.
La arquitectura MPLS describe los mecanismos necesarios para desarrollar conmutación de
etiquetas o labels, de forma que se combinen los beneficios del transporte de paquetes
basados en la conmutación capa 2, con los beneficios del enrutamiento capa 3. Las
etiquetas indican tanto las rutas como los atributos del servicio. En el borde de ingreso a la
red, los paquetes entrantes son procesados y se les aplica la etiqueta seleccionada (dicha
selección depende de la negociación o binding que el nodo hizo con los demás nodos de
borde de la red, como se explicara posteriormente). El núcleo de la red, únicamente lee las
etiquetas, le aplica el servicio adecuado a las mismas y continúa con el envío del paquete
basado en ellas. Es por esto que el análisis, la clasificación y el filtrado de paquetes ocurren
una sola vez, al ingreso de la red. En el borde de egreso, las etiquetas son retiradas y el
paquete es transportado hasta su destino final.
5.2.2. Bloques Constitutivos
Como con toda nueva tecnología, se introducen nuevos términos que describen los
dispositivos conformadores de la arquitectura:
Label Switch Router (LSR): Nodo MPLS capaz de transportar paquetes capa 3. Cualquier
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
BGP PE-a-CE: Router (config-router)# address-family ipv4 [unicast] vrf vrf-name
c. Redistribuir las rutas estáticas VRF en la tabla VRF BGP, de forma que se pase la
información de enrutamiento estático de una VRF a todos los demás PEs:
88
Router (config-router-af)# redistribute static
d. Redistribuir las redes directamente conectadas en la tabla VRF BGP: Router (config-router-af)# redistribute connected
Configuración de Protocolos de enrutamiento Interior:
Para configurar sesiones de enrutamiento RIPv2 entre PE y CE se siguen los siguientes
pasos en el router PE:
a. Habilitar las versión 2 de RIP: Router (config)# router rip
Router (config-router)# version 2
b. Definir los parámetros de RIP para la sesión de enrutamiento PE-a-CE en el
submodo address-family dentro del proceso de configuración principal de RIP, de
forma que la propagación de las rutas RIP no se realice en las tablas de enrutamiento
globales sino dentro de la VRF de la VPN del usuario: Router (config-router)# address-family ipv4 [unicast] vrf vrf-name
c. Asociar una red con el proceso de enrutamiento RIP, bajo del submodo address-
family: Router (config-router-af)# network prefix
d. Redistribuir las rutas IBGP en la familia de direcciones RIP para distribuir dichas
rutas hacia los enrutadores CE: Router (config-router-af)# redistribute bgp asn metric metric
Para configurar sesiones de enrutamiento OSPF entre PE y CE se siguen los siguientes
pasos en el router PE:
a. Habilitar OSPF con extensiones a la VRF: Router (config)# router ospf id-proceso-ospf vrf vrf-name
b. Definir la interface donde correra OSPF y definir la identificación del área para dicha
interface: Router (config)# network address wildcard-mask area area-id
89
c. Redistribuir las rutas IBGP dentro del proceso OSPF VRF: Router (config-router-af)# redistribute protocol [process-id]
{level-1 | level-1-2 | level-2} [metric metric-value] [metric-type
type-value] [match internal | external 1 | external 2] [tag tag-
value] [route-map map-tag] [weight weight] [subnets]
d. Acceder al submodo address-family dentro de la configuración del proceso principal
IBGP: Router (config-router)# address-family ipv4 [unicast] vrf vrf-name
e. Redistribuir las rutas VRF OSPF dentro de IBGP en el submodo de configuración
address-family: Router (config-router-af)# redistribute protocol [process-id]
{level-1 | level-1-2 | level-2} [metric metric-value] [metric-type
type-value] [match internal | external 1 | external 2] [tag tag-
value] [route-map map-tag] [weight weight] [subnets]
Configuración de protocolos de enrutamiento exterior: en este caso el cliente debe tener un
número de sistema autónomo (AS).
Para configurar sesiones de enrutamiento BGP4 entre PE y CE se realizan los siguientes
pasos en el enrutador PE:
a. Configurar un proceso de enrutamiento IBGP con el número del sistema autónomo
pasado en el comando a los otros routers PE: Router (config)# router bgp sistema-autónomo
b. Definir los parámetros EBGP para las sesiones de enrutamiento PE-a-CE, entrando
en el submodo address-family dentro del proceso de configuración principal de
IBGP: Router (config-router)# address-family ipv4 [unicast] vrf vrf-name
c. Especificar las direcciones IP de los CEs vecinos: Router (config-router-af)# neighbor {dirección-ip | peer-group-
name} remote-as número
d. Activar la difusión de las direcciones IPv4:
90
Router (config-router-af)# neighbor dirección-ip activate
Paso 5. Configurar los enrutadores P.
Los enrutadores del núcleo de la red del proveedor son LSRs que participan en el protocolo
de enrutamiento IGP como OSPF o IS-IS, pero no toman parte del proceso multiprotocolo
IBGP, por lo que tienen una configuración más simple que los routers de borde PE, e igual
a la realizada en el paso 1. Es por esto que no se volverán a especificar aquí cada uno de
los pasos de configuración.
Paso 6. Configurar los routers CE
La configuración del los routers CE puede basarse en enrutamiento estático o en los
protocolos inteiores RIPv2 y OSPF, o exteriores como BGP4. Se debe configurar el mismo
protocolo de enrutamiento en los enrutadores PE conectados a los enrutadores CE:
Para configurar enrutamiento estático en los routers CE se debe:
a. Configurar la interfaz que lo conecta al enrutador PE con una dirección IP. Esta
configuración depende del tipo de interfaz que se tenga (Ethernet, Frame Relay, etc.).
Por ejemplo para configurar una interfaz serial DS1: Router (config)# interface Serial slot/adaptador/puerto
Router (config-interface)# ip address dirección-ip mascara
b. Configurar la ruta por defecto que apunta hacia el router PE como es siguiente hop: Router (config)# ip route 0.0.0.0 0.0.0.0 [dirección-ip-PE |
interfaz-egreso-CE]
Configuración de Protocolos de enrutamiento Interior:
Para configurar enrutamiento RIPv2 en los enrutadores CE:
a. Habilitar la versión 2 de RIP: Router (config)# router rip
Router (config-router)# version 2
91
b. Asociar una red con el proceso de enrutamiento RIP para el modo de configuración
del router: Router (config-router)# network prefix
Para configurar enrutamiento OSPF en los enrutadores CE:
a. Habilitar OSPF: Router (config)# router ospf ospf-process-id
b. Definir la interface en que corre OSPF y la identificación del área para dicha
interface: Router (config)# network address wildcard-mask area area-id
Configuración de protocolos de enrutamiento exterior: en este caso el cliente debe tener un
número de sistema autónomo (AS).
Para configurar enrutamiento BGP4 en los enrutadores CE:
a. Configurar un proceso de enrutamiento IBGP con el número del sistema autónomo
pasado al enrutador PE: Router (config)# router bgp sistema-autónomo
b. Especificar las direcciones IP de los PEs vecinos: Router (config-router)# neighbor {dirección-ip | peer-group-name}
remote-as número
c. Especificar las redes o subredes que deben ser anunciadas a la sesión EBGP: Router (config-router)# network numero-red [mask mascara-red]
Estos pasos se explicarán más detalladamente sobre parte del caso de estudio mostrado en
la referencia [7], en el cual se tiene un proveedor de servicio con tres puntos de presencia
en las ciudades de Chicago, Seattle y San Diego, que va a proporcionar con servicios de
VPN a dos usuarios A y B, como se muestra en la figura 25.
El esquema de direccionamiento utilizado en el caso de estudio, se explica en la tabla 5.
92
Router PE Subred WAN CE Subred LAN CE
Usuario A
Chicago 10.10.1.1/32 172.16.254.0/30 172.16.10.0/24
Seattle No esta presente No esta presente No esta presente
San Diego 10.10.3.1/32 172.16.253.0/30 172.16.20.0/24
Usuario B
Chicago 10.10.1.1/32 172.17.254.0/30 172.17.10.0/24
Seattle 10.10.2.1/32 172.17.253.0/30 172.17.20.0/24
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
100
neighbor 10.10.1.1 activate neighbor 10.10.1.1 send-community extended neighbor 10.10.2.1 activate neighbor 10.10.2.1 send-community extended exit-address-family ! address-family ipv4 unicast vrf vrf1 neighbor 172.16.253.2 remote-as 65535 neighbor 172.16.253.2 activate no synchronization no auto-summary exit-address-family !
Configuración del Router CE del usuario A en San Diego: con sesiones de enrutamiento
BGP4:
! hostname San_Diego_CE1 ! interface ethernet0/0 ip address 172.16.20.254 255.255.255.0 ! interface ethernet0/1 ip address 172.16.253.2 255.255.255.252 ! router bgp 65535 neighbor 172.16.253.1 remote-as 64512 network 172.16.20.0 mask 255.255.255.0 ¡
8.2.3. Técnicas de QoS
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:
• Clasificar los usuarios según el acceso que tengan a los recursos de red
• Prioritizar las aplicaciones 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
101
• Administrar la totalidad del flujo de tráfico que transita por las redes internas y
externas de la compañía.
Con el fin de proporcionar estos servicios, las compañías de comunicaciones deben adaptar
su red para poder aplicar políticas al trafico entrante, de forma que les permita programar la
transmisión del tráfico por su red, según el tipo de servicio que éste requiera y a su vez,
poder controlar la congestión de forma tal que no se degraden las comunicaciones.
El ejemplo anterior muestra cómo configurar una VPN sobre una red MPLS de manera que
se provea con altos niveles de seguridad a las interconexiones de los usuarios. La
consecución de un servicio de calidad sobre dicha conexión segura, que cumpla con el nivel
de servicio pactado entre el proveedor de comunicaciones y el usuario, requiere de una
adecuada clasificación de los paquetes a la calidad de servicio apropiada (en especial una
clasificación según aplicación), y de asegurar que dichos niveles de servicio sean mapeados
correctamente en los comportamientos de las capas inferiores a la capa de red.
Adicionalmente, para los puntos de acceso a la red, se deben identificar los cuellos de
botella en ancho de banda, dar forma al tráfico según su clasificación, definir CIRs
(Committed Information Rate) por aplicación y crear políticas basadas en grupos de
usuarios y en horas del día. En el núcleo de la red del proveedor, se debe realizar un manejo
adecuado de la congestión que garantice el transporte de las aplicaciones con los niveles de
desempeño pactados en el SLA, basándose en una adecuada conversión entre la
clasificación de los paquetes transportada en las etiquetas MPLS y el PHB relacionado con
la etiqueta, para el caso de servicios diferenciados.
Un esquema a seguir para la aplicación de calidad de servicio en la red MPLS del
proveedor es el siguiente:
1. Monitorear el tráfico entrante para evitar congestión: de forma que al utilizar un
algoritmo de cubeta de goteo, se mantenga el flujo de tráfico hasta un máximo límite
inferior al ancho de banda del enlace. Los paquetes en exceso pueden ser descartados o
etiquetados en el bit de preferencia de descarte o en la cabeceras del paquete IP.
102
2. Clasificar el tráfico: basado en la clasificación transportada por los paquetes en el byte
ToS de la cabecera IPv4, o según la interfaz de entrada del tráfico, o según datos de las
cabeceras capa 3, 4 o 7 del paquete analizado, de acuerdo con lo especificado en el
SLA.
3. Configurar las colas de salida: para cada interface, asignándole a cada una el porcentaje
adecuado de memoria al que tiene acceso en el router. Esto delimita el tamaño de la
cola para cada clase.
4. Atender las colas de salida y transmitir el tráfico: Para ello se puede utilizar el esquema
WFQ, CBWFQ o WRR, que determina la cola de la que será transmitido el siguiente
paquete.
5. Monitorear la congestión en las colas de salida y descartar paquetes: en un esfuerzo por
evitar los picos de congestión. Para esto se utiliza el algoritmo RED que busca
anticipar situaciones de congestión y reaccionar antes de que éstas ocurran, descartando
un pequeño porcentaje de paquetes de manera preventiva.
Los aspectos relacionados con el control de acceso, el manejo de congestión y la
configuración de los equipos, dependen en gran medida de las capacidades de los equipos
por fabricante y no están estrechamente relacionados con la red MPLS en sí, aunque se
basan en la habilidad de los equipos de leer la clasificación de los paquetes transportada por
las etiquetas para mapearlas al tipo de servicio apropiado a ellas.
Por su parte, la clasificación y marcación de los paquetes es un aspecto que será
desarrollado con mas detalle en la siguiente sección, principalmente en cuanto se refiere a
la forma como se marcan los paquetes MPLS.
8.2.3.1. Clasificación y Marcación de Paquetes
Como se describió en el marco teórico, la clasificación de los paquetes es el paso más
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
103
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).
Dadas las diferentes posibilidades que se ofrecen en el mercado en cuanto a equipos que
implementan la clasificación de los paquetes, es necesario especificar dentro del acuerdo de
nivel de servicio, quien será el ente encargado de realizar la clasificación de los paquetes (el
usuario o el proveedor) y bajo cuales criterios se realizará dicha clasificación.
Un ejemplo de clasificación de tráfico, que desarrollan por defecto los equipos de
enrutamiento Passport 8600, para servicios diferenciados, se muestra en la tabla 6. Estos
valores pueden ser modificados por los administradores de red, para que estén conformes al
SLA.
DSCP Nivel de QoS Clase de Servicio
EF 6 Premium
AF11, AF12 y AF13 5 Platino
AF21, AF22 y AF23 4 Oro
AF31, AF32 y AF33 3 Plata
AF41, AF42, AF43 2 Bronce
DE (Discard Elegible) 1 Estándar
Tabla 6. Mapeo de DSCP de ingreso a nivel de QoS para enrutadores Passport 8600. Tomado de “Packet
Policing on the Passport 8600”, Technical Information Bulletin, Nortel Networks.
Una vez clasificado el tráfico, se procede a realizar la marcación del mismo, usando en
primera instancia los tres bits de Precedencia IP o los 6 bits del byte DSCP del modelo de
Servicios Diferenciados. Como será necesario en el borde de la red copiar dicha
clasificación en los bits EXP de la etiqueta MPLS (E-LSP) o dentro de una nueva etiqueta
(L-LSP), se debe tener en cuenta que sólo los tres bits más significativos del código DSCP
serán los que señalen la clasificación del paquete para el primer caso.
Por ejemplo en equipos Cisco [7], al establecer en la red del proveedor del servicio, el
campo EXP y la política de servicio para una VPN del cliente A, se define:
PE(config)# policy-map VPN_A_policy PE(config-pmap)# class VPN_A
104
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
Donde se garantiza un mínimo ancho de banda de 256 Kbps a todo el tráfico de la VPN
bajo una eventual congestión; se define una cola de máximo 60 paquetes para esta clase,
antes de iniciar a descartar los paquetes siguientes (tail drop) y se asigna el valor 4 al
campo MPLS EXP para los paquetes que estén conformes a los requerimientos de la clase
de tráfico asociada con la política de dicha VPN.
Adicionalmente se configuran los valores por defecto para ésta política, que incluye 20
colas hash para el tráfico que no cumple con los requerimientos de la clase VPN_A y un
máximo de 40 paquetes por cola antes de descartar los paquetes siguientes. En la sección
8.5 se explica más detalladamente los pasos de configuración en los equipos enrutadores.
En los routers del núcleo se configura el PHB relacionado con los bits EXP de la etiqueta
MPLS [7]. En primer lugar se configuran las características de las clases de servicio y
después la política de servicio adecuada a cada clase.
P(config)# class-map class2 P(config-cmap)# match mpls experimental 4 P(config-cmap)# end
P(config)# policy-map class_PHB_policy P(config-pmap)# class class2 P(config-pmap-c)# bandwidth 256 P(config-pmap-c)# queue-limit 60 P(config-pmap-c)# exit
Donde se ha definido que la clase 2 corresponde al valor MPLS EXP 4 y que garantiza un
ancho de banda mínimo de 256 Kbps a todo el tráfico de la clase 2, además de reservar una
cola de hasta 60 paquetes antes de descartar los siguientes (tail drop).
105
Una vez definido el mapeo, la tabla es consultada 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.
El estándar 3270 define algunos mapeos entre PHB y valores EXP para tráfico de servicios
diferenciados EF (Expedite Forwarding) y AF (Assured Forwarding) [11]. Por ejemplo, si
la etiqueta entrante corresponde a un L-LSP que soporta el AF1 PSC25, el mapeo Encaps à
PHB será:
Campo EXP à PHB
001 à AF11
010 à AF12
011 à AF13
Pero es necesario anotar que dichos mapeos están sujetos a la configuración que cada
administrador de red realice en sus equipos.
8.2.3.2. Regulación de tráfico y Administración de Congestión
Para asegurar que un flujo de tráfico permanezca conforme al ancho de banda asignado y a
los criterios de servicio definidos para su nivel de QoS, es necesario desarrollar técnicas de
policing dentro de la red. Las políticas se definen por filtros asignados a flujos de tráfico
específicos; por ejemplo, se puede decidir limitar la tasa de tráfico de un departamento,
para proporcionar al tráfico de misión crítica con un acceso ilimitado a los recursos de red.
Las políticas contienen información que identifican el perfil del tráfico, la tasa promedio de
transmisión, la marca E-LSP o L-LSP para tráfico conforme al perfil, el comportamiento
que se debe aplicar al tráfico que excede el perfil especificado, la forma como se remarcan
los paquetes fuera de perfil y el nivel de descarte.
Una vez accede el tráfico a la red, las marcas E-LSP o L-LSP son examinadas y los
paquetes son conducidos a la cola apropiada según el mapeo definido entre su marca y el
25 PSC = PHB Scheduling Class
106
nivel de QoS. En la tabla 7 se muestra un ejemplo del nivel de servicio definido para cada
una de las clases de servicio de la tabla 6.
Clase de Servicio
Nivel de QoS
Oportunidad de transmitir paquetes *
Peso en porcentaje **
Premium 6 32 100%
Platino 5 10 31%
Oro 4 8 25%
Plata 3 6 19%
Bronce 2 4 13%
Estándar 1 2 6% * Determina que cola es servida primero ** Configura la oportunidad de transmitir paquetes para cada cola
Tabla 7. QoS asignada a las clases de servicio por defecto en los enrutadores Passport 8600. Tomado de
“Packet Policing on the Passport 8600”, Technical Information Bulletin, Nortel Networks.
El tráfico ubicado en cada cola, es servido por el mecanismo de programación configurado
en el router (WRR, WFQ, PQ, etc.). En general, estos mecanismos aseguran prioridad
estricta para el tráfico EF PHB y sirven las demás colas según el esquema de
administración de congestión configurado.
Los algoritmos de scheduling definen prioridades, anchos de banda, tamaños de buffers y
perfiles de descarte a ser aplicados a cada clase de tráfico en particular.
El nivel de prioridad determina el orden de transmisión del tráfico en cada clase, asociados
con una interfaz de salida. Las clases con alta prioridad transmiten paquetes antes que las
clases con baja prioridad y tienen acceso a una mayor proporción de ancho de banda, según
se halla programado en las tasas de control de transmisión. El ancho de banda de
transmisión se puede configurar en un valor exacto para cada clase, o puede permitirse
excesos al valor configurado, si otras clases no están utilizando todo el ancho de banda
asignado a ellas.
La probabilidad de descarte, asociada con el tamaño de la cola en el buffer, es un parámetro
utilizado por el algoritmo de abolición de congestión RED, que busca anticipar posibles
estados de congestión y permite controlar la cantidad de tráfico que un usuario está
107
enviando, de forma que se incrementa la probabilidad de descarte para el tráfico que excede
el nivel contratado.
Es recomendable implementar los algoritmos de programación de colas en los puntos de
acceso a la red MPLS, puesto que allí la concentración del tráfico genera cuellos de botella
que se pueden evitar con un manejo adecuado de colas. De otro lado, en el núcleo de la red
MPLS, es necesario implementar no solo los algoritmos de scheduling, sino también los
esquemas de abolición de congestión como RED, de forma que se pueda controlar en
mayor medida la cantidad de tráfico en la red y brindar un servicio más confiable y
eficiente a los usuarios.
Los fabricantes de enrutadores ofrecen con sus equipos una combinación de disciplinas de
colas que pretenden soportar adecuadamente diferentes clases de servicio durante periodos
de congestión, buscando el mejor desempeño, la mayor exactitud, versatilidad y
simplicidad en los algoritmos que implementan.
Por ejemplo, Allot Comunications ofrece en sus equipos NetEnforcer una combinación de
colas basadas en clases (CBQ) y Colas por flujos, para soportar diferentes clases de
servicio, pero a su vez asignar una cola por flujo en cada clase de servicio, de forma que
dentro de una misma clase se ofrezca igualdad de servicio para todos los flujos.
Cada fabricante permite en mayor o menor medida programar los parámetros de los
diferentes mecanismos de calidad de servicio, dando mayor versatilidad a las características
de sus enrutadores o mayor simplicidad para los proveedores que no se encuentran
familiarizados con los diferentes mecanismos. En este último caso, los fabricantes
usualmente configuran sus equipos con valores predeterminados que deben ser analizados
por los proveedores de servicios, para comprobar que cubran los requisitos definidos en los
SLAs. En la sección 8.5 se mostrará un ejemplo de configuración de RED para equipos
Cisco y en la página www.juniper.net/techpubs/software/junos/junos57/swconfig57-
interfaces/html/cos-config14.html se puede encontrar un ejemplo de configuración de
clases de servicio para equipos Juniper.
108
Se recomienda a los proveedores de servicios de comunicación verificar si los equipos en el
núcleo de su red son capaces de soportar esquemas de manejo activo de colas como
WRED, para implementar la abolición de congestión y en caso positivo, configurarlos
adecuadamente al nivel y tipo de tráfico que transportan.
Finalmente, 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:
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.
109
8.3 Requisitos para el Usuario
Como se vio en el ejemplo de implementación de MPLS VPNs, sección 8.2.2, no se
requiere que los routers de borde del usuario (CE: Customer edge routers) soporten MPLS,
sino que pueden usar cualquiera de los métodos convencionales de enrutamiento para lograr
la conectividad con los enrutadores de borde de la red del proveedor (PE: Provider edge
routers). Lo que si es importante es definir junto con el proveedor de servicios, quien se
encargará del proceso de clasificación de paquetes. Puesto que, como se vio anteriormente,
es el usuario el ente conocedor del tipo de paquetes que maneja y quien está interesado en
obtener un servicio diferenciado para su tráfico.
Existen diferentes formas que se pueden emplear en la clasificación de los paquetes. Los
usuarios deben ponerse de acuerdo con los proveedores en el tipo de método que se
empleará (por ejemplo bits ToS o códigos DSCP), de que manera deben manejar los
proveedores dicha clasificación y si les es permitido alterarla, es decir, si el proveedor
puede cambiar los bits de clasificación al manejar los paquetes dentro de su red. En caso de
no poder alterar la clasificación almacenada en los paquetes, el proveedor debe al ingreso
de la red, implementar el proceso de marcación del paquete en la etiqueta MPLS teniendo
como base la clasificación actual del paquete – si fue acordado - y los resultados de los
algoritmos de control de admisión y administración de congestión que tenga
implementados en el borde de red. De esta forma, manejara internamente la clasificación
del paquete en el valor de la etiqueta MPLS y dejara intacto el valor de la clasificación
transportada por el paquete, una vez retire la etiqueta a la salida de la red.
Adicionalmente es necesario definir dentro del acuerdo de nivel de servicio el tipo de
modelo que se usará para la implementación de QoS en la MPLS VPN: modelo Peer,
modelo Hose o una combinación de los dos. Dicha definición depende de los requisitos del
tráfico usuario como se especificó en el marco teórico.
110
8.4 Aspectos Adicionales
8.4.1. Implementación de Extranets y Acceso a
Internet
Para la creación de Extranets entre dos usuarios de MPLS VPNs, es necesario definir
nuevas VRFs por usuario de VPN. Es decir, hacer que usuarios específicos de cada VPN,
entre los que se va a implementar la Extranet, pertenezcan a dos VPNs distintas: la VPN
corporativa que lo conecta con sus sucursales y la Extranet VPN que lo conecta con otra
compañía. Para soportar estos requerimientos, la arquitectura MPLS VPN añade el
concepto de sitios (sites), donde una VPN esta conformada por uno o múltiples sitios. Una
VPN es esencialmente una colección de sitios que comparten información de enrutamiento
en común, lo que significa que un sitio puede pertenecer a más de una VPN si mantiene
rutas de VPNs separadas.
La relación entre VPNs, sitios y VRFs se resume en la siguiente regla, que debe ser usada
como base para cualquier definición de VRFs en una red MPLS VPN:
“Todos los sitios que comparten la misma información de enrutamiento (usualmente esto
significa que pertenecen al mismo conjunto de VPNs), que pueden comunicarse
directamente entre sí y que están conectados al mismo router PE, pueden ser ubicados
dentro de una VRF común” [4].
La creación de Extranets entre usuarios de MPLS VPNs, se logra a través de la definición
de comunidades extendidas entre las dos VPNs. Para ello es necesario definir comunidades
objetivo VPNs (route target) dentro de las tablas de enrutamiento VRF, en las que se
controle la distribución de la información de enrutamiento VPN (se implementa con
comunidades extendidas BGP). En el ejemplo de la figura 25, es posible crear una Extranet
entre los usuarios A y B al configurar en el enrutador PE de Chicago una route target de
importación adicional, dentro de la definición de la vrf2, dirigida a la vrf1:
Route-target import 100:1
111
De esta misma forma se puede conseguir el acceso a Internet para usuarios de VPNs, dentro
de la arquitectura MPLS. La mayor limitación que se tiene al permitir acceso a Internet
sobre un backbone MPLS está relacionada con la propagación de todas las rutas de Internet.
La propagación de todas las rutas debe ser evitada a cualquier costo, porque esto
sobrecargaría las tablas de enrutamiento MPLS VRF, incrementaría el uso de la CPU y
coparía la memoria del LSR. La regla de diseño es propagar las rutas por defecto mientras
sea posible. [7]
Una de las formas en las que se puede conseguir conectividad a Internet es a través del uso
de rutas estáticas. Para ello se aprovecha el hecho que los enrutadores PE almacenan las
rutas globales (diferentes a las de las VPNs) en la tabla de enrutamiento global. Si el
proveedor de servicios requiere proveer conectividad a Internet sobre el backbone MPLS a
los usuarios de las VPNS, puede usar las rutas por defecto para apuntar a una compuerta
externa conectada a un router PE central; es decir, que la ruta por defecto introducida en la
tabla VRF apuntará a una dirección del siguiente hop que está contenida en la tabla de
enrutamiento global. Los paquetes dirigidos a Internet saldrán de la VPN y se dirigirán a
un siguiente hop que se encuentra dentro del espacio de direccionamiento global. Para
habilitar la conectividad desde Internet hacia la VPN, se deben publicar hacia Internet las
subredes IP de la VPN usuaria que son usadas como funete de direcciones para Internet;
para ello, se configura una ruta estática global que permita a la subred de la VPN aparecer
en la tabla de enrutamiento global y en la VRF, de forma que la dirección del siguiente hop
para dicha ruta estática no se encuentra en la tabla de enrutamiento global, sino en la VRF.
En el ejemplo de la figura 26 [7], la VPN1 esta presente en tres sitios distintos con
conectividad Intranet completa entre los routers CE1, CE2 y CE3. En este ejemplo se han
configurado rutas por defecto estáticas dentro de las tablas VPN1 VRF en los enrutadores
PE2 y PE3, que apuntan a una compuerta de Internet conectada a PE1. La dirección IP del
gateway de Internet (64.1.1.2) debe ser publicada dentro del backbone IGP de forma que
este presente en la tabla de enrutamiento global.
112
Figura 26. Conectividad a Internet usando una ruta estática por defecto. [7]
8.5 QoS en redes MPLS con VPNs
Una vez redactado el SLA entre el proveedor y el cliente, se debe proceder con la
configuración del mismo. Los siguientes pasos definen como se configura QoS para MPLS
VPNs en los routers PE [7]:
1. Configurar las clases de tráfico, clasificando los paquetes IP de acuerdo con
criterios definidos para cada clase
2. Configurar las políticas de servicio asociadas a cada clase de tráfico.
3. Configurar la interfaz de entrada para adicionarle las políticas de servicio.
Paso 1. Configuración de las clases de Tráfico:
En los enrutadores Cisco, el comando class-map es usado para crear clases de tráfico,
especificando el nombre de la clase y los parámetros de clasificación:
class-map [match-any | match-all] nombre-clase no class-map [match-any | match-all] nombre-clase
ISP peer
AS 32771 .2
150.100.1.0 VPN1
.2
64.1.1.0 10.1.1.0 .1
CE1
.1
VPN1 VPN1
CE2 CE3
PE1
PE2 PE3
10.10.1.1
10.10.2.1 10.10.3.1
MPLS VPN backbone AS 25431
113
El comando match-all especifica que se deben cumplir todos los criterios de clasificación
para que un paquete pertenezca a una clase específica; mientras que el comando match-any
sugiere que si al menos un criterio se cumple, el paquete pertenece a la clase especificada.
El comando match-not se usa para especificar un criterio que previene a un paquete de ser
clasificado como miembro de la clase.
Los criterios de clasificación incluyen:
- match access-group grupo-acceso: El criterio de clasificación se basa en un
número ACL (lista de control de acceso) específico
- match any: El criterio de selección es exitoso para todos los paquetes.
- match class-map nombre-class-map: Depende de políticas de clasificación.
- match cos valor-cos [valor-cos valor-cos valor-cos]: según la marcación de CoS
capa 2
- match destination-address mac dirección: según la dirección MAC destino
- match input-interface nombre-interface: según la interfaz de entrada especificada.
- match ip dscp valor-dscp [valor-dscp valor-dscp valor-dscp valor-dscp valor-dscp
valor-dscp valor-dscp]: Según el valor DSCP especificado, siendo posible
configurar hasta ocho valores DSCP en un solo comando
- match ip precedente valor-precedencia [valor-precedencia valor-precedencia
valor-precedencia]: Según el valor de precedencia IP, siendo posible configurar
hasta cuatro valores de precedencia en un solo comando.
- match ip rtp numero-puerto-inicial rango-puertos: el criterio de selección se basa
en el puerto RTP o Real-Time Protocol, donde el valor del puerto inicial esta entre
2000 y 65535 y el rango de puertos fluctúa entre 0 y 16383.
- match mpls experimental numero: Se basa en el valor del campo EXP de MPLS.
114
- match not: configura un criterio no exitoso.
- match protocol protocolo: la clasificación se basa en el protocolo especificado
- match qos-group valor-grupo-qos: se basa en valores de grupo de QoS, que varía
entre 0 y 99, es local al enrutador y es usado como un marcador. El tratamiento de
estos paquetes es definido por el administrador a través de la especificación de
políticas de QoS en el modo de configuración policy map class.
- match source-address mac dirección: Se basa en la dirección MAC fuente.
Por ejemplo, para configurar un mapa de clase en el que todos los paquetes que contengan
un nivel de precedencia IP de 5 pertenezcan a la clase crítica, se utiliza:
Router(config)# class-map crítica Router(config-cmap)# match ip precedence 5 Router(config-cmap)# end
Paso 2. Configuración de la política de servicio
Se utiliza el comando policy-map para especificar una política de servicio y el comando
class para asociar una clase de tráfico a una política de servicio.
Si se configura una clase por defecto, todo el tráfico que no cumpla con los criterios de
selección de las clases, pertenece a dicha clase por defecto. Para ello se crea un mapa de
políticas asignado a una o más interfaces que especifica una política de servicio; dentro del
policy-map se especifica el nombre de una class-map previamente diseñado y finalmente se
especifica la clase por defecto a ser creada como parte de la política de servicio.
Router(config)# policy-map nombre-policy-map Router(config-pmap)# class nombre-class-map Router(config-pmap)# class class-default
Entre las opciones de configuración de policy-map-class, se tienen:
- Especificar un ancho de banda mínimo garantizado a una clase de tráfico (en Kbps o
en porcentaje del ancho de banda total disponible:
115
Router(config-pmap-c)# bandwidth {bandwidth-kbps | percent
porcentaje}
- Seleccionar un comando como el valor por defecto:
Router(config-pmap-c)# default comando
- Especificar el número de colas a ser reservadas para la clase:
Router(config-pmap-c)# fair queue número-colas
- Especificar el máximo ancho de banda permitido para una clase de tráfico por
medio del uso de un algoritmo de cubeta de tokens:
Router(config-pmap-c)# police bps burst-normal burst-max conform-
action action exceed-action action violate-action action
Donde las acciones que se pueden tomar sobre los paquetes entrantes son:
• drop: descarta el paquete
• set-prec-transmit nueva-prec: asigna una precedencia IP y transmite el paquete
• set-qos-transmit nueva-qos: asigna un grupo de QoS y transmite el paquete
• set-dscp-transmit nuevo-dscp: asigna un valor DSCP y transmite el paquete
• set-atm-clp: cambia el bit CLP de ATM de 0 a 1 y transmite el paquete
• transmit: transmite el paquete
- Especificar el ancho de banda garantizado (en Kbps o porcentaje) para tráfico de
prioridad. Es posible indicar el tamaño en bytes del burst permitido a este tráfico
sin considerarlo como tráfico en exceso:
Router(config-pmap-c)# priority {kbps | percent porcentaje} [bytes]
- 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
durante la asignación de la etiqueta:
Router(config)# interface nombre-interface Router(config-int)# rate-limit input [access-group [rate-limit] acl-index] bps burst-normal burst-max conform-action set-mpls-exp-transmit exp exceed-action set-mpls-exp-transmit exp Router(config-int)# end
118
Por ejemplo, para asignar un 4 a un paquete de salida MPLS cuando los paquetes IP de
entrada están conformes a la lista de acceso y a la tasa de acceso, o un 0 si los paquetes
están conformes a la lista de acceso 25, pero exceden la tasa de entrada, se usa:
Router(config)# interface ethernet 1/0/0 Router(config-int)# rate-limit input access-group rate-limit 25
64000 64000 64000 conform-action set-mpls-exp-transmit 4 exceed-action set-mpls-exp-transmit 0
Router(config-int)# end
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
Configuración de PE1
PE1(config)# interface Ethernet4/0/0 PE1(config-int)# service-policy input VPN_A_policy PE1(config-int)# exit PE1(config)# interface Serial5/0/0 PE1(config-int)# service-policy input VPN_B_policy PE1(config-int)# end
Configuración de PE2
PE2(config)# interface Ethernet4/0/0 PE2(config-int)# service-policy input VPN_B_policy PE2(config-int)# end
Configuración de PE3
PE3(config)# interface Ethernet4/0/0 PE3(config-int)# service-policy input VPN_A_policy PE3(config-cmap)# end
Configuración de P1
P1(config)# interface Serial2/0/0 P1(config-int)# service-policy input class_PHB_policy P1(config-int)# exit P1(config)# interface Serial2/0/1 P1(config-int)# service-policy input class_PHB_policy P1(config-int)# end
Configuración de P2
P2(config)# interface Serial2/0/0 P2(config-int)# service-policy input class_PHB_policy P2(config-int)# exit P2(config)# interface Serial2/0/1 P2(config-int)# service-policy input class_PHB_policy P2(config-int)# exit P2(config)# interface Serial3/0/0 P2(config-int)# service-policy input class_PHB_policy P2(config-int)# end
125
Con estos tres pasos, quedaría configurada una MPLS VPN con dos clases de servicio
diferentes para las dos VPNs usuarias A y B.
126
9. Conclusiones
La época actual, conocida como la “Era de la Información”, sugiere la importancia que
tiene para el desarrollo de negocios, la capacidad de contar con gran cantidad de
información fiable, en muy cortos plazos. Cada vez en mayor número, las organizaciones
están enfocando su modelo operacional hacia la capacidad de tener una fuerte conexión en
red, siendo éste un aspecto crítico para la existencia de la empresa. Pero no solo requieren
la capacidad de conexión, sino también la calidad de la misma, puesto que demoras en el
servicio o detrimento en la calidad de la información, equivale a pérdidas de clientes, de
negocios y hasta la posibilidad de ser expulsados del mercado.
Muchas de las redes actuales tienen capacidades para ofrecer dichos servicios pero a altos
costos y con grandes dificultades de escalamiento. Al implementar la tecnología
MultiProtocol Label Switching (MPLS) en la red IP de un proveedor de servicios, se
solucionan por un lado, problemas de escalabilidad, facilidad de aprovisionamiento y
simplicidad en el enrutamiento a que se enfrentan las redes tipo ATM y Frame Relay, y por
otro, de velocidad, calidad de servicio, seguridad, administración e ingeniería de tráfico,
que presentan las redes de enrutadores IP, puesto que se proporciona con un mecanismo
para un enrutamiento eficiente, de alto nivel de seguridad y con la capacidad de reservar
recursos o de proporcionar diferentes niveles de servicio. Adicionalmente MPLS es una
tecnología que puede transportar múltiples protocolos (ATM, Frame Relay, PPP, etc.), de
manera que la migración de la red se convierte en un proceso sencillo de realizar.
Durante la definición de la guía metodológica de calidad de servicio sobre redes MPLS con
VPNs, se encontró que la tecnología MPLS no define explícitamente una arquitectura de
QoS, sino que se basa en los modelos desarrollados por la IETF de servicios diferenciados
y servicios integrados. Esto hace que la implementación de servicios con diferentes niveles
127
de calidad dentro de las redes MPLS se convierta en una tarea más sencilla en cuanto a la
variedad de opciones que se encuentran en el mercado para los distintos requisitos que
exigen los servicios diferenciados e integrados, dados los numerosos estudios e
investigaciones desarrolladas desde hace varios años en dichos campos.
MPLS se convierte entonces en una tecnología facilitadora para la implementación de
calidad de servicio, que utiliza las ventajas que ofrecen las redes IP en cuanto a la facilidad
de enrutamiento, junto con las ventajas que ofrecen las tecnologías de capa 2 respecto a
seguridad, velocidad de transmisión y posibilidad de diferenciar entre los diferentes tipos
de tráficos que transitan la red, ofreciendo distintas clases de servicio.
El proporcionar al tráfico de red con capacidades de calidad de servicio dentro de las redes
privadas virtuales, es un requerimiento esencial para las aplicaciones de tiempo real y de
misión crítica. Con este propósito, las redes actuales deben actualizarse a nuevas
tecnologías como MPLS, que simplifican las interconexiones, disminuyen costos y las
habilitan para ofrecer dichos servicios y controlar su comportamiento según las
necesidades. Adicionalmente, una de las grandes ventajas de MPLS es su habilidad para
mantener las características específicas de desempeño a lo largo de cualquier medio de
transporte, eliminando la necesidad de utilizar redes superiores o múltiples mecanismos de
control.
El trabajo desarrollado muestra la importancia que tiene un buen proceso de clasificación
de paquetes en la consecución de distintos niveles de calidad de servicios. Es por ello que
continuamente se están haciendo mejoras a los equipos de forma que puedan reconocer con
mayor exactitud el tipo de aplicaciones que la red transporta, sin incrementar el retardo
aplicado a los paquetes. Pero no solo es importante la clasificación de los paquetes, también
se debe hacer énfasis en la implementación de esquemas y algoritmos que refuercen las
políticas establecidas en los acuerdos de nivel de servicio, diferenciando entre los distintos
tráficos que llegan al borde de red, evitando congestiones tanto en el borde como en el
núcleo de red y disminuyendo la creación de cuellos de botella que afectan la velocidad de
transporte de los paquetes.
128
Los proveedores de servicio deben tener presente que cada fabricante implementa de
manera distinta los algoritmos de manejo de colas y de abolición de congestión en sus
equipos; es por tanto necesario realizar un estudio de las capacidades de cada equipo, de
forma que se conozca la manera de personalizar sus funciones y se este seguro que ellas
cubren con los requerimientos de los servicios contratados.
Es necesario desarrollar un fuerte trabajo dentro de la red del proveedor y en la relación
proveedor – cliente, respecto a la definición de los acuerdos de nivel de servicio, de forma
que se asegure la capacidad de la red de comunicaciones en el proceso de dar cumplimiento
a lo pactado en el SLA y se conozca adecuadamente el tipo de tráfico que el usuario maneja
y su conocimiento acerca de la mejor manera de clasificarlo, con el fin de poder ofrecerle
un mejor servicio. Igualmente se debe profundizar en la definición del SLM (Service Level
Management), útil al proveedor para asegurar el cumplimiento de los SLAs contratados.
Al mercado están llegando continuamente equipos de diferentes fabricantes que soportan y
mejoran los servicios básicos posibles en redes MPLS. Esto conllevara a que en los
próximos años exista mayor reglamentación acerca de las capacidades del protocolo y por
ende, mayor interoperabilidad entre fabricantes.
En conclusión, las tendencias actuales están obligando a las empresas a girar hacia un
modelo de servicio al cliente en el cual se le ofrezcan distintos tipos de servicio acordes a
sus necesidades, a su liquidez y a su continua evolución; ello obliga a los proveedores de
servicios de comunicación a evaluar su red y realizar cambios en ella de forma que soporte
múltiples tipos de tráfico, con altos niveles de seguridad y con la versatilidad necesaria para
realizar continuos cambios en las conexiones, en cortos plazos y a bajos costos. Todo esto
es accesible al implementar una plataforma MPLS y sobre ella desarrollar las características
de Calidad de Servicio, Ingeniería de Tráfico y VPNs.
No fue posible incluir dentro de esta investigación temas como la implementación de
técnicas de Ingeniería de Tráfico dentro de la red del proveedor, o la definición de los
requisitos necesarios para la implementación de calidad de servicio cuando existe
interconexión entre múltiples proveedores. Tampoco se pudo profundizar en los
procedimientos para la interconexión de redes Extranet o para la salida a Internet.
129
Adicionalmente, aunque se realizó una definición de lo que significa y debe contener los
acuerdos de calidad de servicio que se establecen entre usuarios y proveedores, es
recomendable desarrollar una guía detallada de éstos aspectos en futuros trabajos, que
complementen la información consignada en la presente tesis de grado.
130
10. Anexo 1. Preguntas formuladas a Clientes
y Empresas Proveedoras de Servicios de
Comunicación
1. ¿Que tecnología es la más empleada dentro del backbone de las empresas de
comunicaciones? ATM, Frame Relay, SDH, Routers (IP)
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
DSCP. Differentiated Services Code Point
DTS. Distributed Traffic Shaping
DWRR. Deficit Weighted Round Robin
EBGP. Enhanced Border Gateway Protocol
ECN. Explicit Congestion Notification
ECR. Egress Committed Rate
EF-PHB. Expedited Forwarding PHB
EIGRP. Enhanced Interior Gateway Routing Protocol
E-LSP. Experimental LSP
Exp. Experimental: Campo en la cabecera MPLS
FEC. Forwarding Equivalence Class
FECN/BECN. Forward / Backward Explicit Congestion Notification
FIFO. First In Fist Out
FQ. Fair Queuing
FRR. Fast Re-Routing
FRTS. Frame Relay Traffic Shaping
FTP. File Transfer Protocol
GTS. Generic Traffic Shaping
IAB. Internet Architecture Board
ICR. Ingress Committed Rate
IETF. Internet Engineering Task Force
IGP. Interior Gateway Protocol
IntServ. Integrated Services
139
IP. Internet Protocol
IS-IS. Inter System - Inter System
L2F. Layer 2 Forwarding
L2TP. Layer 2 Transport Protocol
LAN. Local Area Network
LDP. Label Distribution Protocol
LFI. Link Fragmentation and Interleaving
LFIB. Label Forwarding Information Base o Label Forwarding Table
LIB. Label Information Base
LLQ. Low Latency Queuing
L-LSP. Label LSP
LMI. Local Management Interface
LSP. Label Switched Path
LSR. Label Switch Router
MP-BGP. Multiprotocol BGP
MP-IBGP. MultiProtocol Internal-BGP
MPLS. MultiProtocol Label Switching
MTBF. Mean Time Between Failure
MTTR. Mean Time To Recovery
OSPF. Open Shortest Path First
PBR. Policy-Based Routing
PE. Provider Edge Router
PHB. Per-Hop Behavior
PIR. Peek Information Rate
140
PQ. Priority Queuing
PVC. Permanent Virtual Circuit
QoS. Quality of Service
RED. Random Early Detection
RIPv2. Routing Information Protocol Version 2
RSVP. Resource Reservation Protocol
RSVP-TE. Resource Reservation Protocol con extensiones de Ingeniería de Tráfico
RTP. Real-time Transport Protocol
SLA. Service Level Agreement
SVC. Switched Virtual Circuit
ToS. Type of Service: Campo en la cabecera del datagrama IP
TS. Technical Specifications
TTL. Time To Live: Campo en la cabecera MPLS
UNI. User to Network Interface
VPDNs. Virtual Private Dialup Networks
VPN. Virtual Private Network
VRF. VPN Routing and Forwarding instance
WAN. Wide Area Network
WFQ. Weighted Fair Queuing
WRED. Weighted Random Early Detection
WRR. Weighted Round Robin
141
15. Bibliografía y Fuentes de Información
[1] Integral Access, Inc., “MPLS Next Generation Access”, Octubre del 2000
[2] IETF RFC 3031, E. Rosen, A. Viswanathan, R. Callon, “Multiprotocol Label Switching
Architecture”, Enero del 2001
[3] Cisco systems Inc., “Cisco IOS Software and Multiprotocol Label Switching”,
Septiembre del 2000.
[4] Ivan Pepelnjak, Jim Guichard, “MPLS and VPN Architectures. A Practical guide to
understanding, designing and deploying MPLS and MPLS-enabled VPNs”, 2001.
[5] Cisco Systems, Inc., “Cisco IOS Quality of Service Solutions Configuration Guide”,
2001.
[6] The MPLS Resource Center, “MPLS FAQ”, http://www.mplsrc.com/faq2.shtml
[7] Vivek Alwayn, “Advanced MPLS Design and Implementation”, Cisco Press, 2001.
[8] Tamrat Bayle, Reiji Aibara, Kouiji Nishimura, “Performance Measurements of MPLS
Traffic Engineering and QoS”, 2001
[9] S. Bradner, “The Internet Standards Process -- Revision 3”, RFC 2026, 1996.
[10] Internet Architecture Board, “Internet Official Protocol Standards”, RFC 2200, 1997.
[11] IETF RFC 3270, L. Wu, B. Davie, S. Davari, P. Vaananen, R. Krishnan, P. Cheval, J.
Heinanen, “Multi-Protocol Label Switching (MPLS) Support of Differentiated Services”,
Mayo del 2002.
142
[12] Mario Zamorano, Patricio Millan, “Control de Congestión y Enrutamiento en Redes
ATM”, Revista Facultad de Ingeniería, U.T.A. Chile, Vol. 6, 1999.
[13] Raju Rajan, “A Policy Framework for Integrated and Differentiated Service in the
Internet”, AT&T Labs
[14] Raj Jain, “Congestion Control and Traffic Management in ATM Networks: Recent
Advances and a Survey”, Department of Computer and Information Science, The Ohio
State University, 1996.
[15] Chuck Semeria, “Supporting Differentiated Service Classes: Queue Scheduling
Disciplines”, Juniper Networks, 2001.
[16] Chuck Semeria, “Internet Processor II ASIC: Rate-limiting and Traffic-policing
Features”, Juniper Networks, 2000.
[17] Cisco systems Inc., “Comparing Traffic Policing and Traffic Shaping for Bandwidth
Limiting”, Noviembre del 2002.
[18] Chuck Semeria, “Supporting Differentiated Service Classes: Active Queue Memory
Management” , Juniper Networks, 2002.
[19] Kostas Pentikousis, “Active Queue Management”, ACM Crossroads Student
Magazine, Octubre del 2001.
[20] Maria Victoria Martín Senén, “Calidad de Servicio en Redes de Datos. Análisis y
Estudio de las distintas alternativas.” Abril del 2001, http://qos.iespana.es/qos/.
[21] Nortel Networks, “Passport 7400, 15000. Multiprotocol Label Switching Guide”
