Wiki Transmissió de Dades

3. IP MULTICAST

Forum Pàgina Inicial

3.1. Introducció
3.2. Adreçament
3.3. Notificació i entrega
3.4. Encaminament

{)

3.1. INTRODUCCIÓN

En este tema se abordará el direccionamiento que permite la entrega multi-punto eficiente de datagramas. La complejidad de sus esquemas y de sus protocolos para la propagación de la información de encaminamiento.

RESUMEN DE BROADCAST

En bradcasting una copia de cada paquete llega a cada estación, que aceptará el paquete si va destinado a ella (IP de destino la de la estación) o si va destinado a la direccion de broadcast (IP de destino la de broadcast).

Ésta última dirección, la dirección de broadcast, es una dirección especial utilizada para enviar un paquete en broadcast.

  • Broadcast en Ethernet

    ff:ff:ff:ff:ff:ff


En el caso de Ethernet se hace enviando un único paquete para todas las estaciones, en otro tipo de redes es necesario enviar un paquete por cada estación.

Principales problemas del broadcast :

  • Uso excesivo del ancho de banda de la red.

  • Consumo de recursos de las estaciones, debido al procesamiento al que tienen que someter a los paquetes.

Tener una internet utilizando broadcast no es una buena solución. Sería mejor utilizar unicast junto con un mecanismo de resolución de direcciones como ARP.

MULTICAST

Pdríamos definir multicast como un método de difusión de información que hacia múltiples estaciones de la red, por lo tanto, por múltiples usuarios.

Cada estación puede "vincularse" a un grupo, y cada grupo estará asociado a una dirección multicast. Cuando se envía un paquete a una dirección multicast, todos los miembros del grupo, y sólo ellos, reciben el paquete.

  • unicast

    Sólo recibe el paquete una estación

    multicast

    Reciben el paquete un subconjunto de estación preestablecido

    broadcast

    Reciben el paquete todas las estaciones

Podrían entenderse tanto el unicast como el broadcast como casos particulares del multicast:

  • unicast :

    multicast con una única estación en el grupo

    broadcas :

    multicast con todas las estaciones en el grupo

Pero en realidad los tres son necesarios ya que el multicast tiene un problema de ineficiencia en el encaminamiento.

MULTICAST EN ETHERNET

En Ethernet la mitad de las direcciones están reservadas para el multicast. El bit mas bajo del byte más alto indica si una dirección es multicast o no :

  • 01.00.00.00.00.00

Al inicializar una NIC Ethernet puede indicarse que acepte multicast:

  • # ip link show

    eth0:<BRCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast link/ether 00:01:02:03:04:05 brd ff:ff:ff:ff:ff:ff

MULTICAST EN INTERNET

Multicast IP es una ampliación en internet del concepto de multicast para hardware. Permite la comunicación entre un subconjunto de estaciones distribuídas por internet, sobre cualquier tipo de red física.

CARACTERÍSTICAS generales de Multicast con IP :

  • Dirección de grupo :

    • Cada grupo multicast tiene una dirección única dentro del rango de direcciones D. Hay que recordar que en este rango de direcciones existen direcciones reservadas.

  • Pertenencia dinámica al grupo :

    • Un host puede suscribirse o darse de baja de un grupo en cualquier momento, y puede ser miembro de múltiples grupos.

  • Uso del hardware :

    • IP utilizará multicast si la red física que tiene por debajo lo soporta, si no es así utilizará unicast o broadcast.

  • Re-encaminamineto :

    • Se necesitan "routers especiales" para hacer el encaminamiento del multicast IP, ya que los miembros del grupo pueden estar en diferentes redes.

  • Entrega :

    • La política de entrega utilizada es la del "mejor intento", como IP. Los datagramas enviados a una dirección multicast pueden perderse, duplicarse, llegar fuera de orden o retrasarse.

  • Número de grupos :

    • En teoría se podrán direccionar 228 grupos multicast simultáneamente.

  • Miembros :

    • No es una condición necesaria pertencer a un grupo multicast para poder enviar un datagrama a dicho grupo multicast. Únicamente es necesario pertenecer a un grupo multicast para recibir los datagramas detinados a dicho grupo.

Para poder hacer multicasting en internet son necesarias tres piezas fundamentales :

  • Un esquema de direccionamiento multicast.

  • Un mecanismo de notificación y entrega.

  • Un servicio eficiente de encaminamiento para redes interconectadas.

