Groupe de travail Réseau

D. Thaler, Microsoft

Request for Comments : 2715

octobre 1999

Catégorie : Information

Traduction Claude Brière de L'Isle

 

 

Règles d'interopérabilité pour les protocoles d'acheminement de diffusion groupée

 

Statut de ce mémoire

Le présent mémoire donne des informations pour la communauté de l'Internet. Le présent mémoire ne contient aucune sorte de norme de l'Internet. La distribution de ce mémoire n'est soumise à aucune restriction.

 

Notice de copyright

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

 

Résumé

Les règles décrites dans le présent document permettront une interopération efficace entre plusieurs domaines d'acheminement de diffusion groupée indépendants. Les mises en œuvre spécifiques de ces règles sont données pour les protocoles d'acheminement DVMRP, MOSPF, PIM-DM, PIM-SM, et CBT, ainsi que pour les liaisons IGMP-seul. De futures versions de ces protocoles, et de tous autres protocoles d'acheminement de diffusion groupée, peuvent décrire leur procédure d'inter fonctionnement en établissant comment les règles décrites ci-après s'appliquent à eux.

 

1.   Introduction

 

Pour permettre aux sources et receveurs à l'intérieur de plusieurs domaines autonomes d'acheminement de diffusion groupée (ou "régions") de communiquer, les domaines doivent être connectés par des routeurs frontière de diffusion groupée (MBR, multicast border router). Pour empêcher les trous noirs ou boucles d'acheminement dans les domaines, on suppose que ces domaines sont organisés suivant une des topologies suivantes :

 

o   Une topologie en arborescence (ou en étoile) (figure 1) avec un domaine dorsal à la racine, des domaines d'extrémité aux feuilles, et éventuellement des domaines de "transit" comme branches entre la racine et les feuilles. Chaque paire de domaines adjacents est connectée par un ou plusieurs MBR. La racine de chaque sous-arbre des domaines reçoit tout le trafic à portée globale originaire de partout au sein du sous-arbre, et transmet le trafic à son parent et ses enfants lorsque nécessaire. Chaque MBR de domaine parent injecte un chemin par défaut dans les domaines fils, alors que les MBR des domaines fils injectent les chemins réels (mais éventuellement agrégés) dans les domaines parents. Et donc, les flèches de la figure indiquent à la fois la direction dans laquelle pointe le chemin par défaut, ainsi que la direction dans laquelle est envoyé tout le trafic à portée globale.

 

                                                               +--------+

                                                          +----|        |----+

                                    +---+      +---+      |  ====>     <==== |

                                    |   |      |   |      +----|    #   |----+

                                    |   |      | # |         +------#------+

                                    | # |    +---#-----------|      v   |-----------+

                                   +--#------|   v           | Domaine  |           |-----+

                                   |  v    ===>            ===> dorsal <===        <===   |

                                   +---------|   ^           | racine   |     ^     |-----+

                                             +---#---|       |     ^    |-----#-----+

                                             |   #   |       +-----#----+ |   #     |-----+

                                             |       |       |     #    | |         <===  |

                                             +-----+ +-------|          | |         |-----+

                                                     | ===>             | +--------+

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

 

Figure 1 : Arborescence de la topologie des domaines

 

o   Une topologie arbitraire, dans laquelle un protocole d'acheminement de niveau supérieur (inter-domaine), tel que HDVMRP [1] ou BGMP [9], est utilisée pour calculer les chemins parmi les domaines. Chaque paire de domaines adjacents est connectée par un ou plusieurs MBR.

 

La Section 2 décrit les règles qui permettent l'interopérabilité entre les protocoles d'acheminement en diffusion groupée existants [2,3,4,5,6], et réduit le problème de l'interopérabilité de O(N^2) interactions potentielles de protocole à juste N (une par protocole) instanciations du même ensemble de règles invariantes. Le présent document s'applique spécifiquement aux routeurs frontière de diffusion groupée (MBR, Multicast Border Router) qui satisfont aux hypothèses suivantes :

 

o   Le MBR comporte deux composants d'acheminement de diffusion groupée actifs, ou plus, chacun faisant fonctionner une instance d'un protocole d'acheminement en diffusion groupée. Aucune hypothèse n'est faite quant au type de protocole d'acheminement en diffusion groupée (par exemple, diffusion et élagage ou jonction explicite) qu'utilise chaque composant, ou sur la nature d'un "composant". Il est admis que plusieurs composants fonctionnent avec le même protocole.

 

o   Le routeur est configuré pour transmettre des paquets entre deux domaines indépendants ou plus. Le routeur a une ou plusieurs interfaces actives dans chaque domaine, et un composant par domaine. Le routeur a aussi un "répartiteur d'alerte" inter-composant, qui sera traité à la Section 3.

 

o   Un seul protocole d'acheminement en diffusion groupée est actif par interface (on ne prend pas en considération les LAN à protocole de diffusion groupée mixtes). Chaque interface sur laquelle la diffusion groupée est activée est donc "possédée" par exactement un des composants.

 

o   Tous les composants partagent une antémémoire de transmission commune de (S,G) entrées, qui sont créées lorsque les paquets de données sont reçus, et qui peuvent être supprimées à tout moment. Seul le composant qui possède une interface peut changer les informations sur cette interface dans l'antémémoire de transmission. Chaque entrée d'antémémoire de transmission a une seule interface entrante (iif) et une liste d'interfaces sortantes (oiflist). Chaque composant conserve normalement un tableau d'acheminement groupé séparé avec tous les types d'entrées.

 

Noter que les lignes directrices de ce document sont indépendantes de la mise en œuvre. Les mêmes règles données à la Section 2 s'appliquent de cette façon, sans considération de la mise en œuvre. Par exemple, elles s'appliquent à chacun des modèles architecturaux suivants :

o   Traitement unique (par exemple, GateD) : plusieurs composants d'acheminement dans le même traitement d'espace d'utilisateur, fonctionnant par dessus un noyau à capacité de diffusion groupée.

o   Plusieurs traitements d'homologues : plusieurs composants d'acheminement, chacun comme traitement séparé d'espace d'utilisateur, se situant tous par dessus un noyau à capacité de diffusion groupée, avec N*(N-1) canaux d'interaction.

o   Plusieurs traitements avec arbitre : plusieurs traitements de composant d'acheminement d'homologue indépendants qui interagissent les uns avec les autres et avec le noyau seulement à travers un démon d'arbitrage indépendant.

o   Monolithe : plusieurs composants d'acheminement qui font partie du "noyau" lui-même.

 

