Multicast protocoles de routage

1
Multicast protocoles de routage

• Bernard Rapacchi
• Bernard Tuy
• CNRS/UREC

2
Plan

• Définitions
• Exemples d'applications
• Notions générales
• Le MBONE
• Les Protocoles
• IGMP
• DVMRP
• PIM
• Organisation du routage sur un site
• principes et recommandations
• exemple

3
Définitions

• Multicast Multipoint
• Applications "habituelles" entre une source et
  une destination
• applications Unicast (ou point à point)
• "Nouveau" type d'applications entre une source et
  plusieurs destinations
• applications Multicast
• Les participants à une application multicast
  constituent un groupe multicast
• Le groupe multicast a une adresse multicast de
  classe D
• 224.0.0.0 -gt 239.255.255.255
• le groupe multicast n'est pas limité au réseau
  local
• gt routage vers les adresses de groupe routage
  multicast

4
Exemple téléséminaire

• Multicast un seul flux d'information vers les
  destinataires

5
Téléséminaire (2)
224.2.0.1
Groupe Multicast d'adresse 224.2.0.1
6
Types d'applications Multicast

• Diffusion de 1 vers plusieurs
• Téléséminaire
• pas d'interaction des destinataires
• Diffusion des tables de routage RIPv2
• Bootstrap sur le réseau
• Diffusion de plusieurs vers plusieurs
• Téléconférence
• chaque membre du groupe peut être source du flux
  multicast

7
Multicast généralités

• Unicast vers un seul destinataire
• Broadcast vers tous les équipements du LAN
• Multicast vers tous ceux qui appartiennent au
  même groupe multicast
• qui se sont "abonnés" à ce groupe

8
Multicast généralités

• meilleure utilisation de la bande passante
• les mêmes données ne circulent quune seule fois
  sur le même lien
• les sources et les destinataires (membres) sont
  distincts
• les hôtes disent aux routeurs de quels groupes
  ils sont membres
• mais pas auxdestinataires auxquels ils envoient
• les routeurs doivent écouter toutes les adresses
  multicast
• les routeurs utilisent des protocoles pour gérer
  les groupes multicast

9
le MBone

• MBone Multicast backbone
• Virtual Internet backbone for Multicast IP
• Réseau virtuel d'équipements multicast sur
  Internet
• reliés par des "tunnels"
• au-dessus de la topologie unicast (overlay
  network)
• Ensemble d'outils
• pour annoncer la diffusion de programmes
  multimédia (sdr)
• pour permettre aux utilisateurs de rejoindre les
  groupes multicast (sdr)
• pour suivre ou diffuser ces programmes
• vat, rat audio
• vic vidéo

10
le MBone (2)

• Un projet de coopération expérimental
• 1992 première diffusion réseau d'une réunion de
  l'IETF (son)
• 1993 première diffusion vidéo
• Topologie
• maillage des ilots multicast
• par des machines "mroutées"
• à travers des tunnels
• en étoile au niveau du réseau de site

11
La topologie du MBone (2)
routeur multicast
routeur multicast
12
La topologie du MBone (3)
routeur multicast
Tunnel multicast
routeur multicast
13
Tunnels IP

• Structure logique faisant abstraction de la
  topologie physique sous-jacente du réseau
• Dans RFC 1075, on utilise Loose Source Routing
• En réalité, on fait de lIP dans IP avec numéro
  de protocole (protocole 4, tunnel DVMRP)
• Association dun métrique et dun seuil
  (threshold ) à chaque tunnel

14
Rappels adressage

• Adresses de classe A, B, C
• et D 224.0.0.0 à 239.255.255.255
• réservation de plages d'adresses spécifiques
• 224.0.0. utilisation locale sur le LAN
• 224.0.0.1 tous les hosts Xcasts du LAN
• 224.0.0.2 tous les routeurs Xcasts du LAN
• 239... "administratively scoped addresses"
• adresses à portée locale
• toutes les autres adresses ont une portée non
  limitée

15
Envoi de paquets

• Une adresse multicast ne peut être que
  destinataire
• les sources ont toujours une adresse unicast
• le niveau Liaison de données n'utilise pas ARP
• mécanisme de correspondance (pour les _at_ IEEE-802)
• _at_IP multicast -gt _at_Ethernet multicast
• Etre membre d'un groupe est indépendant d'envoyer
  à ce groupe
• une source nest pas obligatoirement membre du
  groupe auquel elles envoie un flux multicast