Existen muchos problemas asiciados uqe habrá que resolver :

  • Como escoger las direcciones (localmente pero de uso global).

  • Como utilizar el multicast HW pero entre redes diferentes.

  • Como hacer llegar los datagramas por las rutas mas cortas.

Fuentes y más información:

  • http://en.wikipedia.org/wiki/Multicast
    Apuntes de clase

Índex

3.2. ADREÇAMENT

(DavidSánchez)[30/11 - 01/12]

  • Multicast eliminen el overhead que genera el broadcast - "un datagrama IP se difunde por broadcast a una subred, cada host de la misma lo recibirá, y tendrá que procesarlo para determinar si el destinatario está activo" - al utilitzar grups (0 o més hosts que estàm a l'espera de la informació que passi el router multicast) de direccions IP.


  • El rang reservat per a aquestes adreces rep el nom de Rang D. Va de la 224.0.0.0 fins a la 239.255.255.255, ja que són les adrecea que comencen amb un patró (en binari) 1110 dins de la ristra de 32 bits que formen la direcció IP, per tan queden 28 bits per a l'identificador del grup. Això significa que hi han espai per direccionar a 228 grups. Hi han dos tipus de adreces d'aquests rang. Un tipus són les adreces assignades permanentment (Well-Known) (a través de IANA) utilitzades per a serveis i manteniment d'infraestructures. Dintre d'aquest grup hi han unes cuantes d'especials, inclosos en el STD-2 (Nombres assignats d'Internet) i utilitzats generalment per a protocols de control:

    1. 224.0.0.0 ==> Adreça base (no s’utilitza).

    2. 224.0.0.1 ==> Tots els hosts de la subxarxa que participen en IP Multicast.

    3. 224.0.0.2 ==> Tots els routers de la subxarxa que participen en IP Multicast.

    4. 224.0.0.3-255 ==> Reservades. Per exemple 224.0.0.4 per a tots els routers DVMRP 224.0.0.5 per a tots els OSPF, 224.0.0.6 Routers OSPF designats i 224.0.0.13 per a tots els PIM.

    De forma similar el conjunt 239.0.0.0 fins a 239.255.255.255 esta reservat per a tasques administratives [administrative scoping, n. del t.]. I l'altre tipus són les adreces de grups multicast temporals que identifiquen als grups multicast que es creen quan es necessiten. Un cop el número de membres d'un grup arriba a zero aquestes adreces es descarten.
    També hi han altres rangs d'adreces, són els següents:

  • Rang A: Es aquell rang on el primer bit dels 32, el de més a l'esquerra, és 0. Per tant el rang pot anar de 0.0.0.0 fins a 127.255.255.255.


  • Rang B: Es aquell rang on el primer bit dels 32, el de més a l'esquerra, és 1 i el segon un 0. Per tant el rang pot anar de 128.0.0.0 fins a 191.255.255.255.


  • Rang C: Es aquell rang on el primer bit dels 32, el de més a l'esquerra ,és 1, el segon també i el tercer un 0. Per tant el rang pot anar de 192.0.0.0 fins a 223.255.255.255.


  • Rang Reservat: Es aquell rang on el primer bit dels 32, el de més a l'esquerra, és 1, tan el segon com el tercer i el quart també són 1 el cinquè és 0. Per tant el rang pot anar de 240.0.0.0 fins a 247.255.255.255.


  • Les diferencies del tractament de IP a les adreces Multicast en relació a les adreces Unicast són:

    1. Les adreces Multicast solament són utilitzades en el camp de destinació.
    2. Per a datagrames Multicast no es poden generar missatges ICMP d’error.

    A la pràctica hem de considerar que no tindrem resposta amb un ping a un grup multicast ni el traceroute funcionarà, encara que el TTL, a la pasada per router es decrementarà i el datagrama serà descartat quan aquest arribi a 0, es a dir quan el TTL arribi a 0.


