Dossier délivré pour

DOCUMENTATION
21/10/2008

Le multicast MPLS

par Jean-Louis LE ROUX

Expert senior, Orange Labs

1. Généralités ................................................................................................. TE 7 578 -2

2. Plan de transfert Multicast MPLS ....................................................... — 2
2.1 Arbre MPLS multicast .................................................................................. — 2
2.2 Opérations sur le LSR racine....................................................................... — 4
2.3 Opérations sur un LSR branche .................................................................. — 4
2.4 Opérations sur un LSR feuille ..................................................................... — 4
3. Plan de commande multicast MPLS ................................................... — 5
3.1 Multicast LDP (MLDP) .................................................................................. — 5
3.1.1 Principes .............................................................................................. — 5
3.1.2 Identification d’un arbre MLDP .......................................................... — 5
3.1.3 Procédures MLDP................................................................................ — 5
3.2 Multicast MPLS-TE ....................................................................................... — 9
3.2.1 Opérations multicast MPLS-TE .......................................................... — 9
3.2.2 Calcul de l’arbre .................................................................................. — 11
3.2.3 Signalisation de l’arbre : protocole P2MP RSVP-TE......................... — 12
3.2.4 Ajout/suppression de feuilles P2MP MPLS-TE ................................. — 18
3.2.5 Réoptimisation P2MP MPLS-TE ......................................................... — 18
3.2.6 Restauration P2MP MPLS-TE ............................................................. — 18
3.2.7 Fast Reroute P2MP MPLS-TE ............................................................ — 18
3.2.8 Protection de lien P2MP MPLS-TE ..................................................... — 18
3.2.9 Protection de nœud P2MP MPLS-TE ................................................. — 18
4. Application au transport du multicast IP .......................................... — 20
4.1 Interconnexion P2MP MPLS-TE statique ................................................... — 20
4.2 Interconnexion P2MP MPLS-TE dynamique .............................................. — 20
5. Conclusions et perspective ................................................................... — 23
Références bibliographiques.......................................................................... — 24

a croissance des applications multicast avec de fortes contraintes de bande

L passante, de qualité de service et de disponibilité (par exemple IPTV,
conférences multipoints, jeux...), et la nécessité d’encapsuler ces flux multicast
dans des tunnels pour le support des réseaux privés virtuels (VPN) multicast,
ont conduit à étendre la technologie MPLS (Multi Protocol Label
5 - 2008

Switching ) ([16] [17]), définie initialement pour du tunneling, de l’ingénierie de

trafic et de la sécurisation unicast, au transport de flux multicast ([18]). L’archi-
tecture MPLS multicast, étend le mode de commutation MPLS pour supporter
des LSP (Label Switched Path) MPLS, ayant une source et plusieurs
destinations, avec une réplication sur certains routeurs de transit, permettant
TE 7 578

une diffusion du trafic de sorte qu’une seule copie d’un paquet est envoyée sur
un lien du réseau. Ces LSP sont appelés LSP P2MP (point-to-multipoint ).
L’architecture MPLS multicast hérite des propriétés de tunneling, d’ingénierie
de trafic et de sécurisation de MPLS. Elle permet l’encapsulation du trafic

Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie

est strictement interdite. – © Editions T.I. TE 7 578 – 1

Dossier délivré pour

DOCUMENTATION
21/10/2008
 Dossier délivré pour
DOCUMENTATION
21/10/2008

LE MULTICAST MPLS ________________________________________________________________________________________________________________

multicast dans des tunnels pour le support de VPN, l’optimisation des arbres
multicast et la protection rapide des arbres multicast. Ce dossier présente les
concepts de base de la technologie MPLS multicast et aborde brièvement son
application au transport du multicast IP. Il n’aborde pas les fonctions MPLS
multicast avancées (routage dans les VPN MPLS multicast, MPLS multipoint à
multipoint, hiérarchie MPLS multicast).
Les dossiers [TE 7 535], [TE 7 577] et [TE 7 527] constituent un pré-requis
pour cet article ([16] [17] [18]).
Un tableau des sigles et abréviations se trouve en fin de l’article.

1. Généralités tion MPLS unicast, LDP et RSVP-TE. Il existe donc, comme en uni-
cast, deux modes pour l’établissement des arbres, le mode non
connecté et le mode connecté. Le mode multicast MPLS non
Il y a dix ans que la technologie MPLS (Multi Protocol Label connecté repose sur une extension du protocole LDP, appelée
Switching ) a été conçue à l’IETF (Internet Engineering Task Force) « multicast LDP » (MLDP). Les arbres LDP suivent le plus court
pour le transport de flux unicast. MPLS repose sur un label inséré chemin vers la racine. Le mode multicast MPLS connecté, ou
après l’en-tête de la couche 2 du modèle OSI, utilisé par un routeur « P2MP MPLS-TE » (point-to-multipoint MPLS Traffic Engineering ),
MPLS, appelé « LSR » (Label Switching Router ), pour déterminer repose sur une extension du protocole RSVP-TE dite « P2MP
l’interface et le label de sortie. Un chemin MPLS entre un routeur RSVP-TE ». Les arbres P2MP RSVP-TE sont établis de façon expli-
d’entrée et un routeur de sortie est nommé « LSP » (Label Swit- cite et empruntent des chemins indépendants des chemins IP, res-
ched Path ) ou « tunnel MPLS ». Les opérateurs utilisent la techno- pectant des contraintes d’ingénierie de trafic (bande passante...).
logie MPLS pour assurer la connectivité entre leurs routeurs Le mode connecté permet un contrôle d’admission et une optimi-
d’accès (Provider Edge router, PE ). La technologie MPLS offre trois sation des arbres. Il permet également de protéger les arbres sur
fonctions essentielles : l’encapsulation de trafic (tunneling MPLS) une extension des mécanismes de protection MPLS Fast Reroute,
utilisée pour le support des réseaux privés virtuels (VPN), l’ingé- appelée « P2MP MPLS Fast Reroute ».
nierie de trafic incluant un contrôle d’admission et l’optimisation
de la bande passante, qui permet de partager la charge et d’éviter
les congestions, et enfin la protection de trafic permettant un
reroutage en moins de 50 ms en cas de panne. 2. Plan de transfert multicast
Il existe deux modes pour l’établissement d’un LSP MPLS : le
mode non connecté et le mode connecté. En mode non connecté, MPLS
les LSP sont établis par le protocole LDP (Label Distribution
Protocol ) et suivent le plus court chemin IP. En mode connecté, ils 2.1 Arbre MPLS multicast
sont établis par le protocole RSVP-TE (MPLS Traffic Engineering )
et suivent un chemin explicite, indépendant du chemin IP, qui res-
pecte un certain nombre de contraintes d’ingénierie de trafic Le concept de LSP MPLS P2MP, encore appelé « arbre
(bande passante, délai...). Le mode connecté permet le support de MPLS », est défini dans la norme IETF RFC4461. Un arbre MPLS
l’ingénierie de trafic : en effet, les chemins sont établis en fonction possède un LSR tête, dit « LSR racine », et un ou plusieurs LSR
des contraintes de trafic et des ressources disponibles. Il permet destinations, appelés « LSR feuilles ». Certains LSR de transit
également une protection en moins de 50 ms en cas de panne de de l’arbre ont plusieurs routeurs en aval. Ces LSR sont chargés
lien ou de nœuds, appelée MPLS « Fast Reroute », où les LSP pri- de la réplication MPLS, ils sont appelés « LSR branches ».
maires sont protégés par des LSP de secours locaux établis à
l’avance, qui sont activés pendant la panne.
Nota : dans la suite on utilisera indistinctement les termes LSR tête/LSR racine et les
L’architecture MPLS a été initialement définie pour le transport termes LSR destination/LSR feuille.
de trafic unicast avec des tunnels MPLS ayant une seule destina-
tion et donc non adaptés au transport du trafic multicast. La crois- Un arbre MPLS peut, par exemple, être utilisé pour transporter
sance des flux multicast avec de fortes contraintes de bande un groupe multicast IP ou un ensemble de groupes multicast IP. Le
passante et de disponibilité (par exemple IPTV, visioconférence trafic est injecté dans l’arbre par le LSR racine qui ajoute le label
multipoint, jeux en réseau) et le besoin de transporter ces flux MPLS (opération push ). Ce trafic est déterminé par la table de
dans des réseaux privés virtuels (VPN) nécessite de disposer de routage IP multicast du LSR racine. Les LSR branches répliquent
fonctions de tunneling multicast, de traffic engineering multicast les paquets MPLS sur plusieurs interfaces de sortie avec les labels
(optimisation des arbres, contrôle d’admission) et de protection de sortie correspondants (opération swap ). Les LSR feuilles sup-
multicast. priment le label MPLS (opération pop ) et routent les paquets en
utilisant la table de routage IP multicast. De façon similaire au mul-
Pour répondre à ces besoins, l’IETF a étendu l’architecture MPLS ticast IP ou, à Ethernet, une seule copie d’un paquet transite sur un
afin de supporter efficacement le transport des flux multicast, c’est lien d’un arbre MPLS.
ce que l’on appelle le « multicast MPLS ». Le multicast MPLS
repose sur l’établissement de LSP MPLS point-à-multipoint La figure 1 illustre un LSP P2MP « L1 », entre le LSR tête R1 et
(P2MP), ou arbres MPLS ; il s’agit de LSP avec un LSR de tête les LSR feuilles R5, R6, R7 et R8, utilisé pour transporter un ensem-
appelé « LSR racine » et un ensemble de LSR destinations appelés ble de groupes IP multicast (232.1/16). Elle représente le contenu
« LSR feuilles », avec une réplication du trafic sur les routeurs de des tables MPLS, ainsi que l’aiguillage d’un paquet IP multicast,
transit. Le multicast MPLS hérite de toutes les propriétés de MPLS. depuis la racine vers les feuilles. Les LSR R2, R4 et R3 sont des
LSR branches, ils répliquent le trafic vers plusieurs LSR en aval.
Nota : dans la suite de ce dossier, on utilisera indistinctement les termes « LSP
P2MP » et « arbre MPLS ».
Sur le routeur racine R1, le paquet IP multicast à destination du
groupe 232.1.1.1 est routé en utilisant la table de routage IP multi-
Pour la mise en place des arbres MPLS, l’approche pragmatique cast qui indique d’emprunter le LSP L1. Une table de LSP indique
suivie par l’IETF a consisté à étendre les protocoles de signalisa- le label et le routeur voisin pour le LSP L1 (24, R2). Le paquet est

Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie

TE 7 578 − 2 est strictement interdite. − © Editions T.I.

Dossier délivré pour

DOCUMENTATION
21/10/2008
Dossier délivré pour
DOCUMENTATION
21/10/2008

________________________________________________________________________________________________________________ LE MULTICAST MPLS

LSR feuille

R5 IP 232.1

60 IP 232.1 Table MPLS

60 → pop, Table IP mcast
LSR branche
Table MPLS
R3 30 → swap 60, R5
swap 50, R6
50 IP 232.1
Trafic IP Multicast 30 IP 232.1
Table MPLS R6 IP 232.1
24 → swap 30, R3
swap 31, R4 Table MPLS
LSR tête 24 IP 232.1 50 → pop, Table IP mcast
IP 232.1 R1 R2

Table IP Multicast
232.1/16 → L1
31 IP 232.1
R7 IP 232.1
Table de LSP
L1 → Push 24, R2 42 IP 232.1 Table MPLS
42 → pop, Table IP mcast

LSR bourgeon R4

28 IP 232.1
Table MPLS
31→ swap 42, R7 R8 IP 232.1
swap 28, R8
IP Table MPLS
pop, Table IP mcast
28 → pop, Table IP mcast
LSP P2MP L1

Figure 1 – Arbre MPLS pour le transport de l’IP

LSR feuille

R5 T

60 T Table MPLS
60 → pop, Table Domaine D
LSR branche Table MPLS
R3 30 → swap 60, R5
swap 50, R6
3
50 T
Trafic T Table MPLS 30 T
24 → swap 30, R3 R6 T
swap 31, R4 Table MPLS
LSR tête 24 T 50 → pop, Table Domaine D
T R1 R2

Table domaine D
T → L1
31 T
R7 T
Table de LSP 42 T Table MPLS
L1 → Push 24, R2 42 → pop, Table Domaine D

LSR bourgeon R4

28 T
Table MPLS
31 → swap 42, R7 R8 T
swap 28, R8
T Table MPLS
pop, Table Domaine D 28 → pop, Table Domaine D
LSP P2MP L1

Figure 2 – Arbre MPLS offrant un service de connectivité P2MP à un domaine de routage D

Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie

est strictement interdite. – © Editions T.I. TE 7 578 – 3

Dossier délivré pour

DOCUMENTATION
21/10/2008
 Dossier délivré pour
DOCUMENTATION
21/10/2008

LE MULTICAST MPLS ________________________________________________________________________________________________________________

