RFC3569 page - 8 - SSM

Groupe de travail Réseau

S. Bhattacharyya, éditeur, Sprint

Request for Comments : 3569

juillet 2003

Catégorie : Information

Traduction Claude Brière de L’Isle



Généralités sur la diffusion groupée de source spécifique (SSM)



Statut de ce mémoire

Le présent mémoire apporte des informations pour la communauté de l’Internet. Il ne spécifie aucune sorte de norme de l’Internet. La distribution du présent mémoire n’est soumise à aucune restriction.


Notice de Copyright

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


Résumé

L’objet du présent document et de fournir une vue d’ensemble de la diffusion groupée spécifique de source (SSM, Source-Specific Multicast) et des questions relatives à son déploiement. Il expose comment le modèle de service SSM relève le défi lancé par le déploiement de la diffusion groupée inter domaine, les changement nécessaires pour que les protocoles d’acheminement et les applications développent SSM, et les questions d’interopérabilité avec les modèles de service actuels de diffusion groupée.


1. Introduction


Le présent document donne une vue d’ensemble du service de diffusion groupée de source spécifique (SSM, Source-Specific Multicast) et de son déploiement en utilisant les protocoles PIM-SM et IGMP/MLD. Le service de couche réseau fourni par SSM est un "canal", identifié par une adresse IP de destination SSM (G) et une adresse IP de source S. Une gamme d’adresses IPv4 a été réservée par l’IANA à l’usage du service SSM. Une gamme d’adresses de destination SSM existe déjà pour IPv6. Une source S transmet des datagrammes IP à une adresse de destination SSM G. Un receveur peut recevoir ces datagrammes en s’abonnant au canal (source, groupe) ou (S,G). Un abonnement à un canal est pris en charge par la version 3 du protocole IGMP pour IPv4 et par la version 2 du protocole MLD pour IPv6. L’arborescence inter domaine pour la transmission des datagrammes IP en diffusion groupée a sa racine à la source S, et est construite en utilisant le protocole PIM en mode épars [9].


Ce document n’est pas destiné à constituer une norme de la diffusion groupée spécifique de source (SSM). Son but est plutôt de servir d’introduction à SSM et d’en faire profiter tous ceux qui s’intéressent au déploiement des services SSM. Il donne une vue d’ensemble de SSM et de la façon dont elle résout un certain nombre de problèmes auxquels fait face le déploiement de la diffusion groupée inter-domaine. Il souligne les changements aux protocoles et applications aussi bien chez les hôtes terminaux que chez les routeurs pour la prise en charge de SSM, avec des pointeurs sur des documents plus détaillés lorsque c’est approprié. Les questions d’interopérabilité avec le modèle du service de diffusion groupée défini par la RFC1112 sont aussi exposées.


Le présent mémoire a été produit par le groupe de travail Diffusion groupée spécifique de source (SSM, Source-Specific Multicast) de l’équipe d’ingénierie de l’Internet (IETF, Internet Engineering Task Force).


Dans le présent document, les mots clés "DOIT", "NE DOIT PAS", "EXIGE", "DEVRA", "NE DEVRA PAS", "DEVRAIT", "NE DEVRAIT PAS", "RECOMMANDE", "PEUT", et "FACULTATIF" sont à interpréter comme décrit dans le BCP 14, [28].


2. Terminologie


Cette section définit certains termes qui sont utilisés dans la suite de ce document :


Diffusion groupée toutes sources (ASM, Any-Source Multicast) :

C’est le modèle de service de diffusion groupée IP défini dans la RFC1112 [25]. Un datagramme IP est transmis à un "groupe hôte", un ensemble de zéro ou plusieurs hôtes d’extrémité (ou routeurs) identifiés par une seule adresse IP de destination (224.0.0.0 à 239.255.255.255 pour IPv4). Les hôtes d’extrémité peuvent se joindre au groupe et le quitter à tout moment, et il n’y a pas de restriction à leur localisation ou à leur nombre. De plus, ce modèle prend en charge les groupes de diffusion groupée avec un nombre d’envoyeurs arbitraire – tout hôte d’extrémité (ou routeur) peut transmettre à un groupe d’hôte, même si il n’est pas membre de ce groupe.


