RFC 4379 - 4. Theory of Operation

4. Théorie de fonctionnement (Theory of Operation)

Un MPLS echo request sert à tester un LSP particulier. Le LSP testé est identifié par une "pile FEC" ; par exemple, si le LSP est établi via LDP vers l'adresse IP de sortie 10.1.1.1, la pile FEC contient un seul élément, le sous-TLV préfixe LDP IPv4 de valeur 10.1.1.1/32. Si le LSP testé est un LSP RSVP, la pile FEC consiste en un seul élément identifiant de façon unique ce LSP par sa session RSVP et son gabarit d'expéditeur.

La pile FEC peut être plus complexe. Par exemple, on peut tester le préfixe VPN IPv4 10.1/8 via un tunnel LSP LDP dont la sortie est 10.10.1.1. La pile FEC contient alors deux sous-TLV, le préfixe VPN IPv4 au fond et le préfixe LDP IPv4 au sommet. Si le tunnel sous-jacent (LDP) est inconnu ou jugé sans rapport, la pile FEC peut être un seul élément contenant le sous-TLV préfixe VPN IPv4.

À la réception d'un MPLS echo request, le récepteur est censé vérifier que le plan de contrôle et le plan de données sont sains (pour la pile FEC pingée) et que les deux plans sont synchronisés. La procédure est à la section 4.4.

4.1. Traitement des chemins équivalents multiples (ECMP) (Dealing with Equal-Cost Multi-Path)

Un LSP n'est pas nécessairement un simple tunnel point à point. Un seul LSP commence souvent en plusieurs entrées et finit en plusieurs sorties (fréquent pour les LSP LDP). Un LSP pour un FEC donné peut aussi avoir plusieurs "sauts suivants" dans un LSR de transit. À l'entrée, plusieurs LSP différents peuvent être choisis pour atteindre le point souhaité. Enfin, un LSP peut avoir des chemins de secours, des chemins de déviation et d'autres chemins alternatifs.

Les deux derniers cas d'abord : on suppose que le LSR initiant l'echo request peut forcer celui-ci dans n'importe quel LSP souhaité, donc le choix de plusieurs LSP à l'entrée n'est pas un problème. La sonde des divers chemins de secours (généralement non utilisés pour le transfert de données tant que le LSP principal est actif) n'est pas traitée ici.

Comme le LSP et le chemin réellement empruntés par un paquet donné peuvent être inconnus à l'avance, il est utile qu'un MPLS echo request puisse parcourir tous les chemins possibles. Mais cela, bien qu'idéal, peut être peu réaliste car l'algorithme utilisé par chaque LSR pour répartir les paquets sur différents chemins peut être propriétaire.

Pour couvrir partiellement les chemins alternatifs, on a une certaine liberté dans le choix de l'adresse IP de destination et du port UDP source de l'echo request. Cela est manifestement insuffisant ; dans le cas du traceroute, les informations de multipath du TLV de correspondance aval offrent plus de liberté. Usage : le LSR d'entrée envoie périodiquement des messages MPLS traceroute pour déterminer si un LSP donné a un multipath. Le cas échéant, chaque saut fournit des informations sur la façon de piloter ses chemins aval. L'entrée peut alors envoyer des MPLS echo request parcourant ces chemins. Si plusieurs LSR ont un ECMP, l'entrée MAY tenter des combinaisons pour parcourir tous les chemins possibles. Mais une couverture complète peut ne pas être réalisable.

4.2. Tester les LSP utilisés pour transporter des charges MPLS (Testing LSPs That Are Used to Carry MPLS Payloads)

Pour détecter certaines ruptures de LSP, il peut être nécessaire (MAY) d'encapsuler le MPLS echo request avec au moins une étiquette supplémentaire lors du test des LSP transportant une charge MPLS (comme les LSP transportant le trafic L2VPN et L3VPN). Par exemple, tester un LSP LDP ou RSVP-TE en envoyant simplement un MPLS echo request peut ne pas détecter qu'un routeur juste en amont de la destination LSP ping a réussi à transférer l'echo request via une interface non configurée pour transporter une charge MPLS, en raison du pop de la pénultième extrémité (penultimate hop popping). Comme le routeur récepteur ne peut pas distinguer si un paquet IP a été envoyé sans étiquette ou avec une étiquette Implicit Null, placer une étiquette de remplissage (shim) Nil FEC au-dessus du MPLS echo request empêche le routeur de transférer de tels paquets via une interface non étiquetée.