16
Envoi de paquets
inchangé
Ethernet
mapping
0x 01 00 5E ______________________________
23 bits de droite de l'_at_ IP destination 24eme
bit 0
17
Réception de paquets

• Par défaut, le coupleur Ethernet d'une station
  écoute
• son adresse Ethernet (fixée PROM)
• et l'adresse de broadcast (FF...FF)
• Les autres adresses Ethernet doivent être
  explicitement programmées dans le driver du
  coupleur
• Pour le multicast, il faut écouter au minimum
• équivalent Ethernet de 224.0.0.1 (tous les hôtes
  multicast du LAN)
• équivalent Ethernet du répertoire des sessions
  MBone
• annonçant la liste des groupes multicast actifs

18
Internet Group Management Protocol( IGMP )

• RFC 1112

19
IGMP généralités

• Protocole d'interaction entre
• le(s) routeur(s) multicast du LAN
• et les hôtes multicast du LAN
• Permet à un hôte de s'abonner (désabonner) à un
  groupe
• et dire au routeur
• envoyez-moi une copie des paquets de cette
  adresse de groupe
• deux versions existent, IGMPv1 et v2
• IGMP version 3 en cours délaboration (IETF/ IDMR)

20
IGMP un seul routeur

• le routeur envoie toutes les 60 secondes
• une sollicitation aveugle à l_at_ 224.0.0.1 (query
  )
• à quel(s) groupe(s) voulez vous vous abonner ?
• et attend les réponses
• le(s) hôte(s) renvoie(nt) un IGMP report
• qui indique ladresse du ou des groupes qui
  lintéressent
• si le routeur ne reçoit aucune réponse pour un
  groupe donné
• il arrête la réémission des paquets multicast
  de ce groupe
• le groupe est réputé sans abonné local

21
IGMP un seul routeur (2)

• quand l hôte reçoit la sollicitation (query)
• il fixe un délai aléatoire avant de répondre
• pour éviter que toutes les réponses arrivent au
  même moment
• quand un hôte a répondu, les autres nont plus
  besoin de répondre
• le routeur arme une temporisation sur les
  abonnements aux groupes multicast avant de
  solliciter à nouveau tous les hôtes

22
IGMP sabonner à un groupe
224.2.0.1 224.5.5.5
224.2.0.1
224.2.0.1
Hôte 1
Hôte 2
Hôte 3
Envoi périodiqueIGMP Query à 224.0.0.1

23
IGMP sabonner à un groupe
224.2.0.1 224.5.5.5
224.2.0.1
224.2.0.1
Hôte 1
Hôte 2
Hôte 3
Envoi Reportpour 224.2.0.1
224.2.0.1
24
IGMP sabonner à un groupe
224.2.0.1 224.5.5.5
224.2.0.1
224.2.0.1
Hôte 1
Hôte 2
Hôte 3
Envoi Reportpour 224.5.5.5
224.2.0.1 224.5.5.5
25
IGMP plusieurs routeurs

• Un routeur est élu entre tous les routeurs
• cest le Dominant Router (DR) ou Designated
  Router
• il est seul à émettre les IGMP Queries
• en v1, le mécanisme délection est fonction du
  routage multicast et nappartient pas à IGMP
• en version 2, le DR est le routeur dont l_at_IP
  est la plus petite
• le DR nest pas forcément le routeur qui transmet
  les paquets multicast

26
IGMP version 2

• Election du DR
• _at_IP la plus petite
• timers programmables
• nouveaux type de paquets envoyés par lhôte
• de désabonnement leave
• au reçu dun leave, le routeur envoie
• un query spécifique au groupe
• gt réduction du temps de latence pour arrêter la
  diffusion dun groupe qui na plus dabonné
• IGMP v2 doit obligatoirement supporter la version
  1

27
IGMP quitter un groupe
224.2.0.1
224.2.0.1
Host 1
Host 2
Host 3
Envoi Leavepour 224.2.0.1 à 224.0.0.2
224.2.0.1 224.5.5.5
28
IGMP quitter un groupe
224.2.0.1
224.2.0.1
Host 1
Host 2
Host 3
Envoi IGMP Query spécifique pour 224.2.0.1
224.2.0.1 224.5.5.5
29
IGMP quitter un groupe
224.2.0.1
224.2.0.1
Host 1
Host 2
Host 3
Envoi Report pour 224.2.0.1
224.2.0.1 224.5.5.5
30
IGMP quitter un groupe
224.2.0.1
224.2.0.1
Host 1
Host 2
Host 3
Envoi Leavepour 224.5.5.5 à 224.0.0.2
224.2.0.1 224.5.5.5
31
IGMP quitter un groupe
224.2.0.1
224.2.0.1
Host 1
Host 2
Host 3
Envoi IGMP Query pour 244.5.5.5
224.2.0.1
32
Les Protocoles de routage multicast