Mapping entre adreces multicast IP i Ethernet

  • L'estandard RFC 2236, que és l'estandar d'IP Multicast no dona cobertura a totes les xarxes, es a dir a tots tipus de xarxes, per exemple les xarxes multicast ehternet, peró explica com fer el mapping a aquestes adreces.
    Com bé diu en els apunts de teoria "l’adreça ethernet multicast corresponent a una adreça IP multicast són els primers 25 bits de 01:00:5E:00:00:00 concatenats amb els darrers 23 de l’adreça IP" . Per exemple l'adreça ethernet multicast 01:00:5E:00:00:00 es correspon amb la 224.0.0.0, que recordem que es una adreça de rang reservat que no s'utilitza.
    Aquesta relació anteriorment esmentada no és única, ja que al tenir 28 bits associats a l'adreça IP Multicast hi han grups que tenen la mateixa adreça ethernet multicast. Això succeeix per eficiencia, ja que la probabilitat de col.lisió es baixa. L'únic requeriment és que IP sempre ha de comprovar les adreces.


Fonts:
Apunts de classe
http://www.wikipedia.org
http://ditec.um.es/laso/docs/tut-tcpip/3376c22.html
http://www.rfc-es.org/rfc/rfc1234-es.txt
http://jungla.dit.upm.es/~jmseyas/linux/mcast.como/Multicast-Como-2.html

Índex

3.3. NOTIFICACIÓ I ENTREGA

(DavidSánchez)[03/12]

  • Tan en una xarxa local com en una de internet es pot utilitzar Multicast IP.
    Pel que fa referencia e les xarxes locals i l'ús de Multicast IP només cal enviar el datagrama directament fent ús de la adreça Multicast HW. Per a una internet cldrà tenir routers multicast que seran els encarregats de encaminar els datagrames cap a unes altres xarxes. La forma de treballar d'aquests routers es basa en escoltar totes les trasmisions multicasr IP. Quan reben un datagrama amb destinació a una adreça multicast els routers els re-encamien a una altra xarxa si és necessari.
    La diferencia més important (principal) entre multicast local i no local recau en el routers multicast i no pas en els hosts, els quals no han de tenir entrades especials a la taula d'encaminaments ja que s'ultitza directament l'adreça Multicast HW.

Abast (Scope) de multicast

  • Aquest terme és el rang que formen els membres d'un grup multicast o la cantitat de xarxes per on es pot propagar un datagrama multicast.
    Hi han dos maneres de controlar l'scope. La primera seria limitant els TTL's dels datagrames. Bàsicament es basa en posar un valor petit en el camp del TTL, així s'aconsegueix limitar la distancia a la que els datagrames multicast seran encaminats.
    La segona tècnica seria la de Assignar grups reservats d’ús exclusiu local o en una organització. Es basa en reservar grups d'adreces per a ús dins de de la mateixa xarxa o organització. Aquesta tècnica és de control i té un caràcter administratiu, com bé hem esmentat amb anterioritat en l'apartat d'adreçament:

239.192.0.0 - 239.251.255.255 ==> Organitzacions.
239.252.0.0 - 239.255.255.255 ==> Sites.
Fonts:
Apunts de classe
http://ditec.um.es/laso/docs/tut-tcpip/3376c22.html
http://jungla.dit.upm.es/~jmseyas/linux/mcast.como/Multicast-Como-2.html
Índex

IGMP

() [03/12]

Internet Group Management Protocol, protocolo de gestión de grupos de internet.
Es el protocolo utilizado en TCP/IP para el control y administración de los grupos y miembros multicast. Actualmente hay tres versiones estandarizadas siendo retrocompatibles entre si, IGMPv1 (1987), IGMPv2 (1997) y IGMPv3 (2002). Al igual que ICMP, IGMP está integrado con IP, ya que aunque IGMP se sirve de IP para enviar los mensajes, IP utiliza IGMP para el control de los grupos multicast. Su presencia es obligada en todos los sistemas que implementen un nivel 2 de multicast, es decir, que deseen tanto recibir como enviar mensajes.
El control de grupos se realiza en dos fases:

  1. El host interesado en unirse a un grupo envía un mensaje al grupo, los routers lo recogen, actualizan las tablas de rutas y reenvían la petición a otros routers.

  2. Se realizan comprobaciones periódicas ( polling ) comprobando si los hosts continuan perteneciendo a los grupos. Si no reciben respuesta se les da de baja y no se envían mensajes sobre estos hosts al resto de routers. Los grupos no son dados de baja hasta que no se queden sin miembros

