L’article MPLS présente les principes de la commutation de label et plus particulièrement le protocole MPLS (MultiProtocol Label Switching). Dans un cœur de réseau MPLS, les paquets IP en transit sont encapsulés dans des paquets MPLS et sont relayés sur la base du label se trouvant dans l’en-tête MPLS. Les LSR (Label Switching Router) d’un nuage MPLS doivent pour cela se mettre d’accord sur le sens à attribuer aux labels, c’est ce que l’on appelle la distribution de label. Il y a plusieurs manières de peupler les tables de commutation MPLS. La première est de le faire manuellement, ce qui n’est réaliste que pour un nombre très limité de classes d’équivalence FEC (Forwarding Equivalence Class). Il est aussi possible d’utiliser un protocole entièrement automatique qui construit, sur la base des informations contenues dans les tables de routage IP, les chemins MPLS (les LSP Label Switched Path) pour chacune des classes d’équivalence reconnues dans les tables de routage. Avec cette approche, la construction des chemins se fait de proche en proche (Hop by Hop) sur un principe de fonctionnement similaire à celui des protocoles de routage IP. L’utilisation du nouveau protocole de distribution des labels, LDP (Label Distribution Protocol) est un exemple de cette approche, l’ajout d’information de distribution des labels dans BGP4 (Border Gateway Protocol 4) en est un autre. Enfin, il existe des solutions basées sur un contrôle centralisé. Elles offrent des outils pour établir des LSP en fournissant explicitement le chemin qu’ils doivent emprunter et la qualité de service qu’ils doivent assurer. Ces solutions s’appuient sur deux protocoles, le premier, CR-LDP (Constraint Routing – Label Distribution Protocol) est une extension de LDP dont il requiert la présence dans le réseau tandis que le second, RSVP-TE (ReSerVation Protocol – Tunnel Extension) est une modification de RSVP déjà présente dans les routeurs de nombreux constructeurs. Il existe un débat quant au choix du protocole permettant d’établir explicitement des chemins entre les tenants de CR-LDP et ceux de RSVP-TE. Nous n’entrerons pas dans la polémique, d’autant plus qu’ils proposent essentiellement les mêmes fonctions. Et, si nous avons choisi de traiter ici CR-LDP, ce n’est que parce que nous traitons déjà de LDP.
Tout d’abord, nous étudions les principes de LDP puis son fonctionnement en donnant un certain nombre d’exemples. Enfin, nous décrirons les possibilités de CR-LDP avant de conclure en esquissant l’état du marché et les propositions d’évolutions et d’extension de LDP d’ores et déjà proposées à l’IETF (Internet Engineering Task Force).
