Ingeniera de Trfico en

Redes MPLS














Proyecto Final de Carrera

Integrantes: Adrin Delfino, Sebastin Rivero, Marcelo San Martn
Tutor: Ing. Pablo Belzarena
Instituto de Ingeniera Elctrica
Facultad de Ingeniera de la Repblica
2
Prefacio

El presente documento constituye la documentacin final del Proyecto de Fin de
Carrera titulado Ingeniera de Trfico en Redes MPLS, realizado para el Instituto de
Ingeniera Elctrica de la Facultad de Ingeniera, Universidad de la Repblica. Los
integrantes del grupo de trabajo son Sebastin Rivero, Adrin Delfino y Marcelo San
Martn. Todos ellos, estudiantes de Ingeniera, opcin Telecomunicaciones.
El proyecto en cuestin se llevo a cabo en el perodo comprendido entre Marzo de
2004 y Agosto de 2005, bajo la tutora del Ing. Pablo Belzarena.
El objetivo del proyecto fue desarrollar una herramienta de software que permite
al usuario realizar lo siguiente: disear la topologa de la red a su gusto por medio de una
interfaz grfica, tanto de manera manual o cargndola de manera automtica 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 visualizacin del estado
actual de la red. En cuanto a los mtodos de bsqueda de caminos, se utiliz el
establecimiento explcito del LSP por parte del usuario, CSPF (Constraint Shortest Path
First), una versin modificada del algoritmo MIRA (Minumum Interference Routing
Algorithm) y algoritmos usados en las llamadas Fair Networks que se explicarn ms
adelante.
El trabajo se divide en 4 partes. Primero se presenta el Objetivo del proyecto, la
Motivacin que llevo a su creacin y una breve descripcin de cmo est organizado el
mismo. Luego se presentan los conceptos principales sobre TE (Traffic Engineering) de
manera que el lector este familiarizado con los conceptos bsicos en los que se basa ste
proyecto. A continuacin pasamos a una segunda parte donde exponemos las principales
herramientas tericas 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 documentacin se adjunta un disco compacto conteniendo:

El archivo instalador del software NET-TE.
Un Manual del Usuario.
Documentacin completa del Proyecto.
Documentacin del cdigo de software (JavaDoc).

Agradecimientos:

A nuestro tutor, Pablo Belzarena
3
A Paola Bermolen, por su amable ayuda en la compresin de los
algoritmos de Fair Networks.
Al grupo de proyecto del EasySim (Mauricio Garca, Gastn Madruga y
Vctor Paladino) por brindarnos su proyecto como base para la interfaz
grfica del nuestro.




























4
ndice General

I Presentacin del Problema

1. Introduccin y objetivos 8
1.1. Objetivos del proyecto 8
1.2. Motivacin 9
1.3. Especificacin funcional del proyecto 12
1.4. Esquema organizacional del proyecto 14

2. Casos de Uso 16
Caso de Uso#1: Construccin de la topologa 16
Caso de Uso#2: Establecimiento de los LSPs 18
Caso de Uso#3: Visualizacin del estado actual de la red 25

3. Ingeniera de Trfico 27
3.1. Introduccin 27
3.2. Componentes de la Ingeniera de Trfico 28


II Principios y Bases tericas


4. Constraint Shortest Path First (CSPF) 32
4.1. Principios bsicos de CBR ........ 32
4.2. CSPF 33
4.3. Ruteo basado en QoS. WSP y SWP 34

5. Minimum Interference Routing Algorithm (MIRA) 37
5.1. Presentacin del algoritmo 37
5.2. Modelado del sistema 38
5.3. Algoritmo propuesto 38

6. Redes Justas (Fair Networks) 40
6.1. Introduccin 40
6.1.1. Nociones de Justicia 41
6.2. Algoritmo 1: Max-Min Fairness bsico para caminos fijos 41
6.2.1. Formulacin completa del Algoritmo 1 42
6.2.2. Pasos para resolver el Algoritmo 1 43
6.3. Algoritmo 2: Max-Min Fairness para caminos fijos con cotas 44
6.3.1. Formulacin del Algoritmo 2 44
6.3.2. Pasos para resolver el Algoritmo 2 45
6.4. Algoritmo 3: Max-Min Fairness para mltiples caminos 46
6.4.1. Pasos para resolver el Algoritmo 3 (usando NBT1) 48
6.5. Algoritmo 4: Max-Min Fairness para mltiples caminos acotado ... 49
5
III Arquitectura de Software


7. Representacin de la red e interaccin con ARCA 52
7.1. El package topologa 52
7.2. La clase Elemento 54
7.3. Las clases LER y LSR 54
7.4. La clase Link 54
7.5. La clase LSP 54
7.6. El Package Arca.InterfazGrfica 54
7.6.1. Compatibilidad con ARCA Analizador de Redes de Caminos
Virtuales 55

8. Interfaz Grfica 57
8.1. El package Programa 57
8.2. Clase Principal y VentanaConf 58
8.3. Clase Intrprete 59
8.4. Clases TxtFileFilter y ArcFileFilter 60
8.5. Clase ConfLink 61
8.6. Clase Cargar topologa 62
8.7. Clases Estadsticas y Propiedades 62
8.8. Clase Utilizacin 64

9. Carga automtica de la topologa 65
9.1. El package CargarRed Implementacin 65

10. Computacin de caminos 70
10.1. El package CrearLSPs 70
10.2. La clase Ruteo Explcito 71
10.3. La clase CSPF 72
10.4. La clase Algoritmo 75
10.5. La clase CarConf 76
10.6. La clase MIRA 77

11. Algoritmos de justicia y el MIRA 78
11.1. El package MT 78
11.2. La clase Caminos 79
11.3. La clase InterpreteMT 79
11.4. La clase GeneroMT 80
11.5. La clase FairnessNetwork 81
11.6. La clase LasDemandas 83
11.7. La clase OfflineMira 84



6
IV Conclusiones


12. Conclusiones y tareas a futuro 87
12.1. Supuestos y objetivos 87
12.2. Conclusiones 88
12.3. Tareas a futuro 89


APNDICES

A. Multi Protocol Label Switching (MPLS) 91
A.1. Descripcin funcional de MPLS 91
A.2. Componentes y funcionamiento de una red 92
A.3. Mtodo de distribucin de etiquetas 94

B. Simple Network Management Protocol (SNMP) & Management
Information Base (MIB) 97
B.1. SNMP y Management Information Base 97
B.2. ASN.1 98
B.3. SNMP v1 100
B.3.1. Operaciones bsicas 101
B.4. SNMP v2 101

C. Ejemplo de Fairness con mltiples caminos 102
C.1. Ejemplo 102

D. Software 107
D.1. Men Archivo y Barra de Herramientas 108
D.2. Crear Matriz de Trfico 110
D.3. Barra Vertical 110

Bibliografa 116

Glosario de trminos 117











7












Parte I


Presentacin del Problema




















8
Captulo 1

Introduccin y Objetivos

En este captulo 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 cul 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
Ingeniera de Trfico 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 especfico fue el formar una slida base terica sobre MPLS y
TE (Traffic Engineering), entendiendo la razn de su existencia y su funcionamiento. El
enfoque brindado se basar en el estudio de algoritmos de TE offline y online,
orientados a brindar garantas de Calidad de Servicio (QoS), las cuales permitan
asegurarle al cliente que obtendr el grado de servicio esperado en trminos del ancho de
banda solicitado. Asimismo se estudiaron tambin mtodos de optimizacin asociados al
reparto justo de carga de las demandas de los clientes, lo que constituye las llamadas
fair networks. Y por ltimo, y tambin a destacar, se estudiaron los principales
conceptos que abarcan las MIBs (Management Information Bases), con el objetivo en
particular de determinar cmo descubrir los routers presentes en cierta red, que estn
intercambiando informacin 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 topologa de la red en estudio, devolvindole el
programa por medio de una interfaz grfica, el estado actual de la red. Se busc tambin
implementar un algoritmo para la computacin de caminos (LSPs en nuestro caso),
comnmente usado en algoritmos de ruteo estilo Constraint Base Routing (CBR), el cual
le ofrecer tambin al usuario diferentes criterios de priorizacin al momento de elegir un
camino. El algoritmo elegido fue el Constraint Shortest Path First (CSPF).
Posteriormente, se puede sealar como tercer objetivo el agregar una
funcionalidad al software que le permitiera al usuario el cargar la topologa de la red en
estudio en forma automtica.
Finalmente, como cuarto objetivo, se busco el darle la posibilidad al usuario de
poder determinar, teniendo como dato de entrada la matriz de trfico conteniendo todos
los pares origen-destino con sus respectivos anchos de banda, cul es la mejor manera de
distribuir la carga de forma tal que la mayora de las demandas se vean cubiertas de
manera satisfactoria siguiendo diferentes pautas de justicia en el reparto de la carga.
9
La realizacin de este proyecto esta contenida en un marco ms amplio de trabajo,
que cuenta con el financiamiento del BID y del PDT, y que tiene por objeto la
implementacin 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 garantas de
calidad de servicio.


1.2 Motivacin

El crecimiento actual de la Internet le da una oportunidad a los Internet Service
Providers (ISPs) de ofrecer nuevos servicios como VoIP, Videoconferencia, etc., adems
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 prdida,
delay y jitter se refiere.
La Internet no fue diseada 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
garanta alguna.
A pesar que protocolos como TCP han agregado mecanismos de reenvo que
tratan de solucionar el problema de la prdida de paquetes generado por el
congestionamiento en la red, estos no solucionan las prdidas 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 aos para poder ofrecer garantas 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
garantas de QoS en el segundo (el actual paradigma de ruteo IP de la Internet provoca la
hiper-agregacin de flujos en ciertas partes de la red y sub-utilizacin de recursos en
otras), es que se necesita de la Ingeniera de Trfico en las redes IP para asegurar QoS.
Los ISPs necesitan as de sofisticadas herramientas de gestin 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 tecnologa de Multi Protocol Label
Switching (MPLS) es un buen ejemplo que ayuda a realizar TE en sistemas autnomos
(AS) (ver Apndice A por ms informacin). Se basa en la idea de enviar paquetes a
travs 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 interconexin 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) (representacin de un conjunto de paquetes que
comparten los mismos requerimientos para su transporte) que son entonces mandados a
travs de uno de los LSPs asociado con esa FEC en particular.
La prctica de TE hoy en da abarca el establecimiento y uso de esos LSPs como
tuberas de determinado ancho de banda entre dos puntos. Dichos LSPs pueden ser
seteados a travs de varios routers, ya sea de forma manual por parte del usuario
10
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 travs
del uso de algn algoritmo de computacin online basado en restricciones (CSPF).
Como podemos ir viendo, la Ingeniera de Trfico (TE) intenta optimizar la
performance de las redes, a travs de tres actividades integradas: medicin del trfico,
modelado de la red, y seleccin de mecanismos para el control del trfico.
Desafortunadamente, grandes Proveedores de Servicios de Internet (ISPs) tienen pocos
sistemas de software y herramientas que soporten la medicin del trfico y el modelado
de la red, pilares bsicos de una ingeniera de trfico efectiva. De manera similar,
preguntas sencillas sobre la topologa, trfico y ruteo son sorprendentemente difciles de
contestar en las redes IP de hoy en da. Una gran cantidad de trabajo ha sido dedicado al
desarrollo de mecanismos y protocolos para el control del trfico. Como ejemplo de ello,
la mayor parte del trabajo de la Internet Engineering Task Force (IETF) est relacionado
al control del trfico en lo que a la ingeniera de trfico concierne.
Existen determinados factores que indican la necesidad de ms y mejores
herramientas de ingeniera de trfico para las redes. Entre ellos se destacan la calidad del
servicio, los parmetros ajustables interdependientes, el crecimiento de las redes y la
variabilidad del trfico (Referirse a [1] por ms informacin).
En cuanto a la Calidad del Servicio, los clientes son cada vez ms exigentes en el
cumplimiento de la performance, confiabilidad y seguridad, que se manifiestan en forma
de Service Level Agreements (SLAs). Los clientes desarrollan ms procedimientos de
certificacin 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 prdida de paquetes y jitter, estn
emergiendo hoy en da. Por eso es muy importante para los operadores de redes el
coordinar cuidadosamente por dnde fluye el trfico 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 Parmetros ajustables Interdependientes se refiere, hoy en da,
los proveedores de equipos de red, proveen a los ISPs con poco o ningn control sobre
los mecanismos bsicos responsables de la coordinacin de paquetes, gestin de buffers y
seleccin de caminos. En su lugar, los proveedores de backbones son forzados a entender
una larga cantidad de parmetros interrelacionados que de una manera u otra afectan la
configuracin y operacin. Hasta el da 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 travs de una combinacin de intuicin, testeo y
pruebas de intento y error.
El Crecimiento de las Redes se ve reflejado en que por un lado, redes de
backbones individuales estn creciendo rpidamente en tamao, velocidad y espectro
abarcado; mientras que por otro lado, la industria intenta unir redes discordes entre s, en
redes integradas ms grandes. Como resultado, las funciones de gestin de red que una
vez pudieron ser manejadas por un grupo reducido de personas, basndose en la intuicin
y experimentacin, deben ser ahora soportadas por herramientas efectivas de ingeniera
de trfico que unen informacin de configuracin y de uso de una variedad de fuentes.
Por ltimo, la Variabilidad del Trfico. El trfico de Internet es complejo. La
carga ofrecida entre pares origen-destino es tpicamente desconocida. Asimismo, la
11
distribucin del trfico IP usualmente flucta ampliamente a travs del tiempo. Esto
introduce una gran complejidad a la ingeniera de trfico sin alivianar las demandas de
los clientes por una performance de comunicacin predecible. Herramientas efectivas de
TE deben soportar la identificacin rpida de potenciales problemas de performance y un
ambiente flexible para experimentar posibles soluciones.
Es por los motivos expuestos anteriormente que se decidi la creacin del
software NET-TE, como un aporte ms en cuanto a las herramientas que puede encontrar
un usuario para poder realizar tests de ingeniera de trfico en un ambiente simulado. La
idea clave detrs de este software es la de ofrecer al usuario de una plataforma donde
pueda visualizar la topologa de su red de estudio conjuntamente con datos sobre el uso
de los enlaces, qu enlaces se encuentran saturados, establecer afinidades que distingan el
trfico que pasa por cierto grupo de enlaces del resto. Una vez enfrente a la topologa, el
poder inferir sobre ella y visualizar las implicaciones de cambios locales en el trfico y
determinar por dnde se rutean las distintas demandas a medida que van llegando, de
acuerdo al estado actual de la red. Tambin el poder realizar una mirada general sobre
todo el grupo de demandas que se tienen hasta el momento y determinar cul 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 cmo lograr cubrirlas de la manera ms justa posible a todas ellas.
Entendiendo por justicia, la eleccin 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 configuracin de la red en un ambiente simulado, en vez en una red
operacional, basndose en una plataforma para investigaciones del tipo what-if de
ingeniera de trfico.




















12
Clculo de Caminos
Candidatos (Dijkstra)


Seleccin de
Camino
Objetivos de Performance
(restricciones)

Estado Actual de la Red
Cargar Matriz
de Trfico
Algoritmos MIRA o
FairNetworks
Descripcin de
la Red
Visualizacin
usuario de la
Red
Router ms
prximo
MIBs
LSP establecido
LSPs establecidos
1.3 Especificacin 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.























Figura 1.1: Diagrama de bloques del Proyecto

A continuacin pasamos a comentar brevemente cada uno de los bloques
funcionales.


Descripcin de la Red:

La funcin 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. Tambin se tendr la opcin de cargarla
automticamente extrayendo la informacin necesaria de las MIBs del router ms
prximo al cual esta conectada la estacin de trabajo donde se encuentra instalado el
software NET-TE.




13
Clculo de caminos candidatos (Dijkstra):

En este bloque el usuario podr establecer restricciones que los futuros LSPs
debern cumplir, como ser el ancho de banda (BW) que debern 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
optimizacin que establecer la eleccin de caminos.


Seleccin de camino:

A partir del estado actual de la red y de los candidatos, se podrn establecer
nuevos LSPs mediante la utilizacin de un algoritmo del tipo Shortest Path First (SPF)
que tome adems en consideracin 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
eleccin. El usuario tambin dispondr de ms de un criterio de TE para aplicar antes de
mostrar cul es/son las soluciones posibles encontradas, a manera de elegir la opcin que
ms ptima le resulte.


Cargar Matriz de Trfico:

Aqu se ingresara la matriz de trfico conteniendo toda la lista de las demandas
que hay sobre la red para los distintos clientes. Se especificarn todos los pares origen-
destino 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 trfico o cargada una ya creada previamente, se
podrn aplicar diversos algoritmos de ruteo offline que mostrarn la manera de alojar a
todas esas demandas en la red en forma conjunta e indicando cunto 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 estn saturados,
14
y cules tienen sus recursos sobre o sub-utilizados. Se podr apreciar el porcentaje de
utilizacin de cada enlace tambin.

