Une seule VRF peut être employée pour des sites
avec des conditions identiques de connectivité. Les topologies complexes
de VPN exigent, donc, plus d'une VRF par VPN. Puisque chaque VRF exige une RD
distinctive, le nombre de RDs dans un réseau de MPLS VPN augmente avec
l'introduction d'autres VPNs. d'aileurs, l'association simple entre le RD et
VPN qui était vrai pour VPNs simple est également disparu.
Exemple :
Figure IV.14 topologies complexes de VPN
Pour illustrer les conditions d'échange d'information
entre les tables de routage virtuelles multiples, on considère un
service de VoIP (Voice over IP) avec trois VPNs (client A, client B, et VoIP
VPN). Les besoins virtuels des tables de routage de ce service sont comme suit
:
Ainsi, dans cet exemple, plus de trois tables VRF
différentes sont nécessaires pour supporter trois VPNs. Il n'y a
aucun rapport linéaire entre le nombre des tables de routage virtuelles
(VRFs) et le nombre des VPNs.
IV.3.6 Transmission des paquets IP
La transmission des paquets IP provenant des routeurs CE sur le
backbone MPLS emploie la notion de label stacking. Pour atteindre un site
donné, le PE source encapsule deux labels : le premier sert à
atteindre le PE de destination, tandis que le second détermine
l'interface de sortie sur le PE, à laquelle est relié le CE. Le
second label est appris grâce aux mises à jour MP-BGP. Les tables
CEF des routeurs peuvent être consultées pour déterminer
les labels utilisées.
Figure IV.15 transmission des packets VPN a travers le
backbone MPLS VPN
IV.3.7 Propagation d'étiquette VPN
La deuxième étiquette est exigée pour
l'opération appropriée de MPLS VPN, Cette étiquette a
été assignée par le routeur PE de sortie. Cette
étiquette doit être propagée du routeur PE de sortie aux
routeurs PE d'entrée pour permettre la transmission de paquet
approprié.
MP-BGP a été choisi comme mécanisme de
propagation. Chaque mise à jour MP-BGP porte ainsi une étiquette
assignée par le routeur PE de sortie ainsi que le préfixe VPNv4
de 96-bit.
Le propagation d'étiquette VPN doit suivre les
étapes suivants
· Etape1 : le routeur PE de sortie assigne
une étiquette à chaque route VPN reçu des routeurs CE
attachés et à chaque route, il la récapitule à
l'intérieur du routeur PE. Cette étiquette est alors
employée comme la deuxième étiquette dans la pile
d'étiquette de MPLS par les routeurs PE d'entrée en marquant des
paquets VPN.
· Etape 2 : Les étiquettes de VPN
assignées par les routeurs PE de sortie sont
annoncées
à tous autres routeurs PE ainsi que le
préfixe VPNv4 dans les mises à jour MP-BGP.
· Etape 3 : le routeur PE d'entrée
a deux étiquettes liées à une route VPN distante, une
étiquette pour le prochain saut de BGP assigné par le prochain
saut du routeur P par l'intermédiaire de LDP aussi bien que
l'étiquette assignée par le routeur distant PE et propagée
par l'intermédiaire de la mise à jour MP-BGP. Les deux
étiquettes sont combinées dans une pile d'étiquette et
installées dans la table VRF.
Figure IV.16 propagation d'étiquette
VPN
IV.4 MPLS-QS
La qualité de service se décline principalement en
quatre paramètres : débit, délai, gigue
et perte.
· Le débit représente les ressources de
transmission occupées par un flot. Un flot est un ensemble de paquets
résultant d'une application utilisatrice.
· Le délai correspond au temps de transfert de bout
en bout d'un paquet.
· La gigue correspond aux variations de latence des
paquets. La gigue provient
essentiellement des variations de trafic sur les
liens de sorties des routeurs.
· Des pertes de paquets peuvent être dues à
des erreurs d'intégrité sur les données ou des rejets de
paquets en cas de congestion.
La qualité de service peut être fournie par deux
approches relativement différentes.
Le premier modèle, IntServ utilise la
réservation de ressources mise en place par RSVP. IntServ classifie les
données par flux. En effet, chaque flux va être placé dans
une file d'attente séparée. La granularité est forte, car
la classification se fait flux par flux selon le protocole de
réservation. En revanche, c'est un processus coûteux en ressources
machine, et qui supporte difficilement la montée en charge car les
routeurs de coeur doivent maintenir une liste des flux en cours afin de
rechercher à chaque fois la qualité de service à
appliquer. En effet, plus les flux seront nombreux, plus les traitements
à effectuer au niveau des routeurs seront importants notamment au niveau
de l'ordonnancement.
L'autre approche servant de support à la
qualité de service est DiffServ. Dans cette
configuration, les flux sont agrégés pour former des classes de
services. De cette manière les flux d'une même classe ont les
mêmes garanties de service. Par rapport à IntServ, la
granularité est donc beaucoup plus faible. Cependant, DiffServ repose
sur l'utilisation d'un système de marquage des paquets pour
définir le comportement à adopter par le noeuds recevant le
paquet. C'est ce que l'on nomme le Per-Hop Behavior. Le but
ici n'étant pas de détailler l'ensemble des mécanismes mis
en oeuvre dans DiffServ, nous allons donc voir l'utilisation de ces approches
dans MPLS.
DiffServ utilise les 8 bits de l'entête IP et les
divise comme présenté par le schéma cidessus. 6 bits sont
réservés pour les codes de différenciation de service
tandis que les deux derniers ne sont pour le moment pas utilisés.
Figure IV.17 Décomposition du DSCP
Comme vous avez sûrement pu le remarquer lorsque nous
avons abordé le format du label, le champ EXP réservé
à la qualité de service est sur 3 bits, alors que les DSCP sont
codés sur 6 bits. En dessous de 8 PHBs, cela ne pose pas de
problèmes car les 3 bits d'EXP suffisent à stocker les valeurs.
Cependant, pour un nombre de PHBs supérieur, le label est alors
utilisé en combinaison avec le champ EXP pour constituer les groupes de
PHBs.
Au niveau du choix d'une approche plus qu'une autre pour MPLS,
je dirais que les deux approches sont complémentaires. En effet, IntServ
réalise un contrôle de bout en bout des ressources
utilisées alors que DiffServ spécifie des comportements à
chaque saut. La signalisation de l'approche DiffServ est beaucoup moins
importante que IntServ, car elle ne nécessite pas de maintien de
l'état des flux par RSVP. On optera donc pour un contrôle
d'admission et un lissage du trafic en entrée du réseau
grâce à IntServ tandis que DiffServ lui sera
préféré en coeur de réseau pour limiter la
signalisation.
IV.5 Extension MPLS
Une première extension du MPLS est le Generalized
MPLS. Le concept de cette dernière technologie étend la
commutation aux réseaux optiques. Le label, en plus de pouvoir
être une valeur numérique peut alors être mappé par
une fibre, une longueur d'onde et bien d'autres paramètres. Le GMPLS met
en place une hiérarchie dans les différents supports de
réseaux optiques. GMPLS permet donc de transporter les données
sur un ensemble de réseaux hétérogènes en
encapsulant les paquets successivement à chaque entrée dans un
nouveau type de réseau. Ainsi, il est possible d'avoir plusieurs niveaux
d'encapsulations selon le nombre de réseaux traversés, le label
correspond à ce réseau étant conservé
jusqu'à la sortie du réseau. GMPLS reprend le plan de
contrôle de MPLS en l'étendant pour prendre en compte les
contraintes liées aux réseaux optiques. En effet, il va rajouter
une brique à l'architecture : Gestion des liens. Cette
brique comprend un ensemble de procédures utilisées pour
gérer les canaux et les erreurs rencontrées sur ceux-ci.
Figure IV.18Architecteur GMPLS
IV.6 Conclusion
Dans ce chapitre, nous avons présenté les
composantes relatives à l'ingénierie de trafic dans MPLS, et mise
en ouvre d'un VPN dans MPLS, ainsi nous présentons les différents
modèles utilisés pour la gestion de la QoS au niveau des
réseaux MPLS.
