FI 9 – 18 novembre 2003 – page 12 FI 9 – 18 novembre 2003 – page 13

SCTP (Stream Control Transmission Protocol)

Une alternative à TCP et UDP ?François Buntschu, buntschu@eif.ch, Rudolf Scheurer, scheurer@eif.ch & Antoine Delley, delley@eif.ch, Ecole d’Ingénieurs et d’Architectes de Fribourg

es protocoles usuels de transport de l’information dans les réseaux IP sont TCP (Transmission Con-trol Protocol) et UDP (User Datagram Protocol). Pour répondre aux nouveaux besoins des applica-

tions de télécommunications, l’IETF (Internet Engineering Task Force) a élaboré un protocole de transport spécifique, le SCTP (Stream Control Transmission Protocol).

Introduction

Bien que développé pour le transfert de la signalisation dans les environnements VoIP (Voice over Internet Protocol), ce protocole est appelé, dans un avenir proche, à couvrir un spectre beaucoup plus large de besoins.

Les différences principales avec TCP sont le multi-ho-ming et le concept de flux (Stream) à l’intérieur d’une même connexion (ou plus précisément nommé association dans la terminologie SCTP). Alors que dans TCP un flux fait réfé-rence à une séquence d’octets, un flux SCTP fait référence à une séquence de messages (courts ou longs).

De plus, des fonctionnalités qui sont optionnelles dans TCP ont été incluses dans la spécification de base de SCTP, telles que le Selective Acknowledgment, permettant d’annoncer la réception de datagrammes erronés ou dupliqués ou encore le support de Explicit Congestion Notification (ECN).

Les attaques simples de type SYN attack qui affectent TCP ne sont plus possibles avec SCTP. Ce nouveau protocole inclut aussi des mécanismes protégeant les applications contre le Head of Line Blocking (HOL), par l’utilisation de flux.

fig. 1. SCTP dans le modèle OSI

Une association SCTP aura l’allure suivante, par analogie au protocole de transport TCP et UDP:

fig. 2. Exemple d’une association SCTP

Historique du protocole

Les réseaux de télécommunications modernes dépendent fortement de l’échange rapide et fiable de paramètres. La signalisation (l’échange de message de contrôle) entre diffé-rentes entités de réseau supporte non seulement des services de télécommunications de base, mais elle permet également la mise en place de services de réseau avancés, tels que les ré-seaux intelligents ou la gestion de la mobilité dans les réseaux de transmission mobiles. Les critères de qualité de service (par exemple post dialing dans les réseaux fixes et mobiles) sont également fortement influencés par la performance du système de signalisation.

Pendant de longues années, le système de signalisation numéro 7 (SS.7) [1] a régenté la signalisation dans les réseaux de télécommunications. Le réseau de signalisation SS7 est un réseau logiquement séparé et partage seulement quelques ressources physiques avec le trafic d’usager. Il a l’inconvénient d’exiger une infrastructure de réseau dédiée et très chère.

A l’IETF Meeting d’Orlando, en 1998, plusieurs alter-natives ont été présentées en concurrence à la création d’un nouveau protocole, telles que Reliable UPD (RUDP) [2] ou encore UDP for TCAP (T/UDP) [3]. Mais ces extensions ne remplissaient pas tous les critères requis pour la transmission de la signalisation sur un réseau IP, tels que l’acquittement sélectif ou le contrôle de congestion.

Récemment, beaucoup de solutions propriétaires, auto-risant le transport de la signalisation au-dessus d’IP, sont apparues. Cette approche permet l’utilisation commune du cœur d’un réseau pour le trafic de transport de signalisation et de données. Le protocole Stream Control Transmission Pro-tocol (SCTP) [4] est une solution standard à ce problème. C’est le résultat du groupe de travail Signaling Transport

FI 9 – 18 novembre 2003 – page 14 FI 9 – 18 novembre 2003 – page 15

de l’IETF (SIGTRAN), qui a été constitué en 1999. De plus, la spécification d’un socket API est devenue un draft Internet.

Plusieurs grands protagonistes du marché des télécom-munications et de l’informatique sont intéressés par ce nou-veau protocole, car il fournit un concept de transmission des données complètement neuf, basé sur des flux. Il est beaucoup plus flexible comparé à ses prédécesseurs TCP et UDP. Comme on peut le constater dans les diverses études faites sur ce protocole, son application ne se limitera pas uniquement au transport de la signalisation sur IP, mais aussi au transport d’applications multimédias [5].