Visualizacin:

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 seccin es el mostrarle al lector las reas tericas analizadas y
principales tareas que se realizaron durante todo el transcurso de este proyecto as como
la manera en que est distribuida la informacin 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 Ingeniera de Trfico en Internet
(TE). Para ello nos informamos sobre lo que motivo la aparicin de MPLS, sus ventajas,
cmo es el mecanismo de intercambio de etiquetas, entre otras cosas. Asimismo se
estudi TE, su relacin con MPLS, los objetivos que busca la ingeniera de trfico as
como tambin 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 ingeniera de trfico tanto offline como online.
Tambin se vieron algoritmos de bsqueda 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 terica deseada, se empez a desarrollar la
herramienta de software. En una primera instancia, se busc ofrecerle al usuario la
posibilidad de que creara la topologa 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 grfica. Tambin 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
ocupacin 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 Explcito, 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
computacin de caminos (usado en protocolos tipo CBR en su primera etapa de bsqueda
de caminos). El elegido fue el Constaint Shortest Path First (CSPF). Si bien en un
principio se implement para que slo desplegara la primera ruta que encontraba de
origen a destino y que cumpliera adems 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 ms corta del origen a fin, refirindonos 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 bsqueda de las rutas posibles.
15
Posteriormente se agregaron ms funciones, siempre con el objetivo de darle al
usuario una mayor participacin en la eleccin de los caminos y dndole al programa una
mayor o menor participacin en esa bsqueda. De sta manera, cuantas ms 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, dndole prioridad a la
distancia o al ancho de banda disponible en los enlaces o a cierto peso administrativo que
es fijado por el usuario. Tambin se ofrecen distintos criterios de TE, que hacen una
especie de filtrado sobre los resultados brindados por el algoritmo CSPF, ayudando
tambin 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 topologa de la red a la que est conectada la PC va
Simple Network Management (SNMP) de manera automtica. Vale destacar que con
cargar la topologa de red se entiende como descubrir todos los routers presentes en cierta
red que estn intercambiando informacin de ruteo mediante el protocolo OSPF. En
nuestro caso la componente de gestin SNMP fue implementada en el software usando el
API de Adventnet. Se tuvo que hacer nuevamente una fuerte investigacin terica,
enfocndose esta vez en la estructura en forma de rbol usada por SNMP para organizar
la gestin de datos; con esto nos estamos refiriendo a las llamadas Bases de gestin de
Informacin (MIBs) (ver Apndice B por ms informacin).
En la prxima etapa surgi la idea de agregar un nuevo algoritmo para el ruteo
dinmico 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 rpidamente servicios
de ancho de banda garantidos y la consecuente necesidad en los backbones de redes de un
aprovisionamiento rpido de caminos con ancho de banda garantido. El algoritmo elegido
fue una pequea variante del conocido algoritmo Minimun Interference Routing
Algorithm (MIRA), el cual se basa en el principio de que cada nuevo tnel ruteado (LSP)
debe seguir una ruta que no interfiera demasiado con una ruta que pueda ser
posiblemente crtica para satisfacer una futura demanda. Previo a su eleccin 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 elstica.
As nos planteamos la siguiente pregunta: cul debera ser el principio que gobierne la
distribucin 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 ms 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, cul es la manera
ms justa de distribuirlas entre los recursos de la misma.
Demos paso entonces, en los prximos captulos, a introducir los conceptos
principales que deber poseer el lector sobre MPLS y TE.



16
Captulo 2

Casos de Uso

Veamos ahora cules 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:
construccin de la topologa de la red de trabajo, establecimiento de los LSPs por los
cules pasar el trfico de cada demanda y visualizacin 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 explcito, CSPF, MIRA y FairNetworks.
Explicaremos ms adelante qu ventaja ofrece cada uno de ellos y los
compararemos.


C
C
C
aso de Uso# 1
1
1
: Construccin de la topologa

Para empezar a trabajar, lo primero que necesita hacer el usuario es construirse la
topologa de la red sobre la cual va a trabajar. NET-TE ofrece dos maneras de realizar
esto: una manual y otra automtica.
La interfaz grfica 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 topologa de
la red.
Empecemos por el mtodo manual de construccin. En este caso, el usuario
dispone de dos posibles objetos para crear su topologa: 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,
pudindolos colocar y desplazndolos de un lugar a otro a gusto del usuario, de manera
que ste pueda disear la red con la forma que desee y pudindola guardar luego en un
archivo en su computadora, en caso de querer reutilizarla luego, si as lo desease.
Esto resulta muy cmodo ya que el usuario puede cargar una vieja topologa que
tenia guardada, y cambiarla a su gusto, para reflejar el estado ms 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 caractersticas de los elementos de la
red. La opcin del uso de pesos administrativos es especialmente til en los casos en los
que el usuario desea darle ms 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 poltica interna por parte del cliente
que regulen el uso de los recursos sobre cierto enlace o grupo de enlaces. Tambin
pueden existir trficos que satisfacen demandas que son crticas o de mayor importancia,
17
con lo cual resultara particularmente til el evitar que futuros LSPs a ser establecidos
pasen por los enlaces que las conforman, a menos que sea necesario. Otra
caracterstica de suma utilidad es poder





















Figura 2.1: Pantalla principal de NET-TE y ventana de configuracin 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 trfico que pasa a travs de ellos. Es muy comn en una red el tener
distintos tipos de trfico circulando por la misma (P2P, TCP, UDP, Low Delay, etc.) y es
deseable quizs para un usuario el establecer LSPs slo sobre los enlaces que dejan pasar
determinado trfico 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 cules LSPs pasan
por ellos. De la misma manera y con la misma facilidad, el usuario ser capaz de
modificar los parmetros de los enlaces nombrados anteriormente, para poder reflejar as
cualquier cambio que haya ocurrido en la topologa.
En todo momento, si el usuario realiz algn 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 atrs en cambios ocurridos en la topologa. Ver Figura 2.2.



Figura 2.2: Botones para deshacer o rehacer cambios.

18
Pero supongamos que el usuario no tiene conocimiento sobre cmo es la
topologa 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 solucin manual no es
la adecuada. Es por ello que NET-TE ofrece tambin un mecanismo automtico,
mediante el cual, tras ingresar determinados parmetros 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 topologa se entiende como descubrir todos los routers
presentes en la red, que estn intercambiando informacin de ruteo mediante el protocolo
OSPF.

Dentro de los parmetros obligatorios se
encuentra la direccin IP de algn router de la red (en
general es la del router a la que la computadora est
directamente conectada), la versin SNMP que se desea
ejecutar (NET-TE ofrece las versiones 1 y 2) y el
community o password usado por SNMP para permitir
slo el acceso al router a personas con permiso. Tambin
se ofrecen parmetros opcionales, que el usuario es libre
de modificar, como el puerto (NET-TE usa el 161 por
defecto), nmero de reintentos y timeout. Adems se
tiene la posibilidad de seleccionar la opcin 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
contine su descubrimiento de la red.

Figura 2.3: Ventana Cargar Red.

Obviamente, esto es sumamente til si la red es una red de gran tamao, ya que
consumira mucho tiempo el crearla manualmente. De esta manera se obtiene el mismo
resultado, pero de una manera mucho ms rpida.
Una vez cargada la topologa en forma automtica, el usuario vuelve a ser libre de
poder modificarla a su gusto, tal como lo hace si la cargara manualmente.


C
C
C
aso de Uso# 2
2
2
: Establecimiento de los LSPs

En MPLS, como todos ya sabemos, el trfico 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 segn la QoS que desee cada usuario. Por eso, es tan
importante el establecimiento de los LSPs, cmo elegirlos y dnde 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 cmo y por dnde
ubicar a los LSPs.


19
R Ru ut te eo o E Ex xp pl l c ci it to o: :

El primer mecanismo es el ms sencillo de los propuestos (en lo que a clculos
se refiere): el ruteo explcito. Se le ofrece al usuario una ventana (ver Figura 2.4) en la
cual, a partir de la eleccin del nodo de origen, se le van desplegando los posibles enlaces
para que pueda ir creando salto a salto, el LSP de manera explcita de origen a fin. En
NET-TE, la demanda se expresa en trminos 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 tambin 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 slo aquellos que cumplan con la condicin 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 slo se
basa en la decisin que
tome el usuario y
depende exclusivamente
del camino que ste
desee. Un ejemplo de
una situacin de este tipo
es cuando el usuario, ya
sea o porque la red tiene
suficiente ancho de
banda como para no
restringir ningn posible
LSP o porque posee
un conocimiento muy
Figura 2.4: Ventana para el Ruteo Explcito.

grande de la red, cree saber ya de entrada por que camino es mejor que vaya el LSP.
Quizs haya un acuerdo con el cliente, el cual obligue al LSP a seguir cierto camino
explcito de manera obligatoria, con lo cual sta sera la manera ms sencilla de
establecerlo.

