           Guide pratique du multicast sur les rseaux TCP/IP

  Adaptation franaise du Multicast over TCP/IP HOWTO

  Juan-Mariano de Goyeneche

        <jmseyas CHEZ dit POINT upm POINT es>
      

   Adaptation franaise: Antoine Duval

        <aduval CHEZ altern POINT org>
      

   Relecture de la version franaise: Fabrice Gadaud

        <fabrice CHEZ gadaud POINT org>
      

   Prparation de la publication de la v.f.: Jean-Philippe Gurard

         <jean TIRET philippe POINT guerard CHEZ corbeaunoir POINT org>
        

   Version : 1.0.fr.1.1

   14 octobre 2003

   +----------------------------------------------------------------+
   | Historique des versions                                        |
   |----------------------------------------------------------------|
   | Version v1.0.fr.1.1        | 2003-10-14       | JPG            |
   |----------------------------------------------------------------|
   | Ajout de titres aux renvois inclus dans le texte. Reformatage  |
   | des exemples de code.                                          |
   |----------------------------------------------------------------|
   | Version v1.0.fr.1.0        | 2003-09-30       | AD,FG,JPG      |
   |----------------------------------------------------------------|
   | Premire version franaise.                                    |
   |----------------------------------------------------------------|
   | Version v1.0               | 1998-03-20       | JMdG           |
   +----------------------------------------------------------------+

   Rsum

   Ce guide pratique couvre les principaux aspects relatifs au
   multicast sur les rseaux TCP/IP. De nombreuses informations
   contenues dans ce document ne sont pas spcifiques  Linux (au cas
   o vous n'utiliserez pas encore le systme Linux/GNU...). Le
   multicast est encore un domaine de recherche et les standards ne
   sont encore que des brouillons. Gardez cela  l'esprit  la
   lecture des lignes qui suivent.

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

   Table des matires

   1. Introduction

                1.1. Qu'est ce que le multicast ?

                1.2. Le problme d'unicast

   2. Explications relatives au multicast

                2.1. Adresses multicast

                2.2. Niveaux de conformit

                2.3. Envoyer des datagrammes multicast.

                2.4. Recevoir des datagrammes multicast

   3. Besoins et configuration du noyau

   4. MBone

   5. Applications multicast

                5.1. Confrences audio

                5.2. Confrences vido

                5.3. Autres utilitaires

                5.4. Outils de session

   6. Programmation multicast

                6.1. IP_MULTICAST_LOOP

                6.2. IP_MULTICAST_TTL

                6.3. IP_MULTICAST_IF

                6.4. IP_ADD_MEMBERSHIP

                6.5. IP_DROP_MEMBERSHIP

   7. Fonctionnement interne

                7.1. IGMP

                7.2. Aspects concernant le noyau

   8. Politiques de routage et techniques de retransmission

   9. Protocoles de transport multicast

   10. Bibliographie

                10.1. RFCs

                10.2. Brouillons Internet (Internet Drafts)

                10.3. Pages web

                10.4. Livres

   11. Licence et mise en garde

1. Introduction

   Dans ce document, je vais essayer de vous donner des informations
   les plus  jour possible sur le multicast au travers des rseaux
   TCP/IP. Tout retour est le bienvenu. Si vous trouvez des erreurs
   dans ce document, si vous avez des commentaires ou des mises 
   jour  faire quant  son contenu, n'hsitez pas  m'en faire part
    l'adresse que vous trouverez dans l'entte du document.

  1.1. Qu'est ce que le multicast ?

   Le multicast est... un besoin. Ou du moins dans certains cas. Si
   vous avez des informations (beaucoup d'informations, le plus
   souvent) qui doivent tre transmises  un ensemble de machines
   (mais le plus souvent pas toutes) au travers d'internet, alors le
   multicast est une bonne solution. Un cas typique d'utilisation du
   multicast, est la diffusion audio ou vido temps rel  un
   ensemble de machines donn qui ont prcdemment rejoint une
   confrence distribue.

   Il est  noter que le multicast ressemble  la radio ou  la
   tlvision, en ce sens que seuls les utilisateurs qui ont rgl
   leur rcepteur (en slectionnant une frquence particulire)
   reoivent l'information. De ce fait, vous n'entendez que le canal
   qui vous intresse, pas les autres.

  1.2. Le problme d'unicast

   Unicast est tout ce qui n'est ni du broadcast ni du multicast.
   Bien sr, cette dfinition n'est pas vraiment claire... Expliquons
   nous : lorsque vous envoyez un paquet et qu'il y a seulement un
   metteur (vous) et un rcepteur (la personne  qui vous envoyez le
   paquet), alors il s'agit d'un mode de transmission unicast. TCP
   est par nature orient unicast. UDP est dclinable selon plus de
   modles, mais si vous envoyez des paquets UDP et qu'il n'y a
   qu'une personne qui est cense les recevoir, alors il s'agit aussi
   d'une transmission unicast.

   Pendant des annes les transmissions unicast ont sembl tre
   suffisantes pour Internet. Cela fut le cas jusqu'en 1993 o la
   premire mise en uvre du multicast vit le jour  l'occasion de la
   parution de la distribution BSD 4.4. Apparemment personne n'en
   avait jamais eu besoin avant cette date. Quels sont donc les
   nouveaux problmes lis au multicast ?

   Il n'est peut-tre pas ncessaire de dire ici, qu'internet a
   beaucoup chang depuis ses  premiers jours . Particulirement,
   l'apparition du web a considrablement transform la situation :
   les personnes ne voulaient plus seulement se connecter  des htes
   distants, serveurs de mails ou encore FTP. Ils voulaient
   maintenant voir les images des personnes qu'ils ctoient sur les
   pages de leurs sites web personnels, et plus tard les voir et les
   entendre.

   Avec la technologie d'aujourd'hui il est possible de supporter le
   cot d'tablissement d'une connexion avec ceux qui veulent voir
   votre page web personnelle. Cependant, si vous diffusez de l'audio
   et de la vido, vous aurez besoin d'un volume de bande passante
   norme compar aux applications web. Vous avez alors -ou vous
   aviez, si vous utilisez dj le multicast- deux solutions :
   tablir une connexion unicast avec chacun de vos destinataires, ou
   utiliser le broadcast. La premire solution n'est pas
   envisageable : si nous nous accordons sur le fait qu'une seule
   connexion audio/vido consomme normment de bande passante,
   imaginez alors le volume consomm par une centaine ou un millier
   de ces connections. Aussi bien l'ordinateur, metteur des donnes,
   que le rseau lui tant li succomberait [ndt : dans une grande
   souffrance].

   Le broadcast, ou envoi par diffusion, semble tre une solution,
   mais pas ncessairement la solution. Si vous souhaitez que toutes
   les machines de votre rseau coutent la confrence, vous pouvez
   utiliser le broadcast. Dans ce cas, les paquets ne sont mis
   qu'une seule fois et chaque hte les reoit sur une adresse de
   broadcast ; adresse sur laquelle ils pourront, de la mme manire,
   mettre. Cependant, il se peut que seulement peu d'utilisateurs
   soient intresss par ces paquets. Plus encore, il se peut que
   certains utilisateurs soient vraiment intresss par votre
   confrence, mais qu'ils se trouvent en dehors de votre rseau
   local,  seulement quelques routeurs de l. Vous n'tes pas sans
   savoir que si le broadcast fonctionne bien  l'intrieur d'un
   rseau local, des problmes surviennent lorsque vous dsirez
   diffuser des paquets qui doivent tre routs au travers de
   diffrents rseaux locaux.

   La meilleure solution serait alors d'mettre des paquets  une
   adresse spciale, telle une frquence donne comme dans le cas
   d'une transmission radio ou de tlvision. Dans ce cas, tous les
   htes qui ont dcid de joindre la confrence seront demandeurs
   des paquets portant cette adresse de destination ; ils les lisent
   lorsqu'ils passent sur le rseau et les transmettent  la couche
   IP pour qu'ils soient dmultiplexs. Cette technique est similaire
   au broadcast en ce sens que vous n'mettez qu'un seul paquet en
   diffusion et que tous les htes du rseau peuvent le reconnatre
   et le lire ; elle est diffrente en ce sens que tous les paquets
   multicast ne sont pas lus et traits, mais seulement ceux qui ont
   t prcdemment enregistrs dans le noyau comme tant
   intressants.

   Ces paquets spciaux sont routs au niveau du noyau comme tout
   autre paquet car il s'agit de paquets IP. L'unique diffrence
   rside dans l'algorithme de routage qui indique au noyau qui doit
   tre rout et que faire des paquets  router.

2. Explications relatives au multicast

  2.1. Adresses multicast

   Comme vous le savez probablement, les adresses IP sont divises en
    classes . Ces classes sont bases sur l'ordre des bits de poids
   fort de l'adresse IP :

   +----------------------------------------------------------------+
   | Bit -> | 0 |   |   |    |    |       31 |  Plage d'adresses :  |
   |--------+---+----------------------------+----------------------|
   |        | 0 |       Adresses de classe A |      0.0.0.0 -       |
   |        |   |                            |   127.255.255.255    |
   |--------+---+----------------------------+----------------------|
   |        | 1 | 0 |   Adresses de classe B |     128.0.0.0 -      |
   |        |   |   |                        |   191.255.255.255    |
   |--------+---+---+------------------------+----------------------|
   |        | 1 | 1 | 0 | Adresses de classe |     192.0.0.0 -      |
   |        |   |   |   |                  C |   223.255.255.255    |
   |--------+---+---+---+--------------------+----------------------|
   |        | 1 | 1 | 1 | 0  |      Adresses |     224.0.0.0 -      |
   |        |   |   |   |    |     multicast |   239.255.255.255    |
   |--------+---+---+---+----+---------------+----------------------|
   |        | 1 | 1 | 1 | 1  | 0  |  Rserv |     240.0.0.0 -      |
   |        |   |   |   |    |    |          |   247.255.255.255    |
   +----------------------------------------------------------------+

   La classe qui nous intresse est la classe D. Chaque datagramme
   dont l'adresse de destination (code sur 32 bits) commence par
    1110  est un datagramme IP Multicast.

   Les 28 autres bits identifient le groupe auquel le datagramme est
   envoy. Poursuivant avec la prcdente analogie, il est ncessaire
   de rgler sa radio pour entendre un programme qui est retransmis
   sur une frquence donne. Dans notre cas, il convient de procder
   de la mme faon : vous devez  rgler  votre noyau pour qu'il
   reoive les paquets qui sont mis  destination d'un groupe
   multicast donn. Lorsque cette opration est effectue, il est dit
   que l'hte a joint ce groupe ; ceci sur une interface spcifie :
   vous trouverez plus d'informations sur ce propos par la suite.

   Il existe des groupes multicast spciaux, dits  groupes multicast
   bien connus , vous ne devez pas les utiliser pour vos
   applications, du fait de l'usage bien spcifique auquel ils sont
   destins :

   224.0.0.1

           est le groupe all-hosts. Si vous pingez ce groupe, tous
           les htes sur le rseau capables d'mettre en multicast
           rpondront, car tout hte grant le multicast doit joindre
           ce groupe au dmarrage sur toutes ses interfaces.

   224.0.0.2

           est le groupe all-routers. Tous les routeurs multicast
           joignent ce groupe sur toutes leurs interfaces multicast.

   224.0.0.4

           est le groupe de tous les routeurs DVMRP.

   224.0.0.5

           est le groupe de tous les routeurs OSPF.

   224.0.0.13

           est le groupe de tous les routeurs PIM, etc.

   Tous ces groupes multicast spciaux sont rgulirement publis
   dans le RFC  Assigned Numbers 

   Dans tous les cas, l'intervalle allant de 224.0.0.0  224.0.0.255
   est reserv pour les contenus locaux (comme des tches
   administratives ou de maintenance) et les datagrammes destins 
   ces adresses ne sont jamais retransmis par les routeurs multicast.
   De la mme manire, l'intervalle allant de 239.0.0.0 
   239.255.255.255 est reserv pour des raisons d'administration (cf
   section 2.3.1 pour de plus amples imformations  ce propos).

  2.2. Niveaux de conformit

   Il existe trois niveaux de conformit diffrents, que les htes
   peuvent implmenter, en accord avec la spcification multicast,
   permettant de grer les diffrents services mis en commun.

   Niveau 0

           signifie  qu'aucun support n'est disponible pour l'IP
           multicast . Beaucoup d'htes et de routeurs sur Internet
           sont dans cet tat, car le support multicast n'est pas
           exig pour l'IPv4 (il l'est cependant pour l'IPv6). Ainsi,
           les htes qui sont dans cet tat ne peuvent ni mettre, ni
           recevoir de paquets multicast. Ils ignorent donc les
           paquets mis par les autres htes pouvant mettre en
           multicast.

   Niveau 1

           signifie  qu'il existe un support pour envoyer mais pas
           pour recevoir des datagrammes IP multicast . Dans ce cas,
           il n'est pas ncessaire de joindre un quelconque groupe
           multicast pour envoyer des datagrammes. Peu d'ajouts sont
           ncessaires  un module IP pour passer un hte du  niveau
           0  au  compatible niveau 1 , comme on pourra le voir
           dans la section 2.3.

   Niveau 2

           signifie qu'un  support complet est disponible pour l'IP
           multicast . Les htes de niveau 2 sont aussi bien
           capables d'mettre, que de recevoir du trafic multicast.
           Ils savent comment joindre et quitter les groupes
           multicast, ainsi que propager cette information aux
           routeurs multicasts. De mme, ils incluent une
           implmentation de IGMP (Internet Group Management
           Protocol) dans leur pile de protocoles TCP/IP.

  2.3. Envoyer des datagrammes multicast.

   Il est vident que le trafic multicast doit tre encapsul par une
   couche transport comme UDP. En effet, TCP fournit des connections
   point--point, ce qui n'est pas envisageable pour du trafic
   multicast. Il est  noter que des recherches sont effectues dans
   ce domaine pour dfinir et implmenter un nouveau protocole de
   transport orient multicast. Consultez la section Protocoles de
   transport multicast pour plus de dtails.

   En principe, une application ncessite seulement l'ouverture d'une
   prise rseau UDP qu'elle remplit de donnes, qui seront envoyes 
   destination d'une adresse multicast (classe D). Cependant,
   certaines oprations doivent tre contrles lors du processus
   d'envoi.

    2.3.1. TTL

   Le champ TTL (Time To Live, ou temps restant  vivre) de l'entte
   IP a une double signification pour le multicast. Comme toujours,
   il contrle le temps restant  vivre pour un datagramme empchant
   ainsi les boucles infinies dues aux erreurs de routage. Chaque
   routeur dcrmente le TTL de tout datagramme le traversant et
   lorsque cette valeur devient gale  0 le paquet est dtruit.

   Le TTL dans notre cas (sur IPv4) a aussi une signification de
    seuil . clairons son utilisation  l'aide d'un exemple :
   supposez que vous fassiez une longue confrence vido (consommant
   beaucoup de bande passante) entre tous les htes de votre
   dpartement. Vous dsirez que tout ce trafic puisse tre support
   par votre rseau local. Peut-tre que votre dpartement est
   suffisamment grand pour avoir diffrents rseaux locaux. Dans ce
   cas vous dsirerez srement que les htes appartenant  chacun de
   vos rseaux locaux puissent suivre la confrence, sans pour autant
   saturer Internet tout entier avec votre trafic multicast. Il est
   donc ncessaire de limiter la porte du trafic multicast au
   travers des routeurs. C'est ce  quoi est destin le TTL. Chaque
   routeur a un seuil TTL assign sur chaque interface, et seuls les
   datagrammes qui ont un TTL suprieur au seuil de l'interface sont
   retransmis au travers de ce routeur. Notez que lorsqu'un
   datagramme traverse un routeur avec une valeur de seuil donne, le
   TTL du datagramme n'est pas dcrment de la valeur de ce seuil.
   Seule une comparaison est faite. (Comme prcedemment, le TTL est
   dcrment de 1  chaque passage au travers d'un routeur).

   Une liste de seuils TTL et de leur signification suit :

   +----------------------------------------------------------------+
   | TTL  |                      Signification                      |
   |------+---------------------------------------------------------|
   |  0   |  Restriction au mme hte. Le paquet ne sera mis sur   |
   |      |                    aucune interface.                    |
   |------+---------------------------------------------------------|
   |  1   |  Restriction au mme sous rseau. Le paquet ne pourra   |
   |      |                       tre rout                        |
   |------+---------------------------------------------------------|
   | <32  | Restriction au mme site, organisation ou dpartement.  |
   |------+---------------------------------------------------------|
   | <64  |              Restriction  la mme rgion.              |
   |------+---------------------------------------------------------|
   | <128 |             Restriction au mme continent.              |
   |------+---------------------------------------------------------|
   | <255 |               Aucune restriction. Global.               |
   +----------------------------------------------------------------+

   Aucune signification exacte n'a t donne au terme de  site  ou
   de  rgion . Il est  la charge des administrateurs de dcider
   des limites qui s'appliquent.

   Il est  noter que l'astuce lie au TTL n'est peut tre pas
   toujours assez souple pour correspondre  tous les besoins, et
   plus spcialement s'il est ncessaire de traiter avec des rgions
   qui se chevauchent et prenent en compte  la fois des limites
   gographiques, topologiques ou encore lies  une gestion de bande
   passante. Afin de rsoudre ce problme, des rgions multicast 
   caractre administratif ont t tablies depuis 1994. (cf
   D.Meyer's  Administratively Scoped IP Multicast  Internet
   draft). Ce dcoupage est bas sur les adresses multicast au lieu
   des TTL. L'intervalle allant de 239.0.0.0  239.255.255.255 est
   reserv  ce dcoupage administratif.

    2.3.2. Loopback

   Lorsqu'un hte est conforme au niveau 2 et qu'il est membre du
   groupe auquel il envoie des datagrammes, alors une copie des
   datagrammes lui est retransmise par dfaut. Cela ne signifie pas
   que l'interface lit sa propre transmission depuis le rseau (en
   reconnaissant les datagrammes comme tant d'un groupe auquel
   appartient l'interface). Au contraire, c'est la couche IP qui, par
   dfaut, reconnat le datagramme  envoyer, le copie puis le met
   sur la file d'entre IP avant de l'envoyer.

   Cette fonctionnalit est apprciable dans certains cas, mais pas
   pour tous. De ce fait il est possible d'activer ou de dsactiver
   ce processus d'envoi selon ses souhaits.

    2.3.3. Slection de l'interface.

   Les htes qui sont relis  plus d'un rseau doivent pouvoir
   dcider de l'interface rseau  utiliser pour envoyer les
   informations. Si rien n'est spcifi, alors le noyau en choisit
   une par dfaut. Ce choix est bas sur la configuration faite par
   l'administrateur.

  2.4. Recevoir des datagrammes multicast

    2.4.1. Joindre un groupe multicast

   La diffusion en broadcast est (en comparaison) plus simple 
   implmenter que la diffusion en multicast. En effet dans le
   premier cas, il n'est pas ncessaire que les processus donnent au
   noyau des rgles concernant la gestion des paquets diffuss. Le
   noyau sait ce qu'il doit faire avec tous les paquets : les lire et
   les dlivrer aux applications concernes.

   En diffusion multicast il est ncessaire d'aviser le noyau des
   groupes multicast qui nous intressent. Le noyau  joint  alors
   ces groupes. Puis selon la nature du matriel sous-jacent, les
   datagrammes multicast sont filtrs soit par le matriel, soit par
   la couche IP (et dans certains cas, par les deux). Seuls les
   datagrammes dont le groupe de destination a prcdemment t
   rejoint sont accepts.

   Essentiellement, lorsque l'on joint un groupe, nous disons au
   noyau  D'accord, je sais que par dfaut tu ignores les
   datagrammes multicast, mais souviens toi que ce groupe multicast
   m'intresse. De ce fait, lit et dlivre ( tous les processus
   intresss, pas seulement moi) tous les datagrammes que tu vois
   sur ton interface rseau et qui sont adresss au groupe multicast
   en question .

   Quelques remarques : tout d'abord, notez que vous ne faites pas
   que rejoindre un groupe. Vous joignez un groupe sur une interface
   rseau particulire. Bien sr, il est possible de joindre le mme
   groupe sur plusieurs interfaces. Si vous ne spcifiez pas
   concrtement une interface, alors le noyau en choisira une (selon
   sa table de routage) lorsqu'il sera ncessaire d'envoyer des
   datagrammes. Par ailleurs, il est possible que plus d'un processus
   rejoignent le mme groupe multicast par une mme interface. Ces
   processus reoivent alors tous les datagrammes envoys  ce groupe
   au travers de cette interface.

   Comme dit prcdemment, tous les htes grant le multicast
   joignent le groupe all-hosts au dmarrage, de ce fait on peut
    pinger  tous les htes grant le multicast au travers de
   l'adresse 224.0.0.1.

   Finalement, considrez le fait suivant : pour qu'un processus
   puisse recevoir des datagrammes multicast, il doit demander au
   noyau de joindre le groupe dsir, et doit se relier au port par
   lequel les datagrammes seront envoys. La couche UDP se base  la
   fois l'adresse de destination et le numro de port pour
   dmultipexer les paquets reus et dcider  quelle(s)
   connection(s) les dlivrer.

    2.4.2. Quitter un groupe multicast

   Quand un processus n'est plus intress par un groupe multicast,
   il informe le noyau qu'il dsire quitter ce groupe. Il est
   important de comprendre que cela ne signifie pas que le noyau
   n'acceptera plus les datagrammes multicast destins  ce groupe.
   En effet, il continuera  le faire si d'autres processus restent
   intresss par ce groupe. Dans ce cas l'hte reste membre de ce
   groupe, et cela jusqu' ce que tous les processus dcident de le
   quitter.

   L'explication ici est que joindre un groupe multicast ncessite
   seulement une adresse IP. C'est la couche de liaison de donnes
   qui, aprs une demande explicite au matriel dans certains cas,
   accepte les datagrammes multicast destins  ce groupe.
   L'appartenance  un groupe ne se fait donc pas par processus, mais
   par hte.

    2.4.3. Transcrire une adresse IP Multicast dans une adresse
    Ethernet/FDDI

   Les trames Ethernet, aussi bien que les trames FDDI, ont une
   adresse de destination code sur 48 bits. Dans le but d'viter une
   sorte d'ARP multicast translatant les adresses IP multicast en
   adresses ethernet/FDDI, l'IANA a rserv une plage d'adresses pour
   le multicast : chaque trame ethernet/FDDI dont l'adresse de
   destination appartient  l'intervalle allant de 01-00-5e-00-00-00
    01-00-5e-ff-ff-ff contient des donnes  destination d'un groupe
   multicast. Le prfixe 01-00-5e identifie la trame comme tant
   multicast, le bit suivant tant toujours  0, il reste donc 23
   bits de disponibles pour les adresses multicast. Comme les groupes
   multicast sont dfinis sur 28 bits, la translation ne peut pas
   tre une  une. Seuls les 23 bits les moins significatifs du
   groupe IP multicast sont placs dans la trame. Les 5 bits d'ordre
   suprieur restant sont ignors, ce qui a pour rsultat que 32
   groupes multicast diffrents peuvent tre translats par une mme
   adresse ethernet/FDDI. Cela signifie que la couche ethernet agit
   tel un filtre imparfait, et que la couche IP doit dcider si elle
   accepte les datagrammes de la couche de liaison de donnes qui lui
   sont donns. La couche IP agit tel un filtre final parfait.

   Tous les dtails concernant l'IP Multicast au travers de FDDI sont
   donns dans le RFC 1390  Transmission of IP and ARP over FDDI
   Networks  (transmission IP et ARP au travers de rseaux FDDI).
   Pour plus d'information concernant la translation d'adresses IP
   multicast vers ethernet, vous pouvez consulter le
   draft-ietf-mboned-intro-multicast-03.txt:  Introduction to IP
   Multicast Routing  (introduction au routage IP multicast).

   Si vous tes intress par l'IP multicast sur les rseaux locaux
   Token-Ring, consultez le RFC 1469.

