Diseño de red IP sobrevivible con enrutamiento OSPF

LS Buriol
Departamento de Informática, Universidad Federal de Rio Grande do Sul, Av. Bento
Gonçalves, 9500, 91501-970 Porto Alegre, RS, Brasil

MGC Resende y M. Thorup

Centro de investigación de sistemas de Internet y redes, AT&T Labs Research, 180 Park
Avenue, Florham Park, NJ 07932

El tráfico del protocolo de Internet (IP) sigue las reglas establecidas por los
protocolos de enrutamiento. Los protocolos basados ​en la ruta más corta, como
Open Shortest Path First (OSPF), el tráfico directo basado en los pesos de arco
asignados por el operador de la red. Cada enrutador calcula las rutas más cortas
y crea tablas de destino utilizadas para el flujo de enrutamiento en las rutas más
cortas. Si un enrutador tiene múltiples enlaces salientes en las rutas más cortas
a un destino dado, divide el tráfico de manera uniforme sobre estos enlaces.
También es función del protocolo de enrutamiento especificar cómo debe
reaccionar la red a los cambios en la topología de la red, como fallas de arco o
enrutador. En tales situaciones, el tráfico IP se redirige a través de los caminos
más cortos que no atraviesan la parte afectada de la red. Este artículo aborda el
problema de asignar pesos y multiplicidades de OSPF a cada arco, con el
objetivo de diseñar redes enrutadas OSPF eficientes con una multiplicidad
ponderada total mínima (multiplicidad multiplicada por la longitud del arco)
necesaria para enrutar la demanda requerida y manejar cualquier falla de arco o
enrutador. Las multiplicidades se limitan a un conjunto discreto de valores, y
suponemos que se proporciona la topología. Proponemos un algoritmo
evolutivo para este problema, y ​presentamos los resultados aplicándolo a varias
instancias de problemas del mundo real. © © 2006 Wiley Periodicals, Inc. REDES, vol.
49 (1), 51–64 2007
conectando los enrutadores. A nivel de red, Internet se compone de varios sistemas
autónomos (AS) que generalmente se encuentran bajo la administración de una sola
institución, como una empresa, una universidad o un proveedor de servicios. El
enrutamiento dentro de un único AS se realiza mediante un Protocolo de puerta de enlace
interior (IGP), mientras que un Protocolo de puerta de enlace exterior (EGP) se utiliza para
enrutar el flujo de tráfico entre los AS. El tráfico de IP se enruta en pequeños fragmentos
llamados paquetes. Una tabla de enrutamiento le indica al enrutador cómo reenviar
paquetes. Dado un paquete con una dirección de destino IP en su encabezado, el enrutador
recupera de la tabla la dirección IP del siguiente salto del paquete.
OSPF (Open Shortest Path First) es el IGP más utilizado. Para este protocolo, se
debe asignar un peso entero a cada arco, y cada router conoce la topología y los
pesos de la red completa. Con esta información, cada enrutador calcula los gráficos
de las rutas más cortas (peso) de cada enrutador en el AS a sí mismo. Los gráficos
no necesitan ser árboles, porque se deben considerar todas las rutas más cortas
entre dos enrutadores. Las demandas se enrutan en los gráficos de ruta más cortos
correspondientes. En cada enrutador s, La demanda total que abandona este nodo y
se dirige a un enrutador de destino t se divide uniformemente entre todos los enlaces
salientes del enrutador s en los gráficos de ruta más cortos que terminan en t.

Palabras clave: Internet; Enrutamiento OSPF; diseño de red; survivabil-

ity algoritmo evolutivo
Esta demanda no solo consiste en la demanda originada en s, pero también de
demanda que pasa s en camino a t.
1. INTRODUCCIÓN
Los pesos de los arcos son asignados por el operador AS. Cuanto menor sea el

Internet es la red global de redes de comunicación interconectadas, peso, mayores serán las posibilidades de que el tráfico se enrute en ese arco. Diferentes

formada por enrutadores y enlaces.
Recibido en septiembre de 2004; aceptado en noviembre de 2005
Correspondencia a: MGC Resende; correo electrónico: mgcr@research.att.com Patrocinador de la
subvención del contrato: Consejo Nacional Brasileño para el Desarrollo Científico y Tecnológico
(CNPq) (a LSB). Patrocinador de la subvención del contrato: AT&T Labs Research (a LSB).
Patrocinador del contrato: El proyecto europeo "Coevolución y Selforganización en Redes
Dinámicas" (COSIN) (a LSB). DOI 10.1002 / neto.20141
Publicado en línea en Wiley InterScience (www.interscience.wiley.com).
configuraciones de peso conducen a diferentes patrones de flujo de tráfico. Se pueden
establecer pesos para optimizar el rendimiento de la red, como minimizar la congestión
[5,8,9], así como minimizar el costo de diseño de la red. En este artículo, abordamos el
último caso.
Dada una topología de red y demandas de tráfico previstas, el problema de
diseño de red OSPF es encontrar un conjunto de pesos OSPF que minimice el costo
de la red. Más precisamente, tenemos una red dirigida G = (N, UNA), dónde norte es el
conjunto de enrutadores y UNA es el conjunto de arcos potenciales donde se puede
instalar la capacidad y una matriz de demanda re eso, para cada par

© © 2006 Wiley Periodicals, Inc. ( s, t) ∈ norte × NORTE, especifica la demanda re t s Entre s y t.

REDES — 2007 — DOI 10.1002 / neto

 HIGO. 1. División de carga para multiplicidades de arco. Izquierda: estructura de arcos salientes del nodo u; Medio: estructura considerando el arco concepto;