Terminologie SCTP

Avant qu’un échange d’information puisse avoir lieu entre deux hôtes d’un réseau IP, il est nécessaire d’établir une rela-tion entre ceux-ci. Dans la terminologie SCTP les éléments qui communiquent entre eux sont appelés points terminaux et la relation établie entre ces mêmes éléments, pour permet-tre l’échange d’informations, s’appelle une association.

A l’instar des protocoles usuels de transport, tels que TCP ou UDP, SCTP nécessite l’utilisation de numéros de ports pour identifier l’application de la couche supérieure. Ces numéros de ports sont assignés par l’Inter-net Assigned Numbers Authority (IANA).

D’un point de vue réseau, un point terminal est l’extrémité logique du protocole de trans-port SCTP. Dans le cas d’une connexion simple (single-homed), l’identification du point terminal sera décrite de la manière suivante: point terminal = [adresse IP: port SCTP]

Dans le cas d’une connexion multiple (multi-homed), les diffé-rentes adresses IP utilisées parta-gent un port SCTP unique: Point terminal = [ adresse IP1, adresse IP2, ... adresse IPn: port SCTP]

En principe c’est l’application utilisatrice du protocole de transport SCTP qui décidera lesquelles des interfaces IP participeront à l’association. Cette fonctionnalité est utile lorsque plusieurs applications fonctionnent sur la même machine et que plusieurs asso-ciations doivent être établies (vers différents équipements terminaux).

Dans le cas de la figure 3, le nœud A est l’équipement terminal pour deux associations SCTP qui seront décrites de la manière suivante: le point terminal desservant l’application 1 est [@IP1, @IP2: Port 1] et celui desservant l’application 2 est [@IP3: Port 2].

Dans notre exemple, l’application 1 du nœud A commu-nique avec l’application 1 du nœud B. L’association établie sera décrite de la manière suivante: Association = {[@IP1, @IP2: Port 1]: [@IP: Port 1]}

fig. 3 – Exemple d’une association SCTP

Format des messages SCTP

Les paquets SCTP sont transportés dans des paquets IP, de manière identique à TCP ou UDP (fig. 4).

L’en-tête communL’en-tête commun fournit trois services de base à

SCTP:❚ la méthode pour associer un paquet SCTP avec une

association;❚ la vérification que ce paquet SCTP appartient à l’instance

courante de cette association;❚ une vérification de la couche transport, soit le contrôle

que les données transférées dans le réseau sont intactes.

ChunksChaque chunk a un champ Type, qui permet d’identifier

le transport des données et les information de contrôle. Les chunks ont une taille variable. Les différents types de chunks (extrait du RFC 2960) sont (cf. table 1):

fig. 4. Encapsulation de SCTP dans IPv4 ou IPv6

SCTP (Stream Control Transmission Protocol) – une alternative à TCP et UDP ?

FI 9 – 18 novembre 2003 – page 14 FI 9 – 18 novembre 2003 – page 15

Echange de données

Etablissement d’une associationL’établissement en quatre temps d’une association entre

deux nœuds SCTP peut paraître compliqué, mais la bonne nouvelle est que deux des paquets SCTP peuvent déjà trans-porter des données utiles lors de la phase d’établissement, soit dans les 3ème et 4ème paquets. Ceci permet de minimiser les délais, tout en augmentant la sécurité.

fig. 5 – Etablissement d’une association, processus en quatre temps

Afin de palier aux problèmes de l’établissement de la connexion (processus en trois temps) du protocole TCP, tels que les SYN attacks ou les demi-connexions (DoS, Denial of Service), le processus d’établissement d’une connexion SCTP est défini en quatre temps. Un des critères étant que le serveur ne doit pas réserver le moindre espace mémoire avant que l’association ne soit complètement établie.

CookieLors de l’établissement d’une associa-

tion, l’INIT-ACK chunk transporte un paramètre spécial: un state cookie, plus couramment appelé cookie. Ce paramètre permet aux associations SCTP de s’af-franchir des attaques de type SYN attack possibles avec TCP.