Diffusion groupée spécifique de source (SSM, Source-Specific Multicast) :

C’est le modèle de service de diffusion groupée défini dans [5]. Un datagramme IP est transmis par une source S à une adresse de destination SSM G, et les receveurs peuvent recevoir ce datagramme en s’abonnant au canal (S,G). SSM fournit aux applications d’hôte une abstraction "canal", dans laquelle chaque canal a exactement une source et un nombre quelconque de receveurs. SSM est dérivé d’un travail antérieur dans EXPRESS [1]. La gamme d’adresses 232/8 a été allouée par l’IANA au service SSM dans IPv4. Pour IPv6, la gamme FF3x::/96 est définie pour les services SSM [21].


Diffusion groupée à filtrage de source (SFM, Source-Filtered Multicast) :

C’est une variante du modèle de service ASM qui utilise la même gamme d’adresses que ASM (224.0.0.0-239.255.255.255). Elle étend le modèle de service ASM de la façon suivante : chaque "module de protocole de couche supérieure" peut maintenant demander les données envoyées par un groupe hôte G par seulement un ensemble spécifique de sources, ou peut demander les données envoyées au groupe hôte G provenant de toutes les sources SAUF un ensemble spécifique de sources. La prise en charge du filtrage de sources est fournie par la version 3 du protocole Internet de gestion de groupe (IGMPv3, Internet Group Management Protocol) [3] pour IPv4, et la version 2 du protocole de découverte d’écoutant de diffusion groupée (MLDv2, Multicast Listener Discovery) [22] pour IPv6. On se réfèrera dorénavant à ces deux protocoles comme "à capacité SFM". Les versions antérieures de ces protocoles - IGMPv1/IGMPv2 et MLDv1 – n’assurent pas la prise en charge du filtrage de source, et on les dit "sans capacité SFM". Noter qu’alors que SFM est un modèle différent de ASM du point de vue du receveur, il n’y a pas de distinction entre les deux pour l’envoyeur.


Pour les besoins du présent document, on traite le modèle de diffusion groupée à portée limitée de [12] comme une variante d’ASM car il ne restreint pas explicitement le nombre de sources, mais exige seulement qu’elles soient localisées au sein de la zone de portée du groupe.


3. Suite de protocoles IGMP/PIM-SM/MSDP/MBGP pour ASM


Au moment de la rédaction du présent mémoire, tous les réseaux capables de diffusion groupée prennent en charge le modèle de service ASM. Une des suites de protocoles de diffusion groupée les plus courantes pour la prise en charge de ASM consiste en IGMP version 2 [2], PIM-SM [8], [9], MSDP [13] et MBGP [26]. IGMPv2 est le protocole le plus couramment utilisé par les hôtes pour spécifier les membres d’un groupe de diffusion groupée, et presque tous les routeurs de diffusion groupée prennent (au moins) en charge IGMPv2. Dans le cas de IPv6, MLDv1 [21] est le protocole utilisé couramment.


Bien qu’un certain nombre de protocoles tels que PIM-DM [10], CBT [24], [11], DVMRP [6], etc. existent pour construire une arborescence de diffusion groupée parmi les receveurs et sources dans le même domaine administratif, PIM-SM [8], [9] est le protocole le plus largement utilisé. PIM-SM construit une arborescence de diffusion groupée qui prend sa racine à un point de rendez-vous pour tous les membres du groupe au sein d’un seul domaine administratif. Un routeur de 'premier bond' adjacent à une source de diffusion groupée envoie le trafic de la source au point de rendez-vous pour son domaine. Le point de rendez-vous transmet les données le long de l’arborescence à tous les receveurs intéressés au sein du domaine. PIM-SM permet aussi aux receveurs de commuter sur une arborescence de plus court chemin fondée sur la source.


