Le paquet est arrivé. Son heure de passage était déjà révolue.

Résumé

• RFC 5143 est une spécification Historic d’émulation de circuits SONET/SDH sur MPLS ; toute nouvelle implémentation doit employer RFC 4842.
• Son en-tête CEM de 32 bits porte les états DBA et de défaut distant, un numéro de séquence, un pointeur de structure, des bits d’ajustement et ECC-6.
• ECC-6 corrige une erreur d’un bit et en détecte jusqu’à deux dans l’en-tête, mais ne protège pas la charge utile du circuit.
• Un en-tête valide ou réparé ne recrée pas un paquet perdu, ne résout pas le désordre et ne remplit pas le tampon de gigue.
• La perte se décide au moment de la restitution, lorsque le récepteur sait enfin si les octets sont arrivés avant l’échéance du circuit.
• Les numéros de séquence révèlent pertes et désordre ; faute de réordonnancement, les paquets désordonnés sont éliminés et remplacés par un motif configuré.
• Une perte de synchronisation provoque CEM-RDI vers le réseau de paquets et AIS-P vers le circuit structuré.
• La DBA peut supprimer volontairement la charge tout en conservant la cadence, de sorte qu’un flux de paquets ne prouve pas la présence de données client.
• La récupération d’horloge reste autonome : l’en-tête ne certifie ni fréquence, ni phase, ni gigue, ni dérapage temporel.
• L’ancien format pouvait ressembler à IPv4 et déclencher un ECMP fondé sur la charge, créant gigue et désordre hors de portée d’ECC.
• Sa sécurité ne dépasse pas celle du réseau de paquets et peut être inférieure au TDM natif ; ECC n’authentifie ni l’émetteur ni la provenance.
• La direction doit exiger des reçus distincts pour l’en-tête, l’ordre, le tampon, le temps, les alarmes et la sortie réellement fournie.

La ponctualité transforme le sens de « reçu »

Un réseau de paquets peut établir qu’une unité a été reçue à une interface. Un circuit synchrone pose une question plus dure : les octets étaient-ils disponibles au moment exact où l’interface devait les émettre ? Après cette échéance, le paquet reste observable, mais il n’est plus utile au créneau qu’il devait remplir.

Supposons qu’un bit de l’en-tête ait changé. ECC-6 le corrige. Le numéro de séquence redevient lisible, le pointeur retrouve sa cohérence et le parseur conclut à un succès. Pourtant, le paquet précédent manque au bord de restitution. Plusieurs absences consécutives franchissent le seuil configuré. Le récepteur perd la synchronisation et produit AIS-P au lieu de prétendre que la charge est valable.

Ce résultat n’invalide pas le code correcteur. Il montre seulement la taille de sa compétence. L’erreur de gouvernance consiste à étendre cette réussite locale jusqu’à la continuité du service, comme si un champ réparé détenait une autorité sur le chemin, le tampon, l’horloge et le client.

Un petit en-tête pour une fonction commune limitée

Les 32 bits de RFC 5143 contiennent le strict nécessaire à l’interprétation partagée. D décrit l’allocation dynamique de bande passante. R signale un défaut distant CEM. Le numéro de séquence sur dix bits tourne de 0 à 1023. Le pointeur de structure situe le début de l’enveloppe synchrone ; N et P servent aux ajustements de pointeur et à certaines indications d’alarme ; six bits portent ECC-6.

Ce registre ne prétend pas raconter tout le circuit. Il n’énumère pas l’historique des arrivées, la profondeur du tampon distant, la qualité de l’horloge reconstruite ou l’état de l’équipement client. Cette sobriété est saine : la couche commune ne devrait contenir que les invariants nécessaires à l’interopérabilité.

L’annexe B précise le périmètre d’ECC-6. Une matrice de contrôle produit un syndrome qui autorise la correction d’un bit et la détection de deux. Le dispositif peut être désactivé lors du provisionnement, auquel cas le champ vaut zéro. Il protège l’en-tête CEM, non les octets SONET/SDH. Aucune lecture raisonnable ne permet d’y voir une récupération de charge ou une attestation de service.

Le numéro de séquence ouvre l’enquête, il ne la clôt pas

Connaître le prochain numéro attendu permet de voir un trou, un doublon ou une inversion. Cela ne reconstitue pas le contenu absent. RFC 5143 impose au dépaquétiseur de détecter les pertes et le désordre. Il peut remettre les paquets dans l’ordre. S’il ne le fait pas, il doit éliminer les paquets désordonnés. Un motif d’octets programmable remplace les données absentes ou rejetées.

Le circuit peut donc continuer à émettre un signal cadencé alors que la charge d’origine n’existe plus. Cette continuité physique évite un comportement encore plus brutal, mais elle n’est pas une continuité sémantique. Un port actif peut transporter une indication de maintenance parfaitement régulière.

La synchronisation de paquets dépend d’une séquence dans le temps. Au démarrage, le récepteur est hors synchronisation. Il exige un nombre configurable de paquets séquentiels avant de déclarer l’acquisition. Il perd cet état après une série configurable de paquets absents ou vides. Aucun en-tête isolé, même impeccable, ne suffit.

La décision de perte attend la restitution. Avant celle-ci, une absence peut encore être un retard. À l’échéance, le système sait si le paquet entier a rejoint le tampon à temps. C’est le point où un événement réseau devient une conséquence de service.

Le tampon de gigue participe au résultat

Le réseau livre de manière irrégulière ; le circuit consomme à cadence fixe. Le tampon de gigue CEM absorbe cette différence. Sa profondeur doit pouvoir être ajustée aux variations du chemin, et le débit moyen d’arrivée doit équilibrer la restitution sur la période que représente le tampon.