4.3. Envoi d'un MPLS Echo Request (Sending an MPLS Echo Request)

Un MPLS echo request est un paquet UDP. L'en-tête IP est paramétré ainsi : l'adresse IP source est une adresse routable de l'émetteur ; l'adresse IP de destination est une adresse (choisie aléatoirement) issue de 127/8 (IPv4) ou 0:0:0:0:0:FFFF:127/104 (IPv6). Le IP TTL est mis à 1. Le port UDP source est choisi par l'émetteur ; le port UDP de destination est 3503 (attribué par l'IANA pour MPLS echo request). L'en-tête IP MUST contenir l'option Router Alert.

Le MPLS echo request est envoyé avec la pile d'étiquettes correspondant au FEC testé. Noter que (par exemple) si le routage normal vers le FEC au sommet de la pile passe par un tunnel de génie traffic [RSVP-TE], d'autres étiquettes peuvent être appliquées. Si tous les FEC de la pile correspondent à une étiquette Implicit Null, le MPLS echo request est considéré comme sans étiquette même si une étiquette supplémentaire est appliquée à l'émission.

Si l'echo request a une étiquette, on peut (selon l'objet du ping) mettre le TTL de l'étiquette la plus interne à 1 pour empêcher la requête d'aller trop loin. Des exemples où cela SHOULD être fait incluent le ping d'un préfixe VPN IPv4 ou IPv6, d'un point de terminaison L2 VPN ou d'un pseudofil. Empêcher la requête d'aller trop loin peut aussi se faire en insérant une étiquette Router Alert sur l'étiquette ; mais cela a l'effet de bord indésirable que le MPLS echo request peut emprunter un chemin de données différent de celui des données réelles. Pour l'usage de ces mécanismes dans la vérification de connectivité des pseudofils, voir [VCCV].

En mode "ping" (vérification de connectivité de bout en bout), le TTL de l'étiquette externe est mis à 255. En mode "traceroute" (isolement des défaillances), le TTL est successivement mis à 1, 2, etc.

L'émetteur choisit Sender's Handle et Sequence Number. Lors de l'envoi d'echo request ultérieurs, il SHOULD incrémenter Sequence Number de 1. Mais l'émetteur MAY envoyer un groupe d'echo request avec le même Sequence Number pour accroître la probabilité qu'au moins un paquet avec ce Sequence Number arrive.

TimeStamp Sent est mis à l'heure d'envoi (secondes et microsecondes). TimeStamp Received est mis à zéro.

Un MPLS echo request MUST avoir un TLV FEC Stack. De plus, le mode de réponse MUST être celui souhaité ; le code et le sous-code de retour sont mis à zéro. En mode "traceroute", l'echo request SHOULD contenir un TLV Downstream Mapping.

4.4. Réception d'un MPLS Echo Request (Receiving an MPLS Echo Request)

Le renvoi d'un MPLS echo request au plan de contrôle est déclenché par une des exceptions de traitement suivantes : option Router Alert, expiration du IP TTL, expiration du MPLS TTL, étiquette Router Alert MPLS, ou adresse de destination dans 127/8. Le plan de contrôle identifie en outre le message par le port UDP de destination 3503.

Pour compte rendu, le fond de la pile est considéré comme la profondeur de pile 1. Cela établit une référence absolue pour le cas où la pile réelle contient plus d'étiquettes que les FEC de la pile FEC cible.

En outre, dans tous les codes d'erreur listés, la profondeur de pile 0 signifie "valeur non spécifiée", pour compatibilité avec les implémentations existantes n'utilisant pas le champ de sous-code de retour.

Le LSR X recevant un MPLS echo request traite comme suit :

1. Vérifier la validité globale du paquet. Si le paquet est mal formé, le LSR X SHOULD envoyer un MPLS Echo Reply avec le code de retour "Malformed echo request received", sous-code 0. S'il y a un TLV non marqué "Ignore" et non compris par X, X SHOULD envoyer un "TLV not understood" MPLS approprié, sous-code 0 ; dans ce dernier cas, inclure ces TLV non compris uniquement comme sous-TLV dans le TLV Errored TLVs de la réponse. Les champs Sender's Handle, Sequence Number et Timestamp Sent ne sont pas vérifiés mais sont inclus dans le message echo reply.

