Groupe de travail Réseau	T. Smith, IBM Corporation	
Request for Comments : 2226	G. Armitage, Lucent Technologies	
Catégorie : Sur la voie de la normalisation	octobre 1997	
Traduction Claude Brière de L'Isle		

Diffusion IP sur réseaux ATM

Statut de ce mémoire
Le présent document spécifie un protocole en cours de normalisation de l’Internet pour la communauté de l’Internet, et appelle à des discussions et suggestions pour son amélioration. Prière de se référer à l’édition en cours des "Normes officielles des protocoles de l’Internet" (STD 1) pour connaître l’état de la normalisation et le statut de ce protocole. La distribution du présent mémoire n’est soumise à aucune restriction.

Notice de Copyright 
Copyright (C) The Internet Society (1997). Tous droits réservés.

Résumé
Le présent mémoire décrit comment le service de diffusion groupée IP développé par le groupe de travail IP sur ATM peut être utilisé pour prendre en charge la transmission de diffusion IP. La solution tourne autour du traitement du problème de la diffusion comme un cas particulier de diffusion groupée, où chaque hôte dans le sous réseau ou grappe est un membre du groupe.

On suppose la compréhension des services fournis par la RFC 2022.
Table des matières
1. Introduction	1
2. Révisions sur l'envoi individuel et la diffusion groupée	2
3. La diffusion comme cas particulier de diffusion groupée	2
4. Rôle de MARS dans la diffusion	3
5. Exigences d'hôte pour la diffusion	4
6. Implications de la diffusion IP sur les ressources de niveau ATM	4
7. Discussion	5
Considérations sur la sécurité	5
Remerciements	5
Références	5
Adresse des auteurs	6
Appendice A. Solutions de remplacement pour la diffusion	6
A.1 Solutions de diffusion par serveur ARP	6
A.2 Solutions MARS	7
Appendice B. MARS devrait il être limité à un seul LIS ?	8
Déclaration complète de droits de reproduction	8

 	1.	Introduction
La première étape de l'IETF pour résoudre les problèmes du fonctionnement de IP sur la technologie de mode de transfert asynchrone (ATM, Asynchronous Transfer Mode) est décrite dans la [RFC1577]. Elle traite de la communication en envoi individuel entre les hôtes et les routeurs au sein des sous réseaux logiques IP (LIS, Logical IP Subnet) et propose un serveur ARP ATM centralisé qui fournit les services de résolution d'adresse IP en adresse ATM aux membres du LIS.

Deux classes de service IP sont omises – les transmissions de diffusion et de diffusion groupée. La diffusion groupée permet qu'une seule opération de transmission cause la réception d'un paquet par plusieurs destinations distantes.

La diffusion permet normalement qu'une seule opération de transmission cause la réception d'un paquet par tous les hôtes IP qui sont membres d'un sous réseau particulier.

