Multi Protocol Label Switching
Applications de MPLS
QoS
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 ci-dessus. 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.
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 champs 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 DiffServ, 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.
Ingénierie de trafic
Comme cela a été évoqué précédemment, il existe deux modes pour l'établissement des LSP. Dans le cadre de l'implicit routing, le chemin sera défini selon l'IGP. Ceci a pour conséquence que le chemin de base sélectionné sera par défaut le chemin qui contient le moins de sauts.
Le schéma précédent décrit une topologie qu'il est courant de rencontrer. Dans le cas de l'utilisation d'un protocole IGP classique, le chemin suivi par les paquets sera constitué des routeurs R1, R3, R5, R6. Avec l'ingénierie de trafic, il est possible de spécifier que pour atteindre le réseau connecté directement au routeur R6, on souhaite utiliser le chemin R1, R2, R4, R5, R6 car la bande passante disponible est supérieure à l'autre chemin malgré le fait qu'il y ait un saut supplémentaire. Il est évident que dans cette configuration l'utilisation du source routing sera impérative. Les protocoles de routage comme OSPF se basent donc sur la métrique du nombre de saut. L'ingénierie de trafic nécessite pour chaque routeur de connaître la topologie du réseau selon d'autres critères. Pour ce faire, Constraint Shortest Path First sera utilisé. Ce protocole permet de construire une topologie selon une contrainte donnée. Dans notre exemple, la contrainte sera la bande passante du LSP. Lors de la détection des différents LSPs possibles, CSPF va automatiquement supprimer de la base topologique les LSPs qui ne satisfont pas aux contraintes émises.
Une fois l'ensemble des LSPs trouvés, si le meilleur LSP possible n'est pas unique (plusieurs chemins avec la même bande passante), le chemin dont l'adresse de destination est identique à celle du LSP sera préféré. Si on se retrouve toujours dans une situation d'égalité le LSP qui a le moins de sauts sera alors préféré. Finalement, au cas où ces deux conditions sont strictement identiques pour les deux LSPs, une répartition de charge sera effectuée entre chaque LSP afin d'équilibrer le trafic entre chacun des LSPs.
VPNs
MPLS fournit une alternative intéressante aux solutions VPNs existantes. En effet, à l'heure actuelle les solutions VPN IPSEC, relativement complexes à mettre en oeuvre s'opposent aux solutions SSL plus flexible (notamment la solution open-source OpenVPN de plus en plus répandue). L'architecture mise en place par MPLS est propice à la création de réseaux privés virtuels. Cette perspective est notamment très sollicitée par les opérateurs réseaux fournissant plusieurs clients, car elle permet de partager des équipements physiques.
Tout d'abord, l'utilisation de MPLS dans un contexte de VPNs fait appel à d'autres termes pour nommer les équipements du réseau MPLS. Les LER s'appelent alors Provider Edge, c'est cet équipement qui va gérer les VPNs des différents clients. Les LSR se transforment alors en Provider Device ; ils conservent le même rôle et se contentent donc de commuter les paquets sur l'interface adéquate. Enfin, il y a les Customer Edge qui désignent le routeur installé côté client (le site à raccorder au backbone). Ces routeurs n'ont aucune connaissance VPN, et sont reliées classiquement au backbone IP grâce à une liaison louée, une connexion PPP ...
Le PE possède plusieurs interfaces reliées aux CE. Le PE va alors maintenir ce qu'on appele des des VPN
Routing Forward. Ces entités sont des types de routeurs virtuels contenus dans le PE. C'est une table de routage qui va
contenir les routes vers les réseaux IP faisant partie d'un VPN client donné. Il faut que chaque PE
communique avec les autres afin de diffuser les routeurs à l'intérieur d'un même VPN. Pour cela un protocole
de diffusion des routes dynamique est appliqué comme Multi-Protocol iBGP. D'autre part, il faut aussi que le
routeur du client communique ses routes à son Provider Edge. Il utilise alors un protocole de routage classique comme OSPF ou RIP.
Voici un schéma général d'une architecture VPN :
Dans cette utilisation de MPLS, deux labels seront utilisés. Il y a un label destiné identifier la VRF du VPN concerné et un autre pour les opérations de commutation dans le coeur du réseau. Lorsque le routeur de sortie consulte les labels, il sait donc quelle VRF consulter pour la route que l'on cherche à joindre.
Migration vers IPv6
MPLS peut servir d'outils de transition vers IPv6 en s'appuyant sur l'infrastructure mise en place pour le VPN. L'avantage majeur de cette technique réside dans le fait que la migration ne se fait dans un premier temps qu'au niveau des sites clients. Ainsi, on conserve un coeur de réseau en IPv4 en passant les différents sites en IPv6. Une technique éprouvée existe et s'appele 6PE. Les routeurs MPLS en bordure du nuage reçoivent nativement les paquets IPv6. Ceux-ci peuvent posséder à a la fois une pile TCP/IP en sa version 4 et une pile en version 6. Un deuxième label est utilisé pour spécifier que le paquet transporté est de l'IPv6. Le paquet transite ensuite naturellement gràce au label inséré par le routeur 6PE jusqu'à ce qu'il soit décapsulé en sortie du nuage.