• On distingue deux types de protocoles en fonction
  du mode de transmission des paquets multicast
  utilisé
• Mode dense (inondation)
• DVMRP, PIM DM et MOSPF
• suppose que les abonnés aux groupes multicast
  sont nombreux
• Mode épars
• PIM SM et CBT
• faible population abonnée

33
Distance Vector Multicast Routing Protocol(
DVMRP )

• RFC 1075

34
DVMRP généralités

• mrouted sous Unix
• Agit en mode dense flooding pruning
• on inonde (flooding ) tout l'arbre multicast
• ceux qui ne sont pas intéressés le disent
• ils sont élagués de larbre (pruning )
• Pour éviter les boucles gt algorithme RPF
• Reverse Path Forwarding

35
Reverse Path Forwarding (RPF)

• un routeur transmet un paquet multicast
• si le datagramme est reçu sur linterface
  utilisée pour envoyer un paquet unicast vers la
  source (reverse )
• Test RPF
• Oui paquet retransmis, on inonde
• Non paquet est mis à la poubelle
• un paquet est retransmis vers toutes les
  interfaces du routeur SAUF linterface RPF
  dentrée

36
Reverse Path Forwarding (RPF)
Source
A
D
B
C
E
37
Reverse Path Forwarding (RPF)
Source
A
D
B
C
E
Paquets multicast non retransmis
38
Routage DVMRP

• DVMRP utilise son propre routage unicast
• variante de RIP
• pour déterminer le critère RPF et
• décider de retransmettre un datagramme multicast
• Le routage Unicast est nécessaire pour localiser
  les Sources multicast
• les paramètres du protocole
• le nombre de sauts (hops), les métriques et les
  seuils (Threshold )
• le seuil indique si un datagramme multicast peut
  être réémis en le comparant à son TTL.
• obligation dutiliser des tunnels
• certains routeurs ne font pas du multicast

39
Routage DVMRP

• échange de tables de routage entre routeurs DVMRP
  
• Destination / Masque / Métrique
• Les destinations sont les _at_ sources multicast
• Loptique est de toujours construire un arbre
  minimal à partir de la source

40
Echange des tables de routage (théorie)
Source
(S,1)
(S,1)
A
D
B
C
E
41
Echange des tables de routage (théorie)
Source
(S,2)
A
D
B
(S,2)
C
E
42
Poison Reverse

• Le routeur B va décider
• que le routeur A voisin est en amont vers la
  source S
• il envoie à A une information de routage versS
  dont la métrique est dite empoisonnée
• Conséquence
• B attend le flux multicast de A pour la source S
• A ne doit pas compter sur B pour ce même flux
• Le RFC 1112 prévoit d' envoyer
• _at_IP Source, m infini (16), un flag à 1
• Dans mrouted
• Source, m vraie métrique vers S infini (32)

43
Poison Reverse
Source
(S,infini)
A
D
B
(S,2)
C
E
44
DVMRP échange des routes

• Les echanges d'informations de routage utilise
  IGMP type 3
• Envoi à 224.0.0.4 (tous les routeurs DVMRP)
• Utilisation de sous-types
• Response envoie les routes vers les
  destinations(Sources)
• Request demande les routes vers les
  destinations
• Prune rapport daucun membre
• Graft greffe dune nouvelle branche sur larbre
  multicast

45
Algorithme de transmission Xcast (1)

• Si TTL lt 2, supprimer le paquet
• Si pas de route, supprimer le paquet
• Paquet reçu sur une interface non-RPF, supprimer
• Dest 224.0.0.1,2, supprimer
• Pour chaque interface fille pour la source
• Si linterface nest pas une feuille et nest pas
  élaguée
• OU il y a des membres du groupe sur cette
  interface alors
• Si TTL gt Seuil alors
• TTL TTL - 1
• on transmet le paquet

46
Connecter un mrouteur au MBone

• Chercher une source du MBone
• Christian.Donot_at_inria.fr
• mbone-fr_at_inria.fr
• On a un interlocuteur, une adresse IP, une
  métrique (1) et un seuil (threshold 32)