Comme l’utilisateur principal du cookie est l’émetteur du INIT-ACK chunk, la structure de celui-ci peut, en théorie, contenir n’importe quel type d’informations.

Le cookie n’a pas vraiment de struc-ture interne, et doit être retransmis de manière transparente par le récepteur du INIT-ACK chunk, pour qui le cookie n’a aucune signification. Comme l’intention est de déplacer vers le client et le réseau la tâche de sauvegarde des informations d’établissement d’association, il est né-cessaire d’avoir une méthode qui valide que celui-ci n’a pas été modifié durant le chemin de retour vers la station émet-

trice, ceci au moyen d’une signature électronique. Le choix de l’algorithme de hashing pour la signature du

cookie est important. En effet, la complexité du calcul de ces algorithmes diffère et pourrait déboucher sur une attaque des ressources CPU.

Fermeture d’une association

fig. 6 – Fermeture d’une association, processus en trois temps

Tout protocole de communication fiable nécessite une méthode pour terminer une communication. Dans le cas de SCTP, deux méthodes sont à disposition, soit le graceful shutdown et l’abortive shutdown. Le premier cas est similaire à TCP, avec comme différence principale le fait que SCTP ne supporte pas l’état demi-fermé. SCTP utilise un processus en trois temps pour la fermeture d’une association.

Le processus en trois temps utilisé dans le graceful shu-tdown n’est jamais activé par le stack SCTP lui-même, mais par les protocoles de couche supérieure d’un des points terminaux. Une fois que la notification d’interrompre l’as-sociation est reçue par le stack SCTP, celui-ci va s’assurer que

ID Value Chunk Type ----- ---------- 0 - Payload Data (DATA) 1 - Initiation (INIT) 2 - Initiation Acknowledgement (INIT ACK) 3 - Selective Acknowledgement (SACK) 4 - Heartbeat Request (HEARTBEAT) 5 - Heartbeat Acknowledgement (HEARTBEAT ACK) 6 - Abort (ABORT) 7 - Shutdown (SHUTDOWN) 8 - Shutdown Acknowledgement (SHUTDOWN ACK) 9 - Operation Error (ERROR) 10 - State Cookie (COOKIE ECHO) 11 - Cookie Acknowledgement (COOKIE ACK) 12 - Reserved for Explicit Congestion Notification Echo (ECNE) 13 - Reserved for Congestion Window Reduced (CWR) 14 - Shutdown Complete (SHUTDOWN COMPLETE) 15 to 62 - reserved by IETF 63 - IETF-defined Chunk Extensions 64 to 126 - reserved by IETF 127 - IETF-defined Chunk Extensions 0x80 - Address Configuration Acknowledgment (ASCONF-ACK) 128 to 190 - reserved by IETF 191 - IETF-defined Chunk Extensions 0xC1 - Address Configuration Change Chunk (ASCONF) 192 to 254 - reserved by IETF 255 - IETF-defined Chunk Extensions

Table 1. Liste des types de chunks, selon le RFC 2960

SCTP (Stream Control Transmission Protocol) – une alternative à TCP et UDP ?

FI 9 – 18 novembre 2003 – page 16 FI 9 – 18 novembre 2003 – page 17

ses queues de transmissions sont vides et qu’il a bien reçu tous les acquittements qui sont encore en attente.

Multi-homingLa propriété essentielle du protocole de transport SCTP

est le support des nœuds avec des connexions multiples (mul-tihomed), c’est-à-dire des nœuds qui peuvent être atteints par plusieurs adresses IP. Le multi-homing spécifié dans le protocole SCTP sert uniquement pour la redondance. La répartition de charge ne fait pas partie de la spécification actuelle du protocole [4] et est toujours à l’étude.

Multi-homing et mobilitéDans les réseaux actuels, la mobilité d’un réseau vers

un autre est un thème important. Afin de permettre de se déplacer d’un réseau IP vers un autre, sans interruption de l’association en cours, deux standards sont en cours d’évalua-tion. Il s’agit des drafts IETF suivants: Stream Control Trans-mission Protocol (SCTP) Dynamic Address Reconfiguration [6] et Architecture of Mobile SCTP for IP Mobility Support [7].