L'algorithme utilise les variables et identifiants suivants :

• Interface-I : interface ayant reçu l'echo request.
• Stack-R : pile d'étiquettes à la réception.
• Stack-D : pile d'étiquettes portée par le TLV Downstream Mapping (pas nécessairement présente).
• Label-L : étiquette en cours de vérification dans la pile réelle. Non initialisé.
• Label-stack-depth : profondeur d'étiquette en cours de vérification. Initialisée au nombre d'étiquettes dans la pile reçue S.
• FEC-stack-depth : profondeur du FEC dans la pile FEC cible appliquée à la vérification de l'étiquette réelle courante. Non initialisé.
• Best-return-code : meilleur code de retour echo reply connu à ce jour. Peut changer avec les vérifications.
• Best-rtn-subcode : comme Best-return-code mais pour le sous-code echo reply.
• FEC-status : valeur renvoyée par l'algorithme de vérification FEC de la section 4.4.1.

2. Si l'echo request est bon, X stocke l'interface dans Interface-I et la pile dans Stack-R.

3. Validation des étiquettes (Label Validation) :

   Si Label-stack-depth est 0 : mettre FEC-stack-depth à 1, Label-L à 3 (Implicit Null) ; mettre Best-return-code à 3 ("Replying router is an egress for the FEC at stack depth"), Best-rtn-subcode à la valeur FEC-stack-depth (1), aller à l'étape 5.

   Sinon, extraire Label-L de Stack-R à la profondeur Label-stack-depth, chercher dans la table ILM si l'étiquette est allouée et associée à une opération. S'il n'y a pas d'entrée pour L : mettre Best-return-code à 11 ("No label entry at stack-depth"), Best-rtn-subcode à Label-stack-depth, aller à l'étape 7. Sinon, récupérer l'opération d'étiquette associée et aller à l'étape 4.

4. Vérification de l'opération d'étiquette (Label Operation Check) :

   Si l'opération est "Pop and Continue Processing" (y compris les étiquettes Explicit Null et Router Alert) : décrémenter Label-stack-depth et itérer vers l'étiquette suivante, retour à l'étape 3.

   Si l'opération est "Swap or Pop and Switch based on Popped Label" : mettre Best-return-code à 8 ("Label switched at stack-depth"), Best-rtn-subcode à Label-stack-depth pour signaler la commutation de transit. Si l'echo request reçu contient un TLV Downstream Mapping : si l'adresse IP du TLV est 127.0.0.1 ou 0::1, mettre Best-return-code à 6 ("Upstream Interface Index Unknown"), la réponse SHOULD contenir un TLV Interface and Label Stack rempli avec Interface-I et Stack-R. Sinon, vérifier que l'adresse IP, l'adresse d'interface et la pile d'étiquettes du TLV correspondent à Interface-I et Stack-R ; en cas de non-correspondance, mettre Best-return-code à 5 ("Downstream Mapping Mismatch"), la réponse SHOULD contenir un TLV Interface and Label Stack basé sur Interface-I et Stack-R, aller à l'étape 7. Pour chaque chemin ECMP aval disponible : récupérer l'interface de sortie de l'entrée NHLFE ; si l'interface de sortie n'a pas MPLS activé, mettre Best-return-code à 9 ("Label switched but no MPLS forwarding at stack-depth"), Best-rtn-subcode à Label-stack-depth, aller à Send_Reply_Packet. Si un TLV Downstream Mapping est présent, la réponse SHOULD contenir un TLV rempli avec les informations du chemin ECMP courant. S'il n'y a pas de TLV Downstream Mapping, ou si l'adresse IP aval est l'adresse multicast ALLROUTERS, aller à l'étape 7. Si le drapeau "Validate FEC Stack" n'est pas positionné et le LSR n'est pas configuré pour exécuter la vérification FEC par défaut, aller à l'étape 7.

   Déterminer FEC-stack-depth : parcourir Stack-D du TLV du fond vers le haut, décrémenter le nombre d'étiquettes pour chaque étiquette non Implicit Null, et incrémenter FEC-stack-depth pour chaque étiquette ; s'il y a une ou plusieurs étiquettes Implicit Null, FEC-stack-depth peut être supérieur à Label-stack-depth. Mettre FEC-stack-depth à 0, i à Label-stack-depth ; tant que i>0 : ++FEC-stack-depth ; si Stack-D[FEC-stack-depth]!=3 (Implicit Null) alors --i. Si le nombre d'étiquettes dans la pile FEC >= FEC-stack-depth, exécuter la procédure de vérification FEC 4.4.1 ; si FEC-status est 2, mettre Best-return-code à 10 ; si le code de retour est 1, mettre Best-return-code à FEC-return-code, Best-rtn-subcode à FEC-stack-depth. Aller à l'étape 7.