• Installer soir un mrouteur DVMRP soit mettre PIM
  en service

47
Solution 1 Mrouted

• ftp//ftp.univ-rennes1.fr/pub/reseau/multicast/
• Station Unix
• Configurer
• /etc/mrouted.conf
• tunnel 129.88.45.84 130.190.6.20 metric 1
  threshold 32
• Tout le sous-réseau est servi, toutes les
  stations sont sur le MBone
• Dautres tunnels avec des thresholds plus petits
  vers dautres sous-réseaux du campus
• /etc/mrouted.conf
• tunnel 129.88.45.84 130.190.6.20 metric 1
  threshold 32
• tunnel 129.88.45.84 192.145.7.22 metric 1
  threshold 16
• tunnel 129.88.45.84 189.130.1.1 metric 1
  threshold 16

48
Le résultat
oreste
m 1 t 32
m 1 t 16
m 1 t 16
sylvestre
melpomene
inria-ra
49
Les régions administratives
oreste
m 1 t 32 boundary NTCM
m 1 t 16 boundary NTCM
m 1 t 16
sylvestre
melpomene
inria-ra
50
Les régions administratives
oreste
lysithea
r-jusren
m 1 t 32
m 1 t 32
m 1 t 32 b NTCM
m 1 t 16 b NTCM
m 1 t 16
sylvestre
melpomene
inria-ra
51
Les régions administratives
oreste
lysithea
r-jusren
m 1 t 32
m 1 t 32
m 3 t 8 b NTCM
m 1 t 32 b NTCM b Urec
m 1 t 16 b Urec
m 1 t 16 b NTCM b Urec
sylvestre
melpomene
inria-ra
52
Les régions administratives

• /etc/mrouted.conf
• name Urec 239.51.0.0/16
• name NTCM 239.69.0.0/16
• tunnel "sylvestre" "oreste" m 1 t 32 boundary
  NTCM boundary Urec
• tunnel "sylvestre" "lysithea" m 3 t 8 boundary
  NTCM
• tunnel "sylvestre" "melpomene" m 1 t 16 boundary
  Urec
• /.sdr/sdr.tcl
• add_admin Urec 239.51.255.255 1234 239.51.0.0 16
  8
• add_admin NTCM 239.69.255.255 1235 239.69.0.0 16
  32

53
Mrouted les outils

• kill -USR1 cat /etc/mrouted.pid (routes
  sources)
• kill -USR2 cat /etc/mrouted.pid (groupes)
• mrinfo
• mtrace
• tcpdump
• http//www.cl.cam.ac.uk/mbone/eu-monitor.htm

54
Protocol Independent Multicast

• "Internet Draft"
• http//netweb.usc.edu/pim/

55
PIM généralités

• Indépendant du protocole de routage
• DVMRP
• prend les décisions de RPF
• a son propre protocole de routage
• PIM repose sur le protocole de routage unicast
  sous-jacent
• pour les décisions RPF
• et les poison reverse routes
• PIM peut fonctionner selon deux modes
• dense mode faible overhead pour les groupes
  denses dabonnés
• sparse mode peu dabonnés

56
PIM Dense Mode

• Ressemble à DVMRP
• sauf pour le routage
• mécanismes de flooding et pruning et de graft
  (greffe),
• Pruning sur les voisins non RPF
• Arbres construits par rapport aux sources
  émettrices avec utilisation de RPF
• Utilisation de déclaration (assert ) pour élire
  un transmetteur sur un LAN à plusieurs routeurs

57
PIM, Dense-Mode exemple
Source
A
B
F
C
D
G
E
Destinataire 1
Destinataire 2
58
PIM, Dense-Mode exemple
Source
Dabord on inonde
A
F
B
C
D
G
E
Destinataire 1
Destinataire 2
59
PIM, Dense-Mode exemple
Source
Elagage de C vers un voisin Non RPF
A
F
B
C
Prune
D
G
E
Destinataire 1
Destinataire 2
60
PIM, Dense-Mode exemple
Source
Assert sur le LAN de C et D suppression des
doublons
A
F
B
C
D
Asserts
G
E
Destinataire 1
Destinataire 2
61
PIM, Dense-Mode exemple
Source
F na pas de membre, il élague
Prune
A
B
F
C
D
E
G
Destinataire 1
Destinataire 2
62
PIM Sparse mode

