Routage multipoint inter-domaineicube-publis.unistra.fr/docs/1225/rhdm99-Pansiot.pdfRoutage multipoint inter-domaine Jean-Jacques PANSIOT & Abdelghani ALLOUI LSIIT - Université Louis

Routage multipointinter-domaine

Jean-Jacques PANSIOT & Abdelghani ALLOUILSIIT - Université Louis Pasteur

Strasbourg{pansiot, alloui}@dpt-info.u-strasbg.fr

Ecole d’Eté RHDM’99, Pointe du Diable, 6-10 septembre 1999

J-J Pansiot & A. Alloui - RHDM ’99 2

Plan

Introduction modèle de Deering routage intra-domaine en mode dense routage intra-domaine en mode épars routage inter-domaine architecture LAR


Hypothèses

Réseau de type IP

Envoyer le même paquet àplusieurs destinations enminimisant le trafic et lesdélais

Le paquet IP parcourt (aumoins) un arbre dont laracine est la source et lesfeuilles les récepteurs C

D

B

E

A

source


Multicast de niveau 2

Dans un réseau à diffusion comme ethernet tout le monde reçoit (diffusion) puis sélection

par les récepteurs

Interconnexion de réseaux à diffusion auniveau 2 (pont, switch ethernet) construction d’un arbre de recouvrement

(spanning tree) pour supprimer les boucles diffusion comme dans un réseau unique problème du filtrage (802.1 GARP)


Modèle de Deering (1991)

Paquets IP multicast même format queunicast

Adresse multicast représente un ensemblede récepteurs (classe D IPv4)

Les récepteurs se déclarent au routeur voisin(IGMP)

Les sources ne se déclarent pas Multipoint à multipoint si les sources sont

aussi réceptrices


Routage multicast

Permettre l’acheminement d’un paquet multicastde la source vers les récepteurs

Arbre construit par signalisation entre les routeurs semi-explicite (inondation/élagage) explicite (adhésion/retrait)

Distinction entre mode dense ou épars intra ou inter domaine


Routage en mode dense

Inondation du réseau (flood) et élimination desbranches inutiles (prune) DVMRP (sur routage unicast spécifique à la RIP) PIM-DM (sur routage unicast quelconque)

Un arbre par source (pas scalable) O(S*G) entrées par routeur

une entrée par couple S,G même si hors arbre

Repose sur le RPF check utilise le chemin vers la source « chemin inverse »


RPF Check

B accepte un paquet multicast venant de As’il arrive par la route unicast (interface) de Bvers A permet d’éviter les boucles la route unicast de B vers A est connue de B problème en cas de routes asymétriques

Inondation/Elagage périodique (soft state)


Source

Inondation/Elagage

IGMP DONNEES PRUNE


MOSPF

Extension de OSPF spécifique à OSPF

chaque routeur connaît les liens du réseau(routage par état desliens)

nécessite de connaître l’existence des membres dechaque groupe sur chaque lien

calcul des arbres multicast à la volée (coûteux) calcul de l ’arbre de S vers tous les membres (Dijkstra) suis-je sur cet arbre et avec quels successeurs ? Résultat mis en cache

chemins calculés dans le « bon sens »


Mode dense: conclusion

Adapté dans un petit domaine si la majoritédes réseaux contiennent des membres

coûteux en signalisation (PRUNE) si groupeépars

coûteux en états dans TOUS les routeurs dudomaine :proportionnel au nombre decouples sources*groupes (DVMRP)


Protocoles en mode épars

Un arbre partagé par toutes les sources Construit autour d’un point central (Core, RP) Signalisation explicite (join) des récepteurs vers le

centre Arbre en général construit à l’envers « chemin

inverse » Localisation du centre ? Panne du centre ? CBT (SIGCOMM 93), PIM (SIGCOMM 94)


Construction de l’arbre PIM-SM

Le routeur d’attachement du nouveau récepteur à réception d’un join IGMP calcule l’adresse du RP transmet le join au routeur voisin vers le RP

Le join remonte vers le RP jusqu’à rencontrer unrouteur sur l’arbre

acquittements dans l’autre sens messages de retrait (prune) analogues


Emission de données PIM-SM

La source envoie son paquet Le routeur d’attachement désigné détermine le RP associé encapsule le paquet et l’envoie au RP

Le RP décapsule et achemine le paquet dansl ’arbre (unidirectionnel)