5. Traitement de sortie (Egress Processing) : si l'echo request reçu ne contient pas de TLV Downstream Mapping, ou si l'adresse IP aval est 127.0.0.1 ou 0::1, aller à l'étape 6. Vérifier que l'adresse IP, l'adresse d'interface et la pile d'étiquettes du TLV correspondent à Interface-I et Stack-R ; en cas de non-correspondance, mettre Best-return-code à 5, la réponse SHOULD créer un TLV Received Interface and Label Stack, aller à l'étape 7.

6. Validation FEC de sortie (Egress FEC Validation) : boucler sur tous les éléments de la pile FEC cible à partir de FEC-stack-depth. Exécuter la vérification FEC de la section 4.4.1 sur Label-L et le FEC à FEC-stack-depth ; mettre Best-return-code à FEC-code, Best-rtn-subcode à la valeur FEC-stack-depth. Si FEC-status est 1, aller à l'étape 7. ++FEC-stack-depth ; si FEC-stack-depth > nombre de FEC dans la pile, aller à l'étape 7. Si FEC-status est 0 : ++Label-stack-depth ; si Label-stack-depth > nombre d'étiquettes dans Stack-R, aller à l'étape 7 ; Label-L = étiquette extraite de Stack-R à la profondeur Label-stack-depth ; retour à l'étape 6.

7. Envoi du paquet de réponse (Send Reply Packet) : envoyer un MPLS echo reply avec le code Best-return-code et le sous-code Best-rtn-subcode, incluant tous les TLV créés. La procédure d'envoi est à la section 4.4.1.

4.4.1. Validation FEC (FEC Validation)

Cette section décrit la validation d'un élément FEC de la pile FEC cible, prenant FEC, Label-L et Interface-I. Étapes :

1. Initialiser les deux valeurs de retour FEC-status et FEC-return-code à 0.
2. Si le FEC est Nil FEC : si Label-L est Explicit_Null ou Router_Alert, retourner. Sinon, mettre FEC-return-code à 10, FEC-status à 1, retourner.
3. Vérifier la correspondance d'étiquettes FEC décrivant comment le trafic reçu sur le LSP est ensuite commuté ou associé à quelle application. S'il n'y a pas de correspondance, mettre FEC-return-code à 4 ("Replying router has no mapping for the FEC at stack-depth"), FEC-status à 1, retourner.
4. Si la correspondance du FEC est Implicit Null, mettre FEC-status à 2 et aller à l'étape 5. Sinon, si la correspondance du FEC est Label-L, aller à l'étape 5. Sinon, mettre FEC-return-code à 10, FEC-status à 1, retourner.
5. Vérification de protocole : vérifier le protocole utilisé pour annoncer le FEC. Si l'on peut déterminer que le protocole associé à Interface-I n'annoncera pas ce type de FEC, mettre FEC-return-code à 12 ("Protocol not associated with interface at FEC stack-depth"), FEC-status à 1.
6. Retourner.

4.5. Envoi d'un MPLS Echo Reply (Sending an MPLS Echo Reply)

Un MPLS echo reply est un paquet UDP. Il MUST être envoyé uniquement en réponse à un MPLS echo request. L'adresse IP source est une adresse routable du répondant ; le port source est le port UDP bien connu de LSP ping. L'adresse IP et le port UDP de destination sont copiés depuis la source de l'echo request. Le IP TTL est mis à 255. Si le mode de réponse de la requête est "Reply via an IPv4 UDP packet with Router Alert", l'en-tête IP MUST contenir l'option Router Alert ; si la réponse est envoyée via un LSP, l'étiquette la plus haute MUST être l'étiquette Router Alert (1) [LABEL-STACK].

