Résumé

  • Le RFC 3429 attribue la valeur MPLS réservée 14 à l’OAM Alert Label, sans confondre cette identification avec les fonctions détaillées par la recommandation Y.1711 de l’UIT-T.
  • Avec le PHP, le routeur précédent pouvait retirer le label supérieur tout en conservant le label OAM et sa charge utile jusqu’à une sortie MPLS capable de traiter l’OAM. Un équipement qui ne sait pas traiter les labels relève d’un autre cas, laissé à l’étude.
  • Le TTSI conservé dans le paquet aide à identifier le LSR d’entrée. Il ne prouve ni la santé du LSP, ni la livraison du trafic client, ni le traitement d’une alarme.

Une sortie MPLS peut demander à son voisin amont de retirer le label de transfert avant que le paquet arrive. Ce mécanisme, appelé penultimate-hop popping (PHP), évite à la sortie une opération de commutation supplémentaire. La demande est signalée par le label implicit-null, valeur 3 : ce label de contrôle est distribué, mais n’apparaît jamais dans l’encapsulation. Le bénéfice est net pour le transfert ordinaire. Pour l’exploitation, une question subsiste : comment la sortie distingue-t-elle un paquet d’OAM une fois le label supérieur supprimé ?

Le RFC 3429 répond par une affectation précise. Il désigne la valeur 14, jusque-là réservée dans l’encodage de pile défini par le RFC 3032, comme « OAM Alert Label ». Celle-ci identifie un paquet OAM du plan utilisateur. Elle ne définit pas à elle seule les opérations de continuité, de défaut ou de performance, et ne promet pas qu’un équipement donné les exécutera.

Une séparation entre trois textes

Le partage des responsabilités importe autant que le numéro. La recommandation Y.1711 de l’UIT-T décrit les fonctions et la charge utile de l’OAM MPLS. Le RFC 3031 pose l’architecture MPLS et le PHP. Le RFC 3429 réserve un label que les équipements compatibles peuvent reconnaître pour séparer ce trafic de contrôle du trafic utilisateur.

Dans le cas PHP que le RFC juge applicable, le nœud de sortie reste un LSR MPLS avec plans de contrôle et de données. Il sollicite le PHP parce qu’il ne peut réaliser deux recherches de label à la cadence voulue. Le LSR pénultième retire le label supérieur, mais transmet le label OAM et la charge utile sans les altérer. À l’arrivée, une sortie prenant en charge l’OAM voit le label 14 au sommet de la pile restante et sait qu’elle doit traiter un paquet de maintenance.

Le TTSI (Trail Termination Source Identifier), transporté dans la charge utile OAM, lui indique le LSR d’entrée à l’origine du paquet. C’est une solution de continuité d’identité après la disparition du label de transfert. Ce n’est pas une mesure de bout en bout : le TTSI ne démontre pas que chaque saut a transmis le trafic client, que le chemin retour fonctionne, ni que le service final a répondu.

Le même PHP, deux capacités de sortie

Le point décisif du RFC est la séparation de deux situations souvent rangées sous la même étiquette. Dans le premier cas, l’équipement de sortie traite MPLS mais demande à son voisin de retirer le label pour alléger son traitement. Il peut encore reconnaître et analyser le label OAM qui reste. Y.1711 s’applique à ce scénario.

Dans le second, le nœud final ne possède aucune capacité de recherche ou de traitement des labels MPLS. Il demande également le PHP, mais il ne devient pas pour autant un terminal d’OAM. Le RFC précise que les fonctions Y.1711 de l’époque ne couvraient que le premier cas. Le second restait à étudier, de même que les scénarios de carrier supporting carrier. La ressemblance du signal de contrôle ne signifie donc pas que les deux sorties possèdent les mêmes facultés.

Cette distinction évite un faux diagnostic. Si la sortie ne produit aucune observation, on ne peut conclure directement que le LSP est sain, ni que le PHP a rompu le transport. Le document prévoit qu’une sortie sans prise en charge MPLS OAM écarte le paquet. Le RFC 3031 déconseille également de retirer arbitrairement un label inconnu puis de transmettre le contenu comme IP non étiqueté : le label peut porter une signification qui ne se déduit pas de l’en-tête IP. La perte de visibilité demeure, même si l’abandon est plus sûr qu’une interprétation inventée.

Ce que le registre ne garantit pas

Le registre IANA des labels MPLS associe toujours la valeur 14 à OAM Alert Label et au RFC 3429. Cette stabilité donne aux spécifications un vocabulaire commun. Elle n’indique pas quels LSR actuels prennent l’étiquette en charge, si PHP est activé sur un LSP, quels paquets sont filtrés, ni comment un constructeur expose un abandon.

Publié comme RFC Informational en novembre 2002, le texte n’est pas un rapport d’adoption. Son apport historique est plus précis : une recommandation de l’UIT-T définit des fonctions OAM, l’IETF réserve un identifiant de paquet MPLS, puis le RFC circonscrit la frontière de capacité au saut de sortie. Le résultat est une possibilité de reconnaissance partagée, pas une garantie de disponibilité du réseau.

Pour examiner un chemin réel, il faut relier séparément le label annoncé, l’opération effectuée par le LSR pénultième, la pile reçue à la sortie, la prise en charge locale de l’OAM, l’analyse du TTSI et le résultat de la fonction concernée. Il faut ensuite une preuve distincte pour le trafic de service. « Label 14 enregistré », « OAM activé » et « LSP opérationnel » ne sont pas trois formulations équivalentes de la livraison au client.

Sources