RFC 4379 - 2. Motivation
2. Motivation
Lorsqu'un LSP ne parvient pas à acheminer le trafic utilisateur, la défaillance ne peut pas toujours être détectée par le plan de contrôle MPLS. Il est nécessaire de fournir un outil qui permette aux utilisateurs de détecter ces "trous noirs" de trafic ou ces erreurs de routage dans un délai raisonnable, ainsi qu'un mécanisme d'isolation des défaillances.
Dans ce document, nous décrivons un mécanisme qui atteint ces objectifs. Ce mécanisme est calqué sur le paradigme ping/traceroute : ping (ICMP echo request [ICMP]) sert aux vérifications de connectivité, et traceroute sert à la localisation des défaillances saut par saut ainsi qu'au traçage de chemin. Ce document spécifie un mode "ping" et un mode "traceroute" pour tester les LSP MPLS.
L'idée de base est de vérifier que les paquets appartenant à une classe d'équivalence de transfert (Forwarding Equivalence Class, FEC) donnée terminent effectivement leur chemin MPLS sur un routeur à commutation d'étiquettes (Label Switching Router, LSR) qui est une sortie pour cette FEC. Ce document propose d'effectuer ce test en envoyant un paquet (appelé "MPLS echo request") le long du même chemin de données que les autres paquets appartenant à cette FEC. Un MPLS echo request transporte également des informations sur la FEC dont le chemin MPLS est vérifié. Cet echo request est transféré exactement comme tout autre paquet appartenant à cette FEC. En mode "ping" (vérification de connectivité de base), le paquet doit atteindre l'extrémité du chemin, où il est envoyé au plan de contrôle du LSR de sortie, lequel vérifie ensuite qu'il est bien une sortie pour la FEC. En mode "traceroute" (isolation des défaillances), le paquet est envoyé au plan de contrôle de chaque LSR de transit, qui effectue diverses vérifications pour établir qu'il est bien un LSR de transit pour ce chemin ; ce LSR renvoie également des informations complémentaires qui aident à confronter le plan de contrôle au plan de données, c'est-à-dire à vérifier que le transfert correspond à ce que les protocoles de routage ont déterminé comme chemin.
L'une des utilisations de ces outils consiste à pinguer périodiquement une FEC pour s'assurer de la connectivité. Si le ping échoue, on peut alors lancer un traceroute pour déterminer où se situe la défaillance. On peut aussi tracer périodiquement les FEC pour vérifier que le transfert correspond au plan de contrôle ; toutefois, cela impose une charge plus importante aux LSR de transit et doit donc être utilisé avec prudence.
2.1. Utilisation de la plage d'adresses 127/8 (Use of Address Range 127/8)
Comme décrit ci-dessus, LSP ping est conçu comme un outil de diagnostic. Il vise à permettre aux fournisseurs d'un service basé sur MPLS d'isoler les défaillances du réseau. En particulier, LSP ping doit diagnostiquer les situations où les plans de contrôle et de données sont désynchronisés. Il y parvient en acheminant un paquet MPLS echo request uniquement en fonction de sa pile d'étiquettes. Autrement dit, l'adresse de destination IP n'est jamais utilisée dans une décision de transfert. De fait, l'émetteur d'un paquet MPLS echo request peut ne pas connaître a priori l'adresse du routeur situé à l'extrémité du LSP.
Les fournisseurs de services basés sur MPLS ont également besoin de pouvoir tracer tous les chemins possibles qu'un LSP peut emprunter. Comme la plupart des services MPLS reposent sur le transfert unicast IP, ces chemins sont soumis au partage de charge par chemins multiples à coût égal (Equal-Cost Multi-Path, ECMP).
Il en découle les exigences suivantes :
-
Bien que le LSP concerné puisse être défaillant de manière inconnue, la probabilité qu'un paquet de diagnostic soit remis à un utilisateur d'un service MPLS MUST être maintenue à un minimum absolu.
-
Si un LSP est défaillant de telle sorte qu'il se termine prématurément, le paquet de diagnostic MUST NOT être transféré en IP.
-
Un moyen de faire varier les paquets de diagnostic afin qu'ils empruntent tous les chemins ECMP est donc REQUIRED.
De toute évidence, l'utilisation d'adresses unicast générales ne satisfait à aucune des deux premières exigences. Un certain nombre d'autres options d'adressage ont été envisagées, notamment une partie de l'espace d'adresses privées (déterminée par l'opérateur du réseau) et les adresses lien local IPv4 récemment désignées. L'usage de l'espace d'adresses privées a été jugé inefficace, car le principal service basé sur MPLS est un réseau privé virtuel (Virtual Private Network, VPN) IPv4, et les VPN utilisent souvent des adresses privées.
Les adresses lien local IPv4 sont plus intéressantes en ce que la portée sur laquelle elles peuvent être transférées est limitée. Toutefois, si l'on utilisait une adresse de cette plage, il resterait possible que le premier destinataire d'un paquet de diagnostic "échappé" d'un LSP défaillant ait cette adresse affectée à l'interface par laquelle il est arrivé, et puisse donc recevoir par erreur un tel paquet. En outre, la plage d'adresses lien local IPv4 n'a été attribuée que récemment. De nombreux routeurs déployés transféreraient un paquet portant une adresse de cette plage vers la route par défaut.
La plage 127/8 pour IPv4, ainsi que cette même plage encapsulée sous forme d'adresses IPv6 mappées IPv4 pour IPv6, ont été choisies pour plusieurs raisons.
La RFC 1122 attribue la plage 127/8 comme "Internal host loopback address" (adresse de bouclage d'hôte interne) et déclare : "Addresses of this form MUST NOT appear outside a host." (Les adresses de cette forme MUST NOT apparaître à l'extérieur d'un hôte.) Ainsi, le comportement par défaut des hôtes est de rejeter ces paquets. Cela aide à garantir que, si un paquet de diagnostic est mal dirigé vers un hôte, il sera silencieusement rejeté.
La RFC 1812 [RFC1812] déclare :
Un routeur SHOULD NOT transférer, sauf sur une interface de bouclage, tout paquet dont l'adresse de destination se trouve sur le réseau 127. Un routeur MAY disposer d'un commutateur permettant à l'administrateur réseau de désactiver ces contrôles. Si un tel commutateur est fourni, il MUST par défaut effectuer les contrôles.
Cela aide à garantir que les paquets de diagnostic ne sont jamais transférés en IP.
La plage d'adresses 127/8 offre 16M d'adresses, ce qui autorise une grande flexibilité dans la variation des adresses pour emprunter les chemins ECMP. Enfin, en tant qu'optimisation d'implémentation, la plage 127/8 fournit un moyen simple d'identifier les paquets LSP potentiels.