donc transmis vers R2 avec le label 24. Le paquet est ensuite une interface logique. Le remplissage de la table de routage du
répliqué par les LSR branches R2, R3 et R4. La spécificité de la domaine client et l’utilisation des arbres peuvent se faire de
commutation MPLS multicast repose sur la fonction de LSR bran- manière statique par configuration (routes statiques) ou de
che. Par exemple, ici, le LSR R2 contient deux sorties dans sa table manière dynamique, via un protocole propre au domaine de rou-
MPLS pour le label 24. Sur réception d’un paquet MPLS avec le tage client.
label 24 (label localement alloué par R2 pour l’arbre), R2 envoie Dans le cas du transport de trafic IP multicast, l’arbre va être uti-
une copie du paquet vers le routeur R3 avec le label 30 (label loca- lisé pour transporter un ou plusieurs groupes multicast. Si l’arbre
lement attribué par R3 pour l’arbre) et une copie vers le routeur R4 A est utilisé pour transporter le groupe IP multicast G, on aura
avec le label 31 (label localement alloué par R4 pour l’arbre). Le l’entrée suivante dans la table de routage IP multicast du routeur
LSR R5 est un LSR feuille, il enlève le label MPLS (opération pop ) racine :
et route le paquet IP multicast en utilisant la table de routage IP
multicast.
Le routeur R4 réalise ici une fonction particulière : il est à la fois IP Mcast G -> A
feuille et transit de l’arbre, c’est-à-dire qu’il fait à la fois une opéra-
tion de suppression de label (pop ) ainsi qu’une opération de Un paquet IP multicast envoyé vers l’adresse de groupe G et
changement de label (swap ). Cette fonction particulière est appe- reçu sur le LSR racine sera injecté dans l’arbre A : il sera envoyé
lée « LSR bourgeon » (ou bud LSR en anglais), il s’agit d’un LSR vers les voisins V1 à Vn avec les labels L1 à Ln.
qui est feuille de l’arbre et a également au moins un LSR en aval
dans l’arbre. Dans le cas du transport de trafic IP multicast d’un VPN V, l’arbre
va être utilisé pour transporter un ou plusieurs groupes multicast
Les services de transport du multicast MPLS ne se limitent pas de V. Si l’arbre A est utilisé pour transporter le groupe IP multicast
au transport du multicast IP natif, un arbre MPLS peut aussi être G, on aura l’entrée suivante dans la table VRF (Virtual Routing and
utilisé pour transporter du trafic multicast d’un VPN IP ou d’un Forwarding ) IP multicast du VPN V sur le routeur racine :
VPN de niveau 2 (Ethernet, ATM, TDM...). On aura, dans ce cas, un
arbre distinct par VPN.
Le trafic à injecter dans un arbre MPLS est déterminé par la table IP Mcast G -> A
de routage du domaine client de l’arbre (par exemple la table de
routage IP multicast globale, la table de routage IP multicast d’un Un paquet IP multicast du VPN V envoyé vers l’adresse de
VPN IP, la table Ethernet d’un VPN Ethernet...). Les LSR branches groupe G et reçu sur le LSR sera injecté dans l’arbre A et transmis
répliquent les paquets MPLS sur plusieurs interfaces de sortie avec aux voisins V1 à Vn avec les labels L1 à Ln.
les labels de sortie correspondants (opération swap ). Les LSR
L’ensemble des groupes IP multicast qui sont transportés dans
feuilles suppriment le label MPLS et routent les paquets dans la
un arbre peut être déterminé de façon statique (route statique mul-
table de routage du domaine client de l’arbre.
ticast configurée sur la racine) ou de façon dynamique via un pro-
La figure 2 illustre un arbre MPLS L1, entre le LSR racine R1 et tocole de routage multicast entre la racine et les feuilles (voir les
les LSR feuilles R5, R6, R7 et R8, utilisé pour transporter le trafic du sections 4.1 et 4.2 respectivement).
domaine client D. Sur le routeur racine R1, le trafic T est routé en
Dans le cas du transport de trafic Ethernet, l’arbre va être utilisé
utilisant la table de routage du domaine client D qui indique
pour transporter par exemple tout le contenu d’un port Ethernet
d’emprunter le LSP L1. Une table de LSP indique le label et le
logique (VLAN). Si l’arbre A est utilisé pour transporter le trafic
routeur voisin pour le LSP L1 (24, R2). Le paquet est donc transmis
Ethernet reçu sur le port 1 avec le VLAN 1 on aura l’entrée suivante
vers R2 avec le label 24. Le LSR R5 est un LSR feuille, il enlève le
dans la table Ethernet du LSR racine :
label MPLS (opération pop ) et route le paquet en utilisant la table
de routage du domaine client D.
Un arbre MPLS multicast peut être établi de façon statique, par Port 1, VLAN 1 -> A
configuration des fonctions MPLS (push, swap, pop ) sur tous les
routeurs de l’arbre ou de façon dynamique, via un protocole de Une trame Ethernet avec le VLAN 1 reçue sur le port 1 du LSR
signalisation distribuée. Il existe deux protocoles de signalisation sera injectée dans l’arbre A, elle sera envoyée vers les voisins V1 à
d’arbre MPLS : le protocole multicast LDP (MLDP) et le protocole Vn, avec les labels L1 à Ln.
P2MP RSVP-TE qui seront abordés dans la partie 3. Il est possible
avec ces protocoles d’ajouter/supprimer dynamiquement des
feuilles de l’arbre en fonction de l’activité des récepteurs multicast
derrière ces feuilles. Cela nécessite des mécanismes d’autodécou-
2.3 Opérations sur un LSR branche
verte qui seront abordés dans la section 4.
Un LSR branche d’un arbre A, ayant pour voisin en aval les
nœuds V1 à Vn, avec les labels L1 à Ln et ayant localement alloué
le label L pour A, va installer dans sa table de routage MPLS
2.2 Opérations sur le LSR racine l’entrée suivante :
Le LSR racine d’un arbre MPLS A, ayant en aval les nœuds V1 à
Vn, avec les labels L1 à Ln, va installer l’entrée suivante dans sa L -> Swap L1, V1
table de LSP : ...
Swap Ln, Vn
A -> Push L1, V1
... Lorsque le LSR reçoit un paquet MPLS avec le label L, il le répli-
Push Ln, Vn que vers les routeurs V1 à Vn avec les labels L1 à Ln.

Un paquet injecté dans l’arbre A1 sera envoyé vers les voisins

V1 à Vn avec les labels L1 à Ln.
2.4 Opérations sur un LSR feuille
La table de routage du domaine client de l’arbre installe un Un LSR feuille supprime le label et route le paquet dans la table
ensemble de trafics T1 à Tm dans l’arbre qui est considéré comme de routage du domaine client de l’arbre. Un LSR feuille d’un

Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie

TE 7 578 – 4 est strictement interdite. – © Editions T.I.

Dossier délivré pour

DOCUMENTATION
21/10/2008
Dossier délivré pour
DOCUMENTATION
21/10/2008

________________________________________________________________________________________________________________ LE MULTICAST MPLS

arbre A ayant alloué le label L pour A va installer dans sa table de dessous décrivent les extensions apportées à LDP et à RSVP-TE
routage MPLS l’entrée suivante : pour l’établissement d’arbre MPLS et proposent une rapide
comparaison des deux solutions.
L -> pop, routage dans la table du domaine client de A
3.1 Multicast LDP (MLDP)
Cette opération exige que le LSR feuille connaisse le domaine
client de l’arbre MPLS et donc connaisse l’arbre MPLS sur lequel le 3.1.1 Principes
trafic est reçu. La connaissance de l’arbre sur lequel le trafic est
reçu nécessite d’avoir un label sur le dernier lien de l’arbre et donc Le protocole LDP (Label Distribution Protocol ) défini dans la
de désactiver la fonction PHP (Penultimate Hop Popping ) laquelle norme IETF RFC-3036 [2] permet l’établissement de LSP unicast le
consiste à ne pas avoir de label sur le dernier lien d’un LSP. long de la route IP. Le protocole multicast LDP (MLDP) est une
extension du protocole LDP mettant en place des LSP P2MP. Les
Nota : en MPLS unicast il n’y a, par défaut, pas de label sur le dernier lien d’un LSP
(on parle de PHP, Penultimate Hop Popping ) ou alors le label présent est un label nul
LSP P2MP LDP sont construits sur le plus court chemin vers le LSR
(Label 0), il n’est donc pas possible de déterminer sur quel LSP le trafic est reçu. racine. Leur établissement est initié par les LSR feuilles et les LSR
de transit ne maintiennent pas l’information sur les feuilles mais
La connaissance sur le LSR feuille du domaine client d’un arbre uniquement sur les LSR voisins dans l’arbre. MLDP passe donc
MPLS peut être obtenue de façon statique par configuration, ou de très bien à l’échelle, la taille d’un état étant indépendante du nom-
façon dynamique par une extension BGP permettant à la racine bre de feuilles de l’arbre. MLDP est bien adapté aux opérateurs de
d’annoncer aux feuilles le domaine associé à un arbre (extensions VPN MPLS qui ont déjà déployé LDP pour le transport de trafic uni-
BGP multicast définies dans le projet de norme IETF BGP- cast et veulent offrir des services multicast.
MCAST [8]).
Les procédures et extensions protocolaires MLDP sont définies
Une feuille d’un arbre A transportant du trafic IP multicast natif, dans le projet de norme IETF MP-LDP [9], elles répondent à
qui a alloué le label L pour le LSP, installe l’entrée suivante dans sa l’expression du besoin définie dans le projet de norme IETF MP-
table MPLS : LDP-REQ [10].
Dans le protocole LDP le message principal est le message
L -> pop, routage dans table multicast IP LabelMap. Ce message permet à un routeur d’annoncer à ses
voisins le label qu’il a alloué à un LSP.
Lorsque le LSR reçoit un paquet avec le label L, il supprime le Pour supporter l’établissement d’un arbre MPLS, le message
label et route le paquet en utilisant la table de routage IP multicast. LDP LabelMap est étendu et inclut un identifiant d’arbre. Pour éta-
Il effectue éventuellement une opération de vérification d’interface blir un arbre MPLS, les feuilles envoient un message LDP Label-
(RPF Check ) en utilisant L comme identifiant d’interface. Map contenant le même identifiant d’arbre, en direction de la
racine, on appelle ces messages « P2MP LabelMap ». Les messa-
Nota : RPF check (Reverse Path Forwarding ). ges P2MP LabelMap distribuent les labels le long de l’arbre par le
plus court chemin vers la racine. Il en résulte un arbre MPLS
Une feuille d’un arbre A transportant le trafic d’un VPN V (IP ou empruntant les plus courts chemins de la racine aux feuilles.
niveau 2) qui a alloué le label L pour le LSP, installe l’entrée
suivante dans sa table MPLS. La construction d’un arbre MPLS avec le protocole MLDP est
donc très similaire à la construction d’un arbre multicast IP avec le
protocole PIM RFC-4601 [6]. Essentiellement porté par le besoin de
L -> pop, routage dans la table VRF du VPN V multicast dans les VPN, le travail sur MLDP a démarré à l’IETF il y
a deux ans. La spécification MLDP n’est pas stable, elle est en
cours de maturation : il n’y a pas d’implémentation commerciale
Lorsque le LSR reçoit un paquet avec le Label L, il supprime le connue au moment où ce papier est écrit.
paquet et le route dans la table VRF du VPN V.
Les opérations dans le plan de transfert d’un LSR bourgeon sont
laissées comme exercice au lecteur.
3.1.2 Identification d’un arbre MLDP
Un arbre MLDP est identifié par un identifiant opaque de taille
variable appelé « opaque-id », généré par le LSR racine. Cet identi-
fiant est dit « opaque » car il peut avoir différentes sémantiques
3. Plan de commande (adresse de groupe multicast, identifiant de VPN) et son contenu
n’est analysé que sur les LSR racine et LSR feuilles. Il n’est pas
multicast MPLS analysé sur les LSR de transit qui l’utilisent comme simple identi-
fiant de LSP. La combinaison de l’adresse IP de la racine et de
l’opaque-id identifie de façon unique un arbre MPLS.
L’établissement d’un arbre MPLS peut être réalisé de manière
statique, par configuration des correspondances de labels sur tous Cet identifiant est transporté dans les messages MLDP. Pour
les LSR de l’arbre. Cette approche est simple mais vite lourde en cela, un nouveau type d’identifiant de LSP LDP (appelé FEC Ele-
termes de configuration et surtout peu réactive aux pannes ou aux ment dans LDP) est défini, il s’agit du type P2MP (P2MP FEC
changements de topologies. Element ), il encode l’adresse de la racine ainsi que l’opaque-id, de
taille variable. La figure 3 représente l’encodage d’un identifiant
Afin d’assurer une automaticité et une dynamicité de l’établisse-
d’arbre transporté dans les messages MLDP tel que défini dans le
ment des arbres MPLS, il est nécessaire de disposer d’un proto-
projet de norme MP-LDP [9].
cole de signalisation qui distribue les labels entre LSR le long de
l’arbre. Pour supporter cette fonction, le groupe de travail MPLS de
l’IETF a choisi d’étendre les deux protocoles de signalisation MPLS 3.1.3 Procédures MLDP
unicast : LDP et RSVP-TE. Cette approche pragmatique permet de
réutiliser au maximum les procédures de signalisation existantes, Pour faciliter la description des procédures MLDP, les notations
et donc d’accélérer les implémentations et de faciliter leur inter- suivantes sont utilisées :
opérabilité. Cette approche évite aussi la multiplication des proto- • <X, Y> : un identifiant d’arbre avec pour racine X et opaque-id
coles dans le réseau et facilite ainsi les opérations. Les sections ci- Y.

Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie

est strictement interdite. – © Editions T.I. TE 7 578 – 5

Dossier délivré pour

DOCUMENTATION
21/10/2008
 Dossier délivré pour
DOCUMENTATION
21/10/2008

LE MULTICAST MPLS ________________________________________________________________________________________________________________

• En l’absence d’état associé à l’arbre <Ru, Y>, il crée cet état et

installe, dans sa table de LSP, l’entrée

<Ru, Y> -> (push L, Rd).

• S’il découvre un état associé à l’arbre <Ru, Y>, il ajoute la sor-

tie (push L, Rd) à l’entrée associée à l’arbre <Ru, Y> dans sa
table de LSP.
La détermination du trafic à injecter dans un arbre peut se faire
de façon statique ou dynamique, via un échange d’informations
d’abonnement multicast entre la racine et les feuilles.
Figure 3 – Identifiant d’arbre transporté dans les messages MLDP Les figures 4, 5 et 6 illustrent l’établissement d’un arbre MPLS
avec le protocole MLDP. Cet arbre a pour racine R1 et pour feuilles
R5, R6 et R8. Il a pour identifiant <R1, 1> (opaque id = 1).
• P2MP LabelMap <X, Y, L> : un message LDP LabelMap pour La feuille R5 rejoint l’arbre en premier (cf. figure 4). Elle alloue le
l’arbre <X, Y> distribuant le label L. label 28 pour l’arbre, détermine R3 comme routeur en amont vers
la racine R1 et lui envoie un message P2MP LabelMap <R1, 1, 28>.
3.1.3.1 Établissement d’un arbre MLDP R3 détermine qu’il n’a pas d’état pour l’arbre <R1, 1>, il crée cet
état, alloue le label 18 pour l’arbre, détermine un routeur en
amont, R2, et envoie un message P2MP LabelMap <R1, 1, 18> vers
3.1.3.1.1 Procédure des LSR feuilles R2. Il met ensuite à jour sa table de routage MPLS et installe
Pour rejoindre un arbre MPLS <X, Y>, un LSR feuille détermine l’entrée :
un LSR voisin, Ru, en amont sur l’arbre. Il s’agit d’un LSR voisin
présent sur un plus court chemin vers la racine de l’arbre ; il est
déterminé en consultant la table de routage IP. Le LSR feuille 18 -> (swap 28, R5)
alloue un label L pour l’arbre et envoie un message P2MP Label-
Map <X, Y, L> vers Ru. Il ajoute l’entrée suivante dans sa table Sur réception de ce message, R2 fait de même, il alloue le label
MPLS : 23 pour l’arbre, envoie un message P2MP LabelMap <R1, 1, 23> à
R1 et installe dans sa table MPLS l’entrée :
L1 -> pop, routage dans la table du domaine client de l’arbre
<X, Y> 23 -> (swap 18, R3)