Derecha: considerando la estructura enlace concepto. [La figura del color se puede ver en la edición en línea, que está disponible en
www.interscience.wiley.com].
los multiplicidad de arco de un arco una es el número de enlaces paralelos asociados
con el arco a. Queremos determinar un peso entero positivo w una ∈ [ 1, 65535], así como
la multiplicidad, para cada arco una ∈ UNA, tal que el costo de la red se minimice. El
costo de red en nuestra aplicación es la suma total de los productos de la multiplicidad
y la longitud de cada arco. Los pesos de OSPF están restringidos para ser idénticos
para todos los enlaces en el mismo arco. Además, consideramos que la capacidad de
cada enlace es fija e igual a METRO. Por lo tanto, cada capacidad de arco está limitada
a un conjunto discreto de valores
0, METRO, 2 METRO, 3 METRO, . . . .
Las multiplicidades se determinan de modo que toda la demanda se pueda enrutar de
manera factible en la red, es decir, ninguna carga de arco excede la capacidad del arco.
Para propósitos de calidad de servicio (QoS), la definición de ruta factible es ligeramente
diferente. Un fl ujo factiblemente encaminado es tal que ninguna carga de arco excede una
fracción ρ
(0 < ρ ≤ 1) de la capacidad del arco.
Para fines de división del tráfico, cada enlace paralelo se considera como un enlace
independiente. Para mayor claridad, usamos el término
arco para referirse a la estructura instalada entre dos nodos y
enlace para cada enlace capacitado insertado en esta estructura. Como ejemplo,
considere la Figura 1, donde una carga atraviesa el enrutador tu está destinado a un
enrutador de destino t ( no se muestra en la fi gura). Arcos ( −− →
u, v 1) y ( −− → u, v 4) pertenecer al camino más corto
gráfico a destino t y arcos ( −− → u, v 2) y ( −− →u, v 3) no haga. Dejar
las multiplicidades de arco de ( −− → u, v 1) y ( −− →u, v 4) ser 1 y 3, respec-
Tively Luego, un cuarto de la carga se enrutará en arco
( u,
−−v→1) que tiene un enlace, y tres cuartos se enrutarán en arco ( −− →
u, v 4), que tiene tres enlaces.
Debido a que pueden ocurrir fallas en arcos o enrutadores, es deseable diseñar
redes IP que sean sobrevivibles sujetas a este tipo de fallas. Para superar la
complejidad asociada con la generación de todas las combinaciones posibles de
fallas, nos limitamos a un solo arco o falla de un solo enrutador. Debido a que los
enlaces en un arco dado dependen en cierto sentido, consideramos en este artículo
la falla de arco único en lugar de la falla de enlace único. Por lo tanto, cuando falla
un arco, todos los enlaces asociados con ese arco fallan. Cuando falla un enrutador,
todos los arcos entrantes y salientes hacia / desde este enrutador se desactivan.
Además, se descartan todas las demandas que tienen este enrutador como origen o
destino. También asumimos que ninguna falla de arco único desconecta la red. Una
falla generalmente cambia uno o más gráficos de ruta más cortos en la red. Por
consiguiente, la demanda puede ser redirigida en diferentes caminos. Si hay
suficiente capacidad para que toda la demanda pueda ser reenviada de manera
factible para todos
52 REDES — 2007 — DOI 10.1002 / neto
posibles fallas de un solo arco y un solo enrutador, la red se llama sobrevivible En el
caso de fallas, la fracción de la capacidad del arco que limita la carga generalmente
es mayor que la fracción utilizada para definir un flujo factible para el caso de falla.
Por ejemplo, en el caso de que no haya falla, un flujo sería factible si la carga del
arco no excede el 70% de la capacidad del arco, mientras que para el caso de falla
única, esta fracción podría ser, digamos, el 90%. Estos valores, que llamamos ρ norte y
ρ F para los casos de falla y falla, respectivamente, dependen de los requisitos de
calidad de servicio de la red. Una alta calidad de servicio está asociada con una
fracción baja. De manera similar, como se muestra en la Figura 2, el costo de la red
es inversamente proporcional a los valores de las fracciones.
Varios artículos sobre el enrutamiento OSPF y el diseño de red IP sobreviviente
han aparecido recientemente en la literatura. Fortz y Thorup [9] proponen un algoritmo
de búsqueda local para determinar los pesos de OSPF para minimizar la congestión
de la red. Ericsson y col. [8] optimizan la misma función objetivo, pero con un algoritmo
genético. Se agrega una búsqueda local a un algoritmo genético similar en Buriol et al.
[5] Bley y col. [3] aborde el diseño de red IP que puede sobrevivir para un solo arco o
falla del enrutador. Las capacidades se asignan de manera que se satisfaga un
porcentaje especificado de cada demanda para cualquier enrutador o falla de arco.
Las capacidades se instalan en múltiplos de una unidad de capacidad, y pueden variar
entre un valor mínimo y un valor máximo si se utiliza el arco. El conteo máximo de
saltos se impone en cada ruta. Los arcos, en ese artículo, tienen un solo enlace.
Además, el enrutamiento se realiza en una sola ruta más corta, es decir, no se
implementa la división de carga. Los pesos de los enlaces se ajustan mediante la
búsqueda local para minimizar el costo total de la red, que depende de las
capacidades instaladas. Bley [2] considera un problema similar, pero también tiene en
cuenta las consideraciones de hardware que afectan la viabilidad y el costo de la
solución. Se utiliza un método de solución basado en la relajación lagrangiana.
Holmberg y Yuan [12] utilizan recocido simulado para determinar los pesos de OSPF y
las capacidades de arco para minimizar el costo de la red basado en un modelo de
costo fijo y de costo fijo. Se utiliza el enrutamiento OSPF con división de carga. Los
arcos en este artículo, sin embargo, tienen un solo enlace. BroströmandHolmberg [4]
utiliza un enfoque similar, pero aborda el problema de minimizar el costo de la red al
tiempo que maximiza una medida de la supervivencia de la red. Solo se consideran
fallas de arco. Se da una formulación de programación entera mixta. Al igual que con
los artículos anteriores, los arcos tienen un solo enlace.
En este artículo, presentamos un algoritmo genético para encontrar soluciones de
buena calidad para el problema de diseño de red que se puede sobrevivir para un solo arco
o fallas de un solo enrutador donde el arco
 HIGO. 2. Efecto de variar el parámetro QoS ρ F en costo de red para una red de 74 enrutadores y 278 arcos ( net-3 en la Sección 5) con falla de arco único. Se