Ceux-ci sont une extension à la fonctionnalité Mobile IP disponible dans IPv4 [8] et IPv6 [9].

Mobile SCTP (mSCTP [10]) est principalement prévu pour une architecture de type client/serveur, avec le client mobile qui initie l’association avec le serveur fixe. Pour le support de connexion de type peer-to-peer, mSCTP doit être utilisé avec des algorithmes de localisation des machines, tels que Mobile IP ou Dynamic DNS.

La fonctionnalité principale permettant de maintenir une association active lors d’un changement de réseau IP est la fonction ADDIP, définie dans [9] et permettant de modifier/supprimer/ajouter une adresse IP faisant partie de l’association, sans que celle-là ne soit interrompue.

StreamAlors que le protocole de transport TCP relie le transfert

fiable de données utilisateur avec la livraison ordonnée des données, SCTP sépare le transfert fiable des données du mécanisme de livraison.

Ceci permet de s’adapter aux besoins spécifiques des applications utilisant SCTP. Certaines applications peuvent seulement avoir besoin d’une remise en ordre partielle des datagrammes tandis que d’autres pourraient se satisfaire d’un transfert fiable qui ne garantisse aucun ordre de trans-mission.

Une autre caractéristique du protocole SCTP est de per-mettre la transmission groupée de flux de données au sein d’une même association (multiplexage de flux), alors que TCP devrait établir plusieurs sessions en parallèle.

La transmission de donnéesPour la transmission des données, deux chunks principaux

sont utilisés:❚ DATA chunk - utilisé par le système qui transmet les

données; il contient les données envoyées❚ SACK chunk - utilisé par le système qui reçoit les données

pour les acquitter.Chaque DATA chunk est identifié par son TSN (Trans-

mission Sequence Number). Les TSN, qui sont consécutifs, indiquent le numéro du chunk.

Le champ Advertised Receiver Window Credit (a_rwnd)

qui se trouve dans le SACK chunk, indique à l’émetteur combien de bytes le récepteur est prêt à recevoir. Utilisé avec les champs Cumulative TSN acknowledgment et Gap Ack Blocks, l’émetteur peut avoir une vue précise de la taille du buffer de réception.

Le host qui a envoyé des données (DATA chunk), reçoit en retour dans le SACK chunk un Cumulative TSN ack-nowledgment, qui lui indique jusqu’à quelle valeur de TSN ses données ont été reçues. A noter la différence avec TCP, où là, les bytes sont acquittés, et non pas les paquets reçus.

S’il y a eu un problème lors de la transmission des don-nées, et qu’une retransmission de ces dernières a eu lieu, les DATA chunks hors séquence sont acquittés à l’aide du champ Gap Ack Blocks, qui permet l’acquittement d’une ou plusieurs séquences de TSN.

Contrôle de congestionDans le cas d’un réseau, la congestion peut se trouver à

deux endroits: au récepteur (taille des queues de réception trop petite) ou dans le réseau (bande passante de la liaison saturée).

Dans le premier cas, le problème est résolu avec le champ Advertised Receiver Window Credit (a_rwnd), qui se trouve dans les chunks de type INIT, INIT-ACK et SACK.

Le deuxième cas, plus complexe à gérer, est résolu à l’aide de plusieurs algorithmes. Ces algorithmes sont les mêmes que ceux utilisés dans TCP, et utilisent les deux variables suivantes pour chaque adresse de réception d’une association:❚ Congestion window (cwnd): qui limite le nombre de

bytes que le host émetteur des données peut avoir en suspens

❚ Slow Start Threshold (ssthresh): permet de choisir le bon algorithme de congestion au bon moment.Les algorithmes utilisés sont le Slow Start Algorithm, le

Fast Retransmit et le Fast Recovery.

Protocole SCTP vs UDP/TCP

La table de la page suivante résume les différences fonc-tionnelles entre les protocoles UDP, TCP et SCTP.

Analyse et simulation

Les caractéristiques du protocole SCTP ont été simulées et mesurées sur la plate-forme de test (voir fig.7).

Deux réseaux de transport sont simulés au moyen de l’application NISTnet, ce qui nous permet, par exemple, d’ajouter un délai dans la transmission, de créer des pertes de paquets ou des duplications.

