FLASH INFORMATIQUE FI

Une alternative à TCP et UDP ?


SCTP (Stream Control Transmission Protocol)




Antoine DELLEY

François BUNTSCHU

Rudolf SCHEURER


Les protocoles usuels de transport de l’information dans les réseaux IP sont TCP (Transmission Control Protocol) et UDP (User Datagram Protocol). Pour répondre aux nouveaux besoins des applications 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-homing 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 alternatives 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, autorisant le transport de la signalisation au-dessus d’IP, sont apparues. Cette approche permet l’utilisation commune du coeur d’un réseau pour le trafic de transport de signalisation et de données. Le protocole Stream Control Transmission Protocol (SCTP) [4] est une solution standard à ce problème. C’est le résultat du groupe de travail Signaling Transport 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écommunications et de l’informatique sont intéressés par ce nouveau 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 relation 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 permettre 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’Internet Assigned Numbers Authority (IANA).

D’un point de vue réseau, un point terminal est l’extrémité logique du protocole de transport 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 partagent 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 associations doivent être établies (vers différents équipements terminaux). Dans le cas de la figure 3, le noeud 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 noeud A communique avec l’application 1 du noeud 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).


fig. 4. Encapsulation de SCTP dans IPv4 ou IPv6 


L’en-tête commun

L’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.

Chunks

Chaque 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) :

  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

Echange de données

Etablissement d’une association L’établissement en quatre temps d’une association entre deux noeuds SCTP peut paraître compliqué, mais la bonne nouvelle est que deux des paquets SCTP peuvent déjà transporter 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.

Cookie

Lors de l’établissement d’une association, 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’affranchir 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 structure 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 émettrice, 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 shutdown 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’association est reçue par le stack SCTP, celui-ci va s’assurer que ses queues de transmissions sont vides et qu’il a bien reçu tous les acquittements qui sont encore en attente.

Multi-homing La propriété essentielle du protocole de transport SCTP est le support des noeuds avec des connexions multiples (multihomed), c’est-à-dire des noeuds 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’évaluation. Il s’agit des drafts IETF suivants : Stream Control Transmission 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.

Stream

Alors 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 transmission.

Une autre caractéristique du protocole SCTP est de permettre 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ées

Pour 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 (Transmission 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 acknowledgment, 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 donné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 congestion

Dans 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 suivante résume les différences fonctionnelles 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).


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


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 fonctionnalité 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
• 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ébit

La 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 calculs :

δ débit brut [b/s]
B taillede 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 volume VD
iACK nombre minimal de trames à envoyer pour atteindre le volume VACK pour un buffer de réception de taille B.
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 VD [s]
VACK volume des acquittements [bytes]
VD 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 paquet 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 brut se calculera de la manière suivante :


Si nous représentons de manière graphique le débit théorique des différents protocoles pour VD= 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.

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


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 protocole 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’acquittements et de données transmises (en terme de bytes) est faible (< 1,5%) lorsque le volume de donnée est relativement é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 :


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


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


Multi-homing et comportement en cas d’erreurs Comme on l’a vu précédemment, le multi-homing est une des fonctionnalités principales du protocole SCTP. Les comportements observés lors de l’introduction d’erreurs (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 expiré, 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 secondaire 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 chunks (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.


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 


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 protocole 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’applications utilisées quotidiennement, comme par exemple un browser Web, un client FTP ou une application de vidéoconfé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 concernant 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écommunications, 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 Telecommunication 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, BSDCon Europe 2002, October 24, 2002 http://eurobsdcon.org/papers/molteni.pdf
6. 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 Mobility 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.txt
9. 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


 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.



Cherchez ...

- dans tous les Flash informatique
(entre 1986 et 2001: seulement sur les titres et auteurs)
- par mot-clé

Avertissement

Cette page est un article d'une publication de l'EPFL.
Le contenu et certains liens ne sont peut-être plus d'actualité.

Responsabilité

Les articles n'engagent que leurs auteurs, sauf ceux qui concernent de façon évidente des prestations officielles (sous la responsabilité du DIT ou d'autres entités). Toute reproduction, même partielle, n'est autorisée qu'avec l'accord de la rédaction et des auteurs.


Archives sur clé USB

Le Flash informatique ne paraîtra plus. Le dernier numéro est daté de décembre 2013.

Taguage des articles

Depuis 2010, pour aider le lecteur, les articles sont taggués:
  •   tout public
    que vous soyiez utilisateur occasionnel du PC familial, ou bien simplement propriétaire d'un iPhone, lisez l'article marqué tout public, vous y apprendrez plein de choses qui vous permettront de mieux appréhender ces technologies qui envahissent votre quotidien
  •   public averti
    l'article parle de concepts techniques, mais à la portée de toute personne intéressée par les dessous des nouvelles technologies
  •   expert
    le sujet abordé n'intéresse que peu de lecteurs, mais ceux-là seront ravis d'approfondir un thème, d'en savoir plus sur un nouveau langage.