Au moment de cette rédaction, les hôtes d’extrémité de diffusion groupée avec des capacités SFM ne sont pas largement disponibles. Donc, un client peut seulement spécifier son intérêt pour un groupe d’hôte entier et recevoir les données envoyées de toute source à ce groupe.


Le service de diffusion groupée inter-domaine (c’est-à-dire, où les sources et les receveurs sont localisés dans des domaines différents) exigent des protocoles supplémentaires – MSDP [13] et MBGP [26] sont ceux qui sont les plus utilisés. Un point de rendez-vous utilise le protocole MSDP pour annoncer les sources de diffusion groupée aux points de rendez-vous dans les autres domaines. Lorsque un point de rendez-vous découvre une source dans un domaine différent qui transmet des données à un groupe de diffusion groupée pour lequel il y a des receveurs intéressés dans son propre domaine, il se joint à l’arborescence fondée sur la source de plus court chemin qui a sa racine à cette source. Il redistribue alors les données reçues à tous les receveurs intéressés via l’arborescence intra-domaine partagée qui a lui-même pour racine.


MBGP définit des extensions au protocole BGP pour la prise en charge de l’annonce des informations d’accessibilité pour les chemins de diffusion groupée. Cela permet à un système autonome (AS) de prendre en charge des topologies d’envoi individuel et de diffusion groupée non congruentes, et donc de mettre en œuvre des politiques d’acheminement distinctes pour chacune.


Cependant, les routeurs de dernier bond des receveurs intéressés peuvent éventuellement commuter sur une arborescence de plus court chemin qui a sa racine à la source qui transmet les données.


4. Problèmes de l’architecture actuelle


Il y a plusieurs problèmes de déploiement qui sont associés à l’architecture actuelle de diffusion groupée :


A) Allocation d’adresse :

L’allocation des adresses est un des principaux défis de déploiement posés par le modèle de service ASM. L’architecture actuelle de diffusion groupée ne fournit pas de solution déployable pour empêcher les collisions d’adresse entre plusieurs applications. Le problème est beaucoup moins sérieux pour IPv6 que pour IPv4 car la taille de l’espace d’adresses de diffusion groupée est bien plus grand. Un schéma d’allocation d’adresse statique, GLOP [17] a été proposé comme solution intérimaire pour IPv4 ; cependant, les adresses GLOP sont allouées par AS enregistrée, ce qui est inadéquat dans les cas où le nombre des sources excède le nombre d’AS disponibles pour la transposition. La RFC3138 élargit la RFC2770 pour permettre aux registres d’acheminement d’allouer des adresses de diffusion groupée à partir de l’espace GLOP correspondant à l’espace d’AS privé de la RFC1930 [27]. Cet espace est appelé l’espace d’adresse EGLOP (GLOP étendu). Des solutions à long terme proposées comme l’architecture d’allocation d’adresses de diffusion groupée [14] sont généralement perçues comme étant trop complexes (par rapport à la nature dynamique de l’allocation d’adresse de diffusion groupée) pour un large déploiement.


B) Manque de contrôle d’accès :

Dans le modèle de service ASM, un receveur ne peut pas spécifier quelles sources particulières il aimerait recevoir lorsque il se joint à un certain groupe. Un receveur va recevoir les données envoyées à un hôte par toutes les sources. De plus, même quand une adresse de groupe de diffusion groupée est allouée à une source pour qu’elle transmette dessus, il n’y a pas de moyens de faire qu’aucune autre source n’utilise aussi la même adresse. Cela est vrai même dans le cas de IPv6, où les collisions d’adresses sont moins probables du fait de la plus grande taille de l’espace d’adresses.