realizaron cinco corridas independientes para cada valor de parámetro. La línea conecta los valores promedio de costo de red. Carreras utilizadas ρ n = . 8 ρ f.
Se consideran multiplicidades. Al simular fallas de arco o enrutador, los gráficos de
ruta más corta se actualizan utilizando algoritmos dinámicos de ruta más corta [6], en
lugar de volver a calcular los gráficos de ruta más cortos desde cero. Además, los
pesos de OSPF se calculan y el enrutamiento de OSPF se ve afectado por las
multiplicidades de arco. Se proponen varias extensiones al modelo básico, que
incluyen pesos OSPF idénticos o diferentes en arcos simétricos, multiplicidades
idénticas o diferentes para arcos simétricos, diferentes funciones objetivas, rango de
peso de arco y restricciones de latencia.
Este artículo está organizado de la siguiente manera. En la Sección 2, describimos un
algoritmo evolutivo general para la configuración de peso en el enrutamiento OSPF. Este
algoritmo llama a un procedimiento que, dada una configuración de peso, encamina las
demandas para determinar las multiplicidades de arco y calcula el costo de la red. Este
procedimiento se describe en la Sección 3. En la Sección 4, agregamos la capacidad de
supervivencia al proceso de diseño de la red. Los resultados computacionales en el "mundo
real" y las redes artificiales se presentan en la Sección 5. Las extensiones y las
observaciones finales se dan en la Sección 6.
2. ALGORITMO EVOLUCIONARIO PARA LA CONFIGURACIÓN DEL
PESO EN LA RUTA OSPF
Los algoritmos evolutivos, como los algoritmos genéticos [10, 11],
desarrollan un conjunto de soluciones (la población) a lo largo del tiempo
(generaciones). Las soluciones de cada generación se forman combinando
pares de soluciones (apareamiento) de la generación anterior y
perturbándolas aleatoriamente (mutación). El proceso se repite durante un
número fijo de generaciones, y el algoritmo devuelve la mejor solución en la
última generación como una solución aproximada al óptimo.
Ericsson y col. [8] presentó un algoritmo genético para establecer los pesos de
OSPF en una red IP con capacidades de enlace conocidas. La función objetivo
utilizada fue la propuesta por Fortz y Thorup [9], que penaliza cada vez más las
cargas que se acercan y superan las capacidades de enlace. El mismo problema se
abordó en Buriol et al. [5], donde se aplicó un procedimiento de búsqueda local a la
descendencia resultante después del apareamiento.
Nuestro algoritmo utiliza la misma estructura de algoritmo genético descrita en
[5, 8], pero difiere en cómo se evalúa la solución. Además, considera fallas de arco
único o enrutador. En esta sección, describimos nuestro algoritmo genético
optimizando una función general f (w). En la siguiente sección, mostramos cómo
calculamos esta función. Todavía no consideramos los problemas de
supervivencia y los abordamos más adelante, en la Sección 4.
Cada una de las pags elementos de la población es un vector de peso entero, que
caracteriza una solución. Cada arco una ∈ UNA se ha asociado con un peso entero w una ∈
[ 1, w]. Inicialmente, todas menos una de las soluciones están formadas por pesos
generados aleatoriamente de manera uniforme. La solución restante se compone de
unidades de peso.
El algoritmo se ejecuta para norte generaciones. Utilizamos el esquema cruzado de
teclas aleatorias de Bean [1] para apareamiento y mutación. En cada generación, las
soluciones se evalúan y clasifican en orden creciente de valor de la función objetivo. los norte
UNA las soluciones con los costos más pequeños se ponen en clase UNA, mientras que la norte
C
las soluciones con los mayores costos se colocan en clase C. Las soluciones
restantes se asignan a la clase. SI.
La próxima generación se produce de la siguiente manera. Todas las soluciones en clase. UNA
son promovidos automáticamente, tal cual, a la próxima generación. Todas las soluciones en clase. C
son descartados y reemplazados por
REDES — 2007 — DOI 10.1002 / neto 53
soluciones de peso aleatorio en la próxima generación. El restante norte si Las
soluciones de la próxima generación se generan de la siguiente manera. Para producir
cada descendencia, un padre ( pags 1) se selecciona al azar (con reemplazo) de los
elementos en clase UNA
y uno ( pags 2) desde si ∪ C. los yo- El peso de la descendencia será el yo- th peso de
los padres pags 1 con probabilidad π 1> 1/2, el yo- th peso de los padres pags 2 con
probabilidad π 2 < 1 - π 1,
o un peso aleatorio en el intervalo [1, w] con probabilidad 1 - π 1 - π 2)
Se deben establecer varios parámetros. En la Sección 5, donde se describen los
resultados computacionales, definimos estos valores. Las pautas para establecer estos
parámetros son las siguientes. Cuanto mayor es el tamaño de la población pags, cuanto
más demorará cada generación en computarse. Los experimentos realizados con este
problema han demostrado que el tiempo de CPU es linealmente proporcional al tamaño
de la población y al número de generaciones. También esperamos que la calidad de la
solución mejore al aumentar el número de generaciones norte y / o aumentar el tamaño
de la población pags. Las probabilidades de apareamiento / mutación π 1 y π 2 debe ser tal
que
π 1> π 2 para evitar mutar demasiado la solución y generar una descendencia con poca
información derivada de las soluciones principales, y π 1 + π 2 ≈ 1) norte UNA, norte SI, y norte C
debe ser tal que norte B> norte A> norte C. norte C Por lo general, es pequeño para evitar una
aleatorización excesiva de la población y tomar demasiadas generaciones para
converger. Sin embargo, norte UNA Por lo general, no es grande para evitar la
convergencia de la población demasiado rápido y "quedarse atascado" en un mínimo
local.
3. HEURÍSTICA PARA COMPUTAR LAS MULTIPLICIDADES
DE ARCO
En esta sección, describimos una heurística que calcula las multiplicidades de arco
dada una topología de arcos potenciales, longitudes y capacidades asociadas con cada
arco (todos los enlaces del mismo arco tienen capacidades y longitudes idénticas),
pesos de arco OSPF y una matriz de demanda. Esta heurística no solo devuelve las
multiplicidades de arco, sino que también calcula el costo de la red f (w) que guía el
algoritmo genético de la Sección 2. En esta sección, describimos la heurística para el
caso sin falla. Se describe un pseudocódigo para la heurística. Más adelante, en la
Sección 4, consideramos el procedimiento completo, con fallas únicas. En todos los
pseudocódigos, los parámetros para algunas funciones se omiten para mayor claridad.
Dejar T ser el conjunto de enrutadores de destino. Calculamos | T |
gráficos de ruta más corta de destino único sol t, t ∈ T. Cada sol t,
con destino t ∈ T tiene un | A | - vector L t asociado con los arcos, que almacena las
cargas parciales que fluyen a t y atravesando cada arco una ∈ A. El | A | - vector l almacenaen un conjunto S y las cargas se actualizan en el procedimiento UpdateSolution, descrito a
la carga total que atraviesa cada arco una ∈ A. Para cada destino t ∈ T el | N | - vectores
π t y δ t están asociados con los nodos. La distancia de cada nodo a t se almacena en
π t, mientras δ t mantiene el número de multiplicidades de arco (enlaces) salientes de
cada nodo en sol t.
La primera heurística encamina la demanda utilizando reglas de enrutamiento OSPF y
suponiendo que cada arco tiene multiplicidad de unidades. Se calculan las cargas de arco y
se determinan las multiplicidades requeridas. La demanda se redirige asumiendo que se
determinan las multiplicidades actualizadas y la carga de arco actualizada. Este ciclo
(enrutamiento, cálculo de cargas de arco, determinación de multiplicidades) se repite
54 REDES — 2007 — DOI 10.1002 / neto
procedimiento EvaluateSolution ( w, lf, rf)
1 para todos una ∈ UNA hacer µ a = 1;
2 para todos t ∈ T hacer
3 π t ← ReverseDijkstra ( w);
44 sol t ← ComputeSPG ( w, π t);
55 δ t ← ComputeDelta ( sol t);
66 L t ← ComputePartialLoads ( µ, δ, π, sol t);
77 fin para todos
8 l ← ComputeTotalLoads ( L)
99 S ← UpdateMultiandDelta ();
10 si | S | > 0 0 UpdateSolution ();
11 para todos una ∈ UNA Si l a = 0 0 entonces µ a = 0; 12 F ← ∑
una ∈ UNA µ una ∗ longitud una;
13 regreso( f, µ);
procedimiento final
HIGO. 3. Pseudocódigo para heurística para calcular multiplicidades de arco.
hasta que la demanda pueda encaminarse de manera factible utilizando las multiplicidades
actuales.
La Figura 3 muestra el pseudocódigo para la heurística para calcular
multiplicidades de arco. Para cada arco potencial una ∈ UNA,
la multiplicidad del arco µ una inicialmente se establece en 1 en la línea 1. Para cada
destino de demanda t ∈ T las distancias más cortas del gráfico de ruta se calculan
desde cero, utilizando el algoritmo de Dijkstra [7], en el procedimiento ReverseDijkstra
( línea 3). Dados los pesos w y las distancias de ruta más cortas, el gráfico de ruta
más corta se identifica por procedimiento ComputeSPG en la línea 4. Dado el gráfico
de ruta más corto sol t, δ t se calcula en la línea 5 por ComputeDelta. Las rutas OSPF
con división de carga se calculan en la línea 6 y el vector de cargas parciales L t está
determinado por el procedimiento ComputePartialLoads para cada arco en el gráfico
de ruta más corto sol t. La carga total l en un arco, calculado en la línea 8 por
procedimiento ComputeTotalLoads, es la suma de todas las cargas parciales
enrutadas en ese arco. En la implementación, las cargas totales se calculan
realmente en el procedimiento
ComputePartialLoads.
Luego, en la línea 9, para cada arco una ∈ UNA, la multiplicidad µ una, y
consecuentemente δ una, se actualizan en UpdateMultiandDelta
de acuerdo con la carga total l una en el arco La multiplicidad actualizada de
arco una es el máximo de su multiplicidad actual
µ una y la multiplicidad mínima requerida para enrutar la carga l una
en arco a, l una/( ρ · C una ), dónde ρ es tal que 0 < ρ ≤ 1 y define la parte de la
capacidad que se puede utilizar, es decir,
µ una ← max { µ una, l una/( ρ · C una) }. Los arcos cuyas multiplicidades se actualizaron se colocan
continuación. En la línea 11, los arcos sin carga tienen sus multiplicidades establecidas
en 0 y en la línea 12, el costo de la solución se calcula como la suma de los productos de
multiplicidades de arco y las longitudes de arco correspondientes. Este valor, así como
las multiplicidades de arco, se devuelven en la línea 13.
Pseudocódigo para el procedimiento UpdateSolution se muestra en la Figura 4. Para
cada gráfico de ruta más corta sol t, t ∈ T las cargas se actualizan si al menos uno de los
arcos en S pertenece a sol t. En este caso, las cargas parciales no se vuelven a calcular
desde cero, sino que simplemente se actualizan. En la línea 4 de UpdateSolution, nodos de
cola
 Líneas 9 y 10 del pseudocódigo de la versión sin falla de Evaluar solución en
