Résumé

  • RFC 6426 étend LSP ping à la vérification de connectivité MPLS-TP à la demande et au traçage de route. Le Requester choisit la sonde, l’encapsulation, le TTL, le mode de réponse et la demande éventuelle de chemin inverse ; le Responder ne fournit que les éléments vérifiables à sa position.
  • Une réponse peut identifier un point intermédiaire sélectionné par expiration du TTL, et non l’extrémité. La réception seule ne permet donc pas de déclarer un service bidirectionnel.
  • Le Requester doit valider l’interface, la pile de labels, le FEC applicable, l’identité et le mode de réponse ; si un TLV Reverse-path Target FEC Stack est présent, il doit aussi le valider. Une validation échouée impose de supprimer la réponse et devrait être signalée.

Lire le paquet

Le fonctionnement encapsulé dans IP utilise une adresse de 127/8 et UDP à l’intérieur de la pile MPLS. Le fonctionnement non-IP utilise l’Associated Channel Header (ACH), sans dépendre du routage IP. En mode ACH non-IP avec le mode de réponse 4, la réponse doit emprunter le LSP inverse via ACH, sans IP ni UDP. Un nœud dépourvu de ce chemin de retour devrait supprimer la demande ; le silence n’est pas une preuve positive de bon fonctionnement inverse.

Les autorités du Requester et du Responder sont distinctes. Le Requester choisit un FEC de LSP statique ou de pseudowire (PW), la séquence de TTL, le mode de réponse et l’activation du bit R, qui demande des informations sur le FEC inverse. Le Responder ne peut rapporter que ce qui est valide à l’endroit où il reçoit la demande. Il ne doit pas positionner R dans une réponse Echo. Si R était positionné dans la demande, le Responder devrait joindre un TLV Reverse-path Target FEC Stack. Des LSP associés et bidirectionnels ou co-routés peuvent néanmoins utiliser un FEC inverse différent. Une réponse sans preuve R/TLV ne prouve aucun FEC inverse.

Pour le traçage, l’expiration pilotée par le TTL dirige les demandes vers des points déterminés du LSP. DSMAP et DDMAP servent à mettre en correspondance destinations et réponses ; ils ne transforment pas une réponse intermédiaire en preuve d’extrémité. Les TLV Source Identifier et Destination Identifier rendent explicites la source, la cible et le contexte administratif. Entre domaines administratifs, les TLV Source Identifier sont recommandés afin de filtrer les sources inattendues ou inconnues.

Le GAL transporte l’OAM ; ce n’est pas le label FEC cible à vérifier. Il ne doit pas recevoir de TLV FEC Nil et ne doit pas apparaître dans DSMAP ou DDMAP, même si les TLV d’interface et de pile de labels l’incluent. Confondre le GAL avec le FEC cible crée une validation erronée.

Fixture concrète de vérification

L’opérateur teste un FEC de LSP statiquement provisionné 10.0.0.1/32 ou un FEC de PW, envoie une sonde MPLS avec TTL 2, enregistre le mode de réponse 4 et demande les informations inverses avec R positionné. La capture doit corréler Source Identifier, Destination Identifier, identité du répondeur, interface d’entrée, pile complète de labels, FEC cible, TLV Reverse-path Target FEC Stack lorsqu’il est présent, encapsulation ACH ou 127/8-plus-UDP et point d’expiration du TTL. La réponse n’est acceptée que si l’interface et la pile locales correspondent au FEC attendu et si toute pile inverse présente est validée par l’inventaire du Requester. R doit être absent de la réponse. Source inattendue, divergence de labels, FEC inverse invalide ou interface invalide signifient : supprimer, journaliser et signaler l’échec.

Répéter plusieurs TTL permet de distinguer l’extrémité attendue des répondeurs intermédiaires. Pour le P2MP avec adressage IP, la prise en charge des procédures de RFC 6425 est obligatoire ; sans adressage IP, les procédures non-IP de RFC 6426 s’appliquent. Il faut identifier la branche et ne pas considérer une réponse comme représentative de toutes les feuilles. Un nœud qui ne prend pas en charge le mode de réponse demandé, ou ne peut pas l’utiliser, doit supprimer la demande.

Il ne faut pas utiliser l’ACH pour le CV à la demande avec ECMP : l’en-tête ACH peut modifier le hachage et la sonde peut suivre un chemin différent de celui des données. RFC 4379 fournit les procédures de base de LSP ping ; RFC 5586 définit le transport G-ACh ; RFC 5860 porte sur les exigences OAM MPLS-TP ; RFC 5884 fournit le contexte BFD/MPLS. RFC 5920 concerne le cadre de sécurité MPLS, RFC 5921 l’architecture du profil de transport, RFC 6370 les identifiants et RFC 6371 le cadre OAM et la limite d’autorité.

La méthode aide à interroger des chemins statiques et non-IP, à localiser les points de transit et à séparer les preuves aller et retour. Elle est déclenchée à la demande, et non une assurance continue. Le paquet factuel ne fournit aucune information sur l’adoption par les fournisseurs, la prévalence des déploiements, la latence ou la perte des sondes, l’historique d’incidents, la valeur commerciale ou les résultats clients ; ces points restent inconnus. Aucune allégation n’est établie ici.

Sources