C CS SP PF F: :

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 tambin que hay ms de un tipo de trfico 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 trfico y
20
requiere que le aseguren determinado BW. Entonces, salvo que sea una red de tamao
pequeo y sea muy evidente el camino a usar, el usuario necesitar de algn 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 trfico, asegurndose que cumplan con el BW solicitado por el
cliente, adems de un conjunto pre-definido de restricciones que puede l mismo ingresar
y comentaremos ms adelante. Finalmente, ser decisin del usuario el elegir el camino
que ms le convenga, dentro de toda la gama de soluciones.
Dentro de los parmetros 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 slo por aquellos
enlaces que soportan cierto tipo de trfico se incorpor al NET-TE la posibilidad de
elegir la Afinidad, como parmetro opcional.
Puede suceder que por razones poltico-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 tambin otros dos parmetros
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)
cumplirn con estas restricciones.
Ahora bien, ya que el CSPF se basa en el algoritmo Dijkstra, se debe determinar
cul es la mtrica a usar para elegir el camino ms corto (con ms 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 Mnimo por
Pesos Administrativos, Ruteo por Mnima Cantidad de Saltos, 1/(BWreservado) y
1/(BWlibre).
El primero de todos es bsicamente 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 decisin de cul es el mejor camino por donde
establecer el LSP.
El segundo, es simplemente establecer la cantidad de saltos, como la mtrica
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 ms ocupados y otros ms 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 ms ocupados en la red, de manera tal de dejar a los que estn ms libres,
disponibles para futuras demandas. Es una manera de procurar seguir usando los enlaces
que ya estn siendo ms utilizados por otros LSPs, y no tocar los que estn ms libres.
NET-TE brinda esta posibilidad, con tan slo 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 estn ms 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
21
aquellas zonas de la red que no han sido usadas an, de manera de no sobrecargar
aquellas que s lo estn siendo. Esto es lo que NET-TE permite si el usuario elige la
cuarta opcin de peso.
Se puede ver que NET-TE ofrece una amplia gama de criterios de pesos, de
manera que el usuario pueda elegir cul desea sea usado por el algoritmo para el clculo
de la nueva ruta, pudiendo jugar as con las distintas combinaciones y viendo cmo afecta
una u otra eleccin. Vale decir que estos son parmetros obligatorios que debe ingresar el
usuario.
Por ltimo, NET-TE le ofrece al usuario, como ltima opcin, la posibilidad de
usar o no determinado criterio de TE, sobre los caminos encontrados: Elegir
manualmente, No saturacin enlaces crticos y Minhop.
Supongamos que luego de que el usuario haya ingresado todos los parmetros
anteriores, NET-TE encuentra ms de un camino que satisfaga los requerimientos de BW,
Afinidad y dems. 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 slo se desplieguen aquellas soluciones que no contienen a los
enlaces ms crticos, 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 cul quedarse.






















Figura 2.5: Ventanas de CSPF y de informacin sobre resultados hallados.
22
Con el segundo criterio, NET-TE lo que hace es comparar las soluciones
encontradas y se queda slo con aquella cuyos enlaces que la componen, tiene el mayor
ancho de banda disponible. De esta manera, no slo se muestra el camino que cumple con
las restricciones y que segn la mtrica elegida es el ms corto, sino que se muestra
aquel que molesta menos a los enlaces ms 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 slo 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 slo las posibles
soluciones que van por la parte ms o menos ocupada de la red, sino tambin, por la ms
corta.
Vale destacar que otra prctica funcionalidad que el NET-TE ofrece al elegir el
segundo o tercer criterio de TE, es una ventana que despliega, en caso de existir mltiples
soluciones, valores como la Capacidad, BW usado y Porcentaje de Utilizacin de los
enlaces que las conforman. Se distinguen las soluciones ofrecidas de aquellas que fueron
descartadas. Esto es muy til para poder visualizar numricamente la razn de la decisin
tomada por NET-TE.


M MI IR RA A: :

Ya habiendo visto los criterios de Ruteo Explcito 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 situacin de querer establecer
varios caminos de acceso a Internet para clientes a los que no se les garantiza ningn tipo
de calidad de servicio (trfico 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 clsicos como el SPF, los caminos se mapearn
indistintamente por el camino ms corto degradando el servicio de los clientes
corporativos ya establecidos e interfiriendo con futuras demandas (nuevos clientes).
La solucin ideal en este caso sera correr un algoritmo que tenga como entrada
los puntos (localidades, nodos, etc.) que el usuario considera crticos y mapear los
caminos de Internet por enlaces que no sean crticos 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
23

mapearn todos
los caminos de
acceso a Internet
por los caminos
ms largos, o
hasta que no
exista otra
posibilidad (sature
por ejemplo algn
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 bsica 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 ms
importantes. Se puede apreciar la ventana de dicho algoritmo en la Figura 2.6.


F Fa ai ir rn ne es ss s: :

As llegamos al ltimo mecanismo ofrecido por NET-TE, Fairness.
Supongamos ahora que el usuario ya no tiene que preocuparse por ver cmo
colocar determinado LSP para cada demanda nueva entrante. Ahora, lo que desea es,
teniendo una matriz de trfico que contiene a todas las demandas que desean establecerse
sobre la red (la cual ya puede contener viejos LSPs establecidos), ver cmo satisfacerlas a
todas ellas de una manera lo ms 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 mnimo requerido por cada
una de ellas. La pregunta que le podra resultar interesante de hacerse sera: Cuntos
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 solucin son los hayados por el
algoritmo CSPF. El usuario dispone de dos tipos de pesos a eleccin: minhop o pesos
administrativos. Una vez hayados todos los caminos posibles que cumplen con la
restriccin del ancho de banda para todas las demandas, el objetivo es ver cmo se
asignan los recursos de la red, a cada una de ellas, de manera que se obtenga el mximo
aprovechamiento posible de la red.
Una aplicacin puede ser cuando se tiene determinada red utilizada para brindar
servicios exclusivamente a un determinado nmero de clientes. Se quiere entonces
24
arrojar sobre ella los LSPs que van a cubrir cada una de esas demandas y darles a ellos
la mxima 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 informacin anterior al usuario, y le da a elegir cuatro
algoritmos a usar distintos: fairness bsico, acotado, con mltiples caminos y con
mltiples caminos acotado. Observar la Figura 2.7.
El primero y el tercero brindan
informacin sobre cul es la cantidad
mxima de BW que puedo tomar de la red
para cada una de las demandas. La nica
diferencia es que el primer algoritmo slo
me considera un camino solucin fijo para
cada demanda, mientras que el tercero toma
todos los caminos solucin posibles. Para el
caso en que hayan mltiples 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 tambin slo
un camino solucin 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 ms de una
opcin disponible), pero le brinda al usuario la opcin 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 econmico, priorizando a aquellos que
por ejemplo pagan ms de los que pagan menos. Tambin es til cuando el usuario debe
asegurarse que las demandas lleguen a obtener al menos un BW mnimo obligatorio en el
reparto.
Como ejemplo, supongamos que tiene una demanda que requiere 10MB. Como
sabe que quizs 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 mnimo de 5MB por ejemplo y de esa manera se asegura que de
haber solucin, 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 clculo cuando ya no quedan ms 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, tambin se detendr el clculo.
25
ste es particularmente til para un usuario cuando no desea ver cul es la
cantidad mxima de recursos que le puede ofrecer la red para satisfacer sus demandas,
sino saber si puede llegar a cumplirlas, detenindose una vez que fueron satisfechas.
Para la mejor visualizacin del usuario, aquellas demandas que no lograron
satisfacer el BW
requerido
, se pintarn 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 cunto ancho de banda rutean
cada una de ellas, as como apreciarlas en forma grfica.
Asimismo, se dispondr tambin de una ventana que despliega los resultados
obtenidos en forma numrica para todas las demandas, teniendo el usuario de sta
manera, otra forma sencilla de visualizar cuntas demandas satisfacen y cuntas no, el
ancho de banda requerido.



C
C
C
aso de Uso# 3: Visualizacin del estado actual de la red


El ltimo caso de uso consiste en los mtodos que tiene el usuario con el software
NET-TE de poder ver el estado de la red.
Bsicamente lo puede hacer de dos formas posibles: por medio del uso del botn
Estadsticas o bien del botn Utilizacin.
Con tan slo apretar el botn Estadsticas (ver Figura 2.8), en cualquier momento,
al usuario se le desplegar una pantalla donde figurarn todos los nodos que conforman la
red, los enlaces, as como los LSPs establecidos hasta ahora. Podr ver las caractersticas
de cada uno de ellos, as como tambin por cul 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 utilizacin de cada uno de ellos. Debido
a la manera en que esta desplegada la informacin, resulta muy prctico a la vista el
comparar unos con otros.



Al usuario tambin le podra
interesar el poder clasificar a los enlaces
de la red, de acuerdo al porcentaje de
utilizacin que tienen y visualizar esa
clasificacin de una manera rpida y
sencilla en pantalla. NET-TE permite
realizar eso por medio de la herramienta
Utilizacin (ver Figura 2.9).



Figura 2.8: Ventana Estadsticas.
26
Basta tan slo 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 utilizacin
para cada enlace.
Esta es una manera sencilla de visualizar en pantalla qu zonas de la red estn
ms saturadas que otras. Es en especial prctico para redes de gran tamao, donde ver
valores numricos no sea tan intuitivo como esto.
















Figura 2.9: Ventana Utilizacin.

En caso de no ingresarse ningn nmero, se asignan dos valores por defecto.





















27
Captulo 3

Ingeniera de Trfico (TE)


3.1 Introduccin

La Ingeniera de Trfico (TE) es una disciplina que procura la optimizacin de
la performance de las redes operativas. La Ingeniera de Trfico abarca la aplicacin de la
tecnologa y los principios cientficos a la medicin, caracterizacin, modelado, y control
del trfico que circula por la red. Las mejoras del rendimiento de una red operacional, en
cuanto a trfico y modo de utilizacin de recursos, son los principales objetivos de la
Ingeniera de Trfico. Esto se consigue enfocndose a los requerimientos del rendimiento
orientado al trfico, mientras se utilizan los recursos de la red de una manera fiable y
econmica.
Una ventaja prctica de la aplicacin sistemtica de los conceptos de Ingeniera de
Trfico a las redes operacionales es que ayuda a identificar y estructurar las metas y
prioridades en trminos de mejora de la calidad de servicio dado a los usuarios finales de
los servicios de la red. Tambin la aplicacin de los conceptos de Ingeniera de Trfico
ayuda en la medicin y anlisis del cumplimiento de stas metas.
La ingeniera de trfico se subdivide en dos ramas principalmente diferenciadas
por sus objetivos:

Orientada a trfico: sta rama tiene como prioridad la mejora de los indicadores
relativos al transporte de datos, como por ejemplo: minimizar la prdida 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 optimizacin de la
utilizacin 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 congestin.
Un reto fundamental en la operacin de una red, especialmente en redes IP pblicas a
gran escala, es incrementar la eficiencia de la utilizacin del recurso mientras se
minimiza la posibilidad de congestin.
Los paquetes luchan por el uso de los recursos de la red cuando se transportan a
travs 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 congestin puede hacer que algunos de los paquetes de entrada sean retardados
e incluso descartados. La congestin aumenta los retardos de trnsito, las variaciones del
retardo, la prdida de paquetes, y reduce la previsin de los servicios de red. Claramente,
la congestin es un fenmeno nada deseable y es causada por ejemplo por la insuficiencia
28
de recursos en la red. En casos de congestin de algunos enlaces, el problema se resolva
a base de aadir ms capacidad a los enlaces.
La otra causa de congestin es la utilizacin ineficiente de los recursos debido al
mapeado del trfico. El objetivo bsico de la Ingeniera de Trfico es adaptar los flujos
de trfico a los recursos fsicos de la red. La idea es equilibrar de forma ptima la
utilizacin de esos recursos, de manera que no haya algunos que estn sobre-utilizados,
creando cuellos de botella, mientras otros puedan estar subutilizados. En general, los
flujos de trfico siguen el camino ms corto calculado por el algoritmo IGP
correspondiente. La Ingeniera de Trfico consiste en trasladar determinados flujos
seleccionados por el algoritmo IGP sobre enlaces ms congestionados, a otros enlaces
ms descargados, aunque estn fuera de la ruta ms corta (con menos saltos).
En resmen la Ingeniera de Trfico 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 ms 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 caractersticas de la performance del trfico orientado de la red,
minimizando la prdida de paquetes, minimizando perodos prolongados de
congestin y maximizando el throughput.

Mejorar las caractersticas estadsticas de los lmites de la performance de la red
(como ser tasa de prdidas, variacin del delay y delay de transferencia).

Proveer de un control preciso sobre cmo el trfico es re-enrutado cuando el
camino primario se enfrenta con una sola o mltiples fallas.
3.2 Componentes de la Ingeniera de Trfico

Hay cuatro componentes que se pueden destacar dentro de la Ingeniera de
Trfico: la componente del packet fowarding, la componente de distribucin de
informacin, la componente de seleccin de camino y la componente de sealizacin
(Por ms informacin 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 travs 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 descripcin sobre MPLS.
29
La clave detrs de MPLS es el mecanismo de asignacin 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 ms saltos (hops) en los
que se produce el intercambio de etiquetas, de modo que cada paquete se enva de un
conmutador de etiquetas (Label-Switching Router, LSR) a otro, a travs 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 conmutacin 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 informacin 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 travs de
los routers de conmutacin de etiquetas (LSRs). Estos se encargan bsicamente de dirigir
el trfico en el interior de la red, segn sea la etiqueta que contenga el paquete. Al llegar
un paquete a un LSR, ste examina su etiqueta y usndola como ndice en una tabla,
determina el siguiente salto y una nueva etiqueta para el paquete. Cambia una por otra
y lo enva 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 trfico de otro. Todos los paquetes que pertenezcan a
la misma FEC seguirn el mismo LSP para llegar a destino. A diferencia del
enrutamiento IP convencional, la asignacin de un paquete a determinado FEC se hace
slo una vez. Otra diferencia con IP, es que las etiquetas en MPLS no contienen una
direccin IP, sino un valor numrico acordado entre dos nodos consecutivos para brindar
una conexin a travs 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 travs de los LSPs preestablecidos por un determinado
FEC.
Habiendo sealado las principales caractersticas de MPLS, proseguimos con la
segunda componente de TE. sta consiste en requerir de un conocimiento detallado de
la topologa de la red as como tambin informacin dinmica de la carga en la red. La
componente de distribucin de informacin es implementada definiendo extensiones
relativamente simples a los IGPs, tal que los atributos de los enlaces son includos como
parte de cada aviso del estado de enlace en cada router.
Cada router mantiene atributos de los enlaces de la red e informacin de la
topologa de la red en una base de datos de TE especializada (TED). La TED es usada
exclusivamente para el clculo de rutas explcitas, para la ubicacin de LSPs a lo largo de
la topologa fsica. En forma aparte, una base de datos es mantenida, de manera que el
clculo subsiguiente de la ingeniera de trfico sea independiente del IGP y de la base de
datos del estado de enlace del IGP. Mientras tanto, el IGP contina su operacin sin
ninguna modificacin, realizando el clculo tradicional del camino ms corto, basado en
informacin contenida en la base de datos del estado de enlace en el router.

30
En cuanto a la componente de seleccin de caminos, luego que los atributos de
los enlaces y la informacin de la topologa 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 explcita estricta o sin trabas(strict
or loose explicit route). El router de ingreso determina el camino fsico para cada LSP
aplicando por ejemplo, un algoritmo de restricciones de camino ms corto (CSPF,
Constrained Shortest Path First) a la informacin en la TED.
A pesar de que se reduce el esfuerzo de administracin (resultado del clculo
online del camino) una herramienta de planeamiento y anlisis offline es necesaria si se
quiere optimizar la TE globalmente. En el clculo online se toma en consideracin 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 dnde 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 tambin. De esta manera, los LSPs que se
calculan primero tienen ms recursos disponibles para utilizar que los que llegan ms
tarde, ya que todo LSP calculado previamente consume recursos.
Por otro lado, una herramienta de planeamiento y anlisis offline, examina en
forma simultnea 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 clculos globales comparando los resultados de cada clculo y selecciona
entonces la mejor solucin de la red tomada como un conjunto. La salida del clculo es
un conjunto de LSPs que optimizan la utilizacin de los recursos de la red. Una vez
finalizado el clculo offline, el LSP puede ser establecido en cualquier orden ya que cada
uno ha sido instalado siguiendo las reglas para una solucin ptima global.
Por ltimo, la componente de sealizacin 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 distribucin de
etiquetas; de hecho se estn estandarizando algunos existentes con las correspondientes
extensiones como son RSPV y LDP.















31












Parte II


Principios y Bases Tericas















32
Captulo 4

Constraint Shortest Path First (CSPF)

4.1 Principios bsicos 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 coleccin de Sistemas Autnomos (AS), donde las rutas
dentro de un AS son determinadas por ruteo intradominio y las rutas que atraviesan
mltiples ASs son determinadas por ruteo interdominio. Ejemplos de protocolos
intradominio son RIP, OSPF y IS-IS. El protocolo de ruteo interdominio usado hoy en da
en redes IP es BGP. Nos enfocaremos de ahora en ms al ruteo intradominio ya que
utiliza para el clculo de los caminos algoritmos que buscan minimizar cierta mtrica en
particular, como es el caso de CSPF usado en NET-TE.
La computacin 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 mtrica escalar en particular. En el caso de RIP,
dicha mtrica es el nmero de saltos. En el caso de OSPF o IS-IS la mtrica es la mtrica
administrativa de un camino. Esto es, con OSPF (o IS-IS), un administrador de red asigna
a cada enlace en la red una mtrica administrativa. Dada la opcin de mltiples caminos a
un destino dado, OSPF (o IS-IS) usa el algoritmo de Dijkstra del camino ms corto (SPF)
para computar el camino que minimiza la mtrica administrativa del camino, donde la
mtrica administrativa del camino se define como la suma de las mtricas 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 mtrica escalar, mientras que los algoritmos
basados en CBR intentar encontrar un camino que optimice cierta mtrica 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 continuacin.
El primer mecanismo que necesitamos es la habilidad de computar un camino,
y de hacerlo de manera tal que no tome slo en cuenta determinada mtrica escalar usada
como criterio de optimizacin, sino tambin un conjunto de restricciones que no deben
ser violadas. Esto requiere que la fuente tenga toda la informacin necesaria para
computar dicho camino.
El segundo mecanismo es la habilidad de distribuir la informacin sobre la
topologa de la red y atributos asociados a los enlaces a travs de la red. Esto porque ya
que cualquier nodo en la red es potencialmente capaz de generar trfico que tenga que ser
ruteado va ruteo basado en restricciones, la informacin que usa la fuente para computar
el camino debe estar disponible a cualquier nodo de la red.
33
Una vez computado el camino, tambin necesitaremos el soportar el envo a
travs de dicho camino. Por lo que el tercer mecanismo es aquel que sea capaz de
soportar el ruteo explcito.
Por ltimo, el establecer una ruta para un conjunto particular de trfico, puede
requerir la reserva de recursos a lo largo de esa ruta, alterando quizs el valor de los
atributos asociados a enlaces individuales de la red. Por lo que el ltimo mecanismo es
uno a travs del cual se puedan reservar recursos de la red y sean modificados los
atributos de los enlaces como resultado de cierto trfico tomando ciertas rutas.
De ahora en ms 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 mtrica escalar (por ejemplo el minimizar la
cantidad de saltos o un mtrica 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
mtrica 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
34
esas restricciones. Nos referiremos a tal algoritmo como constraint shortest path first
(CSPF) (Ver [3] por ms informacin).
Para entender como SPF debe ser modificado para tomar restricciones en cuenta,
miremos primero como es la operacin del SPF plano. El algoritmo SPF plano trabaja
empezando de un nodo llamado raz, y creando luego a partir del mismo, una estructura
en forma de rbol que contiene el camino ms corto. En cada iteracin del algoritmo, hay
una lista de posibles nodos candidatos (inicialmente esta lista contiene slo a la raz).
En general, los caminos de la raz a los nodos candidatos no son los ms cortos. Sin
embargo, para el nodo candidato que esta ms cerca de la raz (con respecto a la distancia
usada por SPF), el camino a ese nodo es el ms corto garantizadamente. Entonces, en
cada iteracin, el algoritmo toma de la lista de candidatos, al nodo con la distancia ms
corta a la raz. Este nodo es entonces agregado al rbol del camino ms corto y removido
de la lista de nodos candidatos. Una vez que el nodo ha sido agregado al rbol del camino
ms corto, los nodos que no estn en el rbol, pero son adyacentes a ese nodo, son
examinados para una posible adicin o modificacin de la lista de candidatos. El
algoritmo entonces itera nuevamente. Para el caso en donde se desee encontrar el camino
ms corto de la raz a todo el resto de los nodos, el algoritmo termina cuando la lista de
candidatos esta vaca. Para el caso en que se desee simplemente encontrar el camino ms
corto de la raz a algn otro nodo especifico, el algoritmo termina cuando este otro nodo
es agregado al rbol del camino ms corto.
















Figura 4.2: Proceso de computacin del CSPF

En la Figura 4.2 se puede apreciar el proceso total de computacin del algoritmo
CSPF. Vale destacar que la TED es la Base de Datos de Ingeniera de Trfico, la cual
provee a CSPF con informacin actual sobre la topologa de la red.
Dadas las operaciones del SPF plano, es bastante sencillo el observar la
modificacin que debemos hacerle al mismo de manera de convertirlo a CSPF. Todo lo
que tenemos que hacer es modificar el paso que maneja la adicin o modificacin de la
lista de candidatos. Especficamente, cuando agregamos un nodo al rbol del camino ms
corto y nos fijamos en los enlaces adyacentes a ese nodo, nos fijamos primeramente si
35
esos enlaces satisfacen todas las restricciones planteadas. Slo si el enlace satisface todas
las restricciones, recin 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
restriccin en particular, es especfico de la naturaleza de la restriccin. Por ejemplo,
cuando la restriccin 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 restriccin; slo si lo es, es que examinamos el nodo ubicado
en el otro extremo del enlace.
Tambin observar que el chequear si un enlace satisface una restriccin en
particular, asume que hay una informacin de restriccin relacionada, asociada con el
enlace. La naturaleza de esta informacin relacionada a la restriccin. Por ejemplo,
cuando la restriccin que queremos satisfacer es el ancho de banda disponible, la
informacin que necesitamos es tener al ancho de banda disponible en un enlace.
Notar que el algoritmo CSPF requiere que el router que realiza la computacin del
camino, tenga informacin sobre todos los enlaces en la red. Esto impone una restriccin
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 explcito 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. Adems 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 razn
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. Adems
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 mtrica en la que l este interesado de usar (por ejemplo la
cantidad mnima de saltos, minimizar los pesos administrativos asignados por el mismo a
los enlaces o hacer la mtrica en funcin 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 investigacin muy activa por muchos
aos. Selecciona rutas en la red que satisfagan la QoS requerida para una conexin o
grupo de conexiones. Adems, el ruteo basado en QoS logra una eficiencia global en la
utilizacin eficiente de los recursos. Un ejemplo de esto es al algoritmo Shortest-
Widest-Path (WSP), el cual usa al ancho de banda como una mtrica y selecciona los
caminos que tienen un cuello de botella de ancho de banda mayor. El cuello de botella de
36
ancho de banda representa la capacidad mnima 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 mnima cantidad de saltos es seleccionado (Ver [4] por ms informacin).
Los algoritmos de ruteo usados en CBR y la complejidad de los mismos, depende
del tipo y del nmero de mtricas que son includas en el clculo 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 ms tiles en comparacin con el delay y jitter, ya que muy pocas
aplicaciones no pueden tolerar una ocasional violacin de dichas restricciones, y como el
delay y jitter se pueden determinar por medio del ancho de banda alojado y nmero de
saltos del camino donde va el flujo, stas restricciones pueden ser mapeadas en
restricciones de ancho de banda y nmero de saltos, en caso de ser necesario. Otro factor
es que muchas aplicaciones en tiempo real requieren un determinado ancho de banda. El
nmero de saltos de una ruta tambin es una mtrica importante, ya que cuantos ms
saltos atraviese un flujo, ms recursos consumir.
Con las implementaciones bsicas del esquema de CBR, hay una especie de
balance y equilibrio entre la conservacin 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 bsicamente el mismo
que el ruteo dinmico. Hace nfasis en preservar los recursos de la red por
medio de la seleccin de los caminos ms cortos.
Widest-Shortest Path (WSP): ste acercamiento hace nfasis en balancear
la carga por medio de la eleccin de caminos ms anchos en cuanto al ancho
de banda. Encuentra caminos con el mnimo nmero de saltos y, si encuentra
mltiples 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 ms cortos
cuando la carga de la red es pesada y a los caminos ms anchos cuando la
carga de la red es moderada. Encuentra un camino con el ancho de banda ms
grande y, en caso de haber mltiples caminos, se queda con el que tiene la
mnima cantidad de saltos.

En los ltimos dos casos se consumen ms recursos, lo cual no es eficiente
cuando la utilizacin de la red es alta. Se debe hacer un balance o equilibrio entre la
conservacin de recursos y el balance de carga (Ver [5] por ms informacin).
Vale hacer notar en este momento, que cualquiera de las 3 opciones superiores se
pueden implementar en el software NET-TE, combinando correctamente la eleccin del
tipo de pesos para los enlaces con la eleccin del criterio de TE.





37
Captulo 5

Minimum Interference Routing
Algorithm (MIRA)

5.1 Presentacin 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 mximo ancho de banda
disponible entre algunos pares de nodos ingreso-egreso crticos en la red, dependiendo de
por dnde se dirija el mismo. Este fenmeno 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 creacin de los cuellos de
botella puede ser evitada tambin.
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 cun crtico es el enlace para el establecimiento
de LSPs entre pares de nodos ingreso-egreso. De esta manera futuras demandas entre
estos nodos tendrn baja probabilidad de ser rechazadas.
En este tipo de algoritmos es necesario conocer la topologa actual y las
capacidades disponibles. Se asume que la topologa 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. Adems, desde cierto nodo
ingreso, pueden ser permitidos LSPs a ciertos egresos solamente Esto se debe por
ejemplo a restricciones de poltica o de servicio. Toda informacin de este tipo es
conocida, y se asume que no vara 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 ms informacin 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 clsicos como el min-hop algorithm.
38


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 situacin en que se necesiten varios LSPs entre (A,G) y se utiliza el enfoque de
min-hop los LSPs sern 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 consideracin lo crtico 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 ms largo (en lo que a nmero 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
extensin del protocolo de enlace de estado operacional).


5.3 Algoritmo propuesto

El pseudo cdigo del algoritmo para el establecimiento de un LSP entre (s, d) se
presenta a continuacin:
1- Calcular el MNF (Maximum Network Flow) entre todos los pares ingreso-egreso
( ) L d s ' , ' .
2- Calcular el peso w(l) para todos los enlaces l E .
39
3- Eliminar todos los enlaces que tienen ancho de banda disponible menor al
requerido por el LSP y formar una nueva topologa con los nodos y enlaces
restantes.
4- Correr SPF con la topologa reducida.
5- Establecer el LSP entre ( ) d s, y actualizar los anchos de banda disponible en cada
enlace.

Especficamente, dada una nueva demanda entre ( ) d s, , 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 ( ) L d s ' , ' , primero
calculamos el MNF (maximum network flow)
' 'd s
[3] entre s y d. El MNF representa
el mximo ancho de banda que puede traficar la red entre el par de nodos (s, d), ya sea
por varios caminos o por uno slo. Luego para cada enlace E l se calcula la
contribucin del enlace a este MNF entre s y d que es representado como
' '
' '
d s
d s
l
f

, donde
' 'd s
l
f es la cantidad de trfico de MNF que pasa por l. Tambin 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 contribucin normalizada de
ancho de banda del enlace l como sigue,

( ) l R
f
d s
d s
l
' '
' '

(5.1a)

sta es la diferencia principal de este algoritmo con respecto a otros, como
versiones anteriores del MIRA, en las cuales slo se considera si los enlaces son crticos
o no en futuras demandas (
' 'd s
l
f =1 0). De sta manera se considera la importancia del
enlace pero tambin el cuantificar esta importancia con la contribucin 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 ( ) L d s ' , ' que pueden originar LSPs en el futuro:


( )

=
L d s
d s
d s
l
E l
l R
f
l w
) ' , ' (
' '
' '
, ) (

(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
obtenindose una topologa 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.




40
Captulo 6

Redes Justas (Fair Networks)

6.1 Introduccin

Debido a que la distribucin del trfico en las redes de datos cambia rpidamente,
es complicado para los operadores de una red, el determinar cundo y dnde incrementar
la capacidad de la misma, lo cual puede llevar a problemas de sobrecarga.
La toma de decisin sobre cuntos usuarios pueden ser atendidos y cunto trfico
puede generar cada uno de ellos, es un tema del que se encarga el proceso de admisin de
trfico. 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 cunto trfico de cada flujo debe ser admitido por la red y por
dnde rutear al mismo una vez que ingresa, satisfaciendo los requerimientos de alta
utilizacin de la red y garantizando justicia a los usuarios, es uno de los retos ms
grandes en el diseo de las redes de telecomunicaciones de hoy en da.
As nos encontramos frente a la pregunta de cmo distribuir econmicamente
cierto volmen de demanda sobre una red, bajo cierto conjunto de restricciones de ruteo y
flujo.
La primera hiptesis es que las demandas entre pares de nodos origen-destino,
pueden utilizar cualquier ancho de banda asignado a ellas en trminos de sus flujos de
caminos, quizs bajo ciertos lmites.
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 algn criterio de
justicia?
Una primera solucin que se nos podra ocurrir es asignar la mayor cantidad de
recursos a cada demanda, al mismo tiempo que se intenta mantener los recursos
asignados lo ms similares posible. Esto nos lleva al principio de asignacin llamado
Max-Min Fairness (MMF), usado para formular el esquema de asignacin de recursos
(Ver [10] por ms informacin).
La nocin de justicia se presenta en el contexto de redes basadas en el intercambio
de paquetes, transportando demandas elsticas entre pares de nodos. Con elasticidad nos
referimos a que cada demanda puede consumir cualquier ancho de banda agregado
asignado a sus caminos individuales, quizs dentro de determinados lmites predefinidos.
En las prximas secciones de ste captulo mostraremos los enunciados
principales de los problemas MMF, analizando cmo usar sus nociones para expresar la
justicia en el proceso de admisin de trfico. Se presentarn los cuatro diferentes mtodos
que fueron implementados en el software NET-TE.

41
*La informacin, as como los enunciados y mtodos presentados en ste
captulo, fueron extrados 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 elsticas. Un problema general con este tipo
de redes es cmo 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 distribudos de una manera justa.


6.2 Algoritmo 1: Max-Min Fairness bsico 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 slo de ellos, pudiendo ste ser elegido por el usuario a su gusto).
Antes de seguir con el planteo del primer mtodo utilizado de asignacin justa de
recursos, debemos introducir una definicin:

Definicin 6.1:
Un vector de n componentes x = (x
1
, x
2
,, x
n
) ordenado en orden ascendente (x
1
x
2

x
n
) es lexicogrficamente mayor que otro vector de n componentes y = (y
1
, y
2
,, y
n
)
ordenado ascendentemente (y
1
y
2
y
n
) si existe un ndice k, 0 k n, tal que x
i
= y
i

para i=1, 2,, k y x
k
> y
k
.

Ahora presentemos la formulacin 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

e
c Capacidad del enlace e
Variables

d
x Flujo asignado a la demanda d, x = (x
1
, x
2
,, x
D
)
Objetivo
Hayar el vector de asignacin x, el cual, cuando ordenado en orden ascendente, es
lexicogrficamente mximo entre todos los vectores de asignacin ordenados en orden
ascendente.


42
Restricciones

ed d e
d
x c e =1, 2, ...,

(6.2.1a)
0 x (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 Definicin 6.1, la solucin x
*
de ste problema tiene la propiedad
de que para cualquier otro posible vector x = (x
1
, x
2
,, x
D
), cuando ambos vectores estn
ordenados
* * *
(1) (2) ( ) (1) (2) ( )
( ... ... )
i i i D j j j D
x x x y x x x entonces existe un ndice
d, 0 d D, tal que
*
( ) ( ) i l j l
x x = para l = 1, 2,, d y
*
( 1) ( 1) i d j d
x x
+ +
> .
Para establecer la equivalencia de la caracterizacin lexicogrfica de la solucin
ptima al problema MMF/FIXSP (Max-Min Fairness for Fixs Paths; problema que
estamos actualmente analizando) con una caracterizacin justa max-min ms conocida,
para el caso considerado de camino fijo nico, debemos introducir a continuacin una
nueva definicin y proposicin.

Definicin 6.2
Un posible vector de asignacin 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 d e
d
x c =

) perteneciente al
camino que satisface la demanda d ( 1
ed
= ) de manera tal que el flujo x
d
es mximo en e
{ }
' '
( max : ' 1, 2,..., ; 1 )
d d ed
x x d D = = = .

Proposicin 6.1
Un vector de asignacin x
*
resuelve el problema anterior si y slo si es max-min justo en
el sentido sealado por la Definicin 6.2. La solucin x
*
de este problema es nica.

Finalmente, la formulacin completa del problema de MMF con caminos fijos
nicos es la siguiente:

6.2.1 Formulacin completa del Algoritmo 1:


Variables
x
d
flujo asignado a la demanda d
u
ed
variable auxiliar binaria, u
ed
= 0 si el enlace e pertenece al camino de la
demanda d, e esta saturado y x
d
es mximo en e; u
ed
= 1 en cualquier otro
caso
z
e
variable auxiliar del flujo para el enlace e



43
Restricciones

(6.2.2a)

(6.2.2b)

(6.2.2c)

(6.2.2d)
(6.2.2e)


con todas las x
d
y z
e
continuas no negativas y todas las u
ed
binarias (6.2.2f)

Como comentarios que podemos hacer al respecto de la formulacin de las
ecuaciones anteriores, si observamos la ecuacin (6.2.2b) podemos ver que lo que
bsicamente quiere decir es que para cada demanda, si consideramos slo los enlaces que
la conforman, existe alguno para el cual u
ed
es igual a 0, lo cual implica que se enlace e
est saturado y x
d
es mximo 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 ecuacin (6.2.2c),
bsicamente nos hace ver que si u
ed
es igual a cero para un determinado enlace, entonces
la parte de la derecha de sa ecuacin es cero tambin, 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 u
ed
es igual a cero, entonces x
d
= max{x
d
: d=1,2,D, y
'
1
ed
= } (dicho en otras palabras, si u
ed
=0 entonces x
d
es el mximo flujo en el enlace e.
Por ende, usando la Preposicin 6.1, el problema (6.2.2) tiene una solucin nica
* * * *
1 2
( , ,..., )
D
x x x x = , idntica a la solucin inicial del problema (6.2.1)).
Finalmente, el nico vector justo max-min (mximo vector de asignacin
lexicogrfico)
* * * *
1 2
( , ,..., )
D
x x x x = , puede ser hayado usando el siguiente algoritmo 1.


6.2.2 Pasos para resolver el Algoritmo 1

Paso 0: Poner
*
0 x =

Paso 1: : min / : 1, 2,...,
e ed
d
t c e E

= =
`
)

Paso 2:
* *
: 1,2,..., ; : 1, 2,...,
e e ed d d
d
c c t para e E x x t para d D
| |
= = = + =
|
\ .

' '
'
(1 ) 1 1, 2,...,
' 1, 2,...,
1, 2,..., 1
1, 2,..., 1
ed d e
d
ed ed
e
ed e e ed d
d
ed e e d ed
d e ed
x c e
d D
c c x e d D
c z x e d D y
x z e d D y

=1, 2, ...,
=
=1, 2,..., =
=1, 2, ..., = =
=1, 2,..., = =

44
Remover todos los enlaces saturados (todos los enlaces e con c
e
=0). Para
cada enlace removido e, remover todos los caminos y correspondientes
demandas que usan ese enlace removido (todas las d con 1
ed
= ).

Paso 3: Si no queda ninguna demanda ms, entonces detenerse. En caso
contrario ir al paso 1.

Observar que la cantidad t calculada en el paso 1, es la solucin del siguiente
problema de programacin lineal (LP):

maximizar t (6.2.3a)
sujeto a 1, 2,...,
ed e
d
t c e E
| |
=
|
\ .

(6.2.3b)

Esa observacin nos permitir a nosotros extender la nocin y solucin de algoritmos
para problemas ms generales MMF como el que veremos ms adelante.


6.3 Algoritmo 2: Max-Min Fairness para
caminos fijos con cotas

Ahora seguiremos considerando el caso del MMF para caminos fijos, pero
agregndole ahora pesos a las demandas y cotas superior e inferior a los flujos asignados
a esas demandas.

6.3.1 Formulacin 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
c
e
capacidad del enlace e
w
d
peso de la demanda d
h
d
lmite inferior para el flujo de la demanda d
H
d
lmite superior para el flujo de la demanda d

Variables
x
d
flujo asignado a la demanda d, x = (x
1
, x
2
,, x
D
)

Objetivo
Encontrar el vector de asignacin x, el cual, cuando est ordenado en orden
ascendente, es lexicogrficamente mximo entre todos los vectores de asignacin
ordenados ascendentemente.
45
1, 2,...,
1, 2,...,
0
d d d
ed d d e
d
h x H d D
w x c e E
x

=
=

Restricciones

(6.3.1a)
(6.3.1b)

(6.3.1c)


En la restriccin (6.3.1b) la carga del enlace e inducida por el flujo x
d
es igual a
ed d d
w x , lo cual implica que el flujo actual asignado a la demanda d es igual a w
d
x
d
.
Debido a la presencia de lmites inferiores, el problema se puede tornar irresoluble.

La solucin al problema del Algoritmo 2 (MMF/EFIXSP),
* * * *
1 2
( , ,..., )
D
x x x x = ,
puede ser encontrada usando el algoritmo 6.3.2 que enunciaremos a continuacin. Este
algoritmo es similar al algoritmo 6.2.2 visto anteriormente. Hace uso tambin del
siguiente problema LP:


maximizar t (6.3.2a)

sujeto a 1, 2,...,
d ed e
d
t w c e E
| |
=
|
\ .

(6.3.2b)


6.3.2 Pasos para resolver el Algoritmo 2:


Paso 0: Poner
*
d d
x h = para d = 1, 2,, D y
: 1, 2,..., ;
e e ed d d
d
c c w h para e E = =

Remover todos los enlaces saturados (todos los e con c
e
= 0). Para cada
enlace removido e remover todos los caminos y correspondientes
demandas que usan el enlace removido (todas las d con 1
ed
= ).
Paso 1: Resolver el problema LP (6.3.2) para obtener t.

Paso 2:


Remover todos los enlaces saturados (todos los e con c
e
=0). Para cada
enlace removido e remover todos los caminos y correspondientes
demandas que usen el enlace removido (todas las d con 1
ed
= ).
Paso 3: Si no quedan ms demandas entonces detenerse. En caso contrario ir al
paso 1.

* *
: 1, 2,..., ; : 1, 2,...,
e e ed d d d
d
c c t w para e E x x t para d D
| |
= = = + =
|
\ .

46
Observacin
La implementacin de este algoritmo consiste bsicamente 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 cuestin. De esta manera, nos aseguramos que el ancho de
banda no se aumente ms que el ancho de banda requerido por el usuario. Es una manera
de poner un tope superior al ancho de banda.

En las prximas secciones consideraremos un problema ms general para MMF,
que involucrar optimizacin simultnea 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 continuacin es
con capacidades para caminos flexibles.
Se considerar ahora el caso donde mltiples 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 asignacin lexicogrficamente mayor que el que
resuelve el caso de los caminos fijos.


6.4 Algoritmo 3: Max Min Fairness para
mltiples caminos

El siguiente problema es para mltiples caminos flexibles (MMF/FLMP, Max-
Min Fairness for Flexible Multiple Paths).

ndices
d = 1, 2,, D demandas (pares de nodos)
p = 1, 2,, P
d
caminos candidatos para la demanda d
e = 1, 2,, E enlaces

Constantes

edp
= 1 si el enlace e pertenece al camino p de la demanda d; 0 en caso contrario
c
e
capacidad del enlace e

Variables
x
dp
flujo (ancho de banda) asignado al camino p de la demanda d
X
d
flujo total (ancho de banda) asignado a la demanda d, X = (X
1
, X
2
,,
X
D
)





47
1, 2,...,
0 1, 2,...,
1, 2,...,
d dp
p
d
edp dp e
d p
X x d D
t X d D
x c e E
= =
=
= =

Objetivo
Encontrar el vector de asignacin de flujo total X, el cual, cuando ordenado en
orden ascendente, es lexicogrficamente mximo entre todos los vectores de
asignacin ordenados en orden ascendente.

Restricciones
1, 2,...,
dp d
p
x X d D = =

(6.4.1a)
1, 2,...,
edp dp e
d p
x c e E = =

(6.4.1b)

todos los x
dp
0. (6.4.1c)


El problema con el que ahora tratamos es ms difcil de resolver que su
contraparte de camino nico MMF/FIXSP, debido a que ahora las soluciones de la
apropiada extensin al problema LP (6.2.3) son, en general, no nicas. La extensin es
como sigue.


maximizar t (6.4.2a)


sujeto a (6.4.2b)

(6.4.2c)

(6.4.2d)

todos los 0
dp
x (6.4.2e)

La funcin objetivo (6.4.2a), junto con la restriccin (6.4.2c) es equivalente al
objetivo en el que estamos interesados en realidad:

maximizar min {X
d
: d = 1, 2,, D}

Eso se debe a que por la ecuacin (6.4.2c), si queremos maximizar t, esto
equivale a querer maximizar el mnimo de X
d
. Es decir, max{t, t- X
d
0, d: 1,2,D} =
max min{ X
d
, d:1,2,D}.

El problema (6.4.2) puede tener mltiples soluciones.

La solucin de MMF/FLMP, tal como el Algoritmo 3 que se expondr a
continuacin es substancialmente ms complicada. Consiste tambin en una aplicacin
iterativa de una extensin del problema LP (6.4.2), pero el uso de la extensin incluye un
48
' '
' ' '
' '
'
' 1, 2,...,
0 ' 1, 2,..., ( )
1, 2,...,
d d p
p
d d d
ed p d p e
d p
X x d D
t X d D t const
x c e E
= =
=
=

paso que chequea qu demanda de asignacin X

d
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 X
d
(6.4.3a)

sujeto a (6.4.3b)

(6.4.3c)

(6.4.3d)

todos los
'
0
d p
x (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
solucin ptima del mismo. Pongamos n := 0, Z
0
:= , Z
1
:= {1, 2,,
D}, y t
d
:= t
*
para cada d Z
1
.

Paso 1: Pongamos n := n + 1. Empecemos considerando las demandas d Z
1
una
por una, para chequear si el volumen total de asignacin
*
d
X puede hacerse mayor a t
*
,
sin decrementar las mximas asignaciones ya encontradas t
d
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 Z
1
(demanda d Z
1
se considera que bloquea, si X
d
no puede
incrementarse ms) entonces ir al Paso 2. En caso contrario, cuando la primer demanda
que bloquee se encuentre, digamos demanda d, agregar d al conjunto Z
0
y borrarla del
conjunto Z
1
(Z
0
:= Z
0
{d}, Z
1
:= Z
1
\{d}). Si Z
1
= , entonces detenerse (el vector
* * * *
1 2 1 2
( , ,..., ) ( , ,..., )
D D
X X X X t t t = = es la solucin para el Problema (6.4.1); en caso
contrario proceder al Paso 2.


Paso 2: Solucionar el problema LP siguiente (modificacin del (6.4.2)) para
mejorar las mejores asignaciones totales actuales:

maximizar t




49
1
0
1, 2,...,
0
0 ( )
1, 2,...,
d dp
p
d
d d d
edp
d p
dp e
X x d D
t X d Z
t X d Z t const
e E
x c

= =
=
=
=

sujeto a (6.4.4a)

(6.4.4b)
(6.4.4c)

(6.4.4d)

(6.4.4e)

todos los 0
dp
x (6.4.4f)

Nombremos (t
*
, x
*
, X
*
) a la solucin de (6.4.4). Pongamos t
d
:= t
*
para cada d
Z
1
y vayamos entonces al Paso 1 nuevamente.
Observar que puede suceder que la solucin ptima de (6.4.4) no incremente al t
*

porque puede que haya ms demandas que bloqueen adems 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 X
d
es estrictamente mayor que t
*
. En otro caso, la demanda
considerada resulta ser bloqueadora en realidad. Notar tambin que la solucin de NBT1
para algunos d Z
1
puede mostrar que para algunas otras d Z
1
el volumen resultante
X
d
es mayor que t
*
. Esas demandas d son no bloqueadoras y no necesitan de tests
separados. Los clculos deben ser realizados usando la solucin resultante del Paso 0 (o
Paso 2) como solucin inicial de NBT1 para cada d Z
1
.
Cerramos finalmente esta seccin con la siguiente proposicin.


Proposicin 8.2:
El vector final de volumenes de asignacin total
* * * *
1 2
( , ,..., )
D
X X X X = , que
resulta de la solucin del Problema (6.4.4) obtenida en la ltima iteracin del Algoritmo
3, es nico.





6.5 Algoritmo 4: Max Min Fairness para
mltiples caminos acotado


El siguiente problema es para mltiples caminos flexibles (MMF/FLMP, Max-
Min Fairness for Flexible Multiple Paths).

La idea detrs de este algoritmo es la siguiente. Es bsicamente 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 vea cunto era la mayor cantidad de recursos que la red me poda ofrecer
50
para cada demanda, determinando a su vez cunta carga llevara 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, segn el ancho de banda que
portan. Supongamos que analizamos primero la primer demanda. Tenemos ya sus sub-
demandas 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 nmero 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.























51












Parte III

Arquitectura de Software













52
Captulo 7

Representacin de la red e
interaccin con ARCA

En los prximos captulos presentaremos la estructura en la que fue creado el
software NET-TE. Se presentarn los packages utilizados y especificar las principales
tareas de las clases que los conforman, as como su implementacin.
El orden en el que se presentaran los packages ser el siguiente.
En un principio, se empezar en este Captulo 7 con el Package correspondiente a
la topologa de la red en donde se presentarn los elementos que la constituyen as como
una breve descripcin de los mismos. En una diferente seccin dentro de este mismo
captulo, tambin se presentar al package encargado de la interaccin con el ARCA. El
mismo tiene como objetivo el poder crear un rea comn 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 Captulo 8 al Package Programa. El
mismo se encarga de la interfaz grfica de la aplicacin. Se encarga de ofrecerle al
usuario, por medio del modo grfico, la manera de acceder a las distintas funcionalidades
del software, como ser ingresar la topologa manualmente, configurar los parmetros de
los enlaces, desplegar los LSPs ya creados y eliminar los que se desee, obtener
informacin sobre el porcentaje de utilizacin de cada enlace en la red y observar de
manera grfica por medio de la diferenciacin de colores los distintos rangos de
utilizacin que el usuario desee analizar, etc.
Luego en el Captulo 9 describimos el Package Cargar Red, encargado de
implementar la funcionalidad de cargar la topologa de la red sobre la cual se esta
trabajando de manera automtica.
Ms adelante, en el Captulo 10, presentamos el Package Crear LSPs, que es
donde se implementa el algoritmo CSPF de computacin de caminos para hayar los
LSPs.
Por ltimo, en el Captulo 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 trfico de la red, en donde el
usuario especifica todos las demandas representadas por los pares origen-destino, para
luego darla como parmetro de entrada a los algoritmos de redes justas y MIRA.

7.1 El Package topologa


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.
53
El package Topologa 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 Topologa

A continuacin se describe ms en detalle las clases anteriormente mencionadas.

54
7.2 La clase Elemento

Esta clase define un objeto Elemento del cual heredarn 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 abstraccin.

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 slo 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 configuracin.
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 representacin en la interfaz grfica sea distinta.

7.4 La clase Link

La clase Link es el elemento fundamental de nuestra arquitectura de red. Esta
clase concentra la mayora de los atributos necesarios para hacer TE como ser
capacidad, capacidad reservada, pesos administrativos, afinidades, etc. Cada instancia de
Link representa una conexin bidireccional entre dos instancias de LER o LSR que recibe
en su construccin y lleva un registro de los LSPs que por l pasan.
La clase Link cuenta con mtodos que permiten determinar si es un posible
candidato para la creacin de un nuevo LSP basado en el ancho de banda que tiene
disponible mediante el ruteo explcito 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 trfico. 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.InterfazGrfica

Debido a que este package est exclusivamente relacionado con la compatibilidad
entre el NET-TE y el ARCA, realizamos los comentarios sobre sta relacin en la seccin
7.6.1.

55
7.6.1 Compatibilidad con ARCA - Analizador de Redes de
Caminos Virtuales

ARCA es el nombre del software que realizaron Daro Buschiazzo Malveira,
Andrs Ferragut Varela y Alejandro Vzquez Paganini con motivo de su proyecto de fin
carrera para el Instituto de Ingeniera Elctrica de la Facultad de Ingeniera, Universidad
de la Repblica. El proyecto se llev a cabo en el perodo comprendido entre el mes de
Junio de 2003 y el mes de Mayo de 2004 en Montevideo, bajo la tutora del Ing. Pablo
Belzarena.
El proyecto analiza el problema de brindar garantas de Calidad de Servicio
(QoS), as como realizar Ingeniera de Trfico sobre redes de datos. En dicho proyecto se
desarroll una herramienta de software que permite relevar el funcionamiento de una red
dada, estimando parmetros de QoS permitiendo predecir el comportamiento de la red en
presencia de carga y evaluar el impacto de diferentes polticas en dicho funcionamiento,
as como conocer las garantas 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
topologas que luego podrn ser usadas en el software ARCA.
Cuando se decide guardar cierta topologa con todas sus caractersticas (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 ledos por el software
para representarlas grficamente. Cuando el usuario elige guardar la topologa en formato
.arc (de ARCA) para luego abrirla con el software ARCA, el software llama a un
intrprete que lo que hace es convertir las clases de NET-TE en el formato especfico
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.

















56



















Figura 7.2: Diagrama UML del Package Arca.InferfazGrfica





















57
Captulo 8

Interfaz Grfica

Este captulo se dedica en su mayora a la interfaz grfica de la aplicacin. En el
package Programa, se implementan las distintas ventanas que permitirn 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
topolgicas con sus respectivos parmetros; tambin la barra de herramientas ubicada a la
derecha de la pantalla que es la principal herramienta para acceder a las utilidades del
software; adems, la ventana en la cual se introduce la informacin requerida para poder
cargar la red automticamente, as como las utilizadas para ver el estado actual de la red
en cuanto a lo que utilizacin y caractersticas 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
visualizacin del estado actual de la red. Todo esto, por medio de una interfaz grfica
sencilla e intuitiva, que sea de fcil 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
travs de una interfaz grfica mediante el uso de elementos como ser ventanas, menes,
dilogos, etc.
A continuacin se presenta el diagrama de clases UML del package y luego se
detallan las clases que lo componen.


58


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 topologas de red.
La clase VentanaConf implementa los dos paneles principales del software que
son el panel grfico 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 estadsticas o correr distintos algoritmos de
ingeniera de trfico.

59


Figura 8.2: Marco Principal del software



8.3 Clase Intrprete

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 topologas y guardar los diferentes estados de la red en un archivo .txt que
luego podr abrirlo para que la clase Intrprete lo convierta en elementos grficos de una
forma sencilla.





60
Formato del archivo segn el elemento de red:

Enlace Nodo LSP
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
LSR
name LSR_1
coord 208 125
routerid 10.10.10.1
ip 10.10.10.1
comunnity xxxxxxxx
descubierto
end
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 grfico asociado al elemento se ubicar en la pantalla. End es utilizado
por el intrprete 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 dilogo del tipo
jFileChooser cuando un usuario decide abrir o guardar un archivo, permiten que slo se
muestren los archivos con los formatos especficos de entrada-salida del software. La extensin
.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
61
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 algn 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 configuracin 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 trfico del tipo Best Effort en enlaces crticos. De esta manera el usuario podr correr
CSPF y usar como restricciones las afinidades creadas en la red.






62
8.6 Clase Cargar Topologa

Esta clase implementa el marco en el cual el usuario podr ingresar los
parmetros necesarios para poder descubrir la topologa en estudio.



Figura 8.5: Ventana Cargar Topologa

Algunos parmetros son obligatorios como la direccin IP de algn router de la
red (casi siempre el que tiene directamente conectado), para comenzar la iteracin hasta
descubrir completamente la red. Otros parmetros obligatorios a ingresar, tal como se
puede apreciar en la Figura 8.5 son la versin SNMP que se desea ejecutar, tenindose
como opciones en primera instancia la versin 1 y 2, pudindose agregar la versin 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
(tambin 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 Estadsticas 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
63
LSPs que pasan por el elemento, o en el caso de los enlaces su utilizacin. Ver Figura
8.6. Por otro lado la clase Estadsticas, genera un marco ms 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 crticos y ver detalles de los LSPs establecidos en la red. Observar la Figura 8.7.




Figura 8.7: Ventana Estadsticas
64
8.8 Clase Utilizacin

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 utilizacin. Luego se llama a un
mtodo que recorre todos los enlaces de la red y los pinta de un color que depende de la
utilizacin actual del enlace. Observar Figura 8.8.



Figura 8.8: Ventana Utilizacin

Esta ventana puede estar abierta siempre y con slo apretar el botn Aceptar se
reflejar de un modo rpido los cambios de utilizacin en los enlaces debido a los nuevos
LSPs creados en la red.

















65
Captulo 9

Carga automtica de la topologa

Tal como el nombre del captulo lo indica, presentaremos ahora el package
encargado de la funcionalidad de extraer la informacin necesaria de los routers para
poder cargar la topologa automticamente, y no de manera manual tal como lo podra
hacer el usuario al crear una topologa desde cero o cargar una ya existente.



9.1 El package CargarRed - Implementacin

En nuestro caso cargar la topologa de red se entiende como descubrir todos los
routers presentes en la red que estn intercambiando informacin de ruteo mediante el
protocolo de enrutamiento OSPF.
Al ser OSPF un protocolo de estado de enlace cada router slo conoce los routers
de la red con los que forma adyacencias e intercambia informacin de ruteo
(generalmente en ospf slo 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, especficamente 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.


















66
OSPF-MIB DEFINITIONS RFC1213-MIB DEFINITIONS


















Figura 9.1: Grupos y Tablas que componen los MIBs de OSPF y RFC-1213

Especficamente 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 sera el NMS si tenemos en cuenta la
especificacin del protocolo SNMP.


















Figura 9.2: Ejemplo de una red
ospfGeneralGroup
ospfAreaTable
ospfStubAreaTable
ospfLsdbTable
ospfAreaRangeTable
ospfHostTable
ospfIfTable
ospfIfMetricTable
ospfVirtIfTable
ospfNbrTable
ospfVirtNbrTable
ospfExtLsdbTable
ospfRouteGroup
ospfAreaAggregateTable
ospfConformance

mib-2
system
interfaces
ifNumber
ifTable
at
ip
icmp
tcp
udp
egp
transmission
snmp
67
Lo primero que hace el software es cargar el RouterID del router, que es la
direccin IP que identifica unvocamente 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
informacin de las adyacencias que forma con los dems 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 tendramos como respuesta a la
consulta del ospfNbrTable:


ospfNbrIpAddr

ospfNbrRtrId

ospfNbrState

10.10.10.17 10.10.10.1 Full(8)


En la tabla anterior slo 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

ospfNbrRtrId

OspfNbrState

10.1.1.2 10.10.10.2 Full(8)
10.1.1.6 10.10.10.3 Full(8)
10.1.1.14 10.10.10.4 Full(8)
10.1.1.18 10.10.10.5 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 iteracin hasta que no se
descubren routers nuevos y ya me conect a todos los que tengo en memoria.





68
En resmen,

1- Me conecto al primer router y lo guardo en las listas RoutersRed y
RoutersDescubiertosNoConectados (en esta lista adems guardo la IP por la que
lleg al router) que al principio estn vacas.

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 ms 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 parmetro 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 ifDescr ifType ifMtu ifSpeed ifAdminStatus ifOperStatus
1 ATM4/0 sonet 4470 149760000 down down
2 FastEthernet0/0 ethernetCsmacd 1500 100000000 up up
3 FastEthernet1/0 ethernetCsmacd 1500 100000000 up up
4 Ethernet2/0 ethernetCsmacd 1500 10000000 down down
5 Ethernet2/1 ethernetCsmacd 1500 10000000 down down

A la direccin IP que tiene asociada la interfaz se le asocia un nmero de interfaz
(ifIndex). Esta asociacin se encuentra en la tabla ospfAddrTable que tambin 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.










69






























Figura 9.3: Diagrama UML del package CargarRed.












70
Captulo 10

Computacin de caminos

El presente captulo analiza los distintos mecanismos para la computacin de
caminos que van a ser futuros LSPs. Se destaca el algoritmo Constraint Shortest Path
First (CSPF) utilizado para encontrar caminos basndose 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 adems distintos criterios a aplicar de
Ingeniera de Trfico (TE), de manera que pueda optimizar el resultado arrojado por el
CSPF, filtrando todas las soluciones posibles y dejando solamente las que ms se
aproximan a lo que desea. Tambin se presenta otro algoritmo online para el
establecimiento de rutas que es el MIRA. Se expone tambin el mtodo manual en donde
el usuario establece los LSP de manera explcita indicando el camino que desee.

10.1 El package CrearLSPs

Este package esta conformado por 5 clases: Ruteo Explcito, CSPF, Algoritmo,
CarConf y MIRA.
Para poder visualizar mejor el relacionamiento entre dichas clases que componen
este package, a continuacin se muestra el diagrama UML del mismo.















Figura 10.1: Diagrama UML del package CrearLSPs
71
A continuacin pasamos a describir en ms detalle cada una de las clases
mencionadas anteriormente.

10.2 La clase Ruteo Explcito

Esta es la clase usada cuando el usuario de la red desea establecer los LSPs de
manera manual, sealando enlace a enlace, cul 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 prximo a crearse.
El usuario debe ingresar como parmetro de entrada el ancho de banda que desea
tenga el LSP y cul es el Nodo de Origen donde desea comience el LSP.
Podemos observar a continuacin en la Figura 10.2 una imagen de cmo luce la
ventana desplegada.




Figura 10.2: Ventana usada para el Ruteo Explcito de un LSP.


Una vez ingresados ambos parmetros, 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 condicin del ancho de banda. Con esto ltimo nos referimos a que slo
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 tambin grficamente.
Finalmente una vez presionado Aceptar, se guardar automticamente dicho LSP
y se actualizarn los valores de ancho de banda disponibles en los enlaces que se vieron
afectados.


72
10.3 La clase CSPF

Esta clase es la usada para computar caminos para futuros LSPs por medio del
algoritmo CSPF explicado en el Captulo 4.
Esta clase lo que bsicamente hace es recolectar toda la serie de parmetros
ingresados por el usuario, necesarios para determinar cules son las restricciones que
desea cumpla el o los LSPs solucin y qu criterio de ingeniera de trfico desea usar.
Posteriormente, de acuerdo a las opciones elegidas, pasa a llamar a la clase Algoritmo
(explicada en la Seccin 10.4) que es donde reside el mtodo que implementa el Dijkstra
y los dems mtodos encargados de ejecutar el criterio de ingeniera de trfico, si es que
se eligi alguno.
Son varias las distintas opciones que se le presentan al usuario al momento de
ingresar los parmetros al sistema, de manera que pueda crear varias situaciones y
analizar cul es la que ms 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 solucin que
ms 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
73
Empecemos sealando cules son los distintos parmetros que debe ingresar el
usuario y las opciones que se le ofrecen para pasar luego a comentar ciertas
caractersticas de cmo fue implementada la clase CSPF.
As como lo muestra la Figura 10.3, automticamente 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 slo sobre los enlaces que pertenecen a una determinada Afinidad, lo cual es
prctico en caso de tener distintos tipos de trficos circulando por los enlaces de la red y
desear correr el algoritmo slo sobre los que portan un determinado tipo.
Finalmente, los siguientes parmetros obligatorios a ingresar son el Nodo de
Origen y de Destino.
Como comentario al margen, vale destacar que la ventana fu diseada para que
las opciones se vayan habilitando a medida que los parmetros vayan siendo ingresados
en orden. Esto obliga al usuario a ingresar si o si los parmetros 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
mtrica en la cual se basar luego el SPF para el clculo de los caminos solucin.
Las opciones presentadas son las siguientes;

Ruteo Mnimo 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 numrico entero mayor que 0. Este valor es una manera de
priorizar determinados enlaces frente a otros. Cuanto ms grande este valor,
menor ser la probabilidad de que el camino pase por ese enlace. Bsicamente
el camino tendera a utilizar los enlaces con menor peso.
Ruteo por Mnima 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 basndose en la cantidad de saltos. Bsicamente, 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 solucin tendern a ir por los enlaces ms ocupados (con menos
ancho de banda disponible). De esta manera se intenta no usar los enlaces ms
libres (dejndolos para futuros LSPs), sino que terminar de ocupar los ms
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
solucin tendern a ir por los enlaces ms libres, no molestando a los ms
ocupados. Es una manera de establecer los LSPs por lugares de baja
utilizacin.

74
A continuacin, una vez elegida la mtrica 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
solucin si o si. De esta manera se obliga a las posibles soluciones que contengan
determinado enlace an cuando este no estara contenido en los caminos arrojados por el
Dijkstra. Adems se le da tambin la posibilidad de lo opuesto, que no pase por
determinado enlace, an cuando ste estuviera contenido en los caminos arrojados por el
Dijkstra. La razn de estas dos opciones es que quizs por razones polticas 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
Ingeniera de Trfico 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 sern las arrojadas por el algoritmo SPF en su totalidad
y que cumplen con las restricciones elegidas por el usuario previamente.
La segunda opcin es usar un criterio de TE basado en filtrar los caminos solucin
brindados por el SPF y desplegar de entre esas soluciones, slo aquellas que no utilizan a
los enlaces ms crticos contenidos en los caminos (de ah el nombre no saturacin de
enlaces crticos).
Y por ltimo, se tiene el MINHOP, el cual, simplemente de todas las soluciones
arrojadas por el SPF, se queda con las ms cortas en cuanto a lo que a cantidad de saltos
se refiere.
Lo nico que resta es correr el Algoritmo y se desplegarn 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 adems la utilizacin y otros
tiles datos de los enlaces que conforman los caminos elegidos y descartados.
Se comentar ms en detalle el algoritmo SPF, criterios de TE y la ventana
mencionada anteriormente, en las prximas secciones.
Pasemos ahora a comentar los mtodos ms importantes y caractersticas de la
implementacin de la clase CSPF.
El primer mtodo a destacar es el mtodo podar(). Dicho mtodo es el encargado
de podar todos los enlaces de la red para pasar como parmetro de entrada al algoritmo
SPF (Dijkstra) solamente a aquellos que cumplen con la condicin 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 algn enlace del combo Enlace Ausente,
simplemente retiro a ese enlace de la lista de enlaces a considerar que entran como
parmetro de entrada al algoritmo SPF.
La situacin es ms 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 opcin,
simplemente se redefinen los pesos de los enlaces de acuerdo a la opcin de mtrica
elegida. Luego se corre el Dijkstra. Si encuentra una solucin ya de entrada, entonces en
ese caso ya la despliega en pantalla. Si se encuentra ms de una, se pasa a fijar si se eligi
algn criterio de TE en particular y de ser as, se aplica ese criterio y despliega en
75
pantalla el resultado conjuntamente con los datos de los caminos descartados, en caso de
haberlos.
Sin embargo en caso de haber elegido la opcin Enlace Presente, se debe tener
ms cuidado en la manera de correr el Dijkstra y cmo hacerlo. Primeramente se
redefinen los pesos de los enlaces de acuerdo a la mtrica 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 sera la solucin. En
todos estos casos en particular, se corre el SPF slo 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, tambin se debe tomar en cuenta ya que quizs
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 tambin 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 solucin a mostrar. En todo caso se deber tener especial cuidado con la
aparicin de errores en alguna pasada debido a la no existencia de una solucin.
Finalmente, recurre a la clase Algoritmo en caso de haber ms de una solucin
posible arrojada por el SPF y elegido algn criterio de TE en particular.
Una vez elegida la solucin deseada, quedar guardada con el resto de los LSPs
ya establecidos.


10.4 La clase Algoritmo

En esta clase se encuentra la implementacin del algoritmo Dijkstra, y los de
SNMP SNMP.
En cuanto al algoritmo de Dijkstra, ste es implementado por medio del mtodo
shortestPath(), el cual es encargado de calcular todos los caminos solucin del origen a
destino, con la mtrica ms chica. Recibe como parmetros 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 opcin 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 mtodo a destacar es el podar2(). Este es encargado de aplicar el segundo
criterio de TE (no saturacin de enlaces crticos). Bsicamente lo que procura es descartar
a aquellas soluciones que poseen los enlaces ms crticos. Con eso nos referimos a
aquellos enlaces que estn casi saturados y que poseen muy poco ancho de banda
disponible, lo cual causara que de pasar el LSP por ellos, queden prcticamente
inutilizables para futuros LSPs. Lo que se hace es tomar de cada camino solucin
76
arrojado por el Dijkstra, el enlace con menor ancho de banda disponible (llamemos
enlaceCrtico al valor de ancho de banda de dicho enlace). Se compara cada
enlaceCrtico de cada solucin y se descartan los caminos con el enlaceCrtico ms
pequeo. En caso de quedar an ms de una solucin posible, significa que el
enlaceCrtico para cada uno de estos caminos tiene el mismo valor. Entonces se pasa a
ver cuntos enlaces en cada uno de esos caminos, tienen un ancho de banda similar al
guardado en enlaceCrtico. Los caminos que tengan ms cantidad de enlaces con ese
valor, se descartan (ya que se estara perjudicando a un nmero mayor de enlaces en esos
caminos). Y si an despus de eso, seguimos con ms de una posible solucin, buscamos
el siguiente valor ms pequeo que sea mayor que enlaceCrtico y redefinimos
enlaceCrtico para cada solucin. Repetimos as el proceso iterativamente hasta
quedarnos con una solucin 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 mtodo podar3(), el cual se encarga de filtrar
tambin las soluciones arrojadas por el Dijkstra, quedndose slo con las ms cortas en
cuanto a lo que nmero de saltos se refiere.

10.5 La clase CarConf

Esta clase es la que implementa la ventana que se despliega cuando tenemos ms
de un camino posible y se eligi algn 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 solucin luego de
aplicar alguno de los criterios de TE. El otro muestra informacin sobre los caminos que
77
fueron descartados (stos son los caminos que pertenecan a la solucin brindada por el
Dijkstra, pero que no cumplieron el requerimiento de TE elegido).
La informacin 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 utilizacin.


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 cuestin. 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 solucin ms sencilla pero computacionalmente ms costosa.
Por ms informacin referirse al Captulo 5. La implementacin de la ventana
usada para el algoritmo MIRA se comenta en el Captulo 11.





























78
Captulo 11

Algoritmos de justicia y el MIRA

En este captulo 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 Trfico (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 Intrprete que pudiera leer dicho archivo y lo
cargue en el software. Se muestra el formato de salida del archivo MT.
Tambin contiene los tres algoritmos implementados para el clculo de caminos
en las llamadas redes justas. Con esto se trata de ofrecerle al usuario distintos criterios en
la bsqueda de caminos para el establecimiento de los LSPs de manera de poder distribuir
todas las demandas solicitadas de la mejor manera posible. En la bsqueda de ese mismo
objetivo se presenta tambin 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 topologa de red cargada y una matriz de trfico 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:

79
Figura 11.1: Diagrama UML del package MT.


A continuacin se describe ms 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 ms que son prioridad (es la prioridad del camino, por defecto es 1) y
demandamin (demanda mnima del camino, por defecto es 0), estos atributos slo son
usados en la clase FairnessNetwork al elegir el mtodo 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 trfico. De esta
manera el usuario podr simular para una topologa dada y posibles variantes de sta,
como quedan los LSPs para la misma matriz de trfico.



80
11.4 La clase GeneroMT

Esta clase implementa el marco en el cual el usuario podr crear el archivo que
representa la matriz de trfico. Al crear cada ruta se debe configurar sus atributos como
ser el nombre (tiene por defecto Ruta seguido de un nmero que se incrementa al crear
una ruta nueva), ancho de banda deseado, nodo origen, nodo destino y afinidad (es
opcional, el camino slo 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 terminacin .txt y ser usado por las clases
FairnessNetwork y OffLineMira y tambin por GeneroMT cuando se desea modificar un
archivo de matriz de trfico ya creado.

Formato del archivo:

Matriz de trfico
Camino
name Ruta_1
connection LER_1 LER_2
ancho 1.0
afinidad: no tiene
end

81
El archivo comienza con Matriz de trfico que es utilizado por el intrprete para
indicar que es un archivo generado por la clase GeneroMT.
End es utilizado por el intrprete 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 despus crear los LSPs para las distintas rutas. Primero se llama al
mtodo que carga el archivo de matriz de trfico al oprimir el botn Cargar Matriz y se
llama al mtodo shortestPath() de la clase Algoritmo que calcula todos caminos posibles
con la menor mtrica para las distintas rutas de la matriz de trfico.




Figura 11.3: Ventana FairnessNetwork

Despus de calcular todos los caminos posibles para cada ruta, se elige uno de
los cuatro algoritmos Fairness. Se selecciona la mtrica a utilizar entre Peso o Minhop y
al apretar el botn Correr se calcula el ancho de banda final de cada camino. Para los
ltimos dos algoritmos no se usan los parmetros Peso o Minhop, por lo que no se
habilitan en se caso. Tambin, 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 mtodos algoritmo1() (que implementa el Fairness Bsico) y algoritmo2()
(que implementa el Fairness acotado) usan un slo camino de los calculados para cada
ruta a diferencia del algoritmo3() (que implementa el Fairness con mltiples caminos) y
algoritmo4() (que implementa el Fairness con mltiples caminos acotado) que usan todos
los caminos calculados para cada ruta.
82
El mtodo algoritmo1() corre el mtodo buscar() que cuenta los caminos que
pasan por cada enlace y el mtodo mnimo1() que incrementa el ancho de banda
reservado de todos los enlaces por donde pasa algn camino, esto lo hace hasta que satura
al menos un enlace de cada camino, a ese enlace le fija su ancho de banda. El mtodo
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 mtodo algoritmo2() corre el mtodo buscar(), pero antes de llamar al mtodo
mnimo1() 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

Despus se crean por cada camino un enlace virtual con el ancho de banda
deseado para esa ruta y se llama mtodo mnimo1(). 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 mtodo algoritmo1() permiten que el ancho de banda
final de cada camino sea como mnimo igual a demandamin y como mximo igual al
ancho de banda deseado.
El mtodo algoritmo3() corre el mtodo calculatodos() que calcula todos los
caminos posibles para cada ruta, sin considerar mtrica alguna, ni el ancho de banda de
los enlaces. Despus corre los siguientes mtodos creaMatrizFairLink(),
OptimizacionLineal(), OptimizacionLinealChequeo(). Estos mtodos 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 sub-
demandas.
El mtodo algoritmo4() corre los mtodos calculatodos(), creaMatrizFairLink(),
OptimizacionLineal(), OptimizacionLinealChequeo(), igual que en el algoritmo3().
La nica diferencia es que despus 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.
83
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 mltiples
caminos para cada ruta, se muestran en la pantalla ubicada a la izquierda, las sub-
demandas 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
pintarn de color rojo a rayas en pantalla, para su diferenciacin.

11.6 La clase LasDemandas

Esta clase se encarga de desplegar una ventana cuando se elige el tercer algoritmo
de fairness (fairness con mltiples caminos). La misma exhibe datos numricos sobre
cada una de las demandas, de manera que sea ms fcil para el usuario el poder apreciar
cules demandas lleg a satisfacer y sobrepasar el ancho de banda requerido, y cules 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.









84














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 trfico previamente configurada y guardada en un archivo .txt
con el formato que se explic anteriormente. Luego de haber cargado la matriz de trfico
el usuario tiene que elegir cules 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, slo
los LER`s o elegirlos manualmente.




Figura 11.7: Ventana configuracin MIRA

85
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 algn
motivo no se encontrase ningn 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 grficamente las posibles rutas en la red y si as lo quisiera, se mapearn
las demandas al apretar el botn Crear LSPs.

















86












Parte IV

Conclusiones























87
Captulo 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 automtica y desplegarla en pantalla.
La hiptesis 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 mtodos de bsqueda 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 tenindolos determinados desde un
principio.
Antes de empezar a trabajar formalmente en el proyecto, sabamos 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 ingeniera de trfico 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 atrs, podemos ahora distinguir
claramente cuatro distintos objetivos. El primero fue el desarrollar una herramienta que
permita la creacin 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 dnde 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 dnde irn 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 ms justa a todas ellas.
Finalmente, como cuarto y ltimo objetivo, se plante la incorporacin de una
funcionalidad que le permitiera al usuario el poder levantar la red a la que est conectado
de manera automtica y visualizarla en pantalla.
Es importante destacar que en todo momento, con respecto a la validacin de los
datos que son devueltos al aplicar los distintos algoritmos de Fairness, se comprob su
correcto funcionamiento basndose en distintas pruebas y ensayos realizados por nuestra
parte. Tambin se compar con ejemplos de los cuales ya se conocan de manera
confiable los resultados y viendo as que obtenamos los valores esperados.
Finalmente, en cuanto a la escalabilidad de los algoritmos a medida que la red
crece de tamao, pudimos corroborar en la prctica, que el tercer y cuarto algoritmo de
fairness son los que consumen ms tiempo de operacin debido a la gran cantidad de
iteraciones que se realizan. De cualquier manera, probamos con topologas de 30 nodos
aproximadamente, y vimos que el tiempo que demora en desplegar los resultados es
88
prcticamente al instante y no considerable (poco ms de un par de segundos cuando
mximo).


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 grfica sencilla y fcil de usar por cualquier
usuario, la cual le otorga una amplia flexibilidad al momento de disear o modificar su
red. Adems, se le brind al usuario varios mecanismos para poder visualizar el estado
actual de la red, pudiendo ver informacin de elementos en particular o de la red en
general. Pensando en la comodidad del usuario en la manera de cmo apreciar esa
informacin, se brinda toda esa informacin tanto en forma numrica como grfica.
El problema del establecimiento de los LSPs fue solucionado utilizando el
algoritmo CSPF. Realizamos varias pruebas sobre distintas topologas y situaciones, y
pudimos apreciar el correcto funcionamiento del mismo. Pudimos tambin comprobar
que es muy til el tener varias opciones a elegir, ya que esto nos permiti crear mltiples
escenarios y tener as un abanico ms grande de soluciones de entre las cuales elegir.
Tambin pudimos comprobar la gran utilidad que ofrece el algoritmo MIRA. Se
hicieron pruebas de chequeo sobre topologas en las cuales haban claramente ciertos
enlaces que eran crticos para futuras posibles demandas, y pudimos apreciar como el
algoritmo tenda a evitar dichos enlaces crticos.
Finalmente, nos planteamos escenarios donde el algoritmo CSPF no encontraba
ningn 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.
Adems, 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 automtica 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 tena el software NET-TE instalado, a la red. Una vez conectada, y luego
de ingresar la informacin 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 topologa descubierta. Debido a restricciones de
seguridad, no pudimos descubrir la red entera, ya que slo tenamos visibilidad hasta los
routers ms prximos 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 Trfico, 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
cuestin.
Como conclusin global se puede afirmar que se lograron realizar con xito todos
los objetivos trazados, juntando diversos criterios y algoritmos para el establecimiento de
89
LSPs en un slo software, el cual puede ahora ser usado como pilar para el desarrollo de
un software ms completo y grande, que agregue ms 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 an ms posibilidades y algoritmos a los
cuales acceder.
En cuanto a la carga automtica de la red, actualmente NET-TE se encarga
solamente de levantar la topologa conjuntamente con la velocidad de cada enlace. Son
varios los datos que un usuario puede querer extraer de la red. En primer lugar, podra
levantar y mostrar los estados de las adyacencias entre nodos de la red. En esta primera
versin del software, no nos preocupamos de dichos estados. Tambin se podra levantar
las mtricas de OSPF y el ancho de banda libre de los enlaces. Uno de los datos ms
tiles que interesara extraer en una posible segunda versin 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, resultara bastante prctico.
Otra posible tarea a realizar a futuro, es aumentar la variedad de algoritmos
usados para el clculo 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 topologa de la
red y extraer la velocidad de los enlaces, para as luego determinar dnde se ubicarn
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 implementacin 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 cerrara el
ciclo que comienza con la carga automtica de la red conjuntamente con los LSPs ya
establecidos, contina con el clculo realizado por NET-TE de las nuevas rutas que
satisfacern 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.










90














Apndices























91
Apndice A

Multi Protocol Label Switching
(MPLS)

MPLS es un estndar emergente del IETF (RFC 3031) que surgi para consensuar
diferentes soluciones de conmutacin multinivel, propuestas por distintos fabricantes a
mitad de los 90s. Ante todo, debemos considerar MPLS como el avance ms reciente en
la evolucin de las tecnologas de routing y forwarding en las redes IP, lo que implica
una evolucin en la manera de construir y gestionar estas redes. Los problemas que
presentan las soluciones actuales de IP sobre ATM, tales como la expansin sobre una
topologa virtual superpuesta, as como la complejidad de gestin de dos redes separadas
y tecnolgicamente 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 gestin de backbones, as como en la provisin
de nuevos servicios de valor aadido.


A.1 Descripcin funcional de MPLS

La base del MPLS est en la asignacin e intercambio de etiquetas, que permiten
el establecimiento de los LSP por la red. Cada LSP se crea a base de concatenar uno o
ms saltos (hops) en los que se intercambian las etiquetas, de modo que cada paquete se
enva de un "conmutador de etiquetas" (Label-Swiching Router) a otro, a travs de la red
MPLS. Un LSR no es sino un router especializado en el envo de paquetes etiquetados
por MPLS.
MPLS separa las dos componentes funcionales de control (routing) y de envo
(forwarding). Del mismo modo, el envo se implementa mediante el intercambio de
etiquetas en los LSPs. Sin embargo, MPLS no utiliza ninguno de los protocolos de
sealizacin 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 ms 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 ms sencilla de gestionar que la solucin clsica 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 lneas punto a punto.




92
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 conmutacin de etiquetas (LSR).
Un LER es un dispositivo que opera en los extremos de las redes MPLS y funciona como
el punto de interconexin entre sta y la red de acceso. Cuando un paquete llega a uno de
estos routers, el LER examina la informacin 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 situacin opuesta, siendo estos dispositivos los responsables de remover la
etiqueta para entregar el paquete en la forma en que fue recibido.
Despus de que los paquetes han sido etiquetados por el LER, stos comienzan su
viaje a travs de la red MPLS, encontrndose en su trayectoria con los routers de
conmutacin de etiquetas (LSRs). Estos son los encargados de dirigir el trfico 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
especifca el siguiente "salto" y una nueva etiqueta. El LSR intercambia entonces sta
etiqueta por la que contena el paquete y lo enva 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

93
Como se coment anteriormente, los LERs se encargan de clasificar paquetes con
base en un nivel de calidad de servicio. A este proceso de clasificacin se le conoce como
Clase Equivalente de Direccionamiento (FEC, por sus siglas en ingls). Un FEC es la
representacin de un conjunto de paquetes que comparten los mismos requerimientos
para su transporte, de manera que todos los paquetes que pertenezcan a un FEC seguirn
el mismo LSP para llegar a su destino. Contrario a lo que sucede en el enrutamiento IP
convencional, la asignacin de un paquete a un determinado FEC en MPLS se hace una
sola vez.
Los LERs utilizan diferentes mtodos para etiquetar el trfico. Bajo el esquema
ms 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 Informacin de
Etiquetas (LIB) para determinar la accin 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 sealarse 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 anlisis: mapear un
protocolo de la capa 2 del modelo OSI a MPLS, mapear MPLS a la capa 3 del modelo y
clasificar el trfico con gran flexibilidad. Adicionalmente, un LER define qu trfico
deber ser tratado como MPLS y qu paquetes debern tratarse como trfico IP ordinario.
A diferencia de un encabezado IP, las etiquetas en MPLS no contienen una
direccin IP, sino ms bien un valor numrico acordado entre dos nodos consecutivos
para proporcionar una conexin a travs de un LSP. La etiqueta es un identificador corto
de longitud fija empleado para asociar un determinado FEC, normalmente de significado
local.
94
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 conexin de enlace de datos (DLCI) de Frame Relay. Otras
tecnologas, como Ethernet y enlaces punto a punto, requieren de una "etiqueta de
insercin" (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. An cuando la
"etiqueta de insercin" no es parte de ninguno de estos encabezados, sta provee un
medio de relacin 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
parmetro que decrementa su valor por cada nodo recorrido hasta llegar a cero.
Obsrvese en la Figura A.4 cmo est compuesta la "etiqueta de insercin" y cul es su
ubicacin dentro de los paquetes IP.


A.3 Mtodo de distribucin de etiquetas

Es tambin importante conocer la forma en que se lleva a cabo la distribucin 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. An
cuando los routers convencionales suelen ser programados para determinar qu es lo que
harn con un determinado paquete, es preferible contar con una asignacin dinmica de
reglas que permita mayor flexibilidad. Existen dos alternativas diferentes para hacer esta
distribucin. Cuando los routers son capaces de "escuchar" estas reglas, crear una base de
datos interna y distribuir esta informacin 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
mtodo de distribucin, el LER de salida es, por lo regular, el encargado de la
distribucin de etiquetas, siendo este proceso en sentido contrario al direccionamiento de
paquetes. El control ordenado ofrece como ventajas una mejor Ingeniera de Trfico y
95
mayor control de la red, aunque, en comparacin 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 distribucin de etiquetas con control ordenado.


La distribucin 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 "empujndolas" hacia
arriba. Este mtodo de distribucin, conocido como transferencia de bajada no
solicitada ("downstream unsolicited), puede hacerse cada determinado tiempo o cada
vez que cambie la Base de Informacin de Etiquetas de un router cualquiera. La segunda
opcin, denominada transferencia de bajada por demanda ("downstream on-
demand"), requiere que un router en particular solicite sus tablas, siendo stas
posteriormente distribuidas por el LER de salida. Vase la Figura A.5.
Adicionalmente, existen dos mtodos 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, an cuando stas no le sean tiles en ese momento. Despus de que
cada router posee sus tablas de etiquetas puede comenzar el direccionamiento de paquetes
a travs de los LSPs preestablecidos por un determinado FEC.
Actualmente existe una amplia variedad de protocolos utilizados para la
distribucin de etiquetas. La arquitectura MPLS no especifica uno de estos en particular,
sino que, ms bien, recomienda su eleccin dependiendo de los requerimientos
especficos de la red. Los protocolos utilizados pueden agruparse en dos grupos:
96
protocolos de enrutamiento explcito y protocolos de enrutamiento implcito. El
enrutamiento explcito es idneo para ofrecer Ingeniera de Trfico y permite la creacin
de tneles. El enrutamiento implcito, por el contrario, permite el establecimiento de
LSPs pero no ofrece caractersticas de Ingeniera de Trfico.
El Protocolo de Distribucin de Etiquetas (LDP) es uno de los protocolos de
enrutamiento implcito que se utilizan con frecuencia. LDP define el conjunto de
procedimientos y mensajes a travs de los cuales los LSRs establecen LSPs en una red
MPLS. Otros protocolos de enrutamiento implcito incluyen al Protocolo de Compuerta
de Frontera (BGP) y al protocolo de Sistema Intermedio a Sistema Intermedio (IS-
IS).
Por otro lado, entre los protocolos de enrutamiento explcito ms comunes
encontramos al protocolo LDP de Ruta Restringida (CR-LDP) y al Protocolo de
Reservacin de Recursos con Ingeniera de Trfico (RSVP-TE). El primero de estos
protocolos ofrece, en adicin a LDP, caractersticas de Ingeniera de Trfico, de manera
que sea posible negociar con anticipacin una ruta en especial. Esto permite establecer
LSPs punto a punto con calidad de servicio en MPLS. CR-LDP es un protocolo de estado
slido, es decir, que despus de haberse establecido la conexin, 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 extensin de la versin original RSVP, aunque incorpora el respaldo para MPLS. A
diferencia de CR-LDP, este protocolo permite negociar una ruta para la transmisin de
informacin, misma que debe "refrescarse" constantemente para que sta se mantenga
activa (estado blando). Mediante estos ltimos protocolos y la aplicacin de distintas
estrategias de ingeniera de trfico es posible asignar diferentes niveles de calidad de
servicio en redes MPLS.




















97
Apndice 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 aplicacin y facilita el intercambio
de informacin de gestin entre elementos de la red y es parte del stack de protocolos
TCP/IP.
Una red administrada con SNMP consta de tres componentes bsicos: estaciones
administradas, los agentes y la estacin 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 informacin que hacen
disponible al NMS va SNMP. El agente SNMP es un proceso de administracin que
reside en la estacin administrada
Cada agente mantiene uno o varias variables que describen su estado. En la
documentacin SNMP, estas variables se llaman objetos. El conjunto de todos los objetos
posibles se da en la estructura de datos llamada MIB (Management Information Base-
base de informacin de administracin). La MIB es una coleccin de informacin que es
organizada jerrquicamente, y los objetos (tambin 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 comunicacin consulta-respuesta.
Sin embargo, a veces ocurren sucesos no planeados. Los nodos administrados
pueden caerse y volver a activarse, las lneas pueden desactivarse y levantarse de nuevo,
pueden ocurrir congestionamientos, etc. Cada suceso significativo se define en un
mdulo MIB. Cuando un agente nota que ha ocurrido un evento significativo, de
inmediato le informa a todas las estaciones administradoras de su lista de configuracin.
La seguridad y la validacin de identificacin desempean un papel
preponderante en el SNMP. Un NMS tambin tiene la capacidad de aprender mucho
sobre cada nodo que est bajo su control, y tambin puede apagarlos. Por lo tanto los
agentes tienen que estar seguros de que las consultas supuestamente originadas por la
estacin administradora realmente vienen de la estacin administradora. En el SNMPv1 y
SNMPv2, la estacin administradora comprobaba su identidad poniendo una contrasea
(de texto normal) en cada mensaje. En el SNMPv3 se mejor considerablemente la
seguridad usando tcnicas criptogrficas modernas.

98
B.2 ASN.1

Como ya se mencion, el corazn del modelo SNMP es el conjunto de objetos
administrados por los agentes y ledos por la estacin administradora. Para hacer posible
la comunicacin multiproveedor, es esencial que estos objetos se definan de una manera
estndar y neutral desde el punto de vista de los proveedores. Es ms, se requiere una
forma estndar de codificarlos para su transferencia a travs de la red. Por esta razn, se
requiere un lenguaje de definicin de objetos estndar, as como reglas de codificacin.
El lenguaje usado por el SNMP se toma del OSI y se llama ASN.1 (Abstract Syntax
Notation One-notacin de sintaxis abstracta uno).

Los tipos de datos bsicos del ASN.1 se muestran en la Figura B.1.

Tipo primitivo

Significado
INTEGER Entero de longitud arbitraria
BIT STRING Cadena de 0 o ms bits
OCTET STRING Cadena de 0 o ms bytes sin signo
NULL Marcador de lugar
OBJECT IDENTIFIER Tipo de datos definido oficialmente

Figura B.1: Tipos de datos bsicos de ASN.1

Los OBJECT IDENTIFIER ofrecen una manera de identificar objetos. En
principio cada objeto definido en cada estndar oficial puede identificarse de manera
nica. El mecanismo consiste en definir un rbol de estndares, y colocar cada objeto en
cada estndar en una localidad nica del rbol. La parte del rbol que incluye la MIB del
SNMP se muestra en la figura NMERO.
El nivel superior lista todas las organizaciones de estndares importantes del
mundo y en los niveles bajos las organizaciones asociadas. Cada arco de la figura
NMERO tiene tanto un nombre como un nmero. Por tanto, todos los objetos de la
MIB de SNMP se identifican unvocamente por su nombre o nmero:

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 slo 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.
99
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 ms bajo, las variables SNMP se definen como objetos individuales.
Los objetos relacionados se renen en grupos, y los grupos se integran en mdulos. Por
ejemplo existen grupos para los objetos IP y los objetos TCP. Un router puede


Figura B.2: Diferentes jerarquas asignadas a diferentes organizaciones.

Reconocer los grupos IP, dado que a su administrador le interesa tener
informacin por ejemplo de la cantidad de paquetes perdidos. Por otra parte, un router de
bajo nivel podra no reconocer el grupo TCP, dado que no necesita usar TCP para
desempear sus funciones de enrutamiento.

100
Todos los mdulos MIB comienzan con una invocacin de la macro MODULE-
IDENTITY que proporciona el nombre y la direccin del implementador, la historia de
modificaciones y otra informacin administrativa. Luego le sigue una invocacin de la
macro OBJECT-TYPE que tiene cuatro parmetros requeridos y cuatro opcionales:

SYNTAX: define el tipo de datos de la variable
MAX-ACCESS: informacin de acceso a la variable (los ms usados lectura-
escritura, lectura).
STATUS: estado de la variable respecto a SNMP (los ms usados actual y
obsoleto)
DESCRIPTION: cadena ASCII que indica lo que hace la variable.

Un ejemplo sencillo se da en la siguiente tabla. La variable se llama RouterID del
mdulo 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 the
router in the Autonomous System.

By convention, to ensure uniqueness, this
should default to the value of one of the
router's IP interface addresses.

Figura B.3: Ejemplo

Tambin SM1 define una gran variedad de tablas estructuradas que son usadas
para agrupar objetos que tienen mltiples variables.


B.3 SNMP v1

SNMP v1 es la implementacin 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 Datagram-
Delivery Protocol (DDP) y Novell Internet Packet Exchange (IPX). Esta versin es la
ms extendida en su uso y es el protocolo de facto en la comunidad de Internet.





101
B.3.1 Operaciones Bsicas

SNMP es un protocolo simple de consulta-respuesta. El NMS hace la consulta y
la estacin administrada responde. Este comportamiento es implementado usando una de
las 4 operaciones del protocolo: Get, GetNext, Set and Trap.


Get Usado por el NMS para consultar el valor
de una variable de un objeto.
GetNext Usado por el NMS para consultar el valor
de la siguiente variable de un objeto.
Set Usado por el NMS para setear valores de
un objeto.
Trap Usado por los agentes para informar al
NMS de eventos significativos.


Figura B.4: Operaciones bsicas de SNMP



B.4 SNMP v2


Es una evolucin de la versin inicial. SNMP v2 ofrece muchas mejoras as como
opciones adicionales: GetBulk e Inform.


GetBulk Usado por el NMS para consultar
eficientemente grandes cantidades de
datos, por ejemplo varias filas de una tabla.
Inform Usado por el NMS para enviar traps a otro
NMS y obtener una respuesta.

Figura B.5: Mejoras en SNMP v2










102
Apndice C

Ejemplo de Fairness con mltiples
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 mltiples caminos
(es decir, para la bsqueda de la asignacin 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
comprensin de los algoritmos de fairness.
Es tambin importante comentar que los valores expuestos fueron calculados
usando MatLab. Debajo de cada uno de los resultados hallados, exponemos tambin los
valores arrojados por NET-TE, de manera de poder as compararlos.
Empecemos mirando en la siguiente figura la topologa a considerar en este
ejemplo.

Figura C.1: topologa 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:
{ } { }
1 2
2 1, 3 1 P y P demanda = =
Para la demanda d = 2 encontramos los posibles caminos:
{ } { }
1 2
1, 4 2, 3, 4 2 P y P demanda = =

Si resolviramos este problema siguiendo los pasos indicados por el algoritmo
llegaramos al siguiente resultado:
103
0
dp d
p
edp dp e
d p
dp
x X demanda d
x c enlace e
x demanda y

1
1
x =1 en el camino { }
1
2 P =

2
1
x =1 en el camino { }
2
1, 3 P =

1
2
x =1 en el camino { }
1
1, 4 P =

2
2
x =0 en el camino { }
2
2, 3, 4 P =
dnde la notacin
j
i
x representa el BW asignado a la demanda i por el posible camino j.

La demostracin de cmo se llega a ese resultado se exhibe a continuacin.
Empezamos observando que la cantidad total de BW asignado a la demanda 1
(X
1
) y a la demanda 2 (X
2
) es lo siguiente:

1 2
1 1 1
X x x = + demanda 1
1 2
2 2 2
X x x = + demanda 2

Si X es el vector de BW total, entonces
1 2
( , ) X X X = .
Si consideramos ( )
1 2 1 2
( ) ( ), ( ) ( , ) f x f x f x X X = = , llegamos a que ( )
i i
f x X = .
El objetivo es el buscar un vector
0 0 0
1 2
( ( , )) X X X = ,
0
( ) ( )
LEX
tal que f x f x x Q

Las restricciones con las que trabajaremos son, expresadas en trminos generales,
las siguientes:





todo camino

Lo anterior, aplicado a nuestro problema en particular, se traduce en:
1 2
1 1 1
1 2
2 2 2
2 1
1 2
1 2
1 2
2 2
1 2
1 2
2 2
2
1
2
1
0 1, 2 1, 2
j
i
x x X
x x X
x x
x x
x x
x x
x i j
+ =
+ =
+
+
+
+
= =
lo que nos lleva al primer clculo de maximizacin:

104
1 2
1 1
1 2
2 2
2 1
1 2
1 2
1 2
2 2
1 2
1 2
2 2
max
2
*
1
2
1
0 1, 2 1, 2
j
i
x x
x x
x x
con x Q
x x
x x
x x
x i j

= =

Haciendo cuentas,
1 2 1 2 1 2 2 1
1 1 2 2 1 2 1 2
1 2
2 ( ) ( ) 3 x x x x x x x x

+ + + = + + +




0
2 3 1.5 1 = es el mximo (NET-TE en su caso arroja el valor 1).

Observar que hay mltiples valores de
j
i
x para los cuales se da que

0
1 2
( ) ( ) 1 f x f x = = =

Por ejemplo,

cumple con todas las restricciones y
0
1 2
( ) ( ) f x f x = =



1 2
1 1
1 2
2 2
) 0.5 0.5
1 0
b x y x
x y x
= =
= =
Tambin cumple con las restricciones. Adems, siguen
habiendo ms posibles soluciones.

Ahora que hayamos el mximo valor de , el siguiente paso es tratar de
maximizar cada demanda d por separado, y ver si puede hacerse ms grande que ese
valor hayado anteriormente, con la restriccin que no se vean afectadas el resto de las
demandas. Segn 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:
1 2 1 2
1 1 1 1 1
0 1 2 1 2
2 2 2 2 2
max ( ) max
1 ( ) 1
f x x x x x
f x x x x x
x Q x Q
= + +

= = + +





1 2
1 1
1 2
2 2
) 1 0
1 0
a x y x
x y x
= =
= =
105
La solucin a problema LP anterior es:
1 2 1 2
1 1 2 2
0
0.9214,1.0786, 0.9214, 0.0786
x x x x
X
(
( =
(



(NET-TE en su caso arroja los valores [1, 1, 1, 0])

Si observamos cuanto quedo el X
1
finalmente vemos que
0 0
1
( ) 0.9214 1.0786 2 ( 1) f X = + = = , entonces aumento!
Pasamos ahora a resolver el problema LP para la segunda demanda (d = 2).
Eligiendo k = 2, testeamos:
1 2
2 2 2
1 2
1 1
max ( )
1
f x x x
x x
x Q
= +

lo cual nos lleva a la solucin:
1 2 1 2
1 1 2 2
0 0
2
0.7436, 0.6066, 0.8663, 0.1337 ( ) 1
x x x x
X f X
(
( = =
(



(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!

Segn el algoritmo, tenemos que pasar entonces el ndice k = 2 al grupo B.

Por lo que, { } { }
0
2
2 ' 1 1
B
B y B con t = = = = , 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:
1 2
1 1
1 2
2 2
2 1 1 2
1 2 1 1 1
1 2 1 2
1 2 2 2 2 2
2 2
1 2
1 2
2 2
max
1
max
2 ( )
1 1 ( )
2
1
0 1, 2 1, 2
B
j
i
x x
x x
x x f x x x
x x t f x x x
x Q x x
x x
x i j

+ = +

+ = = +


+

= =

Resolviendo, obtenemos un 2 = (NET-TE arroja el mismo valor).

Hay una solucin tal que
1 2
1 1 1
( ) 2 f x x x = + = ?
106
La repuesta es Si:
1 2
1 1
1 2
2 2
1
1 0
x x
x y x
= =
= =


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 { } { } ( )
2
2 ' 1 1
B
B y B t = = = , lo
averiguamos:


1 2 1 2
1 1 1 1 1
1 2 1 2
2 2 2 2 2 2
max ( ) max
1 ( ) 1
B
f x x x x x
t f x x x x x
x Q x Q
= + +

= = + +





La solucin obtenida es:
1 2 1 2
1 1 2 2
0.9214,1.0786, 0.9214, 0.0786
x x x x
X
(
( =
(



(NET-TE en su caso arroja los valores [1, 1, 1, 0]).

Como podemos apreciar, X
1
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
1
2
B
t = .
El conjunto B ha quedado entonces vaci. Hemos llegado entonces al fin del
algoritmo y hayado la solucin final del vector de asignacin X.
La solucin final es:
1
2
B
t = y
2
1
B
t = . O lo que es igual, X = (2, 1), con cada
camino para cada demanda teniendo el siguiente BW:


1
1
x =1 en el camino { }
1
2 P =

2
1
x =1 en el camino { }
2
1, 3 P =

1
2
x =1 en el camino { }
1
1, 4 P =

2
2
x =0 en el camino { }
2
2, 3, 4 P =

En el caso de NET-TE, arroja los mismos valores que los sealados
anteriormente.







107
Apndice 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 continuacin 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 mtodo abrirArch() de la clase Principal.
Nuevo, para crear un nuevo archivo mediante el mtodo nuevoArch() de la clase
Principal.
108
Guardar y Guardar como, para guardar un archivo, mediante los mtodos
guardarArch() y guardarNeverSaved() de la clase Principal.
Cerrar, para cerrar una archivo usando el mtodo cerrarArch() de la clase Principal.
Salir, para salir del programa usando el mtodo processWindowEvent(WindowEvent
e) de la clase Principal.

Dentro de la barra de herramientas las opciones son:

Abrir, para abrir un archivo mediante el mtodo
botonOpen_actionPerformed(ActionEvent e) de la clase Principal.
Nuevo, para crear un nuevo archivo mediante el mtodo
botonNew_actionPerformed(ActionEvent e) de la clase Principal.
Guardar, para guardar un archivo, mediante el mtodo
botonSave_actionPerformed(ActionEvent e) de la clase Principal.
Crear matriz de trfico, para crear un archivo de una matriz de trfico mediante el
mtodo 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
extensin sea .txt. Se puede elegir para que muestre los archivos con extensin .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 mtodo abrirArch() de la clase
Principal, se chequea si hay algn archivo abierto. Si lo hay, se hace una llamada el
mtodo cerrarArch() de la clase Principal.
En caso que no halla algn archivo abierto o que se halla cerrado el archivo
abierto (aprovado=true), se despliega una ventana por la cual el usuario puede navegar a
travs del sistema de archivos con el fin de seleccionar el deseado. Si el archivo
seleccionado es con extensin .arc el mtodo abrirArch() llama al mtodo cargar().
Despus de haber elegido el archivo y de haber presionado Abrir se intenta abrir.
En caso que se logre realizar dicha accin, se muestra el contenido en la pantalla.
Adems se escribe la ruta de acceso del archivo en la barra de Ttulo y se guarda
la ruta de acceso al archivo seleccionado para que las futuras ventanas de dilogo 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
mtodo nuevoArch() de la clase Principal. Al llamar a este mtodo, se chequea si hay
algn archivo abierto. En caso que lo halla, se llama al mtodo cerrarArch() de la clase
109
Principal. En caso que este mtodo devuelva aprovado=true, se genera un nuevo
archivo. Si aprovado=false el programa no realizar accin alguna, volviendo al estado
anterior al llamado del mtodo 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 configuracin. En caso que se
elija el tem Guardar, se llama el mtodo 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 mtodo
guardarNeverSaved() de la clase Principal quien dar la opcin al usuario de elegir la
ubicacin y el nombre con el que desee guardar el archivo. Si el archivo ya ha sido
guardado (neverSaved=false) se llama al mtodo guardarSaved() de la clase Principal
que sobrescribe el archivo existente. En la figura 3 puede verse el diagrama de
colaboracin del mtodo 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 mtodo
guardarNeverSaved() de la clase Principal.
Si el archivo que se quiere guardar es con extensin .arc los mtodos
guardarSaved() y guardarNeverSaved() llaman al mtodo salvar().

Cerrar:

Para cerrar un archivo es necesario realizar un evento que llame al mtodo
cerrarArch() de la clase Principal. Esto se puede hacer seleccionando Cerrar en el men
Archivo.
En caso que halla algn archivo abierto se da la eleccin de:

salvar y cerrar
cerrar sin salvar
cancelar

Si se elige la primera opcin y el archivo nunca ha sido guardado se llama al
mtodo guardarNeverSaved() de la clase Principal. Si ya ha sido guardado se llama al
mtodo guardarSaved() de la clase Principal. Luego se llama al mtodo clear() de la
clase Principal. En caso de elegir cerrar sin salvar se llama directamente al mtodo
clear() de la clase Principal. Si se presiona en Cancelar no se realiza accin alguna.

Salir

Al seleccionar este tem, se genera el evento, presionado del botn salir, el cual es
tomado por el mtodo salirArch_actionPerformed(e) de la clase Principal, que a su vez
invoca al mtodo processWindowEvent(WindowEvent e) de la clase Principal, mtodo
110
que se encarga de cerrar el programa dando las opciones correspondientes para guardar
un archivo abierto.

D.2 Crear matriz de trfico

Despus de tener una topologa de la red, es posible crear una matriz de trfico.
Al realizar un evento sobre el tem , se llama al mtodo
botonRuteo_actionPerformed(ActionEvent e) de la clase Principal el cual crea una
instancia de la clase GeneroMT.
En la clase GeneroMT se configuran los parmetros de cada ruta de la matriz de
trfico.
En esta clase dentro del mtodo 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.
Despus de asignar los parmetros 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 botn Agregar que llama al mtodo
jButtonInsertar_actionPerformed(ActionEvent e).
Si se desea modificar una ruta ya creada, se debe seleccionar la ruta y despus de
hacer las modificaciones deseadas se debe apretar el botn Cambiar que llama al mtodo
jButtonEditar_actionPerformed(ActionEvent e).
Si se desea borrar una ruta se debe apretar el botn Borrar que llama al mtodo
jButtonBorrar _actionPerformed(ActionEvent e).
Si se desea modificar una matriz de trfico ya creada, se debe apretar el botn
Cargar que llama al mtodo jButtonCargar_actionPerformed(ActionEvent e) que a su ves
llama al mtodo stringToVectors de la clase InterpreteMT.
Para crear la matriz de trfico se debe apretar el botn Guardar que llama al
mtodo jButtonGuardar_actionPerformed(ActionEvent e) que a su ves llama al mtodo
guardarArch() el cual llama al mtodo EditarTexto de la clase InterpreteMT.

D.3 Barra Vertical
Dentro de la barra vertical las opciones son:

Cargar red, para cargar la topologa de red mediante
carConfActionPerformed(ActionEvent e) el mtodo de la clase VentanaConf.
LER, para crear un LER mediante el mtodo
botonLER_actionPerformed(ActionEvent e) de la clase VentanaConf.
LSR, para crear un LSR mediante el mtodo
botonLSR_actionPerformed(ActionEvent e) de la clase VentanaConf.
111
LINK, para crear un LINK mediante el mtodo
botonLink_actionPerformed(ActionEvent e) de la clase VentanaConf.
Eliminar, para eliminar el objeto seleccionado mediante el mtodo
botonDel_actionPerformed(ActionEvent e) de la clase VentanaConf.
Atrs/Adelante, para deshacer la ltima accin realizada mediante los mtodos
restBack() y restForw()de la clase VentanaConf.
LSP explicito, para crear un LSP manualmente mediante el mtodo
crearLspActionPerformed(ActionEvent e) de la clase VentanaConf.
CSPF, para crear un LSP con la menor mtrica posible mediante el mtodo
botonCSPFActionPerformed(ActionEvent e) de la clase VentanaConf.
Fair Network, para crear los LSPs de la matriz de trfico elegida mediante el mtodo
botonMTActionPerformed(ActionEvent e) de la clase VentanaConf.
MIRA, para crear los LSPs de la matriz de trfico elegida mediante el mtodo de
botonMIRAActionPerformed(ActionEvent e) de la clase VentanaConf.
Lista de LSPs, para mostrar la lista de LSPs creados mediante el mtodo
listaLsps_actionPerformed(ActionEvent e) de la clase VentanaConf.
Borrar LSP, para borrar el LSP seleccionado mediante el mtodo
borrarLspActionPerformed(ActionEvent e) de la clase VentanaConf.
Estadsticas, para mostrar las estadsticas de la topologa de red mediante el mtodo
botonEstadActionPerformed(ActionEvent e) de la clase VentanaConf.
Utilizacin, para mostrar en pantalla la utilizacin de los enlaces mediante el mtodo
botonUtilActionPerformed(ActionEvent e) de la clase VentanaConf.

A continuacin se detallan los mtodos de la lista anterior ms 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 mtrica y
el criterio TE a utilizar y es opcional indicar afinidad, enlace presenten y enlace ausente.
En esta clase dentro del mtodo 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 botn Aplicar Algoritmo, se llama al mtodo
jButtonAlgoritmo_actionPerformed(ActionEvent e). Este mtodo primero se fija en la
variable booleana pinto. Ver Figura D.2.

112


Figura D.2: Diagrama de razonamiento al apretar el botn 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 mtodo shortestPath de la clase Algoritmo. Porque hay que
calcular el camino mas corto entre nodo origen y el nodo A, llamando al mtodo
shortestPath de la clase Algoritmo y hay que calcular el camino mas corto entre nodo
destino y el nodo B, llamando al mtodo 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 ms de un camino posible se puede observar en pantalla los
distintos caminos encontrados al oprimir la flecha hacia la derecha que llama al mtodo
jButtonAdelante_actionPerformed(ActionEvent e). Despus de oprimir la flecha hacia la
derecha se puede ir hacia atrs al oprimir la flecha hacia la izquierda que llama al
mtodo jButtonAtras_actionPerformed(ActionEvent e).
El mtodo jButtonAceptar_actionPerformed(ActionEvent e), crea un LSP del
camino seleccionado con los dos mtodos 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 trfico se llama al
mtodo jButtonCargar_actionPerformed(ActionEvent e) el cual llama al mtodo
stringToVectors de la clase InterpreteMT. Luego al oprimir el botn Correr que llama al
mtodo jButtonCorrer_actionPerformed(ActionEvent e) en donde se crea una instancia a
la clase MIRA. En la clase MIRA se llama al mtodo hallamaxflows para calcular el
mximo ancho de banda entre los nodos, luego este mtodo llama al mtodo 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 mtodo correr, que para cada ruta
de la matriz de trfico cargada llama al mtodo podar, luego llama al mtodo
shortestPath de la clase Algoritmo, para calcular un camino para cada ruta y guardar el
resultado en el array de vectores resultuno.
El mtodo jComboBox_actionPerformed(ActionEvent e), pinta los enlaces por los
cuales pasa la ruta seleccionada en el combo Rutas posibles.
113
El mtodo 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 trfico se
llama al mtodo jButtonCargar_actionPerformed(ActionEvent e) el cual llama al mtodo
stringToVectors de la clase InterpreteMT. Luego se debe el elegir uno de los siguientes
algoritmos:

Fairness bsico
Fairness acotado
Fairness con mltiples caminos
Fairness con mult. caminos acotado

Si se eligi unos de los 2 primeros algoritmos se debe elegir la mtrica entre peso
o minhop.
Al marcar Elegir camino manualmente se puede elegir entre todos los caminos
con la menor mtrica posible calculados de cada ruta, con cual quedarse. Esto se hace
llamando al mtodo jCheckBox4_actionPerformed(ActionEvent e) que llena el combo
Lista de rutas con todas las rutas de la matriz de trfico. Al seleccionar una ruta de este
combo se llama al mtodo podar, luego al mtodo 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 botn Correr que llama al mtodo
jButtonCorrer_actionPerformed(ActionEvent e). Este mtodo primero se fija que
algoritmo se selecciono, esto lo hace fijndose 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.
114
Si se eligi el algoritmo2, entonces JcheckBox1().isSelected=true . Se crea una
instancia de la clase Requerimientos, en donde se configuran la demanda mnima 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 mtodo correr llama para cada
ruta de la matriz de trfico cargada al mtodo podar, luego al mtodo shortestPath de la
clase Algoritmo, si hay mas de un camino posible llama al mtodo podar2 de la clase
Algoritmo y guarda un camino para cada ruta.
El mtodo buscar, busca cuantos caminos pasan por cada enlace y lo guarda en la
variable delta de la clase Link.
El mtodo mnimo 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 contina hasta que
satura algn 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.

115
El mtodo calculatodos, calcula todos los caminos posibles entre el nodo origen y
el nodo destino sin considerar BW, mtrica ni afinidad.
El mtodo OptimizacionLineal, calcula el valor de la variable auxiliar tau.
El mtodo OptimizacionLinealChequeo, maximiza de a una demanda y compara
su valor con el valor de la variable auxiliar tau calculado en OptimizacionLineal.
Los mtodos 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, despus de tener el ancho de banda final de cada
demanda se llama al mtodo ordenar, que ordena de mayor a menor las sub-demandas de
cada demanda segn 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 mtodo 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 mtodo 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.

















116
Bibliografa


[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. Visin y Principios de la Ingeniera de
Trfico en Internet. Autores: D. Awduche, A. Chiu, A. Elwalid, I. Widjaja, X.
Xiao. Mayo 2002.
[3] MPLS: Technology and Applications. Captulo 7: Constraint-Based Routing.
Autores: Bruce Davie y Yakov Rekhter. Ao 2000.
[4] Engineering Internet QoS. Captulo 12: Future. Autores: Sanjay Jha y Mahbub
Hassan. Ao 2002.
[5] Data Networks: Routing, Security, and Performance Optimization. Captulo 8:
Quality of Service. Autor: Tony Kenyon. Ao 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.
Ao 1993.
[9] Multi-terminal network flows, Journal of SIAM. Autores: R.E. Gomory y T.C.
Hu. Ao 2002.
[10] Routing, Flow and Capacity Design in Communication and Computer
Networks. Captulo 8: Fair Networks. Autores: Michal Pioro y Deepankar
Medhi. Ao 2004.







117
Glosario de trminos


ARCA: Analizador de Redes de Caminos Virtuales, software que analiza el problema de
brindar garantas de Calidad de Servicio (QoS) as como realizar Ingeniera de Trfico 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 definicin de objetos estndar usado por SNMP.
BGP: Border Gateway Protocol, protocolo de ruteo interdominio.
CBR: Constraint Based Routing, ruteo que intenta encontrar un camino que optimice cierta
mtrica 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 distribucin de etiquetas del tipo enrutamiento
explcito que ofrece caractersticas de Ingeniera de Trfico.
CSPF: Constraint Shortest Path First, algoritmo para la computacin 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, representacin 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 mayora al control del
trfico en lo que a la ingeniera de trfico 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 distribucin 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 accin 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 trfico dentro de la red MPLS.
MIB: Management Information Base, coleccin de informacin organizada jerrquicamente
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 asignacin usado para formular el esquema de asignacin
de recursos en donde se intenta asignar la mayor cantidad de recursos a cada demanda, al mismo tiempo
que se intenta mantenerlos lo ms similares posible.
MNF: Maximum Network Flow, mximo 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, tecnologa de ruteo y reenvo de paquetes en redes IP
que se basa en la asignacin e intercambio de etiquetas, que permiten el establecimiento de caminos a
travs de la red.
NET-TE: Networking Traffic Engineering, nombre del software diseado en este proyecto que
hace alusin a la Ingeniera de Trfico en redes; tema principal de ste trabajo.
118
NMS: Network Management System, estacin 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 trminos del
ancho de banda o algn otro parmetro.
RSVP-TE: Reservation Protocol with Traffic Engineering, protocolo de enrutamiento
explcito. En ste caso en particular, es una extensin de la versin 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
seleccin de los caminos ms cortos.
SLA: Service Level Agreement, acuerdo sobre el nivel de servicio con el cliente donde se
especifican parmetros 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 aplicacin que
facilita el intercambio de informacin de gestin entre elementos de la red y es parte del stack de
protocolos TCP/IP.
SWP: Shortest Widest Path, ruteo que se basa en la bsqueda del camino con el ancho de banda
ms grande y, en caso de haber mltiples caminos, se queda con el que tiene la mnima cantidad de saltos.
TE: Traffic Engineering, disciplina que procura la optimizacin 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 informacin de la topologa.
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 bsqueda de caminos con el mnimo nmero de
saltos y, si encuentra mltiples caminos, se queda con el que tiene ancho de banda mayor.