Résumé

  • Le RFC 5332 abandonne l’opposition historique entre un EtherType MPLS « unicast » et un autre « multicast ». Sur Ethernet multicast, 0x8847 accompagne un label supérieur assigné en aval et 0x8848 un label supérieur assigné en amont.
  • Cette provenance ne suffit pas à prouver le bon espace de labels, la bonne entrée de réplication, l’acceptation par le destinataire ni la livraison du service. Il faut conserver ces preuves séparément.

Une classification familière, devenue fausse

Le nom d’un codepoint peut survivre à sa signification. Le RFC 3032 avait présenté deux valeurs de couche liaison comme un moyen de distinguer MPLS unicast et MPLS multicast. Le RFC 5332 constate que cet usage multicast n’avait pas été déployé et que les mécanismes développés ensuite demandaient une autre séparation.

La norme ne crée donc pas un troisième numéro. Elle réattribue le sens des deux numéros existants. 0x8848, autrefois appelé codepoint multicast, devient « MPLS avec label assigné en amont » dans les conditions prévues. 0x8847 reste MPLS et peut parfaitement apparaître dans une trame Ethernet multicast.

Un système qui conserve seulement le libellé ancien perd l’événement le plus important : la migration sémantique. Il peut lire les octets sans erreur et attribuer au réseau une propriété qui n’est plus portée par ces octets.

Le multicast se décide dans le contexte du label

Le RFC 5332 définit un label multicast par l’entrée NHLFE à laquelle il mène dans un contexte donné. Cette entrée contient une sémantique de réplication vers un ensemble de prochains sauts. Même si cet ensemble ne compte provisoirement qu’un membre, l’intention reste de répliquer vers tous ses membres.

Le récepteur découvre cette propriété en consultant le label. L’EtherType n’a pas à annoncer une seconde fois « ceci est multicast ». Il indique la provenance d’assignation nécessaire pour savoir comment interpréter le label supérieur sur un support multiaccès.

L’assignation en aval signifie que le récepteur a créé la liaison entre label et FEC puis l’a annoncée à l’émetteur. L’assignation en amont signifie que l’émetteur, ou un tiers, l’a créée. Ces deux chemins d’autorité technique conduisent vers des espaces de labels potentiellement distincts. Le RFC 5331 décrit le contexte requis ; le codepoint du RFC 5332 ne remplace pas ce contexte.

La même valeur change avec le support et l’adresse

Sur Ethernet, une trame unicast MPLS utilise 0x8847. Une trame multicast MPLS utilise elle aussi 0x8847, sauf lorsque son label supérieur a été assigné en amont ; alors elle utilise 0x8848.

Dans GRE, l’adresse IP extérieure devient une autre partie de la règle. Une destination unicast impose 0x8847 dans tous les cas. Une destination multicast associe 0x8847 à l’assignation en aval et 0x8848 à l’assignation en amont.

Pour PPP, le champ protocole reste toujours 0x0281. Pour l’encapsulation MPLS directement dans IP, le numéro de protocole ou Next Header reste 137, que le paquet MPLS ait ou non une sémantique multicast. Une base uniforme qui traite tous ces champs comme le même indicateur binaire détruit précisément les conditions qui donnent leur sens aux valeurs.

Une erreur GRE dépend d’un contrat extérieur

Le RFC 5332 prévoit qu’un tunnel GRE à destination multicast peut être connu, par des procédures extérieures, comme utilisant des labels supérieurs assignés en amont. Dans ce cas, recevoir 0x8847 constitue une erreur et le paquet doit être éliminé.

La formule contient deux preuves. La trame fournit la destination et le codepoint. Une autre source fournit le contrat d’assignation du tunnel. Sans cette seconde source, le moteur de conformité ne sait pas si 0x8847 est la valeur attendue ou l’erreur à rejeter.