procedimiento UpdateSolution ()
la Figura 3 se han sustituido por las líneas 9 a 21 en la versión completa de la
1 hacer

2 para todos t ∈ T hacer Figura 5. Además, en la línea 23, si no hay ninguna situación (sin falla o falla
3 H ← {}; única), arco una tiene una carga positiva, entonces la multiplicidad del arco
44 para todos e = ( -tu
→ v) ∈ S ∩ sol t hacer InsertIntoHeapMax ( H tu π t u);
55 mientras Tamano de la pila( H) > 0 0 hacer

66 tu ← FindAndDeleteMax ( H) µ una se establece en 0. En el pseudocódigo, la carga máxima en el arco

77 Si π t u= ∞ entonces ) una sobre la no falla y todas las simulaciones de falla única es ¯ l a.
8 σ←( re ut + ∑ L tuna / δ tu;
una ∈ sol t ∩ EN( u)
En las líneas 9 a 21, las multiplicidades se actualizan considerando los
99 para todos e = (u, v) ∈ FUERA( u) hacer

10 Si mi ∈ sol t entonces λ ← 0;
casos de fallas sin falla, de arco único y fallas de enrutador único,
11 más λ ← µ mi ∗ σ; consecutivamente. En la línea 10, las multiplicidades se actualizan para el
12 Si λ = L t mi entonces
caso sin falla UpdateMultiandDelta.
13 l mi ← l mi - L t e+ λ;
14 L t e ← λ; Aquí, el parámetro QoS ρ norte es usado Un cambio en la multiplicidad puede causar un
15 InsertIntoHeapMax ( H v, π t v); cambio en el enrutamiento que, en consecuencia, puede causar un cambio en las
dieciséis terminara si
cargas de arco. Un cambio en una carga de arco puede conducir a otro cambio en la
17 fin para todos

18 años terminara si multiplicidad del arco. Por esta razón, los pasos en las líneas 10 a 20 se repiten en un
19 terminar mientras
bucle circular hasta que no se detecte ningún cambio adicional en las cargas de arco o
20 fin para todos

21 S ← UpdateMultiandDelta (); multiplicidades en un ciclo completo del bucle por procedimiento

22 hasta | S | = 0;
procedimiento final
NoMás cambios. En la Sección 5, estudiamos la cantidad de veces que ese
procedimiento No más cambios se llama y, en consecuencia, la cantidad de
HIGO. 4. Pseudocódigo para el procedimiento que actualiza la solución.
veces que se ejecuta el bucle en las líneas 9–21.

tu de todos los arcostu
( -v)
→ ∈ S perteneciendo a sol t se insertan en una prioridad
cola indexada por la distancia a t. Nodos tu se eliminan del montón en la línea 6 y se
consideran uno por uno hasta que el montón esté vacío. La prueba en la línea 7 solo
se usa cuando se consideran fallas, y siempre es cierta para el caso sin fallas. En la
línea 8, la carga se divide uniformemente, considerando las multiplicidades de arco.
La carga σ se calcula como la relación entre la suma de la carga que sale del nodo tu y
la carga que pasa a través del nodo tu y δ t
Las fallas de arco único y las fallas de un solo enrutador se simulan mediante el
mismo procedimiento, SimulateFail. Este procedimiento tiene dos parámetros de entrada:
un conjunto F de conjuntos F 1, F 2, . . . , F q de arcos que se eliminan consecutivamente del
gráfico durante la simulación; y la cardinalidad q de F. Para el caso de falla de arco único, SimulateFail
primero toma como entrada un conjunto de conjuntos F una de arcos individuales, donde
cada F una consiste en arco a. El segundo parámetro es metro, la cardinalidad de F. Para
fallas de un solo enrutador, SimulateFail toma como entrada un conjunto F de conjuntos F yo
y

u.
Todos los arcostu
( -v)
→∈ sol t saliente de tu tienen sus nuevas cargas ( λ)
calculado, y si han cambiado, las cargas se actualizan en las líneas 13–14 y
nodo v se inserta en el montón (línea 15).
Después de actualizar las cargas, pueden cambiar algunas multiplicidades. procedimiento EvaluateSolution ( w, lf, rf)
1 para todos una ∈ UNA hacer µ a = 1;
En la línea 21, procedimiento UpdateMultiandDelta
2 para todos t ∈ T hacer
calcula el conjunto de arcos S para el cual las multiplicidades han cambiado y 3 π t ← ReverseDijkstra ( w);
actualiza los vectores µ y δ. Aunque establecido S 44 sol t ← ComputeSPGandLoad ( w, π t);
55 δ t ← ComputeDelta ( sol t);
contiene al menos un arco, el ciclo de la línea 2 a la línea 20 se repite. En la
66 L t ← ComputePartialLoads ( µ, δ, π, sol t);
Sección 5, registramos el número de veces que se repite el ciclo 2–20 y 77 fin para todos

presentamos estadísticas que indican que este número es pequeño. 8 l ← ComputeTotalLoads ( L)

9 9 mientras que 1 hago
10 S ← UpdateMultiandDelta ();
11 si | S | > 0 0 UpdateSolution ();
12 Si NoMoreChanges () luego ve a OUTLOOP;
4. DISEÑO DE RED SOBREVIVIBLE 13 Si lf = 1 hacer
14 simulateFail ( UNA, metro);
En esta sección, agregamos capacidad de supervivencia al proceso de
15 Si NoMoreChanges () luego ve a OUTLOOP;
diseño de la red. Consideramos la falla de un solo arco, un solo enrutador y dieciséis terminara si

un solo arco o un solo enrutador. La diferencia entre el algoritmo genético 17 Si rf = 1 hacer

18 años simulateFail ( R norte);
para el caso sin falla y los casos con falla única es el procedimiento Evaluar
19 Si NoMoreChanges () luego ve a OUTLOOP;
solución. Describimos los cambios a Evaluar solución y presente el 20 terminara si

procedimiento que simula estas fallas. 21 terminar mientras

22 OUTLOOP:
23 para todos una ∈ UNA Si ¯ l a = 0 0 entonces µ a = 0; 24 F ← ∑
A diferencia del procedimiento en la sección anterior, la evaluación de la
una ∈ UNA µ una ∗ longitud una;
solución no solo calcula las multiplicidades para el caso sin falla, sino que 25 regreso( f, µ);
también actualiza las multiplicidades considerando cada falla. Estos cambios procedimiento final

se muestran en el pseudocódigo de la Figura 5.

HIGO. 5. Pseudocódigo para actualizar una solución considerando fallas.

REDES — 2007 — DOI 10.1002 / neto 55

 5. RESULTADOS COMPUTACIONALES
procedimiento SimulateFail ( F = {F 1, F 2, . . . , F q}, q)
Describimos experimentos computacionales con la implementación del algoritmo
1 i = 1; 2 mientras NoMoreChanges () hacer
descrito en este artículo en lenguaje de CA en cuatro problemas de prueba derivados

3 CopySolution (); de redes IP del mundo real. Las dimensiones de las cuatro instancias se resumen en

44 para todos una ∈ F yo hacer

w una
ˆ ← w una; la Tabla 1. Las dos primeras instancias ( net-1 y neto-2) son redes densas en las que

55 para todos una ∈ F yo hacer w una ← ∞; existe demanda entre todos los pares de enrutadores. Cada uno está formado por
66 UpdateSPGandLoad (); nodos que corresponden a enrutadores existentes o planificados de un proveedor de
77 para todos una ∈ F yo hacer w una ← w
ŵ
ˆ una; servicios de Internet (ISP) de nivel 1 grande en una región (de múltiples estados) de
8 S ← UpdateMultiandDelta (); los Estados Unidos. Las otras dos instancias ( net-3 y neto-4) Son mucho más
99 si | S | > 1 entonces grandes. Ambos implican redes dispersas. Ejemplo net-3 corresponde a una red IP
10 para todos t ∈ T hacer UpdateDelta ( δ t, sol t); obsoleta de red troncal de un gran ISP de nivel 1. Solo 18 de los 74 nodos son
11 UpdateSolution (); enrutadores de destino de pares de demanda. Debido a esto, el algoritmo funciona
12 terminara si
con solo 18 gráficos de ruta más cortos por solución. La última instancia ( neto-4) consiste
13 Si i <q entonces yo ← i + 1; 14
en escasas redes IP regionales optimizadas unidas por una red troncal densa.
más yo ← 1; 15 finaliza
Corresponde a la red nacional de un gran ISP de nivel 1. Todos los nodos son
mientras finaliza el
enrutadores de destino de pares de demanda, y casi todos los pares de enrutadores
procedimiento
tienen una demanda asociada con ellos. Para cada instancia en este estudio, todos
los enlaces tienen capacidades idénticas.
HIGO. 6. Pseudocódigo para actualizar las multiplicidades y cargas simulando un conjunto dado de
fallas.

la cardinalidad norte de F. Cada F yo en este caso es el conjunto de todos los arcos entrantes y
La Tabla 2 presenta algunas estadísticas sobre las instancias. Se dan valores
salientes hacia y desde el enrutador yo.
mínimos, promedio y máximos para demanda, longitud y grado de entrada / salida.
Concluimos esta sección con una descripción de la simulación de falla, que
Porque cada enlace está presente en ambas direcciones (para cada arco una → si, las
se describe en el pseudocódigo de la Figura 6. En el bucle en las líneas 2 a 15
redes tienen un arco correspondiente si → una), la entrada y la salida de cada nodo
del pseudocódigo, la falla de cada conjunto F yo ( i = 1,. . . , q) es simulado El ciclo se
son iguales y, por lo tanto, estos valores no se repitieron en la tabla. Los arcos
repite hasta que se completa una pasada en todo el conjunto F sin causar ningún
simétricos tienen la misma capacidad y la misma longitud. Sin embargo, las
cambio en las multiplicidades de arco, y consecuentemente en las cargas de
demandas rara vez son simétricas. Como se puede observar, las demandas varían
arco. Esta condición se prueba en NoMás cambios. Para cada simulación, la
considerablemente de un par a otro. El valor mínimo de demanda es muy pequeño
solución actual se copia a una solución auxiliar en la línea 3. Los pesos actuales
en comparación con los valores máximos. Además, las redes más grandes tienen
de los arcos una ∈ F yo
valores de demanda más altos, ya que se derivan de redes troncales nacionales en
lugar de redes troncales regionales.
se guardan en el vector auxiliar ˆ w ( línea 4) y se establecen en
infinito (línea 5). Procedimiento UpdateSPGandLoad actualiza los gráficos de ruta
más cortos y las cargas totales y parciales de la solución copiada con pesos w usado
La capacidad de cada enlace desde las redes. net-1, net-2,
para simular la falla de los arcos una ∈ F yo. Los pesos se restablecen a sus
y net-3 se establecen en 2,48, mientras que los enlaces de net-4 tener capacidades unitarias.
valores originales en la línea 7 y en la línea 8 las multiplicidades se actualizan
para la solución copiada. El parámetro QoS ρ F se usa en
El programa C fue compilado con el gcc compilador, versión 3.2.3 con indicador
de optimización - O3 y ejecutar en un SGI Altix 3700 Supercluster con RedHat
UpdateMultiandDelta. Si al menos una multiplicidad ha cambiado, entonces para
Advanced Server con SGI ProPack. El clúster está configurado con 32
cada t ∈ T el original δ t, L t, y l t se actualizan en las líneas 10 y 11. El contador yo se
procesadores Itanium-2 de 1.5 GHz (Rev. 5) y 245 Gb de memoria principal. Cada
incrementa en la línea 13 o se restablece a 1 en la línea 14 para forzar al ciclo a
ejecución estaba limitada a un único procesador. Tiempos de ejecución del usuario
recorrer todos los conjuntos F 1, F 2, . . . , F q.

Hay otra forma de simular fallas. En lugar de copiar la solución actual ( l

y sol t, π t, δ t, L t, para cada t ∈ T) TABLA 1. Pruebe las dimensiones problemáticas de la red.

a la solución auxiliar (línea 3), simulamos cada falla modificando primero la

solución original y luego deshaciendo la modificación al final del ciclo. Red El | N | El | A | El | T | El | D |

Implementamos y probamos este enfoque alternativo, pero sorprendentemente,

net-1 10 90 10 90
fue computacionalmente menos eficiente que el que adoptamos. Quizás esto se
net-2 11 110 11 110
deba al hecho de que la copia de un bloque de memoria se realiza de manera
net-3 74 278 18 años 306
muy eficiente por el hardware moderno. net-4 71 350 71 4960

En la Sección 5, estudiamos la cantidad de veces que la falla del conjunto F yo se
simula, discriminando entre simulaciones de falla de arco y falla de enrutador.
Para cada una de las cuatro redes utilizadas en los experimentos computacionales, esta tabla enumera el
número de enrutadores (| N |), el número de arcos potenciales (| A |),
el número de enrutadores de destino distintos que participan en la lista de demandas (| T |), y el número
de pares de demanda (| D |).

56 REDES — 2007 — DOI 10.1002 / neto

 TABLA 2. Valores mínimos (mínimo), promedio (promedio) y máximo (máximo) para demanda, longitud y grados de entrada / salida.

Demanda Longitud Grado de entrada / salida

Ejemplo min promedio max min promedio max min promedio max

net-1 0.0000001631 0,18 1,54 3.70 142,88 335,50 99 9.00 99

net-2 0.0000000040 0,11 1.06 1,36 55,981 126,29 10 10.00 10

net-3 0.0016299999 0,50 6.07 0.00 635,36 2468.89 2 5.15 12
net-4 0.0000008064 0,06 3,36 4.50 507,08 3669.80 2 4.93 13

fueron medidos con el getrusage llamada al sistema Los tiempos de ejecución excluyen la
entrada de problemas.
Como se mencionó en la Sección 2, la calidad de la solución mejora con el tamaño de
la población y el número de generaciones (ver Figs. 7 y 8). Por otro lado, los tiempos de
funcionamiento aumentan a medida que aumenta el tamaño de la población y el número de
generaciones. A lo largo de estos experimentos computacionales, utilizamos una población
de tamaño p = 50, probabilidades de apareamiento / mutación π 1 = 0.7 y π 2 = 0.29 y definir
clases UNA, SI, y C con norte A = 0.25 p, N B = 0.7 pags, y
norte C = 0,05 pags elementos, respectivamente. Los pesos pueden tomar valores en el
intervalo [1, w = 20]. Se probaron rangos más grandes y más cortos, pero el adoptado
parece conducir a una buena optimización de la red. Los rangos cortos tienen
demasiados lazos y los grandes casi no tienen ninguno. Las pruebas experimentales
sugieren que tener vínculos ayuda a encontrar mejores soluciones. Con respecto a
los parámetros de QoS, utilizamos ρ n = 0.8 para enrutamiento sin fallas y ρ f = 0.95 para
los casos donde ocurren fallas. En todos los experimentos, la función objetivo es la
suma de las multiplicidades ponderadas, donde la multiplicidad ponderada de un arco
es la multiplicidad del arco multiplicado por su longitud.
La Figura 9 muestra el costo de la red en función del tiempo de ejecución de
cuatro ejecuciones en la red net-3. El algoritmo se ejecutó para falla sin falla, falla de
arco único, falla de enrutador único y falla de arco único / enrutador único. Cada
carrera se limitó a 10,000 segundos. La figura muestra que el algoritmo produjo
diseños que tienen costos: 104,528.32 para el caso sin falla, 168,801.88 para falla de
arco único, 172,570.86 para falla de enrutador único y 185,709.16 para falla de arco
único / enrutador único. Por lo tanto, para lograr protección contra fallas de un solo
arco y un solo enrutador en net-3 da como resultado aproximadamente un 78% más de
costo de red que cuando no se requiere capacidad de supervivencia. La Figura 10
ilustra el progreso de las mejores soluciones producidas por el algoritmo genético. La
figura traza los errores relativos de cada ejecución en función del tiempo de CPU. Los
errores se calculan en relación con el valor de la mejor solución encontrada durante
cada ejecución, es decir, todos los errores relativos son cero en el momento 10,000
segundos. La figura muestra que para la ejecución sin fallas, el algoritmo produce
soluciones dentro del 10 y 1% de la mejor solución encontrada (104,528.32) en 6.86 y
1921.53 segundos, respectivamente. Para la ejecución de falla de arco único,
soluciones dentro del 10 y 1% de la mejor solución

HIGO. 7. Costo de la red en función del número de algoritmos genéticos de tamaño de población para 50, 100, 200, 500 y 500 generaciones. Experimento
realizado en una red de 74 enrutadores y 278 arcos ( net-3 en la Sección 5) sin enrutador o falla de arco.

REDES — 2007 — DOI 10.1002 / neto 57

 HIGO. 8. Costo de la red en función del número de generaciones de algoritmos genéticos para tamaños de población de 10, 30, 50,

70, 90, 150, 250 y 500 elementos. Experimento realizado en una red de 74 enrutadores y 278 arcos ( net-3 en la Sección 5) sin enrutador o falla de arco.

encontrado (168,801.88) se encuentran en, respectivamente, 374.11 y
3365.66 segundos. En 85.18 y 6925.90 segundos, el algoritmo produce soluciones
dentro del 10 y 1%, respectivamente, de la mejor solución encontrada (172,570.86) para
la ejecución de falla de un solo enrutador. Finalmente, para la ejecución de falla de arco
único / enrutador único,
el algoritmo produce soluciones dentro del 10 y 1% de la mejor solución encontrada
(185,709.16) en 356.78 y 9249.97 segundos, respectivamente.
En el siguiente experimento, el algoritmo genético (GA) se ejecutó en cada uno de
los cuatro problemas de prueba usando cinco diferentes

HIGO. 9. El costo del diseño de la red para el algoritmo genético se ejecuta durante 10,000 segundos net-3 para no falla, falla de un solo enrutador, falla de
un solo arco y falla de un solo arco o un solo enrutador.

58 REDES — 2007 — DOI 10.1002 / neto

 HIGO. 10. Error relativo con respecto a la mejor solución encontrada para el algoritmo genético que se ejecuta durante 10.000 segundos, por ejemplo. net-3 para no
falla, falla de un solo enrutador, falla de un solo arco y falla de un solo arco o un solo enrutador.
semillas generadoras de números aleatorios. Por problemas net-1 y
net-2, el algoritmo se ejecutó durante 200 generaciones, mientras que para los
problemas más grandes net-3 y net-4, el número de generaciones se fijó en 100.
Comparamos el costo promedio de red para pesos calculados por el algoritmo
genético con el costo promedio de red producido usando pesos unitarios y
aleatorios (rand). Para las soluciones aleatorias y de peso unitario, aplicamos la
heurística de configuración de multiplicidad descrita en las Secciones 3 y 4, es
decir, repetidamente, la demanda se enruta siguiendo las reglas OSPF, y se
calculan las cargas y multiplicidades, hasta que haya suficiente capacidad para que
todos La demanda puede ser encaminada de manera factible. Calculamos tantas
soluciones de peso aleatorio como son generadas por el algoritmo genético. por
net-1 y net-2, donde el GA calcula 200 generaciones con una población de
tamaño 50 para cada semilla aleatoria, calculamos 7500 soluciones de
peso aleatorio. por net-3 y
net-4, donde se ejecutan 100 generaciones de GA, examinamos 3750 soluciones de
peso al azar. Para cada una de las cinco corridas independientes, se devuelve la
mejor solución de peso aleatorio. La solución aleatoria promedio informada es el
promedio de estas cinco soluciones. Calculamos los costos de red para las cuatro
combinaciones de falla de arco y enrutador / sin falla. También calculamos un límite
inferior (LB) en el costo de la red de la siguiente manera. Para cada nodo objetivo,
determinamos una longitud de ruta de uso más corta como pesos de arco. Las
demandas se enrutan en las rutas más cortas suponiendo que se calculan las
multiplicidades de unidades y las cargas de arco. Las nuevas multiplicidades se
calculan como en la Sección 3, excepto que sus valores no se redondean a un número
entero, sino que se toman como números reales. El costo del arco es el producto de
su multiplicidad real y su longitud. Un límite inferior en la red
El costo de diseño es la suma de todos los costos de arco. El límite inferior es el costo
máximo de red encontrado repitiendo este procedimiento para cada escenario de falla.
Los resultados se resumen en la Tabla 3, donde para cada caso, se muestran cuatro
conjuntos de costos: sin falla de arco o enrutador, falla de un solo enrutador y sin falla de
arco, falla de un solo arco y sin falla del enrutador, y ambos de arco único y falla del
enrutador único. Los tiempos promedio de CPU para el algoritmo genético (en 1,5-GHz
Itanium-2 segundos) también se enumeran en la tabla. Las Figuras 11 y 12 muestran
gráficas de los datos en la Tabla 3. Recordamos que la solución de peso unitario es una
de las soluciones iniciales generadas por el GA. Por lo tanto, la solución final encontrada
por el GA nunca puede costar más que el diseño utilizando pesos unitarios.
En casi todos los casos, el algoritmo genético produjo diseños donde el
costo de la red aumentó cuando se consideraron fallas adicionales. La única
excepción fue en net-1, donde el costo promedio por falla de arco único y sin
falla del enrutador fue
2773.0, mientras que disminuyó a 2766.8 cuando también se consideraron las fallas de
un solo enrutador. Esto probablemente se deba al hecho de que la demanda que se
origina o termina en los enrutadores fallidos se descarta en el cálculo del costo.
La Tabla 4 enumera las relaciones de los costos promedio de red de soluciones de
algoritmo genético y peso aleatorio y de los costos promedio de red de soluciones de
algoritmo genético y peso unitario. La tabla también enumera las proporciones de
soluciones promedio de algoritmos genéticos y los límites inferiores. La tabla considera
solo ejecuciones sin falla o falla de arco único. Con respecto a las soluciones de peso
aleatorio, las soluciones de GA fueron del 15% hasta casi un factor de tres más
pequeñas. Del mismo modo, con respecto a las soluciones de peso unitario, las
soluciones GA fueron hasta tres veces más pequeñas.
REDES — 2007 — DOI 10.1002 / neto 59
TABLA 3. Costo promedio de la red para soluciones de peso de arco de algoritmo genético, aleatorio y unitario, costo límite inferior y tiempos de ejecución del algoritmo genético (segundos en un procesador
Itanium-2 de 1.5 GHz) para los experimentos sin fallas, y todos combinaciones de fallas.

Fracaso Costo promedio de red Tiempo medio

Red Arco Enrutador Unidad Aleatorio Georgia LB Georgia

net-1 No No 4162,4 3089,6 1597,1 690,7 1,48

No si 6591,5 5231,3 2512,8 690,7 7.75
si No 6443,4 5389,0 2773,0 841,7 34,70
si si 6964,4 5520,6 2766,8 841,7 42.04

net-2 No No 1805,4 1385,9 558,8 209,4 1,76

No si 2770,8 2361,3 1032,2 209,4 9.48
si No 2782,8 2319,6 1041,4 223,6 46,92
si si 2801,1 2419,5 1081,4 223,6 54,77

net-3 No No 183195.2 165115.4 120708.1 51850,2 5.26

No si 264176.4 314559,4 182941.6 83775.6 116,60
si No 257112.1 303168.1 174780.8 80040.0 381.70
si si 260940,4 321332.1 185379,1 84178.2 470,29

net-4 No No 655428.0 660958.5 566632.0 171642.1 26,58

No si 1040761.7 1168607.7 941359.4 224954,4 651,96
si No 876604.1 1065181.9 818249.3 222062.7 2035.37
si si 1076690.4 1254047.5 987499.6 245750.0 3017,41

Los valores se promedian sobre cinco ejecuciones independientes.

Los límites inferiores no parecen ser muy fuertes con la solución GA alcanzando
casi un factor de 5 del límite inferior. Sin embargo, recuerde que estas
ejecuciones se limitaron a solo 100 o 200 generaciones, y utilizaron una
pequeña población de tamaño 50. En contraste, la ejecución de 1000
generaciones con una población de 500 elementos de la Figura 8 produjo una
solución con un costo de 100.880 net-3 sin fallas Esto aumenta la relación rand /
GA de 1.37 a 1.64 y la unidad de relación / GA de 1.52 a 1.82 y disminuye la
relación GA / LB de 2.33 a 1.94.
Concluimos esta sección con un examen empírico del número de veces que los
algoritmos descritos en las Secciones 3 y 4 se ejecutan para cada evaluación de la
solución. Nosotros llamamos bucles de convergencia el conjunto de mientras bucles
que se ejecutan en la configuración de multiplicidad heurística. Para el propósito de
nuestro análisis, llamamos a los bucles de convergencia L 1, L 2, L 3, y L 4)
Lazo L 1 es el mientras bucle en las líneas 9 a 21 del procedimiento Evaluar
solución; lazo L 2 ( L 3) es el bucle en las líneas 2 a 15 del procedimiento SimulateFail arco o del enrutador, bucle L 1 se ejecutará solo una vez por llamada y, en
para falla de arco (enrutador); y L 4 4 es el bucle en las líneas 1 a 22 del
procedimiento
UpdateSolution.
En cada simulación de falla de arco o enrutador, las multiplicidades no cambian. Por lo
tanto, el número de llamadas al bucle L 4 4 siempre es menor que la suma de las
llamadas de los otros tres bucles.
La Tabla 5 presenta el número de veces que los bucles L 1, L 2, L 3,
y L 4 4 son llamados y ejecutados para instancias net-1 y
net-4. Se consideran las cuatro combinaciones de falla de arco y enrutador y
ninguna falla. Estos recuentos se realizaron en los experimentos informados en
la Tabla 3. Para cada combinación de fallas, la tabla enumera los recuentos
para cada combinación posible de bucles. Para cada bucle e instancia, hay tres
columnas. Columna No. llamado es el número promedio de veces que se llamó
al ciclo; No. pasa es el número de veces que se ejecutó el bucle (con una
excepción en el caso del bucle L 1) y max
No. es el número máximo de veces que una llamada ejecutó el bucle. El campo
No. pasa en bucle L 1 es el número de veces que llama a los otros bucles de
convergencia. Por ejemplo, como se muestra en la tabla, en caso de falla del
consecuencia,
max No. es igual a uno.
Debido a que el algoritmo genético se ejecutó durante 200 generaciones en la instancia