Pour traiter le besoin de prise en charge de la diffusion groupée (représentée par la transmission aux adresses IP dans l'espace de classe D) la RFC 2022 ("Prise en charge de la diffusion groupée sur réseaux ATM fondés sur UNI 3.0/3.1") [RFC2022] a été créée. Le présent mémoire crée par analogie au serveur ARP de la RFC 1577 une nouvelle entité appelée un serveur de résolution d'adresses de diffusion groupée (MARS, Multicast Address Resolution Server). Le MARS opère comme registre centralisé et mécanisme de distribution pour les transpositions entre adresses de diffusion groupée IP et groupes d'adresses d'envoi individuel ATM. Le comportement de l'hôte est aussi défini pour établir et gérer les VC en point à multipoint, sur la base des informations retournées par le MARS, quand les hôtes souhaitent transmettre des paquets à un groupe de diffusion groupée.

Le présent mémoire vise à montrer comment la [RFC2022] peut être utilisée pour émuler la diffusion IP au sein de sous réseaux logiques IP. Alors que la technique de diffusion ne s'aligne pas bien sur la nature point à point sous-jacente de ATM, certaines applications vont clairement souhaiter encore utiliser les diffusions IP. L'application client-serveur où le client cherche un serveur en envoyant une diffusion est un scénario. Les protocoles d'acheminement, en particulier RIP, en sont un autre exemple.

 	2.	Révisions sur l'envoi individuel et la diffusion groupée

Les deux cas de l'envoi individuel et de la diffusion groupée tirent parti des capacités point à point et point à multipoint définies dans le document UNI 3.1 de l'ATM Forum [ATM-UNI]. Une adresse IP d'envoi individuel IP a une seule destination de niveau ATM. Les transmissions en envoi individuel surviennent sur des canaux virtuels (VC, Virtual Channel) point à point entre source et destination. Le serveur ARP détient les transpositions entre les adresses de destination IP et leur adresse de destination ATM associée. Les hôtes produisent une ARP_REQUEST au serveur ARP quand ils souhaitent s'assurer d'une transposition particulière. Le serveur ARP répond soit par une ARP_REPLY contenant l'adresse ATM de la destination, soit par un ARP_NAK quand le serveur ARP ne peut pas résoudre l'adresse. Si la demande réussit, l'hôte établit un VC à l'interface de destination. Ce VC est alors utilisé pour transmettre les premiers paquets (et les suivants) pour cette destination IP particulière. La RFC 1577 décrit plus en détails comment les hôtes sont groupés administrativement dans des sous réseaux IP logiques (LIS, Logical IP Subnet) et comment le serveur ARP établit les transpositions initiales pour les membres du LIS qu'il dessert.

Le comportement de base d'hôte pour la diffusion groupée est similaire - l'envoyeur doit établir et gérer un VC en point à multipoint dont les nœuds d'extrémité sont les membres actuels du groupe. Dans UNI 3.1, ces VC peuvent seulement être établis et altérés par l'interface de source (racine).

Le MARS est une évolution du modèle de serveur ARP, et effectue deux fonctions clés. La première fonction est la tenue d'une liste des adresses ATM correspondant aux membres de chaque groupe. Cette liste est créée par un processus d'enregistrement d'hôte qui implique deux messages - un MARS_JOIN qui déclare qu'un hôte souhaite se joindre au ou aux groupes spécifiés, et un MARS_LEAVE qui indique qu'un hôte souhaite quitter le ou les groupes spécifiés.

Les messages MARS_JOIN et MARS_LEAVE sont aussi redistribués à tous les membres du groupe afin que les envoyeurs actifs puissent ajuster dynamiquement leur VC en point à multipoint en conséquence.

L'autre fonction majeure est la restitution des membres du groupe à partir du MARS (analogue au serveur ARP qui fournit les transpositions d'adresse d'envoi individuel). Quand il a besoin de transmettre un paquet IP avec une adresse de destination de classe D, un hôte produit une MARS_REQUEST au MARS. Si le groupe a des membres, le MARS retourne un MARS_MULTI (éventuellement en plusieurs segments) portant un ensemble d'adresses ATM. L'hôte établit alors un VC initial en point à multipoint en utilisant ces adresses ATM comme nœuds d'extrémité. Si le MARS n'a pas de transpositions, il va retourner un MARS_NAK.

(La RFC 2022 explique aussi comment le MARS peut s'arranger pour que des groupes de classe D soient pris en charge par des serveurs de diffusion groupée, ou des maillages de VC en point à multipoint d'hôte à hôte. Cependant, du point de vue de l'hôte, ceci est transparent, et n'est pas un point central de cette discussion de la prise en charge de la diffusion IP.)

Le présent mémoire décrit comment un hôte peut utiliser les fonctions d'enregistrement et de gestion de groupe dans un réseau IP/ATM fondé sur un MARS existant pour émuler les diffusions IP.

 	3.	La diffusion comme cas particulier de diffusion groupée

Beaucoup des problèmes qui se posent quand on met en œuvre une solution de diffusion se posent aussi quand on met en œuvre une solution de diffusion groupée. En fait, la diffusion peut être considérée comme un cas particulier de diffusion groupée. C'est-à-dire que la diffusion est un groupe de diffusion groupée dont les membres incluent tous les membres dans le LIS.

Le présent mémoire vise deux groupes de diffusion :
(1) 255.255.255.255 – diffusion "toute de uns" (255 en décimal s'écrit 11111111 en binaire)
(2) x.z – diffusion dirigée sur un préfixe de CIDR (sous réseau)

La diffusion (1) est parfois appelée une diffusion limitée à son réseau physique. La diffusion (2) peut être vue comme la diffusion pour des sous réseaux ou réseaux dans le vieux paradigme. Comme décrit dans les [RFC1519] et [RFC1812], la notion de sous réseau et réseaux est remplacée par une utilisation plus efficace de l'espace d'adresses d'acheminement connu sous le nom d'acheminement inter domaines sans classe (CIDR, Classless InterDomain Routing). Le préfixe de CIDR (x) est la combinaison de l'adresse IP et du gabarit de sous réseau qui note le numéro de sous réseau. La portion hôte de l'adresse (z) est toute de uns. On devrait noter que bien que ces diffusions aient des portées différentes à la couche IP ou réseau, elles ont précisément la même portée à la couche de liaison – à savoir tous les membres du LIS vont recevoir une copie.

Ces adresses peuvent être utilisées dans deux environnements :

o	Diffusion à tous les membres d'un certain LIS où l'adresse IP d'un hôte et le gabarit de sous réseau sont connus a priori (par exemple, la diffusion dirigée sur le préfixe de CIDR).

o	Diffusion à tous les membres d'un réseau physique sans connaître l'adresse IP d'un hôte ni le gabarit de sous réseau (par exemple, la diffusion toute de uns).

Sur un support de diffusion comme Ethernet, ces deux environnements résultent en la même destination physique. C'est-à-dire que toutes les stations sur ce réseau vont recevoir la diffusion même si elles sont sur des sous réseaux logiques différents, ou sont des stations non IP. Avec ATM, cela ne peut pas être le cas.
Parce que ATM est en non diffusion, un processus d'enregistrement doit avoir lieu. Et si il y a des stations qui s'enregistrent à certains groupes de diffusion, mais pas à d'autres, alors les différents groupes de diffusion vont avoir des adhérents différents. La notion de diffusion devient non cohérente.

Un cas qui exige l'utilisation de la diffusion toute de uns est celle de l'amorçage sans disque, ou client bootp, où l'hôte s'amorce, et ne connaît pas sa propre adresse IP ni son gabarit de sous réseau. Il est clair que l'hôte ne sait pas à quel sous réseau il appartient. Donc, pour envoyer une diffusion à son serveur bootp, la station de travail sans disque doit utiliser le groupe qui ne contient pas d'informations de sous réseau, c'est-à-dire, le groupe de diffusion 255.255.255.255. En poussant un peu plus l'exemple, le serveur bootp, après avoir reçu la diffusion, ne peut envoyer ni une trame dirigée ni une diffusion dirigée sur le sous réseau pour répondre à la station de travail sans disque. À la place, le serveur bootp doit aussi utiliser le groupe 255.255.255.255 pour communiquer avec le client.

Alors que la diffusion toute de uns est exigée à la couche IP, elle est aussi pertinente à la couche de liaison pour décider quel groupe de diffusion enregistrer auprès du MARS. En d'autres termes, un client bootp qui souhaite s'enregistrer pour une diffusion de couche de liaison, peut seulement s'enregistrer pour 255.255.255.255 dans l'espace d'adresses du MARS parce que le sous réseau du client n'est pas connu à ce moment. Étant donné que certaines applications doivent utiliser l'adresse toute de uns dans le MARS pour leur groupe de diffusion, et qu'on souhaite minimiser le nombre de groupes de diffusion utilisés par les membres du LIS, le groupe tout de uns dans le MARS DOIT être utilisé par tous les membres du LIS quand ils s'enregistrent pour recevoir les transmissions en diffusion. Le VCC utilisé pour transmettre tout paquet en diffusion va se fonder sur les membres enregistrés dans le MARS sous la position d'adresse 255.255.255.255. Ce VCC va être appelé le "canal de diffusion" dans la suite du présent mémoire.

 	4.	Rôle de MARS dans la diffusion

De nombreuses solutions ont été proposées, certaines d'entre elles sont citées dans l'Appendice A. Le présent mémoire vise la solution de MARS qui paraît faire au mieux pour résoudre le problème de la diffusion.

Un certain nombre des caractéristiques de l'architecture de MARS devraient être conservées intactes. Cela inclut :
o	MARS ne contient aucune connaissance des préfixes et gabarits de sous réseau. Chaque adresse de groupe enregistré au MARS est gérée indépendamment.
o	Un MARS peut seulement desservir un LIS. Cela assure que le groupe de diffusion 255.255.255.255 est joint par les hôtes d'un seul LIS, gardant sa limite de portée dans une interprétation conventionnelle.
o	Le serveur de diffusion groupée (MCS, MultiCast Server) décrit dans la [RFC2022] peut être utilisé pour desservir les groupes de diffusion définis dans le présent mémoire sans modification. Le MCS va réduire le nombre de canaux utilisés par le réseau.

Le MARS n'a pas besoin de code supplémentaire ni d'algorithmes particuliers pour traiter la résolution des adresses de diffusion IP. C'est simplement une base de données générale qui détient les transpositions {Adresse de protocole, ATM.1, ATM.2, ... ATM.n} et n'impose pas de contrainte sur le type et la longueur de l'adresse de protocole. Que les hôtes le voient comme classe D ou "diffusion" (ou même IP) est purement un problème côté hôte.

Il est probable que les points d'extrémité vont vouloir utiliser l'émulation de diffusion IP décrite ici afin de prendre en charge au moment de l'amorçage la localisation de l'adresse IP du point d'extrémité. Cela amène l'observation que le MARS NE DEVRAIT PAS s'attendre à voir remplis les champs d'adresse IP de source et d'adresse ATM de source du MARS_JOIN. Ceci est raisonnable, car seule l'adresse ATM de source est utilisée lors de l'enregistrement du point d'extrémité comme membre de groupe.

L'architecture de MARS est suffisante pour assurer l'intégrité de la liste de groupe de diffusion sans modification.

 	5.	Exigences d'hôte pour la diffusion

Les point suivants décrivent les caractéristiques supplémentaires d'un hôte conforme au MARS. Ces caractéristiques sont exigées pour tirer parti de la fonction de diffusion :

o	Un hôte doit s'enregistrer comme client MARS.

o	Un hôte, peu après l'enregistrement DOIT produire un MARS_JOIN à l'adresse de diffusion toute de uns (c'est-à-dire, 255.255.255.255) avec le mar$flags.layer3grp réinitialisé.

o	Lors de la transmission de paquets, l'hôte devrait transposer toutes les diffusions de couche IP en le VCC (canal de diffusion) créé et maintenu sur la base de l'entrée toute de uns dans le MARS.

o	Un hôte DOIT surveiller les messages MARS_JOIN/MARS_LEAVE pour 255.255.255.255 pour garder le canal de diffusion en cours.

o	Un canal de diffusion devrait être supprimé après une période d'inactivité. La période de temporisation correspondante PEUT être spécifiée avec une valeur minimum d'une minute, et une valeur RECOMMANDÉE par défaut de 20  minutes.

On devrait noter qu'alors que chaque membre participant à la diffusion DOIT être un membre du groupe tout de uns, tous les membres ne vont pas choisir de transmettre des informations en diffusion. Certains des membres vont choisir de seulement recevoir passivement les informations en diffusion. Donc, dans un LIS avec n stations, il peut y avoir moins de n canaux terminés à chaque station pour les informations en diffusion. Plus de réductions peuvent être obtenues en ajoutant un MCS à l'environnement de diffusion qui pourrait réduire le nombre de VC à deux (un entrant, un sortant) ou à un pour une station qui souhaite seulement écouter.

Il est bien entendu que la diffusion dans cet environnement peut peser sur les ressources du réseau et des hôtes qui l'utilisent. Donc, une mise en œuvre PEUT choisir de fournir un mécanisme pour retirer l'entrée de l'hôte dans le groupe de diffusion après qu'il a été établi ou avant de se joindre au groupe. Le MARS_LEAVE est utilisé pour demander le retrait du groupe si l'hôte souhaite désactiver la réception de diffusion après qu'il s'est joint au groupe. Le comportement par défaut DEVRA être de se joindre au groupe de diffusion tout de uns dans le MARS.

 	6.	Implications de la diffusion IP sur les ressources de niveau ATM

La RFC 2022 discute certaines des implications des grands groupes de diffusion groupée sur l'allocation de ressources de niveau ATM, à la fois dans le réseau et dans les interfaces de station ATM.

Le mécanisme par défaut est que la diffusion groupée IP soit réalisée en utilisant des maillages de VC en point à multipoint, directs de l'hôte de source aux membres du groupe. Dans certaines circonstances les administrateurs de système peuvent, d'une manière complètement transparente aux hôtes d'extrémité, rediriger le trafic de diffusion groupée à travers des MCS de niveau ATM. Ceci peut être effectué sur la base d'un groupe individuel.

Il est suffisant de noter ici que la diffusion IP de "groupe de diffusion groupée" va constituer le plus grand consommateur de VC au sein du réseau ATM quand il est actif. Pour cette raison, cela va probablement être le premier groupe de diffusion groupée a avoir plus d'un MCS ATM alloué pour le prendre en charge. Cependant, il n'y a rien d'unique a avoir un MCS alloué pour prendre en charge le trafic de diffusion IP, de sorte qu'on n'en parlera pas plus dans le présent mémoire. La RFC 2022 contient plus de discussions sur les applications possibles de plusieurs MCS pour fournir des architectures tolérantes aux fautes.

 	7.	Discussion

Un point de discussion du forum ip-atm a tourné autour de "l'auto configuration" et de "l'amorçage sans disque". Le présent mémoire décrit une solution de diffusion qui exige l'utilisation du MARS. Donc, au minimum, l'adresse ATM du MARS doit être configurée manuellement dans une station de travail sans disque. Des suggestions comme des numéros de canal universels, et des adresses ATM universelles ont été proposée, cependant, aucun accord n'a été obtenu.

Un autre sujet de discussion est la prise en charge multi protocoles. MARS est conçu pour être indépendant du protocole. Le présent mémoire vise spécifiquement le cas de la diffusion IP, en identifiant quelles adresses sont les plus efficaces dans l'espace d'adresses IP. Cependant, les principes s'appliquent à tout protocole de couche 3. D'autres travaux devraient être engagés pour identifier les adresses convenables pour les autres protocoles de couche 3.

Finalement, il y a eu du soutien pour une diffusion de couche de liaison qui serait indépendante du protocole de couche 3. Une telle solution peut fournir un plus simple ensemble de règles selon lesquelles des applications de diffusion peuvent être utilisées. De plus, certaines solutions fournissent aussi une utilisation plus efficace des VCC.

 	Considérations sur la sécurité

Le présent mémoire vise une utilisation spécifique de l'architecture de MARS et de ses composants pour fournir la fonction de diffusion. À ce titre, les implications pour la sécurité ne sont pas plus grandes ou plus petites que les implications de l'utilisation des autres groupes de diffusion groupée disponibles dans la gamme des adresses de diffusion groupée. Si des améliorations de la sécurité devaient être requises, elles devraient être ajoutées comme extension à l'architecture de base de la RFC 2022.

 	Remerciements

L'apparente simplicité du présent mémoire doit beaucoup aux services fournis dans la [RFC2022], qui elle-même est le produit de beaucoup de discussions dans la liste de diffusion du groupe de travail IP-ATM de l'IETF. Grenville Armitage a travaillé à ce document alors qu'il était employé par Bellcore.

 	Références

[ATM-UNI]	ATM Forum, "ATM User-Network Interface Specification Version 3.0", Englewood Cliffs, NJ: Prentice Hall, septembre 1993.

[RFC1112]	S. Deering, "Extensions d'hôte pour diffusion groupée sur IP", STD 5, août 1989. (Mise à jour par la RFC2236)

[RFC1519]	V. Fuller, T. Li, J. Yu et K. Varadhan, "Acheminement inter domaine sans classe (CIDR) : stratégie d'allocation et d'agrégation d'adresses", septembre 1993. (D.S., rendue obsolète par la RFC4632)

[RFC1577]	M. Laubach, "IP classique et ARP sur ATM", janvier 1994. (rendue obsolète par la RFC2225)

[RFC1755]	M. Perez et autres, "Prise en charge de la signalisation ATM pour IP sur ATM", février 1995. (P.S.)

[RFC1812]	F. Baker, "Exigences pour les routeurs IP version 4", juin 1995. (MàJ par les RFC2644, RFC6633)

[RFC2022]	G. Armitage, "Prise en charge de la diffusion groupée sur réseaux ATM fondés sur UNI 3.0/3.1", novembre 1996. (P.S.)

[RFC2119]	S. Bradner, "Mots clés à utiliser dans les RFC pour indiquer les niveaux d'exigence", BCP 14, mars 1997. (MàJ par RFC8174)

 	Adresse des auteurs

Timothy J. Smith	Grenville Armitage	
Network Routing Systems,	Bell Labs, Lucent Technologies	
International Business Machines Corporation.	101 Crawfords Corner Rd,	
N21/664	Holmdel, NJ, 07733	
P.O.Box 12195	USA	
Research Triangle Park, NC 27709	mél : gja@lucent.com 	
téléphone : (919) 254-4723		
mél : tjsmith@vnet.ibm.com 		

 	Appendice A.	Solutions de remplacement pour la diffusion

Durant le développement du présent mémoire, de nombreuses solutions de remplacement ont été explorées et éliminées pour une raison ou une autre. Cet appendice documente ces solutions de remplacement et les raisons pour lesquelles elles ont été écartées.

 	A.1	Solutions de diffusion par serveur ARP
Le serveur ARP est un bon candidat pour la prise en charge de la diffusion. Il y a un serveur ARP pour chaque LIS. Le serveur ARP contient la liste entière des membres du LIS. Il a les ingrédients fondamentaux pour la fonction de diffusion.

 	A.1.1	Solution de base sans modification au serveur ARP
On peut choisir comme point de départ existant d'utiliser seulement ce qui est disponible dans la RFC 1577. C'est-à-dire, un hôte peut facilement calculer la gamme des membres dans son LIS sur la base de sa propre adresse et gabarit de sous réseau. L'hôte peut alors produire une demande ARP pour chaque membre du LIS. Avec ces informations, l'hôte peut alors établir des connexions point à point avec tous les membres, ou peut établir une connexion en point à multipoint avec tous les membres. C'est la diffusion du pauvre.

Bien que cette solution soit très directe, elle souffre d'un certain nombre de problèmes.

o	La charge sur le serveur ARP est très lourde. Si toutes les stations sur un LIS choisissent de mettre en œuvre la diffusion, la charge initiale de demandes ARP va être énorme. Une sorte de séquence de démarrage lent serait nécessaire.

o	La quantité de ressources requise rend cette solution non adaptable. Les auteurs pensent que la diffusion va exiger un MCS pour réduire le nombre de ressources de canaux nécessaires pour prendre en charge chaque groupe de diffusion. Utiliser le serveur ARP de cette manière ne permet pas à un MCS d'être introduit de façon transparente. (Les interfaces de base de la RFC1577 ne mettent pas non plus en œuvre l'encapsulation LLC/SNAP étendue requise pour utiliser en toute sécurité plus d'un MCS).

o	La solution de l'amorçage sans disque ne peut pas fonctionner dans cet environnement parce qu'il peut être incapable de déterminer à quel sous réseau il appartient.

 	A.1.2	Solution de serveur ARP amélioré
Cette solution est similaire à la solution de base sauf qu'elle prend certaines des solutions de la diffusion groupée (MARS)  et l'incorpore dans le serveur ARP. La première amélioration est d'ajouter la commande MARS_MULTI au jeu de opcodes que prend en charge le serveur ARP. Cela permettrait à un hôte de produire une seule demande, et d'obtenir en retour la liste des membres dans un ou plusieurs paquets MARS_REPLY. Plutôt que d'avoir un mécanisme d'enregistrement, le serveur ARP pourrait simplement utiliser la liste des membres qui ont déjà été enregistrés. Quand une demande arrive pour l'adresse de diffusion du sous réseau, le serveur ARP va agréger la liste, et envoyer le résultat au demandeur.

Cela souffre de deux inconvénients :

1)	L'adaptabilité à l'égard du nombre de VC est toujours un problème. On pourrait éventuellement ajouter dans certaines sortes de solutions de serveur de diffusion groupée un serveur ARP.

2)	Le scénario d'amorçage sans disque est toujours en panne. Il n'y a aucun moyen pour une station d'effectuer un MARS_MULTI sans d'abord connaître son adresse IP et son gabarit de sous réseau.

Le problème de l'amorçage sans disque pourrait être résolu en ajoutant au serveur ARP un processus d'enregistrement où chacun pourrait s'enregistrer à l'adresse 255.255.255.255. Ces changements feraient ressembler le serveur ARP de plus en plus au MARS.

 	A.2	Solutions MARS
Si on souhaite conserver le serveur ARP constant comme décrit dans la RFC 1577, la solution est d'utiliser le serveur de résolution d'adresse de diffusion groupée (MARS, Multicast Address Resolution Server) décrit dans la [RFC2022].

MARS a trois caractéristiques qui conviennent à la diffusion :

1)	 Il a une approche d'enregistrement généralisé qui permet pour toute adresse d'avoir un groupe d'entités enregistrées. Donc, si l'adresse de sous réseau n'est pas connue, un hôte peut s'enregistrer pour une adresse qui est connue (par exemple, 255.255.255.255).