Il faut donc versionner le contrat, son origine, son instant d’activation et la preuve de prise en charge par le voisin. Une alerte doit pouvoir montrer quelle règle a rendu la combinaison invalide. « 8847 observé » est une observation ; « invalide sous le contrat E » est un jugement ; « service interrompu » exige encore les décisions du récepteur et le résultat mesuré.

Le suffixe MAC n’est pas une liste de destinataires

Pour Ethernet multicast MPLS, l’adresse de destination suit la forme 01-00-5e-8v-wx-yz. Les vingt bits vwxyz peuvent être nuls ou reprendre la valeur d’un label de la pile. Avec plusieurs labels, la valeur par défaut provient du deuxième ; une configuration peut en choisir un autre. Avec un seul label, celui-ci fournit la valeur.

Les deux méthodes — zéro ou dérivation depuis un label — doivent interopérer. Un équipement ne doit ni rejeter tous les suffixes nuls ni filtrer indistinctement tous les suffixes non nuls. La norme permet d’utiliser l’information supplémentaire pour un filtrage plus fin, mais elle laisse la politique de filtrage hors de son champ.

Il serait donc faux de compter vwxyz comme une identité de récepteur. La valeur ne prouve ni l’adhésion à un groupe, ni l’autorisation, ni la réception. Elle peut refléter un label, et plusieurs états indépendants déterminent ensuite qui reçoit, accepte, réplique et livre.

Connaître la fonction locale ne connaît pas le pair

Les labels assignés en amont sont facultatifs et ne doivent pas être utilisés sans savoir que le LSR en aval les prend en charge. Le RFC 5332 ne normalise pas la méthode par laquelle cette connaissance est acquise.

Une case « fonctionnalité installée » sur l’équipement local ne constitue donc pas le reçu demandé. Il faut une preuve liée au pair, au lien ou au tunnel, à une version et à une durée de validité. Un remplacement de voisin ou une restauration de configuration peut rendre une ancienne preuve obsolète sans changer l’EtherType vu dans une capture.

Le contrôle opérationnel doit rapprocher capacité locale, capacité du pair, contrat d’assignation, contexte du label, pile reçue et décision de recherche. Chacun de ces éléments peut être exact séparément et néanmoins incohérent avec les autres.

Une altération n’annonce pas son résultat

Le RFC 5332 avertit qu’une modification malveillante du codepoint peut provoquer perte ou mauvais acheminement. Mais il précise aussi que modifier le codepoint sans modifier le label n’a pas d’effet prévisible. Une modification de la MAC DA peut conduire la trame vers un tiers.

Cette incertitude est essentielle en réponse à incident. Un codepoint incohérent peut prouver qu’un objet reçu ne respecte pas le contrat. Il ne révèle pas l’auteur, l’intention, l’entrée de label finalement consultée ni le destinataire qui a observé la trame.

Conserver les octets, le point de capture, la direction, les adresses, la pile et la décision du récepteur empêche une hypothèse de devenir une histoire irréversible. Les mots « perte », « mauvais acheminement » et « tiers » désignent des risques à vérifier, pas des résultats automatiquement contenus dans quatre chiffres hexadécimaux.

Le registre coordonne, l’exécution prouve

Une discipline utile consiste à tenir un registre de migration sémantique. Pour chaque numéro partagé, il conserve le document d’autorité, les conditions de support, l’ancien sens déprécié, le sens actuel, les combinaisons invalides et la version du parseur qui applique la règle.

Chaque observation RFC 5332 devrait ensuite garder le support, la classe d’adresse extérieure, le codepoint brut, la pile de labels, le contrat d’assignation, la preuve de capacité du pair, le contexte, le résultat NHLFE, la règle vwxyz, le filtrage, la réplication et la réception.

C’est une architecture de preuve, non une bureaucratie décorative. Elle respecte la primauté du code exécuté : le numéro commun rend l’interopérabilité possible, mais seules les décisions du système vivant et leurs reçus établissent ce qui s’est produit.

Sources