Minimización del tráfico Para minimizar el tráfico de control IGMP contempla ciertas acciones:

  1. Para enviar información entre los routers se utiliza multicast, de esta forma todo aquel que no lo soporte no recibe esa información.

  2. En el proceso de polling solo se envía un mensaje por grupo cada 125 segundos.

  3. Solo uno de los routers de cada red realiza el pooling.

  4. Todos los hosts del grupo no responden en el mismo momento, sino que es escoge un valor aleatorio entre 0 y el timeout especificado en el mensaje de pooling.

  5. Cada host comprueban los mensajes de los otros miembros y cancelan su respuesta al router si otro miembro en la misma red ya ha contestado.

Mantenimiento de las tablas de pertinencia a grupos
Cada host ha de controlar que aplicaciones han pedido pertenecer a un grupo, esto es básico ya que entre otra cosas, determina que paquetes se enviarán a la capa superior. Se mantiene una tabla por cada grupo del que se es miembro.

  • Cuando una aplicación se añade a un grupo se introduce una nueva entrada en la tabla.
  • Se incrementa el contador de referencias cuando se introduce una aplicación, y se decrementa cuando se finaliza una aplicación o esta se da de baja del grupo en cuestión.
  • Cuando el contador llega a 0 se elimina la tabla.

Se envían mensajes a los routers multicast de alta o baja de los grupos cada vez que un contador llega a 0 o cuando se inicializa a 1, es decir, cada vez que se elimina o se crea una tabla.
Los mensajes se envían a la dirección de todos los routers multicast, 224.0.0.2

Estados de los hosts ( IGMPv2 )


En el estado No miembro se escoge un valor aleatorio entre 0 y el timeout, este valor limitará el tiempo máximo en que se mantendrá este estado. Como se puede ver en la figura, de este estado pasará a ser miembro activo según dos circunstancias, o bien porque otro miembro del grupo envíe un report al router, o bien cuando expire el tiempo máximo escogido con lo que se enviará al router un report. Para conservar compatibilidad con IGMPv1 es necesario otro estado mas y unas transiciones extra.

Escoger el router que realizará el polling se utiliza un mecanismo muy sencillo,
  • Al iniciarse los routers envian mensajes de polling.

  • Si se detecta una solicitud de un router con una dirección IP inferior no se envían mas mensajes y con ello se delega la responsabilidad en el otro router.

Una vez recibido el mensaje de baja un hosts para un grupo, los routers envían una query al grupo, si pasado un timeout ningún host contesta se elimina al grupo completo.

Formato de la trama IGMP v2

7

15

32

Tipo

Timeout

Checksum

Dirección de grupo


  1. Tipo

    • 0x11 Petición de grupo ( polling )

    • 0x12 Compatibilidad IGMPv1
    • 0x16 Reporte miembro
    • 0x17 Dejar grupo


  1. Timeout

    • Tiempo máximo que se dispone para enviar respuesta. Cota máxima para escoger el número aleatorio. Esta expresado en decimas de segundo

  2. Dirección de grupo

    • Se especifica una dirección o 0 si se hace referencia a todos los grupos.


Asignación de dirección de los grupos
A priori no se puede saber la dirección IP de un grupo determinado, por ello hay distintos métodos para que las aplicaciones las obtengan:

  1. Direcciones asignadas permenentemente, existe el problema del número limitado, y que pueden estar utilizadas en un momento determinado por otra aplicación.
  2. Configurables durante la instalación o las opciones de la aplicación.

  3. Obtenibles en run-time, por ejemplo accediendo a un servidor externo.


Fuentes
http://tools.ietf.org/html/rfc2236
http://en.wikipedia.org/wiki/IGMP
http://www.networksorcery.com/enp/protocol/igmp.htm
http://www.fdi.ucm.es/profesor/jseptien/WEB/Docencia/AVRED/avred_1.htm
Apuntes de la asignatura

Índex

3.4. ENCAMINAMENT

() [03/12]

Hemos explicado un método para realizar la notificación y el envío dentro de una misma red de mensajes multicast, pero la mayor problemática surge cuando intentamos extender el sistema para aplicarlo en distintas redes simultáneamente.
Debido a esta dificultad no se ha llegado a un consenso sobre el protocolo a usar.
Utilizaremos la siguiente figura para detallar algunas de las problemáticas:

()

Core Based Trees (CBT)

[FALTA PARTE DE (DanielMartín)]

CBT permite compartir los árboles de retransmisión para todos los orígenes utilizando una combinación de algoritmos dinámicos y estáticos para poder formar el árbol de retransición multicast.