2)	Le jeu de commandes permet que les listes de membres soient passées dans un seul paquet MARS_MULTI. Cela réduit le trafic.

3)	MARS contient une architecture pour traiter les questions d'adaptabilité. C'est-à-dire, les serveurs de diffusion groupée (MCS, Multicast Server) peuvent être utilisés pour établir les canaux de point à multipoint et réduire à un le nombre de canaux qu'un hôte doit établir. Les hôtes qui souhaitent diffuser vont plutôt envoyer le paquet au MCS qui va alors le transmettre à tous les membres du LIS.

 	A.2.1	Solution de diffusion sur un préfixe de CIDR (sous réseau)
Une des premières solutions était de simplement déclarer que la prise en charge de la diffusion serait mise en œuvre en utilisant un seul groupe de diffusion groupée dans l'espace d'adresses de classe D – à savoir, le groupe d'adresse de diffusion au préfixe CIDR (sous réseau). Tous les membres d'un LIS seraient obligés de s'enregistrer à cette adresse, et de l'utiliser comme nécessaire. Un hôte souhaitant utiliser la diffusion 255.255.255.255, ou les adresses de diffusion  réseau transposerait en interne le VC en le VC de diffusion de sous réseau. Les adresses toute de uns et de diffusion réseau existeraient sur le MARS, mais ne seraient pas utilisées.