La Figura 13 muestra cómo se relacionan los bucles. Lazo L 1 llama a todos los otros más pequeña ( neto-1), el no. llamado entrada para bucle L 1 es más grande de lo que es para

bucles. Llama bucle L 4 4 en las cuatro combinaciones de falla de arco y enrutador y sin la instancia más grande ( neto-4),

falla. Para el caso de falta de arco o falla del enrutador, bucle L 1 y bucle L 4 4 se ejecutan
solo una vez durante la evaluación de la solución. En caso de falla de arco o enrutador,
bucle L 1 se ejecuta hasta que se calcula una ronda sin falla, falla de arco y / o falla del
enrutador sin ningún cambio en la solución. Debido a que las fallas de arco se simulan
antes que las fallas del enrutador, realice un bucle L 1 puede terminar entre simulaciones.
Por lo tanto, el número de llamadas al bucle L 2 siempre es al menos tan grande como el
número de llamadas al bucle L 3)
Lazo L 4 4 se llama desde los otros bucles solo cuando al menos una
multiplicidad ha cambiado. Por ejemplo, en la última ronda de
que se ejecutó por solo 100 generaciones. Debido a que hay 50 individuos
por población, se evalúan tres soluciones aleatorias y 34 soluciones
originadas a partir de un cruce por generación, que, junto con la evaluación
de las soluciones iniciales (en la AG, la población inicial se cuenta como la
primera generación de soluciones), resumir el número total de llamadas al
bucle L 1)
Lazo L 2 se ejecuta más veces que el bucle L 3, porque hay más arcos
que enrutadores en las redes estudiadas.
El número máximo de veces que se ejecuta un bucle da una idea sobre
la convergencia de estos bucles. Por ejemplo,

