6. The Usage of SCTP for Data Channels (Utilisation de SCTP pour les canaux de données)

6.1 SCTP Protocol Considerations (Considérations relatives au protocole SCTP)

L'encapsulation DTLS des paquets SCTP décrite dans [RFC8261] DOIT (MUST) être utilisée.

Cette pile de protocoles SCTP et ses couches supérieures DOIVENT (MUST) prendre en charge l'utilisation de plusieurs flux SCTP. Les messages utilisateur peuvent être envoyés de manière ordonnée ou non ordonnée, avec une fiabilité partielle ou complète.

Les extensions de protocole SCTP suivantes sont requises :

• L'extension de reconfiguration de flux (Stream Reconfiguration Extension) définie dans [RFC6525] DOIT (MUST) être prise en charge. Elle est utilisée pour fermer les canaux.

• L'extension de reconfiguration d'adresse dynamique (Dynamic Address Reconfiguration Extension) définie dans [RFC5061] DOIT (MUST) être utilisée pour signaler la prise en charge de l'extension de réinitialisation de flux définie dans [RFC6525]. Les autres fonctionnalités de [RFC5061] sont OPTIONNELLES (OPTIONAL).

• L'extension de fiabilité partielle (Partial Reliability Extension) définie dans [RFC3758] DOIT (MUST) être prise en charge. En plus de la politique PR-SCTP de fiabilité temporisée définie dans [RFC3758], la politique de retransmission limitée (Limited Retransmission Policy) définie dans [RFC7496] DOIT (MUST) être prise en charge. Limiter le nombre de retransmissions à zéro, combiné à une livraison non ordonnée, fournit un service similaire à UDP, où chaque message utilisateur est envoyé exactement une fois et livré dans l'ordre de réception.

La prise en charge de l'entrelacement de messages (Message Interleaving) définie dans [RFC8260] DEVRAIT (SHOULD) être utilisée.

6.2 SCTP Association Management (Gestion des associations SCTP)