Le problème avec cette approche revient à celui de la station de travail sans disque. Parce que la station de travail ne peut pas savoir à quel sous réseau elle appartient, elle ne sait pas à quel groupe s'enregistrer.

 	A.2.2	Tout de uns en premier, diffusion de sous réseau en second
Cette solution reconnaît que le problème de l'amorçage sans disque exige une adresse générique (qui ne contienne pas d'informations de préfixe de CIDR (sous réseau)) pour s'enregistrer et à utiliser jusqu'à ce quelle apprenne son sous réseau. Essentiellement, toutes les stations s'enregistrent d'abord au groupe 255.255.255.255, puis lorsque elles connaissent leurs informations de sous réseau, elles pourraient facultativement se désenregistrer du groupe tout de uns et s'enregistrer au groupe de diffusion de préfixe de CIDR (sous réseau).

Cette solution paraît résoudre un couple de problèmes :

1)	Le client bootp peut fonctionner si le serveur reste enregistré continuellement au groupe tout de uns.

2)	Il y aura moins de trafic sur le groupe tout de uns parce que les transactions préférées vont être sur le canal de diffusion de sous réseau.

Malheureusement le premier point contient une faute. Le serveur doit continuellement être enregistré sur deux groupes – le groupe tout de uns et le groupe de diffusion de sous réseau. Si ce serveur a plusieurs processus qui fonctionnent sur différentes applications IP, il peut être difficile à la couche de liaison de savoir quel VC de diffusion utiliser. Si il utilise toujours le tout de uns, alors il va manquer les membres qui se sont retirés du tout de uns et se sont enregistrés au sous réseau de diffusion. Si il utilise toujours le groupe de diffusion de sous réseau, le scénario d'amorçage sans disque reste en panne. Bien que prendre la décision à la couche de liaison puisse exiger que soient construits des flux de contrôle supplémentaires dans le chemin, cela peut aussi exiger de réécrire le logiciel d'application.