60 REDES — 2007 — DOI 10.1002 / neto

 HIGO. 11. Costos promedio de red para instancias net-1 y net-2 para pesos aleatorios, pesos unitarios y pesos determinados por GA. También se
muestra un límite inferior en el costo de la red.

por ejemplo net-4, el número máximo de veces de bucle L 2 El número de veces que se ejecutaron los bucles está relacionado con el
se ejecutó para el caso de falla de arco y enrutador. En este caso max No. = tamaño de la instancia y el tipo de experimento realizado. Además, es un indicador
1872.6, lo que significa que la simulación de falla de arco se ejecutó hasta de cuánto tiempo llevó el experimento completo.
5.35 (= 1872.6 / 350) veces para cada arco. Además, para este caso, bucle L 1
se ejecutó hasta 3.33 veces por llamada, bucle L 3 fue llamado hasta 4.75 (=
337.0 / 71) veces por llamada y loop L 4 4 fue llamado a
6. OBSERVACIONES FINALES

5.2 veces por llamada. Tenga en cuenta que los números máximos de llamadas anteriores se En este artículo, describimos un nuevo algoritmo evolutivo para el diseño de
promedian en cinco ejecuciones cada uno y, por lo tanto, pueden valorarse de manera real. red IP sobreviviente con enrutamiento OSPF. El algoritmo funciona con un conjunto
de pags soluciones Cada solución