On décrit toutes les interactions entre composants en termes "d'alertes". La nature d'une alerte dépend de la mise en œuvre (par exemple, elle peut consister en un simple appel de fonction, écriture dans une mémoire partagée, utilisation de IPC, ou quelque autre méthode) mais des alertes d'une forme ou une autre existent dans chaque modèle. De même, l'origine d'une alerte est aussi dépendante de la mise en œuvre ; par exemple, les alertes peuvent être générées par un composant qui effectue un changement, par un arbitre indépendant, ou par le noyau.

 

1.1   Langage de spécification

 

Les mots clés "DOIT", "NE DOIT PAS", "EXIGE", "DEVRA", "NE DEVRA PAS", "DEVRAIT", "NE DEVRAIT PAS", "RECOMMANDE", "PEUT", et "FACULTATIF" dans le présent document sont à interpréter comme décrit dans la RFC 2119.

 

2.   Exigences

 

Pour s'assurer qu'un MBR qui s'en tient aux hypothèses ci-dessus affiche un comportement correct d'acheminement inter domaine, chaque composant de MBR DOIT adhérer aux règles suivantes :

 

Règle 1 :   Tous les composants doivent se mettre d'accord sur le composant qui possède l'interface entrante (iif) pour une entrée d'antémémoire de transmission. Ce composant, que nous appelons le "propriétaire iif" est déterminé par le répartiteur (voir la Section 3). Le composant entrant peut choisir TOUTE interface qu'il possède comme le iif conformément à ses propres règles.

 

Lorsque survient un changement d'acheminement qui cause le changement du iif pour une interface possédée par un composant différent, le composant qui possédait précédemment le iif de l'entrée et le composant qui possède maintenant le iif de l'entrée DOIVENT tous deux remarquer le changement (de sorte que le premier puisse élaguer vers l'amont et que le second puisse joindre/greffer l'amont, par exemple). Normalement, remarquer de tels changements vont se faire par suite d'un comportement de protocole normal.

 

Règle 2 :   Le composant qui possède une interface spécifie les critères selon lesquels les paquets reçus sur cette interface sont acceptés ou abandonnés (par exemple, s'il faut effectuer une vérification de RPF, et quelles limites de portée existent sur cette interface). Cependant, une fois qu'un paquet est accepté, il est traité conformément aux règles de transmission de tous les composants.

 

De plus, certains protocoles d'acheminement en diffusion groupée (par exemple. PIM) exigent aussi la capacité à réagir aux paquets reçus sur la "mauvaise" interface. Pour prendre en charge ces protocoles, un MBR doit permettre à un composant de placer chacune de ses interfaces en "WrongIf Alert Mode" (faux si mode d'alerte). Si un paquet arrive sur une telle interface, et s'il n'est pas accepté conformément à la règle 2, le composant qui possède l'interface DOIT alors être alerté [(S,G) alerte WrongIf]. Normalement, les alertes WrongIf doivent être limitées en débit.

 

Règle 3 :   Chaque fois qu'une nouvelle entrée d'antémémoire de transmission (S,G) doit être créée (par exemple, à l'acceptation d'un paquet destiné à un groupe non local), tous les composants DOIVENT être alertés [(S,G) alerte Creation] de sorte qu'ils puissent établir l'état de transmission sur leurs propres interfaces de sortie (oif) avant la transmission du paquet.

 

Noter que les alertes de création (S,G) ne sont pas nécessairement générées par un des composants de protocole eux-mêmes.

 

Règle 4 :   Lorsque un composant retire le dernier oif d'une entrée d'antémémoire de transmission (S,G) dont le iif est la propriété d'un autre composant, ou lorsque une telle entrée d'antémémoire de transmission (S,G) est créée avec une liste d'oif vide, le composant qui possède le iif DOIT être alerté [(S,G) alerte Prune] (afin qu'il puisse envoyer un élagage, par exemple).

 

Règle 5 :   Lorsque le premier oif est ajouté à une entrée d'antémémoire de transmission (S,G) dont le iif est possédé par un autre composant, le composant qui possède le iif DOIT être alerté [(S,G) alerte Join] (afin qu'il puisse envoyer un ordre de jonction ou de greffe, par exemple).

 

La liste des oif dans les règles 4 et 5 doit aussi inclure logiquement toute interface d'encapsulation virtuelle telle que celles utilisées pour le tunnelage ou pour l'envoi de paquets encapsulés à un RP/cœur.

 

Règle 6 :   Sauf si un composant rapporte qu'il est membre d'un groupe agrégé dans la direction de ses interfaces, il DOIT être un "receveur de caractères génériques" pour toutes les sources dont l'interface RPF est possédée par un autre composant (sources "atteintes en externe"). De plus, un composant DOIT être un "receveur de caractères génériques" pour toutes les sources dont l'interface RPF est possédée par ce composant (sources "atteintes en interne") si un quelconque autre composant du MBR est un receveur de caractères génériques pour les sources atteintes en externe ; cela va arriver naturellement par suite de la règle 5 lorsque elle reçoit une alerte (*,*) Join.

 

Par exemple, si le cœur de réseau ne conserve pas les informations sur les adhésions globales, tous les composants MBR dans le cœur de réseau avec une topologie arborescente des domaines, aussi bien que tous les composants qui possèdent l'interface RPF vers le cœur de réseau sont des receveurs de caractères génériques pour les sources atteintes en externe.

 

Les MBR n'ont pas besoin d'être des receveurs de caractères génériques (pour les source atteintes en interne ou en externe) si un protocole d'acheminement de niveau supérieur, tel que BGMP, est utilisé pour l'acheminement entre les domaines.

 

2.1   Suppression des entrées d'antémémoire de transmission

 

Un soin particulier doit être apporté au respect des règles 4 et 5 lorsque les entrées d'antémémoire de transmission peuvent être supprimées à volonté. En particulier, un composant doit être capable de déterminer quand la liste combinée d'oif pour (S,G) va de nul à non nul, et vice versa.

 

Cela peut être fait de toutes les façons spécifiques de la mise en œuvre, y compris, mais sans s'y limiter, les possibilités suivantes :

o   Chaque fois qu'un composant modifierait la liste oif d'une seule entrée d'antémémoire de transmission s'il en existait une, il en est d'abord créé une. La liste oif est alors modifiée et les règles 4 et 5 s'appliquent après que l'alerte (S,G) Creation est envoyée à tous les composants et que tous les composants ont mis à jour la oiflist. OU,

 