• Mode dabonnement explicite (Join )
• La source senregistre auprès d'un Point de
  Rendez-vous RP
• Le RP est la racine de l'arbre de diffusion
  multicast
• c'est une adresse bien connue de tous
• Pour s'abonner le destinataire envoit un Join au
  RP
• Il peut y avoir plusieurs RP pour différents
  groupes
• Pas d'inondation
• Le flux multicast parcourt un arbre partagé
• les routeurs feuilles peuvent de se joindre à
  larbre
• les paquets ne vont que là où c'est utile

63
PIM, Sparse-Mode exemple
Source
B
A
D
RP
C
E
Destinataire 1
Destinataire 2
64
PIM, Sparse-Mode exemple
Destinataire 1 se joint au groupe, C créé létat
(, G) et envoie un join à RP
Source
B
A
D
RP
Join
C
E
Destinataire 1
Destinataire 2
65
PIM, Sparse-Mode exemple
RP crée létat (, G), met un lien vers C sur
linterface de sortie
Source
B
A
D
RP
C
E
Destinataire 1
Destinataire 2
66
PIM, Sparse-Mode exemple
Source envoie des données, A encapsule les
données et envoie un register vers RP
Source
Register
B
A
D
RP
C
E
Destinataire 1
Destinataire 2
67
PIM, Sparse-Mode exemple
RP crée létat (S, G), envoie les données sur
larbre partagé, envoie join vers la source, A et
B créent létat (S, G)
Source
Join
Join
B
A
D
RP
C
E
Destinataire 1
Destinataire 2
68
PIM, Sparse-Mode exemple
Quand les données arrivent normalement à RP,il
envoie register-stop
Source
Register-Stop
B
A
D
RP
(S,G)
( ,G)
C
E
Destinataire 1
Destinataire 2
68
69
PIM, Sparse-Mode exemple
Destinataire 1 veut un chemin plus court,C
envoie join vers Source
Source
A
B
D
RP
Join
C
E
Destinataire 1
Destinataire 2
69
70
PIM, Sparse-Mode exemple
C reçoit (S, G), il envoieprune pour la source
sur larbre partagé, RP garde le lien vers C
sauf pour S
Source
B
A
RP
D
Prune Source
(S,G)
( - S,G)
C
E
Destinataire 1
Destinataire 2
70
71
PIM, Sparse-Mode exemple
Destinataire 2 rejoint le groupe, E crée létat
(, G),envoie join vers RP
Source
B
A
D
RP
(S,G)
Join
( - S,G)
C
E
Destinataire 1
Destinataire 2
71
72
PIM, Sparse-Mode exemple
C ajoute un lien sur linterface de sortie pour
(, G) et (S, G)
Source
B
A
D
RP
(S,G)
( - S,G)
C
E
( ,G)
Destinataire 1
Destinataire 2
72
73
PIM, Sparse-Mode exemple
Source 2 envoie des données, D envoie
Register,RP envoie sur larbre partagé
Source
Source 2
B
A
D
RP
(S,G)
( - S,G)
( ,G)
C
E
( S2 ,G)
Destinataire 1
Destinataire 2
73
74
Interactions PIM - DVMRP
75
Principes

• Les sources du nuage PIM doivent être annoncées
  dans DVMRP
• Les membres dans le nuage PIM doivent être connus
  dans DVMRP
• Le routeur de frontière PIM-DVMRP
• doit savoir parler le protocole de routage
  unicast DVMRP
• doit convertir les métriques propres à chaque
  protocole
• il a une vision particulière pour chacun des
  protocles
• utilise IGMP pour le rapport des groupes

76
Groupes bordure native LAN

• routeur PIM envoie IGMP reports pour tous les
  groupes qui ont des membres dans le nuage PIM

G1
PIM
G2
G3
DVMRP
IGMP
PIM
G1
G2
G3
mrouted
77
Groupes bordure par un tunnel

• routeur PIM Poison Reverse toutes les sources
  connues du DVMRP puis élague les groupes sans
  intérêt

PIM
S1
DVMRP
Poison Reverse
PIM
S2
S1
S2
S3
S3
mrouted
78
Recevoir les rapports DVMRP

• Sur un tunnel
• cacher les routes apprises
• Poison Reverse vers lémetteur
• Interface native
• si pas besoin de transmettre à dautres DVMRP les
  routes apprises peuvent être abandonnées mais les
  routes unicast vers les sources doivent être même
  interface