REDES — 2007 — DOI 10.1002 / neto 61

 HIGO. 12. Costos promedio de red para instancias net-3 y net-4 para pesos aleatorios, pesos unitarios y pesos determinados por GA. También se
muestra un límite inferior en el costo de la red.

se caracteriza por un vector de peso de arco entero. El algoritmo comienza con una
solución de peso unitario y pags - 1 soluciones de peso al azar y evoluciona esta
población a lo largo de norte generaciones, combinando soluciones de acuerdo con una
receta específica. Para asociar un diseño con cada vector de peso, una heurística de
configuración de multiplicidad determina el número de enlaces que debe tener cada arco
para que toda la demanda pueda enrutarse de manera factible en la red utilizando el
enrutamiento OSPF con división de ruta. Para lograr una implementación eficiente, en
lugar de volver a calcular las rutas más cortas y las cargas desde cero, se utilizaron
algoritmos dinámicos de rutas más cortas siempre que fue posible.
Para simplificar la descripción del algoritmo, omitimos del artículo
muchas extensiones que hemos incorporado al algoritmo. La mayoría son
simples de incorporar en un algoritmo genético. Incluyen:
• Además del costo de red descrito en el artículo, también permitimos minimizar el
número de enlaces, así como un modelo de costo de cargo fijo, donde uno paga K
una usar arco una y un adicional k una por enlace de arco una desplegado.
• Además de las fallas de arco y enrutador, el algoritmo también permite lapso fracaso.
Un lapso es un conjunto de arcos que utilizan una estructura de red común y es
probable que fallen simultáneamente.