Pour rejoindre un arbre, la feuille doit avoir connaissance de Enfin, la racine R1 reçoit ce message P2MP LabelMap : elle
l’identifiant <X, Y> de l’arbre et de l’ensemble des canaux multi- détermine qu’il n’existe pas d’état associé à l’arbre <R1, 1>, crée
cast transportés par cet arbre. Cela peut être connu de façon sta- cet état et met à jour sa table de LSP en ajoutant l’entrée :
tique, par configuration statique sur la feuille, ou découvert
automatiquement, par un échange d’information de la racine vers
<R1, 1> -> (push 23, R2)
les feuilles via une extension du protocole BGP, actuellement en
cours de spécification à l’IETF (cf. projet de norme BGP-
MCAST [8]). La feuille R6 rejoint ensuite l’arbre (cf. figure 5). Elle attribue le
label 50 pour l’arbre, détermine R3 comme routeur en amont vers
3.1.3.1.2 Procédure des LSR de transit la racine R1 et lui envoie un message P2MP LabelMap <R1, 1, 50>.
R3 détermine qu’il a déjà un état pour l’arbre <R1, 1>, il met à jour
Quand un LSR de transit (Ru) reçoit un message P2MP LabelMap l’entrée correspondante dans sa table MPLS (label 18) et ajoute la
<X, Y, L> d’un LSR en aval (Rd), il vérifie s’il existe déjà un état sortie :
pour l’arbre <X, Y>.
• S’il n’y a aucun état associé à l’arbre <X, Y>, il crée cet état : (swap 50, R6)
il alloue un label L′ pour cet arbre et détermine un LSR voisin,
Ru, en amont sur un plus court chemin vers la racine, en
consultant sa table de routage IP. Dans la table MPLS il La feuille R8 rejoint enfin l’arbre (cf. figure 6). Elle alloue le label
ajoute l’entrée. 81 pour l’arbre, détermine R4 comme routeur en amont vers la
racine R1 et lui envoie un message P2MP LabelMap <R1, 1, 81>. R4
détermine qu’il n’a pas déjà un état pour l’arbre <R1, 1>, il crée cet
L′ -> (swap L, Rd) état, alloue le label 31, détermine R2 comme routeur en amont
vers la racine, lui envoie le message P2MP LabelMap <R1, 1, 31> et
ajoute l’entrée :
Puis il envoie un message P2MP LabelMap <X, Y, L′> à Ru.
• S’il existe déjà un état associé à l’arbre <X, Y> avec le label 31 -> (swap 81, R8)
L′, il ajoute la sortie (swap L, Rd) au label L′ dans sa table
MPLS et ne propage pas le message en amont.
Sur réception de ce message, R2 détermine qu’il a déjà un état
pour l’arbre <R1, 1>, il met à jour l’entrée correspondante dans sa
3.1.3.1.3 Procédure du LSR racine table MPLS (label 23), et ajoute la sortie :
Quand un LSR racine (Ru) reçoit un message P2MP LabelMap
<Ru, Y, L> d’un LSR en aval (Rd), il vérifie s’il existe déjà un état
(swap 31, R4)
pour l’arbre <Ru, Y>.

Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie

TE 7 578 – 6 est strictement interdite. – © Editions T.I.

Dossier délivré pour

DOCUMENTATION
21/10/2008
Dossier délivré pour
DOCUMENTATION
21/10/2008

________________________________________________________________________________________________________________ LE MULTICAST MPLS

État <R1,1>

P2MP LabelMap R5
<R1, 1, 28>

État <R1,1>
Table MPLS
R3 18 → swap 28, R5

P2MP LabelMap
<R1, 1, 18>
R6
P2MP LabelMap
État <R1,1> <R1, 1, 23>
LSR racine Table MPLS
R1 R2 23 → swap 18, R3

Table LSP État <R1, 1>

<R1, 1> → push 23, R2
R7

R4

R8

Figure 4 – Établissement d’un arbre MPLS avec le protocole LDP : ajout de R5

État <R1,1>

R5

État <R1,1> Table MPLS

R3 18 → swap 28, R5
swap 50, R6

R6
P2MP LabelMap État <R1, 1>
État <R1,1> <R1, 1, 50>
Table MPLS
R1 R2 23 → swap 18, R3
État <R1, 1>
Table LSP
<R1, 1> → push 23, R2
R7

R4

R8

Figure 5 – Établissement d’un arbre MPLS avec le protocole LDP : ajout de R6

Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie

est strictement interdite. – © Editions T.I. TE 7 578 – 7

Dossier délivré pour

DOCUMENTATION
21/10/2008
 Dossier délivré pour
DOCUMENTATION
21/10/2008

LE MULTICAST MPLS ________________________________________________________________________________________________________________

État <R1,1>

R5

État <R1,1>
Table MPLS
R3 18 → swap 28, R5
swap 50, R6

R6

État <R1,1> État <R1,1> État <R1,1>

Table MPLS
R1 R2 23 → swap 18, R3
swap 31, R4

Table LSP
<R1, 1> → push 23, R2
R7

P2MP LabelMap
<R1, 1, 31>
État <R1,1> R4
Table MPLS
31 → swap 81, R8

R8
P2MP LabelMap
<R1, 1, 81> État <R1,1>

Figure 6 – Établissement d’un arbre MPLS avec le protocole LDP : ajout de R8

3.1.3.2 Suppression de feuille dante (label 31) de sa table MPLS et envoie un message P2MP
LabelWithdraw <R1, 1, 31> vers le routeur en amont R2. Sur récep-
Lorsqu’une feuille veut quitter un arbre <X, Y> elle envoie un
message LDP LabelWithdraw, contenant l’identifiant de l’arbre. Un tion de ce message R2 détermine que R4 n’est pas le seul routeur
en aval, il maintient donc l’état de l’arbre <R1, 1> et enlève simple-
tel message est noté :
ment la sortie (swap 31, R4) de l’entrée MPLS correspondant à
<R1, 1> (label 23).
P2MP LabelWithdraw <X, Y, L>
3.1.3.3 Changement du routeur en amont
Une feuille peut être amenée à quitter un arbre pour plusieurs En cas de modification de la topologie due par exemple à un
raisons, en particulier quand elle n’a plus de récepteurs pour le changement de métrique ou à une panne, il se peut que le plus
trafic multicast transporté dans l’arbre. court chemin vers la racine soit modifié et donc que le routeur en
• Lorsqu’un nœud de transit (Ru) reçoit un message P2MP amont change. Dans ce cas, l’arbre MPLS est rerouté dynamique-
LabelWithdraw <X, Y, L> envoyé par un LSR en aval (Rd), ment sur le nouveau routeur en amont.
alors : Lorsqu’un routeur Rd sur un arbre <X, Y> ayant pour routeur en
– si Rd était le seul routeur en aval : Ru supprime de sa table amont Ru1, avec le label L, détecte, par le protocole de routage,
MPLS l’entrée correspondant à l’arbre <X, Y> et propage le mes- que le plus court chemin vers la racine X n’est plus par Ru1 mais
sage P2MP LabelWithdraw vers son routeur en amont ; par Ru2, il reroute l’arbre vers Ru2 de la façon suivante :
– si Rd n’était pas le seul routeur en aval : Ru supprime de sa – étape 1 : il supprime l’état de commutation associé à L de sa
table MPLS la sortie vers Rd : table MPLS ;
– étape 2 : il envoie un message P2MP LabelWithdraw <X, Y, L>
vers Ru1 ;
(swap L, Rd) – étape 3 : il alloue un nouveau label L′ pour <X, Y> et envoie un
message P2MP LabelMap <X, Y, L′> vers Ru2 (déclenchement de
• Lorsque le nœud racine X reçoit un message P2MP Label- l’activation de la nouvelle branche) ;
Withdraw <X, Y, L> envoyé par un LSR en aval (Rd), alors : – étape 4 : il installe le label L′ dans sa table MPLS pour l’arbre
<X, Y>.
– si Rd était le seul routeur en aval : X supprime l’état <X, Y> et
enlève l’arbre <X, Y> de la table des LSP ; L’ordre de ces étapes a un impact sur le trafic. Si les étapes sont
– si Rd n’était pas le seul routeur en aval : il supprime la sortie réalisées dans cet ordre, cela entraîne une perte de paquets entre
vers Rd, (push L, Rd) de l’entrée associée à <X, Y> dans la table des les étapes 1 et 4, ce qui n’est pas gênant si le reroutage est dû à
LSP. une panne, mais devient très pénalisant si le reroutage résulte
La figure 7 illustre le départ de la feuille R8 de l’arbre <R1, 1>. d’un changement de métrique ou d’un ajout d’éléments.
Pour quitter l’arbre <R1, 1>, le routeur R8 envoie un message Si les étapes 3 et 4 sont réalisées avant les étapes 1 et 2, alors
P2MP LabelWithdraw <R1, 1, 81> vers son routeur en amont R4. Le on évite la perte de paquets ; on risque cependant de recevoir le
routeur R4 détermine que R8 est le seul routeur en aval, il sup- trafic en double pendant un certain moment, ce qui aura un impact
prime donc l’état de l’arbre <R1, 1>, enlève l’entrée correspon- très néfaste sur les applications multicast.

Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie

TE 7 578 – 8 est strictement interdite. – © Editions T.I.

Dossier délivré pour

DOCUMENTATION
21/10/2008
Dossier délivré pour
DOCUMENTATION
21/10/2008

________________________________________________________________________________________________________________ LE MULTICAST MPLS

État <R1,1>

R5

État <R1,1> Table MPLS

R3 18 → swap 28, R5
swap 50, R6

R6
État <R1,1>
État <R1,1> État <R1,1>
LSR Racine Table MPLS
R1 R2 23 → swap 18, R3

Table LSP
<R1, 1> → push 23, R2
R7

P2MP Labelwithdraw
<R1, 1, 31>
R4

R8
P2MP Labelwithdraw
<R1, 1, 81>

Figure 7 – Suppression d’une feuille

Une solution pour éviter la perte et la duplication de paquets de routage et suit le plus court chemin IP entre la racine et les
consisterait à effectuer les étapes dans cet ordre : 3, 1, 4, 2, en feuilles. Cette technologie repose sur les trois briques fonction-
accomplissant successivement les étapes 1 et 4 très rapidement. Il nelles MPLS-TE : découverte de la topologie TE (bande passante
ne faut déclencher les étapes 1 et 4 qu’une fois l’activation de la sur les liens...), calcul de chemin et signalisation du chemin. Ces
nouvelle branche de LSP assurée (c’est-à-dire que le message briques sont étendues pour supporter l’établissement d’arbres
P2MP LabelMap a d’ores et déjà atteint un nœud) sinon, il y aura MPLS.
une perte de trafic. Afin d’indiquer à un routeur en aval qu’une P2MP MPLS-TE hérite des propriétés d’ingénierie de trafic et de
branche a bien été activée, le groupe MPLS de l’IETF définit actuel- sécurisation de MPLS-TE. En particulier, la technologie multicast
lement une procédure reposant sur le message de notification MPLS-TE permet :
LDP. Lorsqu’une branche de l’arbre est activée, un message noti-
fiant cette activation se propage dans le sens descendant et – une optimisation de la bande passante multicast : le mode
l’indique aux routeurs en aval (Rd). Ainsi, après l’étape 3, sur explicite permet d’établir des arbres de coût minimal ;
réception du message de notification indiquant que la nouvelle – un contrôle d’admission du trafic multicast : le routage par
branche (passant par Ru2) est active, Rd déclenche les étapes 1 et contrainte et la réservation de ressources permettent de vérifier si
4. Cette procédure permet d’éviter la duplication et la perte de un nouveau groupe multicast peut être transporté ou non dans le
paquets. réseau ;
– une ré-optimisation sans perte de paquet en cas d’ajout/sup-
En cas de reroutage sur panne, le temps de reroutage dépend pression d’éléments (travaux programmés) ;
du temps de reroutage IGP et du nombre de LSP reroutés. On peut – une protection rapide en moins de 50 ms du trafic multicast en
espérer un reroutage en moins d’une seconde avec des implémen- cas de panne de lien ou de nœud (P2MP MPLS Fast Reroute).
tations performantes.
Cette technologie est particulièrement bien adaptée au transport
d’applications multicast haut débit à fortes contraintes de QoS,
3.2 Multicast MPLS-TE particulièrement la télévision ou certains services de conférence
multipoint.
La technologie MPLS Traffic Engineering (MPLS-TE) a été initia- Les travaux sur P2MP MPLS-TE ont démarré il y a 5 ans à l’IETF,
lement conçue pour assurer des fonctions d’ingénierie de trafic et avec comme application motrice la diffusion de la télévision. La
de sécurisation unicast (cf. [17]). Elle repose sur l’établissement de technologie est maintenant relativement mûre avec des spécifica-
LSP MPLS point-à-point routés de façon explicite, dont les chemins tions stables, plusieurs implémentations et plusieurs déploie-
respectent un ensemble de contraintes, comme la bande passante. ments.
La technologie multicast MPLS-TE (ou P2MP MPLS-TE) est une
extension de la technologie MPLS-TE pour l’établissement d’arbres 3.2.1 Opérations multicast MPLS-TE
MPLS routés de façon explicite, appelés « arbres MPLS-TE » (ou
LSP P2MP MPLS-TE). Elle permet l’établissement d’arbres MPLS L’établissement d’un arbre MPLS-TE est initié par la racine.
en mode connecté. Un arbre MPLS-TE suit un chemin explicite qui L’arbre est configuré sur le LSR racine en indiquant l’ensemble des
respecte un ensemble de contraintes comme la bande passante, destinations, un ensemble de contraintes TE comme la bande pas-
contrairement à un arbre LDP qui n’est soumis à aucune contrainte sante et éventuellement un chemin d’arbre explicite.

Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie

est strictement interdite. – © Editions T.I. TE 7 578 – 9

Dossier délivré pour

DOCUMENTATION
21/10/2008
 Dossier délivré pour
DOCUMENTATION
21/10/2008

LE MULTICAST MPLS ________________________________________________________________________________________________________________

Les destinations peuvent être configurées explicitement sur le

routeur de tête, ou découvertes automatiquement par une exten- IGP étendu
sion du protocole BGP (cf. [8] et section 4). 1 OSPF-TE, ISIS-TE

Une fois l’arbre configuré sur le LSR racine et les destinations

connues, un processus de routage P2MP par contrainte s’enclen- 4 3
che afin d’établir l’arbre. Ce processus fait intervenir trois blocs Base de Arbre MPLS avec
2 Calcul de l‘arbre
fonctionnels : données TE contraintes TE

• Le bloc de découverte de la topologie TE. Il permet à chaque

nœud du réseau de découvrir l’ensemble des liens et des
nœuds dans son aire, la bande passante résiduelle dispo- Arbre explicite 5
nible, ainsi que la capacité des nœuds à supporter le P2MP.
Ces données sont stockées dans une base de données appe-
lée « base de données TE ». C’est le bloc déjà utilisé pour
MPLS-TE unicast, assuré par les protocoles ISIS-TE et OSPF- Signalisation
de l‘arbre 6
TE, avec quelques extensions définies pour annoncer les P2MP RSVP-TE
capacités P2MP des nœuds ;
Nota : des extensions IGP sont définies pour annoncer la capacité d’un nœud à sup- Figure 8 – Opérations pour l’établissement d’un arbre P2MP
porter la signalisation P2MP RSVP-TE et à agir comme LSR branche ou LSR bourgeon MPLS-TE
d’un arbre MPLS (cf. [11]).

• Le bloc de calcul de l’arbre. Il assure le calcul d’un d’arbre

contraint en s’appuyant sur la base de données TE et en pre-
nant en compte les contraintes TE de l’arbre (bande pas-
sante...). Le résultat de ce calcul est un arbre explicite 10G 10G
représenté par un ensemble de chemins point-à-point explici-
R6 R3
tes depuis la racine vers chaque feuille. Ce bloc peut calculer
différentes formes d’arbres, par exemple des arbres de plus 10G 10G 1G
court chemin ou des arbres de coût minimal. Cette fonction
10G 10G
de calcul peut être réalisée sur le routeur racine ou sur un
serveur externe ; R1 R2 R4

• Le bloc de signalisation en charge de l’établissement de 10G 10G 1G

l’arbre. Il comprend le routage explicite de l’arbre le long du 10G 10G
chemin déterminé par le bloc de calcul, la réservation de la R7 R5
bande passante sur les liens de l’arbre, ainsi que la distribu-
tion des labels. Ce bloc repose sur le protocole de signalisa-
tion P2MP RSVP-TE défini dans la norme IETF RFC-4875 [7], il
s’agit d’une extension du protocole RSVP-TE RFC-3209 [4]. Il
Figure 9 – Topologie initiale
répond à l’expression de besoin, définie dans la norme IETF
RFC-4461 [1].
La figure 8 illustre les fonctions mises en œuvre sur le routeur
racine pour l’établissement d’un arbre MPLS-TE, lorsque le calcul Configuration de l’arbre Arbre calculé :
de l’arbre est réalisé directement sur le routeur racine. Le proto- Nom : A1 R1-R2-R4
cole de routage IGP étendu (1) distribue les informations de topo- Feuilles : R3, R4, R5 R1-R2-R6-R3
logie TE à tous les routeurs, cela inclut en particulier la bande Bande passante : 2G R1-R2-R7-R5
passante disponible sur les liens ainsi que la capacité à supporter
des arbres MPLS. Les routeurs maintiennent cette information
dans la base de données TE (2). 10G 8G
R6 R3
Pour établir un arbre MPLS, l’opérateur configure l’arbre sur le
routeur racine (3) en indiquant, dans le cas de feuilles statiques, 10G 8G 1G
l’ensemble des destinations, et, dans le cas de feuilles dynami- 8G 8G
ques, un identifiant représentant l’ensemble des destinations.
Dans ce dernier cas, les feuilles sont automatiquement découver- R1 R2 R4
tes via une extension BGP (cf. [8]) permettant à un LSR d’annoncer
10G 8G 1G
à la racine son souhait de rejoindre un arbre. Dans le cas statique,
les feuilles sont fixes et reçoivent un trafic multicast même s’il n’y 10G 8G
a pas de récepteurs pour ce trafic. Dans le cas dynamique, les R7 R5
feuilles sont ajoutées/supprimées dynamiquement lorsqu’un
récepteur apparaît/disparaît pour le trafic multicast transporté dans
l’arbre (cf. section 4). Il indique également un ensemble de para-
mètres TE comme la bande passante ou les liens/nœuds à inclure/ Figure 10 – Établissement de l’arbre MPLS-TE A1
exclure.
Le routeur de tête calcule ensuite un arbre, respectant les
contraintes TE (4). Le résultat de ce calcul est un arbre explicite (5), Les figures 9 et 10 illustrent l’établissement d’un arbre dans le
codé sous la forme d’un ensemble de chemins point-à-point expli- cas où les feuilles sont configurées de façon statique et le calcul de
cites entre la racine et chaque feuille. l’arbre est réalisé par le routeur racine. La figure 9 indique la topo-
logie initiale et les ressources disponibles sur tous les liens
Cet arbre explicite est ensuite transmis au protocole de signali- (1 Gbps et 10 Gbps).
sation P2MP RSVP-TE (6) qui distribue les labels et réserve les res-
sources le long de l’arbre explicite. Nota : Gbps = Giga bit par seconde.

Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie

TE 7 578 – 10 est strictement interdite. – © Editions T.I.

Dossier délivré pour

DOCUMENTATION
21/10/2008
Dossier délivré pour
DOCUMENTATION
21/10/2008

________________________________________________________________________________________________________________ LE MULTICAST MPLS

La figure 10 présente la mise en place, dans cette topologie,

d’un arbre A1 de capacité 2 Gbps entre R1 et les feuilles R3, R4, R5. Arbre S1 → {L1, L2, L3}
L’arbre est configuré par l’opérateur sur le routeur de tête R1 en S1
indiquant son nom, la liste de ses feuilles et sa bande passante. Le
routeur R1 calcule ensuite un arbre explicite en prenant en compte
la bande passante requise (2 Gbps) et la bande passante dispo- SPT MCT
Coût arbre = 7 Coût arbre = 5
nible sur les liens (il exclut donc les liens R3-R4 et R4-R5 qui n’ont Coût chemin = 3 Coût chemin = 4
que 1 Gbps disponible). Les chemins point-à-point de l’arbre cal-
culé sont R1-R2-R4, R1-R2-R6-R3 et R1-R2-R7-R5. R1 lance ensuite
la signalisation P2MP RSVP-TE qui distribue les labels et réserve
les ressources le long des chemins explicites. Une fois l’arbre
établi, la bande passante résiduelle (8 Gbps) est mise à jour sur
tous les liens de l’arbre et annoncée dans l’IGP.
Les sections 3.2.2 et 3.2.3 ci-dessous décrivent plus en détail les
blocs de calcul d’arbre et de signalisation d’arbre.

3.2.2 Calcul de l’arbre

Dans MPLS-TE, un chemin point-à-point explicite correspond à L1 L2 L3
la suite d’adresses d’interface le long du chemin. Dans P2MP
MPLS-TE, un arbre explicite est la combinaison d’un ensemble de Figure 11 – Arbres SPT et MCT
chemins point-à-point explicites entre la racine de l’arbre et
l’ensemble des feuilles.
De façon similaire à l’unicast, le calcul d’un arbre MPLS-TE peut Le principe de l’heuristique de Takahashi consiste à ajouter les
être réalisé en mode offline soit manuellement, soit via un gestion- feuilles les unes après les autres. Pour ajouter une nouvelle feuille
naire centralisé, auquel cas l’arbre explicite est configuré sur le F, on recherche le nœud N, déjà dans l’arbre, le plus proche de la
LSR racine. Le calcul peut aussi être réalisé en mode online direc- feuille F et on raccorde F à N en utilisant le plus court chemin.
tement par le LSR racine ou par un élément de calcul appelé
L’heuristique de Takahashi peut être décrite de la façon
« PCE » (Path Computation Element ) interrogé par le LSR racine
suivante :
(cf. projet de norme IETF PCE-P2MP [12]).
Le multicast MPLS-TE, par ses propriétés de routage explicite, – initialement, l’ensemble des nœuds de l’arbre, noté {NA},
supporte toutes les formes d’arbres possibles. Il existe deux contient uniquement la racine ;
formes d’arbres caractéristiques : les arbres de plus court chemin, – l’ensemble des chemins de l’arbre, noté {CA}, est initialement
dits « SPT » (Shortest Path Tree ) qui limitent la distance entre la vide ;
racine et chaque feuille, et les arbres de coût minimal, appelés – pour ajouter la première feuille F1, on calcule le plus court
« MCT » (Minimum Cost Tree ), qui limitent le nombre d’arêtes tra- chemin C entre F1 et la racine, en utilisant par exemple l’algo-
versées par l’arbre et réduisent ainsi la consommation de bande rithme de Dijkstra, et on ajoute C à {CA} et l’ensemble des nœuds
passante. de C à {NA} ;
Le protocole IP multicast PIM et le protocole MLDP établissent – pour ajouter la feuille Fn, on calcule le plus court chemin au
uniquement des arbres de plus courts chemins, ils ne peuvent éta- départ de Fn, afin de déterminer le nœud N de {NA} le plus proche
blir des arbres de coût minimal et ne permettent donc pas de mini- de Fn, en utilisant par exemple l’algorithme de Dijkstra. Le plus
miser la consommation de bande passante. court chemin Cn entre Fn et N, est ajouté à {CA} et ses nœuds sont
La figure 11 compare un arbre SPT et un arbre MCT, établis ajouter à {NA}. Cette étape se répète jusqu’à ce que toutes les
entre la racine S1 et les feuilles L1, L2 et L3. Toutes les métriques feuilles soient ajoutées.
des liens sont ici à 1. L’arbre SPT emprunte les plus courts che- Cette heuristique nécessite de lancer k fois l’algorithme SPT de
mins entre S1 et L1, L2, L3. Cet arbre emprunte 7 arêtes avec une Dijkstra pour calculer un arbre de k feuilles, il a donc une
distance maximale de 3 bonds entre la source et les feuilles. complexité en k · n · lg(n ) où n est le nombre de nœuds du réseau.
L’arbre MCT, quant à lui, emprunte seulement 5 arêtes, il minimise Elle est particulièrement bien adaptée à l’ajout/suppression dyna-
le nombre d’arêtes consommées ; en revanche, la distance maxi- mique de feuilles. En effet, l’ajout d’une feuille n’impacte pas les
male entre la source et les feuilles augmente d’un bond. L’arbre autres chemins de l’arbre et ne nécessite de lancer qu’un seul SPT,
MCT permet ici une réduction de 30 % de la bande passante avec une complexité en n · l g(n ). On peut montrer que l’heuristique
consommée. De manière générale, on observe une réduction permet une bonne approximation d’un arbre MCT, avec un rapport
significative dans les topologies bien maillées et une réduction maximal de coût de 2 · (1 – 1/k ) par rapport à l’optimum, où k est le
plus faible, voire nulle, dans les topologies faiblement maillées nombre de feuilles de l’arbre.
comme les étoiles ou les anneaux.
La recherche d’un arbre SPT est un problème dit « P » (on peut La figure 12 illustre le déroulement de l’heuristique de Taka-
résoudre le problème en un temps polynomial). Il existe de nom- hashi pour l’établissement d’un arbre MPLS-TE entre la racine S1
breux algorithmes, le plus connu étant l’algorithme de Dijkstra et les feuilles L1, L2 et L3. La feuille L1 est ajoutée en premier, elle
avec une complexité en n·lg(n ) où n est le nombre de nœuds. emprunte le plus court chemin vers la racine S1-R1-R2-L1. La
C’est algorithme implémenté aujourd’hui dans les routeurs pour le feuille L2 est ensuite rattachée au nœud le plus proche déjà dans
calcul d’arbres MPLS-TE. l’arbre, il s’agit du nœud L1 : le chemin pour L2 est donc S1-R1-R2-
L1-L2. Enfin, L3 est rattaché au nœud le plus proche déjà dans
Le problème de la recherche d’un arbre MCT, plus connu sous le
l’arbre, à savoir le nœud L2, et le chemin pour L3 est donc S1-R1-
nom de « problème de Steiner », est un problème NP-
R2-L1-L2-L3. On aboutit à un arbre de coût minimal (coût 5).
complet [14] : on ne peut trouver une solution en un temps polyno-
mial, en revanche on peut « vérifier » une solution du problème en Il est à noter que, dans l’heuristique de Takahashi, l’ordre d’arri-
un temps polynomial. Il existe cependant des heuristiques permet- vée des feuilles a un impact sur la forme de l’arbre et donc sur son
tant d’approcher la solution en un temps polynomial. L’heuristique coût. Il existe plusieurs approches pour déterminer un « bon
dite « de Takahashi » [15] est bien adaptée au cas P2MP MPLS-TE, ordre » d’arrivée. Une approche consiste à lancer un calcul SPT
car l’ajout d’une feuille ne nécessite pas le recalcule de tout l’arbre. depuis la racine pour connaître les distances entre la racine et les

Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie

est strictement interdite. – © Editions T.I. TE 7 578 – 11

Dossier délivré pour

DOCUMENTATION
21/10/2008
 Dossier délivré pour
DOCUMENTATION
21/10/2008

LE MULTICAST MPLS ________________________________________________________________________________________________________________

Arbre S1 → {L1, L2, L3}

S1

R1

R2 R3 R4

L1 L2 L3

1 : Ajout L1 2 : Ajout L2 3 : Ajout L3

SPF to S1 SPF SPF
{A} = {S1, R1, R2, L1} Nœud le plus proche = L1 Nœud le plus proche = L2
Chemins :
{A} = {S1, R1, R2, L1, L2} {A} = {S1, R1, R2, L1, L2, L3}
S1-R1-R2-L1
Chemins : Chemins :
S1-R1-R2-L1 S1-R1-R2-L1
S1-R1-R2-L1-L2 S1-R1-R2-L1-L2
S1-R1-R2-L1-L2-L3