o   Lorsque une entrée d'antémémoire de transmission est à supprimer, une nouvelle alerte [(S,G) alerte Deletion] est envoyée à tous les composants, et l'entrée n'est supprimée que si tous les composants accordent alors leur permission. Chaque composant pourrait alors n'accorder sa permission que si il n'avait pas d'entrée de tableau d'acheminement (S,G).

 

2.2   Recommandation supplémentaire

 

L'utilisation des alertes (*,G) Join et (*,G) Prune peut réduire l'utilisation de bande passante en évitant le comportement de diffusion élagage dans les domaines lorsque il n'est pas nécessaire. Cette optimisation exige que chaque composant soit capable de déterminer quels autres composants sont intéressés à un groupe donné.

 

Bien que cela puisse être fait dans toute méthode qui dépende de la mise en œuvre, un exemple en serait d'entretenir un tableau commun (que nous appellerons tableau des composants de groupe) indexé par préfixe de groupe, faisant la liste des composants qui sont intéressés par chaque préfixe de groupe. Et donc, tout composant qui est receveur de caractères génériques pour les sources en externe (c'est-à-dire, celles dont l'interface RPF est possédée par un autre composant) figurerait dans la liste de toutes les entrées de ce tableau, y compris une entrée par défaut. Ce tableau est donc en gros analogue à une antémémoire de transmission de (*,G) entrées, sauf qu'aucune distinction n'est faite entre les interfaces entrantes et sortantes.

 

3.   Répartiteurs d'alertes

 

On suppose que chaque MBR a un "répartiteur d'alerte". Le répartiteur est chargé de choisir, pour chaque entrée (S,G) dans l'antémémoire de transmission partagée, le composant possesseur du iif. Il est aussi chargé de choisir à quel ou quels composants une alerte donnée devrait être envoyée.

 

3.1   Le répartiteur "Interop"

 

On décrit ici des règles qui peuvent être utilisées en l'absence de tout protocole d'acheminement de diffusion groupée inter-domaine, pour permettre l'interopérabilité dans une topologie arborescente de domaines. Si un protocole d'acheminement de diffusion groupée inter-domaine est utilisé, un autre répartiteur devrait être utilisé à sa place. Le répartiteur Interop ne possède aucune interface.

 

Pour choisir le iif d'une entrée (S,G), le possesseur du iif est le composant qui possède l'interface de prochain bond vers S dans le RIB de diffusion groupée.

 

Le "possesseur de iif" des entrées (*,G) et (*,*) est le répartiteur Interop lui-même. Cela permet au répartiteur Interop de recevoir les alertes pertinentes sans posséder aucune interface.

 

3.1.1   Traitement des alertes

Si le répartiteur Interop reçoit une alerte (S,G) Creation , il n'ajoute aucune interface à la liste des oif de l'entrée, car il n'en possède aucune.

 

Lorsque le répartiteur Interop reçoit une alerte (*,G) Prune, les actions suivantes sont entreprises, selon le nombre N de composants qui veulent recevoir des données pour G. Si N a juste changé de 2 à 1, une alerte (*,G) Prune est envoyée au composant restant. Si N a juste changé de 1 à 0, une alerte (*,G) Prune est envoyée à TOUS les composants autres que le 1.

 

Lorsque le répartiteur Interop reçoit une alerte (*,G) Join, les actions suivantes sont entreprises, selon le nombre N de composants qui veulent recevoir des données pour G. Si N a juste changé de 0 à 1, une alerte (*,G) Join est envoyée à TOUS les composants autres que le 1. Si N a juste changé de 1 à 2, une alerte (*,G) est envoyée au composant (1) d'origine.

 

3.2   Répartiteur "BGMP"

 

Ce répartiteur peut être utilisé avec un protocole d'acheminement de diffusion groupée inter-domaine (tel que BGMP) qui permet les arborescences (S,G) et (*,G) globales.

 

Le possesseur de l'iif d'une entrée (S,G) est le composant qui possède l'interface de prochain bond vers S dans le RIB de diffusion groupée.

 

Le possesseur de l'iif d'une entrée (*,G) est le composant qui possède l'interface de prochain bond vers G dans le RIB de diffusion groupée.

 

3.2.1   Traitement des alertes

Ce répartiteur transmet simplement toutes les alertes (S,G) et (*,G) au possesseur de l'iif de l'entrée associée.

 

4.   Composants de protocole d'acheminement de diffusion groupée

 

Dans cette section, on décrit comment s'appliquent les règles de la section 2 aux versions actuelles de divers protocoles. Les futures versions, et les protocoles supplémentaires, devraient décrire comment ces règles s'appliquent dans un document distinct.

 

4.1   DVMRP

 

Ce paragraphe décrit comment les règles de la section 2 s'appliquent à DVMRP. On suppose que le lecteur est familiarisé avec le comportement DVMRP normal tel que spécifié dans [2].

 