Les analyseurs AN-1 et AN-2 seront synchronisés au moyen d’un GPS ou directement par un câble. Cette fonc-tionnalité est très utile pour examiner le comportement d’une association lors d’une connexion multiple (multi-homing) ou dans les situations de congestion et d’erreurs.

Les spécifications des machines client/serveur sont les suivantes:❚ Pentium IV, 1.8 GHz, 256 MB RAM❚ NIC 1: Intel 82801 100 Base TX❚ NIC 2: 3COM 3C905B 100 Base TX

SCTP (Stream Control Transmission Protocol) – une alternative à TCP et UDP ?

FI 9 – 18 novembre 2003 – page 16 FI 9 – 18 novembre 2003 – page 17

❚ OS: Linux Redhat 7.3 pour merlin et camelot❚ OS: FreeBSD 4.6 pour perceval et morgan❚ Software: Iperf 1.6.1 + extension pour le générateur de

trafic SCTP, dévelopé à l’EIA-FR.

Rendement & débitLa première étape de cette simulation consiste à calculer

les rendements et débits théoriques des différents protocoles en compétitition.

Nous utiliserons les variables suivantes pour nos cal-culs:

δ débit brut [b/s]B taille de la queue de réception [bytes]D taille des données transmises [bytes]H taille de l’en-tête (Ethernet + IP + TCP/UDP/

SCTP) [bytes]

HACK

taille des trames d’acquittement (Ethernet + IP + TCP/SCTP) [bytes]

iD nombre de trames à envoyer pour atteindre le vo-

lume VD

iACK

nombre minimal de trames à envoyer pour atteindre le volume V

ACK pour un buffer de réception de taille

B.

SCTP (Stream Control Transmission Protocol) – une alternative à TCP et UDP ?

fig. 7 – Plate-forme de simulation et de mesure

FI 9 – 18 novembre 2003 – page 18 FI 9 – 18 novembre 2003 – page 19

SCTP (Stream Control Transmission Protocol) – une alternative à TCP et UDP ?

n nombre de data chunks pouvant être regroupés dans un paquet IP sans dépasser le PMTU

tACK

temps nécessaire pour transmettre les acquittements (ACK ou SACK) [s]

tb temps de transmission pour 1 bit [s]

tf temps inter-trames [s]

tHD

temps nécessaire pour transmettre VH et V

D [s]

VACK

volume des acquittements [bytes]V

D volume des données transmises [bytes]

VH

volume des en-têtes [bytes]

Admettons vouloir transmettre VD bytes de

données avec des paquets de D bytes de données. Nous considérons comme hypothèse de départ que la transmission est unique sur le réseau, sans concurrence pour l’accès au médium, sans erreurs de transmission et avec un buffer de réception (B) de taille constante.

Le calcul du nombre de trames émises (iD)

et d’acquittements (iACK

)se fera de la manière suivante:

Avec n=1 dans le cas de TCP et UDP et n≥1 dans le cas de SCTP, avec n • D ≤ (PMTU - H) (correspond au nombre de chunks émis par pa-quet SCTP, nous admettons que chaque chunk a la même taille de données D).

Le volume total des données transmises dans les deux directions sera calculé de la manière suivante (sans tenir compte de l’établissement et de la fermeture de la session/association):

Avec H correspondant aux en-têtes transmis sur une trame Ethernet:

❚ TCP: HTCP = HACK =58 bytes (18 Ethernet + 20 IP + 20 TCP)

❚ UDP: HUDP = 46 bytes (18 Ethernet + 20 IP + 8 UDP)

❚ SCTP: HSCTP = 18 Ethernet + 20 IP + 12 SCTP + n · 16 DATA chunk + n · 1..3 padding

HSACK = 66 bytes (18 Ethernet + 20 IP + 12 SCTP + 16 SACK chunk)

Le calcul des temps de transmission se fera de la manière suivante:

Le calcul du débit brut1 se calculera de la manière sui-vante:

Si nous représentons de manière graphique le débit théorique des différents protocoles pour V

D= 2,8 Mb/s sur

une liaison à 100 Mb/s, B = 32’768 bytes et sans aucune erreur sur les différents médiums, nous aurons les résultats représentés sur la figure 8.