Dans certaines mises en œuvre, une simple constante est utilisée pour indiquer à la couche de liaison que ce paquet est à transmettre à l'adresse de diffusion "MAC". L'hypothèse est que la diffusion de réseau physique et le protocole de diffusion logique sont une seule et même entité. Comme on l'a souligné précédemment, ce n'est pas le cas avec ATM. Donc les applications devraient identifier spécifiquement l'adresse de groupe de diffusion de sous réseau pour tirer parti du plus petit groupe.

Ces problèmes pourraient être résolus de diverses façons, mais il a été estimé qu'elles ajoutaient inutilement de la complexité à la solution de diffusion.

 	Appendice B.	MARS devrait il être limité à un seul LIS ?

La RFC 2022 déclare explicitement qu'un administrateur de réseau DOIT s'assurer que chaque LIS est desservi par un MARS distinct, créant une transposition biunivoque entre grappe et LIS en envoi individuel. Mais, elle mentionne aussi que l'assouplissement de cette restriction PEUT se faire si de futures recherches la garantissent. Le présent appendice discute certaines des implications potentielles sur la diffusion si cette restriction devait être supprimée.

Le changement le plus évident serait que la notion d'une grappe s'étendrait sur plus d'un LIS. Donc, le groupe de diffusion de 255.255.255.255 contiendrait les membres de plus d'un LIS.

