Chapter 4 Design
4.5 Stirling components & API
6.2.1.1.1. DESCRIPCIÓN DE LAS
COSIDERACIONES Y MÉTODOS A SER
UTILIZADOS EN LA COMPARACIÓN DE
AQoSM CON IP MULTICAST NATIVO.
Para verificar la performance del método AQoSM definiremos una serie de parámetros que nos permitirán verificar y demostrar la misma:
NMT (Números de Árboles de Distribución MPLS): se considera como la cantidad promedio de árboles MPLS que mantiene el Tree Manager. Da una medida del overhead
que produce el tener que mantener árboles Multicast. Cuanto mayor sea este número, mayor será el procesamiento necesario en los routers de borde, ER, y en el Tree Manager.
NLFE (Número de Entradas de Etiquetas de Forwarding): se considera como la cantidad promedio de entradas de forwarding , correspondientes a etiquetas MPLS, tanto en los routers de borde, ER, como en los router de core, CR. Da una dimensión del
requerimiento de memoria y procesamiento de forwarding en los routers de la red. Cuanto menor sea este indicador, menor será la cantidad de memoria requerida y se tendrá un forwarding más rápido de las etiquetas MPLS.
RRR (Tasa de Rechazo de Pedido de Establecimiento de un grupo Multicast):
) t ( N ) t ( N ) t ( RRR A R = , donde:
: cantidad de pedidos de establecimiento de grupos Multicast, en un período t, después de alcanzado el estado de estabilidad.
) t (
NA
: cantidad de pedidos de establecimiento de grupos Multicast rechazados.
) t (
NR
TSR (Tasa de Establecimiento de Árboles de Distribución):
) t ( N ) t ( N ) t ( N ) t ( N TSR A R M A − − = , donde:
: representa la cantidad de pedidos de establecimiento de grupos Multicast, en un período t, que pueden ser asignados, “matcheados” a árboles de distribución existentes.
) t (
NM
Consideremos la siguiente estructura de red:
Backbone MPLS Tree Manager CR B CR A CR C ER 1 ER 2 ER 3 ER 4 ER 5 ER 6
Figura 6.2.1.1.1.1.- Esquema de Red Propuesto.
La performance de la agregación de árboles de distribución Multicast se ve afectada por la distribución de los miembros de un grupo Multicast dentro de la red.
Para la generación y distribución de los miembros de un grupo Multicast se considerará:
a. Que los miembros de los grupos Multicast y los nodos no están correlacionados (esto refleja la distribución de los miembros de grupos Multicast de muchas aplicaciones reales como Juegos en Internet).
b. Distribución de los miembros dentro de un grupo Multicast.
c. Correlación entre grupos Multicast.
d. Distinto peso a los nodos Multicast según su “participación”.
e. Correlación entre nodos.
Así, a cada nodo de la red se le asigna un peso que representa la probabilidad de que el nodo sea parte de un grupo Multicast.
A partir de las consideraciones anteriores se desarrollará un modelo que nos permitira generar grupos Multicast, teniendo en cuenta el “peso” de los nodos o routers de la red:
Modelo para la Generación de Grupos Multicast.
1. Consideremos dos nodos o routers los cuales denominaremos i y j, donde el peso del nodo i esta dado por w(i)y el del nodo j por w(j).
2. Consideraremos 0〈w(i) y w(j)≤1.
3. N(i): cantidad de grupos que tienen al nodo i como miembro.
4. N(j): cantidad de grupos que tienen al nodo j como miembro.
5. De lo anterior se tiene, que en promedio,
) j ( w ) i ( w ) j ( N ) i ( N = .
6. Consideraremos que la cantidad de nodos en la red es igual a N y que los nodos están numerados de 1 a N.
7. Consideraremos que para cada nodo i, 1≤i≤N, y que 0≤w(i)≤1
8. Luego, tomando en cuenta lo presentado en los puntos 1 a 7, se tiene el siguiente algoritmo que permitirá simular la creación de los grupos Multicat:
for i = 1 to N do
generate a random number between 0 and 1, let it be p if p < w(i) then
add i as a group member
end if
end for
Basados en el modelo descripto anteriormente, y en la arquitectura de red considerada, a los nodos de Backbone o Core, los , les asignaremos un peso de 0. Al resto de los nodos de la red, , les asignaremos un peso de 0,2 o 0,8 , dependiendo del tráfico en tiempo real del
i
CR
i
nodo de core asociado. El fundamento de esta consideración se basa en el hecho que, en un
router, cuanto mayor sea el tráfico que pasa a través de este, mayor sera su participación en el proceso de comunicación de la red, lo cual le da mayor probabilidad de unirse a un grupo Multicast.
Con respecto a los anchos de banda de los enlaces en la red, consideraremos que los enlaces entre los nodos de borde y los nodos de core es infinito, y en los enlaces entre los nodos de core tomaremos anchos de banda comerciales (STM-16).
Para la generación de las sesiones Multicast, consideraremos que estas arriban siguiendo una distribución de Poisson, con tasa de arrivos .
Consideraremos que el tiempo de vida de una sesión cumple con una distribución exponencial con promedio .
En el estado de estabilidad, el número promedio de sesiones estará dado por:
μ λ = .
N
Definamos ahora tres tipos de grupos Multicast:
i. De bajo ancho de banda: 10 kbps. ii. De ancho de banda medio: 100 kbps. iii. De gran ancho de banda: 1 Mbps.
Supongamos que los requerimientos de ancho de banda de los grupos que son generados cumplen con las siguientes consideraciones:
i. 50% de los grupos presentan requerimiento de ancho de banda bajo. ii. 30% de los grupos presentan requerimiento de ancho de banda medio. iii. 20% de los grupos presentan requerimiento de ancho de banda alto.
6.2.1.1.2. COMPARACIÓN DE AQoSM E IP
MULTICAST NATIVO.
A continuación compararemos la preformance obtenida si utilizaramos AQoSM versus la utilización de IP Multicast Nativo sobre MPLS (PIM-SM/CBT MPLS), suponiendo la transmisión de una aplicación de vídeo conferencia. Para esto nos basaremos en los desarrollos y consideraciones realizadas en el punto anterior.
En Multicast Nativo, un árbol de distribución en MPLS es construido utilizando el protocolo PIM-SM/CBT para cada uno de los grupos Multicast.
Para el caso de AQoSM consideraremos que los árboles generados son bi-direccionales.
Para ambos casos, tomaremos que cada miembro de un grupo puede ser fuente o receptor de tráfico Multicast.
Una vez establecida una sesión Multicast, su router de core, o RP, es seleccionado aleatoriamente entre los tres routers de core del esquema de red propuesto.
Para el caso de AQoSM el “mapeo” o asignación de un grupo a un árbol de distribución es realizado utilizando el algoritmo descripto en el punto 6.1, donde el protocolo de ruteo será PIM-SM/CBT, al igual que para el caso de IP Multicast Nativo.
En ambos casos, AQoSM y Multicast Nativo (PIM-SM/CBT), si el árbol de distribución calculado a partir del router de core asignado no cumple con los reuquerimientos del grupo, se seleccionará un nuevo RP entre el resto de los nodos candidatos, hasta que se encuentre un árbol que satisfaga los requerimientos del grupo Multicast, y en caso de no poder encontrarse un árbol que cumpla con los requerimientos del grupo, el grupo será rechazado. De esta manera se logrará un mejor balanceo de carga en la red.
Para el caso de AQoSM consideraremos que el umbral de overhead de ancho debanda, varia entre 0 y 0,3 (con pasos de 0,1). De aquí, gráficando estas condiciones, se tiene: th
0 500 1000 1500 2000 2500 3000 1500 2000 2500 3000 3500
Número Promedio de grupos Activos Concurrentes Nú m er o s d e Ár b o le s M P L S AQoSM: bt=0,3 AQoSM: bt=0,2 AQoSM= bt=0,1 AQoSM: bt=0 IP Multicast Nativo
Figura 6.2.1.1.2.1.- Gráfico Número de Árboles MPLS vs Número Promedio de Grupos Activos Concurrentes.
En el gráfico anterior se muestra la relación entre el Número de Árboles MPLS con el número promedio de Grupos Concurrentes Activos, tanto para el caso de AQoSM e IP Multicast Nativo. Las curvas representan esta relación en función del valor del umbral de overhead de ancho de banda (bth), el cual se hizo variar entre 0 y 0.3, con pasos de 0.1.
Del gráfico se puede concluir que AQoSM escala con el promedio de grupos IP Multicast activos; en cambio, para el caso de IP Multicast Nativo (PIM-SM/CBT), la cantidad de árboles MPLS crece casi linealmente con la cantidad de grupos activos. En AQoSM, cuando la cantidad de grupos activos tiende a aumentar, la catidad de árboles MPLS aumenta, aunque en mucha menor proporción que para el caso de IP Nativo, lo cual implica menor overhead originado por el mantenimiento de los árboles distribucuión.
También se ve en el gráfico anterior que para el caso de AQoSM, cuanto mayor es la cantidad de grupos Multicast activos, mayor cantidad de grupos pueden compartir un árbol MPLS.