Nous avons une cassure dans le débit SCTP calculé pour D=750 bytes. Notre calcul se base en effet sur des streams de données avec D constant, et lorsque D ≥ 700 bytes, le proto-cole SCTP ne peut pas regrouper deux chunks de cette taille sinon la taille de la trame sera supérieure au MTU. Si nous avons plusieurs streams simultanés à émettre et que chaque stream a une taille de données différente pour chaque chunk, le rendement ainsi obtenu sera meilleur, ainsi que le débit.

Les résultats obtenus sont les suivants:❚ Comme nous l’avions déjà mentionné précédemment,

SCTP a un rendement de transmission meilleur que TCP et UDP pour des tailles de DATA chunks inférieures à MTU/2. Ce rendement supérieur nous donnera donc un débit théorique quasiment constant pour SCTP, quelle que soit la taille des données (grâce au regroupement de DATA chunks dans un paquet).

❚ On constate aussi que le rapport entre volume d’acquit-tements et de données transmises (en terme de bytes) est faible (< 1,5%) lorsque le volume de donnée est relative-ment élevé (> 2MB), mais lorsque le volume de données est faible (<100 KB), ce rapport est grand (>90%).Le calcul du rendement se fera de la manière suivante:

1 Par débit brut nous entendons le débit atteint pour la transmission des données avec les en-têtes nécessaires à leur transmission.

Fig. 8. Débits théoriques SCTP/TCP/UDP vs taille des données, pour VD=2.8 MB

FI 9 – 18 novembre 2003 – page 18 FI 9 – 18 novembre 2003 – page 19

La figure 9 représente le résultat du calcul du rendement pour un volume de données de 10 MB.

Multi-homing et comportement en cas d’erreurs

Comme on l’a vu précédem-ment, le multi-homing est une des fonctionnalités principales du pro-tocole SCTP. Les comportements observés lors de l’introduction d’er-reurs (au moyen de NISTnet) sur la liaison primaire, entre deux stations, sont les suivants:❚ La version actuelle de SCTP ne

fait pas de partage de charge. Un lien est le lien primaire et tous les autres liens sont en secours. Uniquement des messages de type HEARTBEAT circulent sur les liens secondaires.

❚ Lors d’une coupure franche ou d’erreurs survenant sur le lien primaire, l’émetteur va utiliser un des liens secondaires pour émettre les données vers le récepteur, comme on peut le constater sur la Figure 10. Après que le temporisateur T3-rtx a ex-piré, la retransmission du dernier DATA chunk (point A) s’effectue par le chemin secondaire (point C). Dans notre mesure, le délai entre le dernier DATA chunk reçu sur le lien primaire et sa retransmission par le lien secon-daire est de 623,6 ms. Le point B de la même figure correspond à la perte de deux SACK sur le chemin primaire.

❚ Une retransmission (point A de la Figure 11) peut amener à une duplication des données, mais grâce aux mécanismes supportés dans les SACK, ce type d’erreur est parfaitement géré. On peut observer le comportement du récepteur sur la Figure 11, où celui-ci va annoncer à l’émetteur qu’il lui manque des DATA chu-nks (point C & D) ou que des données ont été reçues plusieurs fois (point B).

❚ L’introduction de délai dans la transmission ne fait pas basculer le trafic vers un lien secondaire où le délai serait inférieur, cela serait une extension possible du protocole.

SCTP (Stream Control Transmission Protocol) – une alternative à TCP et UDP ?

fig. 10. Multi-homing, coupure du lien primaire et basculement sur le lien secondaire

fig. 11. Multi-homing, détails des acquittements sur les liens primaire et secondaire en cas d’erreur de transmission sur le lien primaire

fig. 9 – Rendement théorique SCTP vs TCP vs UDP, pour VD=10 MB

FI 9 – 18 novembre 2003 – page 20 FI 9 – 18 novembre 2003 – page 21

Conclusions

Les nouvelles caractéristiques apportées par ce protocole permettront de faire face aux limitations imposées par les protocoles actuels et de laisser la voie libre aux nouvelles applications temps réel.

Voici les commentaires d’un des concepteurs du pro-tocole SCTP, Randall Stewart, concernant le futur de ce protocole:

«And my latest question is concerning the future of SCTP, do you thing this protocol will be a major actor on Internet with TCP and UDP ? Some constructor like Cisco use this protocol for ITP, but do you know if there is emerging software/application using SCTP ?