• sinon on cache les routes apprises

79
Ce quon envoie à DVMRP

• Les interfaces directement connectées avec PIM
• Les routes connues dautres nuages DVMRP
• Les routes des sources dans le nuage PIM
• si nécessaire Poison-Reverse les routes des
  sources dont DVMRP est en amont

80
Annonces aux voisins DVMRP

• Calcul des métriques pour
• les routes directement connectées 1
• Apprises de DVMRP métrique reçue 1
• Apprises dun routeur PIM qui fait du routage
  unicast DVMRP métrique reçue 1
• Apprise dune table de routage unicast existante
  1
• Poison-Reverse métrique connue infini (32)

81
Modification des Métriques (option)

• Mettre manuellement les valeurs
• Ajouter manuellement un offset
• Appliquer aux routes de toutes origines
• Appliquer des access-lists (par défaut , tout
  est filtré)
• Possibilité de déclarer des route maps

82
Configuration d'un routeur commandes globales

• no ip multicast-routing
• pour activer le routage Xcast
• no ip mroute ltsrcgt ltmaskgt ... lt_at_RPFgt _at_
  interface
• pour déclarer une route Xcast statique
• no ip dvmrp route-limit 7000
• limiter la taille de la table de routage Xcast

83
Configuration d'un routeur commandes
d'interface (IGMP)

• ip igmp access-group ltaccess-listgt
• configure les groupes autorisés sur une interface
  donnée
• ip igmp join-group ltgroup-addressgt
• déboguer le trafic qui arrive pour ce groupe
• ip igmp query-interval ...
• fixe l'intervalle des requêtes envoyées aux hôtes
  du LAN
• --------------------------------------------------
  -------------------------------
• no ip sdr listen
• connaitre les sessions multicast qui sont
  annoncées
• on les visualise avec show ip sdr

84

Configuration d'un routeur commandes
d'interface (PIM)

• no ip pim dense-mode sparse-mode
• dense mode est le défaut
• ip pim query interval lt time in seconds gt
• no ip pim rp-address ltip-addressgt
• pour définir le point de Rendez-Vous
• ip dvmrp unicast-routing
• (!) utiliser le routage unicast DVMRP sur une
  interface PIM
• ip multicast ttl-threshold ltvaleurgt
• fixer un seuil sur une interface

85

Configuration d'un routeur commandes
d'interface (DVMRP)

• no ip dvmrp metric ltnombregt list
  ltaccess-listgt
• no ip dvmrp default info only
• fixer la route par défaut
• ip multicast rate-limit in out ltvaleur en
  kbpsgt
• tunnel mode dvmrp
• établir un tunnel entre un routeur et une station
  par exemple
• les tunnels entre routeurs (Cisco ?) sont en mode
  GRE

86
Organisation du routage multicast principes

• sur un campus
• Participer au FMBone
• minimiser les flux multicast pour éviter les flux
  inutiles
• Topologie arborescente et sur chaque Routeur
• naccepter aucune route DVMRP sur linterface RPF
  
• ip dvmrp accept-filter 15
• access-list 15 deny any
• ne retransmettre quune route par défaut DVMRP
  sur les autres interfaces
• ip dvmrp default-information only
• configurer une route multicast statique par
  défaut qui pointe vers linterface RPF
• ip mroute 0.0.0.0 0.0.0.0 TunnelX
• préférer PIM aux tunnels quand cela est possible
• informer / former les utilisateurs potentiels

87
Organisation du routage multicast principes

• dans un laboratoire
• mettre en place un seul routeur multicast
• quand le besoin existe !
• PIM si possible (type du routeur, niveau d'IOS,
  ...)
• même configuration de routeur

88
Solution 2 développer PIM dense
PIM/GRE MBone
DVMRP interne
PIM
PIM
Renater
DVMRP MBone
PIM
DVMRP interne
DVMRP interne
89
Solution 3 développer PIM dispersé
DVMRP interne
PIM/GRE MBone
PIM
PIM
Renater
DVMRP MBone
PIM
DVMRP interne
DVMRP interne
90
Bibliographie

• C. Huitema
• Le Routage dans lInternet, Eyrolles, 1995
• LInternet Professionnel
• Collectif, Ed. CNRS, 1995
• ftp//ftpeng.cisco.com/ipmulticast.html
• http//electre.inria.fr
• http//www.univ-rennes1.fr/CRU/Multimedia/annonce_
  multimedia.html