Le multicast
Transcription
Le multicast
à l’Université Pierre et Marie Curie, le 5 octobre 2004 Plan M2 Informatique Réseaux ■ ■ Multimédia et Qualité de Service ■ ■ Introduction Le multicast au niveau réseau Le multicast au niveau transport Perspectives de recherche Cours 2 : Le multicast Timur FRIEDMAN à partir des transparents de Kim THAI, avec modifications Copyright 2004 by Timur Friedman Copyright 2004 by Timur Friedman 1 2 Qu’est-ce que le multicast ? Plan ■ Introduction ■ ■ ■ ■ ■ ■ ■ Définition Notion de groupe Problématique ■ moyen efficace de communication 1-vers-N multicast vs. unicast et broadcast ■ ■ Le multicast au niveau réseau Le multicast au niveau transport Perspectives de recherche ■ unicast : une seule source vers une seule destination multicast : une seule source vers un sous-ensemble de destinataires broadcast : une seule source vers toutes les destinations unicast (1-ver s-1) mult icast (1-ver s-N ) Copyright 2004 by Timur Friedman br oadcast (1-ver s-t ous) Copyright 2004 by Timur Friedman 3 4 Pourquoi le multicast ? (1/3) Des applications pour le multicast ■ t emps r éel int er act if f iabilit é 100% dist r ibut ion mult imédia distribution utilisant TCP/IP dist r ibut ion de document s S R1 R2 D1 R4 D5 200 ms ■ ■ ■ conférence délai de l’ordre de 100 ms tolérance d’un certain taux de pertes ■ 20 s t emps de r éponse 2s flux continus, temps réel, non interactifs, unidirectionnels ■ ■ ■ R3 distribution de logiciels fiabilité de 100% peu de contraintes temporelles D4 D2 ■ résultats ■ ■ Copyright 2004 by Timur Friedman 5 ■ D3 plusieurs copies du même paquet plusieurs buffers Copyright 2004 by Timur Friedman plusieurs connexions 6 Pourquoi le multicast ? (2/3) ■ Pourquoi le multicast ? (3/3) distribution utilisant un multicast ■ S ■ ■ R1 ■ R2 D1 R4 D5 R3 D4 D2 ■ ■ ■ ■ D3 résultats ■ ■ une seule copie de chaque paquet un seul buffer Copyright 2004 by Timur Friedman une seule connexion multicast Copyright 2004 by Timur Friedman 7 Notion de groupe de multicast ■ ■ ■ 8 Adresses de multicast IP (1/2) comment identifier les récepteurs d’un paquet Mcast ■ ■ en unicast : une adresse IP de destination ici, toutes les adresses de destination ??? une abstraction : le groupe de multicast ■ un groupe de multicast : une adresse de classe D A 0 réseau B 10 C 110 associe un ensemble d’émetteurs et de récepteurs existe indépendamment des émetteurs et récepteurs station réseau station réseau D 1110 station adresse multicast de 224.0.0.0 11100000 00000000 00000000 00000000 ... .. . ■ utilise la bande passante de façon efficace prévient la congestion du réseau minimise la charge des serveurs fournit l’information à davantage d’utilisateurs simultanément touche un nombre quelconque de personnes en une seule fois etc. chaque récepteur reçoit les paquets de chaque émetteur émet t eur s à 239.255.255.255 11101111 11111111 11111111 11111111 ■ ■ r écept eur s gr oupe de mult icast ■ Copyright 2004 by Timur Friedman Copyright 2004 by Timur Friedman 9 Adresses de multicast IP (2/2) ■ adressage du groupe S S des questions... ■ données à Mcaster ■ ■ ■ D D D ■ ■ D ■ 10 Multicast : les problèmes @ IP source 224.1.2.3 D ■ ■ les r écept eur s s’abonnent à l’adr esse de gr oupe 224.1.2.3 découvrir l’ensemble des groupes Mcast courants exprimer le souhait de recevoir les paquets d’un groupe découvrir l’ens. des récepteurs d’un groupe Copyright 2004 by Timur Friedman délivrer les données à chaque membre du groupe ■ ■ quand et comment un groupe naît-il et prend-il fin ? quand et comment l’@ groupe est-elle choisie ? comment de nouvelles stations se joignent-elles à un groupe ? y-a-t-il des conditions pour l’appartenance à un groupe ? comment les routeurs interopèrent-ils pour délivrer les paquets ? des choix... ■ indirection d’adresse chaque hôte a sa propre @IP, indépendante de l’@groupe dissociation des problèmes ■ ■ ■ ■ 224.0.0.0 : non utilisée 224.0.0.1 : représente l’ens. des stations du sous-réseau considéré il n’y a pas d’adresse pour l’ens. des machines de l’Internet un récepteur doit pouvoir joindre ou quitter un groupe en cours de transmission un récepteur doit pouvoir joindre ou quitter un groupe sans le signaler explicitement aux émetteurs des constats.... ■ les hôtes récepteurs sont souvent connectés à des réseaux locaux... Copyright 2004 by Timur Friedman 11 12 Plan ■ ■ Introduction Le multicast au niveau réseau ■ ■ ■ ■ ■ ■ ■ Multicast sur un LAN (1/3) ■ l’existant (cas d’Ethernet) ■ Le multicast sur un LAN Le protocole IGMP Le modèle de service Les algorithmes de routage multicast Les protocoles de routage multicast ■ ■ ■ Le multicast au niveau transport Perspectives de recherche Ethernet repose sur un support à diffusion chaque station a une carte réseau avec une @ matérielle spécifique il existe une adresse de diffusion (FF:FF:FF:FF:FF:FF) que faire si l’on souhaite joindre uniquement un sousensemble de stations ? ■ ■ ex : H1 souhaite envoyer un paquet Mcast à H2 et H4 qui sont sur le même réseau que lui deux possibilités... Copyright 2004 by Timur Friedman Copyright 2004 by Timur Friedman 13 Multicast sur un LAN (2/3) ■ Multicast sur un LAN (3/3) de réseau utilise le multicast le broadcast de liaison ■ @ de H1 FF.FF.FF.FF.FF.FF paquet IP multicast ■ H2 H3 IP IP IP IP Et her net Et her net Et her net Et her net ... H1 H2 format des adresses multicast Ethernet de 01:00:5e:00:00:00 0000 0001 0000 0000 0101 1110 0000 0000 0000 0000 0000 0000 à 01:00:5e:7f:ff:ff 0000 0001 0000 0000 0101 1110 0111 1111 1111 1111 1111 1111 ■ le multicast de réseau utilise le multicast de liaison @ de H1 @ MAC multicast traduction des adresses IP multicast en @ Ethernet ■ H4 .. . H1 14 mécanisme de traduction 1110 xxxx x paquet IP multicast H3 H4 IP IP IP IP Et her net Et her net Et her net Et her net ... 0000 0001 0000 0000 0101 1110 0 ➥ on sait Mcaster un paquet IP sur un LAN à diffusion ! Copyright 2004 by Timur Friedman Copyright 2004 by Timur Friedman 15 IGMP : Qu’est-ce que c’est ? IGMP Version 1 (1/1) ■ comment un routeur détermine-t-il si son LAN possède des récepteurs pour un groupe donné ? ■ Internet Group Management Protocol H H I GMP R I GMP R r out age mult icast gr ande dist ance ■ échange de messages query/report S2 @ IP source 224.9.9.9 H H R H $&% $&% $&% $ # H données @ destination r out age mult icast gr ande dist ance H I GMP H R RFC 1112 (Aug.89) S1 ... ■ ■ en-tête IP permet à un hôte d’indiquer à son routeur local qu’il souhaite joindre un groupe est utilisé sur les LAN à diffusion H ... H ... ■ 16 H ! " # '&% (% (% ( # H H I GMP Copyright 2004 by Timur Friedman Copyright 2004 by Timur Friedman 17 18 IGMP Version 1 (2/2) ■ IGMP Version 2 (1/2) risque de congestion ■ ■ étalement des réponses basé sur des temporisateurs ) R ■ envoi de la r equêt e query ■ H , * H H + ar mement du t empo r écept ion de la r éponse, désar mement du t empo 3 types de message type de message membership_query général spécifique membership_report leave_group report * RFC 2236 (Nov.97) un récepteur informe explicitement son routeur lorsqu’il quitte un groupe ar mement du t empo envoi de la r éponse - réduction du trafic sur le LAN si aucun membre ■ envoyé par but routeur routeur hôte hôte s’enquérir des groupes auxquels sont abonnés les hôtes demander si un groupe donné a des membres sur le LAN indiquer que l’hôte souhaite joindre ou a joint un groupe indiquer que l’hôte quitte un groupe donné étalement des réponses avec 0 / tempo / MaxRespTime . délai éventuel (qq s.) avant de recevoir les données Copyright 2004 by Timur Friedman Copyright 2004 by Timur Friedman 19 IGMP Version 2 (2/2) IGMP Version 3 en-tête IP S2 S1 @ IP source 224.9.9.9 H ■ 0 1 $&% $&% $&% $ # H ■ H R H ■ données @ destination r out age mult icast gr ande dist ance H 20 8:954; < en cours un récepteur peut sélectionner les sources qu’il souhaite (ne pas) entendre ! " # '&% (% (% ( # H H S1 Checksum $&% $&% $&% $@= ≠? # Multicast Group Address Copyright 2004 by Timur Friedman données H R H - réduction de la latence du 24345!673 @ IP source 224.9.9.9 @ destination H MaxRespTime en-tête IP S3 r out age mult icast gr ande dist ance H format du message type S2 H ! " # '&% (% (% (= H H >? # Copyright 2004 by Timur Friedman 21 Le modèle de service du multicast (1/5) ■ ■ Le modèle de service de multicast (2/5) P issu des travaux de Steve Deering caractéristiques de la transmission ■ ■ ■ 22 P multicast IP : transmission d’un paquet IP à un groupe d’hôtes identifié par une seule adresse de destination transmission ACBCDECBCF F GCH E caractéristiques du groupe ■ ■ ■ ■ ■ ■ P ■ ■ ■ H BCLB&J M BCH N OCH J M BCK Copyright 2004 by Timur Friedman l’émetteur ne contrôle pas qui joint le groupe il n’y a pas de contrôle sur qui envoie au groupe les paquets issus de plusieurs sources peuvent être reçus entrelacés 2 groupes différents peuvent choisir la même @ rôle des routeurs Mcast locaux ■ appartenance dynamique pas de restriction quant à la localisation et au # de membres un hôte peut être simultanément membre de plusieurs groupes un hôte n’a pas besoin de faire partie d’un groupe pour être source groupe permanent/transitoire l’opération de est IG&J K P co-résidents ou séparés des routeurs classiques un routeur local qui reçoit un paquet Mcast d’un de ses hôtes, avec un TTL>1, le fait suivre vers tous les sous-réseaux connectant des membres récepteurs sur les sous-réseaux destinataires, le routeur local termine la transmission en Mcastant le paquet en local Copyright 2004 by Timur Friedman 23 24 Le modèle de service de multicast (3/5) ■ Le modèle de service de multicast (4/5) le RFC 1112 spécifie les extensions à apporter à un hôte IP pour supporter le Mcast ■ les extensions pour l’envoi Mcast ■ 3 niveaux de conformité ■ ■ ■ ■ ■ ■ 0 : l’hôte ne supporte pas le Mcast 1 : l’hôte peut émettre à destination d’un groupe 2 : l’hôte supporte le Mcast en émission et réception ■ ■ ■ modèle d’implémentation IP d’un hôte modules de protocoles de utilisation de SendIP @ dest = @ de groupe le niveau supérieur doit pouvoir spécifier un TTL module IP y z{ |} ~ { { 4z y z @ ■ si IP-dest est sur le même réseau local alors envoyer le paquet en local à IP-dest sinon envoyer le paquet en local à GatewayTo (IP-dest) niveau sup. i j@k Vlmno VpSVXq Vl r i o VwWY s t uv s x uv QCR S T@U VXW Y i j@k Vlmno VpSVXq Vl r i o VpZ \] QCR S T@U V[Z \] ^ _ ` a b c ^ d e fag h (Ethernet) interface de service IP ■ ■ interface de service LAN module LAN ■ mécanisme de traduction des @IP Mcast en @MAC Mcast (ARP) Copyright 2004 by Timur Friedman Copyright 2004 by Timur Friedman 25 Le modèle de service du multicast (5/5) ■ Plan les extensions pour la réception Mcast ■ ■ ■ ■ ■ utilisation de ReceiveIP ajout de JoinHostGroup (group-address, interface) ajout de LeaveHostGroup (group-address, interface) Introduction Le multicast au niveau réseau ■ ■ ■ maintien de la liste des groupes dont l’hôte est membre pour chacune des interfaces (mise à jour avec les Join et Leave) intégration de IGMP et adhésion à 224.0.0.1 ■ ■ ■ ■ ajout de JoinLocalGroup (group-address) ajout de LeaveLocalGroup (group-address) ■ ■ module LAN ■ Le multicast sur un LAN Le protocole IGMP Le modèle de service Les algorithmes de routage multicast ■ interface de service LAN ■ ■ ■ module IP ■ ■ ■ interface de service IP ■ 26 mécanismes de filtrage par la carte souhaités ■ Shortest Path Tree Minimum Cost Tree Constrained Tree Les protocoles de routage multicast Le multicast au niveau transport Perspectives de recherche Copyright 2004 by Timur Friedman Copyright 2004 by Timur Friedman 27 Les algorithmes de routage multicast ■ ■ Les algorithmes SPT (1/2) objectif : calculer un arbre de liens connectant tous les routeurs ayant des hôtes appartenant au groupe buts : ■ ■ ✬ 28 ■ but : calculer un arbre ■ ■ minimiser la distance entre la source et chaque récepteur minimiser l’utilisation de liens dans le réseau ces buts ne sont pas compatibles ■ ■ ayant la source S pour racine couvrant tous les récepteurs Di du groupe tel que la distance entre S et Di soit minimum algorithmes de base ■ ■ Bellmann-Ford : à vecteurs de distance Dijkstra : à états des liens un arbre par émetteur Copyright 2004 by Timur Friedman Copyright 2004 by Timur Friedman 29 30 Les algorithmes SPT (2/2) Les algorithmes MCT (1/2) S S R1 R1 R3 D2 R5 D3 R4 R6 D4 R7 R9 R10 D6 R11 D7 ■ ■ but : minimiser le coût total de l’arbre 2 familles ■ R3 D2 3 R5 D3 4 R4 R6 D4 4 R7 R9 R10 D6 5 R11 D7 5 les algorithmes Minimum Spanning Tree ■ D1 R2 3 D1 R2 ■ R8 D5 un ex emple de t opologie 5 D5 R8 ■ i Di = Copyright 2004 by Timur Friedman 29, liens : 17 Copyright 2004 by Timur Friedman 32 Les algorithmes CT S S R1 R1 ■ D1 R2 R5 D2 D3 R4 5 D1 R2 R3 D2 3 R5 D3 4 ■ but : minimiser simultanément la dist(S, Di) et le coût total de l’arbre principe ■ ■ R6 R8 D5 D4 R9 R10 R11 D7 R7 6 D5 D6 l’ar br e obt enu avec un algor it hme à vect eur s de dist ance r q : dist (S, D6) = 5 la contrainte est levée problème NP-complet ils supposent de connaître toutes les liaisons du réseau ils sont monolithiques ils n’exploitent pas les informations déjà disponibles de routage unicast 31 Les algorithmes MCT (2/2) R3 les algorithmes Minimum Steiner Tree ■ l’ar br e obt enu avec un algor it hme à vect eur s de dist ance contrainte : l’arbre ne doit toucher aucun nœud qui ne soit pas membre du groupe (pas réaliste car les routeurs ne sont pas de membres) ex : algorithme de Prim R6 D4 5 R9 R10 R11 D7 7 associer à chaque lien 2 métriques (distance/délai et coût) rechercher l’arbre à coût minimum tel que dist(S, Di) D6 7 l’ar br e de St einer r q : dist (S, D6) = 7 i Di = 37, liens : 15 Copyright 2004 by Timur Friedman Copyright 2004 by Timur Friedman 33 Qu’appelle-t-on IP multicast ? ■ ■ 34 RPF (1/2) ■ mécanisme utilisé dans l’Internet pour construire un arbre de routage multicast 4 : et :4 : IGMP + protocole de routage Mcast ■ ■ ■ Reverse Path Forwarding (Source-based Routing) l’une des premières techniques utilisées but : construire un arbre ayant S comme racine et minimisant dist(S, Di) principe : utiliser l’inondation ( :4: 4 ) avec ■ si un paquet est reçu par l’if utilisée par le routeur pour joindre S alors le paquet est retransmis sur les autres if sinon le paquet est rejeté mécanisme simple ■ ■ ■ Copyright 2004 by Timur Friedman les informations utilisées sont celles du routage unicast Ri n’a pas à connaître les arbres recouvrants pas de mécanisme particulier pour arrêter l’inondation Copyright 2004 by Timur Friedman 35 36 RPF (2/2) Truncated Broadcasting (1/2) H1 F F H5 H17 H18 F F F F F R8 R12 F R11 F F H20 H21 H22 ■ H7 but : réduire le trafic sur les LAN feuilles idée : utiliser les informations d’appartenance fournies par IGMP pour déterminer s’il faut ou non Mcaster un paquet sur un LAN feuille ■ F F R9 H12 ■ forme d’élagage ( 7 ¡ ¢ ) des feuilles pas de réduction de trafic au cœur du réseau H13 F F F F H6 H8 H14 H15 R13 H19 F R4 F R5 F F ■ H3 F R6 R7 H2 F F F F F H11 F F R3 R2 H9 H16 F F H4 H10 R1 R10 F H23 H24 H25 Copyright 2004 by Timur Friedman H26 Copyright 2004 by Timur Friedman 37 Truncated Broadcasting (2/2) H1 H4 F H5 F F R1 R2 F H17 F F F H19 ■ ■ H13 ■ F ■ R10 ■ F H20 H21 H22 H23 H24 H25 Copyright 2004 by Timur Friedman RFC 1075 (Nov.88), draft Version 3 en cours £w ¤ :¦¥:¤ § Multicast Routing Protocol but : réduire le trafic au cœur du réseau principe : inondation et élagage ( 44: 4¨:©§&4 4 ) ■ H12 F H15 R11 F H18 H7 R9 F R13 ■ F H14 R8 R12 H6 H8 R5 F F R7 R4 F R6 ■ H3 F F F H10 H16 F DVMRP (1/6) H2 R3 H9 H11 F F 38 H26 s’il n’a pas de membre sur son LAN, un routeur feuille envoie un message prune à ses voisins un routeur feuille peut envoyer un prune sur toutes ses if, sauf celle correspondant à son SP avec la source (i.e. l’if RPF) quand un routeur intermédiaire reçoit un prune sur chacune de ses if, sauf l’if RPF, il remonte le prune en amont quand un routeur envoie un prune, il mémorise la paire (Source, Groupe) pour laquelle le prune a été envoyé Copyright 2004 by Timur Friedman 39 DVMRP (2/6) H1 H4 H5 F F F R1 R2 H16 H17 R12 P F F F F P F H21 H22 H23 H5 D P H10 H12 R9 H11 H13 F P R6 R12 H24 H25 R13 H26 H18 41 H19 H20 H7 H12 R9 H14 H13 H15 D R11 D Copyright 2004 by Timur Friedman H6 H8 R5 R8 D R10 H3 R4 D R7 H16 H17 L’ar br e apr ès élagage H2 R3 D H9 F R1 R2 H8 P F H4 D D H7 F H15 R11 H20 R5 P F R13 H19 P H1 H6 P R4 H14 R8 P P H18 R7 F P R6 F H11 F P F H3 F DVMRP (3/6) I nondat ion et élagage H2 R3 P F F H9 H10 F 40 R10 D H21 H22 H23 H24 Copyright 2004 by Timur Friedman H25 H26 42 DVMRP (4/6) H1 H4 H5 F R1 F F R3 H9 H10 H11 H16 H18 H13 F F H21 H22 H16 H23 R10 H25 H26 H18 H19 H20 R5 D D R9 H12 H13 H15 D R13 R11 D H24 H7 H8 H14 R8 R12 H17 Copyright 2004 by Timur Friedman D D R7 H6 R4 R6 D R11 H20 H11 H15 R13 H19 R9 H3 R2 H10 H12 L’ar br e apr ès la gr ef f e H2 R3 H9 G H14 R1 D F F D H8 R5 R8 R12 H17 H5 D D H7 G F R7 H6 R4 R6 H1 H4 H3 R2 F DVMRP (5/6) Gr ef f e H2 R10 D H21 H22 H23 H24 Copyright 2004 by Timur Friedman H25 H26 43 44 DVMRP (6/6) MOSPF problèmes communs aux protocoles à vecteurs de ■ distance (e.g. temps de convergence) processus périodique d’inondation et d’élagage pour chaque source mémorisation des enregistrements prune (Source, Groupe) ■ ■ RFC 1584 (March 94) Multicast Open Shortest Path First principe ■ ■ opère dans un AS qui utilise OSPF pour l’unicast étend OSPF en ajoutant les informations d’appartenance aux informations d’états des liens qui sont diffusées par OSPF problème : : :4 ¤ ª avec la taille du réseau ■ ■ mémorisation d’un enregistrement par groupe et par lien du réseau un arbre par source Copyright 2004 by Timur Friedman Copyright 2004 by Timur Friedman 45 CBT (1/3) ■ ■ ■ ■ ■ CBT (2/3) RFC 2189 et 2201 (Sept.97) Core Based Tree (Group-shared Tree) but : éviter les inconvénients de DVMRP et MOSPF ■ 46 ■ construction de l’arbre ■ ■ résistance au facteur d’échelle : un seul arbre pour le groupe efficacité (éviter les inondations) : messages de Join et de Leave explicites ■ ■ principe : construire un arbre partagé, bidirectionnel, avec un cœur unique maintien de l’arbre ■ ■ ■ Copyright 2004 by Timur Friedman un routeur local qui a un nouveau membre pour un groupe envoie un message join-request vers le cœur en unicast le cœur ou le premier routeur sur le chemin faisant déjà partie de l’arbre répond par un join-ack chaque routeur ayant vu passer le join-request marque l’if sur laquelle il l’a reçu chaque routeur envoie périodiquement des echo-request à son routeur amont le routeur amont répond par des echo-reply si un routeur aval n’obtient pas de réponse au bout de N essais, il détache son sous-arbre en envoyant un flush-tree Copyright 2004 by Timur Friedman 47 48 CBT (3/3) ⑤ ⑦ R4 S PIM (1/3) ① R1 envoie un join (G) au cœ ur ② R2 mar que l’if R2-R1 pour f air e R1 R2 R3 cœ ur ① ②⑥ ③ ④ « avantages ■ ■ ■ ■ RFC 2362 (June 98) Protocol Independent Multicast idée : distinction explicite de 2 scénarios de distribution le mode dense ■ suivr e ult ér ieur ement les paquet s ③ R3 mar que l’if R3-R2 ④ le cœ ur mar que l’if cœ ur -R3 ⑤ lor sque R4 r ej oint G, son join ■ ■ s’ar r êt e à R2 ⑥ R2 mar que l’if R2-R4 ⑦ pour envoyer un paquet ■ à G, S l’envoie en unicast au cœ ur qui f ait suivr e ■ pas d’inondation (vs. DVMRP) un hôte peut joindre/quitter un groupe sans délai (vs. DVMRP) un enregistrement par groupe avec les if sortantes (vs. DVMRP) pas de calcul explicite d’arbre (vs. MOSPF) ■ ¬ inconvénients ■ ■ les membres sont géographiquement concentrés dans une zone idée : RPF avec ® ¯7¯°²± ³² ´°²± 7 ´µ , similaire à DVMRP est alors raisonnable problèmes de fiabilité, robustesse et de congestion pour le cœ ur l’arbre n’est pas optimal pour toutes les sources Copyright 2004 by Timur Friedman Copyright 2004 by Timur Friedman 49 PIM (2/3) ■ 50 PIM (3/3) le mode épars ■ ■ ■ S les membres sont géographiquement éparpillés but : un routeur ne doit pas avoir à travailler, à moins de rejoindre un arbre principe : approche ¶·µ7 ¸ µ² ± ¹´³7º·µ° , similaire à CBT ■ ■ ■ ■ ■ D R1 R3 » » pas d’acquittement en réponse au join le join est envoyé périodiquement pour «rafraîchir» l’arbre ¼ le point de RDV informe une source active d’arrêter d’émettre lorqu’il n’y a plus de routeurs dans l’arbre changement de mode possible : de l’arbre partagé vers l’arbre par source les points de RDV émettent périodiquement en aval pour indiquer leur activité Copyright 2004 by Timur Friedman R2 cœ ur • • • • • R1 sait que son SP avec S passe par son if R1-R4 or , R1 r eçoit les paquet s Mcast sur son if R1-R2 R1 envoie un join à R4 R1 envoie ensuit e un prune au cœ ur le cœ ur ar r êt e le t r ansf er t Mcast sur cœ ur -R2 et R2-R1 chemin avec CBT sauf : ■ R4 chemin avec PI M ¼ le changement de mode per met de déchar ger le cœ ur en cas de panne du cœ ur , les hôt es ayant commut é de mode cont inuent de r ecevoir PI M ne dit pas comment un r out eur dét er mine le point de RDV d’un gr oupe PI M ne dit pas comment dét er miner si un gr oupe est dense ou épar s Copyright 2004 by Timur Friedman 51 Le Mbone (1/3) ■ ■ ■ ■ pour mettre en œ uvre le Mcast sur l’Internet, il faut que tous les routeurs aient des fonctions de Mcast et que les routeurs locaux supportent IGMP la plupart des routeurs de l’Internet ne supportent pas le Mcast !!! ■ bâtir des sous-réseaux capables de Mcast à la périphérie de l’Internet les interconnecter par des , les extrémités des tunnels sont des stations avec mrouted et un support de l’OS pour le Mcast ½ ¾@¿C¿CÀ&Á  ■ ■ ■ encapsulation des paquets Mcast transmis sur le Mbone dans des paquets IP classiques ■ l’extrémité du tunnel réceptrice détecte qu’elle a un paquet IP encapsulé dans un paquet IP (protocol =4) ■ après désencapsulation, elle fait suivre le paquet Mcast ■ soit en local sur son sous-réseau, s’il a des hôtes membres Ë Ú Û soit Ð Ü Ð ËauÝ Þprochain Ï Ú Ø Ò Í Ó Ð routeurÊ ËMcast, Ì Í Î Ï Ë Ð4après ÑÒ Í Ó ré-encapsulation ÐÔÕ Ö × Ø Ù Ø Ú Ë ■ Multicast Backbone of the Internet ■ principe : le à ÄÅ4ÅÆ:Ç È Å4É ■ idée ■ ■ Le Mbone (2/3) problème ■ 52 @ M1 unicast réseau virtuel de recouvrement, solution transitoire premier tunnel en 88 entre BBN et Stanford des milliers de sous-réseaux aujourd’hui utilisé pour diffuser des sessions IETF ou des conf. IEEE/ACM @ M2 unicast @ M1 224.5.5.5 unicast encapsulat ion M1 désencapsulat ion M2 t unnel R1 Copyright 2004 by Timur Friedman données R2 Copyright 2004 by Timur Friedman 53 chemin r éel 54 Le Mbone (3/3) ■ trafic ■ ■ ■ Plan ■ les conférences génèrent typiquement 100-300 kbits/s (limité à 500 kbit/s) pas de mécanisme de «police» mais une déontologie de l’utilisateur ■ ■ applications ■ ■ ■ ■ ■ ■ Introduction Le multicast au niveau réseau Le multicast au niveau transport ■ annuaires de session (sd, sdr) conférences audio (vat, nevot, rat) conférences vidéo (nv, ivs, vic, nevit) tableau blanc (wb) éditeur de textes (nte) jeux distribués interactifs (MiMaze) ■ ■ ■ fiabilité SRM RMTP Perspectives de recherche Copyright 2004 by Timur Friedman Copyright 2004 by Timur Friedman 55 Fiabilité ■ ■ ß ß ■ ■ chaque destination doit envoyer un ACK pour chaque (groupe de) message(s) un msg est retransmis jusqu’à réception d’un acquittement de chaque destinataire congestion du réseau implosion de la source ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ÂÁ ìC½ ½ ä ¿&í envoi des requêtes : ■ Request Timer + çCáCîéëä ¿&í Reliable Multicast Transport Protocol ■ ■ S1/ D1 ■ D5 ■ D6 estimation du RTT pour chaque paire (Di, Dj) ï principe ■ dimensionnement des Timers S notion de hiérarchie réduire l’implosion à la source réduire les temps de réponse notion de reprise en local ï S3/ D3 D4 offre une transmission point à multipoint, fiable, avec maintien de séquence idées ■ S2/ D2 envoi des retransmissions ■ Repair Timer ■ 58 ■ difficulté ■ sur détection d’une perte, la demande de retransm. est Mcastée le récepteur le plus proche du demandeur Mcaste la retransmission Copyright 2004 by Timur Friedman hyp : D5, D6 et D7 ont un msg manquant un seul membre demande la retransm. un seul membre retransmet le msg manquant principe ä ¿CçCè@é·ÀC¿CçCáC¿C½CçCÀÁ ê á@éCéëÁ ä àáC½ ä ìC¿ RMTP but : minimiser le trafic ■ ã ÀCàÀ&ä å ÀCã æ 57 SRM (2/2) ■ âCáCÂÀCç idée : un segment manquant n’est pas forcément retransmis par la source ■ atomicité : soit 0 soit tous les récepteurs ont reçu le msg terminaison : le résultat d’une transm. est connu en un temps fini Copyright 2004 by Timur Friedman SRM, RMTP, RAMP, RMP, etc. Âàá&Á áCâ&Á À offre une transmission fiable, sans séquencement, « » (car + reprise en local) 2 composants ■ un composant : offre les mécanismes pour demander et récupérer les segments de données manquants ■ un composant : est responsable du nommage des segments de façon à ce qu’ils soient identifiés de manière unique par tout le groupe et de l’ordonnancement çCè@é·ÀC¿CçCáC¿C½CçCÀÁ ê á@éCéëÁ ä àáC½ ä ìC¿ le contrôle est déplacé de l’émetteur vers les récepteurs la source émet sans se préoccuper des ACK les récepteurs détectent les pertes sur «trous» de N° de séquence de nombreux protocoles ont été proposés ■ ■ Scalable Reliable Multicast idée : utiliser des NAK ■ ■ SRM (1/2) peut-on étendre l’approche utilisée en unicast (ACK) ? ■ 56 D7 ■ nouveaux msgs r eq. de r et r ansm. r et r ansmissions Copyright 2004 by Timur Friedman ■ 59 DR1 D les récepteurs sont groupés dans des régions locales il y a un DR ( ) par région, chargé d’agréger les msg de status ñ ÀCàÀCä å ÀCã DR2 DR4 D ðÀCÂä íë¿CáC½ ÀCç difficulté : construire l’arbre logique D D D DR3 D D D msg de st at us Copyright 2004 by Timur Friedman 60 Plan ■ ■ ■ ■ Perspectives au niveau réseau ■ Introduction Le multicast au niveau réseau Le multicast au niveau transport Perspectives de recherche ■ ■ ■ adressage et routage òóÇ ô È Åà õ:öÈ ÆÄö d’un groupe D1 D niveau réseau niveau transport niveau application S S R1 R1 R2 D R3 D D2 R4 D R5 D D D D D mult icast sur un sous ar br e (« subcast ing ») ■ ■ Copyright 2004 by Timur Friedman D2 R2 R3 D R4 D R5 D ■ routage multicast dans un réseau mobile routage multicast avec QoS contrôle de flux/congestion fiabilité assistée par les routeurs auto-configuration des membres du groupe ■ ■ Bibliographie ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ allocation des adresses multicast nommage d’objets partagés Copyright 2004 by Timur Friedman 63 ■ 62 Perspectives au niveau application Copyright 2004 by Timur Friedman ■ D1 Copyright 2004 by Timur Friedman Perspectives au niveau transport ■ D unicast ver s un membr e du gr oupe (« r eachcast ing ») 61 ■ D ÷ øù úû û û ü ý þÿ û ÿ ý ÿ "# $ %& þÿ ú@ÿ ' ( ø )÷ øù úû ! * %+ û ÿ ÷ øù úû ! , ý - ÿ . 0/&þù 1·û , ÿ ÷ øù ú´ü û ý ÿ 2 ' ú 02 3 54 ú62 35( ·ü 7 6 ø 8 þ9 þ 9 %0+ û ÿ ÷ øù ú´ü ü û ý ÿ 2 ' ú 02 3 54 6ú 2 35( ·ü 7 6 : 1 þ 9 %0+ û ÿ ÷ øù ú´ü ü ; < ýøÿ ù =6 9&6 %5 ( ·ü ) * %0+ û ÿ ÷ øù ú´ü ; < ü ý ÿ ÿ ù @ÿ %5. ÿ 3 1 þÿ Cÿ ' . (ÿ - + ú@ÿ > ÿ þ 1 %5 > ÿ "# ' 9 ' ? þ 9 & ' 54 6? :þ 7 8 :þ 9 - ·û ÿ ú@ÿ "´ÿ + + - ÿ :ú @5 6 ) A 9 ú %&%0 8 ´þ * .5 ù '6 1 %5 &- þ : ú ( ÿ û ! ; 9 û ÿ þÿ ù . ' (ÿ - + þÿ 6 ú ú@ÿ =Cÿ > > ÿ B 1 :ø + & ù %5 @5 C: > 1 ? @5 1 þ '&9 9 &> * ù %& ÿ @ ú þ =C:ú /66D ! /: + û ! ÿ þÿ Eÿ Eÿ þ + ) A - ÿ ú@ÿ > þÿ 2 1 1 . . ø + & 3 9 4 ø 63 7 0- þ : ú ( ÿ û ! ; 9 û ÿ þÿ 0 1 & ' 9 9 E @5 ' %0 0 + 1 û ÿ 1 9 8 F F @6@6@·ÿ %0+ ÿ % Copyright 2004 by Timur Friedman 65 64