C) Traitement inefficace des sources bien connues :

Dans les cas où l’adresse de la source est bien connue à l’avance par le receveur qui rejoint le groupe, et quand le plus court chemin de transmission est le mode de transmission préféré, les mécanismes d’arborescence partagée ne sont pas nécessaires.


5. Diffusion groupée spécifique de source (SSM) : avantages et exigences


Comme on l’a mentionné précédemment, le modèle de service de diffusion groupée spécifique de source (SSM, Source Specific Multicast) définit un "canal" identifié par une paire (S,G) où S est une adresse de source et G est une adresse de destination SSM. Les abonnements aux canaux sont décrits en utilisant un protocole de gestion de groupe à capacité SFM tel que IGMPv3 ou MLDv2. Seules les arborescences de transmission fondées sur la source sont nécessaires pour mettre en œuvre ce modèle.


Le modèle de service SSM soulage tous les problèmes de déploiement décrits plus haut :

A) Allocation d’adresse :

SSM définit les canaux sur la base de la source, c’est-à-dire que le canal (S1,G) est distinct du canal (S2,G), où S1 et S2 sont les adresses de source, et G est une adresse de destination SSM. Cela écarte le problème de l’allocation globale des adresses de destination SSM, et rend chaque source seule responsable de la résolution des collisions d’adresses pour les divers canaux qu’elle crée.


B) Contrôle d’accès :

SSM se prête à une élégante solution du problème du contrôle d’accès. Lorsque un receveur s’abonne à un canal (S,G), il reçoit les données envoyées par la seule source S. À l’opposé, tout hôte peut transmettre à un groupe d’hôtes ASM. En même temps, lorsque un envoyeur prend un canal (S,G) pour transmettre, il est automatiquement assuré qu’aucun autre envoyeur ne va transmettre sur le même canal (excepté dans le cas d’actes malveillants comme une usurpation d’adresse). Cela rend beaucoup plus difficile de "pourrir" un canal SSM qu’un groupe de diffusion groupée ASM.


C) Traitement des sources bien connues :

SSM exige seulement des arborescences de transmission fondées sur la source ; cela élimine le besoin d’infrastructure d’arborescence partagée. Cela implique que ni l’infrastructure d’arborescence partagée fondée sur le point de rendez-vous de PIM-SM ni le protocole MSDP ne sont exigés. Donc, la complexité de l’infrastructure d’acheminement de diffusion groupée pour SSM est faible, la rendant viable pour un déploiement immédiat. Noter qu’il n’y a pas de différence dans la façon dont MBGP est utilisé pour ASM et SSM.


6. Cadre de SSM


La Figure 1 illustre les éléments dans un cadre de mise en œuvre de bout en bout de SSM :


--------------------------------------------------------------

Alloué par l’IANA 232/8 pour IPv4 ALLOCATION D’ADRESSE

FF3x::/96 pour IPv6

--------------------------------------------------------------

|

v

+--------------+ répertoire de session/page de la Toile

|source,groupe | DESCRIPTION DE SESSION

--------------------------------------------------------------

^ |

Interrogation| | (S,G)

| v

+-----------------+ hôte

| App à capa SSM | DÉCOUVERTE DE CANAL

--------------------------------------------------------------

| App à capa SSM | APPLICATION À CAPACITÉ ssm

--------------------------------------------------------------

| IGMPv3/MLDv2 | RAPPORT D’HOTE IGMPv3/MLDv2

+-----------------+

|(rapport d’hôte spécifique de source) --------------------------------------------------------------

v

+-----------------+ Routeur interrogateur

| IGMPv3/MLDv2 | INTERROGATEUR

--------------------------------------------------------------

| PIM-SSM | ACHEMINEMENT PIM-SSM

+------------+ Routeur désigné

|

| (S,G) seulement adhésion

v

+-----------+ Routeur de cœur de réseau

| PIM-SSM |

