Aller au contenu principal

1. Introduction

Cette section explique le raisonnement derrière le développement du protocole de transmission avec contrôle de flux (Stream Control Transmission Protocol, SCTP), les services qu'il offre et les concepts de base nécessaires pour comprendre la description détaillée du protocole.

Ce document rend obsolètes [RFC2960] et [RFC3309].

1.1. Motivation​

TCP [RFC0793] a rendu un immense service en tant que moyen principal de transfert de données fiable dans les réseaux IP. Cependant, un nombre croissant d'applications récentes ont trouvé TCP trop limitant et ont incorporé leur propre protocole de transfert de données fiable au-dessus d'UDP [RFC0768]. Les limitations que les utilisateurs ont souhaité contourner incluent les suivantes :

  • TCP fournit à la fois un transfert de données fiable et une livraison stricte des données dans l'ordre de transmission. Certaines applications ont besoin d'un transfert fiable sans maintenance de séquence, tandis que d'autres se contenteraient d'un ordonnancement partiel des données. Dans ces deux cas, le blocage en tête de ligne (head-of-line blocking) offert par TCP provoque un délai inutile.

  • La nature orientée flux de TCP est souvent un inconvénient. Les applications doivent ajouter leur propre marquage d'enregistrement pour délimiter leurs messages et doivent utiliser explicitement la fonction push pour garantir qu'un message complet est transféré dans un temps raisonnable.

  • La portée limitée des sockets TCP complique la tâche de fournir une capacité de transfert de données hautement disponible en utilisant des hôtes multi-domiciliés.

  • TCP est relativement vulnérable aux attaques par déni de service, telles que les attaques SYN.

Le transport de la signalisation PSTN sur le réseau IP est une application pour laquelle toutes ces limitations de TCP sont pertinentes. Bien que cette application ait directement motivé le développement de SCTP, d'autres applications peuvent trouver que SCTP correspond bien à leurs exigences.

1.2. Vue architecturale de SCTP​

SCTP est considéré comme une couche entre l'application utilisateur SCTP (« utilisateur SCTP » en abrégé) et un service de réseau de paquets sans connexion tel qu'IP. Le reste de ce document suppose que SCTP fonctionne au-dessus d'IP. Le service de base offert par SCTP est le transfert fiable de messages utilisateur entre utilisateurs SCTP homologues. Il exécute ce service dans le contexte d'une association entre deux points d'extrémité SCTP. La section 10 de ce document esquisse l'API qui devrait exister à la frontière entre les couches SCTP et utilisateur SCTP.

