Qu’est-ce que la diffusion (broadcast) ?
La diffusion (broadcasting) consiste à envoyer le même paquet à plusieurs destinataires.
Lorsque les différents destinataires sont sur la même liaison (cas de la liaison multipoint), il suffit d’envoyer le même paquet et chaque destinataire peut le recevoir. Pour cela, bien sûr, il faut que le protocole de niveau physique ait prévu ce type d’adressage. C’est le cas, par exemple d’Ethernet.
Dans le cas où pour accéder à un destinataire, il faut traverser un commutateur ou un routeur, deux solutions sont possibles :
- l’émetteur envoie une copie du paquet à chaque destinataire avec une forte utilisation de la bande passante ;
- l’émetteur envoie un seul paquet en précisant l’adresse de diffusion et les équipements relais se chargent de la diffusion ; Dans ce cas, la diffusion doit être prévu par le niveau réseau.
Comment s’effectue la diffusion dans Ethernet ?
L’adresse Ethernet est une adresse sur 48 bits. L’adresse de diffusion consiste à mettre tous les bits à 1. Chaque carte reconnaît sa propre adresse ainsi que l’adresse de diffusion. La diffusion est utilisée dans des cas bien précis ainsi le protocole ARP (Address Resolution Protocol) l’utilise pour résoudre la correspondance entre les adresses physique Ethernet et l’adresse IP. Cela évite une consommation trop forte de bande passante.
Qu’est-ce que la diffusion de groupe (multicast) ?
Une autre forme d’adressage existe : l’adressage de diffusion de groupe (Multicast).
Dans ce cas, chaque machine prévient si elle décide de participer à une diffusion de groupe ou non. Au niveau physique, il faut une configuration au niveau filtrage d’adresse. Ainsi, une machine pourra recevoir un paquet lui étant adressé individuellement, à tout le monde ou au groupe auquel elle appartient. L’émetteur utilisera soit l’adressage individuel (unicast address), soit l’adressage de diffusion (broadcast address), soit l’adressage de groupe (multicast address).
Comment s’effectue la diffusion de groupe dans Ethernet ?
Ethernet utilise le bit de poids faible de l’octet de poids le plus fort :
0 adresse unicast, 1 adresse de diffusion.
Dans la notation hexadécimale pointée : 01.00.00.00.00.00
Comment s’effectue la diffusion au niveau IP ?
Le concept de groupe d'hôtes est né en 1985 lorsque Deering et Cheriton décrivent l'extension multicast à IP (RFC 966 - "Host groups: a multicast extension to the Internet Protocol"). D'autres RFC proposés par Steve Deering suivirent: RFC 988, RFC 1054 et RFC 1112.
Un groupe peut contenir des hôtes se trouvant sur le même réseau ou sur plusieurs réseaux. Dans ce dernier cas, des routeurs spéciaux Multicast Routers (mrouters ou MR) acheminent les datagrammes de diffusion de groupe.
C'est en 1988 que les premières expériences furent menées. Comme tous les routeurs ne supportent pas les fonctionnalités d'un MR, un réseau virtuel formé de tunnels (liaisons virtuelles point à point) regroupant les MR fut déployé: le MBone (Multicast BackBone). Le MBone va permettre que le multicast soit une réalité au delà du LAN. Un tunnel fonctionne de la manière suivante: à partir d'une extrémité (MR) un paquet multicast est encapsulé dans un paquet UDP unicast (avec une adresse IP individuelle) et envoyé sur l'Internet; Arrivé à l'autre extrémité, le paquet est désencapsulé. Des extensions au protocoles existants sont nécessaires: d'une part sur l'hôte et d'autre part sur certains routeurs qui seront des MR.
Un hôte peut envoyer un paquet à un groupe sans qu’il en fasse partie. Le paquet transmis est remis aux membres du groupe avec la même QOS ("Best-efforts")que si c'était un paquet Unicast. Le paquet n'est pas garanti d'arriver intact à tous les membres.
L’appartenance d’un hôte à un groupe est dynamique. Il ne faut pas mélanger l’adresse de diffusion de groupe qui permet d’identifier un groupe avec l’adresse d’une station qui permet d’identifier une station et une seule. Le groupe contient N hôtes (N pouvant être zéro). Un hôte peut appartenir à N groupes (N pouvant être zéro).
Seul le champ adresse destinataire dans le paquet IP peut contenir une adresse de groupe. L’adresse source contient toujours l’adresse individuelle.
A chaque groupe de diffusion correspond une adresse de groupe. Certaines adresses sont réservées (well-known - assignées par une autorité) même si les groupes correspondants ne comprennent aucune station. Ces groupes sont permanents (pas les membres). Les autres adresses sont temporaires, créées à la demande et supprimées lorsqu’elles ne servent plus (il n'y a plus de membres).
Pour l’émission des datagrammes sur les réseaux on utilise les possibilités de diffusion de groupe physiques. Pour cela une correspondance est nécessaire entre les adresses de diffusion de groupe IP et physique.
Comment limiter la propagation des datagrammes ?
Les datagrammes sont munis d’un champ durée de vie (TTL: Time To Live) qui permet de limiter leurs propagation. En effet, les routeurs ont la responsabilité selon la valeur du TTL de retransmettre ou non le paquet. Cette faculté n'est pas assurée par les ponts (niveau 2). Lorsque TTL=1, la portée du datagramme est le réseau local.
Comment est structurée l’adresse de diffusion de groupe ?
L’adresse IP est sur 32 bits comme l’adresse individuelle. Par contre, il n’y a plus de partie réseau et partie hôte. En effet, une nouvelle classe d’adresses IP a été définie : la classe D. Dans cette classe, les 4 premiers bits sont 1110 et les 28 bits restants contiennent l’identification du groupe.
En notation décimale pointée, les adresses sont comprises entre 224.0.0.0 et 239.255.255.255. L’adresse 224.0.0.0 est réservée et ne peut être affectée à un groupe et l’adresse 224.0.0.1 ("all-hosts group address") est affectée à toutes les machines et toutes les passerelles sur le réseau local (à condition qu'ils supportent l'IP multicast). Il n’y a pas d’adresse désignant toutes les machines de l’Internet.
Comment s’effectue la correspondance entre une adresse Ethernet et une adresse IP?
Le paquet IP est encapsulé dans une trame Ethernet. Les cartes Ethernet ne capturent (filtrent) que les trames qui leur sont destinées. Une première possibilité est d'utiliser l'adresse de diffusion d'Ethernet pour envoyer des datagrammes multicast. Ce cas est valable si des cartes ne sont pas capables de reconnaître des adresses de groupes Ethernet. L'inconvénient est que le filtrage sera effectué au niveau IP surchargeant la CPU.
Une autre possibilité est d'effectuer une correspondance entre une adresse de groupe IP et une adresse de groupe Ethernet. Le IANA posséde un ensemble d'adresses Ethernet: 00:00:5E:XX:XX:XX - La moitié de ces valeurs (utilisation de 23 bits) est réservée pour le multicast. Ainsi, pour les adresses multicast les valeurs 01:00:5E:00.00.00 à 01:00:5E:7F:FF:FF sont disponibles. Le fait de limiter à 23 bits la correspondance permet de conserver un nombre de bits au niveau d’Ethernet non utilisés dans la correspondance pour d’autres protocoles.
Pour mettre en correspondance les adresses de diffusion au niveau IP avec les adresses de diffusion Ethernet, placer les 23 bits de poids faible des adresses de diffusion au niveau IP dans les 23 bits de l’adresse de diffusion de groupe au niveau Ethernet.
On remarquera que plusieurs adresses de groupe IP pourraient avoir les même 23 bits de poids faible. Cela oblige le logiciel IP de vérifier le champ adresse destinataire IP pour filtrer tous les paquets qui ne lui sont pas destinés.
Quelles sont les modifications à apporter à IP ?
Pour émettre un paquet à destination d’un groupe, il suffit
de préciser cette adresse comme adresse destinataire. Le logiciel de correspondance
d’adresse doit pouvoir réaliser la correspondance d’adresses.
Toutefois le module IP doit être légèrement modifié.
Dans une implantation classique nous avons:
si le destinataire (@ IP unicast) est sur le même réseau alors
émettre la trame Ethernet (contenant l'@ Eth du destinataire)
contenant le datagramme
sinon
émettre la trame Ethernet (contenant l'@ Eth de la passerelle)
contenant le datagramme
Pour permettre l'émission multicast:
si le destinataire (@ IP unicast) est sur le même réseau ou est un groupe
alors
émettre la trame Ethernet (contenant l'@ Eth du destinataire)
contenant le datagramme
sinon
émettre la trame Ethernet (contenant l'@ Eth de la passerelle)
contenant le datagramme
Pour recevoir un paquet, il faut que le logiciel IP sache si
une application a demandé d’appartenir à un groupe ou non. D’autre
part, il est nécessaire dans le cas de machines multidomiciliées de savoir si
l’application a demandé d’appartenir à un groupe à partir d’un
réseau spécifique. Le logiciel doit alors gérer des listes d’adresses de
diffusion par réseau. Quand il n’y a plus d’application appartenant
à un groupe donné, le logiciel IP n’appartient plus à ce groupe. Ainsi
deux opérations doivent être implantées:
JoinHostGroup (group-address, interface)
LeaveHostGroup (group-address, interface)
Les fonctionnalités qui viennent d'être décrites sont valables lorsque le multicast est limité à un seul réseau. Dans le cas, où plusieurs réseaux sont impliqués, il est nécessaire de prévoir un protocole spécifique. En effet, supposons qu'un groupe contient des membres de plusieurs réseaux. Lorsqu'un datagramme multicast est émis sur un réseau, que doit faire le routeur qui le reçoit ? Vers quelle sortie envoyer le paquet ? Tous les réseaux doivent-ils recevoir le paquet même s'il n'y a aucun membre du groupe ?
Ainsi pour pouvoir utiliser le multicast sur l'Internet il faut que:
- l'implantation soit réalisée sur l'hôte;
- un MR existe sur le réseau (machine faisant tourner le daemon mrouted);
Quelles sont les niveaux de conformité à la spécification ?
Il y a trois niveaux de conformité :
- Niveau 0 : aucun support d’IP multicasting (ni en émission, ni en réception) ;
- Niveau 1 : support pour l’émission mais pas pour la réception. Pour passer du niveau 0 au niveau 1, peu de code est nécessaire. En effet, il n'y a pas de fonctionnalité de membre de groupe.
- Niveau 2 : conforme au IP multicasting. Cela nécessite l'implantation de protocole de gestion de groupe ainsi que des services nouveaux de correspondance d'adresse entre l'interface physique et IP.
IGMP (Internet Group Management Protocol) est un protocole Internet de Gestion de groupes entre les machines et les routeurs de groupe (RFC 1112). Il permet d’échanger des informations d’appartenance aux groupes.
IGMP, comme ICMP, fait partie de la couche IP et utilise des datagrammes IP.
 |
Le module IP identifie IGMP par la valeur 2 du champ protocole.
Le message IGMP contient les champs suivants:
 |
version = 1; type = 1 (requête du routeur multicast)
ou 2 (rapport de l'hôte)
adresse de groupe = 0 dans une requête.
Quelles sont les phases d’IGMP ?
IGMP comporte deux phases :
- Un hôte qui rejoint un groupe de diffusion pour la première fois diffuse un rapport IGMP informant les équipements connectés au réseau (ce rapport est réémis une ou deux fois au cas où il s'est perdu ou arrivé endommagé). Les routeurs de groupe locaux reçoivent le message, déterminent le routage nécessaire et communiquent ces informations aux autres routeurs de groupe ;
- Les routeurs de groupe interrogent périodiquement les machines du réseau local pour savoir s’il y a des machines appartenant encore à des groupes (l’appartenance change dynamiquement). Les machines appartenant à des groupes répondent à des instants différés. Une seule réponse d’une machine appartenant à un groupe suffit, les autres machines du même groupe n’ont pas alors à répondre. De cette façon on évite la saturation du réseau.
Le rapport d'un hôte en réponse à une requête du routeur n'est pas expédié immédiatement mais après un temps aléatoire. Pour éviter que le temps aléatoire choisi ne soit identique à plusieurs stations, l'adresse IP de la station est utilisée dans le calcul du délai. Si après plusieurs requêtes, aucun rapport concernant un groupe est émis, ce dernier est considéré comme vide au niveau du réseau en question et le routeur répercute cette information.
S. Deering donne un diagramme de transition d'états (State Transition Diagram) pour déclire la machine protocolaire IGMP:
 |
A host may be in one of three possible states, with respect to any single IP host group on any single network interface:
- Non-Member state, when the host does not belong to the group on the interface. This is the initial state for all memberships on all network interfaces; it requires no storage in the host.
- Delaying Member state, when the host belongs to the group on the interface and has a report delay timer running for that membership.
- Idle Member state, when the host belongs to the group on the interface and does not have a report delay timer running for that membership.
There are five significant events that can cause IGMP state transitions:
- "join group" occurs when the host decides to join the group on the interface. It may occur only in the Non-Member state.
- "leave group" occurs when the host decides to leave the group on the interface. It may occur only in the Delaying Member and Idle Member states.
- "query received" occurs when the host receives a valid IGMP Host Membership Query message. To be valid, the Query message must be at least 8 octets long, have a correct IGMP checksum and have an IP destination address of 224.0.0.1. A single Query applies to all memberships on the interface from which the Query is received. It is ignored for memberships in the Non-Member or Delaying Member state.
- "report received" occurs when the host receives a valid IGMP Host Membership Report message. To be valid, the Report message must be at least 8 octets long, have a correct IGMP checksum, and contain the same IP host group address in its IP destination field and its IGMP group address field. A Report applies only to the membership in the group identified by the Report, on the interface from which the Report is received. It is ignored for memberships in the Non-Member or Idle Member state.
- "timer expired" occurs when the report delay timer for the group on the interface expires. It may occur only in the Delaying Member state.
All other events, such as receiving invalid IGMP messages, or IGMP messages other than Query or Report, are ignored in all states.
There are three possible actions that may be taken in response to the above events:
- "send report" for the group on the interface.
- "start timer" for the group on the interface, using a random delay value between 0 and D seconds.
- "stop timer" for the group on the interface.
 HTTR |
Tous
droits réservés
© 2001 Université Paul Sabatier (Toulouse III) André Aoun |