+-----------+

|

| (S,G) seulement adhésion

V


Figure 1 : Éléments du modèle de bout en bout dans le cadre SSM


On va maintenant exposer en détails les éléments du cadre :


6.1 Allocation d’adresse


Pour IPv4, la gamme d’adresses de 232/8 a été allouée par l’IANA pour SSM. Pour assurer la fonctionnalité SSM mondiale dans 232/8, y compris dans les réseaux où les routeurs fonctionnent avec des protocoles sans capacité SFM, des politiques de fonctionnement ont été proposées [9] qui recommandent que les routeurs n’envoient pas de trafic SSM aux parties du réseau qui n’ont pas d’abonné aux canaux.


Noter que IGMPv3/MLDv2 ne limitent pas les adhésions (S,G) à la seule gamme 232/8. Cependant, le service SSM, tel que défini dans [5], n’est disponible que dans cette gamme d’adresses pour IPv4.


Dans le cas de IPv6, [23] a défini une extension à l’architecture d’adressage pour permettre des adresses de diffusion groupée en envoi individuel fondées sur un préfixe. Voir les détails dans la RFC3306 [21].


6.2 Description de session et découverte du canal


Une application de receveur SSM doit connaître aussi bien l’adresse de destination SSM G que l’adresse de source S avant de s’abonner à un canal. La découverte de canal est de la responsabilité de l’application. Ces informations sont disponibles d’un certain nombre de façons, incluant des pages de la Toile, des applications d’annonce de session, etc. Ceci est similaire à ce qui est utilisé pour les applications ASM où une session en diffusion groupée doit être annoncée afin que les souscripteurs potentiels puissent connaître l’adresse de groupe de diffusion groupée, les schémas de codage utilisés, etc. En fait, le seul élément d’information supplémentaire qui doive être annoncé est l’adresse de source du canal annoncé. Cependant, le mécanisme exact pour faire cela sort du domaine d’application du présent document.


6.3 Applications à capacité SSM


Rendre les applications de diffusion groupée "à capacité SSM" touche deux problèmes principaux :

- une application qui veut recevoir une session SSM doit d’abord découvrir l’adresse du canal utilisé ;

- une application receveuse doit être capable de spécifier une adresse de source et une adresse de destination au module de protocole de couche réseau sur l’hôte d’extrémité.


Les exigences d’API spécifiques sont identifiées dans [16]. [16] décrit une interface de programmation d’application recommandée pour un système d’exploitation d’hôte pour la prise en charge du modèle de service SFM. Bien qu’il soit destiné à SFM, un sous-ensemble de cette interface est suffisant pour la prise en charge de SSM.


6.4 Rapport d’hôte et interrogateur IGMPv3/MLDv2


Afin d’utiliser le service SSM, un hôte d’extrémité doit être capable de spécifier une adresse de canal, consistant en l’adresse d’envoi individuel d’une source et en une adresse de destination SSM. IGMP version 2 [3] et MLD version 1 [19] permettent à un hôte d’extrémité de ne spécifier qu’une adresse de destination en diffusion groupée. La capacité à spécifier une adresse de canal SSM c est fournie par IGMP version 3 [3] et MLD version 2 [20]. Ces protocoles prennent en charge le "filtrage de source", c’est-à-dire, la capacité d’un système d’extrémité à exprimer son intérêt à recevoir des paquets de données envoyés seulement par des sources SPÉCIFIQUES, ou de TOUTES les sources SAUF certaines sources spécifiques. En fait, IGMPv3 fournit un sur-ensemble des capacités requises pour réaliser le modèle de service SSM.


Un exposé détaillé de l’utilisation d’IGMPv3 dans la gamme d’adresses de destination SSM figure dans [4].