Possibilité de passer à un arbre par source(pour certaines sources très actives)


RP

Source non-membredu groupe

Source membredu groupe

PIM : Arbres unidirectionnels


CBT

Assez semblable à PIM-SM mais arbre bidirectionnel données encapsulées vers le centre (Core) dans le cas

des sources non membres du groupe.


Core

Source non-membredu groupe

Source membredu groupe

CBT : Arbres bidirectionnels


PIM-SM: choix du centre

Algorithme du bootstrap bootstrap router (BSR) élu parmi les candidats

BSR le BSR diffuse une liste de points de rendez-vous

(RP) valides (parmi les candidats RP) une fonction de hachage associe une adresse de

groupe à un RP parmi la liste tout routeur peut calculer le RP associé à un

groupe (une adresse)


Commentaires

Nombre d ’entrées en O(g) où g est le nombre degroupes « On tree » (plus si arbres PIM par source)

Le mécanisme de sélection du Core /RP n’est passcalable: la liste de tous les RP doit être connue de tous les

routeurs (diffusion de cette liste) placement non optimal dans un grand réseau

a priori devrait dépendre de la topologie (variable) des membres

panne du Core/RP = reconstruction de tout l’arbre

limités à l’intra-domaine


Déploiement actuel

Implémentations de DVMRP, MOSPF, PIM,CBT...

Les routeurs inter-domaines ne routent pasle multicast (pas de solution viable à grande échelle)

Réseau expérimental Mbone (FMBone) tunnels entre routeurs multicast à travers des

routeurs non multicast allocation d ’adresse manuelle


Problèmes de l’Inter-domaine

Extensibilité en nombre de groupes

potentiels, existants, existants à un endroit

taille des groupes état à mémoriser, signalisation

Allocation des adresses unicité à l’échelle d’Internet dynamicité

si nombreux groupes transitoires espace d ’adressage limité (en IPv4)


Problèmes inter-domaine (suite)

Interaction protocoles de routage intra/inter Respect des politiques de routage contrôle des flux multicast en transit minimiser la « third party dependency »

Accounting essentiel si applications multicast commerciales

diffusion vidéo, diffusion d’infos,...

Fiabilité du routage liée à la taille importance si applications commerciales


Interaction entre domaines : exemple

MBR Domaine 2PIM-SM

Domaine 1DVMRP

Relayer les données de 2 vers 1 MBR doit être sur tous les arbres

du domaine 2 non optimal

ou MBR doit connaître l'état des

adhésions dans le domaine 1 Domain Wide Reports

Relayer les données de 1 vers 2 MBR encapsule les données

reçues depuis 1 vers le RPcorrespondant dans 2

ou MBR est le RP des groupesde 2


Passage à l ’inter-domaine

Problème du centre: hiérarchisation (HPIM, HDVMRP, OCBT, HIP,

BGMP)

adressage du centre (SIMPLE, EXPRESS)


L’architecture BGMP/MASC (Thaler et al, ietf)

Un protocole d’allocation d’adresses multicast inter-domaine (MASC), + protocoles intra domaine (AAP,MDHCP)

Un protocole d’annonce des blocs d ’adressesmulticast et des politiques multicast (BGP4+)

Un protocole de construction d’arbre multicastinter-domaine (BGMP)

Un modèle d’interaction aux frontières Des protocoles de routage multicast intra-domaine


MASC (Multicast Address Set Claim)

Domaines organisés en une hiérarchie Allocation unique, dynamique et temporaire Chaque domaine demande une (ou plusieurs) plages d’adresses dans une

plage affectée à son domaine père résolution de conflit

Les plages d’adresses utilisées par un domaine sontannoncées à l ’extérieur via BGP association plage d ’adresse Root Domain


BGMP Border Gateway Multicast Protocol

Utilisé en inter-domaine un protocole intra-domaine (MIGP) dans chaque

domaine (PIM, CBT, MOSPF, ...) l’arbre BGMP relie des domaines

arbre enraciné dans le domaine possédant l’adressedu groupe (alloué par MASC et publié par BGP) bi-directionnel

fait transiter données et join d’un domaine à unautre


Construction

Join du membre vers un routeur multicast frontièredu domaine via protocole intra-domaine (nécessiteque les BR appartiennent à tous les groupes:modification des protocoles épars)

le BR détermine le root domain associé à l’adresse multicast

grâce à la M-RIB construite par BGP4+