62 REDES — 2007 — DOI 10.1002 / neto

CUADRO 4. Proporciones de costo de red promedio de soluciones de peso aleatorio y unidad de peso al

algoritmo genético costo de red y relaciones entre los costos de red del algoritmo genético medio y el límite

inferior.

Red Falla de arco unidad / GA rand / GA GA / LB

net-1 No 2,61 1,93 2,31

si 2,32 1,94 3.29

net-2 No 3.23 2,48 2,67

si 2,67 2,23 4.66

net-3 No 1,52 1,37 2,33

si 1,47 1,73 2,18

net-4 No 1.16 1,17 3.30

si 1.07 1,30 3,68

Asumimos que los enrutadores no fallan.

La falla de un solo tramo es una generalización de fallas de un solo arco y un solo

enrutador.
• A menudo se desea imponer una restricción de latencia máxima a demanda. El
algoritmo descrito en el artículo no restringe ninguna demanda de seguir una ruta
larga y sinuosa. Es simple mantener la latencia de cada gráfico de ruta más corta
y, por lo tanto, calcular la latencia de cada par de demanda. Se puede agregar una HIGO. 13. La relación entre bucles en la heurística de configuración de multiplicidad. [La figura del
función de penalización con la suma de latencias en exceso a la función objetivo color se puede ver en la edición en línea, que está disponible en www.interscience.wiley.com].
para desfavorecer soluciones que violen la restricción de latencia.

• Se dice que dos arcos son simétricos si la cola de uno es la cabeza del otro y
viceversa. A menudo se desea imponer que los pesos de OSPF sean iguales en
arcos simétricos. Modificaciones menores de la generación de peso aleatorio y los
procedimientos de apareamiento / mutación pueden lograr esto.
• Del mismo modo, puede ser necesario que las multiplicidades sean las mismas en arcos
simétricos. Una simple modificación de la configuración heurística de multiplicidad permite
este tipo de restricción.
• Las soluciones de la descendencia resultantes del apareamiento de dos soluciones de la
población pueden no ser óptimas localmente con respecto a los vecindarios definidos
por la eliminación de enlaces únicos y el aumento del peso del arco único (como en [5]).
Implementamos tales procedimientos de búsqueda local. Aunque pueden reducir el
costo de diseño de algunos descendientes, creemos que el esfuerzo computacional
adicional no justifica su uso.

• La implementación permite la entrada de pesos OSPF fijos para un subconjunto S ⊆ UNA • Los pesos producidos por la mejor solución se pueden ajustar aún más para
de los arcos. optimizar una medida de congestión de la red. Permitimos que los pesos OSPF
• La implementación permite la entrada de un conjunto inicial de multiplicidades para del conjunto de mejores soluciones en la población final se optimicen con el
todas las soluciones para permitir estudios de expansión de red. algoritmo de ajuste de peso de Buriol et al. [5]

TABLA 5. Número promedio de llamadas, ejecuciones y ejecuciones máximas por llamada de los bucles de convergencia de redes net-1 y net-4.

Fracaso Net-1 Net-4

Arco Enrutador Lazo No. llamado No. pasa max No. No. llamado No. pasa max No.

No No L1 7413,0 7413,0 1.0 3713,0 3713,0 1.0

L44 7410,6 7924,4 3.2 3714,0 9213.0 5.0

No si L1 7413,0 27132.8 5.0 3713,0 14994,2 5.4

L3 12298,2 153786.0 32,0 7427,4 1032683.4 369,2
L44 15748.0 16001.2 3.2 131439.8 137829.2 5.40

si No L1 7413,0 28939.8 5.0 3713,0 15009,6 5.6

L2 14106,2 1605306.8 276,2 7427.8 5259311.4 1877,2
L44 24732,6 25010.8 3.2 431627.4 438850.6 5.2

si si L1 7413,0 37727.0 8.0 3713,0 26311.8 10,0

L2 14528,2 1666501.6 262,8 9410.2 6225702.2 1872,6
L3 8354.0 89004.4 25,8 7471.8 976921.8 337,0
L44 31501,2 32202.6 3.2 492128.8 499017.8 5.2

REDES — 2007 — DOI 10.1002 / neto 63

Expresiones de gratitud
El primer autor reconoce las discusiones con Paulo Morelato França,
que ayudó a mejorar una versión anterior del artículo. Reconocemos los
comentarios constructivos de dos árbitros anónimos. También estamos
agradecidos con Doug Shier por revisar cuidadosamente el manuscrito y
sugerir mejoras.
Referencias
[1] JC Bean, algoritmos genéticos y claves aleatorias para la secuencia-
ing y optimización, ORSA J Comp 6 (1994), 154–160. [2] A. Bley, “Un
enfoque lagrangiano para la red integrada
diseño y enrutamiento en redes IP ", Actas de la Conferencia Internacional
de Optimización de Redes (INOC 2003),
2003, pp. 107-113.
[3] A. Bley, M. Grötschel y R. Wessäly, "Diseño de
redes privadas virtuales de banda: modelo y heurística para B-WiN ", redes de
comunicación robustas: interconexión y capacidad de supervivencia, volumen
53 de la serie DIMACS en Matemática discreta y ciencias de la computación
teórica, N. Dean,
DF Hsu y R. Ravi (Editores), Sociedad Americana de Matemáticas, Nueva
Providencia, RI, 1998, pp. 1-16. [4] P. Broström y K. Holmberg, diseño
multiobjetivo de
redes IP que pueden sobrevivir, Informe técnico LiTH-MAT-R-
64 REDES — 2007 — DOI 10.1002 / neto
2004-03, División de Optimización, Linköping Institute of Technology, 2004.
[5] LS Buriol, MGC Resende, CC Ribeiro y M. Thorup,
Un algoritmo genético híbrido para el problema de ajuste de peso en el
enrutamiento OSPF / IS-IS, Redes 46 (2005), 36–56. [6] LS Buriol, MGC
Resende y M. Thorup, Speeding
arriba algoritmos dinámicos de la ruta más corta, Informe técnico TD5RJ8B,
AT&T Labs Research, 2003. [7] E. Dijkstra, una nota sobre dos problemas en
relación con
gráficos, Numer Math 1 (1959), 269–271. [8] M. Ericsson, MGC Resende, y
PM Pardalos, una genética
algoritmo para el problema de ajuste de peso en el enrutamiento OSPF, J Combin
Optimizat 6 (2002), 299–333. [9] B. Fortz y M. Thorup, Aumento de la capacidad de
Internet utilizando
búsqueda local, Comput Optimizat Appl 29 (2004), 13–48. (Versión breve
preliminar de este documento publicado como "Ingeniería de tráfico de Internet
mediante la optimización de los pesos OSPF", Proc. 19º IEEE Conf. On
Computer Communications (INFOCOM), 2000, pp. 519–528.
[10] DE Goldberg, Algoritmos genéticos en búsqueda, optimización
ción y aprendizaje automático, Addison-Wesley, Reading, MA,
1989.
[11] JH Holland, Adaptación en sistemas naturales y artificiales,
MIT Press, Cambridge, MA, 1975. [12] K. Holmberg y D. Yuan, Optimización
del protocolo de internet
diseño y enrutamiento de redes, Redes 43 (2004), 39–53.