jueves, 4 de febrero de 2010

Introducción al Multicast (Parte II)

Como vimos en el capítulo anterior, unicast no escala cuando se debe enviar la misma información a muchos destinos dado que el ancho de banda requerido se multiplica por la cantidad de receptores de la información.

Por otro lado si usamos broadcast, los receptores no pueden estar atrás de un router dado que estos no los transmiten. Además estamos generando una carga intensiva en los dispositivos de red y desperdiciando ancho de banda.

Ahora bien, necesariamente tengo que aclarar un par de conceptos que son naturalmente elementales y en una magnitud tal que la mayoría de la gente nunca se detiene a pensar. Estoy hablando de la relación entre el direccionamiento de capa 2 y capa 3.

Conocemos perfectamente que a nivel de capa 3 una dirección IPv4 tiene una longitud de 32 bits y una dirección de capa 2 (MAC) del archifamoso protocolo Ethernet tiene 48 bits.

Es evidente que debemos contar con algo que relacione unívocamente cada una de estas direcciones dado que son de distinto tamaño y no es un requerimiento necesario que sean iguales.

En el caso de IPv4 existe un protocolo llamado ARP que se encarga de armar una "tabla de equivalencias" en cada host, que contiene direcciones IP y sus correspondientes MAC asociadas.

¿Por qué me detengo en este detalle?

Los equipos cuando quieren mandar información a otro host conocen la dirección IP de destino (generalmente obtenida por consultas DNS) y al momento de poner la información  en los cables, deben armar los encabezados de la capa de enlace de datos y por ende, deben conocer la dirección MAC de destino.