3. Besoins et configuration du noyau

   Linux est, bien sr (doutez-vous de cela ?), pleinement compatible
   avec le multicast niveau 2. Il satisfait toutes les exigences
   lies  l'envoi,  la rception et au routage (grce  mrouter)
   des datagrammes multicast.

   Si vous dsirez mettre et recevoir des paquets IP multicast, vous
   devez activer l'option  IP: multicasting  lors de la
   configuration de votre noyau. Si vous dsirez aussi que votre
   Linux agisse tel un routeur multicast, vous aurez alors besoin
   d'activer le routage multicast du noyau en slectionnant  IP:
   forwarding/gatewaying  (transfert/passerelle),  IP: multicast
   routing  (routage multicast) et  IP: tunneling  (tunnel), cette
   dernire option est ncessaire car les nouvelles versions de
   mrouted peuvent aussi retransmettre les paquets au travers de
   tunnels IP ; les datagrammes IP multicast sont alors encapsuls
   dans des datagrammes unicast. Il est ncessaire d'tablir des
   tunnels entre des htes multicast s'ils sont spars par un rseau
   ou par plusieurs routeurs incapables de transfrer des datagrammes
   multicast. (mrouted est un service qui implmente un algorithme de
   routage multicast -politique de routage- et informe le noyau sur
   la faon de router les datagrammes multicast.

   Certaines versions du noyau considrent le routage multicast comme
   tant  EXPERIMENTAL , de ce fait vous devez activer l'option
    Prompt for development and/or incomplete code/drivers  dans la
   section  Code maturity level options .

   Si, durant l'excution de mrouted, le trafic gnr sur le rseau
   (o est connecte votre station linux) est correctement transfr
   aux autres rseaux, mais il vous est impossible de  voir  le
   trafic des autres rseaux sur votre rseau local, vrifiez alors
   si vous recevez des messages d'erreur du protocole ICMP. Il s'agit
   d'une erreur due, le plus frquemment,  la non activation de l'IP
   tunneling de votre routeur Linux. C'est le genre d'erreur qui
   parat stupide lorsque vous la connaissez mais, croyez moi, cela
   prend beaucoup de temps pour la dtecter quand vous l'ignorez, car
   il n'y a pas de raison apparente signifant la cause de l'erreur.
   Un renifleur (ou  sniffeur ) s'avre utile dans ce genre de
   situation.

   Vous trouverez plus d'informations dans la section politiques de
   routage et techniques de retransmission ; mrouted et les tunnels
   sont aussi expliqus dans la section consacre  MBone et la
   section applications multicast.

   Une fois votre nouveau noyau compil et install, vous devez
   dfinir une route par dfaut pour votre trafic multicast. Ce qui
   revient  ajouter une route au rseau 224.0.0.0.

   Le problme auquel le plus de personnes font face  ce stade de la
   configuration est la valeur du masque  appliquer. Si vous avez lu
   prcdemment l'excellent NET-3-HOWTO de Terry Dawson, il ne vous
   sera pas difficile de trouver la bonne valeur. Comme expliqu, le
   masque de sous rseau est un nombre cod sur 32 bits rempli avec
   des  1  sur la partie rseau de votre adresse IP, et avec des
    0  sur la partie hte. En rfrence  la section 2.1 une
   adresse multicast de classe D n'a pas de division rseau/hte. 
   la place, il a un groupe d'identification cod sur 28 bits et un
   identifiant de classe D cod sur 4 bits. Le masque de sous rseau
   voulu est donc 11110000000000000000000000000000 ou d'une manire
   plus facilement lisible : 240.0.0.0. De ce fait la commande
   complte est :

 route add 224.0.0.0 netmask 240.0.0.0 dev eth0

   Selon la version de votre programme route, il peut tre ncessaire
   d'ajouter l'option -net aprs l'option add.

   Dans l'exemple, nous supposons que l'interface eth0 supporte le
   multicast et, si rien d'autre n'est spcifi, nous voulons que le
   trafic multicast sorte par cette interface. Si cela n'est pas
   votre cas, changez alors le paramtre dev de manire approprie.

   Le systme de fichiers /proc s'avre utile une fois encore : il
   est possible de vrifier dans le fichier /proc/net/igmp les
   groupes auxquels votre machine est actuellement connecte.

4. MBone

   L'utilisation d'une nouvelle technologie apporte son lot
   d'avantages et d'inconvnients. Les avantages du multicast sont
   -je le pense- clairs. Le principal inconvnient est
   qu'actuellement des centaines d'htes, et plus spcialement les
   routeurs, ne supportent pas le multicast. Par consquent, les
   personnes qui commencent  travailler avec du multicast, et qui de
   fait ont achet de nouveaux quipements et modifi leurs systmes
   d'exploitation ; on construit des lots multicast dans leurs
   locaux. C'est alors qu'ils ont dcouvert qu'il leur tait
   difficile de communiquer avec des personnes faisant de mme car il
   suffit d'un routeur ne supportant pas le multicast pour que rien
   ne fonctionne.

   La solution est alors apparue comme vidente : ils dcidrent de
   contruire un rseau multicast virtuel au-dessus d'Internet. De
   fait : les sites relis par des routeurs multicasts peuvent
   communiquer entre-eux directement. Mais les sites joigniables
   uniquement par le biais de routeurs unicast doivent encapsuler
   leur trafic multicast dans des paquets unicast pour communiquer
   avec les autres lots multicast. Les routeurs traverss ne
   poserons pas de problmes car ils savent grer ce trafic unicast.
   Finalement, le site de rception dsencapsulera le trafic, et le
   retransmettra  l'lot selon la mthode multicast originale.
   Ainsi, les deux extrmits convertissent du multicast vers de
   l'unicast et  nouveau de l'unicast vers du multicast, dfinissant
   ainsi ce qui est appel un tunnel multicast.

   Le MBone ou pine dorsale multicast (Multicast BackBone) est un
   rseau virtuel multicast bas sur l'interconnection d'lots
   multicast relis entre eux par des tunnels multicast.

   Diverses utilisations sont faites du MBone de nos jours, on peut
   ainsi remarquer la profusion de tlconfrences audio/vido en
   temps rel qui ont lieu au travers d'Internet. Un exemple de ces
   tlconfrences est la retransmission (en direct !) de la
   confrence de Linus Torvalds qui a t donne au groupe
   d'utilisateurs de Linux de la Silicon Valley [ndt : en 1999 ?].

   Pour plus d'informations  propos du MBone, consultez :
   http://www.mediadesign.co.at/newmedia/more/mbone-faq.html

5. Applications multicast

   La plupart des personnes ayant affaire avec le multicast, dcident
   tt ou tard de se connecter au MBone, et de ce fait ont
   tradionnellement besoin de mrouted. Vous aurez srement besoin de
   lui si vous ne possdez pas de routeur capable de faire du
   multicast et que vous voulez que le travail effectu sur l'un de
   vos sous rseaux soit  entendu  par un autre rseau. mrouted
   circonscrit le problme d'envoi de trafic au travers des routeurs
   unicast -il encapsule les datagrammes multicast dans des
   datagrammes unicast (IP dans IP)-. Il ne s'agit pas de la seule
   fonctionnalit de mrouted. La plus importante, est qu'il indique
   au noyau la faon de router (ou de ne pas router) les datagrammes
   multicast selon leurs adresses d'origine et de destination. De ce
   fait, mme si vous avez un routeur multicast, mrouted peut tre
   utilis pour lui dire quoi faire des datagrammes. (notez que j'ai
   dit quoi, et non comment, mrouted dit  transmet ceci au rseau
   connect  cette interface , mais le transfert se fait
   actuellement par le noyau). Il existe une distinction  faire
   entre le transfert en lui-mme et l'algorithme qui dcide de ce
   qui doit tre transfr et de la faon de le faire. Cette
   distinction est trs utile car elle permet d'crire un code unique
   permettant le transfert, en l'insrant dans le noyau ; tandis que
   les algorithmes et les politiques de transfert sont implments en
   tant que service utilisateur, ce qui permet un changement de
   politique sans recompiler le noyau.

   Vous pouvez vous procurer une version de mrouted pour Linux
   depuis : ftp://www.video.ja.net/mice/mrouted/Linux/. Des mirroirs
   de ce site existent tout autour de la plante. Lisez bien le
   fichier ftp://www.video.ja.net/mice/README.mirrors pour choisir le
   mirroir le plus prs de chez vous.

   Vous trouverez ci-dessous une liste des applications qui ont t
   crites afin de se connecter au MBone et qui ont t portes sous
   Linux. Cette liste est issue de la page d'information  Linux
   Multicast Information  crite par Michael Esler :
   http://www.cs.virginia.edu/~mke2e/multicast/. Je vous recommande
   cette page pour toutes les informations et ressources  propos du
   multicast et de Linux.

  5.1. Confrences audio

     o NeVoT - Terminal rseau pour la voix
       http://www.fokus.gmd.de/step/nevot

     o RAT - UCL outil audio robuste
       http://www-mice.cs.ucl.ac.uk/mice/rat

     o vat - LBL outil audio visuel http://www-nrg.ee.lbl.gov/vat/

  5.2. Confrences vido

     o ivs - Systme de vido confrence de l'Inria
       http://www.inria.fr/rodeo/ivs.html

     o nv - Outil rseau pour la vido
       ftp://ftp.parc.xerox.com/pub/net-research/

     o nv w/ Meteor - Version de nv w/ pour Matrox Meteor (UVa)
       ftp://ftp.cs.virginia.edu/pub/gwtts/Linux/nv-meteor.tar.gz

     o vic - LBL Outil de vido confrence
       http://www-nrg.ee.lbl.gov/vic/

     o vic w/ Meteor - Version de vic w/ support pour Matrox Meteor
       (UVa)
       ftp://ftp.cs.virginia.edu/pub/gwtts/Linux/vic2.7a38-meteor.tar.gz

  5.3. Autres utilitaires

     o mmphone service tlphonique multimdia
       http://www.eit.com/software/mmphone/phoneform.html

     o wb - LBL tableau blanc partag http://www-nrg.ee.lbl.gov/wb/

     o webcast - Application multicast fiable pouvant relier les
       navigateurs Mosaic
       http://www.ncsa.uiuc.edu/SDG/Software/XMosaic/CCI/webcast.html

  5.4. Outils de session

   Les outils de gestion de sessions ont t placs aprs les autres,
   car ils ncessitent quelques explications. Lorsque qu'une
   confrence a lieu, il est assign pour chaque service (audio,
   vido, tableau-blanc partag, etc) un ou plusieurs groupes
   multicast, eux-mms associs  un numro de port. Les confrences
   qui vont avoir lieu sont priodiquement annonces sur le MBone.
   Ces annonces contiennent des informations  propos des groupes
   multicasts, des numros de ports et des programmes qui peuvent
   tre utiliss (vic, vat, ...). Les outils de gestion de sessions
    coutent  ces informations et vous les annoncent de manire 
   ce qu'elles soient facilement joignables. Vous pouvez ainsi
   dcider quelle confrence vous intresse. Ainsi, au lieu de
   dmarrer chaque programme qui sera utilis et lui indiquer les
   groupes multicast et les numros de ports qu'il vous faut joindre,
   il vous suffit de cliquer sur l'annonce et l'outil de gestion de
   sessions dmarre les bonnes applications, en leur communiquant
   toutes les informations ncessaires pour joindre la confrence.
   Les outils de gestion de sessions vous permettent gnralement
   d'annoncer votre propre confrence sur le MBone.

     o gwTTS - systme de tl-enseignement de Universit de Virginie
       http://www.cs.Virginia.EDU/~gwtts

     o isc - contrleur de session intgr
       http://www.fokus.gmd.de/step/isc

     o mmcc - contrle de confrences multimdia
       ftp://ftp.isi.edu/confctrl/mmcc

     o sd - outil de rfrencement de session LBL
       ftp://ftp.ee.lbl.gov/conferencing/sd

     o sd-snoop - utilitaire de rfrencement de sessions du Tenet
       Group ftp://tenet.berkeley.edu/pub/software

     o sdr - nouvelle gnration de rfrencement de sessions d'UCL
       ftp://cs.ucl.ac.uk/mice/sdr

6. Programmation multicast

   Programmation multicast... ou comment crire vos propres
   applications multicast.

   Diverses extensions de l'API de programmation sont ncessaires
   pour utiliser le multicast. Ces extensions sont utilisables par le
   biais de deux appels systmes : setsockopt() (utilis pour envoyer
   des informations au noyau) et getsockopt() (utilis pour recevoir
   des informations du voisinage multicast). Cela ne signifie pas que
   ces 2 nouveaux appels systmes ont t ajouts pour le
   fonctionnement du multicast. La paire setsockopt() / getsockopt()
   est l depuis des annes. Depuis la BSD 4.2 au moins. L'ajout
   consiste en un nouveau jeu d'options (options multicast) qui est
   pass  ces appels systmes et que le noyau doit comprendre.

   Les deux lignes suivantes donnent le prototypage des fonctions
   setsockopt() / getsockopt().

 int getsockopt(int s, int level, int optname, void* optval, int* optlen);
 int setsockopt(int s, int level, int optname, const void* optval, int optlen);

   Le premier paramtre, s, est la prise rseau (socket)  laquelle
   l'appel systme s'applique. Pour le multicast, la prise doit tre
   de la famille AF_INET et peut tre de type SOCK_DGRAM ou SOCK_RAW.
   Le plus courant est l'utilisation d'une prise SOCK_DGRAM, mais si
   votre but est d'crire un dmon de routage ou d'en modifier un,
   vous aurez plutt besoin d'une prise de type SOCK_RAW.

   Le deuxime paramtre, level, identifie la couche qui capturera
   l'option, le message, ou la requte, ou tout ce que vous dsirez
   appeler. De fait, SOL_SOCKET est pour la couche de la prise
   rseau, IPPROTO_IP est pour la couche IP, etc. Pour la
   programmation multicast, la valeur est toujours IPPROTO_IP.

   optname identifie l'option que nous passons ou demandons. Sa
   valeur, soit fournie par le programme, soit retourne par le
   noyau, est optval. Les valeurs pour optname qui peuvent tre
   invoques pour la programmation multicast sont les suivantes :

   +--------------------------------------------------+
   |                    | setsockopt() | getsockopt() |
   |--------------------+--------------+--------------|
   | IP_MULTICAST_LOOP  |     oui      |     oui      |
   |--------------------+--------------+--------------|
   |  IP_MULTICAST_TTL  |     oui      |     oui      |
   |--------------------+--------------+--------------|
   |  IP_MULTICAST_IF   |     oui      |     oui      |
   |--------------------+--------------+--------------|
   | IP_ADD_MEMBERSHIP  |     oui      |     non      |
   |--------------------+--------------+--------------|
   | IP_DROP_MEMBERSHIP |     oui      |     non      |
   +--------------------------------------------------+

   optlen transporte la taille de la structure de donnes  laquelle
   optval fait rfrence. Notez que pour getsockopt(), c'est un
   rsultat et non une donne : le noyau crit la valeur de optname
   dans la zone tampon pointe par optval et nous informe de la
   longueur de la valeur par optlen.

   Aussi bien setsockopt() que getsockopt() retournent 0 en cas de
   succs et -1 en cas d'erreur.

  6.1. IP_MULTICAST_LOOP

   Vous devez dcider, en tant que programmeur, si les donnes que
   vous voulez mettre doivent tre retournes ou non sur votre hte.
   Si vous pensez avoir plus d'un processus ou utilisateur en coute,
   alors un retour doit tre activ.  contrario, si vous mettez des
   images que votre camra vido produit, vous ne ncessiterez
   probablement pas de retour,  moins que vous dsiriez les voir sur
   votre cran. Dans ce dernier cas, votre application recevra dj
   certainement les images depuis le priphrique connect  votre
   ordinateur pour les envoyer  la prise rseau. De ce fait,
   l'application possde dj les donnes, et cela devient improbable
   que vous vouliez les recevoir de nouveau au travers de la prise
   rseau.

   Il est  noter que le retour est activ par dfaut.

   Comme optval est un pointeur, vous ne pouvez pas crire :

 setsockopt(socket, IPPROTO_IP, IP_MULTICAST_LOOP, 0, 1);

   pour dsactiver le loopback vous devez crire :

 u_char loop;
 setsockopt(socket, IPPROTO_IP, IP_MULTICAST_LOOP, &loop, sizeof(loop));

   et donnez la valeur 1  loop pour activer le retour et 0 pour le
   dsactiver.

   Pour savoir si une prise rseau a activ ou non son retour,
   utilisez quelque chose comme :

 u_char loop;
 int size;
 getsockopt(socket, IPPROTO_IP, IP_MULTICAST_LOOP, &loop, &size)

  6.2. IP_MULTICAST_TTL

   Si rien n'est prcis, les datagrammes multicast sont envoys avec
   comme valeur par dfaut 1, dans le but d'viter qu'ils soient
   transfrs sur tout le rseau local. Pour changer la valeur du TTL
   (de 0  255), mettez cette valeur dans une variable (ici nomme 
   ttl ) et crivez dans votre programme :

 u_char ttl;
 setsockopt(socket, IPPROTO_IP, IP_MULTICAST_TTL, &ttl, sizeof(ttl));

   Le comportement avec getsockopt() est similaire  celui vu avec
   IP_MULTICAST_LOOP.

  6.3. IP_MULTICAST_IF

   Traditionnellement, l'administrateur systme indique l'interface
   multicast par dfaut sur laquelle les datagrammes sont envoys. Le
   programmeur peut surcharger cela et choisir ainsi  l'aide de
   cette option une interface de sortie concrte pour une prise
   rseau donne.

 struct in_addr interface_addr;
 setsockopt (socket, IPPROTO_IP, IP_MULTICAST_IF, &interface_addr,
             sizeof(interface_addr));

   Ainsi, tout le trafic multicast gnr par cette prise rseau sera
   envoy sur l'interface choisie. Pour revenir au comportement par
   dfaut et laisser le noyau choisir l'interface de sortie (choix
   bas sur la configuration de l'administrateur systme), il suffit
   d'appeler setsockopt() avec la mme option et INADDR_ANY comme
   valeur pour l'interface.

   Pour connaitre ou slectionner une interface de sortie, les ioctls
   suivants peuvent tre utililiss : SIOCGIFADDR (pour obtenir les
   adresses des interfaces), SIOCGIFCONF (pour obtenir la liste de
   toutes les interfaces) et SIOCGIFFLAGS (pour obtenir les
   fonctionnalits d'une interface et, de fait, permet de dterminer
   si l'interface supporte le multicast ou non. Fonction indique par
   l'option IFF_MULTICAST).

   Si un hte a plus d'une interface et que l'option IP_MULTICAST_IF
   n'est pas mentionne, alors les transmissions multicast sont
   mises sur l'interface par dfaut, bien que les interfaces
   restantes puissent tre utilises pour des retransmissions
   multicast si l'hte joue le rle de routeur multicast.

  6.4. IP_ADD_MEMBERSHIP

   Rappelez vous que vous devez informer le noyau des groupes
   multicast qui vous intressent. Si aucun processus n'est intress
   par un groupe donn, les paquets provenant de ce groupe et qui
   arrivent sur notre hte sont rejets. Pour informer le noyau, des
   groupes qui vous intressent, et de fait, pour devenir membre de
   ce groupe, vous devez d'abord remplir une structure ip_mreq qui
   sera passe plus tard au noyau dans le champ optval avec l'appel
   systme setsockopt().

   La structure ip_mreq (provenant de /usr/include/linux/in.h) a les
   membres suivants :

 struct ip_mreq
 {
   struct in_addr imr_multiaddr;   /* adresse IP du groupe multicast */
   struct in_addr imr_interface;   /* adresse IP de l'interface locale */
 };

   Note : la dfinition  physique  de la structure est contenue
   dans le fichier spcifi ci-dessus. Vous ne devez en aucun cas
   inclure <linux/in.h> si vous souhaitez que votre code soit
   portable. En lieu et place, incluez <netinet/in.h>, qui inclut 
   son tour <linux/in.h>.

   Le premier membre, imr_multiaddr, contient l'adresse du groupe que
   vous dsirez joindre. Souvenez-vous que l'appartenance  un groupe
   se fait aussi par le biais d'une interface, pas uniquement sur
   l'adresse du groupe. C'est la raison pour laquelle vous devez
   fournir une valeur au second membre : imr_interface. De cette
   faon, si vous tes sur un hte ayant plusieurs interfaces
   multicast, vous pouvez joindre un mme groupe par le biais de
   diffrentes interfaces. Si vous ne dsirez pas indiquer
   d'interface, vous pouvez toujours remplir ce dernier membre avec
   un joker (INADDR_ANY), alors le noyau choisira de lui mme
   l'interface.

   Une fois la structure remplie (dfinie en tant que struct ip_mreq
   mreq;) vous avez juste  appeler setsockopt() de cette manire :

 setsockopt (socket, IPPROTO_IP, IP_ADD_MEMBERSHIP, &mreq, sizeof(mreq));

   Notez que vous pouvez joindre plusieurs groupes  travers la mme
   prise rseau. Cette limite suprieure est fixe par
   IP_MAX_MEMBERSHIPS et, a pour la version 2.0.33 du noyau Linux, la
   valeur de 20.

  6.5. IP_DROP_MEMBERSHIP

   La procdure ncessaire pour quitter un groupe est semblable 
   celle ncessaire pour le joindre.

 struct ip_mreq mreq;
 setsockopt (socket, IPPROTO_IP, IP_DROP_MEMBERSHIP, &mreq, sizeof(mreq));

   O mreq est une structure contenant les mmes donnes que celles
   utilises lorsque ce groupe ft joint. Si le membre imr_interface
   contient la valeur INADDR_ANY, alors le premier groupe pouvant
   correspondre est supprim.

   Si vous avez rejoint un grand nombre de groupes sur une mme prise
   rseau, il n'est pas ncessaire de supprimer toutes les
   souscriptions pour terminer. Lorsque vous fermez une prise rseau,
   toutes les souscriptions associes  cette prise sont supprimes
   par le noyau. Il en est de mme si le processus qui a ouvert la
   prise est tu.

   Cependant, gardez  l'esprit que si un processus abandonne la
   souscription  un groupe, cela n'implique pas forcment l'arrt de
   la transmission des datagrammes du groupe en question  l'hte. En
   effet, si une autre prise a joint ce groupe avec la mme interface
   avant le IP_DROP_MEMBERSHIP, alors l'hte continuera  tre membre
   de ce groupe.

   ADD_MEMBERSHIP (aussi bien que DROP_MEMBERSHIP) est une opration
   non-bloquante. Il renvoie un rsultat, immdiatement, indiquant
   s'il a russi ou chou.

7. Fonctionnement interne

   Ce chapitre dlivre des informations, qui ne sont ni ncessaires 
   la comprhension du fonctionnement du multicast, ni ncessaires 
   l'criture de programmes multicast, mais qui deumeurent cependant
   trs intressantes car elles permettent une comprhension des
   concepts sur lesquels s'appuient le multicast et ses
   implmentations. Cela permet ainsi de contourner les erreurs les
   plus frquentes et de nombreuses incomprhensions.

  7.1. IGMP

   Lorsque nous avons parl de IP_ADD_MEMBERSHIP et de
   IP_DROP_MEMBERSHIP, nous avions dit que l'information dlivre
   tait utilise par le noyau pour accepter ou refuser les
   datagrammes multicast. Cela est vrai mais pas compltement. Une
   telle simplification impliquerait que les datagrammes multicast de
   tous les groupes multicast  travers le monde seraient reus par
   notre hte, et alors il vrifierait les souscriptions des
   processus s'excutant sur lui et dciderait s'il dlivre
   l'information ou non. Comme vous pouvez l'imaginer, cela serait du
   gaspillage de bande passante.

   De fait actuellement, un hte informe son routeur des groupes
   multicasts qui l'intressent ; alors, ce routeur informe  son
   tour les routeurs en amont qu'il souhaite recevoir le trafic en
   question, et ainsi de suite. Les algorithmes employs servant 
   demander le trafic d'un groupe donn, ou  l'inverse ceux pour
   terminer une souscription, peuvent varier. Cependant, il y a
   quelque chose qui ne change jamais : la manire dont cette
   information est transmisse. IGMP est utilis pour cela. IGMP
   signifie Internet Group Management Protocol. C'est un protocole
   similaire par de nombreux aspects  ICMP. Il porte un numro de
   protocole gal  2 et ses messages sont transports dans des
   datagrammes IP. Tous les htes compatibles multicast niveau 2
   doivent implmenter ce protocole.

   Comme dit prcdemment, IGMP est utilis aussi bien par les htes
   pour donner des informations de souscription  ses routeurs, que
   par les routeurs pour communiquer entre eux. Par la suite, il ne
   sera question que des relations entre les htes et les routeurs,
   principalement parce que les informations dcrivant les
   communications entre routeurs (autres que celles provenant du
   source code de mrouted, RFC-1075) et dcrivant le protocole de
   routage multicast  distance-vecteur  sont maintenant obsoltes.
   mrouted implmente quant  lui une version de ce protocole non
   encore documente.

   La version 0 d'IGMP est spcifie dans le RFC-988 qui est
   maintenant obsolte. Plus personne n'utilise la version 0 de nos
   jours.

   La version 1 d'IGMP est dcrite dans le RFC-1112 et, bien qu'elle
   soit mise--jour par le RFC-2236 (IGMP version 2), elle est encore
   largement utilise.

   Le noyau Linux implmente compltement IGMP version 1 et en partie
   la version 2.

   Vous trouverez ci-dessous une description informelle du protocole.
   Vous pouvez consulter le RFC-2236 pour une description formelle,
   avec beaucoup de diagrammes d'tats et d'expiration de dlais.

   Tous les messages IGMP ont la structure suivante :

+-------------------------------------------------------------------------------------------------------------------------------+
| 0 |   |   |   |   |   |   |   |   |   | 1 |   |   |   |   |   |   |   |   |   | 2 |   |   |   |   |   |   |   |   |   | 3 |   |
|---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---|
| 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 0 | 1 |
|-------------------------------+-------------------------------+---------------------------------------------------------------|
|             Type              |     Temp max. de rponse      |                     contrle d'intgrit                      |
|-------------------------------------------------------------------------------------------------------------------------------|
|                                                       Adresse de groupe                                                       |
+-------------------------------------------------------------------------------------------------------------------------------+

   Dans le cas d'IGMP version 1 (appel ci-aprs IGMPv1) le champ
    temp maximum de rponse  est marqu comme  inutilis . Il est
   rempli de zros lors d'une mission et est ignor  la rception.
   De plus, cette version d'IGMP coupe le champ  type  en deux sous
   champs de longueur 4 bits :  version  et  type . Comme IGMPv1
   identifie un message d'interrogation de souscription comme tant
   0x11 (version 1, type 1) et IGMPv2 aussi, les 8 bits ont la mme
   signification.

   Je pense qu'il est plus instructif de donner d'abord une
   description d'IGMPv1 et de pointer ensuite les additions faites
   par IGMPv2.

    la lecture de la description faite ci-dessous, gardez  l'esprit
   qu'un routeur multicast reoit tous les datagrammes IP multicast.

    7.1.1. IGMP version 1

   Les routeurs mettent priodiquement des requtes IGMP sur les
   souscriptions des htes (IGMP Host Membership Queries). Ces
   requtes sont faites sur le groupe all-hosts (224.0.0.1) avec un
   TTL de 1, ceci toutes les 1 ou 2 minutes. Tous les htes
   supportant le multicast entendent cela, mais ne rpondent pas
   immdiatement pour viter une tempte de rponses. Au lieu de
   cela, ils dclenchent un compte  rebours pour chaque groupe
   auquel ils appartiennent, et cela sur l'interface sur laquelle ils
   ont reu la demande.

   Tt ou tard, le compte  rebours expirera sur un des htes, ce
   dernier envoiera alors un IGMP Host Membership Report (rsultat
   d'appartenance) avec un TTL de 1  l'adresse multicast du groupe
   devant tre rapport. Comme le rsultat est envoy au groupe, tous
   les htes qui ont rejoint ce dernier -et qui sont actuellement en
   train d'attendre que leur propre dlai expire- le recoive aussi.
   Alors, ces htes stoppent leur compte  rebours, et ne gnrent
   pas d'autres rapports. Un seul rapport est gnr - par l'hte
   ayant le dlai le plus court-, et cela est suffisant pour le
   routeur. Celui-ci doit seulement savoir s'il y a des membres de ce
   groupe dans le sous rseau, pas qui et combien ils sont.

   Lorsqu'aucune rponse n'est reue pour un groupe donn aprs un
   certain nombre de requtes, le routeur dduit qu'il n'y a pas de
   membre de ce groupe sur ce sous rseau, et de ce fait n'a pas 
   transmettre le trafic. Notez que pour IGMPv1 il n'y a pas de
   message de fin d'appartenance de groupe.

   Lorsqu'un hte rejoint un nouveau groupe, le noyau envoie un
   rapport concernant ce groupe, ainsi il n'est pas ncessaire
   d'attendre une ou deux minutes jusqu'a ce que la demande
   d'appartenance suivante soit formule. Comme vous pouvez le
   constater le paquet IGMP est gnr par le noyau comme tant une
   rponse  la commande IP_ADD_MEMBERSHIP, comme vu dans la section
   IP_ADD_MEMBERSHIP. Notez l'importance de l'adjectif nouveau : si
   la commande IP_ADD_MEMBERSHIP est effectue sur un hte dj
   membre de ce groupe, aucun paquet IGMP n'est envoy car nous
   recevons dj le trafic pour ce groupe ;  la place, un compteur
   sur le nombre d'utilisateurs de ce groupe est incrment.
   IP_DROP_MEMBERSHIP ne gnre aucun datagramme dans IGMPv1.

   Les requtes sur les souscriptions des htes sont identifies par
   le type 0x11, et les rapports d'appartenance par le type 0x12.

   Aucun rapport n'est envoy pour le groupe all-hosts.
   L'appartenance  ce dernier groupe est permanente.

    7.1.2. IGMP version 2

   L'ajout majeur dans cette version du protocole est l'inclusion de
   messages de fin d'appartenance de groupe (Leave Group message)
   not 0x17. La raison de cet ajout est d'viter un gaspillage de
   bande passante entre le moment o le dernier hte du sous-rseau
   quitte ses souscriptions et le moment o le routeur s'aperoit
   qu'il n'y a plus de membre de ce groupe prsent dans ce sous
   rseau (leave latency). Les messages de fin d'appartenance doivent
   tre adresss au groupe all-routers (224.0.0.2) plus qu'au groupe
   que l'on vient de quitter, car l'information n'a pas d'utilit
   pour les autres membres de ce groupe (les versions du noyau
   ultrieures  2.0.33 envoyent l'information au groupe ; et bien
   que cela ne porte pas prjudice aux htes, cela constitue une
   perte de temps car ces messages doivent tres traits, sans pour
   autant donner d'information utile). Il est  noter qu'il existe
   certains dtails subtiles  propos du moment o il est appropri
   ou non d'envoyer des Messages de fin d'appartenance ; si cela vous
   intresse, reportez-vous au RFC.

   Quant un router IGMPv2 reoit un message de fin d'appartenance de
   groupe, il envoie une requte  spcifique de groupe 
   (Group-Specific Queries) au groupe  quitter. Cela contitue un
   autre ajout. IGMPv1 n'a pas ces requtes spcifiques de groupes.
   Toutes ces requtes sont envoyes au groupe all-hosts. Le champ
   type de l'entte IGMP n'est pas amen  changer (0x11 comme
   prcdemment), mais le champ  adresse du groupe  est rempli avec
   l'adresse du groupe multicast  quitter.

   Le champ Temps Maximum de Rponse, qui dans IGMPv1 tait mis  0
   pour la transmission et ignor  la rception, devient
   significatif seulement dans les messages de requtes en
   appartenance (ou Membership Query). Ce champ informe du temps
   maximum allou en 1/10 de secondes avant l'envoi d'un rapport. Il
   est donc utilis comme mcanisme d'coute.

   IGMPv2 introduit un nouveau type de message : 0x16. Il s'agit d'un
    rapport d'appartence IGMPv2  envoy par les htes IGMPv2 si
   ceux-ci dtectent qu'un routeur IGMPv2 est prsent (un hte IGMPv2
   sait qu'un routeur IGMPv1 est prsent s'il reoit une requte avec
   le champ  Rponse Max   0).

   Lorsque plus d'un routeur se rclame comme agissant en
   interrogateur, IGMPv2 fournit un mcanisme pour courter les
   discussions : le routeur possdant la plus petite adresse IP est
   dsign comme tant l'interrogateur. Les autres routeurs restent 
   l'coute d'ventuels dpassements de temps de rponse. Ainsi, si
   le routeur ayant la plus petite adresse IP  tombe  ou est
   teint, la dcision pour connaitre le nouvel interrogateur est
   prise aprs que les dlais aient expir.

  7.2. Aspects concernant le noyau

   Cette sous-section donne le point de dpart de l'tude de
   l'implmentation du multicast dans le noyau Linux. Cela n'explique
   pas l'implmentation faite. Elle indique juste o trouver les
   lments.

   L'tude a t mene sur la version 2.0.32, de ce fait il se peut
   qu'elle soit dpasse au moment o vous allez la lire (le code
   rseau du noyau semble avoir beaucoup chang dans les versions
   2.1.x).

   Le code multicast dans les noyaux Linux est toujours entour par
   une paire de balises #ifdef CONFIG_IP_MULTICAST / #endif, de cette
   faon vous pouvez l'inclure ou l'exclure de votre noyau selon vos
   besoins (cette inclusion/exclusion est faite  l'tape de
   compilation, comme vous le savez probablement... Les #ifdefs sont
   interprts par le pr-processeur. La dcision est prise selon les
   choix que vous avez effectus lors du make config, make menuconfig
   ou make xconfig).

   Vous dsirez probablement activer les fonctionnalits multicast,
   mais si votre machine Linux n'a pas  se comporter comme un
   routeur multicast, vous n'aurez srement pas besoin d'activer le
   routage multicast du noyau. Le code concernant le routage
   multicast est contenu entre la paire de balises #ifdef
   CONFIG_IP_MROUTE / #endif.

   Les sources du noyau sont couramment places dans le rpertoire
   /usr/src/linux. Cependant, l'emplacement peut changer, de ce fait
   l'emplacement du rpertoire de base des sources du noyau sera
   design ici comme tant LINUX. De ce fait, LINUX/net/ipv4/udp.c
   correspond  /usr/src/linux/net/ipv4/udp.c si vous avez extrait
   les sources du noyau dans le rpertoire /usr/src/linux.

   Toutes les interfaces multicast dsignes dans cette section et
   ddies  la programmation d'applications multicast, s'utilisent
   au travers des appels systmes setsockopt() / getsockopt().

   L'un comme l'autre est implment au moyen de fonctions qui
   effectuent quelques tests pour vrifier les paramtres qui leurs
   sont passs et qui,  tour de rle, appellent une autre fonction
   qui effectue quelques tests complmentaires, dmultiplexant
   l'appel pass dans le paramtre level pour chaque appel systme,
   et appelle alors une autre fonction qui... (si vous tes intress
   par tous ces sauts, vous pouvez les suivre dans LINUX/net/socket.c
   (fonctions sys_socketcall() et sys_setsockopt()),
   LINUX/net/ipv4/af_inet.c (fonction inet_setsockopt()) et
   LINUX/net/ipv4/ip_sockglue.c (fonction ip_setsockopt())).

   Le fichier qui nous intresse ici est
   LINUX/net/ipv4/ip_sockglue.c. Nous y trouvons ip_setsockopt() et
   ip_getsockopt() qui sont essentiellement des switchs (aprs
   quelques vrifications d'erreurs) vrifiant chaque valeur possible
   pour optname. Tout comme les options unicast, les options
   multicast sont captures : IP_MULTICAST_TTL, IP_MULTICAST_LOOP,
   IP_MULTICAST_IF, IP_ADD_MEMBERSHIP et IP_DROP_MEMBERSHIP. Avant le
   switch, un test est fait pour savoir si les options sont
   spcifiques au routeur multicast, et dans ce cas, elles sont
   rediriges vers les fonctions ip_mroute_setsockopt() et
   ip_mroute_getsockopt() (fichier LINUX/net/ipv4/ipmr.c).

   Dans le fichier LINUX/net/ipv4/af_inet.c nous pouvons voir les
   valeurs par dfaut -dont nous parlions dans les sections
   prcdentes (loopback activ, TTL=1)- donnes  la prise rseau
   lorsqu'elle est cre (prises depuis la fonction inet_create() de
   ce fichier) :

 #ifdef CONFIG_IP_MULTICAST
   sk->ip_mc_loop=1;
   sk->ip_mc_ttl=1;
  *sk->ip_mc_name=0;
   sk->ip_mc_list=NULL;
 #endif

   L'assertion stipulant que  la fermeture d'une prise rseau
   implique que le noyau n'accepte plus les souscriptions faites par
   cette prise  est corrobore par :

 #ifdef CONFIG_IP_MULTICAST
 /* Les applications oublient de quitter les groupes avant de partir */
   ip_mc_drop_socket(sk);
 #endif

   Extrait de la fonction inet_release(), dans le mme fichier que
   prcdemment.

   Les oprations indpendantes de la couche de liaison et relatives
   aux priphriques sont gardes dans le fichier
   LINUX/net/core/dev_mcast.c.

   Deux fonctions sont encore manquantes : les fonctions concernant
   le tratement des paquets multicast en entre et en sortie. Comme
   tous les autres paquets, les paquets entrants sont transmis depuis
   les pilotes de priphriques  la fonction ip_rcv()
   (LINUX/net/ipv4/ip_input.c). Cette fonction contient le filtrage
   parfait appliqu aux paquets multicasts qui ont pass la couche du
   priphrique (souvenez-vous que les couches les plus basses ne
   fournissent qu'un filtrage approximatif et ce n'est que la couche
   IP qui sait  100% si nous sommes intresss ou non par ce groupe
   multicast). Si l'hte fonctionne comme un routeur multicast, alors
   la fonction dcide aussi si le paquet doit tre transmis. Il
   appelle alors ipmr_forward(). Cette dernire fonction est
   implmente dans le fichier LINUX/net/ipv4/ipmr.c.

   Le code se chargeant des paquets mis en sortie est contenu dans
   le fichier LINUX/net/ipv4/ip_output.c. On y trouve l'effet
   possible de l'option des IP_MULTICAST_LOOP, selon que l'on
   souhaite ou non faire une boucle locale (fonction
   ip_queue_xmit()). Ainsi la valeur du TTL du paquet sortant est
   donn selon qu'il s'agit d'un paquet unicast ou multicast. Dans ce
   dernier cas, la valeur de l'argument IP_MULTICAST_TTL pass en
   option est utilise (fonction ip_build_xmit()).

   Durant un travail  l'aide de mrouted (un programme fournissant
   des informations lies au noyau sur la faon de router des
   datagrammes multicast), nous avons dtect que les paquets
   multicast provenant du rseau local sont routs correctement
   excepts ceux venant de la machine Linux agissant en tant que
   routeur multicast ! ip_input.c fonctionne bien, mais il semble que
   ce n'est pas le cas de ip_output.c. En lisant le code source des
   fonctions de sorties, nous avons trouv que les paquets sortant
   n'taient pas passs  ipmr_forward(), fonction dcidant si les
   paquets doivent tre routs ou non. Les paquets sont sortis sur le
   rseau local mais, comme les cartes rseaux sont le plus souvent
   incapables de lire les donnes transmises, ces datagrammes ne sont
   alors jamais routs. Nous avons ajout le code ncessaire  la
   fonction ip_build_xmit() et le tour tait jou. (Disposer du code
   source du noyau n'est pas un luxe, mais une ncessit !)

   ipmr_forward() a dj t mentionn un certain nombre de fois.
   C'est une fonction importante car elle permet de rsoudre un
   important problme de comprhension ncessitant d'tre plus
   largement expliqu. En routant du trafic multicast, ce n'est pas
   mrouted qui fabrique les copies puis les expdie  ses propres
   destinataires. mrouted reoit tout le trafic multicast et, bas
   sur cette information, calcule les tables de routages multicast
   puis informe le noyau de la manire de router :  les datagrammes
   pour ce groupe provenant de cette interface doivent tre
   transfrs  ces interfaces . Cette information est transmise au
   noyau par l'appel de setsockopt() sur la file d'une prise rseau
   ouverte par le daemon mrouted (le protocole spcifi lors de la
   cration de la file de la prise rseau doit tre IPPROTO_IGMP). La
   prise en compte d'options s'effectue par l'appel  la fonction
   ip_mroute_setsockopt() de LINUX/net/ipv4/ipmr.c. Cette premire
   option (il est prfrable de les appeler commandes plutt
   qu'options) provenant de cette prise rseau doit tre MRT_INIT.
   Toutes les autres commandes sont ignores (retournant -EACCES) si
   MRT_INIT n'est pas prcis en premier. Seulement une seule
   instance de mrouted peut tre excute  la fois sur un mme hte.
   Pour garder une trace de cela, lorsque le premier MRT_INIT est
   reu, une variable importante, struct sock* mroute_socket, est
   pointe sur la prise rseau ou le MRT_INIT a t reu. Si
   mroute_socket n'est pas nul lors de l'attente d'un MRT_INIT cela
   signifie qu'un autre mrouted est en cours d'excution, un
   -EADDRINUSE est alors renvoy. Toutes les commandes s'appuyant sur
   le mme principe (MRT_DONE, MRT_ADD_VIF, MRT_DEL_VIF, MRT_ADD_MFC,
   MRT_DEL_MFC et MRT_ASSERT) retournent -EACCES si elles proviennent
   d'une prise rseau diffrente de mroute_socket.

   Comme les datagrammes multicast routs peuvent tre reus/envoys
   au travers d'interfaces physiques ou de tunnels, une abstraction
   commune a t dfinie : les VIFs, InterFaces Virtuelles (ou
   Virtual InterFaces). mrouted communique les structures VIFs au
   noyau, en indiquant les interfaces physiques ou tunnels pour qu'il
   les ajoute  sa table de routage. Les entres de retransmissions
   multicast indiquent o transmettre les datagrammes.

   Les VIFs sont ajoutes  l'aide de MRT_ADD_VIF et supprimes avec
   MRT_DEL_VIF. L'un comme l'autre passent un struct vifctl au noyau
   (dfini dans /usr/include/linux/mroute.h) avec les informations
   suivantes :

 struct vifctl {
   vifi_t  vifc_vifi;             /* Index du VIF */
   unsigned char vifc_flags;      /* Attributs VIFF_ */
   unsigned char vifc_threshold;  /* Seuil du ttl */
   unsigned int vifc_rate_limit;  /* Valeur de dbit limite : non implment */
   struct in_addr vifc_lcl_addr;  /* Notre adresse */
   struct in_addr vifc_rmt_addr;  /* Adresse du tunnel IPIP */
 };

   Avec cette information une structure vif_device est construite :

 struct vif_device
 {
   struct device   *dev;                   /* le priphrique que nous utilisons */
   struct route    *rt_cache;              /* Tunnel route cache */
   unsigned long   bytes_in,bytes_out;
   unsigned long   pkt_in,pkt_out;         /* Statistiques */
   unsigned long   rate_limit;             /* Forme du trafic ; non implment */
   unsigned char   threshold;              /* seuil du TTL */
   unsigned short  flags;                  /* attributs de contrle */
   unsigned long   local,remote;           /* Adresses(distantes pour les tunnels)*/
 };

   Notez l'entre dev dans la structure. La structure device est
   dfinie dans le fichier /usr/include/linux/netdevice.h. C'est une
   grosse structure, mais le champ qui nous intresse est :

 struct ip_mc_list*    ip_mc_list;   /* chane des filtres IP multicast */

   La structure ip_mc_list -dfinie dans /usr/include/linux/igmp.h-
   est comme suit :

 struct ip_mc_list
 {
   struct device *interface;
   unsigned long multiaddr;
   struct ip_mc_list *next;
   struct timer_list timer;
   short tm_running;
   short reporter;
   int users;
 };

   Ainsi, le membre ip_mc_list de la structure dev est un pointeur
   sur une liste chane de structures ip_mc_list, chacune contenant
   une entre pour chaque groupe multicast pour laquelle l'interface
   est membre. Ici nous voyons une fois de plus que les appartenances
   sont associes  des interfaces. LINUX/net/ipv4/ip_input.c
   parcourt cette liste chane pour dcider si le datagramme reu
   est destin  un groupe auquel l'interface appartient :

 #ifdef CONFIG_IP_MULTICAST
   if(!(dev->flags&IFF_ALLMULTI) && brd==IS_MULTICAST
      && iph->daddr!=IGMP_ALL_HOSTS
      && !(dev->flags&IFF_LOOPBACK))
   {
     /*
      * Verification de l'appartenance  un de nos groupes
      */
      struct ip_mc_list *ip_mc=dev->ip_mc_list;
      do
      {
        if(ip_mc==NULL)
        {
          kfree_skb(skb, FREE_WRITE);
          return 0;
        }
        if(ip_mc->multiaddr==iph->daddr)
          break;
        ip_mc=ip_mc->next;
      }
      while(1);
   }
 #endif

   Le champ users de la strucuture ip_mc_list est utilis pour
   implmenter ce que nous avons dit dans la section IGMP version 1 :
   si un processus joint un groupe et que l'interface est dj membre
   de ce groupe (ie, un autre processus joint le mme groupe sur la
   mme interface que prcdemment) seul le compteur du nombre de
   membres (users) est incrment. Aucun message IGMP n'est envoy,
   comme vous pouvez le voir dans le code suivant (extrait de
   ip_mc_inc_group(), appel par ip_mc_join_group(), provenant du
   fichier LINUX/net/ipv4/igmp.c) :

 for(i=dev->ip_mc_list;i!=NULL;i=i->next)
   {
     if(i->multiaddr==addr)
     {
       i->users++;
       return;
     }
   }

    chaque suppression d'une souscription de groupe, le compteur est
   dcrment. Des oprations supplmentaires sont appliques
   seulement si le compteur est devient gal  0 (fonction
   ip_mc_dec_group()).

   MRT_ADD_MFC et MRT_DEL_MFC ajoutent ou suppriment des entres de
   retransmission dans la table de routage multicast. L'un comme
   l'autre passent un struct mfcctl au noyau (dfini dans
   /usr/include/linux/mroute.h) avec cette information :

 struct mfcctl
 {
   struct in_addr mfcc_origin;       /* Origine du mcast      */
   struct in_addr mfcc_mcastgrp;     /* Groupe en question    */
   vifi_t  mfcc_parent;              /* O cela arrive     */
   unsigned char mfcc_ttls[MAXVIFS]; /* O cela va t-il    */
 };

   Avec toute cette information en main, ipmr_forward() parcourt les
   VIFs, et si une correspondance est trouve, on duplique le
   datagramme et on appelle ipmr_queue_xmit() qui,  tour de rle,
   utilise le priphrique de sortie indiqu par la table de routage
   et une adresse de destination propre si le paquet est  envoyer au
   travers d'un tunnel (il s'agit en fait de l'adresse de destination
   unicast de l'autre cot du tunnel).

   La fonction ip_rt_event() (qui n'est pas directement apparente 
   la sortie des datagrammes, mais qui se trouve pourtant dans
   ip_output.c) reoit les vnements relatifs aux priphriques
   rseaux, tel que le branchement du priphrique par exemple. Cette
   fonction assure que le priphrique joint bien le groupe multicast
   ALL-HOSTS.

   Les fonctions IGMP sont implmentes dans le fichier
   LINUX/net/ipv4/igmp.c. Les informations importantes concernant ces
   fonctions se trouvent dans /usr/include/linux/igmp.h et
   /usr/include/linux/mroute.h. L'entre IGMP dans le rpertoire
   /proc/net est cre  l'aide de la fonction ip_init() contenue
   dans le fichier LINUX/net/ipv4/ip_output.c.

8. Politiques de routage et techniques de retransmission

   Un algorithme trivial pour rendre le trafic multicast disponible
   partout est de l'envoyer... partout, sans se soucier des besoins
   des utilisateurs. Comme cela ne semble pas tre bien optimis,
   plusieurs algorithmes de routage et techniques de retransmission
   ont t implments.

   DVMRP (Distance Vector Multicast Routing Protocol, ou Protocole de
   routage multicast bas sur des vecteurs de distances) est,
   peut-tre, le plus utilis par les routeurs multicast de nos
   jours. Il s'agit d'un protocole de routage en mode dense, de fait,
   il convient bien dans les environnements  large bande passante et
   dont les membres sont densment distribus. Cependant, dans des
   scnarios moins denses, il souffre de problmes de changement
   d'chelles.

   Il existe d'autres protocoles de routage denses, tels que MOSPF
   (Extentions multicast  OSPF -Open Shortest Path First) et PIM-DM
   (Protocol-Independent Multicast Dense Mode).

   Pour pouvoir faire du routage dans un environnement conome, il
   existe PIM-SM (Protocol Independent Multicast Sparse Mode) et CBT
   (Core Based Tree).

   OSPF version 2 est expliqu dans les RFC 1583, et MOSPF dans le
   RFC 1584. Les spcifications de PIM-SM et CBT peuvent tre
   trouves respectivement dans les RFC 2117 et 2201.

   Tous ces protocoles de routage utilisent diffrents types de
   retransmissions multicast, tels que le flooding (technique par
   indondation), RTB (ou Reverse Path Broadcasting), TRPB (ou
   Truncated Reverse Path Broadcasting), RPM (ou Reverse Path
   Multicasting) ou Shared Trees.

   Il serait trop long d'expliquer toutes ces techniques ici et,
   comme de courtes descriptions sont publiquement disponibles, je
   vous recommende la lecture du texte draft-ietf-mboned-in.txt.

   De mme vous pouvez trouver les RFCs correspondants, expliquant en
   dtails toutes les techniques et politiques employes.

9. Protocoles de transport multicast

   Jusqu' prsent nous avons parl des transmissions multicast via
   UDP. Cela est une pratique courante, car il est impossible de
   faire de mme avec TCP. Cependant, une recherche importante a lieu
   depuis un certain nombre d'annes et dont le but est de dvelopper
   de nouveaux protocoles de transport multicast.

   Plusieurs de ces protocoles ont t implments et tests. Une
   bonne leon  tirer est qu'il ne semble pas y avoir de protocoles
   de transport multicast gnriques et suffisament bons pour tous
   les types d'applications multicast.

   Si les protocoles de transports sont complexes et difficiles 
   optimiser, imaginez une faon de grer les dlais, la perte de
   donnes, l'ordonnancement, les retransmissions, le contrle de
   flux et des congestions, le management des groupes, etc, lorsque
   le destinataire n'est pas unique, mais peut tre constitu de
   centaines ou de milliers d'htes disperss. Le changement
   d'chelle est donc un problme. De nouvelles techniques sont 
   implmenter, tel que ne pas dlivrer des accuss de rception 
   chaque paquet reu mais,  la place, envoyer des accuss de
   non-rception (negative acknowledges, ou NACKs) pour les donnes
   qui n'ont pas t reues. Le RFC 1458 donne des propositions
   relatives aux conditions ncessaires  l'implmentation de tels
   protocoles multicasts.

   Donner la description de ces protocoles multicast sort de la
   porte de cette section.  la place, vous trouverez ci-dessous les
   noms de certains d'entre eux et quelques sources d'informations
   complmentaires : RTP, le protocole de transport temps-rel (ou
   Real-Time Transport Protocole) concerne les confrences multimdia
   multi-partite, SRM (Scalable Reliable Multicast) est utilis par
   wb (l'outil servant de tableau blanc partag, voyez la section
   applications multicast), URGC (Uniform Reliable Group
   Communication Protocol) permet des transactions fiables et
   ordonnes -ce protocole est bas sur un contrle centralis-, Muse
   a t dvelopp comme un protocole d'application spcifique au
   transfert de nouvelles (articles) au travers du MBone, le MFTP
   (Protocole Multicast de Transport de Fichiers, ou Multicast File
   Transport Protocol) se dcrit de lui-mme ; les personnes
    joignent  un transfert de fichier (prcdemment annonc) de la
   mme faon qu'ils joignent une confrence, LBRM (Log-Based
   Receiver-reliable Multicast) est un protocole curieux qui permet
   de garder une trace de tous les paquets envoys par un serveur
    loggant  ces derniers -ce serveur indique  l'metteur s'il
   doit retransmettre les donnes ou s'il peut les supprimer
   proprement dans le cas o tous les destinataires ont bien reu les
   donnes. Un protocole avec un drle de nom -spcialement pour un
   protocole multicast- est STORM (STructure-Oriented Resilient
   Multicast). De nombreux protocoles multicast peuvent tre trouvs
   en cherchant sur Internet, de mme que d'intressants papiers
   proposant de nouveaux champs d'applications au Multicast (par
   exemple, la distribution de pages web en multicast).

   Une bonne page fournissant des comparaisons entre les diffrents
   protocoles multicastes fiables est
   http://www.tascnets.com/mist/doc/mcpCompare.html.

   Un trs bon site ( jour !), avec des liens intressants (Internet
   drafts, RFCs, papiers, liens vers d'autres sites) est :
   http://research.ivv.nasa.gov/RMP/links.html.

   http://hill.lut.ac.uk/DS-Archive/MTP.html est aussi une bonne
   source d'informations sur ce sujet.

   L'article de Katia Obraczka  Multicast Transport Protocols: A
   Survey and Taxonomy  donne de courtes descriptions pour chaque
   protocole et essaye de les classifer selon diverses
   fonctionnalits. Vous pouvez le lire dans le magazine IEEE
   Communication, Janvier 1998, vol 36, No 1.

10. Bibliographie

  10.1. RFCs

     o RFC 1112  Host Extensions for IP Multicasting . Steve
       Deering. Aot 1989.

     o RFC 2236  Internet Group Management Protocol, version 2 . W.
       Fenner. Novembre 1997.

     o RFC 1458  Requirements for Multicast Protocols . Braudes, R
       and Zabele, S. Mai 1993.

     o RFC 1469  IP Multicast over Token-Ring Local Area Networks .
       T. Pusateri. Juin 1993.

     o RFC 1390  Transmission of IP and ARP over FDDI Networks . D.
       Katz. Janvier 1993.

     o RFC 1583  OSPF Version 2 . John Moy. Mai 1994.

     o RFC 1584  Multicast Extensions to OSPF . John Moy. Mai 1994.

     o RFC 1585  MOSPF: Analysis and Experience . John Moy. Mai
       1994.

     o RFC 1812  Requirements for IP version 4 Routers . Fred
       Baker, Editor. Juin 1995.

     o RFC 2117  Protocol Independent Multicast-Sparse Mode
       (PIM-SM): Protocol Specification . D. Estrin, D. Farinacci,
       A. Helmy, D. Thaler; S. Deering, M. Handley, V. Jacobson, C.
       Liu, P. Sharma, and L. Wei. Juillet 1997.

     o RFC 2189  Core Based Trees (CBT version 2) Multicast
       Routing . A. Ballardie. Septembre 1997.

     o RFC 2201  Core Based Trees (CBT) Multicast Routing
       Architecture . A. Ballardie. Septembre 1997.

  10.2. Brouillons Internet (Internet Drafts)

     o  Introduction to IP Multicast Routing .
       draft-ietf-mboned-intro-multicast-03.txt. T. Maufer, C.
       Semeria. Juillet 1997

     o  Administratively Scoped IP Multicast .
       draft-ietf-mboned-admin-ip-space-03.txt. D. Meyer. 10 Juin
       1997.

  10.3. Pages web

     o Page d'accueil du Multicast sous Linux.
       http://web.archive.org/web/20010209032950/http://www.cs.washington.edu/homes/esler/multicast/
       [http://web.archive.org/web/20010209032950/http://www.cs.washington.edu/homes/esler/multicast/]

     o Foire Aux Questions (FAQ) Multicast sous Linux.
       http://andrew.triumf.ca/pub/linux/multicast-FAQ
       [http://andrew.triumf.ca/pub/linux/multicast-FAQ]

     o Multicast et MBONE sous Linux.
       http://web.archive.org/web/19990128143933/http://www.teksouth.com/linux/multicast/
       [http://web.archive.org/web/19990128143933/http://www.teksouth.com/linux/multicast/]

     o Liens sur les protocoles multicast fiables
       http://www.nard.net/~tmont/rm-links.html
       [http://www.nard.net/~tmont/rm-links.html]

     o Protocoles de Transport Multicast
       http://web.archive.org/web/20020124084206/http://hill.lut.ac.uk/DS-Archive/MTP.html
       [http://web.archive.org/web/20020124084206/http://hill.lut.ac.uk/DS-Archive/MTP.html]

  10.4. Livres

     o  TCP/IP Illustrated: Volume 1 The Protocols . Stevens, W.
       Richard. Addison Wesley Publishing Company, Reading MA, 1994

     o  TCP/IP Illustrated: Volume 2, The Implementation . Wright,
       Gary and W. Richard Stevens. Addison Wesley Publishing
       Company, Reading MA, 1995

     o  UNIX Network Programming Volume 1. Networking APIs: Sockets
       and XTI . Stevens, W. Richard. Second Edition, Prentice Hall,
       Inc. 1998.

     o  Internetworking with TCP/IP Volume 1 Principles, Protocols,
       and Architecture . Comer, Douglas E. Second Edition, Prentice
       Hall, Inc. Englewood Cliffs, New Jersey, 1991

11. Licence et mise en garde

   Copyright  1998 Juan-Mariano de Goyeneche pour la version
   originale.

   Copyright  2003 Antoine Duval & Fabrice Gadaud pour la version
   franaise.

   Ce guide pratique est un document libre ; vous pouvez le
   redistribuer et le modifier selon les termes de la Licence
   publique gnrale GNU (GPL) telle que publie par la Free Software
   Foundation, dans sa version 2, ou (a votre souhait) toute version
   ultrieure.

   Ce document est distribu dans l'espoir qu'il vous soit utile,
   mais sans aucune garantie ; sans mme la garantie implicite de la
   valeur marchande ou de l'utilisation dans un but particulier.
   Consultez la Licence publique gnrale GNU (GPL) pour plus de
   dtails.

   Vous pouvez obtenir une copie de cette licence en crivant  la
   Free Software Foundation, 59 Temple Place - Suite 330, Boston, MA
   02111-1307, USA.

   Si vous publiez ce document sur un CD-ROM ou sous la forme d'une
   copie physique, une copie complmentaire sera la bienvenue ;
   envoyez-moi un courrier lectronique (en anglais)  l'adresse
   <jmseyas CHEZ dit POINT upm POINT es>. N'hesitez pas non plus 
   faire une donation au Projet de documentation Linux (LDP) ou  la
   Free Software Foundation pour apporter votre soutien au projet de
   documentation libre pour Linux/GNU. Contactez le Projet de
   documentation Linux <feedback CHEZ en POINT tldp POINT org> pour
   plus d'informations.