Deux flux ayant le même nombre de paquets peuvent alors produire deux circuits différents. Une rafale tardive sature un petit tampon. Une pause le vide. Un tampon plus profond tolère davantage de variation, mais ajoute du délai. Un paquet inscrit comme reçu dans la télémétrie peut être éliminé comme trop tardif pour le service.

Une preuve sérieuse conserve donc les paquets reçus, ceux effectivement restitués, les retards, les remplacements, les sous-alimentations, les débordements et l’état de synchronisation. RFC 4842, qui remplace RFC 5143 sur la voie normative, sépare lui aussi les paquets manquants ou éliminés des défauts de tampon et de la perte de synchronisation. La forme change ; la séparation causale demeure.

La DBA entretient le rythme sans prétendre transporter le contenu

Sous AIS-P ou lorsque la charge SONET/SDH est déclarée non équipée, la DBA peut supprimer entièrement la charge CEM. En-tête, labels et encapsulation continuent de circuler. Leur cadence reste équivalente au fonctionnement normal afin de stabiliser le tampon et d’éviter de confondre cette condition avec une panne du réseau de paquets.

Un graphe régulier peut donc représenter l’absence organisée de données utilisateur. Le mécanisme ne ment pas : D et les états associés donnent le contexte. C’est la simplification du système de supervision qui ment lorsqu’elle transforme paquets présents en service présent.

RFC 5143 demande en outre que le déclenchement repose sur les informations d’overhead SONET/SDH, non sur la reconnaissance hasardeuse d’un motif dans la charge. La provenance du signal compte. Une décision dérivée d’un état explicite n’a pas la même valeur qu’une supposition fondée sur le contenu.

La parité ne remet pas une horloge à l’heure

Le bord de sortie doit régénérer l’horloge du service entrant. Les modes synchrone et asynchrone sont provisionnés, et les deux extrémités doivent correspondre. Pour un service structuré synchrone, les bits N/P portent des ajustements ; les séquences empêchent qu’un ajustement dupliqué ou remis dans le désordre soit appliqué plusieurs fois.

Ce mécanisme ne garantit pas la qualité temporelle finale. En mode asynchrone, une récupération adaptative peut être employée, mais son algorithme reste largement local. RFC 4842 conserve cette autonomie tout en exigeant le respect des limites applicables de gigue et de dérapage.

Une suite de numéros parfaite peut conduire à une fréquence erronée. Un débit moyen stable peut masquer une gigue brève mais excessive. Une horloge verrouillée peut cadencer une alarme au lieu de données. La mesure doit donc avoir lieu sur l’interface reconstruite.

Quand l’ancien en-tête ressemblait à IPv4

Le format historique possède une faiblesse révélatrice. Certaines valeurs initiales D et R peuvent faire ressembler son premier demi-octet à IPv4. Un équipement qui inspecte le contenu supposé pour calculer un chemin ECMP risque alors de répartir les paquets d’une même pseudowire sur plusieurs routes. RFC 4928 décrit la gigue et le désordre qui en résultent. Le format de RFC 4842 évite cette violation du mot de contrôle.

L’en-tête peut rester intègre pendant que le réseau modifie son ordre et son délai. ECC sait parler des bits qu’il couvre, pas de la décision de transit qui les a déplacés. Voilà pourquoi RFC 5143 doit rester un objet d’analyse de compatibilité historique. Le document est Historic et impose RFC 4842 aux nouvelles implémentations.

Six reçus pour une seule promesse de service

Le premier reçu décrit l’en-tête : valide, corrigé, détecté mais non corrigé, ou transmis sans ECC. Le deuxième décrit les paquets : trous, doublons, inversions et remise en ordre. Le troisième appartient au tampon : arrivée avant échéance, restitution, sous-alimentation, débordement, synchronisation. Le quatrième mesure le temps : fréquence, phase, gigue et dérapage. Le cinquième conserve les états de maintenance et leur origine : AIS-P, CEM-RDI, Unequipped, DBA. Le sixième observe la sortie : des données utilisateur valides ont-elles réellement atteint l’équipement attaché ?

Leur séparation accélère le diagnostic. Une hausse des corrections désigne une qualité de liaison. Des séquences propres avec un tampon vide désignent le rythme ou la variation de délai. Des paquets corrects et une mauvaise horloge désignent la récupération temporelle. Une DBA régulière avec AIS-P désigne une condition de ligne, pas un silence de transport.

Sources

1. RFC 5143, HTML
2. RFC 5143, texte
3. Notice RFC Editor
4. IETF Datatracker
5. Historique du document
6. Recherche d’errata RFC 5143
7. Paramètres Pseudowire de l’IANA
8. RFC 4842 : Circuit Emulation over Packet
9. RFC 4553 : Structure-Agnostic TDM over Packet
10. RFC 5086 : Structure-Aware TDM Circuit Emulation
11. RFC 4447 : établissement des pseudowires par LDP
12. RFC 4385 : mot de contrôle Pseudowire
13. RFC 4928 : éviter le traitement ECMP dans MPLS
14. RFC 3985 : architecture Pseudowire Emulation
15. RFC 4023 : encapsulation de MPLS dans IP ou GRE
16. RFC 5085 : vérification de connectivité Pseudowire
17. RFC 6374 : mesure de perte et de délai MPLS
18. Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption
19. On Reality Layers, Symbolic Power, and Why Clarity Feels So Hostile
20. Running-Code Primacy