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 ( Œ ˜ –4–4š: “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