Résumé

  • RFC 6525 permettait de ramener à zéro la séquence d’un ou plusieurs flux SCTP tout en conservant l’association et les flux non désignés.
  • Le champ Sender’s Last Assigned TSN séparait l’ancienne époque de la nouvelle. Tant que le point d’acquittement cumulatif ne l’avait pas atteint, le récepteur répondait « In progress » et retenait les données plus récentes.
  • La demande possédait sa propre séquence de reconfiguration, pouvait être refusée et devait produire la même réponse en cas de répétition : oublier les anciennes séquences exigeait d’abord une mémoire fiable de l’acte d’oubli.

Le zéro ne pouvait pas précéder le passé

Dans SCTP, une association transporte plusieurs flux unidirectionnels. Le RFC 4960 associait à chaque fragment DATA un Transmission Sequence Number valable à l’échelle de l’association, tandis que les messages ordonnés recevaient un Stream Sequence Number dans leur flux. Le RFC 9260 conserve cette séparation : le TSN sert à l’acquittement et à la détection des doublons ; l’ordre applicatif reste local au flux.

Cette architecture autorise deux histoires simultanées. Le flux 3 peut attendre son prochain SSN sans que le flux 8 lui soit subordonné, mais leurs fragments continuent de partager l’espace des TSN. Fermer l’association pour réutiliser un seul flux détruirait beaucoup plus d’état que nécessaire. Remettre son SSN à zéro sans cérémonie serait pire : un ancien fragment retardé pourrait être lu dans le nouvel ordre.

Le RFC 6525, publié en 2012, a introduit le chunk RE-CONFIG. Son objectif n’était pas de faire disparaître les paquets déjà émis. Il permettait à une application de finir un usage du flux, d’en commencer un autre et d’être avertie lorsque la transition avait réellement eu lieu.

La demande dessinait une ligne dans l’espace des TSN

Une Outgoing SSN Reset Request contient un numéro de demande de reconfiguration, un numéro de réponse, le Sender’s Last Assigned TSN et, éventuellement, une liste de flux. Sans liste, tous les flux sortants sont visés. Avec une liste, les autres conservent leur état.

Le dernier TSN attribué n’est pas une estimation temporelle. Il vaut le prochain TSN moins un et identifie la frontière maximale de l’ancienne époque. Avant d’envoyer la demande, l’émetteur cesse d’attribuer de nouveaux SSN aux flux concernés et met les nouveaux messages en attente. Si la demande se perdait tandis que de nouvelles séquences partaient déjà, le pair pourrait les interpréter selon l’ancien régime.

Le récepteur compare cette frontière à son point d’acquittement cumulatif. Si celui-ci est en retard, il entre en traitement différé. Les données des flux concernés dont le TSN dépasse la frontière sont conservées localement ; une réponse « In progress » indique que la demande est comprise, mais que le passé n’est pas encore entièrement comptabilisé.

Quand l’acquittement cumulatif atteint le dernier TSN attribué, les prochains SSN attendus des flux désignés passent à zéro. Les TSN retenus sont libérés, puis une réponse de succès est envoyée. Un flux ne devient donc pas neuf à l’heure choisie par une seule application : il le devient au point où les deux extrémités peuvent distinguer l’ancien du nouveau.

La reconfiguration devait elle-même résister aux répétitions

Les demandes de reconfiguration possèdent un compteur monotone, initialisé à partir du TSN initial. Une réponse reprend le numéro de la demande et annonce un résultat : succès, refus, mauvais SSN, demande déjà en cours, mauvais numéro de séquence ou traitement en cours, entre autres.

Cette seconde chronologie est indispensable. Une retransmission du dernier RE-CONFIG ne doit pas provoquer une nouvelle remise à zéro ; le récepteur renvoie la réponse déjà produite. L’opération qui modifie la numérotation des données s’appuie ainsi sur une numérotation de contrôle indépendante.

« In progress » ne compte pas comme une panne du chemin. Le demandeur relance son temporisateur et peut retransmettre sans augmenter les compteurs d’erreur de l’association. Après un succès, l’émetteur remet à zéro l’état des flux concernés, traite la file d’attente et recommence à attribuer les séquences.

Le pair peut aussi refuser. Le RFC qualifie cette décision d’administrative et admet qu’elle reste configurable après la formation de l’association. Avoir accepté l’association ne signifie donc pas avoir cédé le contrôle de chaque reconfiguration future.

Entrant et sortant n’étaient pas des synonymes

Un flux SCTP est unidirectionnel. Le même numéro dans l’autre sens ne crée pas automatiquement un canal bidirectionnel ; ce lien appartient à l’application. Pour remettre à zéro les séquences que l’on reçoit, il faut demander au pair de réinitialiser ses flux sortants. Le pair contrôle alors la frontière réelle de l’opération.

La réinitialisation SSN/TSN est encore différente. Elle touche tous les flux dans les deux sens et choisit de nouveaux points de départ TSN. L’émetteur cesse alors d’attribuer des TSN jusqu’à la fin de la procédure ; des précautions liées à la durée de vie maximale des segments évitent l’ambiguïté d’un retour circulaire des numéros. Ce n’est pas la version « plus forte » d’un simple choix de flux, mais une autre surface de contrôle.

Le RFC 6458 expose les séquences et notifications SCTP aux applications. C’est pourquoi l’extension doit être activée explicitement et ses notifications demandées. Une remise à zéro invisible briserait les hypothèses d’une application qui attend des numéros monotones.

L’entrelacement changeait le compteur, pas la frontière

Avec l’entrelacement de messages du RFC 8260, I-DATA utilise des Message Identifiers de 32 bits à la place des SSN classiques. Une réinitialisation doit alors remettre à zéro deux compteurs MID, l’un pour les messages ordonnés, l’autre pour les non ordonnés. Les ordonnanceurs à attribution tardive des TSN rendent l’implémentation plus délicate ; ils n’abolissent pas la nécessité d’un seuil convenu.

Cette mécanique ne doit pas être confondue avec la fiabilité partielle. Le RFC 7496 décrit des politiques permettant à l’émetteur d’abandonner des messages selon une priorité ou un nombre de retransmissions. Abandonner un message aide le récepteur à avancer ; réinitialiser un flux crée une nouvelle époque de séquence. Les deux opérations répondent à des décisions différentes.

Le registre SCTP de l’IANA attribue le type 130 à RE-CONFIG et documente ses paramètres. Il décode une capture ; il ne démontre ni l’implémentation de l’extension, ni sa négociation, ni son activation par l’application.

Sources