Dans le contexte WebRTC, une association SCTP est établie lorsque les deux points de terminaison d'une PeerConnection WebRTC conviennent d'ouvrir une association SCTP, comme négocié par JSEP (JavaScript Session Establishment Protocol, protocole d'établissement de session JavaScript), généralement par l'échange de SDP (Session Description Protocol, protocole de description de session) [RFC8829]. Elle utilisera la connexion DTLS sélectionnée par ICE, qui sera généralement partagée avec la connexion DTLS utilisée pour les flux de médias SRTP clés via BUNDLE ou équivalent.

Le nombre de flux négociés lors de l'établissement de l'association SCTP DEVRAIT (SHOULD) être 65535, ce qui est le nombre maximum de flux pouvant être négociés lors de l'établissement de l'association.

SCTP prend en charge deux façons de terminer une association SCTP. La première méthode est gracieuse (Graceful), utilisant un processus garantissant qu'aucun message n'est perdu lors de la fermeture de l'association. La seconde méthode est non gracieuse (Non-graceful), où une partie peut directement abandonner l'association.

Chaque point de terminaison SCTP surveille en permanence l'accessibilité de son pair en surveillant le nombre de retransmissions des messages utilisateur et des messages de test. En cas de retransmissions excessives, l'association est terminée de manière non gracieuse.

Si l'association SCTP est fermée de manière gracieuse, tous ses canaux de données seront fermés. En cas de démantèlement non gracieux, tous les canaux de données seront également fermés, mais une indication d'erreur DEVRAIT (SHOULD) être fournie si possible.

6.3 SCTP Streams (Flux SCTP)

SCTP définit un flux (Stream) comme un canal logique unidirectionnel vers un autre point de terminaison SCTP au sein d'une association SCTP. Les flux sont utilisés pour fournir la notion de livraison séquentielle et le multiplexage. Chaque message utilisateur est envoyé sur un flux particulier, de manière ordonnée ou non ordonnée. L'ordre n'est préservé que pour les messages ordonnés envoyés sur le même flux.

6.4 Data Channel Definition (Définition du canal de données)

La définition du canal de données est telle que l'API de niveau application qui l'accompagne peut refléter étroitement l'API des WebSockets, ce qui implique un flux de données bidirectionnel et un champ texte appelé « label » identifiant la signification du canal de données.

L'implémentation d'un canal de données est une paire de flux SCTP entrant et sortant avec le même identifiant de flux SCTP (Stream Identifier). La façon dont ces identifiants de flux SCTP sont choisis dépend du protocole et de l'implémentation. Cela permet une communication bidirectionnelle.

De plus, chaque canal de données possède les propriétés suivantes dans chaque direction :

• Transport de messages fiable ou non fiable : en cas de transport non fiable, le même niveau de non-fiabilité est utilisé. Notez que dans SCTP, il s'agit d'une propriété du message utilisateur SCTP, et non du flux SCTP.

• Livraison ordonnée ou non ordonnée des messages : notez que dans SCTP, il s'agit d'une propriété du message utilisateur SCTP, et non du flux SCTP.

• Priorité (Priority), qui est un entier non signé de 2 octets : ces priorités DOIVENT (MUST) être interprétées comme des priorités d'ordonnancement de file d'attente équitable pondérée (weighted fair queuing scheduling priorities) conformément à la définition de l'ordonnanceur de flux correspondant prenant en charge l'entrelacement dans [RFC8260]. Pour une utilisation dans WebRTC, les valeurs utilisées DEVRAIENT (SHOULD) être l'une des suivantes : 128 (« inférieur à la normale »), 256 (« normale »), 512 (« haute ») ou 1024 (« très haute »).

• Label optionnel.

• Protocole optionnel.

Notez que pour les canaux de données utilisant la négociation de protocole spécifiée dans [RFC8832], toutes les propriétés ci-dessus sont identiques dans les deux directions.

6.5 Opening a Data Channel (Ouverture d'un canal de données)

Un canal de données peut être ouvert en utilisant une négociation au sein de l'association SCTP (appelée négociation en bande, In-band Negotiation) ou une négociation hors bande (Out-of-band Negotiation). La négociation hors bande est définie comme toute méthode conduisant à un accord sur les paramètres du canal et à la création du canal. Les détails dépassent le cadre de ce document. Les applications utilisant des canaux de données doivent utiliser la méthode de négociation de manière cohérente sur les deux points de terminaison.

Un protocole simple pour la négociation en bande est spécifié dans [RFC8832].

Lorsqu'une partie souhaite ouvrir un canal en utilisant la négociation hors bande, elle sélectionne un flux. Sauf définition ou négociation contraire, les flux sont sélectionnés en fonction du rôle DTLS (le client sélectionne les identifiants de flux pairs, le serveur sélectionne les identifiants de flux impairs). Cependant, l'application est responsable d'éviter les conflits avec les flux existants. Si elle tente de réutiliser un flux faisant partie d'un canal de données existant, l'ajout DOIT (MUST) échouer. En plus de sélectionner un flux, l'application DEVRAIT (SHOULD) déterminer les options à utiliser pour l'envoi des messages. L'application DOIT (MUST) s'assurer, de manière spécifique à l'application, que l'application du pair connaît également le flux sélectionné à utiliser et les options d'envoi de données depuis ce côté.

6.6 Transferring User Data on a Data Channel (Transfert de données utilisateur sur un canal de données)

Toutes les données envoyées de manière bidirectionnelle sur un canal de données DOIVENT (MUST) être envoyées via le flux sous-jacent en utilisant la fiabilité définie lors de l'ouverture du canal de données, sauf si les options ont été modifiées ou si des options par message sont spécifiées par un niveau supérieur.

La directionnalité des messages SCTP est utilisée pour préserver les limites des messages utilisateur. Par conséquent, l'émetteur NE DOIT PAS (MUST NOT) placer plusieurs messages d'application dans un seul message utilisateur SCTP. Sauf si la fragmentation et le réassemblage basés sur le PPID (déprécié) sont utilisés, l'émetteur DOIT (MUST) inclure exactement un message d'application dans chaque message utilisateur SCTP.

Les identifiants de protocole de charge utile SCTP (Payload Protocol Identifiers, PPIDs) sont utilisés pour signaler l'interprétation des « données de charge utile ». Les PPIDs suivants DOIVENT (MUST) être utilisés (voir section 8) :

WebRTC String : utilisé pour identifier une chaîne JavaScript non vide encodée en UTF-8.

WebRTC String Empty : utilisé pour identifier une chaîne JavaScript vide encodée en UTF-8.

WebRTC Binary : utilisé pour identifier des données binaires JavaScript non vides (ArrayBuffer, ArrayBufferView ou Blob).

WebRTC Binary Empty : utilisé pour identifier des données binaires JavaScript vides (ArrayBuffer, ArrayBufferView ou Blob).

SCTP ne prend pas en charge l'envoi de messages utilisateur vides. Par conséquent, si un message vide doit être envoyé, le PPID approprié (WebRTC String Empty ou WebRTC Binary Empty) est utilisé et un message utilisateur SCTP de zéro octet est envoyé. Lors de la réception d'un message utilisateur SCTP avec l'un de ces PPIDs, le récepteur DOIT (MUST) ignorer le message utilisateur SCTP et le traiter comme un message vide.

L'utilisation des PPIDs « WebRTC String Partial » et « WebRTC Binary Partial » est dépréciée. Ils étaient utilisés pour la fragmentation et le réassemblage basés sur le PPID des messages utilisateur appartenant à des canaux de données fiables et ordonnés.

Si un message avec un PPID non pris en charge est reçu, ou si le récepteur détecte certaines conditions d'erreur liées au message reçu (par exemple, un ordonnancement illégal), le récepteur DEVRAIT (SHOULD) fermer le canal de données correspondant. Cela signifie notamment que les extensions utilisant des PPIDs supplémentaires ne peuvent pas être utilisées sans négociation préalable.

Le protocole de base SCTP spécifié dans [RFC4960] ne prend pas en charge l'entrelacement des messages utilisateur. Par conséquent, l'envoi de grands messages utilisateur peut monopoliser l'association SCTP. Pour surmonter cette limitation, [RFC8260] définit une extension prenant en charge l'entrelacement des messages, qui DEVRAIT (SHOULD) être utilisée. Tant que l'entrelacement des messages n'est pas pris en charge, l'émetteur DEVRAIT (SHOULD) limiter la taille maximale des messages à 16 Ko pour éviter le monopole.

Il est recommandé de maintenir la taille des messages dans une certaine plage, car les applications ne pourront pas prendre en charge des messages individuels arbitrairement grands. Cette limite DOIT être négociée, par exemple en utilisant [RFC8841].

L'émetteur DEVRAIT (SHOULD) désactiver l'algorithme de Nagle (voir [RFC1122]) pour minimiser la latence.

6.7 Closing a Data Channel (Fermeture d'un canal de données)

La fermeture d'un canal de données DOIT (MUST) être signalée par la réinitialisation du flux sortant correspondant [RFC6525]. Cela signifie que si une partie décide de fermer le canal de données, elle réinitialise le flux sortant correspondant. Lorsque le pair constate que le flux entrant a été réinitialisé, il réinitialise également son flux sortant correspondant. Une fois cela fait, le canal de données est fermé. La réinitialisation d'un flux remet les numéros de séquence de flux (Stream Sequence Numbers, SSNs) à « zéro » et envoie une notification correspondante à la couche application indiquant que la réinitialisation a été effectuée. Le flux est disponible pour réutilisation après la réinitialisation.

[RFC6525] garantit également que tous les messages sont livrés (ou abandonnés) avant la réinitialisation du flux.

---