propage le join soit vers le routage intra du domaine suivant soit vers un voisin BGMP externe


Problèmes

Complexité (MASC, AAP ,BGMP , BGP, PIM,...) Scalabilité (annonce des adresses Multicast) vulnérabilité du root domaine pas de contrôle d’accès routes inverses modification des protocoles intra-domaines


Simple Multicast (RAMA: Crowcroft, Perlman et al)

Groupe identifié par un couple (@Core, ID) plus besoin de déterminer le Core pas de problème d ’allocation d ’adresse multicast arbre bidirectionnel à la CBT mais inter-domaine nécessite un niveau d’adressage en plus

nouveau protocole au dessus de IP

modification soit de IGMP (et join traités dans les routeurs) soit dans les hôtes qui génèrent les join


Simple Multicast (suite)

Problèmes dépendance à la racine (fiabilité) chemins inverses contrôle overhead changement des interfaces hôtes


EXPRESS (Holbrook et Cheriton)

Notion de canal (channel) uni-directionnel une source vers n récepteurs adressé par couple (@source, ID) pas de problème d’allocation d’adresse

prévu pour des applications de type canaltélé

join envoyé du récepteur vers la source pas de problème de localisation du centre


EXPRESS

Contrôle d’accès possibilité de clé d’authentification

par canal stockée dans les routeurs de l’arbre du canal

Arbre uni-directionnel facilite l’accounting (la source paye)


EXPRESS : Commentaires

Assez simple (pas de MASC, IGMP, BSR) Possibilité de contrôle d’accès Mécanismes d’accounting Pas extensible aux grands groupes multipoint

à multipoint (pas de feedback) Chemins dans le mauvais sens Vulnérable à la panne de la source


QoSMIC (Faloutsos et al, SIGCOMM 98)

QoS de l ’arbre obtenue par calcul de plusieurs chemins arbre <-> membre évaluation du meilleur chemin les chemins peuvent être calculés de la racine

vers le membre « bonne direction » en envoyantles requêtes à un routeur racine


Architecture LAR

Logical Addressing and Routing: un niveau d ’adresses logiques au dessus des

adresses de routage (2 niveaux comme dansSimple)

adresse logique d ’un groupe dérivée del ’adresse logique de son gestionnaire

Déport de certaines fonctions hors des routeursvers des gestionnaires de groupe (en général laracine)


LAR (suite)

adhésions envoyées du membre vers legestionnaire puis à travers l’arbre vers lemembre (calcul du chemin dans le bon sens)

Les sources adhèrent à l’arbre arbres bi-directionnels par défaut arbres réduits (tunneling à travers les

routeurs de degré 2 ou n ’implantant pas leprotocole)

unification avec les mécanismes de mobilité


LAR (fin)

Avantages: moins d ’états (arbres réduits) indépendance de la racine (indirection) chemins calculés dans le bon sens insertion des mobiles

Inconvénients overhead des 2 niveaux concentration des joins à la racine diverge du modèle de Deering ?


Conclusions (1)

Problèmes avec le modèle de Deering l’existence d ’un groupe n’est pas définie

manque de contrôle les émetteurs ne sont pas membres

protocole plus complexe (mécanismessupplémentaires) pas très réaliste (contrôle applicatif des émetteurs)

problèmes déportés dans les routeurs


Conclusions (2)

les arbres sont construits en utilisant lesroutes unicast récepteur vers arbre problème avec routes asymétriques (satellite) perte de ressources

branche « morte » vers un groupe inexistant ouinterdit

contrôle plus difficile (branche composée derouteurs non encore authentifiés dans l ’arbre)

Vulnérabilité de la racine


Références

Modèle de Deering:Multicast Routing in Datagram Internetwork, Ph.D thesis, Stanford University, 1991.

Groupes de l ’IETFIDMR : http://www.ietf.org/html.charters/idmr-charter.htmlPIM : http://www.ietf.org/html.charters/pim-charter.htmlMALLOC : http://www.ietf.org/html.charters/malloc-charter.htmlMOSPF : http://www.ietf.org/html.charters/mospf-charter.html

Simple Multicast et EXPRESShttp://www.cs.ucl.ac.uk/research/rama

Documents

Routage multipoint inter-domaineicube-publis.unistra.fr/docs/1225/rhdm99-Pansiot.pdfRoutage multipoint inter-domaine Jean-Jacques PANSIOT & Abdelghani ALLOUI LSIIT - Université Louis