Figure 12 – Calcul d’un arbre MPLS-TE avec l’heuristique de Takahashi

Le message RSVP Path contient l’identifiant de LSP, l’ensemble

Gain en bande passante MCT/SPT des paramètres TE (bande passante...) et la route explicite ; il tran-
18
Gain (%)

site de proche en proche de la source vers la destination, le long

16 de la route explicite. Il ouvre la session RSVP sur tous les routeurs
14 du chemin.
12 Le message RSVP Resv contient l’identifiant de LSP, l’ensemble
des paramètres TE, ainsi que le label alloué par un LSR en aval sur
10
un lien. Il transite de la destination vers la source en empruntant le
8 chemin inverse du message Path. Le message Resv réserve la
6 bande passante et distribue les labels le long du chemin. Le LSP
est établi lorsque le message Resv a atteint la source. Pour plus
4 d’informations sur RSVP-TE, le lecteur est invité à se référer à
2 l’article [TE 7 577] des Techniques de l’Ingénieur (référence
0 bibliographique [17]).
0 5 10 15 20 25 30 35 40 45 Dans RSVP, un message Path/Resv entraîne l’établissement d’un
Nombre de feuilles état RSVP. Cet état est rafraîchi par une émission périodique des
messages Path/Resv. Il peut être modifié par renvoi du message
Figure 13 – Gain MCT en fonction du nombre de feuilles Path/Resv avec des paramètres différents.
Le protocole P2MP RSVP-TE défini dans la norme IETF (RFC-
feuilles, puis à ajouter les feuilles dans l’ordre croissant de leur 4875 [7]) est une extension de RSVP-TE permettant d’établir des
distance à la racine. LSP P2MP. P2MP RSVP-TE étant construit sur RSVP-TE, il réutilise
au maximum les procédures et éléments d’information de ce pro-
Il est important de noter que le gain en bande passante d’un
tocole.
arbre MCT par rapport à un arbre SPT tend à diminuer lorsque le
nombre de feuilles augmente. La figure 13 présente les résultats Un LSP P2MP RSVP-TE (ou LSP P2MP MPLS-TE ou encore arbre
d’une simulation effectuée sur un réseau de 100 nœuds, dont 20 MPLS-TE) est la combinaison d’un ensemble de sous LSP point-à-
nœuds de cœurs et 80 nœuds d’accès, en faisant l’hypothèse que point entre la racine et chaque feuille, appelés « S2L sub-LSP »
chaque nœud d’accès est racine d’un LSP P2MP. Les courbes (Source to Leaf sub-LSP ), qui sont associés sur les LSR branches
donnent le gain en bande passante d’un arbre MCT par rapport à pour former un LSP P2MP. Il existe deux modes pour signaler un
un arbre SPT. LSP P2MP : le mode agrégé et le mode désagrégé.
On observe que la gain augmente jusqu’à 17 % pour 10 feuilles • Dans le mode agrégé, un seul message Path est émis pour
puis redescend à 10 % pour 40 feuilles. signaler le LSP P2MP vers un voisin en aval. Ce message Path
contient l’ensemble des sub-LSP point-à-point vers l’ensemble des
feuilles en aval. Dans ce mode, un seul état RSVP est instancié sur
3.2.3 Signalisation de l’arbre : un nœud pour maintenir le LSP P2MP.
protocole P2MP RSVP-TE
• Dans le mode désagrégé, un message Path distinct est envoyé
Le protocole RSVP-TE défini dans la norme IETF RFC-3209 [4] vers chaque feuille du LSP P2MP. Ces messages Path contiennent
permet l’établissement de LSP point-à-point. Il repose sur deux un unique sub-LSP. Ils transportent le même identifiant de LSP
principaux messages : le message Path et le message Resv. P2MP et se distinguent par un identifiant appelé « sub-group id ».

Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie

TE 7 578 – 12 est strictement interdite. – © Editions T.I.

Dossier délivré pour

DOCUMENTATION
21/10/2008
Dossier délivré pour
DOCUMENTATION
21/10/2008

________________________________________________________________________________________________________________ LE MULTICAST MPLS

Cela conduit à utiliser autant d’états RSVP qu’il y a de feuilles en Resv pour n’en transmettre qu’un seul en amont, et ainsi de suite
aval pour maintenir le LSP P2MP sur un nœud. Dans ce mode, tout jusqu’à ce que le Resv atteigne la racine.
se passe dans le plan de commande comme si l’on avait n LSP
Nota : dans le cas où la racine est également nœud branche (si elle a plusieurs voisins
point-à-point, et ces LSP point-à-point sont combinés dans le plan en aval) elle envoie un message Path par voisin en aval, incluant tous les sub-LSP dont la
de transfert pour former un LSP P2MP. destination se situe en aval.

3.2.3.1 Architecture P2MP RSVP-TE 3.2.3.2.1 Procédure sur le nœud racine

Le protocole RSVP-TE distingue la notion de tunnel et de LSP. Une fois les chemins point-à-point explicites du LSP P2MP calcu-
Un tunnel est l’entité configurée par l’opérateur sur le routeur de lés, le nœud racine envoie un message P2MP RSVP Path à son (ou
tête, il est reconnu grâce à un identifiant appelé « tunnel-id » qui ses) voisin(s) en aval, incluant l’ensemble des sub-LSP point-à-
ne change pas pendant la vie du tunnel. La combinaison du point (adresse de la feuille et chemin explicite point-à-point) vers
tunnel-id et de l’adresse de la racine permettent une identification des feuilles en aval. Sur réception d’un message Resv avec les
unique du tunnel. Un tunnel est la combinaison de un ou plusieurs labels L1 à Ln de ses voisins V1 à Vn en aval, pour le LSP P2MP A,
LSP qui peuvent changer pendant la vie du tunnel. Un LSP corres- le nœud racine considère le LSP actif, et l’ajoute dans sa table des
pond à un chemin MPLS, il est déterminé par un identifiant appelé LSP :
« LSP-id ». À chaque changement de chemin d’un tunnel dû a une
restauration ou une réoptimisation, un nouveau LSP est créé avec
un nouveau LSP-id, en revanche, le tunnel-id ne change pas. A -> Push L1, V1
…
Le protocole P2MP RSVP-TE conserve les notions de tunnel et Push Ln, Vn
de LSP. Un tunnel P2MP RSVP-TE est identifié par un identifiant
appelé « P2MP-id » qui ne change pas pendant la vie du tunnel. Il
est la combinaison d’un ou plusieurs LSP P2MP RSVP-TE. Un LSP 3.2.3.2.2 Procédure sur un nœud transit
P2MP RSVP-TE est identifié par un « LSP-id ». À chaque change- Sur réception d’un message Path, un nœud détecte qu’il est
ment de chemin d’un tunnel P2MP RSVP-TE un nouveau LSP transit s’il n’est pas la destination d’au moins un sub-LSP. Il vérifie
P2MP-TE est créé avec un nouveau LSP-id. Un LSP P2MP RSVP-TE tout d’abord la première adresse de tous les ERO : celle-ci doit être
est la combinaison d’un ensemble de sous LSP point-à-point, les l’une de ses adresses ; si ce n’est pas le cas, il renvoie un message
S2L sub-LSP, entre la racine et chaque feuille. Un S2L sub-LSP est d’erreur PathErr et stoppe l’établissement du LSP. Il supprime
identifié par l’adresse IP de la feuille qu’il rejoint. ensuite cette première adresse de tous les ERO et analyse à
Dans le mode de signalisation désagrégé, les messages Path uti- nouveau la première adresse (c’est-à-dire la deuxième adresse
lisés pour établir le LSP P2MP transportent le même identifiant de dans l’ERO initialement reçu) pour déterminer le ou les voisins en
tunnel et le même identifiant de LSP. Ils se distinguent par un aval. S’il existe un seul voisin en aval, cela signifie que le nœud
identifiant appelé « sub-group id ». n’est pas un LSR branche, il transmet le message Path à ce voisin
avec les ERO mis à jour. S’il existe au moins deux voisins en aval
On a donc cinq identifiants fondamentaux dans le protocole
alors le nœud est un LSR branche. Il envoie à chaque voisin en
P2MP RSVP-TE :
aval un message Path incluant les sub-LSP dont les feuilles sont en
– l’adresse de la racine ; aval de ce voisin. Sur réception d’un message Resv avec le label L1
– l’identifiant de tunnel P2MP : P2MP-id ; à Ln de ses voisins V1 à Vn, un nœud de transit alloue un label L
– l’identifiant de LSP P2MP : LSP-id ; en amont pour le LSP et envoie un message Resv avec le label L
– l’identifiant de sub-LSP, à savoir l’adresse d’une feuille ; vers son voisin en amont. Il ajoute l’entrée suivante dans sa table
– l’identifiant de message Path : sub-group id, utilisé pour distin- de routage MPLS :
guer deux messages Path pour un même LSP P2MP.
La combinaison de l’adresse de la racine et du P2MP-id permet L -> Swap L1, V1
d’identifier de manière unique un tunnel P2MP RSVP-TE. La
…
combinaison de l’adresse de la racine, du P2MP-id et du LSP-id
permet d’identifier de manière unique un LSP P2MP RSVP-TE. La Swap Ln, Vn
combinaison de l’adresse de la racine, du P2MP-id, du LSP-id et de
l’adresse de la feuille permet d’identifier de manière unique un Si le nœud est également feuille, donc s’il est destination d’un
sub-LSP. La combinaison de l’adresse de la racine, du P2MP-id, du sub-LSP, il doit également ajouter une opération pop pour le label
LSP-id et du sub-group id permet d’identifier de manière unique L et réaiguiller le trafic vers la table du domaine de routage client
un message Path. Un état RSVP P2MP est identifié par cette même du tunnel.
combinaison. Deux états ayant les mêmes adresses de racine,
P2MP-id, LSP-id mais des sub-group id différents correspondent à 3.2.3.2.3 Procédure sur un nœud feuille
un même LSP P2MP.
Sur réception d’un message Path, un nœud détecte qu’il est
Dans le cas agrégé, un LSP P2MP est supporté par un seul état feuille si l’unique sub-LSP dans le message Path lui est destiné. Il
RSVP P2MP, instancié par un seul message Path. attribue le label L pour le lien en amont et met à jour sa table
Dans le cas désagrégé, un LSP P2MP est supporté par un MPLS afin d’aiguiller le trafic vers la table du domaine de routage
ensemble d’états RSVP, un par feuille en aval, instanciés par un client du tunnel.
ensemble de message Path. La combinaison de ces états permet le
maintien du LSP P2MP. Le même label sera alloué dans tous les 3.2.3.2.4 Illustration
messages Resv d’un même LSP P2MP envoyés sur un lien donné. Les figures 14 et 15 montrent l’établissement d’un LSP P2MP
RSVP-TE en mode agrégé. Ce LSP a pour racine R1, pour feuilles
3.2.3.2 Établissement d’un LSP P2MP en mode agrégé R5, R6 et R8 et emprunte les chemins R2-R3-R5, R2-R3-R6 et R2-R4-
En mode agrégé, un seul message Path, incluant tous les sub- R8. Ce LSP est identifié par la combinaison de la racine R1 et du
LSP, est envoyé par la racine. Ce message Path est répliqué sur les P2MP-id 1, <R1, 1>.
LSR branches qui transfèrent ce même message à chaque nœud La figure 14 illustre la propagation du message Path le long de
fils, avec les sub-LSP correspondant aux feuilles atteignables par l’arbre de la racine vers les feuilles. La racine R1 envoie à R2 un
ce nœud fils. Sur réception de ce message Path, les feuilles ren- message Path incluant les 3 sub-LSP et leur ERO. Sur réception de
voient un message Resv. Les LSR branches agrègent ces messages ce message, R2 détecte qu’il est LSR branche et qu’il a deux

Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie

est strictement interdite. – © Editions T.I. TE 7 578 – 13

Dossier délivré pour

DOCUMENTATION
21/10/2008
 Dossier délivré pour
DOCUMENTATION
21/10/2008

LE MULTICAST MPLS ________________________________________________________________________________________________________________

Path P2MP <R1,1>

Sub-group 1
ERO : R5 R5
sub-LSP to R5
Path P2MP <R1,1>
Sub-group 1
ERO : R2-R3-R5 Path P2MP <R1,1> R3
sub-LSP to R5 Sub-group 1
ERO : R2-R3-R6 ERO : R3-R5
Sub-LSP to R6 sub-LSP to R5
ERO : R2-R4-R8 ERO : R3-R6
Sub-LSP to R8 sub-LSP to R6
Path P2MP <R1,1>
R6
Sub-group 1
ERO : R6
LSR Racine sub-LSP to R6
R1 R2

Config LSP P2MP sur R1

Destinations : R5, R6, R8
Bandwidth : 100M R7
Path : CSPF

Chemins calculés Path P2MP <R1,1>

R2-R3-R5 Sub-group 1
R2-R3-R6 ERO : R4-R8 R4
R2-R4-R8 sub-LSP to R8

Path P2MP <R1,1>

R8
Sub-group 1
ERO : R8
sub-LSP to R8

Figure 14 – Établissement d’un LSP P2MP RSVP-TE en mode agrégé : message Path

Resv P2MP <R1,1>

Sub-group 1
Label 32 R5
sub-LSP to R5
Resv P2MP <R1,1>
Sub-group 1
Label 16 Resv P2MP <R1,1> R3
sub-LSP to R5 Sub-group 1
sub-LSP to R6 Label 18
sub-LSP to R8 sub-LSP to R5
sub-LSP to R6
Resv P2MP <R1,1>
R6
Sub-group 1
Label 23
LSR Racine sub-LSP to R6
R1 R2

Config LSP P2MP sur R1

Destinations : R5, R6, R8
Bandwidth : 100M R7
Path : CSPF

Chemins calculés Resv P2MP <R1,1>

R2-R3-R5 Sub-group 1
R2-R3-R6 Label 20 R4
R2-R4-R8 sub-LSP to R8

Resv P2MP <R1,1>

R8
Sub-group 1
Label 28
sub-LSP to R8

Figure 15 – Établissement d’un LSP P2MP RSVP-TE en mode agrégé : message Resv

Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie

TE 7 578 – 14 est strictement interdite. – © Editions T.I.

Dossier délivré pour

DOCUMENTATION
21/10/2008
Dossier délivré pour
DOCUMENTATION
21/10/2008

________________________________________________________________________________________________________________ LE MULTICAST MPLS

Table MPLS
32 → pop, domaine client
Table MPLS
18 → swap 32, R5 R5
swap 23, R6

R3

R6

LSR Racine Table MPLS

R1 R2 23 → pop, domaine client
Table de LSP Table MPLS
LSP <R1, 1> → push 16, R2 16 → swap 18, R3
swap 20, R4 R7

R4

Table MPLS
20 → swap 28, R8 R8
Table MPLS
28 → pop, domaine client

Figure 16 – Contenu des tables MPLS

voisins en aval, R3 et R4, il envoie un message Path à R3 avec les l’arbre de 16 à 11 nœuds ce qui constitue un gain de 30 %. Ce gain
sub-LSP vers R5 et R6 et un message Path à R4 avec le sub-LSP augmente avec le nombre de feuilles.
vers R8. La procédure se répète jusqu’à ce que les messages Path La figure 18 présente des résultats de simulation effectués sur
atteignent les feuilles. un réseau de 100 nœuds, dont 20 nœuds de cœur et 80 nœuds
La figure 15 décrit la propagation du message Resv sur le d’accès, en faisant l’hypothèse que chaque nœud d’accès est
chemin inverse depuis les feuilles vers la racine. R5 alloue le label racine d’un LSP P2MP RSVP-TE. Les courbes donnent la quantité
32 pour le lien en amont, envoie un message Resv avec le label 32 d’information totale en nombre d’adresses IP à maintenir sur un
et installe, dans sa table MPLS (cf. figure 16), l’opération : routeur de cœur, en fonction du nombre de feuilles des arbres
32 -> pop, routage domaine client générés par chaque routeur d’accès. On voit que, pour des arbres
Sur réception des deux messages Resv en provenance de R5 et de 40 feuilles, on réduit de 60 % la quantité d’information et donc
R6 avec les labels 32 et 23, le routeur R3 attribue le label 18 pour le la consommation mémoire sur les routeurs de cœur, ce qui est
routeur en amont et envoie un message Resv avec le label 18 vers non négligeable.
R2. Il met à jour sa table MPLS en ajoutant le label 18 et les sorties Cette compression diminue la consommation mémoire mais elle
associées vers R5, avec le label 32, et R6, avec le label 23. Sur implique plus d’opérations sur la réception du message Path. La
réception du message Resv de R2 avec le label 16, le routeur détermination des sub-LSP accessibles via un voisin en aval néces-
racine R1 met à jour sa table de LSP et installe l’opération site un parcours en profondeur des ERO.

3.2.3.3 Établissement d’un LSP P2MP en mode désagrégé

P2MP LSP <R1, 1> -> Push 16, R2 En mode désagrégé un message Path est généré par le routeur
racine pour chaque sub-LSP vers chaque feuille. Ces messages ont
tous le même P2MP-id, le même LSP-id ; ils se distinguent par le
3.2.3.2.5 Compression des chemins sub-group id. Le nombre d’états RSVP pour maintenir un arbre sur
Dans le message Path émis par R1 (cf. figure 14), les chemins de un nœud de transit est égal au nombre de feuilles en aval de ce
chaque sub-LSP sont listés de bout en bout depuis la racine nœud.
jusqu’à la destination. Il en résulte une répétition des informations Les messages Path P2MP RSVP-TE sont traités ici comme des
et cela augmente de façon inutile la taille des messages Path. Il est messages Path RSVP-TE point-à-point traditionnels. De même, les
possible de compresser les chemins des sub-LSP de façon à ne messages Resv P2MP RSVP-TE sont traités comme des messages
pas répéter l’information : au lieu de spécifier les chemins de sub- Resv RSVP-TE point-à-point traditionnels. Tout se passe comme si
LSP de bout en bout, on les spécifie entre un LSR branche et la l’on établissait un ensemble de LSP RSVP-TE point-à-point entre la
destination. racine et les feuilles, sur les chemins explicites point-à-point entre
La figure 17 représente un ensemble d’ERO non compressés et la racine et les feuilles. La principale spécificité P2MP repose sur
compressés pour un arbre, entre la racine R0 et les feuilles R5, R6, l’allocation de labels. Un même label sur un lien est alloué dans
R7 et R8. La compression permet ici de raccourcir la taille de tous les messages Resv ayant le même P2MP-id et le même LSP-id

Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie

est strictement interdite. – © Editions T.I. TE 7 578 – 15

Dossier délivré pour

DOCUMENTATION
21/10/2008
 Dossier délivré pour
DOCUMENTATION
21/10/2008

LE MULTICAST MPLS ________________________________________________________________________________________________________________

R5

R3

R6

R0 R1 R2

ERO non compressés

R1-R2-R3-R5
R1-R2-R3-R6 R7
R1-R2-R4-R7
R1-R2-R4-R8

ERO compressés
R1-R2-R3-R5 R4
R3-R6
R2-R4-R7
R4-R8
R8

Figure 17 – Compression d’ERO

3.2.3.4 Comparaison des modes agrégés et désagrégés

7 000 Le mode agrégé nécessite un seul état par LSP P2MP tandis que
Quantité d'information à maintenir

le mode désagrégé génère un état par feuille de LSP P2MP. Le

6 000 mode agrégé nécessite donc moins de traitement que le mode
désagrégé. On pourra noter tout de même que le coût de traite-
5 000 ment des états du mode désagrégé peut être réduit de façon signi-
ficative en activant la réduction des rafraîchissements d’état RSVP
4 000 Sans compression
définie dans la norme IETF RFC-2961 [3].
3 000 Bien que la taille d’un état agrégé dépende du nombre de
feuilles, la quantité d’informations à maintenir reste inférieure au
2 000 mode désagrégé, en particulier lorsque la compression des états
est activée (cf. figure 18). Le mode agrégé passe donc globale-
1 000 Avec compression
ment mieux à l’échelle que le mode désagrégé. Le nombre de sub-
0
LSP que l’on peut agréger dans un même message Path reste
0 5 10 15 20 25 30 35 40 45 limité par la taille maximale d’un message RSVP Path, elle-même
bornée par la taille maximale d’un paquet IPv4 (64 ko). Au-delà
Nombre de feuilles
d’un certain nombre de feuilles (quelques milliers), il faut nécessai-
rement désagréger en plusieurs messages Path.
Figure 18 – Performances de la compression des ERO Le mode agrégé implique des extensions significatives de la
machine d’état RSVP-TE. En revanche, le mode désagrégé repose
essentiellement sur la machine d’état RSVP-TE point-à-point.
(c’est-à-dire tous les messages Resv correspondant au même LSP
L’adaptation d’une implémentation RSVP-TE P2P pour le support
P2MP).
du P2MP désagrégé nécessite donc beaucoup moins de ligne de
Les figures 19 et 20 montrent l’établissement d’un LSP P2MP codes qu’une adaptation pour le support du P2MP agrégé. Les ris-
RSVP-TE entre le LSR racine R1 et les LSR feuilles R5, R6 et R8, en ques de problèmes d’interopérabilités sont donc réduits avec le
mode totalement désagrégé. Les tables de commutation résultan- mode désagrégé. De plus, les opérations de « management » et de
tes sont celles présentées à la figure 14. « troubleshooting » RSVP-TE P2MP désagrégé sont similaires aux
La racine R1 génère trois messages Path, avec les mêmes LSP-id opérations RSVP-TE P2P.
et P2MP-id mais des sub-group id distincts, contenant chacun un Si l’approche désagrégée passe moins bien à l’échelle que
sub-LSP point-à-point vers une feuille. Ces messages Path se l’approche agrégée, elle reste néanmoins une approche plus prag-
propagent, comme des messages Path traditionnels, jusqu’aux matique, à la fois pour les vendeurs de routeurs qui n’ont pas à
feuilles (cf. figure 19). Les feuilles répondent par des messages modifier lourdement leur code et pour les opérateurs qui peuvent
Resv qui se propagent sur les chemins inverses vers la racine. Sur disposer plus vite d’une implémentation interopérable et facile à
réception des messages Resv de R5 et R6 avec les labels 32 et 23, réaliser. De plus, la taille des instances d’arbre à court terme ne
R3 détecte qu’il s’agit de messages Resv pour un même LSP P2MP devrait pas dépasser quelques centaines de feuilles ce qui ne pose
(P2MP-id et LSP-id étant les mêmes), il alloue un unique label 18 pas de problèmes en termes de nombre d’états. L’industrie implé-
qu’il transmet à R2 dans deux messages Resv. mente donc uniquement le mode désagrégé à l’heure actuelle.

Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie

TE 7 578 – 16 est strictement interdite. – © Editions T.I.

Dossier délivré pour

DOCUMENTATION
21/10/2008
Dossier délivré pour
DOCUMENTATION
21/10/2008

________________________________________________________________________________________________________________ LE MULTICAST MPLS

Path P2MP <R1,1>

Sub-group 1 Path P2MP <R1,1>
ERO : R2-R3-R5 Sub-group 1
sub-LSP to R5 Path P2MP <R1,1> ERO : R5 R5
Sub-group 1 sub-LSP to R5
ERO : R3-R5
Path P2MP <R1,1> sub-LSP to R5
Sub-group 2
ERO : R2-R3-R6 R3
sub-LSP to R6 Path P2MP <R1,1>
Sub-group 2
ERO : R3-R6
Path P2MP <R1,1> sub-LSP to R6
Sub-group 3 R6
ERO : R2-R4-R8 Path P2MP <R1,1>
sub-LSP to R8 Sub-group 2
ERO : R6
LSR Racine sub-LSP to R6
R1 R2

LSP Config on R1
Destinations: R5, R6, R8
Bande passante: 100M R7
Computed Tree
R2-R3-R5
R2-R3-R6
R2-R4-R8 Path P2MP <R1,1> R4
Sub-group 3
ERO : R4-R8
sub-LSP to R8

R8
Path P2MP <R1,1>
Sub-group 3
ERO : R8
sub-LSP to R8

Figure 19 – Établissement d’un LSP P2MP RSVP-TE en mode désagrégé : message Path

Resv P2MP <R1,1>

Sub-group 1 Resv P2MP <R1,1>
sub-LSP to R5 Sub-group 1
Label 16 Resv P2MP <R1,1> sub-LSP to R5 R5
Sub-group 1 Label 32
sub-LSP to R5
Resv P2MP <R1,1> Label 18
Sub-group 2
sub-LSP to R6 R3
Label 16 Resv P2MP <R1,1>
Sub-group 2
sub-LSP to R6
Resv P2MP <R1,1> Label 18
Sub-group 3 R6
sub-LSP to R8 Resv P2MP <R1,1>
Label 16 Sub-group 2
sub-LSP to R6
LSR Racine Label 23
R1 R2

R7

Resv P2MP <R1,1> R4

Sub-group 3
sub-LSP to R8
Label 20

R8
Resv P2MP <R1,1>
Sub-group 3
sub-LSP to R8
Label 28

Figure 20 – Établissement d’un LSP P2MP RSVP-TE en mode désagrégé : message Resv

Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie

est strictement interdite. – © Editions T.I. TE 7 578 – 17

Dossier délivré pour

DOCUMENTATION
21/10/2008
 Dossier délivré pour
DOCUMENTATION
21/10/2008

LE MULTICAST MPLS ________________________________________________________________________________________________________________

Une évolution vers le mode agrégé pourra être envisagée à moyen mécanisme repose sur des LSP de secours locaux, établis à
terme, quand la taille des arbres augmentera et que le nombre l’avance et contournant l’élément protégé. En cas de panne, le
maximal d’états supportés par les routeurs sera atteint. nœud directement en amont, appelé PLR (Point of Local Repair ),
reroute le trafic dans le LSP de secours. Il existe deux modes pour
l’établissement des LSP de secours : le mode detour dans lequel il
3.2.4 Ajout/suppression y a un LSP de secours, appelé « LSP detour », par LSP primaire à
de feuilles P2MP MPLS-TE protéger, et le mode bypass dans lequel un même LSP de secours,
Un ajout/suppression de feuille est initié par la racine de l’arbre. appelé « LSP bypass » peut protéger n LSP primaires, les LSP pri-
L’ajout/suppression d’une feuille peut être déclenché de manière maires étant encapsulés dans le LSP bypass pendant la panne. Le
statique, par configuration sur le routeur racine, ou de manière mode bypass est le mode le plus repandu aujourd’hui.
automatique, via une extension du protocole de routage BGP
Les mécanismes de Fast Reroute MPLS-TE ont été étendus pour
permettant à la racine de découvrir une nouvelle feuille (cf. [9]).
supporter la protection des LSP P2MP MPLS-TE. Des extensions
Par exemple, dans le cas de l’utilisation d’un arbre P2MP RSVP-TE
des mécanismes de Fast Reroute detour et bypass sont définies
pour le transport de trafic IP multicast, il peut être intéressant
dans la norme IETF RFC-4875 [7]. Seule l’extension du mode
d’ajouter dynamiquement une feuille F à un arbre A lorsqu’un
bypass pour la protection des LSP P2MP sera décrite ici, car c’est
récepteur derrière F s’abonne à un groupe IP multicast diffusé par
la seule extension implémentée à l’heure actuelle.
A (cf. section 4).
■ Ajout de feuille. Lorsqu’un routeur racine a détecté, statique-
ment ou dynamiquement une feuille à ajouter, il joint cette feuille 3.2.8 Protection de lien P2MP MPLS-TE
à l’arbre en utilisant l’une des deux procédures suivantes :
• Mode agrégé : il ajoute le nouveau sub-LSP à un état RSVP Pour protéger un lien d’un LSP P2MP MPLS-TE, un LSP bypass
existant et renvoie le message Path existant auquel il a ajouté point-à-point contournant le lien protégé est établi à l’avance. Tout
le sub-LSP. se passe comme pour la protection point-à-point : en cas de panne
de lien le PLR reroute le trafic du LSP P2MP primaire dans le LSP
• Mode désagrégé : il crée un nouvel état RSVP (nouveau sub- P2P bypass vers le nœud en aval, appelé « MP » (Merge Point ), où
group id) et envoie un nouveau message Path incluant uni- il rejoint le LSP P2MP primaire. On utilise pour cela une double
quement le nouveau sub-LSP. encapsulation MPLS. Un même LSP P2P bypass peut être utilisé
■ Suppression de feuille. Lorsqu’un routeur racine a détecté, stati- pour protéger plusieurs LSP P2MP primaires.
quement ou dynamiquement, une feuille à supprimer, il exclut
cette feuille de l’arbre en utilisant l’une des deux procédures Nota : la tête du LSP bypass est appelée Point of Local Repair (PLR) et la destination
Merge Point (MP).
suivantes :
• Mode implicite : si le sub-LSP correspondant est signalé dans Les figures 21 et 22 illustrent la protection de lien d’un LSP
un message qui en comprend au moins deux, il supprime ce P2MP. Le LSP P2MP primaire est protégé contre la panne du lien
sub-LSP et renvoie le message. R1-R2 par un LSP P2P bypass R1-R3-R2 qui évite le lien R1-R2.
• Mode explicite : si le sub-LSP correspondant est signalé dans Dans la table de commutation MPLS de R1, il y a deux sorties pour
un message Path comprenant uniquement ce sub-LSP, il le label du LSP P2MP primaire : une sortie primaire par R2 et une
envoie un message PathTear qui détruit l’état RSVP corres- sortie de secours par le LSP bypass. En cas de panne de lien R1-R2
pondant. (figure 22), le PLR R1 détecte la panne et met à jour sa table de
commutation MPLS en activant la sortie de secours. Le trafic du
LSP primaire est encapsulé dans le LSP bypass. On a deux niveaux
3.2.5 Réoptimisation P2MP MPLS-TE de label : le label externe (30) est le label du LSP bypass, le label
Il est possible de réoptimiser partiellement ou globalement le interne (40) est le label du LSP primaire sur R2. L’avant-dernier
chemin d’un tunnel P2MP RSVP-TE. Cela peut être utile lorsqu’un routeur du LSP bypass, R3, supprime le label externe (Penultimate
meilleur chemin est disponible ou lorsqu’un élément sur le chemin Hop Popping ) et le paquet arrive sur R2 avec le label 40 corres-
(lien ou nœud) va être supprimé ou momentanément désactivé pondant au LSP primaire, il continue donc son chemin sur le LSP
(travaux programmés). Cette réoptimisation se fait sans impact sur primaire.
le trafic : un nouveau LSP P2MP RSVP-TE (avec le même P2MP-id
mais un LSP-id différent) est établi sur le nouveau chemin, le trafic Le temps de Fast Reroute global est la somme du temps de
est basculé sur ce nouveau LSP et l’ancien LSP, situé sur l’ancien détection de la panne et du temps de mise à jour de la table MPLS.
chemin, est ensuite détruit. On parle de procédure make-before- Sur les implémentations récentes, ce temps est inférieur à 50 ms
break. quel que soit le nombre de LSP protégés.

