Résumé

  • Lorsqu’un paquet PLE manque ou doit être rejeté, RFC 9801 impose de remplacer sa charge par la même quantité de données. Le motif 0xAA doit être disponible par défaut.
  • Cette alternance de zéros et de uns entretient la synchronisation et évite des en-têtes 64B/66B invalides pendant le maintien d’horloge. Elle ne reconstitue pas l’information disparue.
  • Un dossier opposable distingue la réception, le trou de séquence, la décision de remise en ordre, la substitution, l’état d’horloge, les alarmes PLOS/DEG et l’effet réellement observé par le client.

Imaginons une baie où le voyant « signal » reste vert. Le port de sortie délivre toujours des bits au bon rythme ; aucun défaut de codage ne rompt la trame physique. Pourtant, pendant quelques centaines de microsecondes, la sortie ne reproduit rien de ce qui est entré à l’autre extrémité. Elle émet un motif local : 10101010.

Ce paradoxe est au cœur de RFC 9801, norme proposée de juillet 2025 consacrée à l’émulation de lignes privées sur des réseaux à paquets. L’obligation n’est pas de deviner les données perdues. Elle est de fournir exactement autant de données de remplacement que la charge absente, afin que le service synchrone ne se désagrège pas faute de cadence.

Le procédé est rationnel. La confusion commence lorsque la continuité électrique devient, dans un tableau de bord ou un contrat, une preuve de fidélité informationnelle.

Deux temporalités se rencontrent au bord

Le monde du paquet accepte l’irrégularité : retard variable, réordonnancement, parfois perte. Le monde d’une ligne synchrone exige qu’un bit soit présenté à chaque instant prévu. L’Interworking Function de RFC 9801 se place exactement sur cette couture. Elle paquetise le flux entrant dans des charges fixes, l’achemine dans un VPWS puis reconstitue le flux à l’autre bord, dans le cadre PWE3 de RFC 3985.

La taille est convenue pour toute la durée du VPWS et doit être identique dans les deux sens ; 1 024 octets constituent la capacité minimale commune. Le mot de contrôle suit RFC 4385 et contient un numéro de séquence qui progresse à chaque paquet. Ce numéro peut constater une place vide. Il n’explique ni congestion, ni route erronée, ni attaque, ni défaut de lien.

RFC 9801 ajoute un en-tête RTP pour transmettre le temps. Il reprend les règles utiles de RFC 3550, sans prétendre fournir RTCP, SRTP ou toute la sémantique multimédia. Jusqu’à 200 Gbit/s, l’horloge de timestamp vaut 125 MHz ; au-delà, 250 MHz. Le modèle relatif de RFC 4197 transporte l’écart entre l’horloge du circuit d’accès et une référence commune.

Le timestamp aide à savoir quand émettre. Il ne révèle pas ce qu’aurait contenu une charge disparue.

Le tampon décide quand une arrivée devient une perte

Le récepteur doit disposer d’un tampon de dé-gigue. Son volume transforme la variation de délai en temps d’attente. Un paquet arrivé hors ordre peut être remis en place ; si cette capacité n’existe pas, le paquet doit être jeté. Ainsi, un paquet authentique mais trop tardif peut subir le même sort qu’un paquet jamais arrivé.

Le remplissage initial typique mentionné par RFC 9801 est la moitié du tampon. Ce point laisse de la marge lorsque le délai augmente comme lorsqu’il diminue. Il révèle aussi un arbitrage que les indicateurs simplistes masquent : davantage de tampon tolère plus de variation mais accroît la latence ; moins de tampon accélère la sortie mais transforme plus d’arrivées tardives en pertes et en substitution.

Lorsque la charge manque, l’IWF doit produire la même longueur. Le contenu est configurable, mais tout équipement doit savoir générer 0xAA. Pour les services 64B/66B, l’alternance évite de fabriquer un en-tête de synchronisation invalide. Le mécanisme de holdover maintient l’horloge.

Voilà pourquoi il faut conserver plusieurs reçus :