Yes, but like anything it takes time to migrate. The UNIX Network Programming 3rd edition will have a lot of coverage of SCTP. This will help… also I think as slowly apps are pushed out (such as netflow, IUA and others) and SCTP gets more support… so will follow applications that use it… But it will be some time yet I am afraid…»

Le protocole SCTP présente des caractéristiques très inté-ressantes en tant que moyen de transport pour la signalisation SS7, et, comme indiqué dans ce document, aussi comme alternative aux protocoles TCP ou UDP dans des applications standards. L’avantage d’un nouveau protocole tel que SCTP est que tous les aspects novateurs ou optionnels des protocoles comme TCP ou UDP ont été pensés dans leur globalité pour n’en retirer que le meilleur afin de définir le SCTP.

Le multi-homing et l’augmentation de la sécurité (SYN ATTACK, Cookies) sont des caractéristiques essentielles pour les serveurs, où la fiabilité est très importante. Le concept de streams est, quant à lui, très intéressant pour la création d’ap-plications utilisées quotidiennement, comme par exemple un browser Web, un client FTP ou une application de vidéocon-férence. Actuellement, plusieurs connexions sont nécessaires, souvent de types différents (UDP, TCP), ce qui implique l’utilisation de plusieurs ports et des difficultés de gestion du réseau. Prenons l’exemple d’une transmission VoIP: les ports ouverts pour la transmission des données ne sont pas connus à l’avance, ce qui rend difficile la configuration du firewall qui protège le réseau local (LAN), de la part de l’administrateur.

De la même manière, lorsqu’une connexion est ouverte vers un serveur FTP, si un des deux points terminaux (le client ou le serveur) se trouve derrière un firewall, le mode passif est nécessaire, car le port utilisé pour la réception des données n’est pas connu à l’avance.

Enfin, l’acquittement sélectif est une caractéristique très importante lors de transmissions à longue distance, car il permet une augmentation des performances en évitant la retransmission complète du dernier bloc de données transmis.

Comme nous l’ont montré les tests en laboratoire con-cernant les fonctionnalités et les performances du protocole,

même s’il est encore assez jeune, SCTP possède déjà des implémentations libres et fonctionnelles.

Le nombre important d’entreprises qui participent au développement de SCTP, et la position de celles-ci sur le marché international de l’informatique et des télécommu-nications, sont des indices qui portent à croire que SCTP va prendre beaucoup d’importance dans le futur.

Références

1. ITU-T Recommentation Q.700: Introduction to CCITT Signalling System No.7, International Tele-communication Union, Geneva, March 1993

2. Bova T. and Krivoruchka T.: Reliable UDP Protocol, Internet-Draft, expired August 1999,

http://www.watersprings.org/pub/id/draft-ietf-sigtran-reliable-udp-00.txt

3. Ma G., T/UDP: UDP for TCAP, Internet draft, expired May 1999, http://www.watersprings.org/pub/id/draft-ma-tudp-00.txt

4. IETF: Stream Control Transmission Protocol, October 2000, http://www.ietf.org/rfc/rfc2960.txt

5. M. Molteni and M. Villari: Using SCTP with Partial Reliability for MPEG-4 Multimedia Streaming, BS-DCon Europe 2002, October 24, 2002

http://eurobsdcon.org/papers/molteni.pdf6. IETF draft: Stream Control Transmission Protocol

(SCTP) Dynamic Address Reconfiguration, February 2003, http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-addip-sctp-07

7. IETF draft: Architecture of Mobile SCTP for IP Mobi-lity Support, June 2003, http://www.ietf.org/internet-drafts/draft-sjkoh-sctp-mobility-01.txt

8. IETF: IP Mobility Support for IPv4, August 2002 http://www.ietf.org/rfc/rfc3309.txt9. IETF draft: Stream Control Transmission Protocol

(SCTP) Dynamic Address Reconfiguration, August 2002, http://www.ietf.org/internet-drafts/draft-ietf-mobileip-ipv6-22.txt

10. IETF: TCP Selective Acknoledgment Options, October 1996, http://www.ietf.org/rfc/rfc2018.txt ■

SCTP (Stream Control Transmission Protocol) – une alternative à TCP et UDP ?