Comme avec tous les protocoles de diffusion/élagage, les composants DVMRP sont des receveurs automatiques de caractères génériques pour les sources atteintes en interne. Sauf si sont ajoutées à l'avenir à DVMRP certaines formes de rapports sur l'ensemble du domaine (DWR, Domain-Wide-Report) [10] (synonyme des rapports d'adhésion régionaux décrits dans [1]), tous les composants DVMRP agissent aussi comme receveurs de caractères génériques pour les sources atteintes en externe. Si les DWR sont disponibles pour le domaine, un composant DVMRP n'agit alors comme receveur de caractères génériques pour les sources atteintes en externe que si il existe des domaines atteints en interne qui ne prennent pas en charge certaines formes de DWR.

 

Une heuristique simple pour approximer les DWR est de supposer que si il y a des membres atteints en interne, au moins un d'eux est alors un envoyeur. Avec cette heuristique, la présence de tout état (S,G) pour des sources atteintes en interne peut être utilisée à la place. L'envoi d'un paquet de données à un groupe est alors équivalent à l'envoi d'un DWR pour le groupe.

 

4.1.1   Génération des alertes

Une alerte (*,*) Join est envoyée au possesseur de l'iif de l'entrée (*,*) (par exemple, le répartiteur Interop) lorsque le premier composant devient un receveur de caractères génériques pour les sources externes. Cela peut survenir lorsque un composant DVMRP débute et qu'il ne prend pas en charge certaine forme des DWR.

 

Une alerte (*,*) Prune est envoyée au possesseur de l'iif de l'entrée (*,*) (par exemple, le répartiteur Interop) lorsque tous les composants ne sont plus des receveurs de caractères génériques pour les sources externes. Cela peut survenir lorsque un composant DVMRP qui ne prend pas en charge certaine forme des DWR ferme.

 

Une alerte (S,G) Prune est envoyée au composant qui possède le iif pour une entrée d'antémémoire de transmission chaque fois que le dernier oif est retiré de l'entrée, et que le iif est possédé par un autre composant. Dans DVMRP, cela peut arriver lorsque un message DVMRP (S,G) Prune est reçu sur l'interface logique.

 

Une alerte (S,G) Join est envoyée au composant qui possède le iif pour une entrée d'antémémoire de transmission chaque fois que le premier oif logique est ajouté à une entrée, et que le iif est possédé par un autre composant. Dans DVMRP, cela peut arriver lorsque l'un des événements suivants survient :

o   le temporisateur d'élagage de l'oif arrive à expiration,

o   un message DVMRP (S,G) Graft est reçu sur l'interface logique,

o   IGMP [7] notifie à DVMRP que des membres connectés directement de G existent maintenant sur l'interface.

 

Quand il est connu, pour un groupe G, qu'il n'y a plus aucun membre dans le domaine DVMRP qui reçoit des données pour des sources atteintes en externe à partir du routeur local, une alerte (*,G) Prune est envoyée au "possesseur de l'iif" pour (*,G) conformément au répartiteur. Dans DVMRP, cela peut survenir lorsque :

o   le DWR pour G arrive en fin de temporisation,

o   l'approximation des membres qui sont envoyeurs est utilisée et que la dernière entrée (S,G) pour G est arrivée en fin de temporisation.

 

Lorsque il est su pour la première fois qu'il y a des membres d'un groupe G dans le domaine DVMRP, une alerte (*,G) Join est envoyée au "possesseur de l'iif" de (*,G). Dans DVMRP, cela peut arriver lorsque survient un des événements suivants :

o   un DWR est reçu pour G,

o   l'approximation des membres qui sont envoyeurs est utilisée et un paquet de données est reçu pour G sur une des interfaces du composant.

 

4.1.2   Traitement des alertes

Lorsque un composant DVMRP reçoit une alerte (S,G) Creation, il ajoute toutes les interfaces du composant à la liste de oif de l'entrée (conformément au comportement normal DVMRP) EXCEPTÉ :

o   le iif,

o   les interfaces sans membres locaux du groupe de l'entrée, et pour lesquels les messages DVMRP (S,G) Prune ont été reçus de tous les voisins dépendants vers l'aval,

o   les interfaces pour lesquelles le routeur n'est pas le transmetteur désigné pour S,

o   et les interfaces avec des limites de portée qui couvrent le groupe.

 

Lorsque un composant DVMRP reçoit une alerte (S,G) Prune, et que la liste d'oif de l'entrée d'antémémoire de transmission est vide, il envoie un message DVMRP (S,G) Prune au voisin amont, conformément au comportement normal DVMRP.

 

Lorsque un composant DVMRP reçoit une alerte (*,G) ou (*,*) Prune, elle est traitée comme si une alerte (S,G) Prune avait été reçue pour chaque entrée DVMRP (S,G) existante couverte. De plus, si les DWR sont utilisés, un message DWR Leave est envoyé au sein de son domaine.

 

Lorsque un composant DVMRP reçoit une alerte (S,G) Join, et qu'un élagage avait été envoyé précédemment vers l'amont, il envoie un message DVMRP (S,G) Graft au voisin amont conformément au comportement normal DVMRP.

 

Lorsque un composant DVMRP reçoit une alerte (*,G) ou (*,*) Join, elle est traitée comme si une alerte (S,G) Join était reçue pour chaque entrée DVMRP (S,G) existante couverte. De plus, si les DWR sont utilisés, le composant envoie un message DWR Join au sein de son domaine.

 

4.2   MOSPF

 

Ce paragraphe décrit comment les règles de la section 2 s'appliquent à MOSPF. On suppose que le lecteur est familiarisé avec le comportement MOSPF normal tel que spécifié dans [3]. Noter que MOSPF permet la jonction et l'élagage de groupes entiers, mais pas de sources individuelles au sein des groupes.

 

Bien que l'interopérabilité entre MOSPF et les protocoles en mode dense (tels que DVMRP) soit spécifiée dans [3], on décrit ici comment une mise en œuvre MOSPF peut inter fonctionner avec tous les autres protocoles d'acheminement en diffusion groupée.

 

Un composant MOSPF agit comme un receveur de caractères génériques pour les sources atteintes en interne si et seulement si tout autre composant est un receveur de caractères génériques pour les sources atteintes en externe. Un composant MOSPF n'agit comme un receveur de caractères génériques pour les sources atteintes en externe que si il existe des domaines atteints en interne qui ne prennent pas en charge certaine forme de rapport sur l'ensemble du domaine (DWR) [10]. Comme MOSPF diffuse les informations d'adhésion sur tout le domaine, MOSPF est considéré comme prenant lui-même en charge par nature une forme de DWR.

 

4.2.1   Génération des alertes

Une alerte (*,*) Join est envoyée au possesseur du iif de l'entrée (*,*) (par exemple, le répartiteur Interop) lorsque le premier composant devient un receveur de caractères génériques pour les sources externes. Cela peut survenir lorsque un composant MOSPF démarre et décide de jouer ce rôle.

 

Une alerte (*,*) Prune est envoyée au possesseur du iif de l'entrée (*,*) (par exemple, le répartiteur Interop) lorsque tous les composants ne sont plus des receveurs de caractères génériques pour les sources externes. Cela peut survenir lorsque un composant MOSPF qui jouait ce rôle ferme.

 

Lorsqu'il est connu qu'il n'y a plus aucun membres d'un groupe G dans le domaine MOSPF, une alerte (*,G) Prune est envoyée au "possesseur du iif" pour (*,G) conformément au répartiteur. Dans MOSPF, cela peut arriver lorsque :

o   IGMP notifie à MOSPF qu'il n'y a plus aucun membre du groupe qui soit directement connecté sur une interface, ou

o   un LSA d'adhésion de groupe du routeur pour G est périmé.

 

Lorsque il est su pour la première fois qu'il y a des membres d'un groupe G dans le domaine MOSPF, une alerte (*,G) Join est envoyée au "possesseur de l'iif" de (*,G). Dans MOSPF, cela peut arriver lorsque l'un des événements suivants survient :

o   IGMP notifie à MOSPF qu'il existe maintenant des membres du groupe directement connectés sur l'interface, ou

o   un LSA d'adhésion de groupe est reçu pour G.

 

4.2.2   Traitement des alertes

Lorsque un composant MOSPF reçoit une alerte (S,G) Creation, il calcule l'arbre de plus court chemin pour le domaine MOSPF, et ajoute les interfaces vers l'aval à la liste des oif de l'entrée conformément au comportement MOSPF normal.

 

Lorsque un composant MOSPF reçoit une alerte (S,G) Prune, l'alerte est ignorée, car MOSPF peut seulement élaguer des groupes entiers à la fois.

 

Lorsque un composant MOSPF reçoit une alerte (*,G) Prune, et qu'il n'y a pas de membre directement connecté sur l'interface MOSPF, le routeur "périme prématurément" son LSA d'adhésion de groupe pour G dans le domaine MOSPF conformément au comportement MOSPF normal.

 

Lorsque un composant MOSPF reçoit une alerte (S,G) Join ou une alerte (*,G) Join, et que G n'a pas été précédemment inclus dans le LSA d'adhésion de groupe du routeur (et que le composant n'est pas un receveur de diffusion groupée à caractères génériques), il génère un LSA d'adhésion de groupe dans le domaine MOSPF conformément au comportement MOSPF normal.

 

Lorsque un composant MOSPF reçoit une alerte (*,*) Prune, il cesse d'être un receveur de diffusion groupée à caractères génériques dans son domaine.

 

Lorsque un composant MOSPF reçoit une alerte (*,*) Join, il devient un receveur de diffusion groupée à caractères génériques dans son domaine.

 

4.3   PIM-DM

 

Ce paragraphe décrit comment les règles de la section 2 s'appliquent au PIM en mode dense. On suppose que le lecteur est familiarisé avec le comportement PIM-DM normal tel que spécifié dans [6].

 

Comme avec tous les protocoles de diffusion et élagage, les composants PIM-DM sont des receveurs automatiques de caractères génériques pour les sources atteintes en interne. Sauf si des formes de rapport sur l'ensemble du domaine (DWR) [10] sont ajoutées à l'avenir à PIM-DM, tous les composants PIM-DM agissent aussi comme receveurs de caractères génériques pour les sources atteintes en externe. Si des DWR sont disponibles pour le domaine, un composant PIM-DM n'agit comme receveur de caractères génériques pour les sources atteintes en externe que si il existe des domaines atteints en interne qui ne prennent pas en charge certaine forme des DWR.

 

Une heuristique simple pour approximer les DWR est de supposer que si il y a des membres atteints en interne, au moins un d'entre eux est alors un envoyeur. Avec cette heuristique, la présence de tout état (S,G) pour des sources atteintes en interne peut être utilisée à la place. L'envoi d'un paquet de données à un groupe est alors équivalent à l'envoi d'un DWR pour le groupe.

 

4.3.1   Génération des alertes

Une alerte (*,*) Join est envoyée au possesseur du iif de l'entrée (*,*) (par exemple, le répartiteur Interop) lorsque le premier composant devient un receveur de caractères génériques pour les sources externes. Cela peut arriver lorsque un composant PIM-DM démarre et qu'il ne prend pas en charge certaine forme des DWR.

 

Une alerte (*,*) Prune est envoyée au possesseur du iif de l'entrée (*,*) (par exemple, le répartiteur Interop) lorsque tous les composants ne sont plus des receveurs de caractères génériques pour les sources externes. Cela peut arriver lorsque un composant PIM- DM qui ne prend pas en charge certaine forme des DWR ferme.

 

Une alerte (S,G) Prune est envoyée au composant qui possède le iif pour une entrée d'antémémoire de transmission chaque fois que le dernier oif est retiré de l'entrée d'antémémoire de transmission, et que le iif est possédé par un autre composant. Dans PIM-DM, cela peut arriver lorsque :

o   un message PIM (S,G) Join/Prune avec S dans la liste d'élagage est reçu sur une interface point à point,

o   le temporisateur d'oif dans une entrée de tableau d'acheminement (S,G) arrive à expiration,

o   un message PIM (S,G) Assert provenant d'un voisin préféré est reçu sur l'interface.

 

Une alerte (S,G) Join est envoyée au composant qui possède le iif pour une entrée d'antémémoire de transmission chaque fois que le premier oif est ajouté à une entrée, et que le iif est possédé par un autre composant. Dans PIM-DM, cela peut arriver quand l'un des événements suivants survient :

o   le temporisateur d'élagage de l'oif arrive à expiration, ou

o   un message PIM-DM (S,G) Graft est reçu sur l'interface, ou

o   IGMP notifie à PIM-DM qu'il existe maintenant des membres du groupe directement connectés sur l'interface.

 

Lorsque il est su qu'il n'y a plus aucun membre d'un groupe G dans le domaine PIM-DM qui reçoive des données pour des sources atteintes en externe à partir du routeur local, une alerte (*,G) Prune est envoyée au "possesseur de l'iif" pour (*,G) conformément au répartiteur. Dans PIM-DM, cela peut arriver lorsque :

o   le DWR pour G arrive à expiration,

o   l'approximation des membres qui envoient est utilisée et la dernière entrée (S,G) de PIM-DM arrive en fin de temporisation.

 

Lorsque il est su pour la première fois qu'il y a des membres d'un groupe G dans le domaine PIM-DM, une alerte (*,G) Join est envoyée au "possesseur du iif" de (*,G), conformément au répartiteur. Dans PIM-DM, cela peut arriver lorsque l'un des événements suivants survient :

o   un DWR est reçu pour G,

o   l'approximation des membres qui envoient est utilisée et un paquet de données pour G est reçu dans une des interfaces du composant.

 

4.3.2   Traitement des alertes

Lorsque un composant PIM-DM reçoit une alerte (S,G) Creation, il ajoute les interfaces du composant à la liste des oif de l'entrée (conformément au comportement PIM-DM normal) EXCEPTÉ :

o   le iif,

o   les réseaux d'extrémité sans membres locaux dans le groupe de l'entrée,

o   et les interfaces avec des limites de portée qui couvrent le groupe.

 

Lorsque un composant PIM-DM reçoit une alerte (S,G) Prune, et lorsque la liste des oif de l'entrée d'antémémoire de transmission est vide, il envoie un message PIM-DM (S,G) Prune au voisin amont conformément au comportement PIM-DM normal.

 

Lorsque un composant PIM-DM reçoit une alerte (*,G) ou (*,*) Prune, elle est traitée comme si une alerte (S,G) Prune était reçue pour chaque entrée (S,G) correspondante.

 

Lorsque un composant PIM-DM reçoit une alerte (S,G) Join, et qu'une alerte (S,G) Prune avait été précédemment envoyée vers l'amont, il envoie un message PIM-DM (S,G) Graft au voisin amont conformément au comportement PIM-DM normal.

 

Lorsque un composant PIM-DM reçoit une alerte (*,G) ou (*,*) Join, pour chaque entrée (S,G) correspondante dans le tableau d'acheminement PIM-DM pour laquelle un élagage avait été envoyé précédemment vers l'amont, il envoie alors un message PIM-DM (S,G) Graft au voisin amont conformément au comportement PIM-DM normal. De plus, si les DWR sont utilisés, le composant envoie un message DWR Join au sein de son domaine.

 

4.4   PIM-SM

 

Dans ce paragraphe on décrit comment les règles de la Section 2 s'appliquent au mode épars de PIM. On suppose que le lecteur est familiarisé avec le comportement PIM-SM normal, comme spécifié dans [4].

 

Pour réaliser un comportement PIM-SM correct au sein du domaine, le domaine PIM-SM DOIT être convexe de telle sorte que les messages Bootstrap atteignent tous les routeurs dans le domaine. C'est-à-dire que le plus court chemin de tout routeur interne vers tout autre routeur interne doit tenir entièrement au sein du domaine PIM.

 

Sauf si certaines formes de rapports sur l'ensemble du domaine (DWR) [10] sont ajoutées à l'avenir à PIM-SM, tous les composants PIM-SM agissent comme des receveurs de caractères génériques pour les sources atteintes en externe. Si les DWR sont disponibles pour le domaine, un composant PIM-SM n'agit alors comme receveur de caractères génériques pour les sources atteintes en externe que si il existe des domaines atteints en interne qui ne prennent pas en charge certaines formes de DWR.

 

Un composant PIM-SM agit comme receveur de caractères génériques pour les sources atteintes en interne si et seulement si un autre composant quelconque est un receveur de caractères génériques pour les sources atteintes en externe. Il fait cela en envoyant périodiquement des (*,*,RP) Join à tous les RP pour les groupes non locaux (par exemple, 239.x.x.x est considéré comme à portée locale, et les composants PIM-SM n'envoient pas de (*,*,RP) Join aux RP qui ne prennent en charge que cette portion de l'espace d'adresse). La période est réglée conformément aux règles PIM-SM standard pour les messages Join/Prune périodiques.

 

Pour appliquer correctement la règle 1, chaque fois que PIM crée une entrée PIM (S,G) pour une source atteinte en externe, et que le prochain bond vers S est atteint via une interface possédée par un autre composant, le iif devrait toujours pointer vers S et non vers le RP pour G. De plus, le bit frontière est mis dans tous les messages PIM Register pour cette entrée.

 

Finalement, le composant PIM-SM agit comme un DR pour les receveurs atteints en externe au sens d'être capable de passer à l'arbre de plus court chemin pour les sources atteintes en interne.

 

4.4.1   Génération des alertes

Une alerte (*,*) Join est envoyée au possesseur de iif de l'entrée (*,*) (par exemple, le répartiteur Interop) lorsque le premier composant devient un receveur de caractères génériques pour les sources externes. Cela peut survenir lorsque un composant PIM-SM démarre et décide d'agir dans ce rôle.

 

Une alerte (*,*) Prune est envoyée au possesseur de l'iif de l'entrée (*,*) (par exemple, le répartiteur Interop) lorsque tous les composants ne sont plus des receveurs de caractères génériques pour les sources externes. Cela peut survenir lorsque un composant PIM-SM qui tenait ce rôle ferme.

 

Une alerte (S,G) Prune est envoyée au composant qui possède le iif pour une entrée d'antémémoire de transmission chaque fois que le dernier oif est retiré de l'entrée et que le iif est possédé par un autre composant. Dans PIM-SM, cela peut arriver lorsque :

o   un message PIM (S,G) Join/Prune avec S dans la liste d'élagage est reçu sur une interface point à point,

o   un message PIM (S,G) Assert provenant d'un voisin préféré a été reçu sur l'interface,

o   un message PIM Register-Stop est reçu pour (S,G),

o   le temporisateur d'oif de l'interface pour l'entrée de tableau d'acheminement (S,G) de PIM arrive à expiration,

o   le temporisateur d'entrée pour l'entrée de tableau d'acheminement (S,G) de PIM arrive à expiration.

 

Quand il est su qu'il n'y a plus aucun membre d'un groupe G dans le domaine PIM-SM qui reçoive des données pour des sources atteintes en externe à partir du routeur local, une alerte (*,G) Prune est envoyée au "possesseur de l'iif" pour (*,G) conformément au répartiteur. Dans PIM-SM, cela peut arriver lorsque :

o   un message PIM (S,G) Join/Prune avec G dans la liste d'élagage est reçu sur une interface point à point,

o   un message PIM (*,G) Assert provenant d'un voisin préféré a été reçu sur l'interface,

o   IGMP notifie à PIM-SM qu'il n'existe plus de membre directement connecté sur l'interface,

o   le temporisateur d'entrée pour l'entrée de tableau d'acheminement (*,G) de PIM arrive à expiration.

 

Une alerte (S,G) Join est envoyée au composant qui possède le iif pour une entrée d'antémémoire de transmission chaque fois que le premier oif logique est ajouté à une entrée et que l'iif est possédé par un autre composant. Dans PIM-SM, cela peut arriver lorsque un des événements suivant survient :

o   un message PIM (S,G) Join/Prune est reçu sur l'interface,

o   le temporisateur Register-Suppression pour (S,G) arrive à expiration,

o   le temporisateur d'entrée pour une entrée de tableau d'acheminement d'état d'antémémoire négative de (S,G) arrive à expiration.

 

Lorsque il est su pour la première fois qu'il y a des membres d'un groupe G dans le domaine PIM-SM, une alerte (*,G) Join est envoyée au "possesseur de l'iif" de (*,G), conformément au répartiteur. Dans PIM-SM, cela peut arriver lorsque l'un des événements suivants se produit :

o   un message PIM (*,G) Join/Prune est reçu sur l'interface,

o   un message PIM (*,*,RP) Join/Prune est reçu sur l'interface,

o   l'état d'antémémoire négative de (*,G) arrive à expiration,

o   IGMP notifie à PIM qu'il existe maintenant des membres du groupe directement connectés sur l'interface.

 

4.4.2   Traitement des alertes

Lorsque un composant PIM-SM reçoit une alerte (S,G) Creation, il fait une recherche de plus longue correspondance ((S,G), puis (*,G), puis (*,*,RP)) dans son tableau d'acheminement de diffusion groupée. Toutes les interfaces sortantes de cette entrée sont alors ajoutées à l'entrée d'antémémoire de transmission. Sauf si le composant PIM-SM possède le iif, la liste des oif est aussi modifiée pour prendre en charge l'envoi des PIM Register avec le bit frontière mis au RP correspondant.

 

Lorsque un composant PIM-SM reçoit une alerte (S,G) et que la liste d'oif de l'entrée d'antémémoire de transmission est vide, pour chaque entrée d'état PIM (S,G) couverte, il envoie un message (S,G) Join/Prune avec S dans la liste des élagages au voisin amont conformément au comportement PIM-SM normal.

 

Lorsque un composant PIM-SM reçoit une alerte (*,G) Prune, il envoie un message (*,G) Join/Prune avec G dans la liste des élagages au voisin amont vers le RP pour G, conformément au comportement PIM-SM normal.

 

Lorsque un composant PIM-SM reçoit une alerte (S,G) Join, il envoie un message (S,G) Join/Prune au voisin de prochain bond vers S, et remet à zéro le temporisateur d'entrée (S,G), conformément au comportement PIM-SM normal.

 

Lorsque un composant PIM-SM reçoit une alerte (*,G) Join, il envoie alors un message (*,G) Join/Prune au voisin de prochain bond vers le RP pour G, et remet à zéro le temporisateur d'entrée (S,G), conformément au comportement PIM-SM normal.

 

Lorsque un composant PIM-SM reçoit une alerte (*,*) Join, il envoie alors des messages (*,*,RP) Join/Prune vers chaque RP.

 

Lorsque un composant PIM-SM reçoit une alerte (*,*) Prune, il envoie alors un message (*,*,RP) Prune vers chaque RP.

 

4.5   CBTv2

 

Ce paragraphe décrit comment les règles de la Section 2 s'appliquent à CBTv2. On suppose que le lecteur est familiarisé avec le comportement CBTv2 normal tel que spécifié dans [5]. On notera que, comme MOSPF, CBTv2 permet de rejoindre et d'élaguer des groupes entiers, mais pas de sources individuelles au sein des groupes.

 

L'interopérabilité entre un seul domaine CBTv2 de bout et un réseau dorsal DVMRP est exposée dans [8]. En bref, les composants MBR de CBTv2 sont configurés de façon statique de telle façon que chaque fois qu'existe un chemin externe entre deux MBR ou plus, l'un d'eux soit désigné comme étant le principal, et les autres agissent comme sauvegardes non transmetteuses (pour empêcher la duplication des paquets). Et donc, un domaine CBTv2 ne doit pas servir comme transit entre deux domaines si il existe un autre chemin entre eux.

 

On va maintenant décrire comment une mise en œuvre de CBTv2 peut étendre cela pour interopérer avec tous les autres protocoles d'acheminement en diffusion groupée. Un composant CBTv2 n'agit comme receveur de caractères génériques pour les sources atteintes en interne que si et seulement si un autre composant quelconque est un receveur de caractères génériques pour les sources atteintes en externe. Il le fait en envoyant des JOIN-REQUEST pour toutes les gammes de groupes non locaux à tous les cœurs connus, comme décrit dans [8].

 

Sauf si certaines formes de rapports sur l'ensemble du domaine (DWR) [10] sont ajoutées à l'avenir à CBTv2, tous les composants CBTv2 agissent comme des receveurs de caractères génériques pour les sources atteintes en externe. Si les DWR sont disponibles pour le domaine, un composant CBTv2 n'agit alors comme receveur de caractères génériques pour les sources atteintes en externe que si il existe des domaines atteints en interne qui ne prennent pas en charge certaines formes de DWR.

 

4.5.1   Génération des alertes

Une alerte (*,*) Join est envoyée au possesseur de l'iif de l'entrée (*,*) (par exemple, le répartiteur Interop) lorsque le premier composant devient un receveur de caractères génériques pour les sources externes. Cela peut survenir lorsque un composant PIM-SM démarre et décide de jouer ce rôle.

 

Une alerte (*,*) Prune est envoyée au possesseur de l'iif de l'entrée (*,*) (par exemple, le répartiteur Interop) lorsque aucun composant n'est plus receveur de caractères génériques pour les sources externes. Cela peut survenir lorsque un composant PIM- SM qui jouait ce rôle ferme.

 

Lorsque le dernier oif est retiré de l'arbre central pour G, une alerte (*,G) Prune est envoyée au "possesseur de l'iif" pour (*,G) conformément au répartiteur. Comme CBTv2 envoie toujours toutes les données au cœur, le seul moment où cela peut arriver après la création de l'entrée est quand le MBR est le cœur. Dans ce cas, le dernier oif est retiré de l'entrée quand :

o   une QUIT-REQUEST est reçue sur l'interface logique, et qu'il n'y a pas de membres directement connectés présents sur l'interface, ou que

o   IGMP notifie à CBT qu'il n'y a plus de membre directement connecté présent sur l'interface, et que l'interface n'est pas une interface CBT fille pour le groupe G.

 

Lorsque la première interface CBT sortante est ajoutée à un arbre cœur existant, une alerte (*,G) Join est envoyée au "possesseur de l'iif" de (*,G) conformément au répartiteur. Comme CBTv2 envoie toujours toutes les données au cœur, le seul moment ou cela peut se produire, autre que lors de la création de l'entrée, est lorsque le MBR est le cœur. Dans ce cas, le premier oif logique est ajouté à une entrée quand :

o   une JOIN-REQUEST pour G est reçue sur l'interface, ou que

o   IGMP notifie à CBT qu'il existe maintenant des membres du groupe qui sont directement connectés sur l'interface.

 

4.5.2   Traitement des alertes

Lorsque un composant CBTv2 reçoit une alerte (S,G) Creation, et que le routeur fonctionne comme BR désigné, toutes les interfaces de CBT qui sont sur l'arbre pour G sont ajoutées à la liste des oif de l'entrée d'antémémoire de transmission (conformément au comportement CBTv2 normal).

 

Lorsque un composant CBTv2 reçoit une alerte (S,G) Prune, l'alerte est ignorée, car CBTv2 ne peut pas élaguer une source spécifique. Et donc, il va continuer de recevoir des paquets de S car il doit recevoir les paquets des autres sources dans le groupe G.

 

Lorsque un composant CBTv2 reçoit une alerte (*,G) Prune, et que le routeur n'est pas le cœur principal pour G, et que la seule interface de CBT sur l'arbre est l'interface vers le cœur, il envoie une QUIT-REQUEST au voisin du prochain bond vers le cœur, conformément au comportement CBTv2 normal.

 

Lorsque un composant CBTv2 reçoit une alerte (S,G) Join ou une alerte (*,G) Join, et que le routeur n'est pas le cœur principal pour G, et si le routeur n'est pas déjà l'arbre cœur pour G, il envoie une (*,G) JOIN-REQUEST CBT au voisin de prochain bond vers le cœur, conformément au comportement CBTv2 normal.

 

4.6   Liaisons IGMP seul

 

Ce paragraphe décrit comment les règles de la Section 2 s'appliquent à une liaison qui n'est pas au sein d'un domaine d'acheminement, et donc aucun message de protocole d'acheminement n'est échangé et l'interface n'est possédée par aucun composant de protocole d'acheminement de diffusion groupée. On suppose que le lecteur est familiarisé avec le comportement IGMP normal spécifié dans [7]. On notera que IGMPv2 permet la jonction et l'élagage de groupes entiers, mais pas de sources individuelles au sein des groupes.

 

Un "composant" IGMP seul ne peut posséder qu'une seule interface ; et donc un domaine IGMP seul ne consiste qu'en une seule liaison. Comme un composant IGMP seul ne peut agir que comme receveur de caractères génériques pour les sources atteintes en interne si toutes les sources atteintes en interne sont directement connectées, soit le domaine IGMP seul (la liaison) doit être un domaine de bout, soit alors il doit y avoir d'autres composants qui sont des receveurs de caractères génériques pour les sources atteintes en externe.

 

4.6.1   Génération des alertes

Quand il est su qu'il n'y a plus aucun membre directement connecté d'un groupe G sur l'interface IGMP seul, une alerte (*,G) Prune est envoyée au "possesseur de l'iif" pour (*,G) conformément au répartiteur. Dans IGMP, cela peut arriver lorsque l'adhésion de groupe arrive en fin de temporisation.

 

Quand il est su pour la première fois qu'il y a des membres directement connectés d'un groupe G sur l'interface, une alerte (*,G) Join est envoyée au "possesseur de l'iif" de (*,G), conformément au répartiteur. Dans IGMP, cela peut arriver lorsque un rapport d'adhésion est reçu pour G.

 

4.6.2   Traitement des alertes

Quand un composant IGMP seul reçoit une alerte (S,G) Creation, et qu'il y a des membres directement connectés de G présents sur son interface, il ajoute l'interface à la liste des oif de l'entrée.

 

Quand un composant IGMP seul reçoit une alerte (S,G) Prune, l'alerte est ignorée, car IGMP peut seulement élaguer un groupe entier à la fois.

 

Quand un composant IGMP seul reçoit une alerte (*,G) Prune, le routeur quitte le groupe G, en envoyant un message IGMP Leave si il était le dernier fournisseur de rapport, conformément au comportement IGMPv2 normal.

 

Quand un composant IGMP seul reçoit une alerte (*,*) Prune, il quitte le mode de diffusion groupée en promiscuité.

 

Quand un composant IGMP seul reçoit une alerte (S,G) Join ou une alerte (*,G) Join, et qu'il n'était pas précédemment membre de G sur l'interface IGMP seul (et que le composant n'est pas un receveur de caractères génériques pour les sources atteintes en interne), il rejoint le groupe sur l'interface, lui faisant envoyer un rapport d'adhésion non sollicitée conformément au comportement IGMPv2 normal.

 

Quand un composant IGMP seul reçoit une alerte (*,*) Join, il entre dans le mode de diffusion groupée en promiscuité.

 

5.   Considérations pour la sécurité

 

Toutes les opérations décrites ici sont internes aux routeurs frontière de diffusion groupée. Les règles décrites dans le présent document ne modifient pas les questions de sécurité sous-jacentes aux protocoles individuels d'acheminement de diffusion groupée. Permettre à différents protocoles d'interagir signifie cependant que les faiblesses de la sécurité d'un protocole particulier peuvent aussi s'appliquer par voie de conséquence aux autres protocoles.

 

6.   Références

 

[1]   Ajit S. Thyagarajan and Stephen E. Deering. Hierarchical distance-vector multicast routing for the MBone. Dans "Proceedings of the ACM SIGCOMM", pages 60--66, octobre 1995.

 

[2]   T. Pusateri, "Distance Vector Multicast Routing Protocol", Travail en cours.

 

[3]   J. Moy, "Extensions de diffusion groupée à OSPF", RFC 1584, Proteon, Inc., mars 1994.

 

[4]   D. Estrin, D. Farinacci, A. Helmy, D. Thaler, S. Deering, M. Handley, V. Jacobson, C. Liu, C., Sharma et L. Wei, "Mode épars de diffusion groupée indépendante du protocole (PIM-SM) : Spécification du protocole", RFC 2362, juin 1998.

 

[5]   A. Ballardie, "Acheminement de diffusion groupée en arborescences fondées sur le cœur de réseau (CBT version 2)", RFC 2189, septembre 1997.

 

[6]   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)

 

[7]   W. Fenner, "Protocole de gestion de groupe Internet, version 2", RFC 2236, novembre 1997. (Remplacée par la RFC3376)

 

[8]   A. Ballardie, "Core Based Tree (CBT) Multicast Border Router Specification", Travail en cours.

 

[9]   D. Thaler, "Protocole de routeur frontière de diffusion groupée (BGMP) : spécification du protocole", RFC3913, septembre 2004. (Historique)

 

[10]   W. Fenner, "Domain Wide Multicast Group Membership Reports", Travail en cours.

 

7.   Adresse de l'auteur

 

Dave Thaler

Microsoft

One Microsoft Way

Redmond, WA 98052

USA

téléphone : (425) 703-8835

mél : dthaler@microsoft.com

 

8.   Déclaration de copyright

 

Copyright (C) The Internet Society (1999). 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 copyright ci-dessus et le présent et 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 copyright 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 copyright 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 successeurs ou ayant droits.  

Le présent document et les informations y contenues sont fournies 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 CI-ENCLOSES NE VIOLENT AUCUN DROIT OU AUCUNE GARANTIE IMPLICITE DE COMMERCIALISATION OU D’APTITUDE À UN OBJET PARTICULIER.

 

Remerciement

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