Le format de l'echo reply est identique à celui de l'echo request. Sender's Handle, Sequence Number et TimeStamp Sent sont copiés de la requête ; TimeStamp Received est mis à l'heure de réception (utile si les horloges sont synchronisées). Le TLV FEC Stack de la requête MAY être copié dans la réponse.

Le répondant MUST remplir le code et le sous-code de retour déterminés ci-dessus.

Si la requête contient un TLV Pad, le répondant MUST interpréter le premier octet indiquant comment répondre.

Si le routeur répondant est la destination du FEC, la réponse SHOULD NOT contenir de TLV Downstream Mapping.

Si la requête contient un TLV Downstream Mapping et le répondant n'est pas la destination du FEC, il SHOULD calculer ses routeurs aval et les étiquettes d'entrée correspondantes, et ajouter un TLV Downstream Mapping pour chaque routeur aval dans la réponse renvoyée.

Si le traitement des informations de multipath du TLV Downstream Mapping dépasse ce que le routeur récepteur accepte, il MAY ne répondre qu'avec un sous-ensemble des multipaths de la requête. (Note : l'initiateur MAY envoyer une autre echo request avec les informations de multipath absentes de la réponse.)

Sauf mode de réponse 4 ("Reply via application level control channel"), l'echo reply est toujours envoyé dans le contexte du réseau IP/MPLS.

4.6. Réception d'un MPLS Echo Reply (Receiving an MPLS Echo Reply)

Le LSR X ne SHOULD recevoir que des réponses à ses propres echo request. Aussi, à la réception d'un echo reply, X analyse le paquet, vérifie sa validité, puis tente de l'associer à une echo request envoyée via le port UDP de destination et le Sender's Handle. S'il n'y a pas correspondance, X ignore la réponse ; sinon il vérifie le Sequence Number.

Si la réponse contient une correspondance aval et que X veut poursuivre le traceroute, il SHOULD copier la correspondance aval dans sa prochaine echo request (TTL incrémenté de 1).

4.7. Problème des préfixes VPN IPv4 et IPv6 (Issue with VPN IPv4 and IPv6 Prefixes)

Habituellement, le LSP ping d'un préfixe VPN IPv4 ou IPv6 est envoyé avec une pile d'étiquettes de profondeur > 1, le TTL de l'étiquette la plus interne à 1, pour s'arrêter au PE de sortie avant d'atteindre l'équipement client. Mais dans certains cas, la pile peut se réduire à une seule étiquette avant d'atteindre le PE de sortie ; cela termine le ping prématurément. Un exemple est le VPN Carrier's Carrier à plusieurs AS.

Pour contourner cela, une méthode est que le LSR recevant un tel ping réalise l'arrêt prématuré et renvoie le code d'erreur 13. L'initiateur peut alors réessayer le ping en incrémentant le TTL de l'étiquette VPN. Ainsi, le LSR d'entrée essaiera successivement les valeurs de TTL jusqu'à trouver celle permettant au VPN ping d'atteindre le PE de sortie.

4.8. Routeurs non conformes (Non-compliant Routers)

Si la sortie de la pile FEC pingée ne prend pas en charge LSP ping, aucune réponse n'est envoyée, ce qui peut donner un "faux négatif". En mode "traceroute", si un LSR de transit ne prend pas en charge LSP ping, il ne répond pas pour certains TTL (disons n). Le LSR ayant envoyé la requête SHOULD envoyer des echo request avec TTL=n+1, n+2, ..., n+k pour sonder les LSR plus aval. Dans ce cas, pour les echo request de TTL>n, jusqu'à réception d'une réponse contenant un TLV Downstream Mapping, il SHOULD envoyer le champ "Downstream IP Address" du TLV mis à l'adresse multicast ALLROUTERS. La pile d'étiquettes MAY être omise du TLV. De plus, jusqu'à réception d'un echo reply contenant un TLV Downstream Mapping, il SHOULD NOT positionner le drapeau "Validate FEC Stack".