Il devrait aussi être souligné que la limitation à un LIS n'est pas une restriction de l'architecture de MARS. Elle n'est plutôt appliquée que si un administrateur choisit de le faire.

 	Déclaration complète de droits de reproduction

Copyright (C) The Internet Society (1997). Tous droits réservés.

Le présent document et ses traductions peuvent être copiés et fournis aux tiers, et les travaux dérivés qui les commentent ou les expliquent ou aident à leur mise en œuvre peuvent être préparés, copiés, publiés et distribués, en tout ou partie, sans restriction d’aucune sorte, pourvu que la déclaration de droits de reproduction ci-dessus et le présent paragraphe soient inclus dans toutes telles copies et travaux dérivés. Cependant, le présent document lui-même ne peut être modifié d’aucune façon, en particulier en retirant la notice de droits de reproduction ou les références à la Internet Society ou aux autres organisations Internet, excepté autant qu’il est nécessaire pour le besoin du développement des normes Internet, auquel cas les procédures de droits de reproduction définies dans les procédures des normes Internet doivent être suivies, ou pour les besoins de la traduction dans d’autres langues que l’anglais.

Les permissions limitées accordées ci-dessus sont perpétuelles et ne seront pas révoquées par la Internet Society ou ses successeurs ou ayant droits.

Le présent document et les informations contenues sont fournis sur une base "EN L’ÉTAT" et le contributeur, l’organisation qu’il ou elle représente ou qui le/la finance (s’il en est), la INTERNET SOCIETY et la INTERNET ENGINEERING TASK FORCE déclinent toutes garanties, exprimées ou implicites, y compris mais non limitées à toute garantie que l’utilisation des informations encloses ne violent aucun droit ou aucune garantie implicite de commercialisation ou d’aptitude à un objet particulier.