Le protocole de découverte d’écoutant de diffusion groupée (MLD, Multicast Listener Discovery) utilisé par un routeur IPv6 pour découvrir la présence d’écoutants de diffusion groupée sur ses liaisons directement rattachées, et pour découvrir les adresses de diffusion groupée qui intéressent ces nœuds du voisinage. MLD version 1 est dérivé de IGMPv2 et ne fournit pas la capacité de filtrage de source exigée pour le modèle de service SSM. MLD version 2 est dérivé de IGMPv3, et fournit la même prise en charge du filtrage de source. Donc, IGMPv3 (ou MLDv2 pour IPv6) fournit à un hôte la capacité de demander au réseau un abonnement à un canal SSM.


6.5 Acheminement PIM-SSM


[9] fournit des lignes directrices sur la façon dont une mise en œuvre de PIM-SM devrait traiter les rapports d’hôtes spécifiques d’une source comme l’exige SSM. Les précédentes versions de la spécification du protocole PIM ne décrivaient pas comment faire cela.


Les exigences de routeur pour le fonctionnement dans la gamme de SSM sont détaillées dans [5]. Ces règles sont principalement destinées à empêcher un comportement de style ASM dans la gamme des adresses SSM. Afin de se conformer à [5], plusieurs changements au protocole PIM-SM sont nécessaires, comme décrit dans [9]. Les plus importants changements à PIM-SM exigés pour la conformité à [5] sont :

- lorsque un DR reçoit une demande (S,G) Joindre avec l’adresse G dans la gamme d’adresses SSM, il DOIT initier un (S,G) Joindre, et JAMAIS un (*,G) Joindre :

- les routeurs de cœur de réseau (c’est-à-dire, les routeurs qui n’ont pas d’hôte directement rattaché) NE DOIVENT PAS propager de (*,G) Joindre pour les adresses de groupe dans la gamme d’adresses SSM ;

- les points de rendez-vous (RP) NE DOIVENT PAS accepter de messages PIM Enregistrer ou de messages (*,G) Joindre dans la gamme d’adresses SSM.


Noter que seul un petit sous-ensemble de la pleine fonctionnalité du protocole PIM-SM est nécessaire pour la prise en charge du modèle de service SSM. Ce sous-ensemble est explicitement documenté dans [9].


7. Interopérabilité avec les modèles existants de service de diffusion groupée


L’interopérabilité avec ASM est une des questions les plus importantes dans le passage au déploiement de SSM, car les deux modèles sont supposés être utilisés au moins dans un futur prévisible. SSM est le SEUL modèle de service pour la gamme d’adresses SSM – le comportement de protocole correct pour cette gamme est spécifié dans [5]. Le modèle de service ASM sera offert pour la gamme d’adresses non SSM, où les receveurs peuvent produire des demandes (*,G) Joindre pour recevoir des données en diffusion groupée. Il est aussi permis à un receveur de produire une demande (S,G) Joindre dans la gamme d’adresses non SSM ; cependant, dans ce cas, il n’est pas garanti qu’il va recevoir un service conforme au modèle SSM.


Un autre problème d’interopérabilité concerne le protocole MSDP, qui est utilisé entre les points de rendez-vous PIM-SM pour découvrir les sources de diffusion groupée à travers plusieurs domaines. MSDP n’est pas nécessaire pour SSM, mais est nécessaire si ASM est pris en charge. [9] spécifie les recommandations opérationnelles pour aider à s’assurer que MSDP n’interfère pas avec la capacité d’un réseau à prendre en charge le modèle de service SSM. Précisément, [9] déclare que les points de rendez-vous ne doivent pas accepter, générer, ou transmettre de messages SA MSDP pour la gamme d’adresses SSM.


8. Considérations pour la sécurité


SSM n’introduit pas de nouvelles considérations sur la sécurité pour la diffusion groupée IP. Il peut aider à prévenir des attaques de déni de service résultant de la transmission de données par des sources indésirables à un canal de diffusion groupée (S, G). Cependant, aucune garantie n’est fournie.