En multicast IPv4, existe una relación entre las direcciones MAC y las direcciones de grupo (IP's de clase D).

Supongamos el ejemplo de un servidor que envía un streaming a una LAN:


Cuando el servidor quiere usar Unicast y enviar datos a la PC D, arma los paquetes de la siguiente manera:

Capa 3:
IP Origen: 192.168.1.10
IP Destino: 192.168.1.14

Capa 2:
MAC Origen: aaaa.aaaa.aaaa
MAC Destino: 0000.0000.649a

Ahora imaginemos, que si seguimos el mismo ejemplo con Multicast a la dirección de grupo 239.1.1.10 tendríamos:
Capa 3:
IP Origen: 192.168.1.10
IP Destino: 239.1.1.10

Capa 2:
MAC Origen: aaaa.aaaa.aaaa
MAC Destino: ¿?

¿A qué dirección MAC debe enviar las tramas?

Es evidente que no puede ser ninguna MAC de alguno de los equipos, porque sino la información se transformaría en Unicast, dado que el switch replicaría la trama en un único puerto. Esto me lleva a citar una frase que siempre enfatizo con mis alumnos:

Antes de que exista Unicast, Multicast o Broadcast en capa 3, debe existir en capa 2.

Todos los hosts deben acordar una dirección MAC común que puedan utilizar para recibir las tramas dirigidas al grupo de multicast 239.1.1.10. Y no solo eso, sino que tambien el switch debe comprender que esa dirección MAC no se va a guardar como perteneciente a un solo puerto, sino a varios.

Verán ahora que la MAC en cuestión no se negocia, sino que se calcula según lo que veremos a continuación.

La IEEE registró un OUI que es el prefijo de todas las direcciones MAC relacionadas con direcciones IPv4. Dicho prefijo es: 01:00:5e

Verán el bit marcado en rojo, este es el bit menos significativo del byte más significativo de la dirección MAC (el último bit del primer byte en criollo) y determina que la MAC es de multicast. Cuando los switches ven este bit en 1 en cualquier dirección MAC entienden que no deben almacenar esa dirección en la tabla CAM dado que debe ser reenviada a varios puertos.

Ahora bien, sabemos que se calcula una dirección MAC de multicast en base a un OUI fijo y a la dirección de grupo, pero la problemática a la que nos enfrentamos es que una dirección IP tiene 32 bits y solo nos restan 24 de la dirección MAC, por lo que no podremos directamente pegar los bits de la dirección de grupo en la MAC dado que no nos alcanza el espacio. En cambio, podemos realizar el siguiente análisis:

Las direcciones de clase D se utilizan para multicast comprenden el rango desde la 224.0.0.0 a la 239.255.255.255, por lo que podemos ver que cualquier dirección que está dentro de ese rango tiene la forma:

Dado que los bits 1110 pasados a decimal son 128 + 64 + 32 + 0 = 224 y si el cuerto bit estuviese en 0 se sumarían 16 más y el 240 no está incluído en las clases D.
Si entendemos esto, podemos comprender que como estos bits siempre tienen el mismo valor para direcciones multicast de IPv4, podemos desestimarlos y no incluírlos en nuestra futura dirección  MAC de multicast:
Ahora tenemos 28 bits para almacenar y 24 bits disponibles. Ya nos estamos acercando a nuestra meta.

Lo que la gente de la IEEE pensó es en desestimar los bits 4 a 8 del primer byte y el primer bit del segundo byte y transformarlos en un único bit con valor cero.

En criollo:
  1. Tomar los 5 bits que quedan en el primer byte incluyendo el primero del byte 2.
  2. Reemplazarlos por un solo bit en cero.
Ahora si... transladamos los 24 bits a la dirección MAC de multicast.


En un ejemplo práctico:

Dirección IPv4: 224.0.0.5 (OSPF)

Binariamente es: 11100000.00000000.00000000.00000101

Quito la parte en rojo, que es siempre igual para todas las direcciones
____0000.00000000.00000000.00000101
Ahora transformo los próximos 5 bits en un solo cero:
00000000.00000000.00000101
Paso esto a hexadecimal:
00000000.00000000.00000101 = 00.00.05
Luego agrego el OUI de multicast (01:00:5E) como prefijo:
01:00:5E:00:00:05
Esa será la MAC address de multicast que todos los equipos se pondrán para recibir los datos del grupo.

Vamos a otro ejemplo:

Dirección IPv4: 239.140.125.94
En binario: 11101111.10001100.01111101.01011110
Quito los primeros 4 bits y comprimo los próximos 5: 00001100.01111101.01011110
Paso a hexadecimal:  0C:7D:5E
Agrego el OUI: 01:00:5E:0C:7D:5E

¿Fácil, no?

Ahora probemos con la IP: 231.12.125.194
En binario: 11100111.00001100.01111101.01011110
Quito los primeros 4 bits y comprimo los próximos 5: 00001100.01111101.01011110
Paso a hexadecimal:  0C:7D:5E
Agrego el OUI: 01:00:5E:0C:7D:5E <-- ¡¡¡ES LA MISMA QUE CALCULAMOS ANTES!!!

¿Qué pasó?

Cuando nosotros comprimimos los 5 bits en un solo valor en cero, estamos pisando 2^5 bits, por lo que 32 valores de direcciones IP van a corresponder a una única MAC.

Comenten por favor.

Nos vemos en la próxima.

11 comentarios:

Anónimo dijo...

DE DIEZZZZZ!!!!!!!!!!!!!!! LO ENTENDI BARBARO!!!!!
GRACIAS!!!!!!!!!!!!!!! MONICA

Titi dijo...

Ari,

Y que ocurre con esas 32 IPs que corresponden una sola MAC? Significaría que a aquellos host que estén asociados a un grupo multicast en una MAC que corresponda con 32 IPs va a pertenecer a 32 grupos indirectamente?

Abrazo y espero se entienda mi pregunta..jeje

Exitos groso!

Anónimo dijo...

EXCELENTE EXPLICACIÓN.!

Anónimo dijo...

Perfectoo!!!!!!!!!! MAs claro ni el agua

Anónimo dijo...

Gracias Amigo esto me sirve para examen de redes de mañana, saludos desde Honduras

Anónimo dijo...

excelente pero cuales host saben que tienen esa Mac address?

Ariel S. Weher dijo...

El host usa la MAC en cuestión cuando hay algún programa que le indica escuchar a una dirección de grupo en particular.

Unknown dijo...

Muy buena la explicación, pero tengo un sólo comentario.
En el 2° ejemplo, la dirección IP, en el último octeto indica "194", por lo cual la dirección MAC multicast, no es la misma.
A menos que sea un error de digitación, o me equivoco?.
Saludos y gracias por la explicación.
Quedó muy claro!.

Anónimo dijo...

excelente...no encontré un tuto como este en toda la red! Muchas gracias!!

alrogo dijo...

Gracias desde colombia!!!!!

Heyner Castro Cruz dijo...

Definitivamente explicaciones como estas necesitamos muchos :)
Muchas gracias!!!
Dios los bendiga!!

Publicar un comentario