Consideraciones Para el Diseño de una Red de Backbone

> REPLACE THIS LINE WITH YOUR PAPER IDENTIFICATION NUMBER (DOUBLE-CLICK HERE TO EDIT) <
1
Consideraciones Para el Diseño de una Red de
Backbone Multiservicio
Carlos M. Martínez-Cagnazzo, Antel, Uruguay
Abstract—Este trabajo presenta algunas reflexiones que surgen
a la hora de encarar el diseño de una red de backbone
multiservicio para un operador de telecomunicaciones. Se incluye
un breve estado del arte del diseño de redes de este tipo desde el
punto de vista de la academia, continuándose con algunas
consideraciones que surgen de la industria.
I. INTRODUCCIÓN
A. Contexto Actual de la Industria
A industria de las telecomunicaciones en general se
encuentra en la actualidad en un momento de cisma
tecnológico. Los procesos de desregulación, la crisis
económica posterior al fenómeno “Dot Com” y la creciente
competencia de empresas provenientes de otros campos
(notablemente del campo de la Televisión Cable) están
forzando a las operadores incumbentes a abandonar los viejos
modelos de prestación de servicios basados únicamente en el
suministro de conectividad extremo a extremo y con ello a
moverse a modelos basados en brindar servicios de
conectividad mas una diversa batería de servicios de valor
agregado.
Los mismos operadores se encuentran en un momento en el
que deben plantearse cuáles serán la o las tecnologías que
vengan a reemplazar a las redes de backbone tradicional
basadas en tecnología ATM (Asynchronous Transfer Mode)
con las que estas empresas vienen prestando servicios desde
hace algunos años. A su vez estas empresas sufren del
problema de “una red – un servicio”. A medida que se
produzco la evolución de los servicios de telecomunicaciones
de una realidad en la que el único servicio a prestar era el de
voz a una realidad con servicio de voz y múltiples servicios de
transmisión de datos incluyendo el de acceso a Internet; los
operadores fueron construyendo redes o “capas” (overlays) de
infraestructura paralelas para la prestación de diferentes
servicios. Cada una de estas capas se gestiona, opera y
mantiene de una manera diferente así como interactúa de
manera dificultosa con otras capas de infraestructura. Esto
acarrea en duplicaciones de recursos y en costos innecesarios.
A nivel de desarrollo tecnológico nos encontramos con la
aparición de tecnologías como MPLS [4] y tecnologías
derivadas como el MPLS Fast Reroute [9] y enrutamiento
L
Manuscript received July 10, 2006
Carlos M. Martínez-Cagnazzo trabaja en la Administración Nacional de
Telecomunicaciones (Antel) en Montevideo, Uruguay.
basado en restricciones. Estos nuevos protocolos y técnicas
permiten recuperar en el mundo de las redes de datagramas los
principales beneficios asociados a las redes de circuitos
virtuales (ATM y TDM) como ser implementación de calidad
de servicio, control de congestión y brindar SLA (Service
Level Agreements) a los usuarios de las mismas.
Las tecnologías Ethernet han multiplicado su ancho de
banda hasta llegar a contar con módulos de 10 Gbps (gigabits
por segundo) a precios relativamente bajos.
Por otro lado también nos encontramos con el gran
desarrollo que en los últimos años han tenido las tecnologías
de multimedia sobre protocolo IP, principalmente video y
telefonía. La posibilidad de realizar llamadas telefónicas a
través de Internet a precios irrisorios o nulos ejerce una
importante presión sobre una de las fuentes de ingresos
tradicionalmente importante de los incumbentes como es el
tráfico telefónico internacional, así como también (junto con
las tecnologías de red inalámbrica como 802.11 y
posiblemente WiMax) disminuyendo la barrera de entrada
para operadores competitivos de telecomunicaciones.
Sin embargo, como sucede con todo riesgo, también hay
oportunidades asociadas. El uso conjunto de todas estas
tecnologías permite visualizar un futuro en el cual un operador
de telecomunicaciones no tenga que mantener diferentes redes
de acceso y backbone para prestar diferentes servicio tal como
ocurre hoy.
En este futuro ideal, un operador de telecomunicaciones
tendría una única red (basada en IP y MPLS) para soportar
toda su gama de servicios, lo que se traduciría en disminución
de costos (debido a la unificación de redes) y aumento de
ganancias (al aumentar la flexibilidad de dar nuevos servicios).
Este futuro es comúnmente conocido como Convergencia o
Redes Convergentes o Redes Multiservicio.
Dado que obviamente no es posible pensar en una
migración “instantánea” hacia una red convergente cabe
preguntarse cual es el camino mas adecuado a recorrer para
llegar a la red convergente. Para responder esta pregunta
completamente debemos considerar no solamente los aspectos
típicamente técnicos (protocolos, tecnologías) sino también el
estado de la práctica de los fabricantes de equipamiento
(¿están
realmente
las
tecnologías
que
necesito
implementadas?), consideraciones económicas y financieras
(¿se justifica la inversión que tengo que realizar para llegar a
tener una red convergente?) y también consideraciones
organizacionales y de recursos humanos dentro de las propios
> REPLACE THIS LINE WITH YOUR PAPER IDENTIFICATION NUMBER (DOUBLE-CLICK HERE TO EDIT) <
operadores de telecomunicaciones.
B. El diseño desde la Industria y la Academia
Desde el punto de vista de la industria el diseño de redes
tradicionalmente se ha dividido en Redes de Acceso y Redes
de Backbone o de Core.
La capa de acceso provee la conectividad a los equipos
directamente involucrados en la prestación del servicio
(centrales telefónicas, modems ADSL, etc.) a la red. En el
contexto de las redes de conmutación de paquetes los nodos de
acceso proveen también funcionalidades de agregación de
tráfico, sumarización de tablas de enrutamiento y de aplicación
de políticas de calidad de servicio. En el contexto de una red
MPLS además los nodos de acceso se encargarán entre otras
funciones de la clasificación del tráfico en FECs (forwarding
equivalence classes) [4]
El backbone o core de la red deberá entre otras cosas cursar
grandes volúmenes de tráfico entre los puntos de presencia
(POPs) de la red de acceso con un muy elevado grado de
confiabilidad. Desde el punto de vista topológico el backbone
de la red transforma lo que de otro modo debería ser un
mallado completo de N*(N-1) enlaces en una colección de N
enlaces uno entre cada POP y el backbone.
Figura 1: Una red (multiservicio o no) con dos niveles de jerarquía
La división jerárquica entre nivel de acceso y nivel de core
además apoya una división administrativa de la red. La tarea
de operación y mantenimiento de una gran red es muy
demandante para los recursos humanos dedicados a ella y por
ello el contar con una división a este nivel generalmente refleja
la estructura organizacional de la empresa operadora.
Además, las problemáticas con las que los técnicos deben
enfrentarse en el nivel de acceso difieren en gran manera de
los problemas que aparecen en el nivel de backbone. Este
problema se exacerba cuando consideramos que la red es una
red multiservicio, como veremos mas adelante.
Desde el punto de vista de la academia el diseño de redes de
backbone ha sido tratado tradicionalmente como un problema
de optimización de recursos.
2
Dados los requisitos o la carga sobre la red y los recursos
(enlaces, routers) entonces podría calcularse un diseño óptimo
para la red condicionada a ciertas restricciones a satisfacer [1]
[2].
Por lo anteriormente expuesto, el problema del diseño y la
transición hacia redes convergentes es de una complejidad
muy grande. En este trabajo trataremos de atacar un problema
mucho mas restringido que es el de dar algunas pautas para
comenzar a diseñar una red de backbone multiservicio.
En el presente trabajo haremos una breve reseña de los
métodos analíticos que se han propuesto para el diseño de
redes, continuando con una serie de consideraciones que
surgen de la práctica en la industria y terminando con algunas
pautas para sistematizar el trabajo de diseño de un backbone
multiservicio.
II. BREVE ESTADO DEL ARTE
A. Diseño de red visto como un problema de optimización
Una de las visiones tradicionales de la academia sobre el
problema de diseñar una red de backbone consiste en mirar el
problema como un problema de optimización de recursos.
La familia de problemas de optimización agrupa a todos
aquellos en los cuales se trata hallar valores óptimos (máximos
o mínimos) de una cierta función objetivo que define “que es
lo que buscamos”.
Una formulación posible muy simplificada para un
problema de diseño de red en estos términos podría ser la
siguiente: Consideremos la red de la Figura 1, donde además
de la topología conocemos lo que denominaremos Matriz de
Tráfico D = (( dij)), donde dij representa la demanda de tráfico
direccional entre el nodo i y el nodo j en la red. En nuestro
caso, podemos asimilar los nodos i y j a los POPs de la red de
acceso.
Introducimos las siguientes notaciones:
M: número de routers en el backbone. Si suponemos que
estos routers están conectados en mallado completo tenemos
M (M-1) enlaces internos al backbone.
αkij : fracción de la demanda dij que se transporta en el
enlace “k” del backbone, k = 1…M(M-1).
Observar que: dij = ∑(k) αk dij
Wk: capacidad (ancho de banda) del enlace “k” del
backbone.
wk = ∑i∑(i≠j) αkji: tráfico esperado en el enlace “k” del
backbone.
δk : “costo” por unidad de ancho de banda del enlace “k”.
La naturaleza de este costo depende de nuestro objetivo al
diseñar el backbone. Si queremos asegurar determinadas
características de calidad de servicio, el costo puede ser la
métrica según un protocolo de enrutamiento del enlace “k”.
Este costo podría ser efectivamente un costo económico si lo
que queremos es minimizar la inversión en infraestructura.
La función objetivo entonces es:
> REPLACE THIS LINE WITH YOUR PAPER IDENTIFICATION NUMBER (DOUBLE-CLICK HERE TO EDIT) <
·
Figura 2: La red como problema de optimización
F = ∑i ∑(j≠i) ∑kαkδkdij
Esta función mide entonces el costo de transportar las
demandas a través de nuestro hipotético backbone. El
problema entonces se reduce a encontrar los extremos de la
función F sujeto a restricciones que puedan existir
Como ejemplo de restricciones tenemos que el ancho de
banda a transportar en cada enlace del backbone no puede
exceder la capacidad del mismo:
Wk ≥ wk , k = 1…M(M-1)
Existe una extensiva cantidad de trabajos sobre estos
problemas de optimización, entre ellos [1] y [2].
Esta aproximación al problema brinda soluciones analíticas
al problema del diseño de la red, pero sin embargo existen
varios problemas:
· Una formulación completa y detallada para
optimizar una red de tamaño real puede ser muy
compleja.
· Los problemas de optimización que surgen de estos
modelados en general no son resolubles en tiempos
polinomiales (son NP).
· La interconexión interna del backbone puede no
ser de mallado completo. Es posible generalizar el
modelado para contemplar este caso pero el
problema es que muchas veces lo que quisiéramos
optimizar es este mallado interno.
· Es muy difícil conocer correctamente la matriz de
tráfico. Lo que es peor, la matriz de tráfico puede
ser de una variabilidad muy importante tanto
horaria como estacional. Además, las demandas de
tráfico pueden variar de acuerdo a factores
externos a la red muy difíciles de tomar en
consideración como ser la distribución geográfíca
de la región de interés.
3
¿Qué hacer cuando ocurren fallas en la red? Una
falla altera la topología haciendo que el problema
de optimización a resolver sea uno completamente
diferente. La aproximación que suele tomarse es
reservar capacidades importantes ociosas en todos
los enlaces.
B. Problema de la Localización de los Hubs (Hub Location
Problem)
En el punto anterior consideramos que la topología de la red
es un dato del problema. Sin embargo, puede ocurrir que se
desee diseñar también la topología de la red para satisfacer los
requerimientos planteados para la red.
Este problema aún mas general también ha sido estudiado
profundamente. Problemas similares aparecen en dominios de
aplicación muy diferentes al de las redes, como ser problemas
de logística, transporte, líneas aéreas, etc. ([5])
Un “hub” es un tipo de nodo que permite reemplazar una
gran cantidad de enlaces directos entre nodos terminals (POPs
en nuestro caso) por un número limitado de enlaces que pasan
a través del hub.
En nuestro caso, la red de backbone se compondrá de varios
nodos tipo hub interconectados entre sí.
El problema en su formulación mas general involucra
encontrar:
· La localización óptima de los hubs, de acuerdo a las
demandas de tráfico entre sitios.
· Determinar la mejor forma de enlazar los hubs entre
sí.
· Encaminar los flujos de tráfico dentro de este
conjunto de hubs enlazados.
C. Diseño “Valiant Load Balanced”
Los autores de [3] proponen la aplicación de una estrategia
un poco diferente de establecimiento del diseño de una red.
Ellos observan la dificultad de obtener una estimación
adecuada de la matriz de tráfico pero observan que si es muy
sencillo medir el tráfico saliente y entrante de un nodo
individual.
Asumimos en este caso que la red de backbone es una red
con mallado completo. Este mallado no tiene por que ser un
mallado físico sino que puede ser construido mediante alguna
técnica de tunelización, en particular MPLS.
Figura 3: Un backbone VLB (Valiant Load-Balanced)
> REPLACE THIS LINE WITH YOUR PAPER IDENTIFICATION NUMBER (DOUBLE-CLICK HERE TO EDIT) <
El tráfico que ingresa al backbone es balanceado de igual
forma en todos los caminos de dos saltos hacia el destino.
Todo paquete recorre dos saltos, uno primero hacia algún
nodo intermedio y un segundo salto hacia el destino final.
Si la capacidad de cada nodo es r y hay N nodos en la red,
se puede probar ([7]) que la solución óptima al problema es un
mallado completo donde cada enlace individual es de
capacidad 2r/N.
Se puede probar también ([3], [7]) que esta solución es
óptima para cualquier matriz de tráfico válida, donde por
matriz de tráfico válida se entiende a una matriz de tráfico que
no sobreasigna ningún nodo intermedio.
Obsérvese que esta propuesta implica un cambio en la
manera de encaminar los paquetes. Se aplica un criterio de
balanceo estricto del tráfico sin importar lo que pueda decir un
protocolo de enrutamiento. Solamente los nodos intermedios
deberán tomar una decisión de enrutamiento, los nodos de
admisión deberán ciegamente balancear el tráfico entre todos
los caminos posibles.
Esta propuesta también impone una topología sobre la red
de backbone, por lo menos a nivel lógico.
En [3] los autores también demuestran que una red de esta
forma permite dimensionar los enlaces eficientemente para que
la red sobreviva a la falla de un número dado k de fallas de
enlaces.
III. CONSIDERACIONES QUE SURGEN DE LA INDUSTRIA
A. El diseño de una red de backbone visto desde la Industria
Si bien ese ha escrito y se ha estudiado extensivamente el
problema del diseño de una red desde el punto de vista de los
problemas de optimización, rara vez las redes son diseñadas de
esta manera por parte de los operadores de
telecomunicaciones.
En la práctica surgen una serie de dificultades que conspira
contra la aplicación de estos métodos:
· Para el diseño de un backbone multiservicio, es
necesario conocer la matriz de tráfico de todos los
servicios.. La matriz de tráfico generalmente se
conoce bien para los servicios de telefonía pero
rara vez se conoce adecuadamente para los
servicios de datos y de Internet.
· Aún en el caso de conocer D, esta matriz es
extremadamente dinámica en diferentes escalas
temporales. Tiene variaciones horarias y
estacionales y en escalas mas grandes depende de
aspectos aún mas difíciles de modelar como el
impacto de políticas comerciales (¿cuáles son y
como se brindan los nuevos servicios?), el
comportamiento de los usuarios, etc.
· El diseño generalmente está pre-condicionado por
la realidad de la organización, tanto en
disponibilidad de equipamiento, de tendido de
enlaces, de locales para alojar equipos e incluso de
aspectos organizacionales como disponibilidad de
4
recursos humanos.
Por esto es que el diseño de redes a nivel de operadores
tiende a realizarse en función del mejor criterio y de acuerdo a
la experiencia de los técnicos involucrados, aplicando reglas
ad-hoc que han sido aprendidas a lo largo del tiempo. ([3]).
Incluso en este punto aparecen problemas, ya que estos
criterios y estas experiencias son dependientes de la historia de
cada persona. Quienes provienen del mundo de la telefonía
manejan criterios y experiencias diferentes de quienes
provienen del mundo de Internet y de la transmisión de datos;
lo cual conduce a diferentes visiones acerca de cómo debe ser
la nueva red.
B. Convergencia
A este panorama ya complejo se le suma la necesidad de
realizar las promesas que encierra el futuro de la red
convergente.
En este camino sin embargo, el concepto de convergencia
ha sido interpretado de diferentes maneras por diferentes
personas.
“Convergencia” tiene un significado para las áreas
comerciales y para los clientes (convergencia de servicios,
facturación unificada, todos los servicios en un único equipo
terminal) y tiene otro (¿u otros?) significados para quienes
diseñan, operan y mantienen la red de backbone.
En el único punto donde todas las partes parecen estar de
acuerdo es en el hecho de que la red convergente va a ser una
red de datagramas IP/MPLS.
La convergencia de red no garantiza la convergencia a nivel
de servicios. Para lograr también la convergencia de servicios
se necesita contar con sistemas de gestión de red y de gestión
comercial que; interoperando entre sí; permitan aplicar las
decisiones de negocio de manera armónica en la red y
comercialmente.
IV. ALGUNAS IDEAS PARA SISTEMATIZAR EL TRABAJO DE
DISEÑO DE UN BACKBONE MULTISERVICIO
Los comentarios que siguen pretenden ser un primer paso
para sistematizar el trabajo de diseño acordando algunos
principios básicos entre todos los involucrados.
> REPLACE THIS LINE WITH YOUR PAPER IDENTIFICATION NUMBER (DOUBLE-CLICK HERE TO EDIT) <
A. Una definición de “red convergente”
El primer escollo a sortear es acordar una definición de
cuando una red es “convergente” o con capacidad de ser
multiservicio.
Proponemos entonces definir una “red convergente” o “red
multiservicio” como una red en la cual los planos de control y
de gestión de todos sus componentes son uniformes (o al
menos uniformizables).
Es de destacar que esto no implica que la red no pueda tener
divisiones jerárquicas (acceso, backbone) o administrativas
(subred telefonía, subred Internet).
En particular, estas divisiones son necesarias para poder
diseñar, operar y mantener una red multiservicio
adecuadamente.
Por un lado, la problemática de diferentes servicios es muy
diferente llevando a que sea necesaria una cierta
especialización de la operación. Por ejemplo, los servicios de
Internet implican que al menos una parte de la red tendrá
direcciones IP públicas de Internet, lo cual a su vez tiene
implicancias de seguridad que no pueden ignorarse, y que no
deberían afectar de ninguna forma a la parte de la red que se
utilice para dar servicios de video o de telefonía.
Por otro lado, los diferentes servicios pueden tener
requisitos de calidad de servicio muy diferentes unos de otros.
Un servicio de telefonía de calidad equivalente al de la
telefonía tradicional tendrá requisitos de retardo, jitter y
pérdida de paquetes mucho más exigente que los que
seguramente tendrá el servicio de Internet. ¿Es necesario
entonces que toda la red este dimensionada y diseñada para
soportar los requisitos más exigentes de todos? ¿Es
económicamente razonable?
Figura 4: Ejemplos de Interacción convergente y no convergente entre
equipos de red de distinto tipo
B. Identificación de Requerimientos
Un segundo paso consiste en relevar la máxima información
disponible sobre los requerimientos que la red de backbone
tendrá que cumplir.
Proponemos parametrizar estos requerimientos de acuerdo a
los servicios a brindar, construyendo una tabla de
5
TABLA I
EJEMPLO DE RELEVAMIENTO DE REQUERIMIENTOS PARA BACKBONE
MULTISERVICIO
Servicio
Internet de
Banda Ancha
Telefonía de
calidad
“tradicional”
Video
Servicios de
datos
empresariales“le
gacy” (punto a
punto)
Servicios de
datos
empresariales
“nueva
generación”
(metro ethernet)
Req. QoS
Ancho de
banda
Tasa de
pérdida de
paquetes
Retardo
Jitter
…
Tráfico
total
saliente1
450 Mbps
Tráfico total
saliente2
1300 Mbps
…
…
…
…
…
…
…
…
…
…
…
1
Tráfico total saliente de todo el servicio, considerado como una unidad, sin
tener en cuenta la distribución geográfica.
2
Tráfico total entrante de todo el servicio, considerado como una unidad, sin
tener en cuenta la distribución geográfica.
requerimientos como la que se muestra en la Tabla I 1.
Esta tabla es básicamente un relevamiento de servicios
existentes y planeados junto con los requerimientos de cada
uno de ellos.
En una primera aproximación proponemos relevar datos de
número de clientes, requerimientos de calidad de servicio
(ancho de banda por cliente, tasa de pérdida de paquetes,
retardo y jitter) y volumen de tráfico entrante y saliente (por
cliente o total2).
Simples como parece, al tratar de relevar esta información
surgen inmediatamente diferencias de puntos de vista entre los
involucrados y surge la necesidad de uniformizar criterios y
poner en un lenguaje común las necesidades de todas las
partes.
En esta primera etapa dejamos explícitamente afuera la
distribución geográfica, dado que la arquitectura que se elija
debería ser en lo posible independiente de este aspecto.
En una segunda etapa proponemos entonces relevar
información de distribución geográfica de clientes de los
distintos servicios. Con esta información entonces se puede
estimar un número de POPs a instalar.
Finalmente se deberemos estimar las necesidades de
1
Los servicios mostrados en la Tabla I son algunos ejemplos de los
servicios mas comunes que se encontrarán al hacer este relevamiento en el
momento actual.
2
Dependiendo del servicio será mas exacta la estimación de tráfico total o
por cliente.
Con formato: Fuente: 8 pt,
Español (España - alfab.
internacional)
> REPLACE THIS LINE WITH YOUR PAPER IDENTIFICATION NUMBER (DOUBLE-CLICK HERE TO EDIT) <
interconexión entre los distintos servicios. Este es un punto
especialmente delicado y difícil de estimar.
Un ejemplo claro es el servicio de telefonía. Es probable
que una de las necesidades del servicio de telefonía sea
intercambiar minutos de comunicación telefónica con carriers
presentes en Internet. También es posible que se le quiera
brindar servicios de telefonía IP a clientes de datos
empresariales.
Este último dato permitirá delimitar los dominios de los
diferentes niveles de calidad de servicio.
Esta información debe complementarse luego con
información de distribución geográfica sobre la localización de
las mayores agrupaciones de clientes de los diferentes
servicios a los efectos de poder identificar los puntos de
acumulación tráfico.
C. Principios de diseño
Relevada la información lo que queda es definir una
arquitectura para la red de backbone. No parece haber un
procedimiento claro a seguir. Podemos si identificar algunos
principios u objetivos de diseño a satisfacer entre los cuales
identificamos:
· Nivel de mallado en el backbone: si bien es deseable
contar con un mallado completo para el máximo nivel de
tolerancia a fallas y posibilidades de re-enrutamiento,
esto puede no ser feasible dependiendo del costo que
implique y de las posibilidades de la infraestructura
física.
· Jerarquías: Contar con jerarquías de niveles en la red es
extremadamente importante desde distintos puntos de
vista, como agregación de tráfico, agregación de
información de enrutamiento, etc.
¿Cuántos niveles jerárquicos son necesarios? Dependerá
directamente de la escala de la red. En el caso de
Uruguay, podemos considerar que una red con dos
niveles (acceso y backbone) es suficiente.
· Separación de roles administrativos: Las problemáticas
en las diferentes jerarquías de red y en los diferentes
servicios requieren especialización en los operadores así
como también un cierto grado de aislamiento para
hacerlas mas manejables.
· Uso compartido de la red de acceso en todo lo posible:
· QoS para cada servicio: Diferentes servicios requieren
diferentes grados de calidad de servicio. Puede no ser
viable mantener los niveles mas estrictos en toda la red.
· Integración del plano de control y del plano de gestión
en toda la red: Este es el punto crítico que permitirá
cosechar los mayores beneficios del proceso de
convergencia de la red.
· Aplicación de ingeniería de tráfico: Para que la red
alcance los niveles de escalabilidad, confiabilidad y
niveles de calidad de servicio necesarios, será necesario
contar con mecanismos de ingeniería de tráfico que
6
permitan contar con un control mayor sobre los flujos de
información que el que se obtiene simplemente mediante
“next-hop routing” y mayor control sobre la calidad de
servicio del que se obtiene mediante overprovisioning3.
En [8] se presenta una propuesta de utilización de
ingeniería de tráfico como herramienta de planificación y
optimización de la red.
V. CONCLUSIONES
Desde la academia se ha analizado profundamente el
problema del diseño de una red como un problema de
optimización. Sin embargo, los resultados obtenidos son
escasamente utilizados en la práctica.
Desde el punto de vista de la industria, hemos visto como
existe una considerable necesidad por parte de los operadores
de realizar los beneficios prometidos por la convergencia de
redes; pero que también existe una importante complejidad a
resolver previamente.
En este trabajo hemos resumido a grandes rasgos los
procesos que se siguen a la hora de diseñar redes de backbone
y hemos también propuesto algunos grandes lineamientos
acerca de cómo comenzar a analizar el problema.
Finalmente, queremos destacar que trabajos como [8]
proponen un camino para reencontrar la visión desde los
problemas de optimización con la visión industrial.
AGRADECIMIENTOS
Agradecemos a Antel por el apoyo recibido.
REFERENCIAS
[1]
[2]
[3]
[4]
[5]
[6]
[7]
[8]
[9]
SH Chung, YS Myung, DW Tcha, “Optimal Design of a Distributed
Network with a Two-level Hierarchical Structure” - European Journal
of Operational Research, 1992
E Kubilinskas, M Pióro, “An IP/MPLS over WDM Network Design
Problem” - Proc. International Network Optimization Conference.
R Zhang-Shen, N McKeown, “Designing a Predictable Internet
Backbone Network” - HotNets III, 2004
E. Rosen, R. Callon, A. Viswanathan, RFC 3031 “Multiprotocol Label
Switching Architecture” (http://www.ietf.org/rfc/rfc3031.txt)
M. E. O’Kelly, H. J. Miller, “The Hub Network Design Problem, A
Review and Synthesis” – Journal of Transport Geography , 1994 2(1)
31-40.
C. Filsfils, J. Evans, “Engineering a multiservice IP backbone to support
tight SLAs” – Elsevier Computer Networks 40 (2002) 131-148.
I. Keslassy, C-S Chang, N. McKeown, D-S Lee, “Optimal Load
Balancing”, Infocomm 2005, Miami, Florida.
Grampin, E. Serrat, J. , “Cooperation of control and management plane
for provisioning in MPLS networks” - Integrated Network
Management, 2005. IM 2005. 2005 9th IFIP/IEEE International
Symposium on.
P. Pan, G. Swallow, A. Atlas, - RFC 4090, “Fast Reroute Extensions to
RSVP-TE
for
LSP
Tunnels”
–
(ftp://ftp.rfc-editor.org/innotes/rfc4090.txt)
3
Por “overprovisioning” se denomina usualmente a lo que ocurre cuando
un operador de red instala recursos de red (equipos, ancho de banda) en
exceso por sobre la demanda a los efectos de que el retardo de encolamiento
sea despreciable. Es hoy por hoy la técnica mas utilizada para brindar calidad
de servicio en redes de backbone públicas.