9. Remerciements


Nous tenons à remercier Gene Bowen, Ed Kress, Bryan Lyles, Timothy Roscoe, Hugh Holbrook, Isidor Kouvelas, Tony Speakman et Nidhi Bhaskar pour leur participations aux longues discussions et au travail de conception sur SSM, et pour leurs réactions sur le présent document. Nos remerciements sont aussi dus à Mujahid Khan, Ted Seely, Tom Pusateri, Bill Fenner, Kevin Almeroth, Brian Levine, Brad Cain, Hugh LaMaster et Pekka Savola pour leur précieuse collaboration et leur soutien continu.


10. Références

10.1 Références pour information


[1] Holbrook, H. and D.R. Cheriton, "IP Multicast Channels: EXPRESS Support for Large-scale Single-Source Applications", dans Proceedings of SIGCOMM 1999.


[2] W. Fenner, "Protocole de gestion de groupe Internet, version 2", RFC2236, novembre 1997. (Obsolète, voir RFC3376)


[3] B. Cain et autres, "Protocole Internet de gestion de groupe, IGMP version 3", RFC3376, octobre 2002.


[4] H. Holbrook et autres, "Utilisation de la version 3 du protocole de gestion de groupe Internet (IGMPv3) et de la version 2 du protocole de découverte d'écoutant de diffusion groupée (MLDv2) pour la diffusion groupée spécifique de source", RFC4604, août 2006. (P.S.)


[5] H. Holbrook, B. Cain, "Diffusion groupée spécifique de source pour IP", RFC4607, août 2006. (P.S.)


[6] Deering, S. and D. Cheriton,"Multicast Routing in Datagram Networks and Extended LANs", ACM Transactions on Computer Systems, 8(2):85-110, mai 1990.


[7] Deering, S. et al., "PIM Architecture for Wide-Area Multicast Routing", IEEE/ACM Transaction on Networking, pages 153-162, avril 1996.


[8] D. Estrin et autres, "Mode épars de diffusion groupée indépendante du protocole (PIM-SM) : Spécification du protocole", RFC2362, juin 1998. (Obsolète, voir RFC4601, RFC5059)


[9] B. Fenner et autres, "Diffusion groupée indépendante du protocole - Mode épars (PIM-SM) : spécification du protocole (Révisée)", RFC4601, août 2006. (Remplace RFC2362) (MàJ par RFC5059) (P.S.)


[10] A. Adams et autres, "Diffusion groupée indépendante du protocole - Mode dense (PIM-DM) : Spécification du protocole (révisée)", RFC3973, janvier 2005. (Expérimentale)


[11] A. Ballardie, "Architecture d'acheminement de diffusion groupée d'arborescences fondées sur le cœur (CBT)", RFC2201, septembre 1997. (Historique)


[12] D. Meyer, "Diffusion groupée sur IP limitée administrativement", RFC2365, juillet 1998. (BCP0023)


[13] B. Fenner et D. Meyer, éd., "Protocole de découverte de source de diffusion groupée (MSDP)", RFC3618, octobre 2003. (Exp.)


[14] D. Thaler, M. Handley, D. Estrin, "Architecture d'allocation d'adresse de diffusion groupée Internet", RFC2908, septembre 2000. (Info.)


[15] Diot, C., Levine, B., Lyles, B., Kassem, H. and D. Balensiefen, "Deployment Issues for the IP Multicast Service and Architecture", Dans le numéro spécial de IEEE Networks Magazine sur Multicast, janvier 2000.


[16] D. Thaler, B. Fenner et B. Quinn, "Extensions d'interface de prise pour filtres de source en diffusion groupée", RFC3678, janvier 2004.


[17] D. Meyer, P. Lothberg, "Adressage GLOP dans 233/8", BCP0053, RFC3180, septembre 2001.


[18] Levine, B. et al., "Consideration of Receiver Interest for IP Multicast Delivery", In Proceedings of IEEE Infocom, mars 2000.


