Mon blog

Ce RFC complète le RFC 3031 sur MPLS en spécifiant l'encodage des labels sur le câble.

Le RFC 3031, qui a introduit le nouveau protocole MPLS restait dans les généralités sur la façon exacte dont les labels étaient encodés. Notre RFC le complète sur ce point. Un label fait donc 32 bits, dont 20 pour sa valeur, celle qui est affichée par certains traceroute.

La section 2.1 détaille concrètement le format et les valeurs spéciales comme 0 (IPv4 Explicit NULL Label qui, en bas d'une pile de labels, indique qu'on est arrivé à la fin du nuage MPLS et que le routage IP « normal » doit reprendre.

La section 2.2 couvre un problème plus délicat : déterminer le protocole de couche 3 transporté, lorsqu'on doit prendre une décision basée sur ce protocole. Rien dans le label MPLS n'indique ce protocole (contrairement à Ethernet où un champ de l'en-tête indique le protocole transporté, 0x0800 indique IPv4 et 0x86DD indique IPv6). Il faut donc pouvoir le déterminer en examinant le paquet (distinguer IPv4 et IPv6 de la sorte est facile, il suffit de regarder les quatre premiers bits du paquet, qui indiquent la version) ou par une autre méthode externe au paquet.

La section 2.3 couvre un autre cas compliqué : générer un paquet ICMP si nécessaire. Si un LSR (un routeur MPLS) doit transmettre un paquet IP mais que, pour une raison ou une autre, il ne le peut pas, il est censé transmettre un paquet ICMP à la source. Cela n'est pas possible à partir des informations MPLS seules. Et ce n'est pas toujours facile puisque le LSR n'a pas toujours de moyen de joindre la source en IP (par exemple si des adresses IP privées sont « tunnelées » dans un nuage MPLS public). Notre RFC détaille donc les méthodes possibles et les précautions à prendre.