Ingeniería de Tráfico en Redes MPLS

Ingeniería de Tráfico en
Redes MPLS
Proyecto Final de Carrera
Integrantes: Adrián Delfino, Sebastián Rivero, Marcelo San Martín
Tutor: Ing. Pablo Belzarena
Instituto de Ingeniería Eléctrica
Facultad de Ingeniería de la República
Prefacio
El presente documento constituye la documentación final del Proyecto de Fin de
Carrera titulado “Ingeniería de Tráfico en Redes MPLS”, realizado para el Instituto de
Ingeniería Eléctrica de la Facultad de Ingeniería, Universidad de la República. Los
integrantes del grupo de trabajo son Sebastián Rivero, Adrián Delfino y Marcelo San
Martín. Todos ellos, estudiantes de Ingeniería, opción Telecomunicaciones.
El proyecto en cuestión se llevo a cabo en el período comprendido entre Marzo de
2004 y Agosto de 2005, bajo la tutoría del Ing. Pablo Belzarena.
El objetivo del proyecto fue desarrollar una herramienta de software que permite
al usuario realizar lo siguiente: diseñar la topología de la red a su gusto por medio de una
interfaz gráfica, tanto de manera manual o cargándola de manera automática a la misma,
disponer de diversos algoritmos para el establecimiento de LSPs (Label Switched Paths)
(objetivo principal de éste proyecto) así como de herramientas de visualización del estado
actual de la red. En cuanto a los métodos de búsqueda de caminos, se utilizó el
establecimiento explícito del LSP por parte del usuario, CSPF (Constraint Shortest Path
First), una versión modificada del algoritmo MIRA (Minumum Interference Routing
Algorithm) y algoritmos usados en las llamadas Fair Networks que se explicarán más
adelante.
El trabajo se divide en 4 partes. Primero se presenta el Objetivo del proyecto, la
Motivación que llevo a su creación y una breve descripción de cómo está organizado el
mismo. Luego se presentan los conceptos principales sobre TE (Traffic Engineering) de
manera que el lector este familiarizado con los conceptos básicos en los que se basa éste
proyecto. A continuación pasamos a una segunda parte donde exponemos las principales
herramientas teóricas que tuvieron que ser estudiadas durante todo el desarrollo del
proyecto para poder alcanzar los objetivos marcados. En la tercer parte se comenta de
manera profunda los diferentes packages que conforman el software NET-TE
(Networking Traffic Engineering), explicando con detenimiento como fueron
implementados. Finalmente, en una última y cuarta parte se realizan las conclusiones del
proyecto y plantean los posibles casos a futuro.
Con la presente documentación se adjunta un disco compacto conteniendo:
•
El archivo instalador del software NET-TE.
•
Un Manual del Usuario.
•
Documentación completa del Proyecto.
•
Documentación del código de software (JavaDoc).
Agradecimientos:
•
A nuestro tutor, Pablo Belzarena
2
•
A Paola Bermolen, por su amable ayuda en la compresión de los
algoritmos de Fair Networks.
•
Al grupo de proyecto del EasySim (Mauricio García, Gastón Madruga y
Víctor Paladino) por brindarnos su proyecto como base para la interfaz
gráfica del nuestro.
3
Índice General
I Presentación del Problema
1. Introducción y objetivos
………………………………………
1.1. Objetivos del proyecto
………………………………………
1.2. Motivación
………………………………………
1.3. Especificación funcional del proyecto
………………………
1.4. Esquema organizacional del proyecto
………………………
8
8
9
12
14
2. Casos de Uso
………………………………………………………
Caso de Uso#1: Construcción de la topología ………………………
Caso de Uso#2: Establecimiento de los LSPs ………………………
Caso de Uso#3: Visualización del estado actual de la red
………
16
16
18
25
3. Ingeniería de Tráfico ………………………………………………
3.1. Introducción
………………………………………………
3.2. Componentes de la Ingeniería de Tráfico ………………………
27
27
28
II Principios y Bases teóricas
4. Constraint Shortest Path First (CSPF)
………………………
4.1. Principios básicos de CBR
........…………………………
4.2. CSPF
………………………………………………………
4.3. Ruteo basado en QoS. WSP y SWP
………………………
32
32
33
34
5. Minimum Interference Routing Algorithm (MIRA)
………
5.1. Presentación del algoritmo
………………………………
5.2. Modelado del sistema
………………………………………
5.3. Algoritmo propuesto
………………………………………
37
37
38
38
6. Redes Justas (“Fair Networks”)
………………………………
6.1. Introducción
………………………………………………
6.1.1. Nociones de Justicia ………………………………………
6.2. Algoritmo 1: Max-Min Fairness básico para caminos fijos ………
6.2.1. Formulación completa del Algoritmo 1
………………
6.2.2. Pasos para resolver el Algoritmo 1
………………………
6.3. Algoritmo 2: Max-Min Fairness para caminos fijos con cotas ……
6.3.1. Formulación del Algoritmo 2
………………………
6.3.2. Pasos para resolver el Algoritmo 2
………………………
6.4. Algoritmo 3: Max-Min Fairness para múltiples caminos ………
6.4.1. Pasos para resolver el Algoritmo 3 (usando NBT1) ………
6.5. Algoritmo 4: Max-Min Fairness para múltiples caminos acotado ...
40
40
41
41
42
43
44
44
45
46
48
49
4
III Arquitectura de Software
7. Representación de la red e interacción con ARCA ………………
7.1. El package topología
………………………………………
7.2. La clase Elemento
………………………………………
7.3. Las clases LER y LSR
………………………………………
7.4. La clase Link
………………………………………………
7.5. La clase LSP
………………………………………………
7.6. El Package Arca.InterfazGráfica
………………………………
7.6.1. Compatibilidad con ARCA – Analizador de Redes de Caminos
Virtuales
………………………………………………
52
52
54
54
54
54
54
8. Interfaz Gráfica
………………………………………………
8.1. El package Programa
………………………………………
8.2. Clase Principal y VentanaConf
………………………………
8.3. Clase Intérprete
………………………………………………
8.4. Clases TxtFileFilter y ArcFileFilter
………………………
8.5. Clase ConfLink
………………………………………………
8.6. Clase Cargar topología
………………………………………
8.7. Clases Estadísticas y Propiedades
………………………
8.8. Clase Utilización
………………………………………………
57
57
58
59
60
61
62
62
64
9. Carga automática de la topología ……………………………………
9.1. El package CargarRed – Implementación ………………………
65
65
10. Computación de caminos
………………………………………
10.1. El package CrearLSPs
………………………………………
10.2. La clase Ruteo Explícito ………………………………………
10.3. La clase CSPF
………………………………………………
10.4. La clase Algoritmo
………………………………………
10.5. La clase CarConf
………………………………………
10.6. La clase MIRA
………………………………………………
70
70
71
72
75
76
77
11. Algoritmos de justicia y el MIRA
………………………………
11.1. El package MT
………………………………………………
11.2. La clase Caminos
………………………………………
11.3. La clase InterpreteMT
………………………………………
11.4. La clase GeneroMT
………………………………………
11.5. La clase FairnessNetwork
………………………………
11.6. La clase LasDemandas
………………………………………
11.7. La clase OfflineMira
………………………………………
78
78
79
79
80
81
83
84
5
55
IV Conclusiones
12. Conclusiones y tareas a futuro
………………………………
12.1. Supuestos y objetivos
………………………………………
12.2. Conclusiones
………………………………………………
12.3. Tareas a futuro
………………………………………………
87
87
88
89
APÉNDICES
A. Multi Protocol Label Switching (MPLS)
………………
A.1. Descripción funcional de MPLS
………………………
A.2. Componentes y funcionamiento de una red
………………
A.3. Método de distribución de etiquetas
………………
91
91
92
94
B. Simple Network Management Protocol (SNMP) & Management
Information Base (MIB)
………………………………………
B.1. SNMP y Management Information Base
………………
B.2. ASN.1
………………………………………………
B.3. SNMP v1
………………………………………………
B.3.1. Operaciones básicas
………………………………
B.4. SNMP v2
………………………………………………
97
97
98
100
101
101
C. Ejemplo de Fairness con múltiples caminos
………………
C.1. Ejemplo
………………………………………………
102
102
D. Software
………………………………………………………
D.1. Menú Archivo y Barra de Herramientas ………………………
D.2. Crear Matriz de Tráfico ………………………………………
D.3. Barra Vertical
………………………………………………
107
108
110
110
Bibliografía
Glosario de términos
………………………………………………………
116
………………………………………………
117
6
Parte I
Presentación del Problema
7
Capítulo 1
Introducción y Objetivos
En este capítulo expondremos los objetivos, motivaciones y los distintos casos de
uso de manera que se pueda entender en forma clara lo que hace el software y cuál es su
utilidad.
1.1 Objetivos del proyecto
El objetivo general de este proyecto es desarrollar una herramienta que permita
analizar las distintas prestaciones que se pueden obtener al aplicar algoritmos de
Ingeniería de Tráfico sobre una red de computadoras basadas en Multi Protocol Label
Switching (MPLS).
En general se pueden identificar cuatro diferentes objetivos a lo largo de todo este
proyecto.
El primer objetivo específico fue el formar una sólida base teórica sobre MPLS y
TE (Traffic Engineering), entendiendo la razón de su existencia y su funcionamiento. El
enfoque brindado se basará en el estudio de algoritmos de TE “offline” y “online”,
orientados a brindar garantías de Calidad de Servicio (QoS), las cuales permitan
asegurarle al cliente que obtendrá el grado de servicio esperado en términos del ancho de
banda solicitado. Asimismo se estudiaron también métodos de optimización asociados al
reparto “justo” de carga de las demandas de los clientes, lo que constituye las llamadas
“fair networks”. Y por último, y también a destacar, se estudiaron los principales
conceptos que abarcan las MIBs (Management Information Bases), con el objetivo en
particular de determinar cómo descubrir los routers presentes en cierta red, que estén
intercambiando información de ruteo mediante el protocolo OSPF.
Un segundo objetivo, fue el desarrollo de la herramienta de software, llamada
NET-TE (Networking Traffic Engineering), la cual en primera instancia le permitiera al
usuario el poder ingresar manualmente la topología de la red en estudio, devolviéndole el
programa por medio de una interfaz gráfica, el estado actual de la red. Se buscó también
implementar un algoritmo para la computación de caminos (LSPs en nuestro caso),
comúnmente usado en algoritmos de ruteo estilo Constraint Base Routing (CBR), el cual
le ofrecerá también al usuario diferentes criterios de priorización al momento de elegir un
camino. El algoritmo elegido fue el Constraint Shortest Path First (CSPF).
Posteriormente, se puede señalar como tercer objetivo el agregar una
funcionalidad al software que le permitiera al usuario el cargar la topología de la red en
estudio en forma automática.
Finalmente, como cuarto objetivo, se busco el darle la posibilidad al usuario de
poder determinar, teniendo como dato de entrada la matriz de tráfico conteniendo todos
los pares origen-destino con sus respectivos anchos de banda, cuál es la mejor manera de
distribuir la carga de forma tal que la mayoría de las demandas se vean cubiertas de
manera satisfactoria siguiendo diferentes pautas de “justicia” en el reparto de la carga.
8
La realización de este proyecto esta contenida en un marco más amplio de trabajo,
que cuenta con el financiamiento del BID y del PDT, y que tiene por objeto la
implementación de una red multi-servicio, utilizando infraestructura similar a la que
soporta los servicios de datos ofrecidos por ANTEL (ANTELDATA), con el objetivo de
probar aplicaciones/servicios que pueda ser implantados en el futuro con garantías de
calidad de servicio.
1.2 Motivación
El crecimiento actual de la Internet le da una oportunidad a los Internet Service
Providers (ISPs) de ofrecer nuevos servicios como VoIP, Videoconferencia, etc., además
de los ya tradicionales servicios de datos como email, ftp y web browsing. Todos estos
nuevos servicios tienen grandes requerimientos en lo que a throughput, tasa de pérdida,
delay y jitter se refiere.
La Internet no fue diseñada para trabajar con este tipo de requerimientos,
trabajando desde sus comienzos, bajo el paradigma “Best Effort” de IP. Esto significa
que el usuario manda paquetes a la red y la red va a tratar de hacerlos llegar a destino sin
garantía alguna.
A pesar que protocolos como TCP han agregado mecanismos de reenvío que
tratan de solucionar el problema de la pérdida de paquetes generado por el
congestionamiento en la red, estos no solucionan las pérdidas en aplicaciones interactivas
de tiempo real, donde no es posible esperar a que un paquete sea reenviado.
Es por ello que la comunidad de Internet ha hecho grandes esfuerzos en los
pasados años para poder ofrecer garantías de calidad de servicio (QoS) a Internet, con el
objetivo de transformarla en una red convergente para todos los servicios de
telecomunicaciones. Entre los primeros modelos podemos destacar el de Servicios
Integrados (IntServ) y el de Servicios Diferenciados (DiffServ). Debido principalmente a
problemas de escalabilidad en el primer caso y al no poder ofrecer las suficientes
garantías de QoS en el segundo (el actual paradigma de ruteo IP de la Internet provoca la
hiper-agregación de flujos en ciertas partes de la red y sub-utilización de recursos en
otras), es que se necesita de la Ingeniería de Tráfico en las redes IP para asegurar QoS.
Los ISPs necesitan así de sofisticadas herramientas de gestión de redes que
apunten a un uso óptimo de los recursos de la red que son compartidos entre clases de
servicios con diferentes requerimientos de QoS. La tecnología de Multi Protocol Label
Switching (MPLS) es un buen ejemplo que ayuda a realizar TE en sistemas autónomos
(AS) (ver Apéndice A por más información). Se basa en la idea de enviar paquetes a
través de Label Switched Paths (LSPs) haciendo uso de etiquetas que son adjuntadas a los
paquetes en los routers de ingreso de al red (puntos de interconexión entre la red MPLS y
la red de acceso). Esas etiquetas son a su vez asignadas a los paquetes de acuerdo a su
Forwarding Equivalence Class (FEC) (representación de un conjunto de paquetes que
comparten los mismos requerimientos para su transporte) que son entonces mandados a
través de uno de los LSPs asociado con esa FEC en particular.
La práctica de TE hoy en día abarca el establecimiento y uso de esos LSPs como
tuberías de determinado ancho de banda entre dos puntos. Dichos LSPs pueden ser
seteados a través de varios routers, ya sea de forma manual por parte del usuario
9
eligiendo las rutas deseadas o por medio de una herramienta que los compute. Las rutas
pueden ser computadas tanto offline usando alguna herramienta de software, o a través
del uso de algún algoritmo de computación online basado en restricciones (CSPF).
Como podemos ir viendo, la Ingeniería de Tráfico (TE) intenta optimizar la
performance de las redes, a través de tres actividades integradas: medición del tráfico,
modelado de la red, y selección de mecanismos para el control del tráfico.
Desafortunadamente, grandes Proveedores de Servicios de Internet (ISPs) tienen pocos
sistemas de software y herramientas que soporten la medición del tráfico y el modelado
de la red, pilares básicos de una ingeniería de tráfico efectiva. De manera similar,
preguntas sencillas sobre la topología, tráfico y ruteo son sorprendentemente difíciles de
contestar en las redes IP de hoy en día. Una gran cantidad de trabajo ha sido dedicado al
desarrollo de mecanismos y protocolos para el control del tráfico. Como ejemplo de ello,
la mayor parte del trabajo de la Internet Engineering Task Force (IETF) está relacionado
al control del tráfico en lo que a la ingeniería de tráfico concierne.
Existen determinados factores que indican la necesidad de más y mejores
herramientas de ingeniería de tráfico para las redes. Entre ellos se destacan la calidad del
servicio, los parámetros ajustables interdependientes, el crecimiento de las redes y la
variabilidad del tráfico (Referirse a [1] por más información).
En cuanto a la Calidad del Servicio, los clientes son cada vez más exigentes en el
cumplimiento de la performance, confiabilidad y seguridad, que se manifiestan en forma
de Service Level Agreements (SLAs). Los clientes desarrollan más procedimientos de
certificación y testeos continuos, para asegurar el cumplimiento de dichos SLAs.
Aplicaciones como Voz sobre IP, las cuales por su naturaleza, requieren del transporte de
datos de alta calidad, medido por el retardo, tasa de pérdida de paquetes y jitter, están
emergiendo hoy en día. Por eso es muy importante para los operadores de redes el
coordinar cuidadosamente por dónde fluye el tráfico de cada demanda y ver si pueden o
no tolerar la llegada de futuras nuevas demandas sin afectar las ya existentes y por ende,
viendo comprometido el cumplimiento de los SLAs pertinentes.
En lo que a los Parámetros ajustables Interdependientes se refiere, hoy en día,
los proveedores de equipos de red, proveen a los ISPs con poco o ningún control sobre
los mecanismos básicos responsables de la coordinación de paquetes, gestión de buffers y
selección de caminos. En su lugar, los proveedores de backbones son forzados a entender
una larga cantidad de parámetros interrelacionados que de una manera u otra afectan la
configuración y operación. Hasta el día de hoy, un ISP debe gestionar su red de
backbone, y sus complicadas relaciones de frontera con proveedores vecinos, ajustando
los asuntos mencionados anteriormente a través de una combinación de intuición, testeo y
pruebas de intento y error.
El Crecimiento de las Redes se ve reflejado en que por un lado, redes de
backbones individuales están creciendo rápidamente en tamaño, velocidad y espectro
abarcado; mientras que por otro lado, la industria intenta unir redes discordes entre sí, en
redes integradas más grandes. Como resultado, las funciones de gestión de red que una
vez pudieron ser manejadas por un grupo reducido de personas, basándose en la intuición
y experimentación, deben ser ahora soportadas por herramientas efectivas de ingeniería
de tráfico que unen información de configuración y de uso de una variedad de fuentes.
Por último, la Variabilidad del Tráfico. El tráfico de Internet es complejo. La
carga ofrecida entre pares origen-destino es típicamente desconocida. Asimismo, la
10
distribución del tráfico IP usualmente fluctúa ampliamente a través del tiempo. Esto
introduce una gran complejidad a la ingeniería de tráfico sin alivianar las demandas de
los clientes por una performance de comunicación predecible. Herramientas efectivas de
TE deben soportar la identificación rápida de potenciales problemas de performance y un
ambiente flexible para experimentar posibles soluciones.
Es por los motivos expuestos anteriormente que se decidió la creación del
software NET-TE, como un aporte más en cuanto a las herramientas que puede encontrar
un usuario para poder realizar tests de ingeniería de tráfico en un ambiente simulado. La
idea clave detrás de este software es la de ofrecer al usuario de una plataforma donde
pueda visualizar la topología de su red de estudio conjuntamente con datos sobre el uso
de los enlaces, qué enlaces se encuentran saturados, establecer afinidades que distingan el
tráfico que pasa por cierto grupo de enlaces del resto. Una vez enfrente a la topología, el
poder inferir sobre ella y visualizar las implicaciones de cambios locales en el tráfico y
determinar por dónde se rutean las distintas demandas a medida que van llegando, de
acuerdo al estado actual de la red. También el poder realizar una mirada general sobre
todo el grupo de demandas que se tienen hasta el momento y determinar cuál es la mejor
manera de ubicar los LSPs en la red de manera que todas vean sus requerimientos
satisfechos. En el caso de no ser posible satisfacerlas a todas, es deseable el poder
determinar cómo lograr cubrirlas de la manera “más justa” posible a todas ellas.
Entendiendo por “justicia”, la elección por parte del usuario de determinado criterio en
cuanto a la manera en que se debe tratar de repartir la carga entre las diferentes demandas
(clientes).
Usando esta herramienta, un proveedor de red pude claramente experimentar con
cambios en la configuración de la red en un ambiente simulado, en vez en una red
operacional, basándose en una plataforma para investigaciones del tipo “what-if” de
ingeniería de tráfico.
11
1.3 Especificación Funcional del proyecto
La herramienta de software desarrollada, se puede describir en rasgos generales
por medio del diagrama de bloques mostrado en la Figura 1.1.
Router más
próximo
Objetivos de Performance
(restricciones)
MIBs
Descripción de
la Red
Cargar Matriz
de Tráfico
usuario de la
Red
Cálculo de Caminos
Candidatos (Dijkstra)
Algoritmos MIRA o
FairNetworks
Selección de
Camino
LSPs establecidos
LSP establecido
Visualización
Estado Actual de la Red
Figura 1.1: Diagrama de bloques del Proyecto
A continuación pasamos a comentar brevemente cada uno de los bloques
funcionales.
Descripción de la Red:
La función de este bloque es la de generar “un objeto Red”, el cual representará a
la red sobre la cual el usuario trabajará. Se construirá manualmente por parte del usuario
de la Red, ingresando datos como ser la lista de nodos y links con sus respectivos
atributos, los LSPs ya existentes, etc. También se tendrá la opción de cargarla
automáticamente extrayendo la información necesaria de las MIBs del router más
próximo al cual esta conectada la estación de trabajo donde se encuentra instalado el
software NET-TE.
12
Cálculo de caminos candidatos (Dijkstra):
En este bloque el usuario podrá establecer restricciones que los futuros LSPs
deberán cumplir, como ser el ancho de banda (BW) que deberán soportar y el pertenecer
a una determinada Afinidad previamente establecida (P2P, UDP, etc.).
Objetivos de Performance (restricciones):
Acá el usuario podrá ingresar restricciones como el asegurarse que los caminos
encontrados pasen por un determinado enlace y/o no lo hagan por otro, o el elegir el tipo
y valor de los pesos que desea tengan los mismos, determinando así el criterio de
optimización que establecerá la elección de caminos.
Selección de camino:
A partir del estado actual de la red y de los “candidatos”, se podrán establecer
nuevos LSPs mediante la utilización de un algoritmo del tipo Shortest Path First (SPF)
que tome además en consideración un conjunto de restricciones que deben ser cumplidas,
teniendo como objetivo encontrar caminos de origen a destino que satisfagan esas
restricciones impuestas por el usuario previamente, y de ser posible, optimizar la
elección. El usuario también dispondrá de más de un criterio de TE para aplicar antes de
mostrar cuál es/son las soluciones posibles encontradas, a manera de elegir la opción que
más óptima le resulte.
Cargar Matriz de Tráfico:
Aquí se ingresara la matriz de tráfico conteniendo toda la lista de las demandas
que hay sobre la red para los distintos clientes. Se especificarán todos los pares origendestino así como el valor del ancho de banda requerido para cada una de esas demandas.
Algoritmos MIRA o FairNetworks:
Una vez ingresada la matriz de tráfico o cargada una ya creada previamente, se
podrán aplicar diversos algoritmos de ruteo offline que mostrarán la manera de alojar a
todas esas demandas en la red en forma conjunta e indicando cuánto se puede satisfacer a
cada una de ellas.
Estado Actual de la Red:
Simplemente se refiere al estado en el que se encuentra la red en un determinado
instante, con los LSPs ya establecidos en caso que los haya, qué enlaces están saturados,
13
y cuáles tienen sus recursos sobre o sub-utilizados. Se podrá apreciar el porcentaje de
utilización de cada enlace también.
Visualización:
En este bloque se visualizan los nuevos LSPs establecidos, así como el estado
actual de la red.
1.4 Esquema organizacional del proyecto
El objetivo de esta sección es el mostrarle al lector las áreas teóricas analizadas y
principales tareas que se realizaron durante todo el transcurso de este proyecto así como
la manera en que está distribuida la información en el presente documento.
En primer lugar, la tarea de este grupo de trabajo fue la de ponerse en contacto
con los principales conceptos que encierra MPLS y la Ingeniería de Tráfico en Internet
(TE). Para ello nos informamos sobre lo que motivo la aparición de MPLS, sus ventajas,
cómo es el mecanismo de intercambio de etiquetas, entre otras cosas. Asimismo se
estudió TE, su relación con MPLS, los objetivos que busca la ingeniería de tráfico así
como también los pasos que debe seguir un Administrador para poder hacer una
aprovechamiento eficiente de los recursos que ofrece la red en la que opera. Se estudiaron
diversos algoritmos de ruteo que hacen ingeniería de tráfico tanto offline como online.
También se vieron algoritmos de búsqueda de caminos, haciendo principal hincapié en el
Constraint Shortest Path First (CSPF), analizando su uso junto con diferentes tipos de
restricciones.
Una vez conseguida la base teórica deseada, se empezó a desarrollar la
herramienta de software. En una primera instancia, se buscó ofrecerle al usuario la
posibilidad de que creara la topología de la red a su gusto, pudiendo agregar o quitar
nodos y enlaces a su deseo y especificando el ancho de banda, peso y afinidad de los
mismos; todo por medio de una interfaz gráfica. También se crearon herramientas
mediante las cuales el usuario puede visualizar el estado actual de la red en todo
momento. Algunos de los ejemplos de lo anterior son el observar el porcentaje de
ocupación de los enlaces o la lista de los LSPs creados hasta el momento con sus
respectivos anchos de banda. En cuanto a los mecanismos para el establecimiento de los
LSPs, el primero en implementar fue el Ruteo Explícito, mediante el cual el usuario
puede crear un LSP de manera manual, eligiendo los enlaces hasta llegar a formar el
camino de origen a detino. El paso siguiente fue implementar un algoritmo de
computación de caminos (usado en protocolos tipo CBR en su primera etapa de búsqueda
de caminos). El elegido fue el Constaint Shortest Path First (CSPF). Si bien en un
principio se implementó para que sólo desplegara la primera ruta que encontraba de
origen a destino y que cumpliera además con las restricciones ingresadas por el usuario,
luego esto se extendió para que mostrara todas las soluciones posibles (se despliegan
todos los caminos con la distancia más corta del origen a fin, refiriéndonos por distancia
al peso de los enlaces, los cuales representan diversas cosas de acuerdo a lo que el
usuario desee) brindando así al usuario una mayor gama de posibilidades sobre la cual
trabajar y una mayor flexibilidad en la búsqueda de las rutas posibles.
14
Posteriormente se agregaron más funciones, siempre con el objetivo de darle al
usuario una mayor participación en la elección de los caminos y dándole al programa una
mayor o menor participación en esa búsqueda. De ésta manera, cuantas más opciones
tenga el usuario, podrá crear una mayor variedad de escenarios “what-if”. Claros
ejemplos de la flexibilidad que se le intenta dar al usuario son los distintos tipos de pesos
que le puede asignar a los enlaces al momento de usar el CSPF, dándole prioridad a la
distancia o al ancho de banda disponible en los enlaces o a cierto peso administrativo que
es fijado por el usuario. También se ofrecen distintos criterios de TE, que hacen una
especie de filtrado sobre los resultados brindados por el algoritmo CSPF, ayudando
también a incrementar las combinaciones de escenarios que se pueden crear.
El siguiente paso fue el empezar a idear la manera de agregarle al programa la
funcionalidad de poder cargar la topología de la red a la que está conectada la PC vía
Simple Network Management (SNMP) de manera automática. Vale destacar que con
cargar la topología de red se entiende como descubrir todos los routers presentes en cierta
red que estén intercambiando información de ruteo mediante el protocolo OSPF. En
nuestro caso la componente de gestión SNMP fue implementada en el software usando el
API de Adventnet. Se tuvo que hacer nuevamente una fuerte investigación teórica,
enfocándose esta vez en la estructura en forma de árbol usada por SNMP para organizar
la gestión de datos; con esto nos estamos refiriendo a las llamadas Bases de gestión de
Información (MIBs) (ver Apéndice B por más información).
En la próxima etapa surgió la idea de agregar un nuevo algoritmo para el ruteo
dinámico de los LSPs con ancho de banda garantido, en donde las demandas de ruteo van
llegando una por una y no hay conocimiento previo acerca de futuras demandas. Este
problema es motivado por la necesidad de los ISPs de desarrollar rápidamente servicios
de ancho de banda garantidos y la consecuente necesidad en los backbones de redes de un
aprovisionamiento rápido de caminos con ancho de banda garantido. El algoritmo elegido
fue una pequeña variante del conocido algoritmo Minimun Interference Routing
Algorithm (MIRA), el cual se basa en el principio de que cada nuevo túnel ruteado (LSP)
debe seguir una ruta que no “interfiera demasiado” con una ruta que pueda ser
posiblemente crítica para satisfacer una futura demanda. Previo a su elección se
analizaron otros posibles algoritmos y luego de compararlos se decidió usar éste.
Finalmente, en una última etapa, asumimos que el volumen de carga (BW) para
cada demanda deja de ser una cantidad fija y pasa a ser una especie de demanda elástica.
Así nos planteamos la siguiente pregunta: ¿cuál debería ser el principio que gobierne la
distribución de los volumenes de esas demandas entre ciertos recursos de red (capacidad
de los links) que llevan a asignaciones que cumplen con determinado criterio de justicia?
Nos encontramos así con un nuevo tema abarcado por las llamadas “redes justas” (Fair
Networks), del cual estudiamos sus aspectos más generales e incorporamos cuatro
diferentes algoritmos, con el objetivo de determinar si el usuario podrá alojar en la red
todas las demandas que fueron solicitadas, o en caso de no ser posible, cuál es la manera
“más justa” de distribuirlas entre los recursos de la misma.
Demos paso entonces, en los próximos capítulos, a introducir los conceptos
principales que deberá poseer el lector sobre MPLS y TE.
15
Capítulo 2
Casos de Uso
Veamos ahora cuáles son los usos y las distintas funcionalidades que el software
NET-TE tiene para ofrecer.
Se distinguen tres principales utilidades o casos de uso dentro de NET-TE:
construcción de la topología de la red de trabajo, establecimiento de los LSPs por los
cuáles pasará el tráfico de cada demanda y visualización del estado actual de la red. A su
vez, han de destacarse los cuatro mecanismos usados por NET-TE para el
establecimiento de los LSPs: ruteo explícito, CSPF, MIRA y FairNetworks.
Explicaremos más adelante qué ventaja ofrece cada uno de ellos y los
compararemos.
C
Caso de Uso# 11: Construcción de la topología
Para empezar a trabajar, lo primero que necesita hacer el usuario es construirse la
topología de la red sobre la cual va a trabajar. NET-TE ofrece dos maneras de realizar
esto: una manual y otra automática.
La interfaz gráfica donde se apoya NET-TE está formada por dos barras de
herramientas, desde las cuales el usuario puede acceder a las distintas funciones del
software y una pantalla que es el marco de trabajo donde se crea o carga la topología de
la red.
Empecemos por el método manual de construcción. En este caso, el usuario
dispone de dos posibles objetos para crear su topología: routers y links. Como la red
donde se trabaja es basada en MPLS, los routers que se ofrecen son de dos tipos: LERs y
LSRs.
NET-TE permite manipular los objetos dentro de la pantalla con total libertad,
pudiéndolos colocar y desplazándolos de un lugar a otro a gusto del usuario, de manera
que éste pueda diseñar la red con la forma que desee y pudiéndola guardar luego en un
archivo en su computadora, en caso de querer reutilizarla luego, si así lo desease.
Esto resulta muy cómodo ya que el usuario puede cargar una vieja topología que
tenia guardada, y cambiarla a su gusto, para reflejar el estado más reciente de la misma,
agregando o quitando enlaces o routers de la red.
Los campos que ofrece NET-TE para configurar los enlaces son los siguientes:
ancho de banda, peso administrativo y afinidad. Como se puede apreciar en la Figura 2.1,
el usuario puede describir con bastantes detalles las características de los elementos de la
red. La opción del uso de pesos administrativos es especialmente útil en los casos en los
que el usuario desea darle más prioridad a ciertos enlaces sobre otros. Son varios los
motivos que pueden llevar a un usuario el querer priorizar cierto grupo de enlaces sobre
otros. Como ejemplo, podemos mencionar razones de política interna por parte del cliente
que regulen el uso de los recursos sobre cierto enlace o grupo de enlaces. También
pueden existir tráficos que satisfacen demandas que son críticas o de mayor importancia,
16
con lo cual resultaría particularmente útil el evitar que futuros LSPs a ser establecidos
pasen por los enlaces que las conforman, a menos que
sea
necesario. Otra
característica de suma utilidad es poder
Figura 2.1: Pantalla principal de NET-TE y ventana de configuración de enlace.
seleccionar una Afinidad determinada para ciertos grupos de enlaces. NET-TE le da al
usuario la posibilidad de crear como grupos de enlaces que se diferencien unos a otros de
acuerdo al tipo de tráfico que pasa a través de ellos. Es muy común en una red el tener
distintos tipos de tráfico circulando por la misma (P2P, TCP, UDP, Low Delay, etc.) y es
deseable quizás para un usuario el establecer LSPs sólo sobre los enlaces que dejan pasar
determinado tráfico por ellos. El concepto de Afinidad brindado por NET-TE permite
éste tipo de cosas.
Basta con hacer un simple click en el enlace deseado y el usuario será capaz de
visualizar las propiedades de cada enlace y router, así como apreciar cuáles LSPs pasan
por ellos. De la misma manera y con la misma facilidad, el usuario será capaz de
modificar los parámetros de los enlaces nombrados anteriormente, para poder reflejar así
cualquier cambio que haya ocurrido en la topología.
En todo momento, si el usuario realizó algún cambio el cual quisiera deshacer, o
viceversa, NET-TE le ofrece esa posibilidad por medio del uso de dos flechas de poder ir
hacia adelante como hacia atrás en cambios ocurridos en la topología. Ver Figura 2.2.
Figura 2.2: Botones para deshacer o rehacer cambios.
17
Pero supongamos que el usuario no tiene conocimiento sobre cómo es la
topología de la red a la cual esta conectado, y sin embargo quiere poder obtenerla para
poder así crear distintos escenarios sobre la misma. Obviamente la solución manual no es
la adecuada. Es por ello que NET-TE ofrece también un mecanismo automático,
mediante el cual, tras ingresar determinados parámetros obligatorios tal como la Figura
2.3 nos muestra, comienza a iterar hasta descubrir completamente la red. Vale destacar
que para NET-TE, el cargar la topología se entiende como descubrir todos los routers
presentes en la red, que estén intercambiando información de ruteo mediante el protocolo
OSPF.
Dentro de los parámetros obligatorios se
encuentra la dirección IP de algún router de la red (en
general es la del router a la que la computadora está
directamente conectada), la versión SNMP que se desea
ejecutar (NET-TE ofrece las versiones 1 y 2) y el
“community” o password usado por SNMP para permitir
sólo el acceso al router a personas con permiso. También
se ofrecen parámetros opcionales, que el usuario es libre
de modificar, como el puerto (NET-TE usa el 161 por
defecto), número de reintentos y timeout. Además se
tiene la posibilidad de seleccionar la opción de
“Continuar carga de red”, útil cuando llegamos a un área
de la red la cual tiene un community distinto, el cual
poseemos y queremos ingresar al programa para que
continúe su descubrimiento de la red.
Figura 2.3: Ventana Cargar Red.
Obviamente, esto es sumamente útil si la red es una red de gran tamaño, ya que
consumiría mucho tiempo el crearla manualmente. De esta manera se obtiene el mismo
resultado, pero de una manera mucho más rápida.
Una vez cargada la topología en forma automática, el usuario vuelve a ser libre de
poder modificarla a su gusto, tal como lo hace si la cargara manualmente.
C
Caso de Uso# 2
2: Establecimiento de los LSPs
En MPLS, como todos ya sabemos, el tráfico para determinada demanda sigue
determinados LSPs desde que entra a la red MPLS hasta que sale. Es de esa manera que
se puede clasificar los servicios según la QoS que desee cada usuario. Por eso, es tan
importante el establecimiento de los LSPs, cómo elegirlos y dónde ubicarlos de manera
de cubrir de la mejor manera posible las demandas. NET-TE tiene por ende cuatro
distintos mecanismos para ofrecer al usuario, al momento de elegir cómo y por dónde
ubicar a los LSPs.
18
Ruteo Explícito:
El primer mecanismo es el más sencillo de los propuestos (en lo que a cálculos
se refiere): el ruteo explícito. Se le ofrece al usuario una ventana (ver Figura 2.4) en la
cual, a partir de la elección del nodo de origen, se le van desplegando los posibles enlaces
para que pueda ir creando salto a salto, el LSP de manera explícita de origen a fin. En
NET-TE, la demanda se expresa en términos del ancho de banda. Es decir, cada demanda
se representa por medio del nodo origen, destino y un determinado ancho de banda que
satisfacer. El usuario debe por ello ingresar también en primer lugar el ancho de banda
que desea tenga el LSP a crear. NET-TE entonces va chequeando el ancho de banda
disponible de los enlaces que contienen el nodo en el que esta parado el usuario y
despliega sólo aquellos que cumplan con la condición de tener un BW mayor o igual al
requerido por el LSP.
Esta
es
una
manera que como vemos
no utiliza algoritmo
alguno, sino que sólo se
basa en la decisión que
tome el usuario y
depende exclusivamente
del camino que éste
desee. Un ejemplo de
una situación de este tipo
es cuando el usuario, ya
sea o porque la red tiene
suficiente ancho de
banda como para no
restringir ningún posible
LSP o porque posee
un conocimiento muy
Figura 2.4: Ventana para el Ruteo Explícito.
grande de la red, cree saber ya de entrada por que camino es mejor que vaya el LSP.
Quizás haya un acuerdo con el cliente, el cual obligue al LSP a seguir cierto camino
explícito de manera obligatoria, con lo cual ésta sería la manera más sencilla de
establecerlo.
CSPF:
El segundo mecanismo ofrecido es el CSPF. Supongamos el caso donde el
usuario tiene una red sobre la cual ya existen determinadas demandas siendo ruteadas por
ciertos LSPs. Supongamos también que hay más de un tipo de tráfico circulando por la
red y que eso está siendo reflejado por las afinidades creadas por el usuario. Aparece
entonces un nuevo cliente queriendo conseguir un LSP por el cual rutear su tráfico y
19
requiere que le aseguren determinado BW. Entonces, salvo que sea una red de tamaño
pequeño y sea muy evidente el camino a usar, el usuario necesitará de algún algoritmo
que le halle ese LSP que está buscando, teniendo en cuenta el estado actual de la red.
NET-TE le muestra al usuario cuales son todos los posibles caminos por los
cuales puede rutear su tráfico, asegurándose que cumplan con el BW solicitado por el
cliente, además de un conjunto pre-definido de restricciones que puede él mismo ingresar
y comentaremos más adelante. Finalmente, será decisión del usuario el elegir el camino
que más le convenga, dentro de toda la gama de soluciones.
Dentro de los parámetros obligatorios a ingresar (ver Figura 2.5) por parte del
usuario, se encuentran obviamente, el nodo de origen, el nodo destino y el BW
requerido por el cliente. En caso que se desee buscar soluciones sólo por aquellos
enlaces que soportan cierto tipo de tráfico se incorporó al NET-TE la posibilidad de
elegir la Afinidad, como parámetro opcional.
Puede suceder que por razones político-administrativas de parte del cliente, o por
determinado SLA que debe cumplirse, el usuario necesite que los caminos posibles pasen
por un determinado enlace en particular y no lo hagan por otro, por ejemplo. A manera de
tener en cuenta este tipo de solicitudes, se incorporaron también otros dos parámetros
opcionales a elegir, que son: Enlace Presente y Enlace Ausente. NET-TE se encarga de
esta manera de asegurar al cliente que las soluciones a mostrar (en el caso que existan)
cumplirán con estas restricciones.
Ahora bien, ya que el CSPF se basa en el algoritmo Dijkstra, se debe determinar
cuál es la métrica a usar para elegir el camino “más corto” (con más corto, nos referimos
no al camino de menos saltos, sino al camino cuya suma de pesos es la menor). Acá,
NET-TE ofrece 4 diferentes tipos de pesos a asignar a los enlaces: Ruteo Mínimo por
Pesos Administrativos, Ruteo por Mínima Cantidad de Saltos, 1/(BWreservado) y
1/(BWlibre).
El primero de todos es básicamente basarse en los pesos que fueron pre-definidos
por el usuario para cada enlace. El usuario, al tener la posibilidad de asignar pesos a los
enlaces, puede influir en la toma de decisión de cuál es el mejor camino por donde
establecer el LSP.
El segundo, es simplemente establecer la cantidad de saltos, como la métrica
elegida. NET-TE se fijará solamente en la cantidad de saltos del origen al destino y
buscará los caminos que tengan la menor cantidad de saltos de principio a fin.
La tercera, tal como lo indica su nombre, usa pesos que equivalen al inverso del
BWreservado en cada enlace. Supongamos que el cliente, tiene ya varios LSPs
establecidos sobre la red, los cuales consumen determinado BW de los enlaces por los
que pasan. Esto hace que hayan enlaces más ocupados y otros más libres en la red. Llega
un nuevo LSP que necesita ser ubicado en la red y el usuario quiere que éste tienda a usar
los enlaces más ocupados en la red, de manera tal de dejar a los que están más libres,
disponibles para futuras demandas. Es una manera de procurar seguir usando los enlaces
que ya están siendo más utilizados por otros LSPs, y no tocar los que están más libres.
NET-TE brinda esta posibilidad, con tan sólo seleccionar este tipo de peso.
Finalmente, supongamos que el usuario quiere exactamente lo opuesto a lo
anterior. Es decir, quiere que el nuevo LSP a crearse tienda a pasar por aquellos enlaces
que están más libres en la red, no tocando aquellos que ya tienen recursos consumidos o
LSPs pasando por ellos. O sea, dicho con otras palabras, que se tienda a ubicar al LSP por
20
aquellas zonas de la red que no han sido usadas aún, de manera de no sobrecargar
aquellas que sí lo están siendo. Esto es lo que NET-TE permite si el usuario elige la
cuarta opción de peso.
Se puede ver que NET-TE ofrece una amplia gama de criterios de pesos, de
manera que el usuario pueda elegir cuál desea sea usado por el algoritmo para el cálculo
de la nueva ruta, pudiendo jugar así con las distintas combinaciones y viendo cómo afecta
una u otra elección. Vale decir que estos son parámetros obligatorios que debe ingresar el
usuario.
Por último, NET-TE le ofrece al usuario, como última opción, la posibilidad de
usar o no determinado criterio de TE, sobre los caminos encontrados: Elegir
manualmente, No saturación enlaces críticos y Minhop.
Supongamos que luego de que el usuario haya ingresado todos los parámetros
anteriores, NET-TE encuentra más de un camino que satisfaga los requerimientos de BW,
Afinidad y demás. Y supongamos ahora que el usuario no quiere ver uno a uno cada uno
de ésos caminos, analizando sus diferencias, sino que por otro lado, desea aplicarle una
especie de “filtro” y que sólo se desplieguen aquellas soluciones que no contienen a los
enlaces más críticos, o por aquellas que, dentro del grupo de soluciones posibles, tengan
la menor cantidad de saltos.
Es por lo anterior que se incorporaron tres criterios de TE al software.
El primer criterio, simplemente le indica a NET-TE que despliegue todas las
soluciones posibles que encontró Dijkstra, tomando en cuenta las restricciones y pesos
seleccionados. De esta manera el usuario ve todas las soluciones y él es quien determina
con cuál quedarse.
Figura 2.5: Ventanas de CSPF y de información sobre resultados hallados.
21
Con el segundo criterio, NET-TE lo que hace es comparar las soluciones
encontradas y se queda sólo con aquella cuyos enlaces que la componen, tiene el mayor
ancho de banda disponible. De esta manera, no sólo se muestra el camino que cumple con
las restricciones y que según la métrica elegida es el más “corto”, sino que se muestra
aquel que “molesta” menos a los enlaces más saturados.
Finalmente, el último criterio de TE es el de Minhop, el cual, tal como su
nombre lo indica, de todas las soluciones encontradas, se queda sólo con aquellas que
tienen la menor cantidad de saltos de origen a destino. Esto es especialmente útil si se
combina con ciertos tipos de pesos, pudiendo encontrar por ejemplo, no sólo las posibles
soluciones que van por la parte más o menos ocupada de la red, sino también, por la más
corta.
Vale destacar que otra práctica funcionalidad que el NET-TE ofrece al elegir el
segundo o tercer criterio de TE, es una ventana que despliega, en caso de existir múltiples
soluciones, valores como la Capacidad, BW usado y Porcentaje de Utilización de los
enlaces que las conforman. Se distinguen las soluciones ofrecidas de aquellas que fueron
descartadas. Esto es muy útil para poder visualizar numéricamente la razón de la decisión
tomada por NET-TE.
MIRA:
Ya habiendo visto los criterios de Ruteo Explícito y CSPF, pasemos ahora al
mecanismo conocido como MIRA (Minimum Interefence Routing Algorithm), para el
establecimiento de los LSPs.
El usuario por ejemplo se puede encontrar en la situación de querer establecer
varios caminos de acceso a Internet para clientes a los que no se les garantiza ningún tipo
de calidad de servicio (tráfico Best Effort). Pero a la vez querer establecer caminos con
altos requerimientos de calidad de servicio para ofrecer por ejemplo servicios
corporativos de voz y video.
Con los algoritmos clásicos como el
SPF, los caminos se mapearán
indistintamente por el camino más corto degradando el servicio de los clientes
corporativos ya establecidos e interfiriendo con futuras demandas (nuevos clientes).
La solución ideal en este caso sería correr un algoritmo que tenga como entrada
los puntos (localidades, nodos, etc.) que el usuario considera críticos y mapear los
caminos de Internet por enlaces que no sean críticos para las demandas que se les quiere
dar prioridad.
Con NET-TE, el usuario podrá cargar todas las demandas que corresponden a
caminos de acceso a Internet y mapearlas en la red corriendo el algoritmo MIRA. Así, se
22
mapearán todos
los caminos de
acceso a Internet
por los caminos
más largos, o
hasta
que
no
exista
otra
posibilidad (sature
por ejemplo algún
enlace). Luego el
usuario podrá por
ejemplo
correr
CSPF
para
establecer
los
caminos
de
servicios
corporativos.
Figura 2.6: Ventana del algoritmo MIRA.
La idea básica de este tipo de algoritmos es la de minimizar la interferencia que
provoca el establecimiento de un nuevo LSP a potenciales nuevos LSPs que son
desconocidos de modo de reservar recursos para demandas a las que considero más
importantes. Se puede apreciar la ventana de dicho algoritmo en la Figura 2.6.
Fairness:
Así llegamos al último mecanismo ofrecido por NET-TE, Fairness.
Supongamos ahora que el usuario ya no tiene que preocuparse por ver cómo
colocar determinado LSP para cada demanda nueva entrante. Ahora, lo que desea es,
teniendo una matriz de tráfico que contiene a todas las demandas que desean establecerse
sobre la red (la cual ya puede contener viejos LSPs establecidos), ver cómo satisfacerlas a
todas ellas de una manera lo más “justa” posible.
El usuario posee la lista de todas las demandas correspondientes a cada uno de
sus clientes, especificadas por sus pares origen-destino y BW mínimo requerido por cada
una de ellas. La pregunta que le podría resultar interesante de hacerse sería: ¿Cuántos
recursos me puede ofrecer la red en su estado actual, para cada uno de los caminos que
satisfacen las demandas de los clientes? Esos caminos solución son los hayados por el
algoritmo CSPF. El usuario dispone de dos tipos de pesos a elección: minhop o pesos
administrativos. Una vez hayados todos los caminos posibles que cumplen con la
restricción del ancho de banda para todas las demandas, el objetivo es ver cómo se
asignan los recursos de la red, a cada una de ellas, de manera que se obtenga el máximo
aprovechamiento posible de la red.
Una aplicación puede ser cuando se tiene determinada red utilizada para brindar
servicios exclusivamente a un determinado número de clientes. Se quiere entonces
23
“arrojar” sobre ella los LSPs que van a cubrir cada una de esas demandas y darles a ellos
la máxima cantidad de recursos que la red me puede brindar, de manera que se haga un
uso de ellos “justo” entre las demandas.
NET-TE brinda la información anterior al usuario, y le da a elegir cuatro
algoritmos a usar distintos: fairness básico, acotado, con múltiples caminos y con
múltiples caminos acotado. Observar la Figura 2.7.
El primero y el tercero brindan
información sobre cuál es la cantidad
máxima de BW que puedo tomar de la red
para cada una de las demandas. La única
diferencia es que el primer algoritmo sólo
me considera un camino solución fijo para
cada demanda, mientras que el tercero toma
todos los caminos solución posibles. Para el
caso en que hayan múltiples caminos
posibles en el primero, se le brinda la
posibilidad al usuario de elegir el que guste
de entre una lista de posibles opciones, de
manera tal que se quede con uno solamente,
tal como debe ser.
El segundo considera también sólo
un camino solución fijo por demanda (tal
Figura 2.7: Ventana de algoritmos Fairness
como en el primero, el usuario puede elegir el que desee en caso de haber más de una
opción disponible), pero le brinda al usuario la opción de ingresar prioridades a las
demandas y le permite elegir una cota inferior de BW para cada demanda. Si bien el
concepto de incorporar prioridades parece oponerse al de ofrecer un reparto de ancho de
banda justo entre las demandas, es útil para aquellos casos en donde deseamos poder
diferenciar a los clientes desde un punto de vista económico, priorizando a aquellos que
por ejemplo pagan más de los que pagan menos. También es útil cuando el usuario debe
asegurarse que las demandas lleguen a obtener al menos un BW mínimo obligatorio en el
reparto.
Como ejemplo, supongamos que tiene una demanda que requiere 10MB. Como
sabe que quizás el LSP que se cree para esa demanda, tenga que compartir recursos con
otros LSPs de otras demandas, puede suceder que no llegue a obtener esos 10MB. Lo que
puede hacer es poner un mínimo de 5MB por ejemplo y de esa manera se asegura que de
haber solución, el BW que va a obtener va a estar entre esos dos valores con seguridad.
El cuarto algoritmo es similar al tercero. La diferencia es que en vez de
detenerse el cálculo cuando ya no quedan más recursos que la red pueda ofrecer, se
detiene cuando se llegó a cumplir con el ancho de banda requerido para cada demanda.
Obviamente que en caso de saturar primero la red antes que se llegue al ancho de banda
requerido, también se detendrá el cálculo.
24
Éste es particularmente útil para un usuario cuando no desea ver cuál es la
cantidad máxima de recursos que le puede ofrecer la red para satisfacer sus demandas,
sino saber si puede llegar a cumplirlas, deteniéndose una vez que fueron satisfechas.
Para la mejor visualización del usuario, aquellas demandas que no lograron
satisfacer el BWrequerido, se pintarán de color rojo, a diferencia de aquellas que si lo
lograron satisfacer o superar. Asimismo, para el tercer y cuarto algoritmo, se tiene la
posibilidad de apreciar cada una de las sub-demandas o caminos que conforman las
demandas principales en forma separada, pudiendo ver cuánto ancho de banda rutean
cada una de ellas, así como apreciarlas en forma gráfica.
Asimismo, se dispondrá también de una ventana que despliega los resultados
obtenidos en forma numérica para todas las demandas, teniendo el usuario de ésta
manera, otra forma sencilla de visualizar cuántas demandas satisfacen y cuántas no, el
ancho de banda requerido.
C
Caso de Uso# 3: Visualización del estado actual de la red
El último caso de uso consiste en los métodos que tiene el usuario con el software
NET-TE de poder ver el estado de la red.
Básicamente lo puede hacer de dos formas posibles: por medio del uso del botón
Estadísticas o bien del botón Utilización.
Con tan sólo apretar el botón Estadísticas (ver Figura 2.8), en cualquier momento,
al usuario se le desplegará una pantalla donde figurarán todos los nodos que conforman la
red, los enlaces, así como los LSPs establecidos hasta ahora. Podrá ver las características
de cada uno de ellos, así como también por cuál o tal nodo o enlace pasa cierto LSP, entre
otros valores. Si así lo desea, se le brinda la posibilidad de visualizar al mismo tiempo
todos los enlaces de la red, y ver el porcentaje de utilización de cada uno de ellos. Debido
a la manera en que esta desplegada la información, resulta muy práctico a la vista el
comparar unos con otros.
Al usuario también le podría
interesar el poder clasificar a los enlaces
de la red, de acuerdo al porcentaje de
utilización que tienen y visualizar esa
clasificación de una manera rápida y
sencilla en pantalla. NET-TE permite
realizar eso por medio de la herramienta
Utilización (ver Figura 2.9).
Figura 2.8: Ventana Estadísticas.
25
Basta tan sólo ingresar dos valores de porcentajes, una cota inferior y otra
superior, y NET-TE pintará de colores distintos cada uno de los tres niveles de utilización
para cada enlace.
Esta es una manera sencilla de visualizar en pantalla qué zonas de la red están
más saturadas que otras. Es en especial práctico para redes de gran tamaño, donde ver
valores numéricos no sea tan intuitivo como esto.
Figura 2.9: Ventana Utilización.
En caso de no ingresarse ningún número, se asignan dos valores por defecto.
26
Capítulo 3
Ingeniería de Tráfico (TE)
3.1 Introducción
La Ingeniería de Tráfico (TE) es una disciplina que procura la optimización de
la performance de las redes operativas. La Ingeniería de Tráfico abarca la aplicación de la
tecnología y los principios científicos a la medición, caracterización, modelado, y control
del tráfico que circula por la red. Las mejoras del rendimiento de una red operacional, en
cuanto a tráfico y modo de utilización de recursos, son los principales objetivos de la
Ingeniería de Tráfico. Esto se consigue enfocándose a los requerimientos del rendimiento
orientado al tráfico, mientras se utilizan los recursos de la red de una manera fiable y
económica.
Una ventaja práctica de la aplicación sistemática de los conceptos de Ingeniería de
Tráfico a las redes operacionales es que ayuda a identificar y estructurar las metas y
prioridades en términos de mejora de la calidad de servicio dado a los usuarios finales de
los servicios de la red. También la aplicación de los conceptos de Ingeniería de Tráfico
ayuda en la medición y análisis del cumplimiento de éstas metas.
La ingeniería de tráfico se subdivide en dos ramas principalmente diferenciadas
por sus objetivos:
Orientada a tráfico: ésta rama tiene como prioridad la mejora de los indicadores
relativos al transporte de datos, como por ejemplo: minimizar la pérdida de paquetes,
minimizar el retardo, maximizar el throughput, obtener distintos niveles de acuerdo para
brindar calidad de servicio, etc.
Orientada a recursos: ésta rama se plantea como objetivo, la optimización de la
utilización de los recursos de la red, de manera que, no se saturen partes de la red
mientras otras permanecen subutilizadas, tomando principalmente el ancho de banda
como recurso a optimizar.
Ambas ramas convergen en un objetivo global, que es minimizar la congestión.
Un reto fundamental en la operación de una red, especialmente en redes IP públicas a
gran escala, es incrementar la eficiencia de la utilización del recurso mientras se
minimiza la posibilidad de congestión.
Los paquetes luchan por el uso de los recursos de la red cuando se transportan a
través de la red. Un recurso de red se considera que está congestionado si la velocidad de
entrada de paquetes excede la capacidad de salida del recurso en un intervalo de tiempo.
La congestión puede hacer que algunos de los paquetes de entrada sean retardados
e incluso descartados. La congestión aumenta los retardos de tránsito, las variaciones del
retardo, la pérdida de paquetes, y reduce la previsión de los servicios de red. Claramente,
la congestión es un fenómeno nada deseable y es causada por ejemplo por la insuficiencia
27
de recursos en la red. En casos de congestión de algunos enlaces, el problema se resolvía
a base de añadir más capacidad a los enlaces.
La otra causa de congestión es la utilización ineficiente de los recursos debido al
mapeado del tráfico. El objetivo básico de la Ingeniería de Tráfico es adaptar los flujos
de tráfico a los recursos físicos de la red. La idea es equilibrar de forma óptima la
utilización de esos recursos, de manera que no haya algunos que estén sobre-utilizados,
creando cuellos de botella, mientras otros puedan estar subutilizados. En general, los
flujos de tráfico siguen el camino más corto calculado por el algoritmo IGP
correspondiente. La Ingeniería de Tráfico consiste en trasladar determinados flujos
seleccionados por el algoritmo IGP sobre enlaces más congestionados, a otros enlaces
más descargados, aunque estén fuera de la ruta más corta (con menos saltos).
En resúmen la Ingeniería de Tráfico provee por ende, de capacidades para realizar
lo siguiente:
•
Mapear caminos primarios alrededor de conocidos cuellos de botella o puntos de
congestionamiento en la red.
•
Lograr un uso más eficiente del ancho de banda agregado disponible, asegurando
que subgrupos de la red no se vuelvan sobre-utilizados, mientras otros subgrupos
de la red son inutilizados a lo largo de caminos potenciales alternativos.
•
Maximizar la eficiencia operacional.
•
Mejorar las características de la performance del tráfico orientado de la red,
minimizando la pérdida de paquetes, minimizando períodos prolongados de
congestión y maximizando el throughput.
•
Mejorar las características estadísticas de los límites de la performance de la red
(como ser tasa de pérdidas, variación del delay y delay de transferencia).
•
Proveer de un control preciso sobre cómo el tráfico es re-enrutado cuando el
camino primario se enfrenta con una sola o múltiples fallas.
3.2 Componentes de la Ingeniería de Tráfico
Hay cuatro componentes que se pueden destacar dentro de la Ingeniería de
Tráfico: la componente del packet fowarding, la componente de distribución de
información, la componente de selección de camino y la componente de señalización
(Por más información ver [2], RFC 3272).
Dentro de la primera componente tenemos a MPLS, responsable de dirigir un
flujo de paquetes IP a lo largo de un camino predeterminado a través de la red. Esa es una
de las principales diferencias entre MPLS e IP, ya que en IP, en vez de seguir los
paquetes un camino ya preestablecido, lo hacen salto a salto. Antes de continuar con la
segunda componente veamos una breve descripción sobre MPLS.
28
La clave detrás de MPLS es el mecanismo de asignación e intercambio de
etiquetas en que se basa. Esas etiquetas son las que permiten que se establezcan las rutas
que siguen los paquetes entre dos nodos de la red. Esa ruta a seguir se la conoce como
ruta conmutada de etiquetas (LSP). Se crea concatenando uno o más saltos (hops) en los
que se produce el intercambio de etiquetas, de modo que cada paquete se envía de un
“conmutador de etiquetas” (Label-Switching Router, LSR) a otro, a través de la red
MPLS.
Los routers en este tipo de redes pueden ser de dos tipos, routers de frontera de
etiquetas (LERs) y routers de conmutación de etiquetas (LSRs). Los LERs operan en
los extremos de la red MPLS y se encarga de interconectar a ésta con la red de acceso. Al
llegar un paquete a un LER, éste examina la información entrante y chequeando una base
de datos, le asigna una etiqueta. A la salida de la red MPLS, éstos mismos dispositivos se
encargan de remover la etiqueta para entregar así el paquete tal como fue recibido.
Los paquetes, una vez etiquetados por el LER, viajan por la red MPLS a través de
los routers de conmutación de etiquetas (LSRs). Estos se encargan básicamente de dirigir
el tráfico en el interior de la red, según sea la etiqueta que contenga el paquete. Al llegar
un paquete a un LSR, éste examina su etiqueta y usándola como índice en una tabla,
determina el siguiente “salto” y una nueva etiqueta para el paquete. Cambia una por otra
y lo envía hacia el siguiente router, formando así el LSP.
Un conjunto de paquetes que comparten los mismos requerimientos para su
transporte, pertenecen a la misma FEC (Forwarding Equivalence Class). Las FECs son
una manera de distinguir un tipo de tráfico de otro. Todos los paquetes que pertenezcan a
la misma FEC seguirán el mismo LSP para llegar a destino. A diferencia del
enrutamiento IP convencional, la asignación de un paquete a determinado FEC se hace
sólo una vez. Otra diferencia con IP, es que las etiquetas en MPLS no contienen una
dirección IP, sino un valor numérico acordado entre dos nodos consecutivos para brindar
una conexión a través de un LSP. Este valor se asocia a una determinada FEC.
Finalmente, luego que cada router tiene sus tablas de etiquetas puede comenzar el
direccionamiento de paquetes a través de los LSPs preestablecidos por un determinado
FEC.
Habiendo señalado las principales características de MPLS, proseguimos con la
segunda componente de TE. Ésta consiste en requerir de un conocimiento detallado de
la topología de la red así como también información dinámica de la carga en la red. La
componente de distribución de información es implementada definiendo extensiones
relativamente simples a los IGPs, tal que los atributos de los enlaces son incluídos como
parte de cada aviso del estado de enlace en cada router.
Cada router mantiene atributos de los enlaces de la red e información de la
topología de la red en una base de datos de TE especializada (TED). La TED es usada
exclusivamente para el cálculo de rutas explícitas, para la ubicación de LSPs a lo largo de
la topología física. En forma aparte, una base de datos es mantenida, de manera que el
cálculo subsiguiente de la ingeniería de tráfico sea independiente del IGP y de la base de
datos del estado de enlace del IGP. Mientras tanto, el IGP continúa su operación sin
ninguna modificación, realizando el cálculo tradicional del camino más corto, basado en
información contenida en la base de datos del estado de enlace en el router.
29
En cuanto a la componente de selección de caminos, luego que los atributos de
los enlaces y la información de la topología han sido inundados por IGP y localizados en
la TED, cada router de ingreso utiliza la TED para calcular los caminos de su propio
conjunto de LSPs a lo largo del dominio de ruteo. El camino para cada LSP puede ser
representado tanto por lo que se denomina, una ruta explícita estricta o sin trabas(“strict
or loose explicit route”). El router de ingreso determina el camino físico para cada LSP
aplicando por ejemplo, un algoritmo de restricciones de camino más corto (CSPF,
Constrained Shortest Path First) a la información en la TED.
A pesar de que se reduce el esfuerzo de administración (resultado del cálculo
online del camino) una herramienta de planeamiento y análisis offline es necesaria si se
quiere optimizar la TE globalmente. En el cálculo online se toma en consideración las
restricciones de los recursos y se va calculando un LSP a la vez, a medida que van
llegando las demandas. Esto implica que el orden en que los LSPs son calculados es muy
importante, ya que depende de los LSPs ya establecidos, por dónde se dirigirá cada nuevo
LSP que llega. Si se cambiara el orden de llegada de los LSPs, es muy probable que los
caminos elegidos para establecerlos cambien también. De esta manera, los LSPs que se
calculan primero tienen más recursos disponibles para utilizar que los que llegan más
tarde, ya que todo LSP calculado previamente consume recursos.
Por otro lado, una herramienta de planeamiento y análisis offline, examina en
forma simultánea las restricciones de recursos de cada enlace y los requerimientos de
cada LSP. Si bien el acercamiento offline puede tardar varias horas en completarse,
realiza cálculos globales comparando los resultados de cada cálculo y selecciona
entonces la mejor solución de la red tomada como un conjunto. La salida del cálculo es
un conjunto de LSPs que optimizan la utilización de los recursos de la red. Una vez
finalizado el cálculo offline, el LSP puede ser establecido en cualquier orden ya que cada
uno ha sido instalado siguiendo las reglas para una solución óptima global.
Por último, la componente de señalización es la responsable de que el LSP sea
establecido para que sea funcional mediante el intercambio de etiquetas entre los nodos
de la red. La arquitectura MPLS no asume un único protocolo de distribución de
etiquetas; de hecho se están estandarizando algunos existentes con las correspondientes
extensiones como son RSPV y LDP.
30
Parte II
Principios y Bases Teóricas
31
Capítulo 4
Constraint Shortest Path First (CSPF)
4.1 Principios básicos de CBR
Para poder entender el concepto de Constraint Based Routing (CBR), debemos
mirar primero al sistema de ruteo convencional usado en redes IP, como la Internet. Una
red es modelada como una colección de Sistemas Autónomos (AS), donde las rutas
dentro de un AS son determinadas por ruteo intradominio y las rutas que atraviesan
múltiples ASs son determinadas por ruteo interdominio. Ejemplos de protocolos
intradominio son RIP, OSPF y IS-IS. El protocolo de ruteo interdominio usado hoy en día
en redes IP es BGP. Nos enfocaremos de ahora en más al ruteo intradominio ya que
utiliza para el cálculo de los caminos algoritmos que buscan minimizar cierta métrica en
particular, como es el caso de CSPF usado en NET-TE.
La computación de caminos para cualquiera de los protocolos de ruteo
intradominio que mencionamos anteriormente, se basa como ya indicamos, en un
algoritmo que optimiza (minimiza) una métrica escalar en particular. En el caso de RIP,
dicha métrica es el número de saltos. En el caso de OSPF o IS-IS la métrica es la métrica
administrativa de un camino. Esto es, con OSPF (o IS-IS), un administrador de red asigna
a cada enlace en la red una métrica administrativa. Dada la opción de múltiples caminos a
un destino dado, OSPF (o IS-IS) usa el algoritmo de Dijkstra del camino más corto (SPF)
para computar el camino que minimiza la métrica administrativa del camino, donde la
métrica administrativa del camino se define como la suma de las métricas administrativas
en todos los enlaces a lo largo del camino.
La diferencia principal entre el ruteo IP convencional y el ruteo basado en
restricciones (CBR) es la siguiente. Algoritmos de ruteo plano IP intentan encontrar un
camino que optimiza una determinada métrica escalar, mientras que los algoritmos
basados en CBR intentar encontrar un camino que optimice cierta métrica escalar y al
mismo tiempo que no viole un conjunto de restricciones. Es precisamente la habilidad de
encontrar un camino que no viole un conjunto de restricciones lo que distingue al ruteo
basado en restricciones del ruteo plano IP.
Los mecanismos claves necesarios para soportar ruteo basado en restricciones son
a grandes rasgos los enumerados a continuación.
El primer mecanismo que necesitamos es la habilidad de computar un camino,
y de hacerlo de manera tal que no tome sólo en cuenta determinada métrica escalar usada
como criterio de optimización, sino también un conjunto de restricciones que no deben
ser violadas. Esto requiere que la fuente tenga toda la información necesaria para
computar dicho camino.
El segundo mecanismo es la habilidad de distribuir la información sobre la
topología de la red y atributos asociados a los enlaces a través de la red. Esto porque ya
que cualquier nodo en la red es potencialmente capaz de generar tráfico que tenga que ser
ruteado vía ruteo basado en restricciones, la información que usa la fuente para computar
el camino debe estar disponible a cualquier nodo de la red.
32
Una vez computado el camino, también necesitaremos el soportar el envío a
través de dicho camino. Por lo que el tercer mecanismo es aquel que sea capaz de
soportar el ruteo explícito.
Por último, el establecer una ruta para un conjunto particular de tráfico, puede
requerir la reserva de recursos a lo largo de esa ruta, alterando quizás el valor de los
atributos asociados a enlaces individuales de la red. Por lo que el último mecanismo es
uno a través del cual se puedan reservar recursos de la red y sean modificados los
atributos de los enlaces como resultado de cierto tráfico tomando ciertas rutas.
De ahora en más nos basaremos en comentar el algoritmo Constraint Shortest
Path First (CSPF), el cual, como mencionamos anteriormente, es usado por CBR para
computar un camino.
Figura 4.1: Modelo del servicio CBR
4.2 CSPF
Como se dijo anteriormente, CBR requiere la habilidad de computar un camino de
manera tal que
•
•
Sea óptimo respecto a alguna métrica escalar (por ejemplo el minimizar la
cantidad de saltos o un métrica administrativa)
No viole un conjunto de restricciones
Una manera de lograr esos objetivos es usar el algoritmo de shortest path first
(SPF). El algoritmo SPF plano, computa un camino que es óptimo con respecto a cierta
métrica escalar. Entonces, para computar un camino que no viole restricciones, todo lo
que necesitamos es el modificar el algoritmo de manera tal que pueda tomar en cuenta
33
esas restricciones. Nos referiremos a tal algoritmo como constraint shortest path first
(CSPF) (Ver [3] por más información).
Para entender como SPF debe ser modificado para tomar restricciones en cuenta,
miremos primero como es la operación del SPF plano. El algoritmo SPF plano trabaja
empezando de un nodo llamado raíz, y creando luego a partir del mismo, una estructura
en forma de árbol que contiene el camino más corto. En cada iteración del algoritmo, hay
una lista de posibles nodos “candidatos” (inicialmente esta lista contiene sólo a la raíz).
En general, los caminos de la raíz a los nodos candidatos no son los más cortos. Sin
embargo, para el nodo candidato que esta más cerca de la raíz (con respecto a la distancia
usada por SPF), el camino a ese nodo es el más corto garantizadamente. Entonces, en
cada iteración, el algoritmo toma de la lista de candidatos, al nodo con la distancia más
corta a la raíz. Este nodo es entonces agregado al árbol del camino más corto y removido
de la lista de nodos candidatos. Una vez que el nodo ha sido agregado al árbol del camino
más corto, los nodos que no están en el árbol, pero son adyacentes a ese nodo, son
examinados para una posible adición o modificación de la lista de candidatos. El
algoritmo entonces itera nuevamente. Para el caso en donde se desee encontrar el camino
más corto de la raíz a todo el resto de los nodos, el algoritmo termina cuando la lista de
candidatos esta vacía. Para el caso en que se desee simplemente encontrar el camino más
corto de la raíz a algún otro nodo especifico, el algoritmo termina cuando este otro nodo
es agregado al árbol del camino más corto.
Figura 4.2: Proceso de computación del CSPF
En la Figura 4.2 se puede apreciar el proceso total de computación del algoritmo
CSPF. Vale destacar que la TED es la Base de Datos de Ingeniería de Tráfico, la cual
provee a CSPF con información actual sobre la topología de la red.
Dadas las operaciones del SPF plano, es bastante sencillo el observar la
modificación que debemos hacerle al mismo de manera de convertirlo a CSPF. Todo lo
que tenemos que hacer es modificar el paso que maneja la adición o modificación de la
lista de candidatos. Específicamente, cuando agregamos un nodo al árbol del camino más
corto y nos fijamos en los enlaces adyacentes a ese nodo, nos fijamos primeramente si
34
esos enlaces satisfacen todas las restricciones planteadas. Sólo si el enlace satisface todas
las restricciones, recién ahí examinamos el nodo que esta ubicado en el otro extremo del
enlace.
En general, el procedimiento por el cual chequeamos si un enlace satisface una
restricción en particular, es específico de la naturaleza de la restricción. Por ejemplo,
cuando la restricción que queremos satisfacer es al ancho de banda disponible, entonces
el chequeo es si el ancho de banda disponible en el enlace es mayor o igual al ancho de
banda especificado por la restricción; sólo si lo es, es que examinamos el nodo ubicado
en el otro extremo del enlace.
También observar que el chequear si un enlace satisface una restricción en
particular, asume que hay una información de restricción relacionada, asociada con el
enlace. La naturaleza de esta información relacionada a la restricción. Por ejemplo,
cuando la restricción que queremos satisfacer es el ancho de banda disponible, la
información que necesitamos es tener al ancho de banda disponible en un enlace.
Notar que el algoritmo CSPF requiere que el router que realiza la computación del
camino, tenga información sobre todos los enlaces en la red. Esto impone una restricción
en el tipo de protocolo de ruteo que podemos usar para soportar el ruteo basado en
restricciones (CBR). Tenemos que usar protocolos de estado de enlace como IS-IS u
OSPF, ya que protocolos de ruteo de vector distancia como RIP no son capaces de
encontrar estos requerimientos.
Como comentario sobre uno del resto de los mecanismos restantes necesarios para
soportar CBR, la capacidad de ruteo explícito necesaria es provista por MPLS.
En el caso del software NET-TE en este proyecto, se utilizó CSPF para computar
los caminos para los LSPs obligando a que cumplan ciertos requerimientos. El
requerimiento usado en este proyecto fue el ancho de banda disponible en cada enlace de
la red. Además se le agregó la posibilidad de que el usuario pueda obligar al LSP hayado
que pase por cierto enlace de la red así como que no pase por otro en particular. La razón
por la cual se puede desear querer obligar que un LSP pase por cierto enlace y no lo haga
por otro depende totalmente del usuario y de la forma en que él gestione su red. Además
es importante destacar que con respecto a los pesos asignados a los enlaces al momento
de correr el SPF, se le ofrece al usuario la oportunidad de usar distintos pesos,
dependiendo de cual sea la métrica en la que él este interesado de usar (por ejemplo la
cantidad mínima de saltos, minimizar los pesos administrativos asignados por el mismo a
los enlaces o hacer la métrica en función del ancho de banda disponible en los enlaces,
entre otros).
4.3 Ruteo basado en QoS. WSP y SWP.
El ruteo basado en QoS ha sido un área de investigación muy activa por muchos
años. Selecciona rutas en la red que satisfagan la QoS requerida para una conexión o
grupo de conexiones. Además, el ruteo basado en QoS logra una eficiencia global en la
utilización eficiente de los recursos. Un ejemplo de esto es al algoritmo ShortestWidest-Path (WSP), el cual usa al ancho de banda como una métrica y selecciona los
caminos que tienen un cuello de botella de ancho de banda mayor. El cuello de botella de
35
ancho de banda representa la capacidad mínima no usada de todos los enlaces en el
camino. En el caso de dos caminos con el mismo cuello de botella de ancho de banda, el
camino con la mínima cantidad de saltos es seleccionado (Ver [4] por más información).
Los algoritmos de ruteo usados en CBR y la complejidad de los mismos, depende
del tipo y del número de métricas que son incluídas en el cálculo de la ruta. Algunas de
las restricciones pueden ser contradictorias (por ejemplo costo vs. ancho de banda, delay
vs. throughput). Resulta que el ancho de banda y la cuenta de saltos son en general
restricciones más útiles en comparación con el delay y jitter, ya que muy pocas
aplicaciones no pueden tolerar una ocasional violación de dichas restricciones, y como el
delay y jitter se pueden determinar por medio del ancho de banda alojado y número de
saltos del camino donde va el flujo, éstas restricciones pueden ser mapeadas en
restricciones de ancho de banda y número de saltos, en caso de ser necesario. Otro factor
es que muchas aplicaciones en tiempo real requieren un determinado ancho de banda. El
número de saltos de una ruta también es una métrica importante, ya que cuantos más
saltos atraviese un flujo, más recursos consumirá.
Con las implementaciones básicas del esquema de CBR, hay una especie de
balance y equilibrio entre la conservación de recursos y el balance de carga. Un esquema
de CBR puede seleccionar de las siguientes opciones para un camino viable para un flujo:
•
•
•
Shortest-Distance Path (SDP): éste acercamiento es básicamente el mismo
que el ruteo dinámico. Hace énfasis en preservar los recursos de la red por
medio de la selección de los caminos más cortos.
Widest-Shortest Path (WSP): éste acercamiento hace énfasis en balancear
la carga por medio de la elección de caminos más “anchos” en cuanto al ancho
de banda. Encuentra caminos con el mínimo número de saltos y, si encuentra
múltiples caminos, se queda con el que tiene ancho de banda mayor.
Shortest-Widest Path (SWP): éste acercamiento hace una especie de
intercambio entre los dos extremos. Favorece a los caminos más cortos
cuando la carga de la red es pesada y a los caminos más “anchos” cuando la
carga de la red es moderada. Encuentra un camino con el ancho de banda más
grande y, en caso de haber múltiples caminos, se queda con el que tiene la
mínima cantidad de saltos.
En los últimos dos casos se consumen más recursos, lo cual no es eficiente
cuando la utilización de la red es alta. Se debe hacer un balance o equilibrio entre la
conservación de recursos y el balance de carga (Ver [5] por más información).
Vale hacer notar en este momento, que cualquiera de las 3 opciones superiores se
pueden implementar en el software NET-TE, combinando correctamente la elección del
tipo de pesos para los enlaces con la elección del criterio de TE.
36
Capítulo 5
Minimum Interference Routing
Algorithm (MIRA)
5.1 Presentación del algoritmo
La idea de éste tipo de algoritmos es la de minimizar la “interferencia” que
provoca el establecimiento de un nuevo LSP a potenciales nuevos LSPs que son
desconocidos. Mapear un LSP en la red puede reducir el máximo ancho de banda
disponible entre algunos pares de nodos ingreso-egreso críticos en la red, dependiendo de
por dónde se dirija el mismo. Este fenómeno es conocido como “interferencia”. Esto nos
lleva a pensar que si los caminos que reducen la cantidad de ancho de banda disponible
entre otros nodos ingreso-egreso son evitados, entonces la creación de los cuellos de
botella puede ser evitada también.
Para llevar a cabo esto, se asocia a cada enlace de la red un peso y luego se aplica
SPF a la red. Este peso es proporcional a cuán crítico es el enlace para el establecimiento
de LSPs entre pares de nodos ingreso-egreso. De esta manera futuras demandas entre
estos nodos tendrán baja probabilidad de ser rechazadas.
En este tipo de algoritmos es necesario conocer la topología actual y las
capacidades disponibles. Se asume que la topología es conocida administrativamente o
que un protocolo de ruteo de estado de enlace está operacional (OSPF, IS-IS, etc.) y que
la base de datos de los estados de los enlaces es accesible. Además, desde cierto nodo
ingreso, pueden ser permitidos LSPs a ciertos egresos solamente Esto se debe por
ejemplo a restricciones de política o de servicio. Toda información de este tipo es
conocida, y se asume que no varía frecuentemente.
Existen varios trabajos respecto a algoritmos que disminuyen la interferencia,
pero el algoritmo que implementamos en nuestro software esta basado en el algoritmo
MIRA (por más información ver Referencias [6] y [7]).
En la Figura 5.1 se muestra en que casos éste tipo de algoritmo soluciona los
problemas causados por los algoritmos clásicos como el min-hop algorithm.
37
Figura 5.1: Ejemplo de uso del MIRA
Consideramos que los nodos ingreso-egreso son (A, G), (B, G), (C, G). Se puede
dar la situación en que se necesiten varios LSPs entre (A,G) y se utiliza el enfoque de
min-hop los LSPs serán mapeados en el camino con menor cantidad de saltos, saturando
los enlaces A-D y D-G y bloqueando futuras demandas entre (B,G) y (C,G), siendo lo
ideal un algoritmo que tenga en consideración lo crítico que son estos enlaces en éstas
futuras demandas, de modo de mapear la demanda entre (A,G) por A-E-F-G aunque éste
camino sea más largo (en lo que a número de saltos se refiere).
5.2 Modelado del sistema
Se considera una red de n nodos representados por un grafo G = (V, E), donde V
es el conjunto de nodos en la red y E el conjunto de m enlaces de la red. Un subconjunto
de estos nodos es considerado como nodos ingreso-egreso de futuras demandas y se
denota a este subconjunto como L. Sin embargo, no es necesario conocer este
subconjunto para que el algoritmo funcione, ya que se puede considerar que L=V de
modo que cada par de nodos pueden ser los nodos ingreso-egreso para futuras demandas.
La capacidad disponible R (l) de cada enlace l se asume conocida (mediante alguna
extensión del protocolo de enlace de estado operacional).
5.3 Algoritmo propuesto
El pseudo código del algoritmo para el establecimiento de un LSP entre (s, d) se
presenta a continuación:
1- Calcular el MNF (Maximum Network Flow) entre todos los pares ingreso-egreso
(s' , d ') ∈ L .
2- Calcular el peso w(l) para todos los enlaces l ∈ E .
38
3- Eliminar todos los enlaces que tienen ancho de banda disponible menor al
requerido por el LSP y formar una nueva topología con los nodos y enlaces
restantes.
4- Correr SPF con la topología reducida.
5- Establecer el LSP entre (s, d ) y actualizar los anchos de banda disponible en cada
enlace.
Específicamente, dada una nueva demanda entre (s, d ) , se considera el impacto
de mapear esta demanda en futuras demandas entre nodos ingreso-egreso. Este impacto
es caracterizado al asignarle pesos a los enlaces que pueden ser usados por estas futuras
demandas. Cuando consideramos un par de nodos ingreso-egreso (s ' , d ') ∈ L , primero
calculamos el MNF (maximum network flow) θ s 'd ' [3] entre s’ y d’. El MNF representa
el máximo ancho de banda que puede traficar la red entre el par de nodos (s, d), ya sea
por varios caminos o por uno sólo. Luego para cada enlace l ∈ E se calcula la
f s 'd '
contribución del enlace a este MNF entre s’ y d’ que es representado como ls 'd ' , donde
θ
s 'd '
f l es la cantidad de tráfico de MNF que pasa por l. También se necesita caracterizar el
ancho de nada disponible en el enlace l de modo de incorporar la capacidad de mapear
futuras demandas por el enlace. Hacemos esto calculando la contribución normalizada de
ancho de banda del enlace l como sigue,
f l s 'd '
(5.1a)
θ s 'd ' R(l )
Ésta es la diferencia principal de este algoritmo con respecto a otros, como
versiones anteriores del MIRA, en las cuales sólo se considera si los enlaces son críticos
o no en futuras demandas ( f l s 'd ' =1 ó 0). De ésta manera se considera la importancia del
enlace pero también el cuantificar esta importancia con la contribución normalizada de
ancho de banda.
Luego se asigna a cada enlace el peso total debido a todas las contribuciones de
todos los pares ingreso-egreso (s ' , d ') ∈ L que pueden originar LSPs en el futuro:
w(l ) =
f l s 'd '
∑ s 'd ' R(l ) , l ∈ E
( s ', d ')∈L θ
(5.2a)
Una vez que los pesos son calculados y asignados, se eliminan los enlaces en E
que tienen el ancho de banda disponible menos al requerido por la demanda
obteniéndose una topología reducida con los pesos asignados incambiados. Luego se
corre el SPF basado en Dijkstra para obtener el LSP entre s y d y se actualiza el ancho de
banda disponible en los enlaces que pertenecen al nuevo LSP.
39
Capítulo 6
Redes Justas (“Fair Networks”)
6.1 Introducción
Debido a que la distribución del tráfico en las redes de datos cambia rápidamente,
es complicado para los operadores de una red, el determinar cuándo y dónde incrementar
la capacidad de la misma, lo cual puede llevar a problemas de sobrecarga.
La toma de decisión sobre cuántos usuarios pueden ser atendidos y cuánto tráfico
puede generar cada uno de ellos, es un tema del que se encarga el proceso de admisión de
tráfico. El mismo, es responsable de garantizar que los usuarios tengan un acceso justo a
los servicios de la red, al mismo tiempo de minimizar la probabilidad de negar un
servicio a un cliente.
El determinar cuánto tráfico de cada flujo debe ser admitido por la red y por
dónde rutear al mismo una vez que ingresa, satisfaciendo los requerimientos de alta
utilización de la red y garantizando justicia a los usuarios, es uno de los retos más
grandes en el diseño de las redes de telecomunicaciones de hoy en día.
Así nos encontramos frente a la pregunta de cómo distribuir económicamente
cierto volúmen de demanda sobre una red, bajo cierto conjunto de restricciones de ruteo y
flujo.
La primera hipótesis es que las demandas entre pares de nodos origen-destino,
pueden utilizar cualquier ancho de banda asignado a ellas en términos de sus flujos de
caminos, quizás bajo ciertos límites.
La pregunta es: ¿qué principio debemos seguir al alojar las demandas entre los
recursos que la red tiene pare ofrecer, de manera de cumplir con algún criterio de
justicia?
Una primera solución que se nos podría ocurrir es asignar la mayor cantidad de
recursos a cada demanda, al mismo tiempo que se intenta mantener los recursos
asignados lo más similares posible. Esto nos lleva al principio de asignación llamado
Max-Min Fairness (MMF), usado para formular el esquema de asignación de recursos
(Ver [10] por más información).
La noción de justicia se presenta en el contexto de redes basadas en el intercambio
de paquetes, transportando demandas elásticas entre pares de nodos. Con elasticidad nos
referimos a que cada demanda puede consumir cualquier ancho de banda agregado
asignado a sus caminos individuales, quizás dentro de determinados límites predefinidos.
En las próximas secciones de éste capítulo mostraremos los enunciados
principales de los problemas MMF, analizando cómo usar sus nociones para expresar la
justicia en el proceso de admisión de tráfico. Se presentarán los cuatro diferentes métodos
que fueron implementados en el software NET-TE.
40
*La información, así como los enunciados y métodos presentados en éste
capítulo, fueron extraídos del libro "Routing, Flow and Capacity Design in
Communication and Computer Networks", de Michal Pioro y Deepankar Medhi [10].
6.1.1
Nociones de Justicia
Consideremos una red con demandas elásticas. Un problema general con este tipo
de redes es cómo asignar flujos (BW) a los caminos de las demandas, de manera que las
capacidades de los links no son excedidas y que los actuales volumenes de ancho de
banda agregado asignados a las demandas sean distribuídos de una manera justa.
6.2
Algoritmo 1: Max-Min Fairness básico para
caminos fijos
Consideremos una red con enlaces de capacidades fijas y con caminos prefijados
únicos asignados para transportar los flujos de las demandas (o sea que en caso de existir
varios caminos posibles entre determinado par de nodos, nos quedamos solamente con
uno sólo de ellos, pudiendo éste ser elegido por el usuario a su gusto).
Antes de seguir con el planteo del primer método utilizado de asignación justa de
recursos, debemos introducir una definición:
Definición 6.1:
Un vector de n componentes x = (x1, x2,…, xn) ordenado en orden ascendente (x1 ≤ x2 ≤…
≤ xn) es lexicográficamente mayor que otro vector de n componentes y = (y1, y2,…, yn)
ordenado ascendentemente (y1 ≤ y2 ≤… ≤ yn) si existe un índice k, 0 ≤ k ≤ n, tal que xi = yi
para i=1, 2,…, k y xk > yk.
Ahora presentemos la formulación del primer algoritmo.
Índices
d = 1, 2,…, D demandas
e = 1, 2,…, E enlaces
Constantes
δ ed = 1 si el enlace e pertenece al camino fijo de la demanda d; 0 en otro caso
ce Capacidad del enlace e
Variables
xd Flujo asignado a la demanda d, x = (x1, x2,…, xD)
Objetivo
Hayar el vector de asignación x, el cual, cuando ordenado en orden ascendente, es
lexicográficamente máximo entre todos los vectores de asignación ordenados en orden
ascendente.
41
Restricciones
∑δ
ed
xd ≤ ce
e = 1, 2,..., Ε
(6.2.1a)
d
x≥0
(6.2.1b)
Obviamente, como es simple de ver, la ecuacion (6.2.1a) quiere decir que, para
cada enlace, la suma de los anchos de banda de cada demanda que pase por ese enlace, no
puede ser mayor que la capacidad de dicho enlace, lo cual es razonable.
De acuerdo a la Definición 6.1, la solución x* de éste problema tiene la propiedad
de que para cualquier otro posible vector x = (x1, x2,…, xD), cuando ambos vectores están
ordenados ( xi*(1) ≤ xi*(2) ≤ ... ≤ xi*( D )
y
x j (1) ≤ x j (2) ≤ ... ≤ x j ( D ) ) entonces existe un índice
d, 0 ≤ d ≤ D, tal que xi*(l ) = x j (l ) para l = 1, 2,…, d y xi*( d +1) > x j ( d +1) .
Para establecer la equivalencia de la caracterización lexicográfica de la solución
óptima al problema MMF/FIXSP (Max-Min Fairness for Fixs Paths; problema que
estamos actualmente analizando) con una caracterización justa max-min más conocida,
para el caso considerado de camino fijo único, debemos introducir a continuación una
nueva definición y proposición.
Definición 6.2
Un posible vector de asignación de flujo x que satisfaga (6.2.1a y 6.2.1b) es max-min
justo si para cada demanda d existe un enlace saturado e ( ∑ δ ed xd = ce ) perteneciente al
d
camino que satisface la demanda d ( δ ed = 1 ) de manera tal que el flujo xd es máximo en e
( xd = max { xd ' : d ' = 1, 2,..., D; δ ed ' = 1}) .
Proposición 6.1
Un vector de asignación x* resuelve el problema anterior si y sólo si es max-min justo en
el sentido señalado por la Definición 6.2. La solución x* de este problema es única.
Finalmente, la formulación completa del problema de MMF con caminos fijos
únicos es la siguiente:
6.2.1 Formulación completa del Algoritmo 1:
Variables
xd
ued
ze
flujo asignado a la demanda d
variable auxiliar binaria, ued = 0 si el enlace e pertenece al camino de la
demanda d, e esta saturado y xd es máximo en e; ued = 1 en cualquier otro
caso
variable auxiliar del flujo para el enlace e
42
Restricciones
∑δ
ed
xd ≤ ce
∑δ
ed
(1 − υed ) ≥ 1
e = 1, 2,..., Ε
(6.2.2a)
d
(6.2.2b)
d = 1, 2,..., D
e
υed ce ≥ ce − ∑ δ ed ' xd '
e = 1, 2,..., Ε
(6.2.2c)
d ' = 1, 2,..., D
d'
υed ce ≥ ze − xd
xd ≥ ze
e = 1, 2,..., Ε
e = 1, 2,..., Ε
d = 1, 2,..., D
d = 1, 2,..., D
y
y
δ ed = 1
δ ed = 1
(6.2.2d)
(6.2.2e)
con todas las xd y ze continuas no negativas y todas las ued binarias (6.2.2f)
Como comentarios que podemos hacer al respecto de la formulación de las
ecuaciones anteriores, si observamos la ecuación (6.2.2b) podemos ver que lo que
básicamente quiere decir es que para cada demanda, si consideramos sólo los enlaces que
la conforman, existe alguno para el cual ued es igual a 0, lo cual implica que ése enlace e
está saturado y xd es máximo en el mismo (dicho de otra manera, que llegué a obtener al
mayor ancho de banda posible para ésa demanda y me doy cuenta de ello, ya que alguno
de los enlaces que conforman la demanda saturó ya). Luego, la ecuación (6.2.2c),
básicamente nos hace ver que si ued es igual a cero para un determinado enlace, entonces
la parte de la derecha de ésa ecuación es cero también, indicando que ya ha saturado el
enlace, debido a que la suma de todos los anchos de banda de todas las demandas que
pasan por el mismo ha igualado a su capacidad. Finalmente, de las ecuaciones (6.2.2d) y
(6.2.2e) sacamos que si ued es igual a cero, entonces xd = max{xd’: d’=1,2,…D, y
δ ed ' = 1 } (dicho en otras palabras, si ued=0 entonces xd es el máximo flujo en el enlace e.
Por ende, usando la Preposición 6.1, el problema (6.2.2) tiene una solución única
x* = ( x1* , x2* ,..., xD* ) , idéntica a la solución inicial del problema (6.2.1)).
Finalmente, el único vector justo max-min (máximo vector de asignación
lexicográfico) x* = ( x1* , x2* ,..., xD* ) , puede ser hayado usando el siguiente algoritmo 1.
6.2.2 Pasos para resolver el Algoritmo 1
Paso 0:
Poner x* = 0
Paso 1:


t := min ce / ∑ δ ed : e = 1, 2,..., E 
d


Paso 2:


ce := ce − t  ∑δed 
d

para
e = 1,2,..., E;
43
xd* := xd* + t
para
d = 1,2,..., D
Remover todos los enlaces saturados (todos los enlaces e con ce=0). Para
cada enlace removido e, remover todos los caminos y correspondientes
demandas que usan ese enlace removido (todas las d con δ ed = 1 ).
Paso 3:
Si no queda ninguna demanda más, entonces detenerse. En caso
contrario ir al paso 1.
Observar que la cantidad t calculada en el paso 1, es la solución del siguiente
problema de programación lineal (LP):
maximizar
t
(6.2.3a)
sujeto a


t  ∑ δ ed  ≤ ce
 d

e = 1, 2,..., E
(6.2.3b)
Esa observación nos permitirá a nosotros extender la noción y solución de algoritmos
para problemas más generales MMF como el que veremos más adelante.
6.3
Algoritmo 2: Max-Min Fairness para
caminos fijos con cotas
Ahora seguiremos considerando el caso del MMF para caminos fijos, pero
agregándole ahora pesos a las demandas y cotas superior e inferior a los flujos asignados
a esas demandas.
6.3.1
Formulación del Algoritmo 2:
Índices
d = 1, 2,…, D demandas
e = 1, 2,…, E enlaces
Constantes
δ ed = 1 si el enlace e pertenece al camino fijo de la demanda d; 0 en caso
contrario
ce
capacidad del enlace e
wd
peso de la demanda d
hd
límite inferior para el flujo de la demanda d
Hd
límite superior para el flujo de la demanda d
Variables
xd
flujo asignado a la demanda d, x = (x1, x2,…, xD)
Objetivo
Encontrar el vector de asignación x, el cual, cuando está ordenado en orden
ascendente, es lexicográficamente máximo entre todos los vectores de asignación
ordenados ascendentemente.
44
Restricciones
hd ≤ xd ≤ H d
∑δ
ed
d = 1, 2,..., D
wd xd ≤ ce
(6.3.1a)
(6.3.1b)
e = 1, 2,..., E
d
(6.3.1c)
x≥0
En la restricción (6.3.1b) la carga del enlace e inducida por el flujo xd es igual a
δ ed wd xd , lo cual implica que el flujo actual asignado a la demanda d es igual a wdxd.
Debido a la presencia de límites inferiores, el problema se puede tornar irresoluble.
La solución al problema del Algoritmo 2 (MMF/EFIXSP), x* = ( x1* , x2* ,..., xD* ) ,
puede ser encontrada usando el algoritmo 6.3.2 que enunciaremos a continuación. Este
algoritmo es similar al algoritmo 6.2.2 visto anteriormente. Hace uso también del
siguiente problema LP:
6.3.2
Paso 0:
maximizar
t
(6.3.2a)
sujeto a


t  ∑ wd δ ed  ≤ ce
 d

e = 1, 2,..., E
(6.3.2b)
Pasos para resolver el Algoritmo 2:
Poner xd* = hd para d = 1, 2,…, D y
ce := ce − ∑δ ed wd hd
para
e = 1, 2,..., E;
d
Paso 1:
Paso 2:
Paso 3:
Remover todos los enlaces saturados (todos los e con ce = 0). Para cada
enlace removido e remover todos los caminos y correspondientes
demandas que usan el enlace removido (todas las d con δ ed = 1 ).
Resolver el problema LP (6.3.2) para obtener t.


ce := ce − t  ∑ δ ed wd 
 d

para
e = 1, 2,..., E;
xd* := xd* + t
para
d = 1, 2,..., D
Remover todos los enlaces saturados (todos los e con ce=0). Para cada
enlace removido e remover todos los caminos y correspondientes
demandas que usen el enlace removido (todas las d con δ ed = 1 ).
Si no quedan más demandas entonces detenerse. En caso contrario ir al
paso 1.
45
Observación
La implementación de este algoritmo consiste básicamente en agregar un enlace
y nodo ficticio para cada demanda, de manera de asegurarse que por dicho enlace pase
solamente ésa demanda en particular. O sea que cada demanda tendrá un enlace y nodo
ficiticio propio de ella. La capacidad de dicho enlace ficticio será igual al ancho de banda
requerido para la demanda en cuestión. De esta manera, nos aseguramos que el ancho de
banda no se aumente más que el ancho de banda requerido por el usuario. Es una manera
de poner un tope superior al ancho de banda.
En las próximas secciones consideraremos un problema más general para MMF,
que involucrará optimización simultánea de caminos y flujos. Nos referimos a este tipo
de problemas como problemas de caminos flexibles, en contraste con los problemas de
caminos fijos vistos hasta ahora. En particular, el problema analizado a continuación es
con capacidades para caminos flexibles.
Se considerará ahora el caso donde múltiples caminos son posibles candidatos en
la lista de ruteo asignada a cada demanda. Esto implica por ende que, los flujos que
satisfacen el volumen de cada demanda son divididos entre los posibles caminos, lo cual
resultará, en general, en un vector de asignación lexicográficamente mayor que el que
resuelve el caso de los caminos fijos.
6.4
Algoritmo 3: Max Min Fairness para
múltiples caminos
El siguiente problema es para múltiples caminos flexibles (MMF/FLMP, MaxMin Fairness for Flexible Multiple Paths).
Índices
d = 1, 2,…, D
p = 1, 2,…, Pd
e = 1, 2,…, E
demandas (pares de nodos)
caminos candidatos para la demanda d
enlaces
Constantes
δ edp = 1 si el enlace e pertenece al camino p de la demanda d; 0 en caso contrario
ce
Variables
xdp
Xd
XD)
capacidad del enlace e
flujo (ancho de banda) asignado al camino p de la demanda d
flujo total (ancho de banda) asignado a la demanda d, X = (X1, X2,…,
46
Objetivo
Encontrar el vector de asignación de flujo total X, el cual, cuando ordenado en
orden ascendente, es lexicográficamente máximo entre todos los vectores de
asignación ordenados en orden ascendente.
Restricciones
∑ xdp = X d
d = 1, 2,..., D
(6.4.1a)
p
∑∑ δ
d
x = ce
edp dp
e = 1, 2,..., E
(6.4.1b)
p
todos los xdp ≥ 0.
(6.4.1c)
El problema con el que ahora tratamos es más difícil de resolver que su
contraparte de camino único MMF/FIXSP, debido a que ahora las soluciones de la
apropiada extensión al problema LP (6.2.3) son, en general, no únicas. La extensión es
como sigue.
maximizar
sujeto a
t
(6.4.2a)
X d = ∑ xdp
d = 1, 2,..., D
p
t − Xd ≤ 0
∑∑ δ
d
d = 1, 2,..., D
x = ce
edp dp
e = 1, 2,..., E
p
todos los xdp ≥ 0
(6.4.2b)
(6.4.2c)
(6.4.2d)
(6.4.2e)
La función objetivo (6.4.2a), junto con la restricción (6.4.2c) es equivalente al
objetivo en el que estamos interesados en realidad:
maximizar
min {Xd : d = 1, 2,…, D}
Eso se debe a que por la ecuación (6.4.2c), si queremos maximizar t, esto
equivale a querer maximizar el mínimo de Xd. Es decir, max{t, t- Xd ≤ 0, d: 1,2,…D} =
max min{ Xd, d:1,2,…D}.
El problema (6.4.2) puede tener múltiples soluciones.
La solución de MMF/FLMP, tal como el Algoritmo 3 que se expondrá a
continuación es substancialmente más complicada. Consiste también en una aplicación
iterativa de una extensión del problema LP (6.4.2), pero el uso de la extensión incluye un
47
paso que chequea qué demanda de asignación Xd puede seguir siendo incrementada sin
afectar al resto de las demandas.
La eficacia del Algoritmo 3 depende de la eficiencia del test de no bloqueo (NBT)
usado en el Paso 1. El test llamado NBT1 consiste en resolver el siguiente problema LP
para cada demanda fija d ∈ Z1:
maximizar
Xd
(6.4.3a)
sujeto a
X d ' = ∑ xd ' p
d ' = 1, 2,..., D
(6.4.3b)
p
td ' − X d ' ≤ 0
∑∑ δ
d'
x
ed ' p d ' p
d ' = 1, 2,..., D
≤ ce
e = 1, 2,..., E
p
todos los xd ' p ≥ 0
(td ' − const ) (6.4.3c)
(6.4.3d)
(6.4.3e)
6.4.1 Pasos para resolver el Algoritmo 3 (usando NBT1):
Paso 0:
Resolver el problema LP (6.4.2) y nombremos (t*, x*, X*) a la
solución óptima del mismo. Pongamos n := 0, Z0 := ∅ , Z1 := {1, 2,…,
D}, y td := t* para cada d ∈ Z1.
Paso 1:
Pongamos n := n + 1. Empecemos considerando las demandas d ∈ Z1 una
por una, para chequear si el volumen total de asignación X d* puede hacerse mayor a t*,
sin decrementar las máximas asignaciones ya encontradas td’ para el resto de todas las
demandas d’. El chequeo es llevado a cabo por un test de no bloqueo (6.4.3). Si no hay
demandas que bloqueen en Z1 (demanda d ∈ Z1 se considera que bloquea, si Xd no puede
incrementarse más) entonces ir al Paso 2. En caso contrario, cuando la primer demanda
que bloquee se encuentre, digamos demanda d, agregar d al conjunto Z0 y borrarla del
conjunto Z1 (Z0 := Z0 ∪ {d}, Z1 := Z1\{d}). Si Z1 = ∅ , entonces detenerse (el vector
X * = ( X 1* , X 2* ,..., X D* ) = (t1 , t2 ,..., t D ) es la solución para el Problema (6.4.1); en caso
contrario proceder al Paso 2.
Paso 2:
Solucionar el problema LP siguiente (modificación del (6.4.2)) para
mejorar las mejores asignaciones totales actuales:
maximizar
t
48
sujeto a
X d = ∑ xdp
d = 1, 2,..., D
(6.4.4a)
p
t − Xd ≤ 0
td − X d ≤ 0
∑∑ δ
d
edp
d = Z1
d = Z0
(td − const )
e = 1, 2,..., E
(6.4.4b)
(6.4.4c)
(6.4.4d)
p
xdp ≤ ce
(6.4.4e)
todos los xdp ≥ 0
(6.4.4f)
Nombremos (t*, x*, X*) a la solución de (6.4.4). Pongamos td := t* para cada d ∈
Z1 y vayamos entonces al Paso 1 nuevamente.
Observar que puede suceder que la solución óptima de (6.4.4) no incremente al t*
porque puede que haya más demandas que bloqueen además de la detectada en el Paso 1.
La salida de NBT1 (6.4.3) es positiva, lo cual significa que la demanda d es no
bloqueadora si el óptimo Xd es estrictamente mayor que t*. En otro caso, la demanda
considerada resulta ser bloqueadora en realidad. Notar también que la solución de NBT1
para algunos d ∈ Z1 puede mostrar que para algunas otras d’ ∈ Z1 el volumen resultante
Xd’ es mayor que t*. Esas demandas d’ son no bloqueadoras y no necesitan de tests
separados. Los cálculos deben ser realizados usando la solución resultante del Paso 0 (o
Paso 2) como solución inicial de NBT1 para cada d ∈ Z1.
Cerramos finalmente esta sección con la siguiente proposición.
Proposición 8.2:
El vector final de volumenes de asignación total X * = ( X 1* , X 2* ,..., X D* ) , que
resulta de la solución del Problema (6.4.4) obtenida en la última iteración del Algoritmo
3, es único.
6.5
Algoritmo 4: Max Min Fairness para
múltiples caminos acotado
El siguiente problema es para múltiples caminos flexibles (MMF/FLMP, MaxMin Fairness for Flexible Multiple Paths).
La idea detrás de este algoritmo es la siguiente. Es básicamente el mismo
algoritmo que el expuesto anteriormente. La principal diferencia es que se detiene una
vez que se llega a obtener el ancho de banda requerido por el usuario. En el algoritmo
anterior, se veía cuánto era la mayor cantidad de recursos que la red me podía ofrecer
49
para cada demanda, determinando a su vez cuánta carga llevaría cada sub-demanda. En
este caso lo que se hace, es una especie de tratamiento sobre el resultado arrojado por el
algoritmo 3. Se toman todas las demandas y sus respectivas sub-demandas (resultados
obtenidos del algoritmo 3), y se ordenan de mayor a menor, según el ancho de banda que
portan. Supongamos que analizamos primero la primer demanda. Tenemos ya sus subdemandas ordenadas de mayor a menor. Entonces comparamos el ancho de banda que
lleva la primer sub-demanda con el ancho de banda requerido (valor dado por el usuario).
En caso que el ancho de banda de la sub-demanda ya sea mayor que el requerido para la
demanda número uno, se resta el ancho de banda requerido al que porta la sub-demanda y
se descartan el resto de las sub-demandas (ya que al ancho de banda requerido ya fue
satisfecho). Ahora, en caso de no ser mayor, se prosigue a la siguiente sub-demanda y se
ve si el ancho de banda de la primer sub-demanda conjuntamente con el que lleva la
segunda sub-demanda es mayor o no que el requerido. En caso de serlo se descartan el
resto de las sub-demandas y se realiza la resta. Sino, se prosigue de la misma manera, una
y otra vez.
Este proceso se repite para todas las demandas.
Como vemos entonces, los pasos para resolver el algoritmo 4 son los mismos que
los usados en el algoritmo 3. La única diferencia es que se hace un tratamiento de los
resultados arrojados por el algoritmo 3 de manera de, en caso de ser suficiente el ancho
de banda que porta cada demanda, detenerse en cuanto se llega al valor del ancho de
banda requerido.
50
Parte III
Arquitectura de Software
51
Capítulo 7
Representación de la red e
interacción con ARCA
En los próximos capítulos presentaremos la estructura en la que fue creado el
software NET-TE. Se presentarán los packages utilizados y especificará las principales
tareas de las clases que los conforman, así como su implementación.
El orden en el que se presentaran los packages será el siguiente.
En un principio, se empezará en este Capítulo 7 con el Package correspondiente a
la topología de la red en donde se presentarán los elementos que la constituyen así como
una breve descripción de los mismos. En una diferente sección dentro de este mismo
capítulo, también se presentará al package encargado de la interacción con el ARCA. El
mismo tiene como objetivo el poder crear un área común entre ambas aplicaciones para
poder así utilizar el archivo de salida del ARCA como entrada al nuestro y que exista así,
compatibilidad entre ambas aplicaciones.
Pasamos posteriormente a presentar en el Capítulo 8 al Package Programa. El
mismo se encarga de la interfaz gráfica de la aplicación. Se encarga de ofrecerle al
usuario, por medio del modo gráfico, la manera de acceder a las distintas funcionalidades
del software, como ser ingresar la topología manualmente, configurar los parámetros de
los enlaces, desplegar los LSPs ya creados y eliminar los que se desee, obtener
información sobre el porcentaje de utilización de cada enlace en la red y observar de
manera gráfica por medio de la diferenciación de colores los distintos rangos de
utilización que el usuario desee analizar, etc.
Luego en el Capítulo 9 describimos el Package Cargar Red, encargado de
implementar la funcionalidad de cargar la topología de la red sobre la cual se esta
trabajando de manera automática.
Más adelante, en el Capítulo 10, presentamos el Package Crear LSPs, que es
donde se implementa el algoritmo CSPF de computación de caminos para hayar los
LSPs.
Por último, en el Capítulo 11, se trata el Package MT, el cual se encarga de crear
o cargar (en caso de que exista una ya creada) la matriz de tráfico de la red, en donde el
usuario especifica todos las demandas representadas por los pares origen-destino, para
luego darla como parámetro de entrada a los algoritmos de redes justas y MIRA.
7.1 El Package topología
Una parte fundamental del presente proyecto consistió en abstraer la arquitectura
de la red en estudio y representarla de una manera simple mediante un conjunto de
clases.
52
El package Topología fue el primer package desarrollado en el proyecto y en él
se encuentran las clases con las que representamos los elementos de una red MPLS,
que cuenta con los atributos necesarios para poder aplicar algoritmos de TE.
En la Figura 7.1 podemos ver el diagrama UML del package.
Figura 7.1: Diagrama UML del package Topología
A continuación se describe más en detalle las clases anteriormente mencionadas.
53
7.2 La clase Elemento
Esta clase define un objeto Elemento del cual heredarán los objetos LER, LSR y
Link y define los atributos comunes a ellos. Esto sirve para poder referirnos a estos
objetos como si fueran de la clase Elemento, y mantener así un nivel de abstracción.
7.3 Las clases LER y LSR
Los LERs y LSRs representan dentro de nuestra arquitectura de red un elemento
de poca complejidad, ya que cada instancia de ellos sólo lleva registros de los enlaces
que en él convergen y los LSPs que por él pasan. Debido a esto es que cuando el usuario
crea un nuevo nodo en la red no se desplegará ninguna ventana de configuración.
Aunque las clases LER y LSR son muy similares, al tomar nuestro proyecto
como referencia las redes MPLS es que se decidió crear dos clases por separado y no una
sola, logrando por ejemplo que la representación en la interfaz gráfica sea distinta.
7.4 La clase Link
La clase Link es el elemento fundamental de nuestra arquitectura de red. Esta
clase concentra la mayoría de los atributos necesarios para hacer TE como ser
capacidad, capacidad reservada, pesos administrativos, afinidades, etc. Cada instancia de
Link representa una conexión bidireccional entre dos instancias de LER o LSR que recibe
en su construcción y lleva un registro de los LSPs que por él pasan.
La clase Link cuenta con métodos que permiten determinar si es un posible
candidato para la creación de un nuevo LSP basado en el ancho de banda que tiene
disponible mediante el ruteo explícito o corriendo alguno de los algoritmos desarrollados
en el software.
7.5 La clase LSP
La clase LSP, modela los caminos virtuales, que se pueden establecer en las redes
MPLS y que permiten dirigir un flujo agregado de tráfico. Cada LSP consta de un vector
de links, a la cual se le agrega el Nodo desde el cual se origina el LSP y el ancho de
banda requerido, atributos necesarios a la hora de correr los distintos algoritmos de
SNMP que en el software se implementan.
7.6 El Package Arca.InterfazGráfica
Debido a que este package está exclusivamente relacionado con la compatibilidad
entre el NET-TE y el ARCA, realizamos los comentarios sobre ésta relación en la sección
7.6.1.
54
7.6.1 Compatibilidad con ARCA - Analizador de Redes de
Caminos Virtuales
ARCA es el nombre del software que realizaron Darío Buschiazzo Malveira,
Andrés Ferragut Varela y Alejandro Vázquez Paganini con motivo de su proyecto de fin
carrera para el Instituto de Ingeniería Eléctrica de la Facultad de Ingeniería, Universidad
de la República. El proyecto se llevó a cabo en el período comprendido entre el mes de
Junio de 2003 y el mes de Mayo de 2004 en Montevideo, bajo la tutoría del Ing. Pablo
Belzarena.
El proyecto analiza el problema de brindar garantías de Calidad de Servicio
(QoS), así como realizar Ingeniería de Tráfico sobre redes de datos. En dicho proyecto se
desarrolló una herramienta de software que permite relevar el funcionamiento de una red
dada, estimando parámetros de QoS permitiendo predecir el comportamiento de la red en
presencia de carga y evaluar el impacto de diferentes políticas en dicho funcionamiento,
así como conocer las garantías de QoS que la red está en condiciones ofrecer.
Por ser un proyecto que está relacionado con el nuestro, es que se decidió hacer
que sean compatibles en el sentido que un usuario podrá con nuestro software crear
topologías que luego podrán ser usadas en el software ARCA.
Cuando se decide guardar cierta topología con todas sus características (LSPs,
nodos, enlaces, etc.) se abre una ventana en el que el usuario puede elegir guardarla con
formato .txt o con formato .arc (de ARCA). El formato .txt es el formato elegido por
nosotros para guardar las configuraciones, en las que simplemente se escriben en formato
de texto simple los elementos de la red y atributos, que luego son leídos por el software
para representarlas gráficamente. Cuando el usuario elige guardar la topología en formato
.arc (de ARCA) para luego abrirla con el software ARCA, el software llama a un
intérprete que lo que hace es “convertir” las clases de NET-TE en el formato específico
que utiliza el ARCA. De este modo un usuario podrá abrir y guardar archivos en formato
.arc para poder luego utilizarlos en el ARCA.
En la Figura 7.2 podemos apreciar el diagrama UML de este package.
55
Figura 7.2: Diagrama UML del Package Arca.InferfazGráfica
56
Capítulo 8
Interfaz Gráfica
Este capítulo se dedica en su mayoría a la interfaz gráfica de la aplicación. En el
package Programa, se implementan las distintas ventanas que permitirán al usuario el
acceso a las distintas funcionalidades que posee el software. Entre ellas se puede
enumerar por ejemplo todo lo relacionado al abrir y guardar distintas configuraciones
topológicas con sus respectivos parámetros; también la barra de herramientas ubicada a la
derecha de la pantalla que es la principal herramienta para acceder a las utilidades del
software; además, la ventana en la cual se introduce la información requerida para poder
cargar la red automáticamente, así como las utilizadas para ver el estado actual de la red
en cuanto a lo que utilización y características de los LSPs creados hasta el momento se
refiere.
Se procuró agrupar los botones de acuerdo a la tarea que cumplen: ingreso de
elementos de red, algoritmos para el establecimiento de los LSPs y herramientas de
visualización del estado actual de la red. Todo esto, por medio de una interfaz gráfica
sencilla e intuitiva, que sea de fácil manejo para el usuario.
Pasemos ahora a describir el package Programa.
8.1 El package Programa
Las clases que contiene el package Programa definen las funcionalidades de la
Interfaz de Usuario, y concentra todas las tareas referentes al despliegue del programa a
través de una interfaz gráfica mediante el uso de elementos como ser ventanas, menúes,
diálogos, etc.
A continuación se presenta el diagrama de clases UML del package y luego se
detallan las clases que lo componen.
57
Figura 8.1: Diagrama de clases del Package Programa
8.2 Clase Principal y VentanaConf
La clase Principal genera el marco principal que contiene las barras de menú y
herramientas con el que se pueden crear, abrir y modificar distintas topologías de red.
La clase VentanaConf implementa los dos paneles principales del software que
son el panel gráfico en el que se representan los elementos que componen la red y el
panel que contiene los botones que implementan todas las funcionalidades del software
como ser, crear elementos de red, ver estadísticas o correr distintos algoritmos de
ingeniería de tráfico.
58
Figura 8.2: Marco Principal del software
8.3 Clase Intérprete
Esta clase permite al usuario generar un archivo de salida, que guarda en forma de
texto todos los elementos de la red y sus atributos. De esta manera el usuario podrá
simular varias topologías y guardar los diferentes estados de la red en un archivo .txt que
luego podrá abrirlo para que la clase Intérprete lo convierta en elementos gráficos de una
forma sencilla.
59
Formato del archivo según el elemento de red:
Enlace
Link
name Link_4
coord 208 125 372 87
connection LSR_1 LSR_2
ipinterfaz 10.10.10.1
bw 155.0
delay 0.0
down 0.0
peso 1.0
end
Nodo
LSR
name LSR_1
coord 208 125
routerid 10.10.10.1
ip 10.10.10.1
comunnity xxxxxxxx
descubierto
end
LSP
LSP
name LSP_1
nodoOrigen LER_1
ancho 100.0
Link_8
Link_11
end
Observaciones: el atributo coord refiere a las coordenadas espaciales (x, y) que en
que el elemento gráfico asociado al elemento se ubicará en la pantalla. End es utilizado
por el intérprete para indicar que se terminaron los atributos del elemento.
8.4 Clases TxtFileFilter y ArcFileFilter
Las
clases
TxtFileFilter
y
ArcFileFilter
heredan
de
la
clase
javax.swing.filechooser.FileFilter y son filtros que al abrirse una ventana de diálogo del tipo
jFileChooser cuando un usuario decide abrir o guardar un archivo, permiten que sólo se
muestren los archivos con los formatos específicos de entrada-salida del software. La extensión
.txt corresponde al formato de texto simple elegido para nuestro software y el formato arc
corresponde al software ARCA. Ver Figura 8.3.
Figura 8.3: Formatos de salida del software
60
8.5 Clase ConfLink
Esta clase implementa el marco en el cual el usuario podrá al crear un enlace
nuevo en la red configurar todos sus atributos como ser el nombre, ancho de banda, peso
asociado al enlace (usado como costo en CSPF) y afinidades. El mismo marco permite al
usuario crear un nuevo tipo de afinidad que luego podrá ser utilizada en todos los enlaces
de la red. Si en algún momento el usuario necesitase modificar alguno de los atributos, el
software creará una nueva instancia a ésta clase, pero cargando los atributos actuales del
enlace.
Figura 8.4: Ventana de configuración de enlaces
Al usuario crear un nuevo Link se abre la ventana que se muestra en la Figura 8.4,
asociando valores por defecto a los distintos atributos del nuevo enlace. El software
cuenta los enlaces ya creados en la red y le asigna el nombre correspondiente. En la parte
inferior de la ventana el usuario podrá asociar al enlace afinidades ya creadas en la red o
crear una, escribiendo la nueva afinidad en el campo Escribir Afinidad. Esta nueva
afinidad podrá luego ser asociada a todos los enlaces de la red. Se decidió agregar el
concepto de afinidad a los enlaces de modo de restringir usar ciertos enlaces por ejemplo
por tráfico del tipo Best Effort en enlaces críticos. De esta manera el usuario podrá correr
CSPF y usar como restricciones las afinidades creadas en la red.
61
8.6 Clase Cargar Topología
Esta clase implementa el marco en el cual el usuario podrá ingresar los
parámetros necesarios para poder “descubrir” la topología en estudio.
Figura 8.5: Ventana Cargar Topología
Algunos parámetros son obligatorios como la dirección IP de algún router de la
red (casi siempre el que tiene directamente conectado), para comenzar la iteración hasta
descubrir completamente la red. Otros parámetros obligatorios a ingresar, tal como se
puede apreciar en la Figura 8.5 son la versión SNMP que se desea ejecutar, teniéndose
como opciones en primera instancia la versión 1 y 2, pudiéndose agregar la versión 3 en
futuras versiones. Luego, el “community” que es el password que utiliza SNMP, que es
previamente configurado en los routers para impedir que se modifiquen los MIBs del
router por personas no autorizadas. Si este password es mal configurado (o es distinto) en
alguno de los routers el software lo reconocerá como un nodo que habla ospf pero no
podrá conocer a sus vecinos (ya que no tiene acceso a él). Como opcionales se pueden
modificar el puerto (por defecto 161 sino se ingresa ninguno), reintentos, timeout
(también con valores por defecto en caso de no ser ingresados por parte del usuario) y
continuar carga de red (para permitir se siga con la carga de la red una vez hallada una
zona donde el community es distinto y deba ser ingresado nuevamente por el usuario).
8.7 Clases Estadísticas y Propiedades
Estas clases son las que permiten al usuario conocer los atributos y estados de los
elementos que componen la red en estudio. La clase propiedades es una ventana que
muestra los atributos configurables de cada elemento de la red así como por ejemplo los
62
LSPs que pasan por el elemento, o en el caso de los enlaces su utilización. Ver Figura
8.6. Por otro lado la clase Estadísticas, genera un marco más general en el que se puede
Figura 8.6: Ventana Propiedades: a) para un enlace b) para un nodo
ver el estado actual de la red como ser los atributos de los elementos de la red, ver los
enlaces críticos y ver detalles de los LSPs establecidos en la red. Observar la Figura 8.7.
Figura 8.7: Ventana Estadísticas
63
8.8 Clase Utilización
Es otra de las clases creadas que permiten al usuario conocer el estado de la red
de una manera sencilla. La clase genera un marco al que el usuario puede ingresar valores
que se toman como referencia para definir rangos de utilización. Luego se llama a un
método que recorre todos los enlaces de la red y los pinta de un color que depende de la
utilización actual del enlace. Observar Figura 8.8.
Figura 8.8: Ventana Utilización
Esta ventana puede estar abierta siempre y con sólo apretar el botón Aceptar se
reflejará de un modo rápido los cambios de utilización en los enlaces debido a los nuevos
LSPs creados en la red.
64
Capítulo 9
Carga automática de la topología
Tal como el nombre del capítulo lo indica, presentaremos ahora el package
encargado de la funcionalidad de extraer la información necesaria de los routers para
poder cargar la topología automáticamente, y no de manera manual tal como lo podría
hacer el usuario al crear una topología desde cero o cargar una ya existente.
9.1 El package CargarRed - Implementación
En nuestro caso cargar la topología de red se entiende como descubrir todos los
routers presentes en la red que estén intercambiando información de ruteo mediante el
protocolo de enrutamiento OSPF.
Al ser OSPF un protocolo de estado de enlace cada router sólo conoce los routers
de la red con los que forma adyacencias e intercambia información de ruteo
(generalmente en ospf sólo se forman adyacencias entre los routers directamente
conectados).
Para conocer los vecinos de un router y las velocidades de las interfaces que lo
conectan es necesario acceder a los MIBs de los routers, específicamente a los definidos
en el RFC-1213 y en los OSPF-MIB. En la siguiente Figura 9.1 se pueden ver los grupos
y tablas que lo componen.
65
OSPF-MIB DEFINITIONS
RFC1213-MIB DEFINITIONS
ospfGeneralGroup
ospfAreaTable
mib-2
ospfStubAreaTable
system
ospfLsdbTable
interfaces
ospfAreaRangeTable
ifNumber
ospfHostTable
ifTable
ospfIfTable
at
ospfIfMetricTable
ip
ospfVirtIfTable
icmp
ospfNbrTable
tcp
ospfVirtNbrTable
udp
ospfExtLsdbTable
egp
ospfRouteGroup
transmission
ospfAreaAggregateTable
snmp
ospfConformance
Figura 9.1: Grupos y Tablas que componen los MIBs de OSPF y RFC-1213
Específicamente dada la red en la Figura 9.2, se conecta una PC con el software
instalado a uno de los routers que hablan ospf, que sería el NMS si tenemos en cuenta la
especificación del protocolo SNMP.
Figura 9.2: Ejemplo de una red
66
Lo primero que hace el software es cargar el RouterID del router, que es la
dirección IP que identifica unívocamente al router en la red. El software guarda el
RouterID en memoria de modo de saber que ya se conectó a este router y no volver a
conectarse. En ese momento carga la tabla ospfNbrTable, que es donde el router guarda
información de las adyacencias que forma con los demás routers de la red. El software
carga en memoria los RouterIDs y las direcciones IP de las interfaces por las cuales se
conecta.
En el caso del router directamente conectado tendríamos como respuesta a la
consulta del ospfNbrTable:
ospfNbrIpAddr
10.10.10.17
ospfNbrRtrId
10.10.10.1
ospfNbrState
Full(8)
En la tabla anterior sólo se muestran algunas de las variables. La variable
opsfNbrState muestra el estado de la adyacencia entre los dos routers De esta manera se
descubrió un nuevo router en la red con RouterID al que puedo llegar por la interfaz con
IP 10.10.10.17 y el software guarda en memoria que ya se conectó al 10.10.10.5 y que le
falta conectarse al 10.10.10.1.
Luego el software procede a conectarse a este nuevo router para descubrir a sus
vecinos, que son los 4 que se muestran en la siguiente tabla:
ospfNbrIpAddr
10.1.1.2
10.1.1.6
10.1.1.14
10.1.1.18
ospfNbrRtrId
10.10.10.2
10.10.10.3
10.10.10.4
10.10.10.5
OspfNbrState
Full(8)
Full(8)
Full(8)
Full(8)
Se comparan los RouterID de estos nuevos routers con los que el software tiene
en memoria como ya conectados. Si aparece en la lista se omite y se guardan los nuevos
routers descubiertos. De esta manera el software se va conectando a todos los routers,
carga a los vecinos, los compara para saber si son nuevos, si lo son los guarda en
memoria para conectarse luego y si no se omiten. Se sigue esta iteración hasta que no se
descubren routers nuevos y ya me conecté a todos los que tengo en memoria.
67
En resúmen,
1-
Me conecto al primer router y lo guardo en las listas RoutersRed y
RoutersDescubiertosNoConectados (en esta lista además guardo la IP por la que
llegó al router) que al principio están vacías.
2-
Cargo vecinos del router.
3-
Para cada vecino: no está en RoutersRed, entonces se agrega a RoutersRed y
RoutersDescubiertosNoConectados.
4-
Elimino el router de RoutersDescubiertosNoConectados.
5-
Si hay más routers en RoutersDescubiertosNoConectados, me conecto al primero
de la lista y vuelvo a 2. Si RoutersDescubiertosNoConectados no tiene elementos,
entonces ya descubrí toda la red y la lista de routers que la componen se encuentra
en RoutersRed
Un parámetro que es fundamental para correr algoritmos de TE es la capacidad de
los enlaces. Estos se cargan de la tabla ifTable definida en el RFC 1213 que tiene el
formato de la siguiente forma:
ifIndex
1
2
3
4
5
ifDescr
ATM4/0
FastEthernet0/0
FastEthernet1/0
Ethernet2/0
Ethernet2/1
ifType
sonet
ethernetCsmacd
ethernetCsmacd
ethernetCsmacd
ethernetCsmacd
ifMtu
4470
1500
1500
1500
1500
ifSpeed
149760000
100000000
100000000
10000000
10000000
ifAdminStatus
down
up
up
down
down
ifOperStatus
down
up
up
down
down
A la dirección IP que tiene asociada la interfaz se le asocia un número de interfaz
(ifIndex). Esta asociación se encuentra en la tabla ospfAddrTable que también se carga al
conectarse al router. Ya con el ifIndex entro al IfTable y cargo la capacidad del enlace.
Veamos por último el diagrama UML del package CargarRed.
68
Figura 9.3: Diagrama UML del package CargarRed.
69
Capítulo 10
Computación de caminos
El presente capítulo analiza los distintos mecanismos para la computación de
caminos que van a ser futuros LSPs. Se destaca el algoritmo Constraint Shortest Path
First (CSPF) utilizado para encontrar caminos basándose en el conocido algoritmo
Shortest Path First (SPF) o Dijkstra, con el requerimiento extra de que debe satisfacer
ciertas restricciones. Se le ofrecen al usuario además distintos criterios a aplicar de
Ingeniería de Tráfico (TE), de manera que pueda optimizar el resultado arrojado por el
CSPF, filtrando todas las soluciones posibles y dejando solamente las que más se
aproximan a lo que desea. También se presenta otro algoritmo online para el
establecimiento de rutas que es el MIRA. Se expone también el método manual en donde
el usuario establece los LSP de manera explícita indicando el camino que desee.
10.1 El package CrearLSPs
Este package esta conformado por 5 clases: Ruteo Explícito, CSPF, Algoritmo,
CarConf y MIRA.
Para poder visualizar mejor el relacionamiento entre dichas clases que componen
este package, a continuación se muestra el diagrama UML del mismo.
Figura 10.1: Diagrama UML del package CrearLSPs
70
A continuación pasamos a describir en más detalle cada una de las clases
mencionadas anteriormente.
10.2 La clase Ruteo Explícito
Esta es la clase usada cuando el usuario de la red desea establecer los LSPs de
manera manual, señalando enlace a enlace, cuál es el camino que desea conforme el LSP.
Como cualquier otro LSP, al momento de desplegarse la ventana, se le asigna un
nombre al LSP próximo a crearse.
El usuario debe ingresar como parámetro de entrada el ancho de banda que desea
tenga el LSP y cuál es el Nodo de Origen donde desea comience el LSP.
Podemos observar a continuación en la Figura 10.2 una imagen de cómo luce la
ventana desplegada.
Figura 10.2: Ventana usada para el Ruteo Explícito de un LSP.
Una vez ingresados ambos parámetros, el programa va desplegando en un combo
la lista de enlaces que contienen en uno de sus extremos al Nodo Origen elegido y que
cumplen con la condición del ancho de banda. Con esto último nos referimos a que sólo
se despliegan los enlaces que contienen al nodo origen y cuyo ancho de banda disponible
es mayor o igual al requerido por el futuro LSP. De la misma manera, a medida que el
usuario va creando el LSP manualmente, en pantalla se va pintando con color el mismo,
de manera que el usuario lo pueda apreciar también gráficamente.
Finalmente una vez presionado Aceptar, se guardará automáticamente dicho LSP
y se actualizarán los valores de ancho de banda disponibles en los enlaces que se vieron
afectados.
71
10.3 La clase CSPF
Esta clase es la usada para computar caminos para futuros LSPs por medio del
algoritmo CSPF explicado en el Capítulo 4.
Esta clase lo que básicamente hace es recolectar toda la serie de parámetros
ingresados por el usuario, necesarios para determinar cuáles son las restricciones que
desea cumpla el o los LSPs solución y qué criterio de ingeniería de tráfico desea usar.
Posteriormente, de acuerdo a las opciones elegidas, pasa a llamar a la clase Algoritmo
(explicada en la Sección 10.4) que es donde reside el método que implementa el Dijkstra
y los demás métodos encargados de ejecutar el criterio de ingeniería de tráfico, si es que
se eligió alguno.
Son varias las distintas opciones que se le presentan al usuario al momento de
ingresar los parámetros al sistema, de manera que pueda crear varias situaciones y
analizar cuál es la que más le conviene. Esto claramente aumenta la cantidad de
escenarios del tipo “what if” que puede plantearse. Todo esto con el objetivo de poder
ofrecerle al usuario tantas herramientas como sea posible para conseguir la solución que
más se ajuste a sus necesidades.
Podemos observar el aspecto de la ventana creada por esta clase en la Figura 10.3.
Figura 10.3: Ventana CSPF
72
Empecemos señalando cuáles son los distintos parámetros que debe ingresar el
usuario y las opciones que se le ofrecen para pasar luego a comentar ciertas
características de cómo fue implementada la clase CSPF.
Así como lo muestra la Figura 10.3, automáticamente que se abre la ventana el
programa ya le asigna un nombre determinado al LSP a crearse.
Paso siguiente, el usuario debe ingresar, como es usual, el ancho de banda que va
a requerir el LSP que desea establecer.
Asimismo tiene la posibilidad de elegir una Afinidad determinada, del grupo de
Afinidades que hayan sido creadas. Esto permite al usuario el poder correr el algoritmo
CSPF sólo sobre los enlaces que pertenecen a una determinada Afinidad, lo cual es
práctico en caso de tener distintos tipos de tráficos circulando por los enlaces de la red y
desear correr el algoritmo sólo sobre los que portan un determinado tipo.
Finalmente, los siguientes parámetros obligatorios a ingresar son el Nodo de
Origen y de Destino.
Como comentario al margen, vale destacar que la ventana fué diseñada para que
las opciones se vayan habilitando a medida que los parámetros vayan siendo ingresados
en orden. Esto obliga al usuario a ingresar si o si los parámetros que son obligatorios para
correr el Dijkstra o SPF.
Ahora pasamos a la parte en donde el usuario debe elegir qué criterio usar para
asignar los pesos a los enlaces. Esto es particularmente importante ya que determina la
métrica en la cual se basará luego el SPF para el cálculo de los caminos solución.
Las opciones presentadas son las siguientes;
•
•
•
•
Ruteo Mínimo por Pesos Administrativos: en este caso se le asigna a cada
enlace un determinado peso que es elegido por el usuario. El peso en este caso
es un valor numérico entero mayor que 0. Este valor es una manera de
priorizar determinados enlaces frente a otros. Cuanto más grande este valor,
menor será la probabilidad de que el camino pase por ese enlace. Básicamente
el camino tendera a utilizar los enlaces con menor peso.
Ruteo por Mínima Cantidad de Saltos: en este caso se le asigna un peso igual
a 1 a cada enlace. De esta manera, al utilizar el Dijkstra, éste calcula los
caminos basándose en la cantidad de saltos. Básicamente, se desplegará como
resultado los caminos con la menor cantidad de saltos de origen a destino.
1/(Bwreservado): en este caso, tal como lo sugiere el nombre, asigno a los
pesos el valor correspondiente a 1/(BW reservado). Esto quiere decir que los
caminos solución tenderán a ir por los enlaces más ocupados (con menos
ancho de banda disponible). De esta manera se intenta no usar los enlaces más
libres (dejándolos para futuros LSPs), sino que terminar de ocupar los más
utilizados.
1/(BWlibre): en este caso, tal como lo indica el nombre, asigno a los pesos el
valor correspondiente a 1/(BW disponible). Esto quiere decir que los caminos
solución tenderán a ir por los enlaces más libres, no molestando a los más
ocupados. Es una manera de establecer los LSPs por lugares de baja
utilización.
73
A continuación, una vez elegida la métrica que se va a tomar en cuenta, el usuario
tiene la posibilidad de elegir un determinado enlace por el que pase el o los caminos
solución si o si. De esta manera se obliga a las posibles soluciones que contengan
determinado enlace aún cuando este no estaría contenido en los caminos arrojados por el
Dijkstra. Además se le da también la posibilidad de lo opuesto, que no pase por
determinado enlace, aún cuando éste estuviera contenido en los caminos arrojados por el
Dijkstra. La razón de estas dos opciones es que quizás por razones políticas o de
determinado Service Level Agreement (SLA), el usuario esté obligado a que se pase o no
por determinado enlace.
Por último, se le da la posibilidad al usuario de elegir entre no usar criterio de
Ingeniería de Tráfico alguno, o usar dos posibles.
De la primer manera, no se usa criterio de TE alguno, lo cual implica que las
soluciones desplegadas al usuario serán las arrojadas por el algoritmo SPF en su totalidad
y que cumplen con las restricciones elegidas por el usuario previamente.
La segunda opción es usar un criterio de TE basado en filtrar los caminos solución
brindados por el SPF y desplegar de entre esas soluciones, sólo aquellas que no utilizan a
los enlaces más críticos contenidos en los caminos (de ahí el nombre “no saturación de
enlaces críticos”).
Y por último, se tiene el MINHOP, el cual, simplemente de todas las soluciones
arrojadas por el SPF, se queda con las más cortas en cuanto a lo que a cantidad de saltos
se refiere.
Lo único que resta es correr el Algoritmo y se desplegarán en pantalla todas las
posibles soluciones.
En caso de haber elegido el segundo o tercer criterio de TE, se despliega en
pantalla una ventana que muestra los caminos que fueron elegidos y los descartados
luego de aplicar esos criterios de TE. Esta ventana muestra además la utilización y otros
útiles datos de los enlaces que conforman los caminos elegidos y descartados.
Se comentará más en detalle el algoritmo SPF, criterios de TE y la ventana
mencionada anteriormente, en las próximas secciones.
Pasemos ahora a comentar los métodos más importantes y características de la
implementación de la clase CSPF.
El primer método a destacar es el método podar(). Dicho método es el encargado
de “podar” todos los enlaces de la red para pasar como parámetro de entrada al algoritmo
SPF (Dijkstra) solamente a aquellos que cumplen con la condición del ancho de banda
requerido y pertenecen al mismo tiempo a la Afinidad seleccionada en caso de haberse
elegido una.
Para el caso de haber elegido algún enlace del combo Enlace Ausente,
simplemente retiro a ese enlace de la lista de enlaces a considerar que entran como
parámetro de entrada al algoritmo SPF.
La situación es más complicada cuando se elige un Enlace Presente. En este caso,
se debe empezar dividiendo el problema en dos. En caso que no se elija esta opción,
simplemente se redefinen los pesos de los enlaces de acuerdo a la opción de métrica
elegida. Luego se corre el Dijkstra. Si encuentra una solución ya de entrada, entonces en
ese caso ya la despliega en pantalla. Si se encuentra más de una, se pasa a fijar si se eligió
algún criterio de TE en particular y de ser así, se aplica ese criterio y despliega en
74
pantalla el resultado conjuntamente con los datos de los caminos descartados, en caso de
haberlos.
Sin embargo en caso de haber elegido la opción Enlace Presente, se debe tener
más cuidado en la manera de correr el Dijkstra y cómo hacerlo. Primeramente se
redefinen los pesos de los enlaces de acuerdo a la métrica elegida. Se deben tomar en
cuenta casos particulares como que uno de los nodos que conforman al Enlace Presente
sea de casualidad el Nodo de Origen o Nodo de Destino, o que justo Enlace Presente sea
el enlace que une al Nodo Origen con el Destino, en cuyo caso ya sería la solución. En
todos estos casos en particular, se corre el SPF sólo 1 vez. Ahora, si no caemos en
ninguno de estos casos en particular, entonces se deberá correr el SPF 4 veces. Si
llamamos al Nodo Origen, nodoA; y al Nodo Destino, nodoB. Y supongamos que los
nodos que conforman a Enlace Presente son nodo1 y nodo2. Entonces se corre primero el
Dijkstra entre el NodoA y el nodo1 y luego entre el nodo2 y el NodoB. Así se deben
tomar en cuenta todos los posibles caminos que surjan en cada pasada del Dijkstra, y en
caso de haber un error en alguna pasada, también se debe tomar en cuenta ya que quizás
no se encuentre camino alguno. Se agrega el Enlace Presente entonces a cada una de
todas las posibles combinaciones que surjan entre todas las soluciones encontradas en las
2 pasadas. Posteriormente, corremos el Dijkstra entre el nodoA y el nodo2 y luego entre
el nodo1 y el nodoB. Acá tomamos también en cuenta todos los caminos posibles que
surjan en cada pasada. Y repetimos el razonamiento. En caso de haber encontrado
soluciones en el primer par de pasadas del Dijkstra y en el segundo, se deben juntar todas
y ésa es la solución a mostrar. En todo caso se deberá tener especial cuidado con la
aparición de errores en alguna pasada debido a la no existencia de una solución.
Finalmente, recurre a la clase Algoritmo en caso de haber más de una solución
posible arrojada por el SPF y elegido algún criterio de TE en particular.
Una vez elegida la solución deseada, quedará guardada con el resto de los LSPs
ya establecidos.
10.4 La clase Algoritmo
En esta clase se encuentra la implementación del algoritmo Dijkstra, y los de
SNMP SNMP.
En cuanto al algoritmo de Dijkstra, éste es implementado por medio del método
shortestPath(), el cual es encargado de calcular todos los caminos solución del origen a
destino, con la métrica más chica. Recibe como parámetros de entrada, la lista de nodos
de la red a tomar en cuenta, la lista de enlaces, el Nodo Origen y Destino y una variable
booleana que indica si fue elegida la opción de Enlace Presente. Ya ambas listas de nodos
y enlaces fueron filtradas con las restricciones de ancho de banda y Afinidad ingresadas
por el usuario.
Otro método a destacar es el podar2(). Este es encargado de aplicar el segundo
criterio de TE (no saturación de enlaces críticos). Básicamente lo que procura es descartar
a aquellas soluciones que poseen los enlaces más críticos. Con eso nos referimos a
aquellos enlaces que están casi saturados y que poseen muy poco ancho de banda
disponible, lo cual causaría que de pasar el LSP por ellos, queden prácticamente
inutilizables para futuros LSPs. Lo que se hace es tomar de cada camino solución
75
arrojado por el Dijkstra, el enlace con menor ancho de banda disponible (llamemos
enlaceCrítico al valor de ancho de banda de dicho enlace). Se compara cada
enlaceCrítico de cada solución y se descartan los caminos con el enlaceCrítico más
pequeño. En caso de quedar aún más de una solución posible, significa que el
enlaceCrítico para cada uno de estos caminos tiene el mismo valor. Entonces se pasa a
ver cuántos enlaces en cada uno de esos caminos, tienen un ancho de banda similar al
guardado en enlaceCrítico. Los caminos que tengan más cantidad de enlaces con ese
valor, se descartan (ya que se estaría perjudicando a un número mayor de enlaces en esos
caminos). Y si aún después de eso, seguimos con más de una posible solución, buscamos
el siguiente valor más pequeño que sea mayor que enlaceCrítico y redefinimos
enlaceCrítico para cada solución. Repetimos así el proceso iterativamente hasta
quedarnos con una solución solamente o con varias que sean indistintas unas de las otras
en lo que a este criterio se refiere.
Por último, se debe destacar el método podar3(), el cual se encarga de filtrar
también las soluciones arrojadas por el Dijkstra, quedándose sólo con las más cortas en
cuanto a lo que número de saltos se refiere.
10.5 La clase CarConf
Esta clase es la que implementa la ventana que se despliega cuando tenemos más
de un camino posible y se eligió algún criterio de TE en particular.
Podemos apreciar la ventana en la Figura 10.4.
Figura 10.4: Ventana CarConf
Presenta dos botones. Uno de ellos muestra los caminos que son solución luego de
aplicar alguno de los criterios de TE. El otro muestra información sobre los caminos que
76
fueron descartados (éstos son los caminos que pertenecían a la solución brindada por el
Dijkstra, pero que no cumplieron el requerimiento de TE elegido).
La información desplegada es la siguiente para cada camino: los enlaces que
conforman dicho camino, la capacidad de cada uno de los enlaces, la cantidad de Mbps
que está siendo usada en ellos y el porcentaje de utilización.
10.6 La clase MIRA
Debido a los packages ya utilizados en nuestro software se decidió calcular el
MNF corriendo el SPF repetidamente y actualizando el MNF hasta que no se encuentren
caminos y por ende ancho de banda disponible entre los dos nodos en cuestión. Existen
varios algoritmos para calcular el MNF como el presentado por Goldberg Tarjan [8] o el
algoritmo de Gomory-Hu [9], pero debido a lo complejo de estos algoritmos se optó por
una solución más sencilla pero computacionalmente más costosa.
Por más información referirse al Capítulo 5. La implementación de la ventana
usada para el algoritmo MIRA se comenta en el Capítulo 11.
77
Capítulo 11
Algoritmos de justicia y el MIRA
En este capítulo se analiza el package MT. El mismo tiene varias tareas de las
cuales es responsable. En primer lugar, se encarga de crear la Matriz de Tráfico (MT) que
contiene todas las demandas y sus respectivos anchos de banda. En caso de que ya exista
un archivo de MT, se implementó un Intérprete que pudiera leer dicho archivo y lo
cargue en el software. Se muestra el formato de salida del archivo MT.
También contiene los tres algoritmos implementados para el cálculo de caminos
en las llamadas redes justas. Con esto se trata de ofrecerle al usuario distintos criterios en
la búsqueda de caminos para el establecimiento de los LSPs de manera de poder distribuir
todas las demandas solicitadas de la mejor manera posible. En la búsqueda de ese mismo
objetivo se presenta también la ventana que implementa el algoritmo online MIRA.
11.1 El package MT
El package MT concentra todas las tareas referentes a calcular los mejores
caminos posibles para la topología de red cargada y una matriz de tráfico dada.
En este package se encuentran las clases con las que representamos los caminos
encontrados para cada ruta y cuenta con los atributos necesarios para poder asignar el
ancho de banda a cada camino de forma justa. La ruta indica entre qué nodos, qué ancho
de banda y qué afinidad deberá tener el LSP que se quiere establecer y el camino indica
por los enlaces deberá pasar el LSP.
En la siguiente figura podemos ver el diagrama UML del package:
78
Figura 11.1: Diagrama UML del package MT.
A continuación se describe más en detalle las clases anteriormente mencionadas.
11.2 La clase Caminos
La clase Caminos, modela el camino virtual que se puede establecer para una ruta
dada.
Cada camino consta de un nombre, nodo origen, nodo destino, ancho de banda
deseado, ancho de banda final (es el ancho de banda que se le asigna al camino), afinidad
y de un arraylist enlacesGr (en donde se guardan los enlaces por donde pasa el camino).
Tiene dos atributos más que son prioridad (es la prioridad del camino, por defecto es 1) y
demandamin (demanda mínima del camino, por defecto es 0), estos atributos sólo son
usados en la clase FairnessNetwork al elegir el método algoritmo2() (correspondiente al
Fairness acotado).
11.3 La clase InterpreteMT
Esta clase permite al usuario generar un archivo de salida, que guarda en forma de
texto una lista de rutas con sus atributos que representan la matriz de tráfico. De esta
manera el usuario podrá simular para una topología dada y posibles variantes de ésta,
como quedan los LSPs para la misma matriz de tráfico.
79
11.4 La clase GeneroMT
Esta clase implementa el marco en el cual el usuario podrá crear el archivo que
representa la matriz de tráfico. Al crear cada ruta se debe configurar sus atributos como
ser el nombre (tiene por defecto Ruta seguido de un número que se incrementa al crear
una ruta nueva), ancho de banda deseado, nodo origen, nodo destino y afinidad (es
opcional, el camino sólo puede pasar por los enlaces con esa afinidad).
Figura 11.2: Ventana GeneroMT
A cada ruta creada se le puede modificar todos sus atributos excepto el nombre,
o se puede borrar la ruta completa.
El archivo que se crea es con terminación “.txt” y será usado por las clases
FairnessNetwork y OffLineMira y también por GeneroMT cuando se desea modificar un
archivo de matriz de tráfico ya creado.
Formato del archivo:
Matriz de tráfico
Camino
name Ruta_1
connection LER_1 LER_2
ancho 1.0
afinidad: no tiene
end
80
El archivo comienza con Matriz de tráfico que es utilizado por el intérprete para
indicar que es un archivo generado por la clase GeneroMT.
End es utilizado por el intérprete para indicar que se terminaron los atributos del
elemento.
11.5 La clase FairnessNetwork
Esta clase permite al usuario correr los distintos algoritmos Fairness, comparar
sus resultados para después crear los LSPs para las distintas rutas. Primero se llama al
método que carga el archivo de matriz de tráfico al oprimir el botón Cargar Matriz y se
llama al método shortestPath() de la clase Algoritmo que calcula todos caminos posibles
con la menor métrica para las distintas rutas de la matriz de tráfico.
Figura 11.3: Ventana FairnessNetwork
Después de calcular todos los caminos posibles para cada ruta, se elige uno de
los cuatro algoritmos Fairness. Se selecciona la métrica a utilizar entre Peso o Minhop y
al apretar el botón Correr se calcula el ancho de banda final de cada camino. Para los
últimos dos algoritmos no se usan los parámetros Peso o Minhop, por lo que no se
habilitan en ése caso. También, en caso de elegir uno de los dos primeros algoritmos, si
existen varios caminos posibles para cada demanda, se le ofrece la posibilidad al usuario
de elegir el que desee por medio del combobox Caminos posibles.
Los métodos algoritmo1() (que implementa el Fairness Básico) y algoritmo2()
(que implementa el Fairness acotado) usan un sólo camino de los calculados para cada
ruta a diferencia del algoritmo3() (que implementa el Fairness con múltiples caminos) y
algoritmo4() (que implementa el Fairness con múltiples caminos acotado) que usan todos
los caminos calculados para cada ruta.
81
El método algoritmo1() corre el método buscar() que cuenta los caminos que
pasan por cada enlace y el método mínimo1() que incrementa el ancho de banda
reservado de todos los enlaces por donde pasa algún camino, esto lo hace hasta que satura
al menos un enlace de cada camino, a ese enlace le fija su ancho de banda. El método
termina cuando todos caminos tienen fijo su ancho de banda.
El ancho de banda final de cada camino puede ser menor, igual o hasta mayor que
el ancho de banda deseado.
El método algoritmo2() corre el método buscar(), pero antes de llamar al método
mínimo1() se abre una ventana que genera un marco donde el usuario puede ingresar los
valores de prioridad y demandamin de cada ruta.
Figura 11.4: Ventana para el Fairness acotado
Después se crean por cada camino un enlace virtual con el ancho de banda
deseado para esa ruta y se llama método mínimo1(). Los enlaces virtuales creados no se
muestran en pantalla y son necesarios para que el ancho de banda final de cada camino no
sea mayor que el ancho de banda deseado.
Estas diferencias con el método algoritmo1() permiten que el ancho de banda
final de cada camino sea como mínimo igual a demandamin y como máximo igual al
ancho de banda deseado.
El método algoritmo3() corre el método calculatodos() que calcula todos los
caminos posibles para cada ruta, sin considerar métrica alguna, ni el ancho de banda de
los enlaces. Después corre los siguientes métodos creaMatrizFairLink(),
OptimizacionLineal(), OptimizacionLinealChequeo(). Estos métodos son los encargados
de maximizar las demandas, asignando a cada sub-demanda el ancho de banda calculado.
El ancho de banda final de cada demanda es la suma de los anchos de banda de sus subdemandas.
El método algoritmo4() corre los métodos calculatodos(), creaMatrizFairLink(),
OptimizacionLineal(), OptimizacionLinealChequeo(), igual que en el algoritmo3().
La única diferencia es que después de tener calculado el ancho de banda final de
todas las demandas y sub-demandas, busca las demandas que su ancho de banda final
supera el ancho de banda deseado y setea éste igual al ancho de banda deseado.
82
Esto lo hace seteando el ancho de banda final de cada sub-demanda de forma que
la suma de éstas no supere el ancho de banda deseado de la demanda a la que pertenecen.
Se pueden correr los cuatro algoritmos sin cerrar la ventana y así poder comparar
los resultados obtenidos para cada uno de ellos. Los resultados obtenidos de cada ruta
para el algoritmo seleccionado se pueden ver al elegir una ruta de Lista de rutas. En
pantalla muestra los enlaces por donde pasa y en la misma ventana muestra sus atributos
como se observa en la siguiente figura.
Figura 11.5: Ventana que despliega resultados
Para el caso del tercer y cuarto algoritmo, donde se pueden tener múltiples
caminos para cada ruta, se muestran en la pantalla ubicada a la izquierda, las subdemandas o caminos que conforman cada ruta. Al hacer click en cada camino, se pinta en
pantalla el mismo y en la pantalla de la derecha se muestran sus atributos en particular. Si
se quieren apreciar todos los caminos que constituyen cierta demanda al mismo tiempo,
nuevamente, conjuntamente con sus atributos, basta hacer click en la ruta deseada otra
vez.
Aquellas demandas que no llegan a obtener el ancho de banda requerido, se
pintarán de color rojo a rayas en pantalla, para su diferenciación.
11.6 La clase LasDemandas
Esta clase se encarga de desplegar una ventana cuando se elige el tercer algoritmo
de fairness (fairness con múltiples caminos). La misma exhibe datos numéricos sobre
cada una de las demandas, de manera que sea más fácil para el usuario el poder apreciar
cuáles demandas llegó a satisfacer y sobrepasar el ancho de banda requerido, y cuáles no.
Los datos que despliega son los siguientes: nombre de la ruta o demanda, ancho
de banda deseado, ancho de banda final, diferencia de ancho de banda (la resta entre los
dos valores anteriores) y cantidad de caminos o sub-demandas que contiene cada ruta.
83
Figura 11.6: Ventana de la clase LasDemandas
11.7 La clase OfflineMira
Esta clase implementa el marco en el cual el usuario podrá correr el algoritmo
MIRA para una matriz de tráfico previamente configurada y guardada en un archivo .txt
con el formato que se explicó anteriormente. Luego de haber cargado la matriz de tráfico
el usuario tiene que elegir cuáles son los pares de nodos que se van a tomar como
referencia como los futuros generadores de LSPs en el sector de la ventana Nodos
ingreso-egreso. El usuario puede optar entre tres opciones, todos los nodos de la red, sólo
los LER`s o elegirlos manualmente.
Figura 11.7: Ventana configuración MIRA
84
En el último caso la clase desplegará una ventana en que el usuario podrá
seleccionar los nodos individualmente.
Figura 11.8: Seleccionar manualmente los nodos
Luego de haber seleccionado qué nodos quiero ingresar como entrada al
algoritmo, se corre el algoritmo. Primero se asocia pesos a los enlaces de acuerdo a lo
visto en secciones anteriores y luego se corre el algoritmo CSPF con los pesos calculados
y los requerimientos de ancho de banda por las demandas como entrada. Si por algún
motivo no se encontrase ningún posible camino para la demanda, un mensaje de
advertencia alertará de este evento. Antes de mapear las demandas en la red, el usuario
podrá visualizar gráficamente las posibles rutas en la red y si así lo quisiera, se mapearán
las demandas al apretar el botón Crear LSPs.
85
Parte IV
Conclusiones
86
Capítulo 12
Conclusiones y tareas a futuro
12.1 Supuestos y objetivos
El único supuesto que podemos considerar importante al momento de instalar el
software, es que se debe hacer sobre una red MPLS cuyos routers manejen el protocolo
de ruteo OSPF. Este supuesto es necesario en caso de desear utilizar NET-TE para
levantar la red en forma automática y desplegarla en pantalla.
La hipótesis sobre la red MPLS no afecta ninguna otra funcionalidad del software,
ya que es principalmente una herramienta de trabajo offline, usada por el usuario para
analizar distintos métodos de búsqueda de caminos para el establecimiento de LSPs.
En cuanto a los objetivos marcados durante el desarrollo de este proyecto, éstos se
fueron dando a medida que el proyecto avanzaba, no teniéndolos determinados desde un
principio.
Antes de empezar a trabajar formalmente en el proyecto, sabíamos que la idea era
en rasgos generales, el crear un software que le permitiera al usuario el visualizar su red y
poder brindarle ciertos mecanismos de ingeniería de tráfico al momento de establecer los
LSPs a modo de poder satisfacer los distintos niveles de QoS solicitados.
Llegado el final de este proyecto y mirando hacia atrás, podemos ahora distinguir
claramente cuatro distintos objetivos. El primero fue el desarrollar una herramienta que
permita la creación de una red, visualizar su estado actual y poder modificarla de acuerdo
a las necesidades del usuario. El segundo fue el ofrecer varios algoritmos que permitieran
al usuario distintas posibilidades de por dónde rutear el LSP que cubrirá a cada nueva
demanda entrante a la red, de manera que se ajuste de la mejor manera a sus necesidades.
Esto es para el caso donde tenemos una red con varios LSPs ya establecidos y queremos
determinar por dónde irán los nuevos LSPs a medida que llegan una a la vez las nuevas
demandas. Como tercer objetivo, se tuvo el implementar otros algoritmos que permitan, a
diferencia de los anteriores, el poder considerar todas las demandas de la red en forma
conjunta y ubicarlas de la mejor manera posible en la red, de tal manera que se vean todas
cubiertas, o en caso de no ser posible, el cubrirlas de la manera más “justa” a todas ellas.
Finalmente, como cuarto y último objetivo, se planteó la incorporación de una
funcionalidad que le permitiera al usuario el poder levantar la red a la que está conectado
de manera automática y visualizarla en pantalla.
Es importante destacar que en todo momento, con respecto a la validación de los
datos que son devueltos al aplicar los distintos algoritmos de Fairness, se comprobó su
correcto funcionamiento basándose en distintas pruebas y ensayos realizados por nuestra
parte. También se comparó con ejemplos de los cuales ya se conocían de manera
confiable los resultados y viendo así que obteníamos los valores esperados.
Finalmente, en cuanto a la escalabilidad de los algoritmos a medida que la red
crece de tamaño, pudimos corroborar en la práctica, que el tercer y cuarto algoritmo de
fairness son los que consumen más tiempo de operación debido a la gran cantidad de
iteraciones que se realizan. De cualquier manera, probamos con topologías de 30 nodos
aproximadamente, y vimos que el tiempo que demora en desplegar los resultados es
87
prácticamente al instante y no considerable (poco más de un par de segundos cuando
máximo).
12.2 Conclusiones
En cuanto a los objetivos planteados, podemos decir que se llegó a cumplirlos
todos de manera satisfactoria.
Se logró implementar una interfaz gráfica sencilla y fácil de usar por cualquier
usuario, la cual le otorga una amplia flexibilidad al momento de diseñar o modificar su
red. Además, se le brindó al usuario varios mecanismos para poder visualizar el estado
actual de la red, pudiendo ver información de elementos en particular o de la red en
general. Pensando en la comodidad del usuario en la manera de cómo apreciar esa
información, se brinda toda esa información tanto en forma numérica como gráfica.
El problema del establecimiento de los LSPs fue solucionado utilizando el
algoritmo CSPF. Realizamos varias pruebas sobre distintas topologías y situaciones, y
pudimos apreciar el correcto funcionamiento del mismo. Pudimos también comprobar
que es muy útil el tener varias opciones a elegir, ya que esto nos permitió crear múltiples
escenarios y tener así un abanico más grande de soluciones de entre las cuales elegir.
También pudimos comprobar la gran utilidad que ofrece el algoritmo MIRA. Se
hicieron pruebas de chequeo sobre topologías en las cuales habían claramente ciertos
enlaces que eran críticos para futuras posibles demandas, y pudimos apreciar como el
algoritmo tendía a evitar dichos enlaces críticos.
Finalmente, nos planteamos escenarios donde el algoritmo CSPF no encontraba
ningún camino posible para ubicar a cierta nueva demanda, y probamos en ese caso los
algoritmos de fairness. Pudimos apreciar con éxito como, con el uso de éstos últimos, se
lograba ubicar esa demanda sobre la red, cosa imposible de realizar usando el CSPF.
Además, comprobamos con éxito como NET-TE lograba asignar los recursos de una
manera justa en aquellos casos donde no era posible satisfacer por completo a todas las
demandas.
Con respecto a la carga automática de la red, se pudo comprobar con éxito su
funcionamiento en la red multiservicio del PDT desde el IIE de la Facultad. Se conectó
una laptop que tenía el software NET-TE instalado, a la red. Una vez conectada, y luego
de ingresar la información requerida, se pudo apreciar en consola, como el software se
conectaba a los routers vecinos e iba descubriendo la red. Finalmente, y tal como era de
esperarse, se dibujó en pantalla la topología descubierta. Debido a restricciones de
seguridad, no pudimos descubrir la red entera, ya que sólo teníamos visibilidad hasta los
routers más próximos de la PC de donde estabamos conectados. De cualquier manera se
pudo comprobar el correcto funcionamiento de esta funcionalidad.
Es por todo lo anterior que creemos que NET-TE es una útil herramienta que
puede ser usada por cualquier usuario que desee realizar pruebas y crear distintos
escenarios de Ingenieria de Tráfico, sin temor de afectar de alguna manera la red real, ya
que se está en todo momento trabajando sobre escenarios de prueba y no sobre la red en
cuestión.
Como conclusión global se puede afirmar que se lograron realizar con éxito todos
los objetivos trazados, juntando diversos criterios y algoritmos para el establecimiento de
88
LSPs en un sólo software, el cual puede ahora ser usado como pilar para el desarrollo de
un software más completo y grande, que agregue más funcionalidades a las ya presentes.
12.3 Tareas a futuro
Si bien se completaron todos los objetivos trazados, existen varias cosas que se
pueden agregar, de manera que el usuario tenga aún más posibilidades y algoritmos a los
cuales acceder.
En cuanto a la carga automática de la red, actualmente NET-TE se encarga
solamente de levantar la topología conjuntamente con la velocidad de cada enlace. Son
varios los datos que un usuario puede querer extraer de la red. En primer lugar, podría
levantar y mostrar los estados de las adyacencias entre nodos de la red. En esta primera
versión del software, no nos preocupamos de dichos estados. También se podría levantar
las métricas de OSPF y el ancho de banda libre de los enlaces. Uno de los datos más
útiles que interesaría extraer en una posible segunda versión del software, son los LSPs
ya establecidos. Datos como el ancho de banda que consume cada uno de esos LSPs, o la
afinidad que presenta tal o cual enlace, pueden resultar muy útiles, en especial ya que son
usados como datos de entrada en los algoritmos implementados en NET-TE. A su vez, el
avisar de cambios en los estados de las adyacencias entre nodos, mediante los traps de
SNMP, resultaría bastante práctico.
Otra posible tarea a realizar a futuro, es aumentar la variedad de algoritmos
usados para el cálculo de los LSPs. Se pueden agregar tantos algoritmos como el usuario
desee y que se ajusten a sus necesidades particulares. Asimismo, se pueden agregar
nuevos pesos, que por ejemplo reflejen el delay de cada enlace, y calcular así el CSPF en
base al retardo de los mismos.
Por último, actualmente NET-TE lo que nos permite es cargar la topología de la
red y extraer la velocidad de los enlaces, para así luego determinar dónde se ubicarán
cada uno de los LSPs de manera que se logre la QoS requerida. Pero no hay una forma de
“arrojar” esos LSPs a la red real. Por ende, una útil implementación en futuras versiones,
es desarrollar una interfaz que permita cargar en los routers de la red real los LSPs que
fueron calculados por NET-TE durante las distintas pruebas. De esa manera se cerraría el
ciclo que comienza con la carga automática de la red conjuntamente con los LSPs ya
establecidos, continúa con el cálculo realizado por NET-TE de las nuevas rutas que
satisfacerán las nuevas demandas y finaliza con la descarga de dichos LSPs a los routers
de la red, de manera que se vean reflejados los cambios y nuevas rutas establecidas.
89
Apéndices
90
Apéndice A
Multi Protocol Label Switching
(MPLS)
MPLS es un estándar emergente del IETF (RFC 3031) que surgió para consensuar
diferentes soluciones de conmutación multinivel, propuestas por distintos fabricantes a
mitad de los 90s. Ante todo, debemos considerar MPLS como el avance más reciente en
la evolución de las tecnologías de routing y forwarding en las redes IP, lo que implica
una evolución en la manera de construir y gestionar estas redes. Los problemas que
presentan las soluciones actuales de IP sobre ATM, tales como la expansión sobre una
topología virtual superpuesta, así como la complejidad de gestión de dos redes separadas
y tecnológicamente diferentes, quedan resueltos con MPLS. Al combinar lo mejor de
cada nivel (la inteligencia del routing con la rapidez del switching) en un único nivel,
MPLS ofrece nuevas posibilidades en la gestión de backbones, así como en la provisión
de nuevos servicios de valor añadido.
A.1 Descripción funcional de MPLS
La base del MPLS está en la asignación e intercambio de etiquetas, que permiten
el establecimiento de los LSP por la red. Cada LSP se crea a base de concatenar uno o
más saltos (hops) en los que se intercambian las etiquetas, de modo que cada paquete se
envía de un "conmutador de etiquetas" (Label-Swiching Router) a otro, a través de la red
MPLS. Un LSR no es sino un router especializado en el envío de paquetes etiquetados
por MPLS.
MPLS separa las dos componentes funcionales de control (routing) y de envío
(forwarding). Del mismo modo, el envío se implementa mediante el intercambio de
etiquetas en los LSPs. Sin embargo, MPLS no utiliza ninguno de los protocolos de
señalización ni de encaminamiento definidos por el ATM Forum; en lugar de ello, en
MPLS o bien se utiliza el protocolo RSVP o Label Distribution Protocol, LDP, del que
se tratará más adelante). Pero, de acuerdo con los requisitos del IETF, el transporte de
datos puede ser cualquiera. Si éste fuera ATM, una red IP habilitada para MPLS es ahora
mucho más sencilla de gestionar que la solución clásica IP/ATM. Ahora ya no hay que
administrar dos arquitecturas diferentes a base de transformar las direcciones IP y las
tablas de encaminamiento en las direcciones y el encaminamiento ATM: esto lo resuelve
el procedimiento de intercambio de etiquetas MPLS. El papel de ATM queda restringido
al mero transporte de datos a base de celdas. Para MPLS esto es indiferente, ya que puede
utilizar otros transportes como Frame Relay, o directamente sobre líneas punto a punto.
91
A.2 Componentes y funcionamiento de una red
MPLS
Los dispositivos que participan en un ambiente como éste pueden clasificarse en
routers frontera de etiquetas (LER) y en routers de conmutación de etiquetas (LSR).
Un LER es un dispositivo que opera en los extremos de las redes MPLS y funciona como
el punto de interconexión entre ésta y la red de acceso. Cuando un paquete llega a uno de
estos routers, el LER examina la información entrante y, de acuerdo con una base de
datos, asigna al paquete una etiqueta. En el extremo de salida de una red MPLS se
presenta la situación opuesta, siendo estos dispositivos los responsables de remover la
etiqueta para entregar el paquete en la forma en que fue recibido.
Después de que los paquetes han sido etiquetados por el LER, éstos comienzan su
viaje a través de la red MPLS, encontrándose en su trayectoria con los routers de
conmutación de etiquetas (LSRs). Estos son los encargados de dirigir el tráfico en el
interior de la red, de acuerdo con las etiquetas asignadas. Cuando un paquete arriba a un
LSR, éste examina su etiqueta y la utiliza como un índice en una tabla propia que
especifíca el siguiente "salto" y una nueva etiqueta. El LSR intercambia entonces ésta
etiqueta por la que contenía el paquete y lo envía hacia el siguiente router. La ruta que
sigue un paquete entre dos nodos de la red MPLS se conoce como ruta conmutada de
etiquetas (LSP). En la Figura A.1 se puede observar el esquema funcional de MPLS.
Figura A.1: Esquema funcional de MPLS
92
Como se comentó anteriormente, los LERs se encargan de clasificar paquetes con
base en un nivel de calidad de servicio. A este proceso de clasificación se le conoce como
Clase Equivalente de Direccionamiento (FEC, por sus siglas en inglés). Un FEC es la
representación de un conjunto de paquetes que comparten los mismos requerimientos
para su transporte, de manera que todos los paquetes que pertenezcan a un FEC seguirán
el mismo LSP para llegar a su destino. Contrario a lo que sucede en el enrutamiento IP
convencional, la asignación de un paquete a un determinado FEC en MPLS se hace una
sola vez.
Los LERs utilizan diferentes métodos para etiquetar el tráfico. Bajo el esquema
más simple, los paquetes IP son ligados a una etiqueta y a un FEC utilizando tablas
preprogramadas como la que se muestra en la Figura A.2. Cuando los paquetes
abandonan el LER e ingresan al LSR correspondiente, la etiqueta MPLS es examinada y
comparada contra una tabla de conectividad conocida como Base de Información de
Etiquetas (LIB) para determinar la acción a seguir. El intercambio de instrucciones se
llevará a cabo dependiendo de las instrucciones del LIB. Un ejemplo de esta tabla de
conectividad se muestra en la Figura A.3. Debe señalarse que las etiquetas poseen
únicamente un significado local dentro del router correspondiente.
Figura A.2: Ejemplo de una tabla preprogramada para LERs.
Figura A.3: Ejemplo de un LIB para LSRs.
Un router frontera lleva a cabo distintas funciones de análisis: mapear un
protocolo de la capa 2 del modelo OSI a MPLS, mapear MPLS a la capa 3 del modelo y
clasificar el tráfico con gran flexibilidad. Adicionalmente, un LER define qué tráfico
deberá ser tratado como MPLS y qué paquetes deberán tratarse como tráfico IP ordinario.
A diferencia de un encabezado IP, las etiquetas en MPLS no contienen una
dirección IP, sino más bien un valor numérico acordado entre dos nodos consecutivos
para proporcionar una conexión a través de un LSP. La etiqueta es un identificador corto
de longitud fija empleado para asociar un determinado FEC, normalmente de significado
local.
93
Algunas etiquetas o encabezados de determinados medios de transporte pueden
utilizarse como etiquetas de MPLS. Tal es el caso del identificador de ruta
virtual/identificador de circuito virtual (VPI / VCI) empleado en ATM y el
identificador de conexión de enlace de datos (DLCI) de Frame Relay. Otras
tecnologías, como Ethernet y enlaces punto a punto, requieren de una "etiqueta de
inserción" (shimlabel) que se ubica entre el encabezado de la capa de enlace de datos y el
encabezado de la capa de red (capas 2 y 3) del modelo OSI de un paquete. Aún cuando la
"etiqueta de inserción" no es parte de ninguno de estos encabezados, ésta provee un
medio de relación entre ambas capas.
Figura A.4: Esquema de una etiqueta MPLS
La etiqueta MPLS tiene una longitud de 32 bits divididos en cuatro secciones. Los
primeros 20 bits corresponden a la etiqueta en sí. Los 3 bits que siguen son considerados
de uso experimental. El siguiente bit es utilizado para denotar la presencia de "stack" y,
finalmente, los 8 bits restantes indican el tiempo de vida del paquete, es decir, un
parámetro que decrementa su valor por cada nodo recorrido hasta llegar a cero.
Obsérvese en la Figura A.4 cómo está compuesta la "etiqueta de inserción" y cuál es su
ubicación dentro de los paquetes IP.
A.3 Método de distribución de etiquetas
Es también importante conocer la forma en que se lleva a cabo la distribución de
etiquetas hacia los routers y los protocolos que pueden utilizarse para hacer esto. Un
router MPLS debe conocer las "reglas" para poder asignar o intercambiar etiquetas. Aún
cuando los routers convencionales suelen ser programados para determinar qué es lo que
harán con un determinado paquete, es preferible contar con una asignación dinámica de
reglas que permita mayor flexibilidad. Existen dos alternativas diferentes para hacer esta
distribución. Cuando los routers son capaces de "escuchar" estas reglas, crear una base de
datos interna y distribuir esta información a otros routers, sin necesidad de contar con un
administrador de etiquetas previamente designado, el control se hace de manera
independiente. La otra alternativa, preferida en MPLS, es el control ordenado. En este
método de distribución, el LER de salida es, por lo regular, el encargado de la
distribución de etiquetas, siendo este proceso en sentido contrario al direccionamiento de
paquetes. El control ordenado ofrece como ventajas una mejor Ingeniería de Tráfico y
94
mayor control de la red, aunque, en comparación con el control independiente, presenta
tiempos de convergencia mayores y el router de salida se convierte en el único punto
susceptible a fallas.
Figura A.5: Alternativas de distribución de etiquetas con control ordenado.
La distribución con control ordenado puede darse, a su vez, de dos maneras
distintas. Una alternativa consiste en distribuir las etiquetas sin que éstas sean solicitadas
por otros routers, desde el LER en el extremo de salida de la red y "empujándolas" hacia
arriba. Este método de distribución, conocido como transferencia de bajada no
solicitada ("downstream unsolicited”), puede hacerse cada determinado tiempo o cada
vez que cambie la Base de Información de Etiquetas de un router cualquiera. La segunda
opción, denominada transferencia de bajada por demanda ("downstream ondemand"), requiere que un router en particular solicite sus tablas, siendo éstas
posteriormente distribuidas por el LER de salida. Véase la Figura A.5.
Adicionalmente, existen dos métodos en que los routers retienen sus tablas de
etiquetas. En el modo conservativo, un router retiene exclusivamente las etiquetas que
necesita en ese momento. En el modo liberal, un LSR retiene todas las tablas que le
fueron asignadas, aún cuando éstas no le sean útiles en ese momento. Después de que
cada router posee sus tablas de etiquetas puede comenzar el direccionamiento de paquetes
a través de los LSPs preestablecidos por un determinado FEC.
Actualmente existe una amplia variedad de protocolos utilizados para la
distribución de etiquetas. La arquitectura MPLS no especifica uno de estos en particular,
sino que, más bien, recomienda su elección dependiendo de los requerimientos
específicos de la red. Los protocolos utilizados pueden agruparse en dos grupos:
95
protocolos de enrutamiento explícito y protocolos de enrutamiento implícito. El
enrutamiento explícito es idóneo para ofrecer Ingeniería de Tráfico y permite la creación
de túneles. El enrutamiento implícito, por el contrario, permite el establecimiento de
LSPs pero no ofrece características de Ingeniería de Tráfico.
El Protocolo de Distribución de Etiquetas (LDP) es uno de los protocolos de
enrutamiento implícito que se utilizan con frecuencia. LDP define el conjunto de
procedimientos y mensajes a través de los cuales los LSRs establecen LSPs en una red
MPLS. Otros protocolos de enrutamiento implícito incluyen al Protocolo de Compuerta
de Frontera (BGP) y al protocolo de Sistema Intermedio a Sistema Intermedio (ISIS).
Por otro lado, entre los protocolos de enrutamiento explícito más comunes
encontramos al protocolo LDP de Ruta Restringida (CR-LDP) y al Protocolo de
Reservación de Recursos con Ingeniería de Tráfico (RSVP-TE). El primero de estos
protocolos ofrece, en adición a LDP, características de Ingeniería de Tráfico, de manera
que sea posible negociar con anticipación una ruta en especial. Esto permite establecer
LSPs punto a punto con calidad de servicio en MPLS. CR-LDP es un protocolo de estado
sólido, es decir, que después de haberse establecido la conexión, ésta se mantiene
"abierta" hasta que se le indique lo contrario.
RSVP-TE opera de manera similar que CR-LDP, pues permite negociar un LSP
punto a punto que garantice un nivel de servicio de extremo a extremo. El protocolo es
una extensión de la versión original RSVP, aunque incorpora el respaldo para MPLS. A
diferencia de CR-LDP, este protocolo permite negociar una ruta para la transmisión de
información, misma que debe "refrescarse" constantemente para que ésta se mantenga
activa (estado blando). Mediante estos últimos protocolos y la aplicación de distintas
estrategias de ingeniería de tráfico es posible asignar diferentes niveles de calidad de
servicio en redes MPLS.
96
Apéndice B
Simple Network Management
Protocol (SNMP) & Management
Information Base (MIB)
B.1 SNMP y Management Information Base
El protocolo SNMP forma parte de la capa de aplicación y facilita el intercambio
de información de gestión entre elementos de la red y es parte del stack de protocolos
TCP/IP.
Una red administrada con SNMP consta de tres componentes básicos: estaciones
administradas, los agentes y la estación administradora NMS (Network Management
System).
Las estaciones administradas son elementos de red que contienen un agente
SNMP y pertenecen a la red administrada. Estos elementos pueden ser routers, switches,
hubs, impresoras, etc. y lo que hacen es recolectar y guardar información que hacen
disponible al NMS vía SNMP. El agente SNMP es un proceso de administración que
reside en la estación administrada
Cada agente mantiene uno o varias variables que describen su estado. En la
documentación SNMP, estas variables se llaman objetos. El conjunto de todos los objetos
posibles se da en la estructura de datos llamada MIB (Management Information Basebase de información de administración). La MIB es una colección de información que es
organizada jerárquicamente, y los objetos (también llamados MIBs) son accedidos por un
NMS usando SNMP .Este protocolo permite al NMS consultar el estado de los objetos
locales de un agente, y cambiarlo de ser necesario. La mayor parte de SNMP consiste en
este tipo de comunicación consulta-respuesta.
Sin embargo, a veces ocurren sucesos no planeados. Los nodos administrados
pueden caerse y volver a activarse, las líneas pueden desactivarse y levantarse de nuevo,
pueden ocurrir congestionamientos, etc. Cada suceso significativo se define en un
módulo MIB. Cuando un agente nota que ha ocurrido un evento significativo, de
inmediato le informa a todas las estaciones administradoras de su lista de configuración.
La seguridad y la validación de identificación desempeñan un papel
preponderante en el SNMP. Un NMS también tiene la capacidad de aprender mucho
sobre cada nodo que está bajo su control, y también puede apagarlos. Por lo tanto los
agentes tienen que estar seguros de que las consultas supuestamente originadas por la
estación administradora realmente vienen de la estación administradora. En el SNMPv1 y
SNMPv2, la estación administradora comprobaba su identidad poniendo una contraseña
(de texto normal) en cada mensaje. En el SNMPv3 se mejoró considerablemente la
seguridad usando técnicas criptográficas modernas.
97
B.2 ASN.1
Como ya se mencionó, el corazón del modelo SNMP es el conjunto de objetos
administrados por los agentes y leídos por la estación administradora. Para hacer posible
la comunicación multiproveedor, es esencial que estos objetos se definan de una manera
estándar y neutral desde el punto de vista de los proveedores. Es más, se requiere una
forma estándar de codificarlos para su transferencia a través de la red. Por esta razón, se
requiere un lenguaje de definición de objetos estándar, así como reglas de codificación.
El lenguaje usado por el SNMP se toma del OSI y se llama ASN.1 (Abstract Syntax
Notation One-notación de sintaxis abstracta uno).
Los tipos de datos básicos del ASN.1 se muestran en la Figura B.1.
Tipo primitivo
Significado
INTEGER
Entero de longitud arbitraria
BIT STRING
OCTET STRING
NULL
OBJECT IDENTIFIER
Cadena de 0 o más bits
Cadena de 0 o más bytes sin signo
Marcador de lugar
Tipo de datos definido oficialmente
Figura B.1: Tipos de datos básicos de ASN.1
Los OBJECT IDENTIFIER ofrecen una manera de identificar objetos. En
principio cada objeto definido en cada estándar oficial puede identificarse de manera
única. El mecanismo consiste en definir un árbol de estándares, y colocar cada objeto en
cada estándar en una localidad única del árbol. La parte del árbol que incluye la MIB del
SNMP se muestra en la figura NÚMERO.
El nivel superior lista todas las organizaciones de estándares importantes del
mundo y en los niveles bajos las organizaciones asociadas. Cada arco de la figura
NÚMERO tiene tanto un nombre como un número. Por tanto, todos los objetos de la
MIB de SNMP se identifican unívocamente por su nombre o número:
iso.identified.organization.dod.internet.private.enterprise.enterprise.cisco.temporaryvari
ables.AppleTalk.atInput. o por su equivalente 1.3.6.1.4.1.9.3.3.1.
Los proveedores pueden definir subconjuntos para administrar sus productos.
MIBs que no han sido estandarizados generalmente se posicionan dentro del
subconjunto experimental, 1.3.6.1.4.
Pero SNMP usa sólo algunas partes del ASN.1. Las partes del ASN.1 que usan el
SNMP se agrupan en un subconjunto, que recibe el nombre de SMI (Structure of
Management Information). El SM1 es en lo que en realidad describe la estructura de
datos del SNMP.
98
Esto es necesario ya que hay que definir algunas reglas si los productos de cientos
de proveedores han de hablar entre sí y realmente entender lo que dicen.
En el nivel más bajo, las variables SNMP se definen como objetos individuales.
Los objetos relacionados se reúnen en grupos, y los grupos se integran en módulos. Por
ejemplo existen grupos para los objetos IP y los objetos TCP. Un router puede
Figura B.2: Diferentes jerarquías asignadas a diferentes organizaciones.
Reconocer los grupos IP, dado que a su administrador le interesa tener
información por ejemplo de la cantidad de paquetes perdidos. Por otra parte, un router de
bajo nivel podría no reconocer el grupo TCP, dado que no necesita usar TCP para
desempeñar sus funciones de enrutamiento.
99
Todos los módulos MIB comienzan con una invocación de la macro MODULEIDENTITY que proporciona el nombre y la dirección del implementador, la historia de
modificaciones y otra información administrativa. Luego le sigue una invocación de la
macro OBJECT-TYPE que tiene cuatro parámetros requeridos y cuatro opcionales:
SYNTAX:
MAX-ACCESS:
escritura, lectura).
STATUS:
obsoleto)
DESCRIPTION:
define el tipo de datos de la variable
información de acceso a la variable (los más usados lecturaestado de la variable respecto a SNMP (los más usados actual y
cadena ASCII que indica lo que hace la variable.
Un ejemplo sencillo se da en la siguiente tabla. La variable se llama RouterID del
módulo OSPF y grupo ospfGeneralGroup que es usada en el software:
ospfRouterId ObjectType
Syntax
RouterID
MaxAccess
read-write
Status
current
Description
A 32-bit integer uniquely identifying
router in the Autonomous System.
the
By convention, to ensure uniqueness,
this
should default to the value of one of the
router's IP interface addresses.
Figura B.3: Ejemplo
También SM1 define una gran variedad de tablas estructuradas que son usadas
para agrupar objetos que tienen múltiples variables.
B.3 SNMP v1
SNMP v1 es la implementación inicial del protocolo SNMP. Es descrito en el
RFC 1157. Opera bajo protocolos tales como User Datagram Protocol (UDP), Internet
Protocol (IP), OSI Connectionless Network Service (CLNS), AppleTalk DatagramDelivery Protocol (DDP) y Novell Internet Packet Exchange (IPX). Esta versión es la
más extendida en su uso y es el protocolo de facto en la comunidad de Internet.
100
B.3.1 Operaciones Básicas
SNMP es un protocolo simple de consulta-respuesta. El NMS hace la consulta y
la estación administrada responde. Este comportamiento es implementado usando una de
las 4 operaciones del protocolo: Get, GetNext, Set and Trap.
Get
GetNext
Set
Trap
Usado por el NMS para consultar el valor
de una variable de un objeto.
Usado por el NMS para consultar el valor
de la siguiente variable de un objeto.
Usado por el NMS para setear valores de
un objeto.
Usado por los agentes para informar al
NMS de eventos significativos.
Figura B.4: Operaciones básicas de SNMP
B.4 SNMP v2
Es una evolución de la versión inicial. SNMP v2 ofrece muchas mejoras así como
opciones adicionales: GetBulk e Inform.
GetBulk
Inform
Usado por el NMS para consultar
eficientemente grandes cantidades de
datos, por ejemplo varias filas de una tabla.
Usado por el NMS para enviar traps a otro
NMS y obtener una respuesta.
Figura B.5: Mejoras en SNMP v2
101
Apéndice C
Ejemplo de Fairness con múltiples
caminos
C1
Ejemplo
Veremos ahora un ejemplo para que el usuario pueda entender mejor el
procedimiento llevado a cabo para aplicar el algoritmo de fairness con múltiples caminos
(es decir, para la búsqueda de la asignación de los flujos considerando que se toman todos
los caminos posibles para cada demanda). Vale destacar antes de exponerlo que dicho
ejemplo fue facilitado al grupo gracias a Paola Bermolen, quien nos ayudó en la
comprensión de los algoritmos de fairness.
Es también importante comentar que los valores expuestos fueron calculados
usando MatLab. Debajo de cada uno de los resultados hallados, exponemos también los
valores arrojados por NET-TE, de manera de poder así compararlos.
Empecemos mirando en la siguiente figura la topología a considerar en este
ejemplo.
Figura C.1: topología a usar en el ejemplo
Consideraremos 2 demandas, d = 1 y d = 2, tal que,
• d = 1 es entre los nodos 1 y 2
• d = 2 es entre los nodos 1 y 4
Si resolvemos el problema anterior encontramos 2 caminos posibles para cada
demanda.
Para la demanda d = 1 encontramos los posibles caminos:
P1 = {2}
y
P2 = {1,3} demanda1
Para la demanda d = 2 encontramos los posibles caminos:
P1 = {1, 4}
y
P2 = {2,3, 4} demanda 2
Si resolviéramos este problema siguiendo los pasos indicados por el algoritmo
llegaríamos al siguiente resultado:
102
x11 =1 en el camino P1 = {2}
x12 =1 en el camino P2 = {1,3}
x12 =1 en el camino P1 = {1, 4}
x22 =0 en el camino P2 = {2,3, 4}
dónde la notación xij representa el BW asignado a la demanda i por el posible camino j.
La demostración de cómo se llega a ese resultado se exhibe a continuación.
Empezamos observando que la cantidad total de BW asignado a la demanda 1
(X1) y a la demanda 2 (X2) es lo siguiente:
X 1 = x11 + x12 demanda 1
X 2 = x12 + x22 demanda 2
Si X es el vector de BW total, entonces X = ( X 1 , X 2 ) .
Si consideramos f ( x) = ( f1 ( x), f 2 ( x) ) = ( X 1 , X 2 ) , llegamos a que fi ( x) = X i .
El objetivo es el buscar un vector X 0 (= ( X 10 , X 20 )) ,
tal
que
f ( x0 ) ≥ LEX f ( x)
∀x ∈ Q
Las restricciones con las que trabajaremos son, expresadas en términos generales,
las siguientes:
∑ xdp = X d
d
∀demanda
 p

∀enlace
e
∑∑ δ edp xdp ≤ ce
d p
 x ≥ 0 ∀demanda
y todo camino
 dp
Lo anterior, aplicado a nuestro problema en particular, se traduce en:
x + x = X1
1
1
2
1
x12 + x22 = X 2
x12 + x12 ≤ 2
x11 + x22 ≤ 1
lo que nos lleva al primer cálculo de maximización:
x12 + x22 ≤ 2
x12 + x22 ≤ 1
xij ≥ 0
i = 1, 2
j = 1, 2
103
ℑ
max

1
2
ℑ ≤ x1 + x1
ℑ ≤ x1 + x 2
2
2

2
1
 x1 + x2 ≤ 2
* 1 2
 x1 + x2 ≤ 1
 x2 + x2 ≤ 2
2
 1
1
 x2 + x22 ≤ 1
 j
 xi ≥ 0 i = 1, 2
con
x ∈Q
j = 1, 2
Haciendo cuentas, 2ℑ ≤ x11 + x12 + x12 + x22 = ( x11 + x22 ) + ( x12 + x12 ) ≤ 3
≤1
≤2
2ℑ ≤ 3 ⇒ ℑ ≤ 1.5 ⇒ ℑ0 = 1 es el máximo (NET-TE en su caso arroja el valor 1).
Observar que hay múltiples valores de xij para los cuales se da que
f1 ( x) = f 2 ( x) = ℑ0 = 1
Por ejemplo,
a ) x11 = 1
x12 = 0
y
x =1
y
x =0
b) x11 = 0.5
y
x12 = 0.5
1
2
2
2
cumple con todas las restricciones y f1 ( x) = f 2 ( x) = ℑ0
También cumple con las restricciones. Además, siguen
x12 = 1
y
x22 = 0
habiendo más posibles soluciones.
Ahora que hayamos el máximo valor de ℑ , el siguiente paso es tratar de
maximizar cada demanda d por separado, y ver si puede hacerse más grande que ese
valor ℑ hayado anteriormente, con la restricción que no se vean afectadas el resto de las
demandas. Según el algoritmo, si encontramos alguna demanda la cual no se puede hacer
mayor que el valor de ℑ encontrado, entonces decimos que esa es una demanda
bloqueadora y la apartamos del grupo, guardando su índice en un conjunto aparte B.
Así entonces procedemos a elegir k = 1 (correspondiente a la demanda d = 1) y
testeamos:
max f1 ( x) = x11 + x12
max x11 + x12
 0

1
2
1
2
ℑ = 1 ≤ f 2 ( x) = x2 + x2 ⇒ 1 ≤ x2 + x2
x ∈ Q
x ∈ Q


104


La solución a problema LP anterior es: X 0 = 0.9214,1.0786,
0.9214,
0.0786

 x11

x12
x12
x22
(NET-TE en su caso arroja los valores [1, 1, 1, 0])
Si observamos cuanto quedo el X1 finalmente vemos que
f1 ( X 0 ) = 0.9214 + 1.0786 = 2 ≠ ℑ0 (= 1) , entonces aumento!
Pasamos ahora a resolver el problema LP para la segunda demanda (d = 2).
Eligiendo k = 2, testeamos:
max f 2 ( x) = x12 + x22

1
2
1 ≤ x1 + x1
x ∈ Q



0
lo cual nos lleva a la solución:
X 0 =  0.7436,
0.6066,
0.8663,
0.1337
 ⇒ f 2 ( X ) = 1
 x11

x12
x12
x22
(NET-TE en su caso arroja los valores [1, 0, 1, 0])
Esto demuestra que permaneció igual que el valor de ℑ hayado previamente.
No aumento!
Según el algoritmo, tenemos que pasar entonces el índice k = 2 al grupo B.
Por lo que, B = {2} y
B ' = {1}
con
t2B = ℑ0 = 1 , siendo B el conjunto que
contiene a las demandas que son bloqueadoras.
El siguiente paso es resolver el siguiente problema LP, tratando de hayar un
nuevo valor de ℑ , pero esta vez considerando las nuevas restricciones que surgen de
saber que las demandas bloqueadoras no pueden hacerse mayores a determinado valor.
Resolvemos:
ℑ
max

1
2
ℑ ≤ x1 + x1
1 ≤ x1 + x 2
ℑ
max
2
2


2
1
1
2

2
x
x
+
≤
ℑ ≤ f1 ( x) = x1 + x1
 1
2
⇒


1
2
B
1
2
1 = t2 ≤ f 2 ( x) = x2 + x2
 x1 + x2 ≤ 1
x ∈ Q
 x2 + x2 ≤ 2

2
 1
1
 x2 + x22 ≤ 1
 j
 xi ≥ 0 i = 1, 2
j = 1, 2
Resolviendo, obtenemos un ℑ = 2 (NET-TE arroja el mismo valor).
¿Hay una solución tal que f1 ( x) = x11 + x12 = 2 ?
105
La repuesta es Si:
x11 = x12 = 1
x12 = 1
y
x22 = 0
Debemos ver ahora si se pueden maximizar las demandas que quedan en el
conjunto B’ de manera que sean mayores que el valor de ℑ hayado previamente.
Haciendo el test siguiente para k = 1
( B = {2}
y
B ' = {1}
t2B = 1) , lo
averiguamos:
max f1 ( x) = x11 + x12
max x11 + x12
B

1
2
1
2
t2 = 1 ≤ f 2 ( x) = x2 + x2 ⇒ 1 ≤ x2 + x2
x ∈ Q
x ∈ Q




La solución obtenida es: X = 0.9214,1.0786,
0.9214,
0.0786

 x11

x12
x12
x22
(NET-TE en su caso arroja los valores [1, 1, 1, 0]).
Como podemos apreciar, X1 es igual a 2. Por lo tanto no se pudo hacer mayor que
el último valor de ℑ hayado.
Pasamos como es debido el índice k = 2 al conjunto B. Tenemos entonces que
t =2.
B
1
El conjunto B’ ha quedado entonces vació. Hemos llegado entonces al fin del
algoritmo y hayado la solución final del vector de asignación X.
La solución final es: t1B = 2 y t2B = 1 . O lo que es igual, X = (2, 1), con cada
camino para cada demanda teniendo el siguiente BW:
x11 =1 en el camino P1 = {2}
x12 =1 en el camino P2 = {1,3}
x12 =1 en el camino P1 = {1, 4}
x22 =0 en el camino P2 = {2,3, 4}
En el caso de NET-TE, arroja los mismos valores que los señalados
anteriormente.
106
Apéndice D
Software
Las acciones principales que pueden realizarse en el simulador se encuentran
distribuidas en el menú Archivo, en la barra de herramientas debajo del menú Archivo y
en la barra vertical a la derecha. Una vez iniciado el programa se visualizará una ventana
principal como se muestra a continuación en la Figura D.1.
Figura D.1: Ventana principal.
Dentro del menú Archivo se encuentran las opciones:
•
•
Abrir, para abrir un archivo mediante el método abrirArch() de la clase Principal.
Nuevo, para crear un nuevo archivo mediante el método nuevoArch() de la clase
Principal.
107
•
•
•
Guardar y Guardar como, para guardar un archivo, mediante los métodos
guardarArch() y guardarNeverSaved() de la clase Principal.
Cerrar, para cerrar una archivo usando el método cerrarArch() de la clase Principal.
Salir, para salir del programa usando el método processWindowEvent(WindowEvent
e) de la clase Principal.
Dentro de la barra de herramientas las opciones son:
•
•
•
•
Abrir,
para
abrir
un
archivo
mediante
el
método
botonOpen_actionPerformed(ActionEvent e) de la clase Principal.
Nuevo,
para
crear
un
nuevo
archivo
mediante
el
método
botonNew_actionPerformed(ActionEvent e) de la clase Principal.
Guardar,
para
guardar
un
archivo,
mediante
el
método
botonSave_actionPerformed(ActionEvent e) de la clase Principal.
Crear matriz de tráfico, para crear un archivo de una matriz de tráfico mediante el
método botonRuteo_actionPerformed(ActionEvent e) la clase Principal.
D.1 Menú Archivo y Barra de Herramientas
Abrir:
Es posible abrir un archivo existente por medio de la barra de herramientas o por
el menú Archivo. Por defecto los archivos que se muestran para abrir son aquellos cuya
extensión sea .txt. Se puede elegir para que muestre los archivos con extensión .arc o
todos los archivos. Esto se logró definiendo las clases ArcFileFilter y TxtFileFilter
pertenecientes al package Programa, las cuales heredan de la clase
javax.swing.filechooser.FileFilter_.
Al producirse un evento sobre el ítem que llama al método abrirArch() de la clase
Principal, se chequea si hay algún archivo abierto. Si lo hay, se hace una llamada el
método cerrarArch() de la clase Principal.
En caso que no halla algún archivo abierto o que se halla cerrado el archivo
abierto (aprovado=true), se despliega una ventana por la cual el usuario puede navegar a
través del sistema de archivos con el fin de seleccionar el deseado. Si el archivo
seleccionado es con extensión .arc el método abrirArch() llama al método cargar().
Después de haber elegido el archivo y de haber presionado Abrir se intenta abrir.
En caso que se logre realizar dicha acción, se muestra el contenido en la pantalla.
Además se escribe la ruta de acceso del archivo en la barra de Título y se guarda
la ruta de acceso al archivo seleccionado para que las futuras ventanas de diálogo del tipo
javax.swing. JFileChooser se inicien en dicho directorio.
Nuevo:
Es posible crear un nuevo archivo por medio de la barra de herramientas o por el
menú Nuevo. Para ello se debe realizar un evento sobre alguno de los ítems que llama al
método nuevoArch() de la clase Principal. Al llamar a este método, se chequea si hay
algún archivo abierto. En caso que lo halla, se llama al método cerrarArch() de la clase
108
Principal. En caso que este método devuelva aprovado=true, se genera un nuevo
archivo. Si aprovado=false el programa no realizará acción alguna, volviendo al estado
anterior al llamado del método nuevoArch() de la clase Principal.
Guardar y GuardarComo:
Es posible guardar un archivo por medio de la barra de herramientas Guardar o
por el menú Guardar o GuardarComo.
Hay doy formas distintas para guardar archivos de configuración. En caso que se
elija el ítem Guardar, se llama el método guardarArch() de la clase Principal. Este
chequea si el archivo ha sido anteriormente guardado mediante el atributo booleano
neverSaved de la clase Principal. En caso que su valor sea true, se llama al método
guardarNeverSaved() de la clase Principal quien dará la opción al usuario de elegir la
ubicación y el nombre con el que desee guardar el archivo. Si el archivo ya ha sido
guardado (neverSaved=false) se llama al método guardarSaved() de la clase Principal
que sobrescribe el archivo existente. En la figura 3 puede verse el diagrama de
colaboración del método guardarArch() de la clase Principal. Las acciones realizadas al
llamar guardarNeverSaved() de la clase Principal son similares.
Si el evento se realiza sobre GuardarComo, se invocará el método
guardarNeverSaved() de la clase Principal.
Si el archivo que se quiere guardar es con extensión .arc los métodos
guardarSaved() y guardarNeverSaved() llaman al método salvar().
Cerrar:
Para cerrar un archivo es necesario realizar un evento que llame al método
cerrarArch() de la clase Principal. Esto se puede hacer seleccionando Cerrar en el menú
Archivo.
En caso que halla algún archivo abierto se da la elección de:
•
•
•
salvar y cerrar
cerrar sin salvar
cancelar
Si se elige la primera opción y el archivo nunca ha sido guardado se llama al
método guardarNeverSaved() de la clase Principal. Si ya ha sido guardado se llama al
método guardarSaved() de la clase Principal. Luego se llama al método clear() de la
clase Principal. En caso de elegir cerrar sin salvar se llama directamente al método
clear() de la clase Principal. Si se presiona en Cancelar no se realiza acción alguna.
Salir
Al seleccionar este ítem, se genera el evento, presionado del botón salir, el cual es
tomado por el método salirArch_actionPerformed(e) de la clase Principal, que a su vez
invoca al método processWindowEvent(WindowEvent e) de la clase Principal, método
109
que se encarga de cerrar el programa dando las opciones correspondientes para guardar
un archivo abierto.
D.2 Crear matriz de tráfico
Después de tener una topología de la red, es posible crear una matriz de tráfico.
, se llama al método
Al realizar un evento sobre el ítem
botonRuteo_actionPerformed(ActionEvent e) de la clase Principal el cual crea una
instancia de la clase GeneroMT.
En la clase GeneroMT se configuran los parámetros de cada ruta de la matriz de
tráfico.
En esta clase dentro del método jbInit() se llenan los combo de nodo origen, nodo
destino con el vector nodes el cual contiene todos los nodos de la red y el combo afinidad
se llena con las afinidades de todos los enlaces que se encuentran en links.afinidad.
Después de asignar los parámetros de cada ruta:
•
•
•
•
BW deseado: jTextFieldNombre.getText()
Nodo Origen: comboNodoOrigen_actionPerformed(ActionEvent e)
Nodo Destino: comboNodoDestino_actionPerformed(ActionEvent e)
Afinidad: comboAfinidad_actionPerformed(ActionEvent e)
se crea la ruta al apretar el botón Agregar que llama al método
jButtonInsertar_actionPerformed(ActionEvent e).
Si se desea modificar una ruta ya creada, se debe seleccionar la ruta y después de
hacer las modificaciones deseadas se debe apretar el botón Cambiar que llama al método
jButtonEditar_actionPerformed(ActionEvent e).
Si se desea borrar una ruta se debe apretar el botón Borrar que llama al método
jButtonBorrar _actionPerformed(ActionEvent e).
Si se desea modificar una matriz de tráfico ya creada, se debe apretar el botón
Cargar que llama al método jButtonCargar_actionPerformed(ActionEvent e) que a su ves
llama al método stringToVectors de la clase InterpreteMT.
Para crear la matriz de tráfico se debe apretar el botón Guardar que llama al
método jButtonGuardar_actionPerformed(ActionEvent e) que a su ves llama al método
guardarArch() el cual llama al método EditarTexto de la clase InterpreteMT.
D.3 Barra Vertical
Dentro de la barra vertical las opciones son:
Cargar
red,
para
cargar
la
topología
de
red
carConfActionPerformed(ActionEvent e) el método de la clase VentanaConf.
•
LER,
para
crear
un
LER
mediante
el
botonLER_actionPerformed(ActionEvent e) de la clase VentanaConf.
•
LSR,
para
crear
un
LSR
mediante
el
botonLSR_actionPerformed(ActionEvent e) de la clase VentanaConf.
•
110
mediante
método
método
LINK,
para
crear
un
LINK
mediante
el
método
botonLink_actionPerformed(ActionEvent e) de la clase VentanaConf.
•
Eliminar, para
eliminar el objeto seleccionado mediante el método
botonDel_actionPerformed(ActionEvent e) de la clase VentanaConf.
•
Atrás/Adelante, para deshacer la última acción realizada mediante los métodos
restBack() y restForw()de la clase VentanaConf.
•
LSP explicito, para crear un LSP manualmente mediante el método
crearLspActionPerformed(ActionEvent e) de la clase VentanaConf.
•
CSPF, para crear un LSP con la menor métrica posible mediante el método
botonCSPFActionPerformed(ActionEvent e) de la clase VentanaConf.
•
Fair Network, para crear los LSPs de la matriz de tráfico elegida mediante el método
botonMTActionPerformed(ActionEvent e) de la clase VentanaConf.
•
MIRA, para crear los LSPs de la matriz de tráfico elegida mediante el método de
botonMIRAActionPerformed(ActionEvent e) de la clase VentanaConf.
•
Lista de LSPs, para mostrar la lista de LSPs creados mediante el método
listaLsps_actionPerformed(ActionEvent e) de la clase VentanaConf.
•
Borrar LSP, para borrar el LSP seleccionado mediante el método
borrarLspActionPerformed(ActionEvent e) de la clase VentanaConf.
•
Estadísticas, para mostrar las estadísticas de la topología de red mediante el método
botonEstadActionPerformed(ActionEvent e) de la clase VentanaConf.
•
Utilización, para mostrar en pantalla la utilización de los enlaces mediante el método
botonUtilActionPerformed(ActionEvent e) de la clase VentanaConf.
•
A continuación se detallan los métodos de la lista anterior más significativos.
botonCSPFActionPerformed(ActionEvent e) crea una instancia de la clase CSPF.
En la clase CSPF primero se debe indicar el BW, nodo origen, nodo destino, la métrica y
el criterio TE a utilizar y es opcional indicar afinidad, enlace presenten y enlace ausente.
En esta clase dentro del método jbInit() se llenan los combo de nodo origen, nodo
destino, con el vector nodes el cual contiene todos los nodos de la red, los combos enlace
presente y enlace ausente se llenan con todos los enlaces de la red que se encuentran en el
vector links y el combo afinidad se llena con las afinidades de todos los enlaces que se
encuentran en el vector afinidad de la clase Link.
Luego al oprimir el botón Aplicar Algoritmo, se llama al método
jButtonAlgoritmo_actionPerformed(ActionEvent e). Este método primero se fija en la
variable booleana pinto. Ver Figura D.2.
111
Figura D.2: Diagrama de razonamiento al apretar el botón Algoritmo.
Si pinto=false es porque se selecciono enlace presente. Supongamos que el enlace
seleccionado esta conectado al nodo A y al nodo B. Para calcular los caminos posibles es
necesario llamar 4 veces al método shortestPath de la clase Algoritmo. Porque hay que
calcular el camino mas corto entre nodo origen y el nodo A, llamando al método
shortestPath de la clase Algoritmo y hay que calcular el camino mas corto entre nodo
destino y el nodo B, llamando al método shortestPath de la clase Algoritmo. Sumo las
dos distancias calculadas. Se hace el mismo procedimiento pero ahora entre el nodo
destino y el nodo A y entre el nodo origen y el nodo B. Se compara la distancia calculada
en el primer caso con la del segundo caso y se queda con la menor.
Si se encontró más de un camino posible se puede observar en pantalla los
distintos caminos encontrados al oprimir la flecha hacia la derecha que llama al método
jButtonAdelante_actionPerformed(ActionEvent e). Después de oprimir la flecha hacia la
derecha se puede ir hacia atrás al oprimir la flecha hacia la izquierda que llama al
método jButtonAtras_actionPerformed(ActionEvent e).
El método jButtonAceptar_actionPerformed(ActionEvent e), crea un LSP del
camino seleccionado con los dos métodos anteriormente mencionados, lo agrega en el
combo de LSPs y actualiza el ancho de banda reservado de cada enlace que pertenece al
camino calculado.
botonMIRAActionPerformed(ActionEvent e) crea una instancia de la clase
OfflineMira.
En la clase OfflineMira, para cargar el archivo de la matriz de tráfico se llama al
método jButtonCargar_actionPerformed(ActionEvent e) el cual llama al método
stringToVectors de la clase InterpreteMT. Luego al oprimir el botón Correr que llama al
método jButtonCorrer_actionPerformed(ActionEvent e) en donde se crea una instancia a
la clase MIRA. En la clase MIRA se llama al método hallamaxflows para calcular el
máximo ancho de banda entre los nodos, luego este método llama al método hallpesos
que calcula los pesos que asocia a cada enlace. Luego de asignar a todos los enlaces su
nuevo peso, dentro de la clase OfflineMira se llama al método correr, que para cada ruta
de la matriz de tráfico cargada llama al método podar, luego llama al método
shortestPath de la clase Algoritmo, para calcular un camino para cada ruta y guardar el
resultado en el array de vectores resultuno.
El método jComboBox_actionPerformed(ActionEvent e), pinta los enlaces por los
cuales pasa la ruta seleccionada en el combo Rutas posibles.
112
El método jButtonAceptar_actionPerformed(ActionEvent e), crea un LSP para
cada ruta, lo agrega en el combo de LSPs y actualiza el ancho de banda reservado de cada
enlace que pertenece al camino calculado.
botonMTActionPerformed(ActionEvent e) crea una instancia de clase
FairnessNetwork.
En la clase FairnessNetwork, para cargar el archivo de la matriz de tráfico se
llama al método jButtonCargar_actionPerformed(ActionEvent e) el cual llama al método
stringToVectors de la clase InterpreteMT. Luego se debe el elegir uno de los siguientes
algoritmos:
•
•
•
•
Fairness básico
Fairness acotado
Fairness con múltiples caminos
Fairness con mult. caminos acotado
Si se eligió unos de los 2 primeros algoritmos se debe elegir la métrica entre peso
o minhop.
Al marcar Elegir camino manualmente se puede elegir entre todos los caminos
con la menor métrica posible calculados de cada ruta, con cual quedarse. Esto se hace
llamando al método jCheckBox4_actionPerformed(ActionEvent e) que llena el combo
Lista de rutas con todas las rutas de la matriz de tráfico. Al seleccionar una ruta de este
combo se llama al método podar, luego al método shortestPath de la clase Algoritmo, se
llena el combo de Caminos posibles con los caminos calculados. Al seleccionar un
camino del combo se guarda los enlaces por donde pasa el camino seleccionado en el
vector enlacesGr de la clase Caminos.
Para correr los algoritmos se debe oprimir el botón Correr que llama al método
jButtonCorrer_actionPerformed(ActionEvent e). Este método primero se fija que
algoritmo se selecciono, esto lo hace fijándose cual JCheckBox fue seleccionado.
Si se eligió el algoritmo1, entonces JcheckBox().isSelected=trae. Ver Figura D.3.
Figura D.3: Diagrama de razonamiento al elegir el algoritmo a correr.
113
Si se eligió el algoritmo2, entonces JcheckBox1().isSelected=true . Se crea una
instancia de la clase Requerimientos, en donde se configuran la demanda mínima y la
prioridad del camino. Ver Figura D.4.
Figura D.4: Diagrama de razonamiento si se elige el Algortmo 2.
Si no se marca Elegir camino manualmente, el método correr llama para cada
ruta de la matriz de tráfico cargada al método podar, luego al método shortestPath de la
clase Algoritmo, si hay mas de un camino posible llama al método podar2 de la clase
Algoritmo y guarda un camino para cada ruta.
El método buscar, busca cuantos caminos pasan por cada enlace y lo guarda en la
variable delta de la clase Link.
El método mínimo calcula t, que es el paso en que se incrementa el ancho de
banda reservado de cada enlace por camino que pasa por él. Esto continúa hasta que
satura algún enlace. Al saturar un enlace se sacan todos los caminos que pasan por ese
enlace y se fija el ancho de banda del camino. Termina cuando se fijan todos los anchos
de banda de cada camino.
Si se eligió el algoritmo 3, entonces JcheckBox()2.isSelected=true o si se eligió el
algoritmo 4, entonces JcheckBox()3.isSelected=true.
Figura D.5: Diagrama de razonamiento si se elige el Algoritmo 3.
114
El método calculatodos, calcula todos los caminos posibles entre el nodo origen y
el nodo destino sin considerar BW, métrica ni afinidad.
El método OptimizacionLineal, calcula el valor de la variable auxiliar tau.
El método OptimizacionLinealChequeo, maximiza de a una demanda y compara
su valor con el valor de la variable auxiliar tau calculado en OptimizacionLineal.
Los métodos OptimizacionLineal y OptimizacionLinealChequeo son los
encargados de maximizar las demandas, asignando a cada sub-demanda el ancho de
banda calculado. El ancho de banda final de cada demanda es la suma de los anchos de
banda de todas sus sub-demandas.
Si se eligió el algoritmo 4, después de tener el ancho de banda final de cada
demanda se llama al método ordenar, que ordena de mayor a menor las sub-demandas de
cada demanda según su ancho de banda. Esto se hace para asignar a las demandas que su
ancho de banda final es mayor que su ancho de banda deseado, asignarle como ancho de
banda final el ancho de banda deseado.
El método jComboBox_actionPerformed(ActionEvent e), pinta los enlaces por los
cuales pasa la ruta seleccionada en el combo Lista de rutas. Si la ruta tiene subdemandas
permite mostrar en pantalla cada una de ellas por separado.
El método jButtonAceptar_actionPerformed(ActionEvent e), crea un Lsp para
cada ruta, lo agrega en el combo de LSPs y actualiza el ancho de banda reservado de cada
enlace que pertenece al camino calculado.
115
Bibliografía
[1] NetScope: Traffic Engineering for IP Networks. Paper de AT&T Labs. Autores:
Anja Feldmann, Albert Greenberg, Carsten Lund, Nick Reingold y Jennifer
Rexford. Marzo 2000.
[2] Request for Comments (RFC): 3272. Visión y Principios de la Ingeniería de
Tráfico en Internet. Autores: D. Awduche, A. Chiu, A. Elwalid, I. Widjaja, X.
Xiao. Mayo 2002.
[3] MPLS: Technology and Applications. Capítulo 7: Constraint-Based Routing.
Autores: Bruce Davie y Yakov Rekhter. Año 2000.
[4] Engineering Internet QoS. Capítulo 12: Future. Autores: Sanjay Jha y Mahbub
Hassan. Año 2002.
[5] Data Networks: Routing, Security, and Performance Optimization. Capítulo 8:
Quality of Service. Autor: Tony Kenyon. Año 2002.
[6] Minimum interference routing with applications to MPLS traffic engineering.
Proceedings of International Workshop on QoS, Pennsylvania. Autores: M.
Kodialam y T.V.Lacksham. Junio 2000.
[7] A New Bandwidth Guaranteed Routing Algorithm for MPLS Traffic
Engineering. Autores: Bin Wang, Xu Su y C.L. Philip Chen. Noviembre 2002.
[8] Network Flows. Autores: R.K Ahuja, T.L Magnanti y J.B. Orlin . Prentice Hall.
Año 1993.
[9] Multi-terminal network flows, Journal of SIAM. Autores: R.E. Gomory y T.C.
Hu. Año 2002.
[10] Routing, Flow and Capacity Design in Communication and Computer
Networks. Capítulo 8: Fair Networks. Autores: Michal Pioro y Deepankar
Medhi. Año 2004.
116
Glosario de términos
ARCA: Analizador de Redes de Caminos Virtuales, software que analiza el problema de
brindar garantías de Calidad de Servicio (QoS) así como realizar Ingeniería de Tráfico sobre redes de
datos.
AS: Autonomous System, áreas que en su conjunto modelan a una red y dentro de las cuales las
rutas son determinadas por el ruteo intradominio.
ASN.1: Abstract Syntax Notation 1, lenguaje de definición de objetos estándar usado por SNMP.
BGP: Border Gateway Protocol, protocolo de ruteo interdominio.
CBR: Constraint Based Routing, ruteo que intenta encontrar un camino que optimice cierta
métrica escalar y al mismo tiempo no viole un conjunto de restricciones.
CLNS: OSI Connectionless Network Service, protocolo bajo el cual opera SNMP v1.
CR-LDP: Constraint Route LDP, protocolo de distribución de etiquetas del tipo enrutamiento
explícito que ofrece características de Ingeniería de Tráfico.
CSPF: Constraint Shortest Path First, algoritmo para la computación de caminos que toma en
cuenta al mismo tiempo un conjunto de restricciones.
DDP: AppleTalk Datagram-Delivery Protocol, protocolo bajo el cual opera SNMP v1.
DLCI: Data Link Connection Identificator, ejemplo de etiqueta o encabezado que pueden
utilizarse como etiqueta de MPLS.
FEC: Forwarding Equivalence Class, representación de un conjunto de paquetes que comparten
los mismos requerimientos para su transporte en MPLS.
IETF: Internet Engineering Task Force, grupo de trabajo dedicado en su mayoría al control del
tráfico en lo que a la ingeniería de tráfico se refiere.
IPX: Novell Internet Packet Exchange, protocolo bajo el cual opera SNMP v1.
IS-IS: Intermediate System to Intermediate System, protocolo de ruteo intradominio.
ISP: Internet Service Provider, proveedor de acceso a Internet.
LDP: Label Distribution Protocol, protocolo responsable de que el LSP sea establecido para que
sea funcional mediante el intercambio de etiquetas entre los nodos de la red.
LER: Label Edge Router, router encargado de la distribución de etiquetas.
LIB: Label Information Base, tabla de conectividad contra la cual es examinada y comparada la
etiqueta MPLS al llegar del LER al LSR, determinando la acción a seguir.
LSP: Label Switched Paths, ruta que sigue un paquete entre dos nodos de la red MPLS.
LSR: Lable Switch Router, router encargado de dirigir el tráfico dentro de la red MPLS.
MIB: Management Information Base, colección de información organizada jerárquicamente
donde los objetos son accedidos usando SNMP y la cual reside en el elemento de red.
MIRA: Minumum Interference Routing Algorithm, algoritmo de ruteo de caminos que
intenta minimizar la “interferencia” que provoca el establecimiento de un nuevo camino a potenciales
nuevos caminos que son desconocidos.
MMF: Max-Min Fairness, principio de asignación usado para formular el esquema de asignación
de recursos en donde se intenta asignar la mayor cantidad de recursos a cada demanda, al mismo tiempo
que se intenta mantenerlos lo más similares posible.
MNF: Maximum Network Flow, máximo ancho de banda que puede traficar la red entre
determinado par de nodos ya sea por un único camino o varios.
MPLS: Multi Protocol Label Switching, tecnología de ruteo y reenvío de paquetes en redes IP
que se basa en la asignación e intercambio de etiquetas, que permiten el establecimiento de caminos a
través de la red.
NET-TE: Networking Traffic Engineering, nombre del software diseñado en este proyecto que
hace alusión a la Ingeniería de Tráfico en redes; tema principal de éste trabajo.
117
NMS: Network Management System, estación administradora o, lo que es similar, elemento de
red que contiene un agente SNMP y pertenece a la red administrada.
QoS: Quality of Service, distintos niveles de servicio que son ofrecidos al cliente en términos del
ancho de banda o algún otro parámetro.
RSVP-TE: Reservation Protocol with Traffic Engineering, protocolo de enrutamiento
explícito. En éste caso en particular, es una extensión de la versión original RSVP que incorpora el
respaldo para MPLS.
SDP: Shortest Distance Path, ruteo basado en preservar los recursos de la red por medio de la
selección de los caminos más cortos.
SLA: Service Level Agreement, acuerdo sobre el nivel de servicio con el cliente donde se
especifican parámetros como performance, confiabilidad y seguridad.
SMI: Structure of Management Information, partes del ASN.1 que usan SNMP. Es lo que en
realidad describe la estructura de datos del SNMP.
SNMP: Simple Network Management Protocol, protocolo de la capa de aplicación que
facilita el intercambio de información de gestión entre elementos de la red y es parte del stack de
protocolos TCP/IP.
SWP: Shortest Widest Path, ruteo que se basa en la búsqueda del camino con el ancho de banda
más grande y, en caso de haber múltiples caminos, se queda con el que tiene la mínima cantidad de saltos.
TE: Traffic Engineering, disciplina que procura la optimización de la performance de las redes
operativas.
TED: Traffic Engineering Especialized Data Base, base de datos contenida en cada router, la
cual mantiene atributos de los enlaces de la red e información de la topología.
UDP: User Datagram Protocol, protocolo de transporte que provee servicios de datagramas por
encima de IP.
VPI/VCI: Virtual Circuit Identificator used in ATM, etiqueta o encabezado que puede
utilizarse como etiqueta de MPLS en redes ATM.
WSP: Widest Shortest Path, ruteo que se basa en la búsqueda de caminos con el mínimo número de
saltos y, si encuentra múltiples caminos, se queda con el que tiene ancho de banda mayor.
118