[19] S. Deering, W. Fenner et B. Haberman, "Découverte d'écouteur de diffusion groupée (MLD) pour IPv6", RFC2710, octobre 1999.


[20] R. Vida, L. Costa, éditeurs, "Découverte d'écouteur de diffusion groupée version 2 (MLDv2) pour IPv6", RFC3810, juin 2004.


[21] B. Haberman, D. Thaler, "Adresses de diffusion groupé IPv6 fondées sur des préfixes d'envoi individuel", RFC3306, août 2002. (MàJ par RFC3956, RFC4489) (P.S.)


[22] S. Kent et R. Atkinson, "Architecture de sécurité pour le protocole Internet", RFC2401, novembre 1998. (Obsolète, voir RFC4301)


[23] B. Haberman, "Lignes directrices pour l'allocation des adresses de diffusion groupée IPv6", RFC3307, août 2002. (P.S.)


[24] A. Ballardie, "Acheminement de diffusion groupée en arborescences fondées sur le cœur de réseau (CBT version 2)", RFC2189, septembre 1997. (Historique, voir RFC5110)


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


[26] T. Bates et autres, "Extensions multiprotocoles pour BGP-4", RFC2858, juin 2000. (Obsolète, voir RFC4760) (P.S.)


[27] D. Meyer, "Extension d'allocations dans 233/8", RFC3138, juin 2001. (Information) (Obsolète, voir RFC5771)


10.2 Références normatives


[28] S. Bradner, "Mots clés à utiliser dans les RFC pour indiquer les niveaux d'exigence", BCP 14, RFC2119, mars 1997.


11. Contributeurs


Christophe Diot

Leonard Giuliano

Greg Shepherd

Robert Rockell

Intel

Juniper Networks

Procket Networks

Sprint

mél : christophe.diot@intel.com

mél : lenny@juniper.net

mél : shep@procket.com

mél : rrockell@sprint.net


David Meyer

John Meylor

Brian Haberman

Sprint

Cisco Systems

Caspian Networks

mél : dmm@1-4-5.net

mél l: jmeylor@cisco.com

mél l: bkhabs@nc.rr.com


12. Adresse de l’éditeur


Supratik Bhattacharyya

Sprint

mél : supratik@sprintlabs.com


13. Déclaration complète de droits de reproduction


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


Ce document et les traductions de celui-ci peuvent être copiés et diffusés, et les travaux dérivés qui commentent ou expliquent autrement ou aident à sa mise en œuvre peuvent être préparés, copiés, publiés et distribués, partiellement ou en totalité, sans restriction d'aucune sorte, à condition que l'avis de droits de reproduction ci-dessus et ce paragraphe soit inclus sur toutes ces copies et œuvres dérivées. Toutefois, ce document lui-même ne peut être modifié en aucune façon, par exemple en supprimant le droit d'auteur ou les références à l'Internet Society ou d'autres organisations Internet, sauf si c'est nécessaire à l'élaboration des normes Internet, auquel cas les procédures pour les droits de reproduction définis dans les processus de normes pour Internet doivent être suivies, ou si nécessaire pour le traduire dans des langues autres que l'anglais.


Les permissions limitées accordées ci-dessus sont perpétuelles et ne seront pas révoquées par la Société Internet ou ses successeurs ou ayants droit.


Ce document et les renseignements qu'il contient sont fournis "TELS QUELS" et l'INTERNET SOCIETY et l'INTERNET ENGINEERING TASK FORCE déclinent toute garantie, expresse ou implicite, y compris mais sans s'y limiter, toute garantie que l'utilisation de l'information ici présente n'enfreindra aucun droit ou aucune garantie implicite de commercialisation ou d'adaptation a un objet particulier.


Remerciement

Le financement de la fonction d’édition des RFC est actuellement fourni par la Internet Society.