Para conseguir la escalabilidad lo que se hace es dividir la Internet en regiones, escogidas por el administrador, en donde a cada una de estas regiones se le asignará un router core y unos routers multicast. Este router core sirve para que todos los routers de esa misma región en la que se encuentra, compartan un árbol de retransmisión. Los routers locales envían peticiones al core y el resto de routers se van configurando.

Protocolo Independiente Multicast PIM

Consiste en dos protocolos independientes y complementarios entre ellos. Estos dos protocolos son PIM-DM y PIM-SM

PIM-DM (PIM Dense Mode):

Se usa en entornos LAN, es decir, en redes rápidas con gran ancho de banda. En este tipo de redes casi todos las redes tienen equipos de todos los grupos.

Este protocolo optimiza la garantía de entrega antes que reducir el overhead. El protocolo aquí descrito utiliza broadcast and prune similar al caso de DVMRP. La principal diferencia de PIM-DM frente a este último radica en que PIM-DM no intercambia información de enrutamiento con el resto de routers, ya que asume que el router ya tiene algún mecanismo para esto (RIP/OSPF).

PIM-SM (PIM Sparse Mode):

Se usa en entornos WAN, es decir, en redes en dónde los grupos multicast ocupan pocas redes. Podríamos decir que es una "extensión" de los conceptos que se refieren a CBT bajo demanda, en donde se utiliza el router central como raíz del árbol de retransmisión. La principal diferencia de PIM-SM frente a CBT es que en el primero cada router tiene un conjunto de routers raíz, de modo que si uno de ellos falla, el árbol se pueda construir a partir del siguiente router raíz.

Extensiones multicast para OSPF (MOSPF)

Aquí la idea es usar la topología de la Internet local que tenemos en OSPF para calcular el árbol de retransmisión de multicast. Cabe destacar que este tipo de protocolo también sigue el paradigma de conducción bajo demanda. El principal problema de este protocolo es la relación entre el tráfico de datos y el de enrutamiento, ya que se envía mucha información de enrutamiento frente a poca de datos.

El ámbito en el que trabaja el MOSPF se denomina Área. Si un datagrama quiere ir fuera de ese área, se necesitan routers especiales que actuarán como proxies reenviando todo el tráfico multicast a la otra región.

Fiabilidad en Multicast

Para según que tipo de aplicaciones nos puede resultar muy interesante disponer de un sistema de entregas multicast fiable, esto es sin perdidas, ni duplicados, ni corrupción, ni cambio de orden... Es por ello que hablamos de un esquema más eficiente que el broadcast que asegure que los datos llegan intactos.

Los aspectos que hay que tener en cuenta para todo esto los podemos describir a continuación:

  • -Si un grupo de multicast tiene más de un emisor, no tiene sentido tener que asegurar que los datos lleguen en orden.

    -Evitar duplicados es muy difícil.

    -En aplicaciones de audio y video, hay que tener en cuenta los retrasos y el jitter'.

    -Si queremos tener fiabilidad, tendremos que usar un sistema de ACKs, con la consiguiente explosión de confirmaciones.

Para poder solucionar algunas de estas premisas, los esquemas de mulitcast fiable obligan a que solo pueda haber un emisor por grupo. Este único emisor puede actuar como un proxy. Así pues se establecen varios puntos de confirmación que guardan en un buffer los datagramas enviados para poder reenviarlos en caso de perdida. En lugar de un mecanismo con ACKs se utiliza uno con NACKs (Negative ACK), en donde solo se responde con confirmación cuando se detecta que se a perdido un datagrama.

A cada datagrama se le asigna un número de secuencia único, de modo que cuando un host detecta que un datagrama se ha perdido envía un NACK que irá siguiendo el árbol de retransmisión multicast hasta dar con el punto de confirmación. Así, cuando un punto de confirmación recibe uno de estos NACKs, reenvía de nuevo el datagrama. A esto se le llama confirmación distribuida.

Para que este esquema de confirmación distribuida funcione correctamente es necesario que los puntos de confirmación tengan todos los datagramas en secuencia, y esto se consigue haciendo que ese punto se comporte como un host más de la red: si no recibe un datagrama, envía un NACK.

Lo más complicado del esquema de multicast fiable es escoger una buena topología y una buena distribución de los puntos de confirmación, ya que no existe un proceso automatizado que resuelva esto.

Este esquema iría bien para servicios que duren mucho en el tiempo, para topologias que no tengan que cambiar y cuando los routers intermedios puedan ser puntos de confirmación.