El protocolo de fiabilidad y balanceo de tráfico RBP en redes de

El protocolo de fiabilidad y balanceo de tráfico
RBP en redes de acceso VPLS
J. M. Arco, J. A. Carral, A. García, G. Ibañez
Departamento de Automática– Universidad de Alcalá
Edificio Politécnico, Campus Universitario, 28871 Alcalá de Henares, España
{jmarco, jac, antonio, gibanez}@aut.uah.es
Abstract— El servicio LAN de red privada virtual (Virtual
Private LAN Service, VPLS), ofrece conectividad punto a
multipunto, pero las implementaciones actuales no tiene
fiabilidad en la red de acceso. El STP (Spanning Tree Protocol) es
requerido para dar fiabilidad, con el problema del bloqueo de los
enlaces y los retardos de recuperación. En este artículo se
propone un nuevo protocolo el Resilience and Traffic Balance
Protocol RBP, que soluciona estos problemas. El protocolo
mejora una versión anterior propuesta, considerando también los
fallos en los nodos de acceso. RBP balancea el tráfico de manera
rápida y eficiente entre los nodos y enlaces activos. El protocolo
se implementa en los nodos de acceso y en el conmutador
Ethernet del cliente. Se ha realizado una implementación del
protocolo y unas pruebas de validación. Los resultados muestran
que la carga del protocolo en el sistema es baja y unos tiempos de
recuperación en torno a 90 mseg.
Palabras clave -redes de acceso, fiabilidad, balanceo de tráfico,
VPLS.
I. INTRODUCCION
VPLS suministra una conectividad punto a multipunto. VPLS
es independiente del protocolo de capa de red y no necesita
configuración de nivel 3 en las redes del usuario y del
proveedor. VPLS es también adecuado para la computación
GRID y el envío de tráfico multicast seguro.
VPLS A Site 1
IP 10.0.0.0
CE
PE
VPLS
network
VPLS A Site 2
IP 10.0.0.0
PE
CE
el multi acceso, por lo que los CEs deben ejecutar STP [1]
para evitar bucles.
STP no admite balanceo de tráfico al deshabilitar enlaces
para evitar los bucles. Otra limitación de STP es su alto
tiempo de reacción, entorno a 40 seg., lo que implica grandes
pérdidas en enlaces de alta velocidad y tiempos de
recuperación inaceptables, dados los tiempos de recuperación
de Multi-Protocol Label Switching (MPLS) y Fast Reroute
(FRR), de decenas de miliseg. Recientemente el IEEE
estandarizó el Rapid Spanning Tree Protocol (RSTP) [2] que
da un tiempo de recuperación más rápido que el STP, de 1 a 2
seg. [3]. Sin embargo, RSTP tiene bajo ciertas condiciones un
comportamiento de cuenta a infinito, que incrementa el tiempo
de recuperación [4], [5]. RSTP, como cualquier protocolo de
árbol en expansión deshabilita enlaces para evitar los bucles.
El protocolo propuesto RBP soluciona estos problemas,
utilizando todos los enlaces activos y con unos tiempos de
recuperación del orden de miliseg., actuando de manera
transparente al usuario. Este protocolo es un mejora de otro
anterior [6] propuesto el Resilience and Traffic Balance
Protocol (RTBP). La mejora consiste en que RBP considera
también los fallos de los PEs.
El resto del artículo está organizado de la siguiente manera.
La sección 2 muestra cómo tratan el problema del multi enlace
los borradores propuestos. En la sección se expone el
protocolo propuesto. Por último, se muestran unos resultados
de una implementación realizada y terminamos con las
conclusiones.
User network
VPLS B Site 2
IP 10.0.0.0
VPLS B Site 1
IP 10.0.0.0
CE
MPLS
core network
CE
PE
PE
Virtual Connection (VC)
of the VPLS A
VC of the VPLS B
MPLS LSP
Fig. 1. Acceso VPLS multi enlace.
El acceso a red a través de varios enlaces, es un servicio
avanzada de VPLS. Desde el nodo del cliente (Customer
Edge, CE) hay varios enlaces al nodo del proveedor (Provider
Edge, PE), Fig 1. Este servicio da fiabilidad pero puede crear
bucles. Las implementaciones actuales de VPLS no soportan
II. ARQUITECTURAS MULTI ACCESO EN VPLS
Hay dos arquitecturas propuestas para VPLS basadas en
MPLS: Lasserre [7] y Kompella [8]. Ambos a su vez,
proponen arquitecturas planas y jerárquicas, [7], [9].
Finalmente, Kompella propone un modelo donde el PE puede
ser descentralizado [10].
En un escenario multi enlace las tramas de difusión de nivel
2 pueden provocar bucles. El servicio de multi enlace puede
ser ofrecido o no por el proveedor. Si no, el usuario debe
configurárselo. Las implementaciones actuales de los CEs que
usan multi enlace emplean STP. Pero STP sólo usa un enlace
en cada momento.
Las arquitecturas actuales no soportan el servicio de multi
enlace. Los usuarios deben implementarlo utilizando STP para
evitar los bucles, con la consiguiente infrautilización de los
enlaces bloqueados y los altos tiempos de reconfiguración.
III. EL PROTOCOLO RBP
El protocolo RBP ha sido diseñado para tener una rápida
recuperación y aprovechar todos los enlaces en un escenario
multi enlace, balanceando el tráfico entre ellos mediante una
técnica eficiente.
Los nodos PEs que sirven a una sede de un cliente, conocen
a otros PEs que sirven a esta sede, implementando un
protocolo tipo “keep-alive”. El balanceo de carga es llevado a
cabo usando una función hash [11] basada en la dirección
origen (source address, SA) de las tramas.
A. Descripción del protocolo
El protocolo ofrece una rápida recuperación ante fallos y
aprovecha el multi enlace para hacer balanceo de carga entre
todos los enlaces disponibles. El protocolo tiene mecanismos
eficientes para solucionar fallos de enlaces o PEs y redistribuir
el tráfico en consecuencia. También descubre nuevos enlaces
y distribuye tráfico tan pronto como se detectan.
El CE Modificado (MCE) sirve a una sede y monitoriza los
PEs activos a los que se conecta la sede mediante un
mecanismo de keep-alive o HELLO (mecanismo de
descubrimiento). El balanceo de carga se hace con una función
hash [11], basada en la dirección fuente para que el tráfico de
un cliente sea reenviado por el mismo interfaz. El MCE tiene
dos tablas, i) la clásica de direcciones MAC aprendidas por el
puente, usada para las direcciones MAC locales de la sede, ii)
una tabla WAN MAC para grabar las direcciones origen
destino (DA-SA) y su interfaz WAN asociado, usado para
encaminar tramas entre esos dos clientes, uno local y el otro
remoto.
B. Procedimiento de descubrimiento
El MCE difunde tramas de HELLO a través de sus
interfaces WAN cada 30 mseg. El mensaje identifica la sede
(ID) y el cliente VPLS, VPLS ID. Los PEs al recibir este
mensaje deben asentirlo y devolver su identidad y la del
interfaz en uso (por si hubiera más disponibles).
Nuevos enlaces disponibles (PEs) son descubiertos cuando
contesta a las tramas HELLO. Fallos en los enlaces o PEs son
asumidos cada 3 respuestas consecutivas no recibidas. Por
tanto, el tiempo de descubrimiento de un fallo varía entre 60 y
90 mseg.
C. Reenvío de tramas
El MCE ejecuta el protocolo en sus interfaces LAN
comportándose como un puente de aprendizaje. En la
recepción de una trama, aprende la dirección de origen y el
interfaz de entrada, o reinicia el temporizador asociado a la
entrada si ya era conocida. Luego procesa la trama para
enviarla al destino:
• Si la trama es de difusión o multidifisión o con
destino desconocido, se difunde por todos los
interfaces LAN. Luego se selecciona un interfaz
WAN, usando una función hash de la dirección
origen para mandar la trama al resto de sedes de la
VPLS.
• Si la dirección destino estaba en la tabla de MAC
conocidas, destino local de la sede, la trama se
reenvía por el interfaz LAN correspondiente.
• En otro caso, debe haber un par de SA-DA
almacenado en la tabla de WAN MAC y la trama se
manda por el correspondiente interfaz WAN.
Tramas recibidas vía un interfaz WAN se pueden reenviar
sólo a través de un interfaz LAN. Si la dirección destino está
en la tabla LAN se reenvía por el interfaz LAN
correspondiente y la entrada DA-SA es creada o actualizada
en la tabla WAN LAN. En otro caso la trama se difunde a la
sede.
D. Procedimiento de fallo
Después de que un fallo de un PE o enlace es detectado, se
deben distribuir los flujos entre los restantes enlaces WAN.
El MCE debe actualizar su tabla WAN para actualizar la
distribución de flujos y los PEs deben ser informados para que
actualicen los caminos de vuelta a la sede. Todo esto debe
hacerse de manera transparente al usuario.
• El MCE debe calcular un nuevo interfaz WAN para
cada entrada de la tabla WAN afectada por el fallo.
Estos pares SA-DA son reasignados a los interfaces
restantes de manera balanceada.
• El MCE selecciona uno de sus PEs activos y envía la
lista de PEs activos de la sede y el ID del PE con el
fallo. Este PE reenvía esta información a los otros
PEs a través de extensiones BGP para VPLS.
Después todos deben balancear las tablas WAN de la
misma manera que lo hizo el MCE.
E. Procedimiento de recuperación
Como se explicó anteriormente, un PE nuevo o recuperado
es detectado por el MCE. Luego distribuye los flujos entre los
PEs e informa de la existencia del nuevo PE a todas la VPLS.
• El MCE debe calcular de nuevo la tabla WAN. Cada
entrada un nuevo interfaz WAN es seleccionado
aplicando la función hash a la SA de cada par SADA. De esta manera los flujos activos son
distribuidos entre todos los PEs.
• Luego el MCE selecciona uno de sus PEs activos y le
manda la lista de PEs activos de la sede. Este PE
informa al resto de PEs de la VPLS a través de
extensiones de BGP para VPLS. Después todos los
borran sus entradas WAN de su tabla MAC.
La figura 2 ilustra un ejemplo del funcionamiento del
protocolo. El cliente A (sede 1) intenta un ping al cliente C
(sede 2). A manda una trama de difusión (ARP request)
preguntando la dirección MAC de C. (1) MCE procesa la
trama enviada por A y la reenvía vía LAN, porque no sabe de
C, añade una entrada para A en la tabla MAC y por último
selecciona un interfaz WAN (hash(‘A’)=L2) para transmitir la
trama a otras sedes. (2) PE2 envía la trama a PE3, (3) luego a
CE2 y finalmente llega al cliente C. (4) C contesta con una
trama ARP Reply enviada directamente a A que sigue el
mismo camino de vuelta al MCE. (5) MCE añade la entrada
‘A-C vía L2’ y envía la trama a A. La tramas siguientes del
ping de A a C, usan el camino abierto por la trama ARP inicial
(mostrado en la figura como una línea de puntos roja).
PE2
Sede 2
Sede 1
A
4
C
4
4
5
L2
B
2
1
1
CE2
3
3
2
L1
MCE
D
4
PE3
PE1
Fig. 2. Ejemplo de funcionamiento del protocolo.
La figura 3 muestra un ejemplo de fallo del enlace L2 y la
reasignación del tráfico del flujo A-C al enlace L1. Hay un
flujo continuo de tramas de A a C siguiendo el camino
seleccionado en la Fig. 2. Cuando falle el enlace L2 o PE2,
MCE selecciona L1 como interfaz WAN para el para A-C y
actualiza su tabla. Después informa a PE1, el único PE activo,
de que PE2 no está accesible. PE1 reenvía la información a
PE3. Ambos borran cualquier entrada dirigida a PE2 y
aprenden el nuevo camino. El flujo es ahora dirigido a través
de PE1 y PE3.
MAC Port
C
2->3
PE2
MAC Port
A
B
A
MCE
MAC Port
3->1
3->1
4
MAC Port
B
3->1
5
MAC Port
B
A
CE2
L1
D
3
2
PE3
MAC Port
A
B
->A
->B
A
B
->A
->B
Pair
Port
Pair
Port
A-C
B-D
L1
L1
A-C
B-D
L2
L1
1
3
PE1
MAC Port
D
C
1->3
1->3
4
MAC Port
D
C
2->3
MAC Port
3
PE2
MAC Port
A
B
A
MCE
MAC Port
L1
MAC Port
B
3->1
5
MAC Port
B
A
3->1
3->1
C
CE2
D
3
2
PE3
6
MAC Port
A
B
->A
->B
A
B
->A
->B
Pair
Port
Pair
Port
A-C
B-D
L2
L1
A-C
B-D
L1
L1
1
4
0
L2
B
3->2
3->1
3
PE1
MAC Port
1->3
5
MAC Port
D
C
1->3
1->3
Fig. 4. Un ejemplo de la activación del enlace L2 o PE2.
3->1
3->2
C
0
L2
B
MAC Port
D
MAC Port
5
prueba, Fig. 2. Se ha implementado una entidad VPLS en los
nodos PEs de las dos sedes. La Sede 1 es multi enlace. El RBP
está implementado principalmente en el MCE. En los PEs se
ha realizado una pequeña modificación para implementar el
RBP.
Los PEs y el MCE son PCs con Linux Red Hat Fedora Core
2 y la distribución 1.946 MPLS for Linux [12]. Luego en los
PEs hemos modificado la entidad MPLS para implementar
una entidad VPLS simplificada. Por último, hemos
implementado la entidad VPLS. En el MCE hemos
modificado la entidad VPLS y hemos implementado RBP.
Más detalles se pueden encontrar en [13].
Como dijimos en la sección 3, hay algunos mensajes RBP
que el MCE debe mandar a través del núcleo MPLS a través
de BGP. Por simplicidad hemos implementado estos envíos a
través de tramas Ethernet.
1->3
Fig. 3. Ejemplo del fallo del enlace L2 o de PE2.
La figura 4 muestra la recuperación del enlace L2 o de PE2
cuando dos flujos A-C y B-D siguen el camino MCE-PE1PE3. Primero MCE calcula una nueva entrada WAN para cada
flujo. Luego informa a PE1 del nuevo PE (PE2). PE3
cambiará sus entradas para balancear los flujos entre PE1 y
PE2 de la manera que MCE lo hizo.
F. Diferencias con el protocolo RTBP
La principal diferencia entre el RBP y el anterior RTBP [6]
es que trata con los fallos de los PEs. Las tramas falsas no son
usadas y la recuperación y fallos de RBP son más fáciles.
En cuanto a las desventajas, que un CE especial es
necesario y que las tablas MAC son más grandes.
IV. IMPLEMENTACION
El protocolo RBP ha sido implementado en una red de
V. RESULTADOS Y PRUEBAS
Para comprobar el impacto de RBP en el rendimiento de la
red, hemos realizado varias pruebas, en el escenario de la Fig.
2. En la mayoría de los casos no había diferencias
significativas entre usar o no RBP, por lo que los resultados
muestran sólo la diferencia entre IP y la arquitectura VPLS
con RBP. Las pruebas miden tiempos de recuperación,
retardo, velocidad máxima, incremento de carga de la CPU y
jitter.
A. Tiempo de recuperación
Esta prueba mide el tiempo sin recepción, cuando el enlace
se cae. El ensayo se hace con la herramienta mgen [14] para
generar tráfico continuo desde un PC de usuario. El tráfico se
graba en otro PC receptor (Fig. 5). De esta manera podemos
ver cuantos mensajes se pierden desde que se tira el enlace
hasta que el protocolo RBP pasa el tráfico al otro enlace.
Después de perder tres mensajes HELLO consecutivos,
RBP da por caído un enlace. Estos mensajes son enviados
cada 30 mseg. (periodo T), por los que el tiempo mínimo de
recuperación es de 60 mseg. (dos veces T), y el máximo 90
mseg., (tres veces T), y el tiempo medio, 75 mseg. Asumimos
que el tiempo de procesamiento de RBP es despreciable frente
al tiempo de recuperación.
Para comprobar el tiempo de recuperación el mgen es
configurado para enviar 200 mensajes por segundo (T=5
mseg.). Los resultados muestran una pérdida de 30 mensajes,
Fig. 5, es decir que el tiempo de recuperación de esta prueba
es de 79,8 mseg.
Flow>0001 Seq>002319 Src>
10.0.0.9/2000 Dest>
10.0.0.1/3000
TxTime>12:35:01.349621
RxTime>08:40:10.943708 Size>1250
Flow>0001 Seq>002333 Src>
10.0.0.9/2000 Dest>
10.0.0.1/3000
TxTime>12:35:01.429433
RxTime>08:40:11.023549 Size>1250
Fig. 5. Tiempo de recuperación con 200 mensajes por segundo.
B. Retardo
En esta prueba comprobamos un CE contra un MCE con
VPLS con el algoritmo RBP. El tiempo de RTT par un
comando ping varia desde 307 μsec.hasta 398 μseg. El
incremento es producido por el cambio de un hub Ethernet
(retardo despreciable) a un MCE (un PC con un retardo
entorno a 80 μsec).
C. Velocidad máxima
El ensayo se ha realizado generando tráfico con mgen. El
tamaño del mensaje fue 1250 bytes, y la velocidad de emisión
se incrementaba progresivamente para comprobar la velocidad
en recepción. Para RBP la máxima velocidad fue de 88 Mbps,
que corresponde a 94,717 Mbps de velocidad en la línea.
Con sólo IP la máxima velocidad fue 82 Mbps, que
corresponde con 94,177 de velocidad en la línea.
La pérdida de velocidad es menor de 550 kbps (menos del
0,6%).
activaciones.
RBP es sencillo de desplegar, precisa sólo pequeños
cambios software en el nodo de acceso VPLS (PEs) y un
nuevo nodo de acceso del cliente (MCE).
El protocolo ha sido implementado y validado en una red de
laboratorio y no muestra pérdidas significativas de
rendimiento.
El protocolo RBP tiene varias ventajas con relación a STP y
RSTP. Primera, permite el uso simultáneo de todos los enlaces
disponibles a diferencia de STP y RSTP (sólo uno). Segundo,
el tiempo de reacción es muy bajo, inapreciable para el usuario
final, en STP es de varios segundos. Tercero, reduce tráfico en
el núcleo de red, ya que sólo transmite tráfico de señalización
cuando se activa o desactivan enlaces o PEs, en STP de forma
continua. Cuarto, a diferencia del último protocolo propuesto
[6], también funciona con fallos en los PEs.
AGRADECIMIENTOS
Este trabajo ha sido financiado por la Conserjería de
Educación de la Comunidad de Madrid y los fondos FEDER
de la UE en el programa “Aplicaciones Emergentes para
Internet de Nueva Generación, eMagerit“ (S-0505/TIC/0251).
REFERENCIAS
[1]
D. Carga de la CPU
En este experimento medimos el incremento de carga
causado por RBP en relación con el funcionamiento de sólo
IP. Esta medida se ha hecho ejecutando el comando top en el
router mientras el sistema final transmitía a la velocidad
máxima, (88 Mbps con mensajes UDP de 1250 bytes). Hay un
descenso de la carga con IP 12% al 10% con RBP en el PE. En
el MCE la carga sube al 14 %.
[2]
E. Variación del retardo
Cada mensaje mgen lleva grabado el tiempo de emisión, por
lo que es posible calcular el periodo de emisión y el de
recepción, cuya diferencia es el jitter. Para IP el jitter máximo
es de 31 μseg. y la media de 17 μseg. Para RBP, el máximo
jitter es 20 μseg. y la media 6.5 μseg. El jitter IP es mayor
debido a que los datagramas necesita más tiempo de
procesamiento, dando lugar a mayor probabilidad de
interrupción de la CPU por otros procesos. En cualquier caso,
el jitter es despreciable.
[6]
[3]
[4]
[5]
[7]
[8]
[9]
[10]
[11]
VI. CONCLUSIONES
La arquitectura VPLS no soporta multi enlaces en el acceso.
Por tanto, el usuario debe ejecutar STP en los CEs para
soportar multi enlaces. Así sólo un enlace por sede puede ser
usado en cada momento para evitar bucles.
Un nuevo protocolo (RBP) ha sido propuesto para soportar
multi enlaces soportando reparto de carga entre los enlaces
disponibles y una rápida reacción frente a fallos o
[12]
[13]
[14]
IEEE 802 LAN/MAN Standards Committee “Media Access Control
(MAC) bridges” IEEE 802.1D. 1998
IEEE 802 LAN/MAN Standards Committee “Media Access Control
(MAC) bridges” IEEE 802.1D. 2004
Iwata, A. Hidaka, Y. Umayabashi, M. Enomoto, N. Arutaki, A., “Global
open ethernet (GOE) system and its performance evaluation”, IEEE
Journal on Selected Areas in Communications, Volume: 22, Issue: 8 pp.
1432-1442, Oct. 2004.
Andy Myers, Eugene Ng, Hui Zhang, “Rethinking the Service Model:
Scaling Ethernet to a Million Nodes”, ACM SIGCOMM HotNets'04.
K. Elmeleegy, Alan L. Cox, T. S. Eugene Ng, "On Count-to-Infinity
Induced Forwarding Loops in Ethernet Networks", INFOCOM'06,
Barcelona, Spain, April 2006.
V, “RTBP: A protocol for providing resilience and load balance in
VPLS network access”, J. M. Arco, J. A. Carral, A. García, G. Ibañez,
VI Workshop in G/MPLS Networks I.S.B.N .978-84-96742-20-8, pp
121-132, Gerona 2007.
M. Lasserre, V. Kompella “Virtual Private LAN Service (VPLS) Using
Label Distribution Protocol (LDP) Signaling” RFC 4762, January 2007
K. Kompella et al.,” Virtual Private LAN Service (VPLS) Using BGP
for Auto-discovery and Signaling “, RFC 4761, enero 2007.
K. Kompella, ”Layer 2 VPNs Over Tunnels” draft-kompella-l2vpnl2vpn-01.txt, http://tools.ietf.org/wg/l2vpn/, January 2003.
K. Kompella et al., “Decoupled Virtual Private LAN Services” draftkompella-ppvpn-dtls-03.txt, http://www.watersprings.org/pub/id/draftkompella-ppvpn-dtls-03.txt, abril 2004.
J. Sastre “Estudio, desarrollo y evaluación de funciones resumen
utilizadas para la generación de firmas digitales”. J. Sastre’s TFC,
University of Alcalá, 2004.
J.
Leu,
R.
Casellas
“MPLS
for
Linux ”,
http://sourceforge.net/projects/mpls-linux.
E. Escudero, “Implementación de VPLS con protocolo de balanceo de
carga y fiabilidad en Linux”, E. Escudero’s TFC, University of Alcalá,
2006.
B.
Adamson,
"The
Multi-Generator
(MGEN)
Toolset".
http://manimac.itd.nrl.navy.mil/MGEN/