3.2.6 Restauration P2MP MPLS-TE 3.2.9 Protection de nœud P2MP MPLS-TE

En cas de panne de lien ou de nœud sur un tunnel P2MP RSVP-
TE, le routeur racine est notifié par un message PathErr lui indi- La protection d’un nœud de transit non branche d’un LSP P2MP
quant l’endroit de la panne. Le routeur racine supprime le point de MPLS-TE est similaire à la protection de lien. Un LSP P2P bypass
panne de la topologie et recalcule un nouvel arbre ; il supprime est établi entre le nœud en amont et le nœud en aval du lien
l’ancien LSP P2MP et établit un nouveau LSP P2MP. Cette restaura- protégé.
tion d’arbre peut prendre de quelques centaines de millisecondes
La protection d’un nœud branche nécessite, quant à elle, l’utili-
à quelques secondes en fonction du nombre d’arbres impactés par
sation de plusieurs P2P bypass. Il faut un P2P bypass par voisin en
la panne et de la taille du réseau.
aval du nœud protégé.

3.2.7 Fast Reroute P2MP MPLS-TE La figure 23 illustre la protection d’un nœud branche par un
ensemble de P2P bypass. Le nœud branche R2 a deux voisins en
Le mécanisme de Fast Reroute MPLS-TE (FRR), défini dans la aval R4 et R5. Il est protégé par un P2P bypass de R1 vers R4 et un
norme IETF RFC-4090 [5], permet de protéger en moins de 50 ms P2P bypass de R1 vers R5. Pendant la panne, R1 réplique le trafic
un LSP point-à-point en cas de panne de lien ou de nœud. Ce dans les deux LSP bypass vers R4 et R5.

Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie

TE 7 578 – 18 est strictement interdite. – © Editions T.I.

Dossier délivré pour

DOCUMENTATION
21/10/2008
Dossier délivré pour
DOCUMENTATION
21/10/2008

________________________________________________________________________________________________________________ LE MULTICAST MPLS

30 → pop, R2

R3
LSP P2P bypass 20 → 28, R7

20 IP
28 IP
LSP P2MP primaire R1 R2 R4

25 IP 40 IP
40 → 20, R4 22 IP
25 → 40, R2 22, R5
secours 40, 30, R3 R5 37 IP
22 → 37, R6

Figure 21 – Protection de lien par un LSP P2P bypass avant la panne

30 → pop, R2

R3
LSP P2P bypass 20 → 28, R7
30 40 IP 40 IP
45 IP 28 IP
LSP P2MP primaire R1
R2 R4

25 IP
25 → 40, 30, R3 40 → 20, R4 22 IP
22, R5
R5 37 IP
22 → 37, R6

Figure 22 – Protection de lien par un LSP P2P bypass pendant la panne

LSP P2P bypass vers R4

LSP P2MP primaire R4

R1 R2

LSP P2P bypass vers R5 R5

R3

Figure 23 – Protection d’un nœud par des P2P bypass

LSP P2P Bypass vers R4

Du R3
pl
ica
tio
n
LSP P2MP Primaire R4
R1 R2

LSP P2P Bypass vers R5 R5

Figure 24 – Protection d’un nœud par des P2P bypass : problème de duplication

Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie

est strictement interdite. – © Editions T.I. TE 7 578 – 19

Dossier délivré pour

DOCUMENTATION
21/10/2008
 Dossier délivré pour
DOCUMENTATION
21/10/2008

LE MULTICAST MPLS ________________________________________________________________________________________________________________

R3

LSP P2MP Primaire R4

R1 R2

LSP P2MP Bypass vers R4 et R5

R5

Figure 25 – Protection d’un nœud par un P2MP bypass

La protection de nœuds par des P2P bypass présente certaines On distingue deux modes pour supporter ce scénario de
limitations. Dans certains cas, les P2P bypass empruntent les raccordement : le mode d’interconnexion statique et le mode
mêmes liens, ce qui entraîne une multiplication du trafic. Un d’interconnexion dynamique. Les sections ci-dessous décrivent ces
même paquet va être envoyé plusieurs fois sur un lien. La deux modes.
figure 24 décrit ce problème. Les deux LSP P2P bypass, pour pro-
téger R2, empruntent le lien R1-R3. Pendant la panne de R2, R1
duplique le trafic sur le lien R1-R3. 4.1 Interconnexion P2MP MPLS-TE
Dans le cas où il y a n voisins en aval du lien à protéger, on peut statique
devoir répliquer jusqu’à n fois le trafic sur un lien, ce qui conduit
vite à une saturation. Dans le mode d’interconnexion statique, un arbre P2MP MPLS-
TE est configuré pour diffuser toutes les chaînes vers tous les PE
Pour remédier à ce problème, l’IETF travaille actuellement sur un
raccordant les PoP récepteurs. Les feuilles sont configurées de
mécanisme de protection par des LSP P2MP bypass. Ce méca-
manière statique sur le routeur racine. Tous les groupes multicast
nisme est défini dans le projet de norme P2MP-BYPASS [13]. Le
sont injectés dans cet arbre par des routes statiques (figure 27).
nœud R2 est protégé par un LSP P2MP bypass de R1 vers les
feuilles R4 et R5 (figure 25). Pendant la panne, une seule copie du Sur le routeur R1 de raccordement de la source, des routes sta-
trafic est envoyée sur le lien R1-R3, dans le LSP P2MP bypass, tiques multicast sont configurées pour envoyer les 3 groupes vers
pour atteindre R4 et R5. PE1. Sur PE1 un LSP P2MP MPLS-TE, L1, est configuré, vers les
feuilles PE2, PE3 et PE4. Des routes statiques sont configurées
Pendant la panne, le LSP P2MP primaire est encapsulé dans le pour injecter les 3 groupes dans L1. Les 3 groupes sont diffusés
LSP P2MP bypass. Cela nécessite des mécanismes de hiérarchie dans l’arbre jusqu’aux feuilles PE2, PE3, PE4. Le protocole PIM
MPLS P2MP en cours de définition à l’IETF. tourne entre les PE feuilles et les routeurs de raccordement des
récepteurs (R2, R3, R4), de sorte que seuls les groupes demandés
sont envoyés par les PE feuilles. Le trafic des groupes qui ne sont
pas demandés est détruit par les PE feuilles. Par exemple, PE2
4. Application au transport détruit les paquets du groupe 3 qui n’est pas demandé par les
récepteurs 1 et 2.
du multicast IP Ce mode d’interaction est simple car il ne nécessite qu’un seul
LSP P2MP MPLS-TE (éventuellement 2 pour la redondance,
Comme abordé dans la section 2, un arbre MPLS peut être uti- lorsque les sources sont doublement raccordées) et n’exige aucun
lisé pour transporter : échange d’information multicast entre les PE feuilles et le PE
racine. En revanche, ce mode statique entraîne un gaspillage de
– du trafic IP multicast natif. Un arbre MPLS peut par exemple
bande passante : en effet, tous les groupes sont envoyés à tous les
être utilisé pour transporter un groupe multicast IP ou un ensem-
PE feuilles même si ceux-ci n’ont pas de récepteur. Cette limitation
ble de groupes multicast IP ;
ne pose pas de problème lorsque les PE feuilles agrègent un grand
– du trafic multicast d’un VPN IP ou d’un VPN de niveau 2 nombre de récepteurs et que la probabilité d’avoir tous les grou-
(Ethernet, ATM, TDM...). On aura dans ce cas un arbre distinct par pes demandés derrière un PE feuille est très forte, ce qui est le cas
VPN ; en cœur de réseau.
– du trafic MPLS (empilement de labels), dans le cas d’arbres
hiérarchiques. Ce mode de raccordement statique est le seul mode disponible
au moment où l’article est écrit. Il est déployé dans plusieurs
Cette dernière section aborde le transport de multicast IP natif réseaux de cœur pour le transport du trafic IPTV.
dans des arbres MPLS.
Nous étudierons ici un scénario de raccordement de nuages IP
multicast par un nuage MPLS multicast ; nous nous intéresserons 4.2 Interconnexion P2MP MPLS-TE
uniquement au mode P2MP MPLS-TE qui est le seul implémenté dynamique
au moment où cet article est écrit.
La figure 26 illustre ce scénario. Quatre PoP IP multicast sont Dans ce mode d’interconnexion dynamique, les routes multicast
connectés à un cœur MPLS multicast. Le PoP de gauche contient sont dynamiquement injectées dans les arbres MPLS et les feuilles
une source qui émet trois groupes multicast. Les 3 PoP de droite des arbres évoluent dynamiquement en fonction de l’activité des
contiennent chacun deux récepteurs multicast qui souhaitent récepteurs multicast.
s’abonner à l’un des trois groupes. Les routeurs d’accès du cœur Dans un cas particulier de réalisation, il y a un arbre P2MP
MPLS sont appelés PE (Provider Edge ). MPLS-TE par groupe multicast. La figure 28 illustre ce mode.

Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie

TE 7 578 – 20 est strictement interdite. – © Editions T.I.

Dossier délivré pour

DOCUMENTATION
21/10/2008
Dossier délivré pour
DOCUMENTATION
21/10/2008

________________________________________________________________________________________________________________ LE MULTICAST MPLS

Récepteur 1

R2

Récepteur 2
PE2
Récepteur 3
Source

R1 PE1 P1 PE3 R3

Récepteur 4
PoP IP MCAST
PE4 Récepteur 5

Cœur MPLS MCAST R4

Groupe 1 232.0.0.1

Groupe 2 232.0.0.2 Récepteur 6

Groupe 3 232.0.0.3 PoP IP MCAST

Figure 26 – Scénario de raccordement IP multicast

LSP P2MP MPLS-TE L1 IGMP Report 232.0.0.1 Récepteur 1

Destination : PE2, PE3, PE4
Route statique
PIM Join 232.0.0.1
232.0.0.1 → L1
Route statique 232.0.0.2 → L1
232.0.0.1 → PE1 232.0.0.3 → L1 R2
232.0.0.2 → PE1
232.0.0.3 → PE1 Récepteur 2
PE2
Récepteur 3
Source

R1 PE1 PE3 R3
LSP P1
P2MP
L1 Récepteur 4
Récepteur 5
PE4
Groupe 1 232.0.0.1
Cœur MPLS MCAST R4
Groupe 2 232.0.0.2

Groupe 3 232.0.0.3 Récepteur 6

Figure 27 – Interconnexion P2MP MPLS-TE statique

Seuls les groupes 1 et 2 sont ici demandés par les récepteurs. – l’utilisation du protocole PIM tournant directement entre le PE
Un LSP P2MP est dynamiquement établi par le LSP racine PE1 racine et les PE feuilles ;
pour chaque groupe, et ses feuilles sont des PE avec des récep- – l’utilisation du protocole BGP avec des extensions multicast.
teurs pour ce groupe. Le groupe 1 est transporté par le LSP P2MP
L1 qui a pour feuilles PE2 et PE3. Le groupe 2 est transporté par le Ce mode nécessite également un mécanisme de découverte des
LSP P2MP L2 qui a pour feuilles PE3 et PE4. Le protocole PIM arbres et des feuilles d’arbre :
tourne entre R1 et PE1 et seuls les groupes 1 et 2 sont transmis sur – le LSR racine doit signaler les arbres dont il est racine et les
le lien R1-PE1. groupes transportés ;
Dans ce mode, seuls les groupes demandés sont transmis dans – les LSR feuilles doivent annoncer les arbres qu’ils veulent
le cœur ; ce mode ne gaspille donc pas de bande passante. En rejoindre.
revanche, il nécessite une communication multicast entre la racine
Cette découverte repose sur des extensions BGP définies dans le
et les feuilles. En effet, PE1 doit avoir connaissance que PE2 a un
projet de norme IETF BGP-MCAST [8]. La découverte des arbres et
récepteur pour le groupe 1, que PE3 a un récepteur pour les grou-
des feuilles avec BGP est illustrée sur la figure 29.
pes 1 et 2 et que PE4 a un récepteur pour le groupe 2. Il y a deux
options pour assurer cette communication multicast entre racine et La figure 29 décrit les procédures lors de l’abonnement du
feuilles : récepteur 6 au groupe 1 :

Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie

est strictement interdite. – © Editions T.I. TE 7 578 – 21

Dossier délivré pour

DOCUMENTATION
21/10/2008
 Dossier délivré pour
DOCUMENTATION
21/10/2008

LE MULTICAST MPLS ________________________________________________________________________________________________________________

LSP P2MP MPLS-TE L1

Destination : Dynamic Récepteur 1
LSP P2MP MPLS-TE L2
Destination : Dynamic
Route dynamique
232.0.0.1 → L1
232.0.0.2 → L2 R2

Récepteur 2
PE2
Récepteur 3
Source

R1 PE1 PE3 R3
P1

Récepteur 4
Récepteur 5
PE4

Groupe 1 232.0.0.1
Cœur MPLS MCAST R4
Groupe 2 232.0.0.2

Groupe 3 232.0.0.3 Récepteur 6

Figure 28 – Interconnexion P2MP MPLS-TE dynamique

LSP P2MP MPLS-TE L1

Destination : Dynamic 1 : Annonce BGP Récepteur 1
LSP P2MP MPLS-TE L2 Groupe 232.0.0.1
Destination : Dynamic LSP L1 racine PE1
Route dynamique
232.0.0.1 → L1
232.0.0.2 → L2 R2
5 : Réception annonce PE4
Ajout feuille PE4 à LSP L1 Récepteur 2
PE2
Récepteur 3
Source

R1 PE1 PE3 R3
P1
6 : Diffusion 232.0.0.1 Récepteur 4
Récepteur 5
PE4
Groupe 1 232.0.0.1
Cœur MPLS MCAST R4
Groupe 2 232.0.0.2
3 : PIM Join 232.0.0.1
Groupe 3 232.0.0.3 Récepteur 6
4 : Annonce BGP
PE4 souhaite rejoindre LSP L1
racine PE1 2 : Abonnement 232.0.0.1
IGMP Report

Figure 29 – Séquence d’abonnement d’un récepteur

• Étape 1 : le LSR racine, PE1, annonce à tous les autres PE, via • Étape 4 : le routeur PE4 détermine dans sa table de corres-
une extension BGP, qu’il est racine de l’arbre MPLS-TE L1 pondance groupe-LSP que le groupe 1 est diffusé par PE1 sur
transportant le groupe 1. Tous les PE enregistrent cette infor- le LSP P2MP L1. Il annonce via une extension BGP qu’il
mation. souhaite rejoindre le LSP L1.
• Étape 5 : sur réception de cette annonce, PE1 calcule un che-
• Étape 2 : le récepteur 6 s’abonne au groupe 1, il envoie un
min vers la nouvelle feuille PE4, et ajoute PE4 à l’arbre L1
message IGMP Report au routeur R4.
(message RSVP-TE Path/Resv).
• Étape 3 : le routeur R4 envoie un message PIM Join pour le • Étape 6 : PE4 reçoit le groupe 1 qui est transmis vers le récep-
groupe 1 à PE4. teur 6.

Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie

TE 7 578 – 22 est strictement interdite. – © Editions T.I.

Dossier délivré pour

DOCUMENTATION
21/10/2008
Dossier délivré pour
DOCUMENTATION
21/10/2008

________________________________________________________________________________________________________________ LE MULTICAST MPLS

5. Conclusions l’échelle que MLDP (il y a toujours un prix à payer en termes

d’états pour assurer ces fonctions avancées). Le protocole P2MP
et perspectives RSVP-TE est standard, implémenté et déployé, tandis que le proto-
cole MLDP est toujours en cours de standardisation et n’est pas
encore implémenté au moment de la rédaction de ce dossier. Des
Pour faire face à l’émergence d’applications multicast à fortes travaux sont encore nécessaires pour consolider la spécification
contraintes de bande passante, de disponibilité et de tunneling, MLDP.
l’IETF travaille depuis 5 ans à étendre la technologie MPLS, définie Des travaux sont aussi en cours à l’IETF pour assurer une inte-
initialement, il y a dix ans, pour le transport du trafic unicast, afin raction entre le routage multicast MPLS et le routage multicast IP,
d’assurer un transport efficace du trafic multicast dans un réseau ils reposent essentiellement sur des extensions du protocole BGP
MPLS. L’architecture MPLS multicast résultante de ces travaux afin de transporter des informations d’abonnement/désabonne-
permet le transport de trafic multicast IP, multicast VPN IP et mul- ment multicast et des informations d’autodécouverte des arbres et
ticast VPN de niveau 2 (Ethernet, ATM, TDM). Elle définit des LSP feuilles d’arbre, entre la racine et les feuilles. Les fonctions avan-
avec une source et plusieurs destinations appelés LSP point-à- cées de hiérarchie MPLS P2MP (encapsulation d’un arbre MPLS
multipoint (P2MP) ou arbre MPLS. Les protocoles RSVP-TE et LDP dans un autre arbre MPLS) et de connectivité MPLS multipoint-à-
ont été étendus pour l’établissement d’arbres MPLS. Ces exten- multipoint (LSP MP2MP) sont également en phase de
sions sont appelées respectivement MLDP et P2MP RSVP-TE. consolidation.

MLDP permet l’établissement d’arbres MPLS de plus court

chemin initiés par les feuilles, il passe très bien à l’échelle, mais Remerciements
n’offre pas de fonctions d’ingénierie de trafic et de sécurisation
rapide. P2MP RSVP-TE permet l’établissement d’arbres explicites
L’auteur tient à remercier Mohamad Chaitou pour l’impor-
initiés par la racine, il offre des fonctions avancées d’ingénierie de
tant travail de simulation, dont certains résultats sont présents
trafic (arbres de coût minimum, contrôle d’admission) et de sécuri-
dans ce dossier.
sation rapide (P2MP MPLS Fast Reroute ), mais passe moins bien à

Sigles et abréviations Sigles et abréviations

BGP Border Gateway Protocol. Protocole de routage LSR Label Switching Router. Routeur MPLS, capable
fonctionnant entre systèmes autonomes. d’aiguiller un paquet sur la base du label MPLS.

FRR Fast ReRoute. Mécanisme de protection locale MLDP Multicast LDP. Extension de LDP permettant d’éta-
MPLS permettant un reroutage en moins de 50 ms blir des LSP P2MP. Les LSP P2MP LDP sont initiés
en cas de panne de lien ou de nœud. par les feuilles, ils suivent un arbre de plus court
chemin des feuilles vers la racine.
IETF Internet Engineering Task Force. Organisme de
standardisation des protocoles de l’Internet, MP Merge Point. LSR de rencontre d’un LSP primaire
chargé de la production des RFC. et de son LSP de secours Fast Reroute en aval
d’une panne.
IGMP Internet Group Management Protocol. Protocole
multicast IP tournant entre les récepteurs et le rou- MPLS Multi Protocol Label Switching. Technique de
teur d’accès, utilisé pour gérer l’abonnement/désa- commutation basée sur l’introduction d’une éti-
bonnement d’un récepteur à un groupe multicast. quette de taille fixe appelée « label » entre les en-
têtes de niveaux 2 et 3. Un routeur MPLS utilise ce
IP Internet Protocol. label pour déterminer l’interface le sortie et le
label de sortie.
ISIS-TE ISIS Traffic Engineering. Extension de IS-IS pour
l’annonce des paramètres d’ingénierie de trafic MPLS-TE MPLS Traffic Engineering. Mécanisme de routage
des liens (bande passante...). par contrainte permettant l’établissement de tun-
nels MPLS-TE. Il s’agit de LSP MPLS routés de
LDP Label Distribution Protocol. Protocole d’établisse- façon explicite en fonction de contraintes d’ingé-
ment de LSP MPLS le long de la route IP. nierie de trafic comme la bande passante.

LSP Label Switched Path. Chemin MPLS. MP2MP Multipoint-to-Multipoint. Connectivité multipoint-
à-multipoint.
LSP P2MP LSP Point-to-Multipoint. LSP avec un routeur de
tête, appelé « routeur racine » et un ou plusieurs P2P Point-to-point. Connectivité point-à-point.
routeurs destination, appelés « routeurs feuilles »
permettant une diffusion de paquets dans un P2MP Point-to-Multipoint. Connectivité point-à-multi-
réseau MPLS. Un LSP P2MP est utilisé pour le point.
transport de paquet multicast IP, multicast VPN IP
ou multicast VPN de niveau 2 (Ethernet, ATM…). P2MP Point-to-Multipoint MPLS-TE. Mécanisme de rou-
Ces LSP sont aussi appelés « arbres MPLS ». MPLS-TE tage par contrainte permettant l’établissement
d’arbres MPLS-TE. Il s’agit de LSP MPLS point-à-
LSP LSP Multipoint-to-Multipoint. LSP avec un ensem- multipoint routés de façon explicite en fonction de
MP2MP ble de feuilles agissant comme émetteurs et contraintes d’ingénierie de trafic comme la bande
récepteurs. passante.

Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie

est strictement interdite. – © Editions T.I. TE 7 578 – 23

Dossier délivré pour

DOCUMENTATION
21/10/2008
 Dossier délivré pour
DOCUMENTATION
21/10/2008

LE MULTICAST MPLS ________________________________________________________________________________________________________________

Sigles et abréviations Sigles et abréviations

P2MP Point-to-Multipoint RSVP-TE. Extension du proto- RPF Reverse « Path » Forwarding. La vérification RPF
RSVP-TE cole RSVP-TE permettant l’établissement d’arbre est une procédure multicast IP consistant à vérifier
MPLS-TE. Les arbres MPLS-TE sont initiés par la que l’interface de réception d’un paquet est l’inter-
racine, ils suivent un chemin explicite. face sur le plus court chemin vers la source. Cette
procédure permet de limiter l’impact d’une boucle
PCE Path Computation Element. Élément externe au de routage.
routeur de tête (autre routeur, serveur) chargé du
calcul de la route d’un LSP MPLS-TE. RSVP Ressource Reservation Protocol. Protocole de
signalisation permettant la réservation de ressour-
ces dans les réseaux IP.
PE Provider Edge. Routeur d’accès d’un réseau IP/
MPLS.
RSVP-TE RSVP Traffic Engineering. Extensions de RSVP
pour l’établissement de tunnels MPLS-TE.
PIM Protocol Independant Multicast. Protocole de rou-
tage IP multicast permettant la construction VPN Virtual Private Network. Réseau privé virtuel.
d’arbres de réplication.
VRF Virtual Routing and Forwarding table. Table de
PoP Point of Presence. Point de présence IP. routage d’un réseau privé virtuel IP.

Références bibliographiques

[1] YASUKAWA et coll. – Norme RFC-4461, Si- norme intitulé « draft-ietf-l3vpn-2547bis- (projet de norme intitulé « draft-leroux-
gnaling Requirements for P2MP TE-LSPs mcast-bgp » à l’IETF). mpls-p2mp-te-bypass » à l’IETF).
(avr. 2006). [9] MINEI et coll. – Norme MP-LDP, LDP Exten- [14] HWANG (F.K.), RICHARDS (D.S.) et WINTER
[2] ANDERSSON (L.) et coll. – Norme RFC-3036, sions for P2MP LSP (projet de norme intitulé (P.). – The Steiner Tree Problem. Elsevier,
LDP Specification (janv. 2001). « draft-ietf-mpls-ldp-p2mp » à l’IETF). North-Holland (1992).
[3] BERGER (L.) et coll. – Norme RFC-2961, RSVP [15] TAKAHASHI. – An approximate solution for
[10] LE ROUX et coll. – Norme MP-LDP-REQ, Re- Steiner tree problem in graphs. Math Japo-
Refresh Overhead Reduction Extensions
quirements for P2MP Extensions to LDP (pro- nica 24, no 6, p. 573 à 577 (1980).
(avr. 2001).
jet de norme intitulé « draft-ietf-mpls-mp-
[4] AWDUCHE (D.) et coll. – Norme RFC-3209, ldp-reqs » à l’IETF).
RSVP Traffic Engineering (déc. 2005). Aux Éditions T.I.
[5] PAN et coll. – Norme RFC-4090, Fast Reroute [11] VASSEUR, LE ROUX et coll. – Norme TE- Dans les Techniques de l’Ingénieur
Extensions to RSVP-TE (mai 2005). NODE-CAP, IGP Routing Protocol Extensions
for Discovery of Traffic Engineering Node Ca- Base documentaire
[6] FENNER (B.) et coll. – Norme RFC-4601, Pro-
pabilities (projet de norme intitulé « draft- Réseaux Télécommunications
tocol Independent Multicast - Sparse Mode
ietf-ccamp-te-node-cap » à l’IETF).
(PIM-SM) (août 2006). [16] BONNIN (J.-M.). – Le protocole MPLS.
[7] AGGARWAL (R.) et coll. – Norme RFC-4875, [12] YASUKAWA et coll. – Norme PCE-P2MP, [TE 7 535] (2003).
Extensions to RSVP-TE for P2MP LSP (mai PCC-PCE Communication Requirements for [17] LE ROUX (J.-L.). – MPLS : applications à l’in-
2007). P2MP MPLS-TE (projet de norme intitulé génierie de trafic et à la sécurisation.
[8] AGGARWAL (R.) et coll. – Norme BGP- « draft-yasukawa-pce-p2mp-req » à l’IETF). [TE 7 577] (2006).
MCAST, BGP Encodings and Procedures for [13] LE ROUX et coll. – Norme P2MP MPLS-TE [18] LOYE (S.). – Le multicast IP : principes et
Multicast in MPLS/BGP IP VPNs. (projet de « Fast Reroute » with P2MP Bypass Tunnels protocoles. [TE 7 527] (2005).

Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie

TE 7 578 – 24 est strictement interdite. – © Editions T.I.

Dossier délivré pour

DOCUMENTATION
21/10/2008