Trace Portée exacte
paquet PLE reçu cette charge et cette identité de transport ont été observées
rupture de séquence une position attendue manquait au moment de décider
rejet ou remise en ordre la politique locale a conservé ou écarté une arrivée tardive
intervalle remplacé la sortie a utilisé des octets produits localement
horloge récupérée la cadence mesurée a respecté un référentiel déclaré
signal de maintenance une couche native a reçu une indication bornée
observation cliente une application nommée a subi un effet mesuré

Le remplacement ne falsifie pas la ligne : il accomplit la fonction définie. C’est le journal qui devient trompeur s’il ne marque pas l’origine synthétique de l’intervalle.

L et R ne racontent pas la même panne

Le bit L annonce que la charge transportée n’est pas valide à cause d’un défaut du circuit d’accès côté émetteur. Le bord distant doit alors fournir des données appropriées de remplacement et peut injecter le signal de défaut propre au service. Le bit R remonte dans l’autre sens : l’IWF destinataire subit une perte dans le réseau à paquets ou une indication de défaut arrière issue d’une couche serveur.

Ces deux bits ont une direction, un émetteur et une portée. Ils ne contiennent aucune donnée manquante. Ils ne prouvent pas qu’un équipement client a compris le signal de maintenance. Ils ne désignent pas automatiquement la cause initiale.

Au-delà d’un intervalle configurable de pertes consécutives—une milliseconde par défaut—l’IWF déclare PLOS. Une perte excessive sur des fenêtres successives déclare DEG ; RFC 9801 décrit comme valeurs par défaut 15 % durant sept intervalles d’une seconde. La première absence, la déclaration de défaut et la réaction native sont donc trois événements horodatables, pas un seul état.

Les compteurs ES-PLE, SES-PLE et UAS-PLE organisent ensuite l’observation. Une seconde comportant au moins une perte, PLOS ou DEG est erronée. Plus de 15 % de perte, PLOS ou DEG la rend gravement erronée. Une série configurable, dix secondes par défaut, fait entrer ou sortir de l’indisponibilité. Mais la surveillance du circuit d’accès reste spécifique au service et hors du périmètre de RFC 9801. Un compteur PLE ne dit pas combien de trames Ethernet utiles, de transactions Fibre Channel ou d’unités OTN le client a effectivement perdues.

Les prédécesseurs éclairent le choix, pas le résultat

RFC 4553, RFC 5086 et RFC 4842 décrivent des formes antérieures d’émulation de circuits synchrones. Ils expliquent l’héritage des numéros de séquence, des timestamps et des données de remplacement. RFC 9801 étend cette logique à une gamme beaucoup plus large de débits et de codages.

Le trafic reste inélastique. Il ne peut pas ralentir comme une session TCP lorsque le réseau est encombré, contrairement à l’objectif de RFC 2914. Il faut donc un réseau suffisamment peu chargé et peu variable, grâce à la qualité de service, à l’ingénierie de trafic, à l’admission ou au surdimensionnement. La méthode concrète reste hors périmètre.

La sécurité repose elle aussi sur des étages distincts. L’émulation n’ajoute ni chiffrement, ni intégrité, ni authentification ; elle suppose un domaine MPLS ou SRv6 isolé et reprend les recommandations de RFC 5920. Les attaques par injection, retard, réordonnancement ou perte décrites comme risques de plans de données déterministes dans RFC 9055 peuvent dépasser le tampon. Les menaces sur PTP et la manipulation du délai documentées par RFC 7384 rappellent qu’une horloge stable n’authentifie pas les données.

La fiche RFC Editor, le registre des errata et l’historique IETF attestent l’état du document. Le registre IANA PWE3 atteste des allocations. RFC 8214 décrit EVPN-VPWS, tandis que RFC 9801 laisse ses extensions de signalisation hors périmètre. Aucune de ces sources ne prouve qu’une ligne donnée a bien fonctionné.

Les versions texte et XML permettent de vérifier précisément la règle. Elles ne rendent pas visibles les octets remplacés chez un opérateur particulier.

Le principe de contrôle est donc sobre : la continuité est une action de protection ; la fidélité est une affirmation à démontrer. Plus le mécanisme de protection rend la sortie propre, plus la trace de substitution doit rester lisible.

Sources