SCTP est de nature orienté connexion, mais l'association SCTP est un concept plus large que la connexion TCP. SCTP fournit les moyens pour chaque point d'extrémité SCTP (section 1.3) de fournir à l'autre point d'extrémité (pendant le démarrage de l'association) une liste d'adresses de transport (c'est-à-dire plusieurs adresses IP en combinaison avec un port SCTP) par lesquelles ce point d'extrémité peut être atteint et à partir desquelles il émettra des paquets SCTP. L'association couvre les transferts sur toutes les combinaisons source/destination possibles qui peuvent être générées à partir des listes de chaque point d'extrémité.

     _____________                                      _____________
    |  SCTP User  |                                    |  SCTP User  |
    | Application |                                    | Application |
    |-------------|                                    |-------------|
    |    SCTP     |                                    |    SCTP     |
    |  Transport  |                                    |  Transport  |
    |   Service   |                                    |   Service   |
    |-------------|                                    |-------------|
    |             |One or more    ----      One or more|             |
    | IP Network  |IP address      \/        IP address| IP Network  |
    |   Service   |appearances     /\       appearances|   Service   |
    |_____________|               ----                 |_____________|

      SCTP Node A |<-------- Network transport ------->| SCTP Node B

                       Figure 1 : Une association SCTP

1.3. Termes clés​

Une partie du langage utilisé pour décrire SCTP a été introduite dans les sections précédentes. Cette section fournit une liste consolidée des termes clés et de leurs définitions.

  • Adresse de transport de destination active (Active destination transport address) : Une adresse de transport sur un point d'extrémité homologue qu'un point d'extrémité émetteur considère disponible pour recevoir des messages utilisateur.

  • Regroupement (Bundling) : Une opération de multiplexage optionnelle, par laquelle plusieurs messages utilisateur peuvent être transportés dans le même paquet SCTP. Chaque message utilisateur occupe son propre chunk DATA.

  • Chunk : Une unité d'information dans un paquet SCTP, composée d'un en-tête de chunk et d'un contenu spécifique au chunk.

  • Fenêtre de congestion (Congestion window, cwnd) : Une variable SCTP qui limite les données, en nombre d'octets, qu'un expéditeur peut envoyer à une adresse de transport de destination particulière avant de recevoir un accusé de réception.

  • Point d'accusé de réception TSN cumulatif (Cumulative TSN Ack Point) : Le TSN du dernier chunk DATA accusé de réception via le champ d'accusé de réception TSN cumulatif d'un SACK.

  • Adresse de destination inactive (Idle destination address) : Une adresse à laquelle aucun message utilisateur n'a été envoyé pendant une certaine durée, normalement l'intervalle HEARTBEAT ou plus.

  • Adresse de transport de destination inactive (Inactive destination transport address) : Une adresse considérée comme inactive en raison d'erreurs et indisponible pour transporter des messages utilisateur.

  • Message = message utilisateur (Message = user message) : Données soumises à SCTP par le protocole de couche supérieure (ULP).

  • Code d'authentification de message (Message Authentication Code, MAC) : Un mécanisme de vérification d'intégrité basé sur des fonctions de hachage cryptographiques utilisant une clé secrète. Typiquement, les codes d'authentification de message sont utilisés entre deux parties qui partagent une clé secrète afin de valider les informations transmises entre ces parties. Dans SCTP, il est utilisé par un point d'extrémité pour valider les informations du cookie d'état (State Cookie) qui sont renvoyées par l'homologue dans le chunk COOKIE ECHO. Le terme « MAC » a différentes significations dans différents contextes. SCTP utilise ce terme avec la même signification que dans [RFC2104].

  • Ordre des octets réseau (Network Byte Order) : Octet le plus significatif en premier, c'est-à-dire big endian.

  • Message ordonné (Ordered Message) : Un message utilisateur qui est livré dans l'ordre par rapport à tous les messages utilisateur précédents envoyés dans le flux sur lequel le message a été envoyé.

  • TSN en cours (Outstanding TSN, à un point d'extrémité SCTP) : Un TSN (et le chunk DATA associé) qui a été envoyé par le point d'extrémité mais pour lequel il n'a pas encore reçu d'accusé de réception.

  • Chemin (Path) : La route empruntée par les paquets SCTP envoyés par un point d'extrémité SCTP à une adresse de transport de destination spécifique de son point d'extrémité SCTP homologue. L'envoi à différentes adresses de transport de destination ne garantit pas nécessairement l'obtention de chemins séparés.

  • Chemin primaire (Primary Path) : Le chemin primaire est l'adresse de destination et source qui sera placée dans un paquet sortant vers le point d'extrémité homologue par défaut. La définition inclut l'adresse source car une implémentation peut souhaiter spécifier à la fois l'adresse de destination et source pour mieux contrôler le chemin de retour pris par les chunks de réponse et sur quelle interface le paquet est transmis lorsque l'expéditeur de données est multi-domicilié.

  • Fenêtre de réception (Receiver Window, rwnd) : Une variable SCTP qu'un expéditeur de données utilise pour stocker la fenêtre de réception la plus récemment calculée de son homologue, en nombre d'octets. Cela donne à l'expéditeur une indication de l'espace disponible dans le tampon entrant du récepteur.

  • Association SCTP (SCTP association) : Une relation de protocole entre points d'extrémité SCTP, composée des deux points d'extrémité SCTP et des informations d'état du protocole, y compris les étiquettes de vérification (Verification Tags) et l'ensemble actuellement actif de numéros de séquence de transmission (TSN), etc. Une association peut être identifiée de manière unique par les adresses de transport utilisées par les points d'extrémité dans l'association. Deux points d'extrémité SCTP ne doivent pas (MUST NOT) avoir plus d'une association SCTP entre eux à un moment donné.

  • Point d'extrémité SCTP (SCTP endpoint) : L'émetteur/récepteur logique de paquets SCTP. Sur un hôte multi-domicilié, un point d'extrémité SCTP est représenté à ses homologues comme une combinaison d'un ensemble d'adresses de transport de destination éligibles auxquelles les paquets SCTP peuvent être envoyés et d'un ensemble d'adresses de transport source éligibles à partir desquelles les paquets SCTP peuvent être reçus. Toutes les adresses de transport utilisées par un point d'extrémité SCTP doivent utiliser le même numéro de port, mais peuvent utiliser plusieurs adresses IP. Une adresse de transport utilisée par un point d'extrémité SCTP ne doit pas être utilisée par un autre point d'extrémité SCTP. En d'autres termes, une adresse de transport est unique à un point d'extrémité SCTP.

  • Paquet SCTP (ou paquet) (SCTP packet or packet) : L'unité de livraison de données à travers l'interface entre SCTP et le réseau de paquets sans connexion (par exemple, IP). Un paquet SCTP comprend l'en-tête SCTP commun, d'éventuels chunks de contrôle SCTP et des données utilisateur encapsulées dans des chunks SCTP DATA.

  • Application utilisateur SCTP (utilisateur SCTP) (SCTP user application, SCTP user) : L'entité d'application de couche supérieure logique qui utilise les services de SCTP, également appelée protocole de couche supérieure (ULP).

  • Seuil de démarrage lent (Slow-Start Threshold, ssthresh) : Une variable SCTP. C'est le seuil que le point d'extrémité utilisera pour déterminer s'il doit effectuer un démarrage lent ou un évitement de congestion sur une adresse de transport de destination particulière. Ssthresh est exprimé en nombre d'octets.

  • Flux (Stream) : Un canal logique unidirectionnel établi d'un point d'extrémité SCTP associé à un autre, dans lequel tous les messages utilisateur sont livrés en séquence, à l'exception de ceux soumis au service de livraison non ordonnée.

Note : La relation entre les numéros de flux dans les directions opposées est strictement une question de la façon dont les applications les utilisent. Il est de la responsabilité de l'utilisateur SCTP de créer et de gérer ces corrélations si elles sont souhaitées.

  • Numéro de séquence de flux (Stream Sequence Number) : Un numéro de séquence de 16 bits utilisé en interne par SCTP pour assurer la livraison séquencée des messages utilisateur dans un flux donné. Un numéro de séquence de flux est attaché à chaque message utilisateur.

  • Étiquettes de liaison (Tie-Tags) : Deux nombres aléatoires de 32 bits qui forment ensemble un nonce de 64 bits. Ces étiquettes sont utilisées dans un cookie d'état (State Cookie) et un TCB afin qu'une association nouvellement redémarrée puisse être liée à l'association d'origine dans le point d'extrémité qui n'a pas redémarré et ne révèle pas les vraies étiquettes de vérification d'une association existante.

  • Bloc de contrôle de transmission (Transmission Control Block, TCB) : Une structure de données interne créée par un point d'extrémité SCTP pour chacune de ses associations SCTP existantes à d'autres points d'extrémité SCTP. Le TCB contient toutes les informations d'état et opérationnelles permettant au point d'extrémité de maintenir et de gérer l'association correspondante.

  • Numéro de séquence de transmission (Transmission Sequence Number, TSN) : Un numéro de séquence de 32 bits utilisé en interne par SCTP. Un TSN est attaché à chaque chunk contenant des données utilisateur pour permettre au point d'extrémité SCTP récepteur d'accuser réception de sa réception et de détecter les livraisons en double.

  • Adresse de transport (Transport address) : Une adresse de transport est traditionnellement définie par une adresse de couche réseau, un protocole de couche transport et un numéro de port de couche transport. Dans le cas de SCTP fonctionnant sur IP, une adresse de transport est définie par la combinaison d'une adresse IP et d'un numéro de port SCTP (où SCTP est le protocole de transport).

  • TSN non accusé de réception (Unacknowledged TSN, à un point d'extrémité SCTP) : Un TSN (et le chunk DATA associé) qui a été reçu par le point d'extrémité mais pour lequel un accusé de réception n'a pas encore été envoyé. Ou dans le cas opposé, pour un paquet qui a été envoyé mais aucun accusé de réception n'a été reçu.

  • Message non ordonné (Unordered Message) : Les messages non ordonnés sont « non ordonnés » par rapport à tout autre message ; cela inclut à la fois d'autres messages non ordonnés ainsi que d'autres messages ordonnés. Un message non ordonné peut être livré avant ou après les messages ordonnés envoyés sur le même flux.

  • Message utilisateur (User message) : L'unité de livraison de données à travers l'interface entre SCTP et son utilisateur.

  • Étiquette de vérification (Verification Tag) : Un entier non signé de 32 bits qui est généré aléatoirement. L'étiquette de vérification fournit une clé qui permet à un récepteur de vérifier que le paquet SCTP appartient à l'association actuelle et n'est pas un paquet ancien ou obsolète d'une association précédente.

1.4. Abréviations​

  • MAC - Code d'authentification de message (Message Authentication Code) [RFC2104]
  • RTO - Temporisation de retransmission (Retransmission Timeout)
  • RTT - Temps aller-retour (Round-Trip Time)
  • RTTVAR - Variation du temps aller-retour (Round-Trip Time Variation)
  • SCTP - Protocole de transmission avec contrôle de flux (Stream Control Transmission Protocol)
  • SRTT - RTT lissé (Smoothed RTT)
  • TCB - Bloc de contrôle de transmission (Transmission Control Block)
  • TLV - Format de codage type-longueur-valeur (Type-Length-Value coding format)
  • TSN - Numéro de séquence de transmission (Transmission Sequence Number)
  • ULP - Protocole de couche supérieure (Upper-Layer Protocol)

1.5. Vue fonctionnelle de SCTP​

Le service de transport SCTP peut être décomposé en un certain nombre de fonctions. Celles-ci sont représentées dans la figure 2 et expliquées dans le reste de cette section.

                        SCTP User Application

         -----------------------------------------------------
          _____________                  ____________________
         |             |                | Sequenced Delivery |
         | Association |                |   within Streams   |
         |             |                |____________________|
         |   Startup   |
         |             |         ____________________________
         |     and     |        |    User Data Fragmentation |
         |             |        |____________________________|
         |   Takedown  |
         |             |         ____________________________
         |             |        |     Acknowledgement        |
         |             |        |          and               |
         |             |        |    Congestion Avoidance    |
         |             |        |____________________________|
         |             |
         |             |         ____________________________
         |             |        |       Chunk Bundling       |
         |             |        |____________________________|
         |             |
         |             |     ________________________________
         |             |    |      Packet Validation         |
         |             |    |________________________________|
         |             |
         |             |     ________________________________
         |             |    |     Path Management            |
         |_____________|    |________________________________|

           Figure 2 : Vue fonctionnelle du service de transport SCTP

1.5.1. Démarrage et arrêt de l'association​

Une association est initiée par une demande de l'utilisateur SCTP (voir la description de la primitive ASSOCIATE (ou SEND) dans la section 10).

Un mécanisme de cookie, similaire à celui décrit par Karn et Simpson dans [RFC2522], est employé pendant l'initialisation pour fournir une protection contre les attaques de synchronisation. Le mécanisme de cookie utilise une poignée de main à quatre voies, dont les deux dernières étapes sont autorisées à transporter des données utilisateur pour une configuration rapide. La séquence de démarrage est décrite dans la section 5 de ce document.

SCTP prévoit la fermeture gracieuse (c'est-à-dire shutdown) d'une association active sur demande de l'utilisateur SCTP. Voir la description de la primitive SHUTDOWN dans la section 10. SCTP permet également la fermeture non gracieuse (c'est-à-dire abort), soit sur demande de l'utilisateur (primitive ABORT), soit en raison d'une condition d'erreur détectée dans la couche SCTP. La section 9 décrit à la fois les procédures de fermeture gracieuse et non gracieuse.

SCTP ne prend pas en charge un état semi-ouvert (comme TCP) dans lequel un côté peut continuer à envoyer des données tandis que l'autre extrémité est fermée. Lorsque l'un ou l'autre point d'extrémité effectue un arrêt, l'association sur chaque homologue cessera d'accepter de nouvelles données de son utilisateur et ne livrera que les données en file d'attente au moment de la fermeture gracieuse (voir section 9).

1.5.2. Livraison séquencée dans les flux​

Le terme « flux » est utilisé dans SCTP pour désigner une séquence de messages utilisateur qui doivent être livrés au protocole de couche supérieure dans l'ordre par rapport aux autres messages du même flux. Ceci contraste avec son utilisation dans TCP, où il fait référence à une séquence d'octets (dans ce document, un octet est supposé être de 8 bits).

L'utilisateur SCTP peut spécifier au moment du démarrage de l'association le nombre de flux à prendre en charge par l'association. Ce nombre est négocié avec l'extrémité distante (voir section 5.1.1). Les messages utilisateur sont associés à des numéros de flux (primitives SEND, RECEIVE, section 10). En interne, SCTP attribue un numéro de séquence de flux à chaque message qui lui est transmis par l'utilisateur SCTP. Du côté réception, SCTP garantit que les messages sont livrés à l'utilisateur SCTP en séquence dans un flux donné. Cependant, alors qu'un flux peut être bloqué en attendant le prochain message utilisateur en séquence, la livraison à partir d'autres flux peut continuer.

SCTP fournit un mécanisme pour contourner le service de livraison séquencée. Les messages utilisateur envoyés en utilisant ce mécanisme sont livrés à l'utilisateur SCTP dès qu'ils sont reçus.

1.5.3. Fragmentation des données utilisateur​

Lorsque nécessaire, SCTP fragmente les messages utilisateur pour garantir que le paquet SCTP transmis à la couche inférieure est conforme au MTU du chemin. À la réception, les fragments sont réassemblés en messages complets avant d'être transmis à l'utilisateur SCTP.

1.5.4. Accusé de réception et évitement de congestion​

SCTP attribue un numéro de séquence de transmission (TSN) à chaque fragment de données utilisateur ou message non fragmenté. Le TSN est indépendant de tout numéro de séquence de flux attribué au niveau du flux. L'extrémité réceptrice accuse réception de tous les TSN reçus, même s'il y a des lacunes dans la séquence. De cette manière, la livraison fiable est maintenue fonctionnellement séparée de la livraison de flux séquencé.

La fonction d'accusé de réception et d'évitement de congestion est responsable de la retransmission de paquets lorsqu'un accusé de réception en temps opportun n'a pas été reçu. La retransmission de paquets est conditionnée par des procédures d'évitement de congestion similaires à celles utilisées pour TCP. Voir la section 6 et la section 7 pour une description détaillée des procédures de protocole associées à cette fonction.

1.5.5. Regroupement de chunks​

Comme décrit dans la section 3, le paquet SCTP tel que livré à la couche inférieure se compose d'un en-tête commun suivi d'un ou plusieurs chunks. Chaque chunk peut contenir soit des données utilisateur, soit des informations de contrôle SCTP. L'utilisateur SCTP a la possibilité de demander le regroupement de plusieurs messages utilisateur dans un seul paquet SCTP. La fonction de regroupement de chunks de SCTP est responsable de l'assemblage du paquet SCTP complet et de son désassemblage du côté réception.

Pendant les périodes de congestion, une implémentation SCTP peut (MAY) toujours effectuer un regroupement même si l'utilisateur a demandé que SCTP ne regroupe pas. La désactivation du regroupement par l'utilisateur n'affecte que les implémentations SCTP qui peuvent retarder une courte période avant la transmission (pour tenter d'encourager le regroupement). Lorsque la couche utilisateur désactive le regroupement, ce petit délai est interdit mais pas le regroupement effectué pendant la congestion ou la retransmission.

1.5.6. Validation de paquet​

Un champ d'étiquette de vérification obligatoire et un champ de somme de contrôle de 32 bits (voir l'annexe B pour une description de la somme de contrôle CRC32c) sont inclus dans l'en-tête commun SCTP. La valeur de l'étiquette de vérification est choisie par chaque extrémité de l'association pendant le démarrage de l'association. Les paquets reçus sans la valeur d'étiquette de vérification attendue sont rejetés, en tant que protection contre les attaques de mascarade aveugle et contre les paquets SCTP obsolètes d'une association précédente. La somme de contrôle CRC32c devrait être définie par l'expéditeur de chaque paquet SCTP pour fournir une protection supplémentaire contre la corruption des données dans le réseau. Le récepteur d'un paquet SCTP avec une somme de contrôle CRC32c invalide rejette silencieusement le paquet.

1.5.7. Gestion des chemins​

L'utilisateur SCTP émetteur est capable de manipuler l'ensemble des adresses de transport utilisées comme destinations pour les paquets SCTP via les primitives décrites dans la section 10. La fonction de gestion des chemins SCTP choisit l'adresse de transport de destination pour chaque paquet SCTP sortant en fonction des instructions de l'utilisateur SCTP et de l'état de joignabilité actuellement perçu de l'ensemble de destinations éligibles. La fonction de gestion des chemins surveille la joignabilité par le biais de battements de cœur lorsque le trafic de paquets est insuffisant pour fournir ces informations et informe l'utilisateur SCTP lorsque la joignabilité de toute adresse de transport d'extrémité distante change. La fonction de gestion des chemins est également responsable de signaler l'ensemble éligible d'adresses de transport locales à l'extrémité distante pendant le démarrage de l'association, et de signaler les adresses de transport renvoyées par l'extrémité distante à l'utilisateur SCTP.

Au démarrage de l'association, un chemin primaire est défini pour chaque point d'extrémité SCTP et est utilisé pour l'envoi normal de paquets SCTP.

Du côté réception, la gestion des chemins est responsable de vérifier l'existence d'une association SCTP valide à laquelle le paquet SCTP entrant appartient avant de le transmettre pour un traitement ultérieur.

Note : La gestion des chemins et la validation des paquets sont effectuées en même temps, donc bien qu'elles soient décrites séparément ci-dessus, en réalité elles ne peuvent pas être effectuées en tant qu'éléments séparés.

1.6. Arithmétique des numéros de série​

Il est essentiel de se rappeler que l'espace de numéros de séquence de transmission réel est fini, bien que très grand. Cet espace va de 0 à 232 - 1. Comme l'espace est fini, toute l'arithmétique traitant des numéros de séquence de transmission doit être effectuée modulo 232. Cette arithmétique non signée préserve la relation des numéros de séquence lorsqu'ils cyclent de 232 - 1 à 0 à nouveau. Il existe certaines subtilités dans l'arithmétique modulo informatique, donc un grand soin doit être pris dans la programmation de la comparaison de telles valeurs. En référence aux TSN, le symbole « =< » signifie « inférieur ou égal » (modulo 232).

Les comparaisons et l'arithmétique sur les TSN dans ce document devraient (SHOULD) utiliser l'arithmétique des numéros de série telle que définie dans [RFC1982] où SERIAL_BITS = 32.

Un point d'extrémité ne devrait pas (SHOULD NOT) transmettre un chunk DATA avec un TSN qui est supérieur de plus de 2**31 - 1 au TSN de début de sa fenêtre d'envoi actuelle. Cela causera des problèmes dans la comparaison des TSN.

Les numéros de séquence de transmission bouclent lorsqu'ils atteignent 232 - 1. C'est-à-dire que le prochain TSN qu'un chunk DATA doit utiliser (MUST) après avoir transmis TSN = 232 - 1 est TSN = 0.

Toute arithmétique effectuée sur les numéros de séquence de flux devrait (SHOULD) utiliser l'arithmétique des numéros de série telle que définie dans [RFC1982] où SERIAL_BITS = 16. Toutes les autres arithmétiques et comparaisons dans ce document utilisent l'arithmétique normale.

1.7. Modifications par rapport à RFC 2960​

SCTP a été initialement défini dans [RFC2960], que ce document rend obsolète. Les lecteurs intéressés par les détails des diverses modifications que ce document incorpore sont invités à consulter [RFC4460].

Dernière mise à jour le