sctp rapport v11 -...

Stream Control Transmission Protocol (SCTP)

Rapport

Projet Ra&D HES-SO Objet No : TI01-02

François Buntschu Ecole d’ingénieurs et d’architectes de Fribourg

Email : [email protected]

Fribourg, le 30 août 2003

Remerciements

i

Chapitre

I Remerciements

Pour l’aide apporté à ce projet dans le cadre de son projet de diplôme Eduswiss et pour ses précieux conseils qui ont facilité la réalisation de ce travail, j’aimerai remercier Aron Bernasconi, ex-collaborateur à l’Ecole d’Ingénieurs de Fribourg. Un merci particulier va aussi aux promoteurs de ce projet, Antoine Delley et Rudolf Scheurer, professeurs à l’Ecole d’Ingénieurs et d’Architectes de Fribourg, pour leur grande disponibilité et leur soutien. Je tiens, en outre, à remercier Christophe Schaer, collaborateur à l’Ecole d’Ingénieurs de Fribourg, qui m’a déchargé de bien des tâches de laboratoires afin que je puisse me consacrer à ce projet.

Introduction

ii

Chapitre

II Introduction

Les protocoles usuels de transport de l'information dans les réseaux IP sont TCP (Transport 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). Bien que développé pour le transfert de la signalisation dans les environnements VoIP, ce protocole est appelé, dans un avenir proche, à couvrir un spectre beaucoup plus large de besoins. Les différences principales avec TCP sont le multihoming 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). Les attaques simples de type SYN attack qui affecte TCP ne sont plus possibles avec SCTP. Ce nouveau protocole inclu aussi des mécanismes protégeant les applications contre le Head of Line Blocking (HOL) en utilisant des flux. De plus, des fonctionnalités qui sont optionnelles dans TCP ont été inclus dans la spécification de base de SCTP, tel que le Selective Acknovledgments, permettant d’annoncer la réception de datagrammes dupliqués ou encore le support de Explicit Congestion Notification (ECN).

Figure 1 : Modèle OSI

Layer 1

Layer 2

Layer 3

Layer 4

Layer 5-7

Ethernet, IEEE802.2/802.3 802.5/802.11, …

IP

TCP, IP, SCTP

FTP, Telnet, …

iii

Introduction

Une association SCTP aura l’allure suivante, de manière identique au protocole de transport TCP et UDP :

Figure 2 : Association SCTP

Nœud SCTP A

SCTP User application

SCTP Transport service

IP Network Service

@IP1 @IP2 @IPn ..

Nœud SCTP B

SCTP User application

SCTP Transport service

IP Network Service

@IP1 @IP2 @IPn ..

IP Network (Réseau de transport)

SCTP association

Table des matières

iv

Table des matières

I REMERCIEMENTS ....................................................................................................................... I II INTRODUCTION........................................................................................................................ II III OBJECTIFS..................................................................................................................................1

1 Introduction.....................................................................................................................................1 2 Objectifs ...........................................................................................................................................1 3 Méthode de travail ..........................................................................................................................2 4 Structure de la documentation de projet ......................................................................................2

IV HISTORIQUE DU SCTP.............................................................................................................3 V PROTOCOLES DE L’INTERNET..............................................................................................4

1 SCTP ................................................................................................................................................4 1.1 Terminologie ................................................................................................................................4 1.2 Format des trames.........................................................................................................................7 1.3 Etablissement d’une association ...................................................................................................9 1.4 Cookie...........................................................................................................................................9 1.5 Fermeture d’une association .......................................................................................................10 1.6 La transmission de données ........................................................................................................10 1.7 Multihoming ...............................................................................................................................12 1.8 Stream.........................................................................................................................................12 1.9 Contrôle d’erreur ........................................................................................................................13 1.10 Sécurité : TLS over SCTP ..........................................................................................................14

2 Protocole SCTP vs UDP/TCP ......................................................................................................15 3 Variantes & extensions du protocole TCP..................................................................................16

3.1 TCP Tahoe..................................................................................................................................16 3.2 TCP Reno ...................................................................................................................................16 3.3 TCP Vegas..................................................................................................................................16 3.4 TCP Eifel ....................................................................................................................................16 3.5 T/TCP .........................................................................................................................................17 3.6 TCP pour liaison satellite ...........................................................................................................18 3.7 TCP pour liaison sans fil ............................................................................................................18

VI INTERFACE DE PROGRAMMATION .................................................................................20 1 Introduction...................................................................................................................................20 2 Socket API de SCTP .....................................................................................................................20 3 Socket API de TCP .......................................................................................................................21 4 Socket API de UDP .......................................................................................................................21 5 Implémentation de référence .......................................................................................................21

VII AUTRES IMPLÉMENTATIONS SCTP ................................................................................22 1 Introduction...................................................................................................................................22 2 Implémentations libres .................................................................................................................22

2.1 Université de Essen - Siemens....................................................................................................22 2.2 Linux Kernel SCTP (lksctp project) ...........................................................................................23 2.3 KAME Project ............................................................................................................................23 2.4 Open SS7 ....................................................................................................................................23 2.5 RivuS ..........................................................................................................................................24

VIII PLATEFORMES DU MARCHÉ...........................................................................................25 1 Introduction...................................................................................................................................25 2 Implémentations commerciales....................................................................................................25

2.1 Adax ...........................................................................................................................................25 2.2 Compaq.......................................................................................................................................25 2.3 DataConnection ..........................................................................................................................25 2.4 Sun Microsystems.......................................................................................................................26 2.5 Cisco ...........................................................................................................................................26

v

Table des matières

2.6 Ericsson ......................................................................................................................................26 2.7 Siemens.......................................................................................................................................26 2.8 Trillium.......................................................................................................................................27 2.9 Ulticom .......................................................................................................................................27 2.10 Motorola .....................................................................................................................................27 2.11 Autres entreprises .......................................................................................................................27

3 Comparaison entre les différentes applications .........................................................................28 IX TESTS ET PLATEFORME DE TEST.....................................................................................29

1 Générateur de trafic SCTP/TCP/UDP........................................................................................29 1.1 Développement du logiciel .........................................................................................................29

2 Plateforme de test..........................................................................................................................31 2.1 Architecture logique ...................................................................................................................32 2.2 Architecture physique.................................................................................................................34

3 Mesures ..........................................................................................................................................35 3.1 Tests fonctionnels & comparaisons avec UDP, TCP .................................................................35 3.2 Performances ..............................................................................................................................41 3.3 Tests en réseau réel.....................................................................................................................45 3.4 Tests d’applications SCTP..........................................................................................................46

X PROBLÈMES RENCONTRÉS ..................................................................................................47 1 Plateforme de développement ......................................................................................................47 2 Equipements de mesure................................................................................................................47 3 Planning .........................................................................................................................................47

XI CONCLUSIONS .........................................................................................................................48 1 Aspect innovateur .........................................................................................................................48 2 Future du protocole SCTP ...........................................................................................................48 3 Suite du projet ...............................................................................................................................49

XII ANNEXES..................................................................................................................................50 1 Contenu du CDROM....................................................................................................................50

XIII INDEX ......................................................................................................................................51 XIV RÉFÉRENCES.........................................................................................................................52 XV LISTE DES TABLES................................................................................................................55 XVI LISTE DES FIGURES ............................................................................................................56 XVII LISTE DES ABRÉVIATIONS ET DES ACRONYMES ..................................................57 XVIII HISTORIQUE.......................................................................................................................59

Objectifs

1/65

Chapitre

III Objectifs

1 Introduction L’objectif principal du projet est de créer un document de référence sur le protocole SCTP en se basant sur les documents existants (RFC, publications, articles, livres), sur l'étude théorique des caractéristiques de SCTP et sur les mesures et analyses effectuées en environnement réel. Ce document devra permettre au lecteur d’acquérir des connaissances sur le protocole (fonctionnement, avantages et inconvénients par rapport à TCP ou UDP), de connaître ses champs d’application et ses implémentations existantes, et de pouvoir l’implémenter rapidement dans une application propriétaire. Pour pouvoir effectuer une comparaison du protocole SCTP, par rapport à UDP et TCP, il sera nécessaire d’étudier et de déployer une plateforme de test qui nous permettra de simuler des conditions particulières du protocole et d’effectuer des mesures de qualité et de performance. Cette plateforme devra nous permettre de tester les nouvelles fonctionnalités proposées par SCTP.

2 Objectifs

Les objectifs généraux du présent projet sont les suivants:

1. Etendre nos compétences dans les protocoles d'Internet.

2. Maintenir des compétences élevées dans le domaine de la qualité des services sur les réseaux IP.

3. Etre en mesure de mettre sur pied de futurs projets de Ra&D dans le domaine du test des réseaux et de la qualité des services.

4. Acquérir les connaissances nécessaires à la mise à jour des cours postgrades et de la formation de base (mise à jour des livres « Téléinformatique, ISBN 2-940156-12-3 » et « Voix sur IP et multimédia, ISBN 2-940156-17-4 ») .

5. Disposer d'une plate-forme d'expérimentation pour des projets d'étudiants (projets de semestre et de diplôme).

Dans le détail, nous allons :

1. Décrire l’historique du protocole

2. Décrire le protocole, son fonctionnement, ses champs d’application

3. Définir et disposer d’une plateforme de test

4. Effectuer diverses mesures et en relater les résultats

2/65

Objectifs

De plus, nous allons donner un compte rendu sur les tests effectués sur la plateforme qui a été mise en place dans le cadre de ce projet. Le document complet des mesures se trouve en annexe à ce rapport [BB-TEST]. Nous donnerons aussi un aperçu de la présence du SCTP sur le marché des télécommunications et de l’informatique.

3 Méthode de travail La méthode de travail adoptée dans le cadre de ce projet est la suivante : Analyse contextuelle: recherche des informations, étude du protocole

o Le RFC2960 o Les autres documents traitant le SCTP o Les implémentations actuelles du SCTP

Description de l’implémentation du protocole SCTP dans des applications propriétaires Définition, mise en place de la plate-forme de mesure

o Design du réseau o Choix des composants du réseau o Choix des instruments de mesure (applications, analyseurs de réseau)

Définition des tests à effectuer o Performances o QoS

Mesures en environnement réel Synthèse des résultats, définition d’une structure de présentation des informations Rédaction du rapport final (au fur et à mesure de l’avancement des travaux)

4 Structure de la documentation de projet Dans le cadre de ce projet, plusieurs documents auront été écrits. En voici la structure :

Figure 3 : Structure de la documentation

Rapport

Plateforme de tests &

Mesures

Description du protocole

SocketAPI

Historique du SCTP

3/65

Chapitre

IV Historique du SCTP

Les réseaux de télécommunication 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, elle permet également l'approvisionnement des services de réseau avancés, tel 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 beaucoup d'années, le système de signalisation numéro 7 (SS.7) [ITU-Q700] a été le porteur dominant de la signalisation pour des 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) [BOV1999] ou encore UDP for TCAP (T/UDP) [MA1998], mais ces extensions ne remplissaient pas tous les critères requis pour la transmission de la signalisation sur un réseau IP, tel que l’acquittement sélectif ou le contrôle de congestion. Récemment, beaucoup de solutions propriétaire 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) [RFC2960] 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 [SCTP-API]. 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 et il est beaucoup plus flexible comparé à ses prédécesseurs TCP et UDP. Comme on peut le constater dans les diverses études faite de ce protocole, son application ne se limitera pas uniquement au transport de la signalisation sur IP, mais aussi au transport d’application multimédia [MOL-MPEG].

Protocoles de l’Internet

4/65

Chapitre

V Protocoles de l’Internet

1 SCTP La description complète du protocole SCTP fait partie du document en annexe à ce rapport [BB-DES], nous allons ici résumer les caractéristiques principales de ce protocole. 1.1 Terminologie 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 qui s’établie entre pour permettre l’échange d’informations s’appelle une association. 1.1.1 Adresse de transport Comme tous les protocoles usuels de transport tels que TCP ou UDP, SCTP nécessite l’utilisation de numéro de port pour identifier l’application de la couche supérieure. Ces numéros de port sont assignés par l’Internet Assigned Numbers Authority (IANA). Dans le cadre de SCTP les numéros énumérés dans le document [IAN-SCTP] sont réservés. 1.1.2 Point terminal 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 mentionnée de la manière suivante :

Point terminal = [adresse IP : port SCTP] Dans le cas d’une connexion multiple (multihomed), 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 lesquels 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). Cet exemple est représenté dans la Figure 4.

5/65


Figure 4 : Multihoming et transport

Dans ce cas, le nœud A est l’équipement terminal pour deux associations SCTP qui seront décrite 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]. 1.1.3 Association Comme mentionné précédemment, SCTP est un protocole de transport orienté connexion. Ceci implique que les points terminaux doivent suivre une procédure d’établissement de connexion. Cette relation entre les deux équipements terminaux est appelée association SCTP.

Un exemple d’association est représenté dans la Figure 5.

Nœud SCTP A

IP Network Service

NIC NIC NIC

IP Network

@IP1 @IP2 @IP3

SCTP Transport Service

Port 1 Port 2

Appl. 1 Appl. 2

6/65


Figure 5 : Exemple d'une association SCTP

Dans notre exemple l’application 1 du nœud A communique 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]} Remarque : Dans aucun cas de figure il ne peut y avoir plus d’une association entre la

même pair de points terminaux. Cependant, on peut avoir des associations concurrentes vers différents points terminaux.

Nœud SCTP B

IP Network Service

NIC

@IP


Port 1

Appl. 1

Nœud SCTP A

IP Network Service

NIC NIC NIC

IP Network

@IP1 @IP2 @IP3


Port 1 Port 2

Appl. 1 Appl. 2

7/65


1.2 Format des trames Les trames SCTP sont transportées dans des paquets IP, de manière identique à TCP ou UDP.

Figure 6 : Encapsulation de SCTP sur IPv4

Header Data

>= 20 octets

IP Packet

Padding Options 0 to 40 bytes

Destination Address

Source Address

Version = 4 H Type of Service Total Length (bytes)

Identification Fragment Offset (8 bytes) 0 D

M

Time to Live Protocol = 132 Header Checksum

32 bits

Header Data SCTP Packet

Source port number

Verification Tag

CRC-32c checksum

32 bits

Destination port number

Chunk type

Chunk Data

32 bits

Chunk length Chunk flags

Chunk type

Chunk Data


Chunk type

Chunk Data


Chunk 1

Chunk 2

Chunk n

8/65


1.2.1 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. Lors de l’encapsulation de SCTP dans IPv4 ou IPv6, et lors de tous types de communications SCTP, l’en-tête principal aura le format suivant :

Figure 7 : En-tête SCTP

1.2.2 Chunks Chaque chunk a un champ Type, qui permet d’identifier le transport des données et les information de contrôles. Les chunks ont une taille variable. Il existe treize types différents de Chunks (extrait du RFC 2960) : 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 : Chunk type

Source port number

Verification Tag

CRC-32c checksum

32 bits

Destination port number

9/65


1.3 Etablissement d’une association L’é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à 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é. 1.3.1 Processus en quatre temps Afin de palier aux problèmes de l’établissement de la connexion (processus en trois temps, [COM-1996]) du protocole TCP, tels que les SYN attacks ou les demi-connexions (DoS, Denial of Service, [RFC2267]), le processus d’établissement d’une connexion SCTP est défini en quatre temps. De plus, les critères suivants ont été définis :

• Le serveur ne doit pas réserver le moindre espace mémoire avant que l’association ne soit complètement établie.

• Il est nécessaire d’avoir un mécanisme permettant de reconnaître que le client (initiateur de la connexion) utilise son adresse IP réelle.

Figure 8 : Processus d'établissement en quatre temps

1.4 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 ([BB-DES]). Comme l’utilisateur principal du cookie est l’émetteur du INIT-ACK, 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, pour qui le cookie n’a aucune signification. Comme l’intention est de déplacer vers

INIT

INIT-ACK

COOKIE-ECHO

COOKIE-ACK

Client Server

CLOSED CLOSED

COOKIE-WAIT

ESTABLISHED

COOKIE-ECHOED

ESTABLISHED

DATA Exchange

10/65


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. 1.4.1 Prévention des attaques sur les ressources Il est primordial que le nœud SCTP qui émet le INIT-ACK ne garde aucune trace en mémoire de cette association. Comme mentionné précédemment, l’intention est de déplacer vers le client et le réseau la tâche de sauvegarde des informations d’établissement d’association. Toutes les informations nécessaires à la réservation des ressources pour cette association sont placées dans le cookie, ce qui ne nécessite pas la création d’un TCB à cet instant. Le choix de l’algorithme de hashing pour la signature du cookie est aussi important. En effet, la complexité du calcul des ces algorithmes diffère et pourrait déboucher sur une attaque des ressources CPU. 1.5 Fermeture d’une association 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. 1.5.1 Processus en trois temps 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 le stack a reçu la notification qu’il doit interrompre l’association, il va s’assurer que ces buffers de transmissions sont vides et qu’il a bien reçu tous les acquittements qui sont encore en attente.

Figure 9 : Processus de libération

1.6 La transmission de données

SHUTDOWN

SHUTDOWN-ACK

SHUTDOWN_COMPLETE

Client Server

CLOSED

CLOSED

ESTABLISHED

Check outstanding data chunks, then

SHUTDOWN_PENDING

ESTABLISHED DATA Exchange

SHUTDOWN_SENT

SHUTDOWN_RECEIVED

Check outstanding data chunks, then

SHUTDOWN_ACK_SENT

11/65


1.6.1 Concept général Pour la transmission des données, deux chunks sont utilisés :

• DATA chunk – utilisé par le host qui transmet les données, il contient les données envoyées • SACK chunk – utilisé par le host qui reçoit les données pour les acquitter

Chaque DATA chunk est identifié par son TSN. Les TSN, qui sont consécutifs, indiquent le numéro du chunk. Chaque SACK qui revient à l’émetteur de données contient dans le champ Cumulative TSN acknowledgment le TSN du dernier DATA chunk à acquitter. 1.6.2 Contrôle de flux 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. 1.6.3 Acquittement sélectif Le SACK chunk (Selective Acknowledgement) contient les champs Cumulative TSN acknowledgment et Gap Ack Blocks. Le host qui a envoyé des données (DATA chunk), reçoit en retour dans le SACK 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ù la, les bytes sont acquittés, et non pas les trames reçues. 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. Avec ce champ, on peut acquitter des DATA chunks qui ont été retransmis, et des DATA chunks qui sont arrivés correctement au premier envoyé, mais qui ne sont plus en séquence, car les DATA chunk avec un TSN inférieure ne sont pas arrivées. 1.6.4 Contrôle de congestion Dans le cas d’un réseau réel, la congestion peut se trouver à deux endroits : au récepteur (taille des buffers trop petite) ou dans le réseau (bande passante de la liaison atteinte). Dans le premier cas, le problème est résolu avec le champ « Advertised Receiver Window Credit », qui se trouve dans les chunks de type INIT, INIT-ACK et SACK, un peut comme dans le cas de TCP. Le deuxième cas, plus complexe à gérer, est résolu de la manière suivante à l’aide de plusieurs algorithmes. Ces algorithmes sont les mêmes que ceux utilisé 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 suspend »

• 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.

12/65


1.7 Multihoming

La propriété essentielle du protocole de transport SCTP est son appui des nœuds à connexions multiples (multihomed), c’est-à-dire des nœuds qui peuvent être atteints par plusieurs adresses IP. Le multihoming spécifié dans le protocole SCTP uniquement pour la redondance, la répartition de charge ne fait pas partie de [RFC2960] et est toujours à l’étude.

1.7.1 Multihoming 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 : [ADDIP] et [MSCTP] Ceux-ci sont une extension à la fonctionnalité Mobile IP disponible dans IPv4 [RFC3344] et IPv6 [DRAFT-IPv6m]. Mobile SCTP (mSCTP) 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 (DDNS). La fonctionnalité principale permettant de maintenir une association active lors d’un changement de réseau IP est la fonction ADDIP, défini dans [ADDIP] et permettant de modifier/supprimer/ajouter une adresse IP faisant partie de l’association, sans que celle-ci soit interrompue. 1.8 Stream Alors que le protocole de transport TCP relie le transfert fiable de données utilisateur avec la livraison ordré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. Quelques 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 garantit aucun ordre de transmission. 1.8.1 Concepts Généraux SCTP distingue différents flux (Stream) de message dans une association. Ceci permet d’avoir un schéma de livraison où seulement l’ordre des messages doit être maintenu par flux. En outre, SCTP fournit un mécanisme pour contourner le service de livraison ordonnancé, de sorte que des messages soient fournis à l'utilisateur dès qu'ils seront complètement reçus (livraison dans l'ordre d’arrivée). Le contrôle de flux et de congestion a été définie de telle manière à ce que le comportement de SCTP dans un réseau soit le même que TCP. SCTP opère à deux niveaux:

• Dans une association le transfert fiable des datagrammes est assuré en employant un total de contrôle (checksum), un numéro de séquence et un mécanisme sélectif de retransmission.

• Le deuxième niveau réalise un mécanisme de livraison flexible qui est basé sur la notion de plusieurs flux (stream) indépendants dans une association.

13/65


1.8.2 La livraison flexible de datagramme L'utilisateur de SCTP peut assigner chaque datagramme à un ou plusieurs stream dans une association. Lors de l’établissement d’une association, le nombre de stream disponibles par direction est échangé entre les partenaires. Chaque stream est identifié par un SSN (Stream Sequence Number). Ces numéros de séquence sont employés au niveau récepteur pour déterminer l'ordre de la livraison. SCTP effectue une livraison ordrée par stream (pour tous les datagrammes qui ne sont pas marqués pour la livraison out-of-order). Ce mécanisme évite le Head-of-Line Blocking1 entre les streams indépendants d'une association. Avec TCP, ceci pourrait être réalisé uniquement en établissant plusieurs sessions (un par stream). 1.9 Contrôle d’erreur Une des fonctionnalités importantes intégrée dans le protocole SCTP est la détection et la résolution de pannes. Il s’agit de fonctions très importantes lorsque le récepteur des données a de multiples connexions. Les cas typiques de pannes sont :

• La retransmission • La détection d’une panne sur un chemin (Path failure) • Un des participants est en panne (End-point failure)

1.9.1 Détection de l’accessibilité Une instance SCTP surveille en permanence tous les chemins vers son partenaire. Pour effectuer cette surveillance, un HEARTBEAT chunk est émis sur toutes les interfaces IP (tous les chemins) et celui-ci devra être acquitté par un HEARTBEAT-ACK chunk. 1.9.2 Retransmission Afin de déterminer si un DATA chunk a été perdu dans le réseau (absence de SACK), l’émetteur démarre un temporisateur (T3-rtx), chaque fois qu’un DATA chunk est émis. Il y a deux stratégies pour gérer ce temporisateur :

1. utiliser un temporisateur unique pour chaque adresse de destination 2. utiliser un temporisateur pour chaque DATA chunk émis

Les deux méthodes sont efficaces pour la détection de la perte de donnée. 1.9.3 Path failure Une adresse de destination peut devenir inaccessible lorsque sur le chemin primaire entre l’émetteur et le récepteur se trouve une panne (hardware, software). Cette détection est effectuée au moyen des chunks HEARTBEAT et HEARTBEAT-ACK. L’émission de données vers le destinataire ne sera pas interrompue, le protocole basculant l’émission des données vers une autre adresse de destination faisant partie de l’association. 1.9.4 End-point failure 1 TCP contrôle l’arrivée des messages de manière séquentielle. Dans une session, le récepteur va transmettre les messages reçus aux couches supérieures dans le même ordre dans lequel ils ont été émis. Dans le cas de la perte d’un des messages intermédiaire, tous les messages suivants déjà reçus ne seront transmis aux couches supérieures que lorsque l’émetteur aura retransmis le message perdu.

14/65


Un point terminal est déclaré inaccessible lorsque toutes ces adresses faisant parties de l’association sont inaccessibles (panne hardware, software ou sur le réseau interconnectant les partenaires). Dans ce cas l’association passera dans l’état « CLOSED » 1.10 Sécurité : TLS over SCTP Afin d’augmenter la sécurité d’une connexion SCTP, le [RFC3436] décrit comment utiliser le protocole TLS (Transport Layer Security) au dessus de SCTP. TLS est en effet prévu pour fonctionner sur le protocole TCP. Le but principal de TLS (ou SSLv3.0) est de garantir l’intégrité et la confidentialité des données entre deux partenaires.

15/65


2 Protocole SCTP vs UDP/TCP La table suivante résume les différences fonctionnelles entre les protocoles UDP, TCP et SCTP. UDP TCP SCTP Démarrage Aucun établissement de

connexion. Etablissement de la connexion en 3 temps.

Etablissement de l’association en 4 temps, avec échange de cookie. L’échange de data peut être effectué déjà dans le 3ème message d’établissement (dans COOKIE-ECHO et COOKIE-ACK)

Assurance de la livraison (fiabilité)

Aucun acquittement des messages, aucune assurance de livraison.

Acquittement des messages pour assurer la transmission. L’acquittement sélectif est optionnel dans TCP ([RFC2018])

Acquittement des messages pour assurer la transmission. L’acquittement est sélectif ; seul les messages erronés sont retransmis.

Ordre de livraison

Aucun mécanisme mis en œuvre pour assurer l’ordre de messages.

Numérotation des messages pour assurer l’ordre.

Les messages peuvent être ordrés ou non ordrés. Même les messages non ordrées gardent une assurance de livraison.

Contrôle de congestion

Aucun mécanisme mis en œuvre.

Mis en œuvre des mécanismes de contrôle de congestion (Additive Increase, Multiplicative Decrease).

Mis en œuvre des mécanismes de contrôle de congestion (Additive Increase, Multiplicative Decrease).

Procédure de fermeture

Aucune (protocole non orienté connexion)

Fermeture de la connexion spécifiée. Le mode « half-closed » est possible.

Fermeture de l’association spécifiée. Le mode « half-closed » n’est pas possible.

SYN attack Insensible (aucune connexion effectuée).

C’est un des problèmes de TCP.

Résolu avec le cookie.

Head-of-Line Blocking

Insensible Partiellement résolu en ouvrant plusieurs connexions.

Résolu car SCTP permet plusieurs streams (non bloquantes entre eux) dans la même associations.

Multi-homing Pas supporté. Pas supporté. Supporté. Table 2 : Différences entre UDP-TCP-SCTP

16/65


3 Variantes & extensions du protocole TCP Afin de palier au divers lacunes du protocole TCP, des extensions ont été proposées (et implémentées) dans le monde internet. Nous allons faire ici un bref aperçu de ces différentes variantes. 3.1 TCP Tahoe TCP Tahoe est une version de TCP dont le comportement en cas de congestion diffère. TCP Tahoe utilise trois algorithmes qui sont les algorithmes de Slow-Start, Congestion Avoidance et Fast Retransmit, décrits dans le [RFC2581]. Pour plus de détails, se référer à [ISOC-TCP]. 3.2 TCP Reno TCP Reno est similaire à TCP Tahoe, excepté qu'il modifie l'algorithme de Fast Retransmit pour inclure le mécanisme de Fast Recovery. Ce nouvel algorithme permet d'éviter que le canal de communication ne soit vide après un Fast Retransmit évitant ainsi le besoin de démarrer le Slow-Start pour le remplir de nouveau après la perte d'un seul paquet. Pour plus de détails, se référer à [ISOC-TCP], [STE-TCP] et [BB-DES]. 3.3 TCP Vegas TCP Vegas est similaire à TCP Reno, excepté qu’il modifie l’algorithme Congestion Avoidance. En résumé, il modifie dynamiquement sa fenêtre de transmission en analysant les intervalles RTT, alors que TCP Tahoe/Reno incrémente leur fenêtre de transmission jusqu’à ce que la perte de paquet soit détectée. Pour plus de détails, se référer à [ISOC-TCP] et [BB-DES]. 3.4 TCP Eifel Cette version du protocole TCP ne touche pas aux algorithmes de contrôle de congestion, mais se consacre à l’amélioration des performances par des modifications du contrôle des erreurs. TCP Eifel a ces trois nouvelles fonctionnalités (en comparaison à TCP) :

1. L’algorithme Eifel, décrit par le draft [EIFEL-ALG]. Cette algorithme élimine les ambiguïtés des retransmissions due aux erreurs de temporisateur ou de l’algorithme Fast retransmit.

2. Eifel retransmission timer, décrit par le draft [BER-RETR]. 3. « Retransmit forever », aucun draft ne décrit actuellement cette fonctionnalité

Les motivations de cette fonctionnalité sont les suivantes : TCP standard fermera une session après 12 retransmissions infructueuses, cela dure environ 9 minutes. Cette décision ne devrait pas être pris par TCP mais par l’application qui doit décider quant la session est considérée comme inactive.

17/65


3.5 T/TCP Pour les applications réseau générant de courte transaction, le développeur se trouve face à un dilemme : doit-il utiliser UDP ou TCP ? S’il choisit UDP, cette solution sera rapide car le temps attendu par le client sera d’un intervalle RTT. Par contre le gain en temps sera pénalisé par le manque de contrôle de transmission. En effet les informations peuvent arriver à destination dans le désordre. Dans le cas de TCP, le temps d’établissement (en trois temps), l’utilisation d’acquittement et la fermeture de la session devront s’ajouter au temps minimum d’échange des données qui sera de deux intervalles RTT. TCP for Transactions (couramment appelé T/TCP) [RFC1644] tente d’augmenter les performances de petites transactions tout en conservant le contrôle de transmission proposé par TCP. T/TCP place les données et positionne le bit FIN dans le paquet initial d’ouverture de session qui a le bit SYN positionné. On peut interpréter cela comme étant une ouverture de session avec transmission de donnée et fermeture de session incluse. Si le serveur accepte ce type de format, il répond par un paquet unique contenant les bits SYN, ACK et FIN positionné, ainsi que les données en réponse. Si le serveur ne supporte pas ce type d’échange, le client peut toujours retourner à un système classique de transmission par TCP. Pour le client, le temps de transmission de cette transaction est d’un intervalle RTT, une période équivalente à une transaction par UDP, tout en permettant au deux systèmes d’avoir un échange de donnée sous contrôle. T/TCP requiert des changements à la pile de protocole IP, autant du côté du client que du serveur. T/TCP n’est pas couramment utilisé sur Internet aujourd’hui, principalement par le fait que malgré l’augmentation des performances au niveau de la transaction, le fait d’avoir simplifier l’établissement de la session le rend plus vulnérable aux attaques.

Figure 10 : Opérations T/TCP

T/TCP SYN + Response DATA + FIN

T/TCP SYN + Response DATA + ACK + FIN

ACK

Client Server

Wakeup Close

Send Request Read

Accept

Wakeup Process Request

Send Response

18/65


3.6 TCP pour liaison satellite Les services de données basés sur des liaisons satellites pose des problèmes de base que sont les délais, erreurs de transmission et la bande passante. A l'aide d'une liaison satellite, il y a un retard inhérent dans la livraison d'un paquet dû aux temps de propagation du signal, liés à l'altitude des satellites de communications. Les satellite avec une orbite géostationnaire sont situés à une altitude d'environ 36.000 kilomètres, et le temps de propagation pour un signal d'une station terrestre directement au-dessous du satellite au satellite varie de 240 ms à 280 ms, ce qui nous donne un RTT entre 480 et 560 ms. La largeur de bande disponible est également limitée. Les fréquences porteuses typiques pour des services par satellite commerciaux sont 6/4 gigahertz (C-Band) et 14/12 gigahertz (Ku Band). La largeur de bande d’un transpondeur est en général 36 mégahertz. Comme les délais sont élevés pour ce type de liaison, une session TCP peut avoir une grande quantité de donnée en cours de transmission sur la liaison. Par exemple, un chemin typique qui inclut un satellite peut avoir un RTT d'environ 700ms. Si la largeur de bande maximale est de 2 Mbps, alors un expéditeur devra stocker dans ces queues d’émission 180 KB de données pour utiliser entièrement la largeur de bande disponible. Même avec des techniques avancées, les canaux satellites montrent un BER (Bit Error Rate)1 plus élevé que les réseaux terrestres typiques. TCP interprète la baisse de paquet comme une congestion de réseau, et réduit la taille de la fenêtre de transmission afin d'essayer d'alléger la situation. Sans savoir si un paquet a été perdu en raison d’une congestion ou d’une corruption, TCP doit assumer que cette perte a été provoqué par une congestion afin d'éviter l'effondrement de congestion [FLO-CON][JAC-CON]. Par conséquent, les paquets perdus en raison de corruption forcent TCP à réduire la taille de sa fenêtre d'émission, malgré que ces perte de paquet ne signalent pas de congestion dans le réseau. Pour atténuer ceci, un certain soin doit être pris avec la taille du Maximum Transmission Unit (MTU) d'une liaison satellite, pour réduire la probabilité de la corruption de paquet. Quant au long délai de transmission, ceux-ci vont être un facteur pénalisant pour les transactions courtes, tels que du trafic web. Par l'exemple, si une transaction exige le transfert de dix paquets, l'algorithme slow-start enverra un paquet unique dans le premier intervalle de RTT, deux dans le deuxième intervalle, quatre dans le troisième, et les trois paquets restants dans le quatrième intervalle de RTT. Indépendamment de la largeur de bande disponible du chemin, la transaction prendra quatre intervalles RTT au minimum. Pour palier à toutes ces lacunes certaines options sont recommandées pour qu’un tel type de transmission soit efficace, le [RFC2488] défini ces diverses options. 3.7 TCP pour liaison sans fil Un des environnements les plus critiques pour les protocoles de l’Internet et pour TCP en particulier, sont les réseaux mobiles. Une approche à l'environnement sans fil est celle du prétendu "jardin muré." Ici les protocoles en service dans l'environnement sans fil sont spécifiquement adaptés au monde sans fil. Les protocoles de transport supportent la faible largeur de bande, la latence plus longue, le BERs, ainsi que la variabilité de chacun de ces trois métriques. Dans ce modèle, les applications d'Internet dialogue avec une passerelle pour atteindre le monde sans fil, et cette passerelle emploie un protocole transport spécifique au réseau sans fil. Un exemple typique de cette configuration est le Wireless Access Protocol Forum (WAP). Une autre alternative est de ne pas utiliser de passerelle et de considéré chaque équipement mobile comme un client Internet.

1 BER : Bit Error Rate, correspond au taux de perte d’un bit sur une liaison.

19/65


Le facteur principal pour un réseau sans fil est le BER, où la perte de trame peut atteindre 1 %, ce qui n'est pas rare, et les erreurs se produisent par rafales plutôt que lors d’une transmission espacée de bits. Dans le cas du TCP, de telles conditions d'erreur forcent l'expéditeur à d’abord retransmettre les segments absents, et si ceci ne corrige pas le problème, l'expéditeur aura un ACK Timeout, entraînant l’effondrement de sa fenêtre de transmission et il devra réémettre les paquets perdus en mode slow-start. Le coeur de ce problème est cette prétention de la part de TCP que la perte de paquet est un symptôme de congestion de réseau plutôt que corruption de paquet. Les recommandations du [RFC2488] sont aussi valable pour les réseaux sans-fils, ainsi que diverses extensions de TCP, comme le fait de découpler le contrôle de congestion du contrôle de la perte de paquets. Cette approche se nomme Forward Acknowledgment with Rate Halving [RFC2760], avec un paquet émis pour chaque deux ACK reçus, alors que TCP effectue la retransmission des paquets perdus. Plusieurs analyses ont été effectuée afin d’évaluer l’influence des pics de délai pour différents protocoles dans un réseau sans fils, voir [FU-MOB] pour plus d’informations.

Interface de programmation

20/65

Chapitre

VI Interface de programmation

1 Introduction Le socket est défini dans [RFC147] comme une référence unique composée par une adresse (par exemple IP) et un numéro de port. On utilise souvent le mot socket pour indiquer un objet software qui fait le lien entre une application et un protocole réseau. En ce qui concerne UNIX, par exemple, on peut envoyer et recevoir des messages TCP/IP en ouvrant un socket et en écrivant / lisant son contenu. Ce mécanisme simplifie beaucoup la programmation, car le programmeur doit connaître uniquement comment utiliser le socket. Il peut donc faire abstraction de la procédure nécessaire à transporter l’information sur le réseau. Une API (Application Program Interface) est une liste de routines et de définitions utilisées pour programmer une application. Dans ce cas spécifique, le socket API indique l’ensemble des fonctions et des définitions qui permettent de manipuler les sockets. Dans ce chapitre seront résumé le fonctionnement et l’utilisation du Socket API décrit dans l’internet draft « Sockets API Extensions for Stream Control Transmission Protocol » [SCTP-API]. Pour plus de détails, se référer au document en annexe [BB-API].

2 Socket API de SCTP Le but de l’internet draft « Sockets API Extensions for Stream Control Transmission Protocol » [SCTP-API] est de définir une méthode pour interfacer les sockets API existants pour l’utilisation avec SCTP, en fournissant compatibilité et des nouvelles options, de manière à rendre la migration des application TCP vers SCTP le plus simple possible. Les trois objectifs fixés par la spécification du socket API sont :

Maintenir la cohérence avec les autres sockets API (UDP, TCP, IPv4, IPv6) ; Etre compatible du point de vue sémantique, avec l’interface UDP ; Etre compatible du point de vue sémantique, avec l’interface TCP.

Le troisième but est de permettre la migration d’une application TCP en SCTP avec très peu de modification dans le code. Comme le deuxième et le troisième but ne sont pas compatibles, deux modes de fonctionnement séparés ont été spécifiés.

3 Socket API de TCP

21/65

Interface de programmation

Le protocole TCP est spécifié dans [RFC793]. Ce protocole de couche quatre du modèle OSI utilise deux entités bien différenciées qui sont le client et le serveur. Au démarrage, le serveur ouvre un socket et lui associe un numéro de port qui sera utilisé pour identifier l’application à laquelle sont destinées les données. Quand un client effectue une connexion à ce port, le serveur démarre un service pour s’occuper des données qu’il reçoit, puis il retourne à l’état « attendre une connexion ». De son côté, le client ouvre aussi un socket et il lui associe optionnellement un numéro de port. Il effectue une connexion avec le serveur, il transmet ses données, et, quand il a fini, il termine la connexion. Cette terminaison peut être effectuée aussi par le serveur.

4 Socket API de UDP La description du protocole UDP se trouve dans [RFC768]. Le serveur UDP est plus simple que le serveur TCP, car aucune connexion ne s’établie au niveau de la couche Transport. De même, on remarque que pour le client UDP, aucune connexion n’est nécessaire à la transmission des données.

5 Implémentation de référence Dans l’ouvrage [STE2002], on trouve une implémentation de SCTP faite par Randall R. Stewart (l’auteur du livre) et d’autres ingénieurs impliqués dans la standardisation de SCTP. Le code développé pour tester le protocole SCTP se base sur cette implémentation. L’implémentation fournie permet d’utiliser SCTP à travers un deamon (SCTP deamon ou SCTPd), afin d’éviter l’utilisation du socket en mode « root » (administrateur du système). Les applications créées et le SCTPd communiquent à l’aide de datagrammes UDP.

IP

UDP

SCTP daemon

SCTP application

Figure 11 : Implémentation de SCTP

Le travail effectué par le deamon SCTP est le suivant :

Ecoute les trois sockets crées et réagit Maintient une table des adresses UDP utilisées pour SCTP.

Autres implémentations SCTP

22/65

Chapitre

VII Autres implémentations SCTP

1 Introduction L’équipe de Stewart n’est pas la seule à avoir implémenté le protocole SCTP. En effet, plusieurs entreprises leader dans le domaine des télécommunications et de l’informatique ont aussi entamé cette démarche. Parmi ces entreprises, certaines ont choisi la voie de l’implémentation propriétaire, tandis que d’autres celle des logiciels « publiques ». L’avantage du logiciel « publique », ou « libre », est que l’entreprise doit faire un investissement mineur par rapport à l’implémentation propriétaire en tant que team de projet, car plusieurs personnes travaillent aux mêmes problématiques. La participation de la part d’autres entreprises ou de particuliers permet, en effet, un développement plus rapide et plus économique. L’expérience faite avec des projets comme Linux, FreeBSD et d’autres encore, a démontré que le logiciel « libre » et « Opensource » est une bonne solution du point de vue de l’investissement et de la fiabilité.

2 Implémentations libres Voici quelques exemples d’implémentations libres. 2.1 Université de Essen - Siemens http://www.sctp.de/sctp.html http://www.siemens.com http://tdrwww.exp-math.uni-essen.de/ Il s’agit d’une implémentation de SCTP pour les systèmes d’exploitations Linux, FreeBSD et MacOS X. Elle supporte IP version 4 et IP version 6 pour ses fonctionnalités, elle est probablement l’implémentation la plus avancée. Les acteurs du projet sont l’université de Essen et Siemens. Le code de référence est protégé par les licences publiques GNU Public Licence et GNU Lesser Public Licence. Deux types d’implémentations ont été crées : une orientée deamon, comme celle de Stewart, et l’autre orientée Socket API. Les versions actuellement en élaboration sont :

Socketapi-1.0.1 ; Sctplib-1.0.0-pre19.

23/65


2.2 Linux Kernel SCTP (lksctp project) http://sourceforge.net/projects/lksctp http://lksctp.sourceforge.net/ Ce développement, qui a été démarré par Stewart, se base sur l’intégration de SCTP dans le kernel Linux (version 2.5.29). L’administrateur du projet est La Monte H.P. Yarroll, de Motorola. Comme la plupart des implémentations libres, ce projet est protégé par une licence GPL. Parmi les principaux acteurs, on trouve IBM, qui est intéressé par cette implémentation, car il propose dans sa ligne de produits des serveurs avec systèmes d’exploitations Linux. La version actuelle de l’implémentation est :

lksctp-2_6_0-test1-0_7_2 2.3 KAME Project http://www.kame.net/ Le projet KAME a été crée par le regroupement de six entreprises japonaises dans le but de développer une version libre de IPv6 et IPsec pour toutes les variantes de BSD. Actuellement KAME a développé une implémentation de SCTP orientée kernel. Les systèmes d’exploitations concernés sont donc :

BSD ; FreeBSD ; OpenBSD ; NetBSD.

Les entreprises partenaires du projet sont :

Fujitsu Limited ; Hitachi, Ltd.; Internet Initiative Japan Inc. ; NEC Corporation ; Toshiba Corporation ; Yokogawa Electric Corporation.

2.4 Open SS7 http://www.openss7.org/ Ce projet propose une implémentation libre de SS7 (le protocole de signalisation numéro 7) et une implémentation libre de SCTP. L’implémentation du SS7 et des protocoles SIGTRAN est développée principalement pour le système d’exploitation Linux. Le code source est protégé par une licence GPL. La version actuelle de l’implémentation est la 0.8.2 et elle date du 15 avril 2002. 2.5 RivuS

24/65


http://rivus.sourceforge.net/ http://www.pictsctr.edu/ Le projet RivuS propose une extension à SCTP pour le système FreeBSD, afin de supporter la fonction load sharing3. Les promoteurs du projet sont trois étudiants du Pune Institute of Computer Tehnology (PICT), en Inde. La plate-forme utilisée pour le projet, débuté en août 2001, est FreeBSD 4.3. L’implémentation de SCTP est terminée, et, actuellement, le projet se concentre sur l’extension load sharing.

3 La fonction load sharing, utilisée dans les routeurs, permet de partager le trafic sur plusieurs interfaces qui ont la même destination, de manière à augmenter les performances et à ne pas congestionner un chemin particulier.

Plateformes du marché

25/65

Chapitre

VIII Plateformes du marché

1 Introduction Diverses entreprises du monde des télécommunications et de l’informatique ont déjà repris l’implémentation du [RFC2960] dans différentes configurations, soit pour le transport de la signalisation SS7 (comme prévu à l’origine lors de la création de ce protocole) ou pour d’autres types de transport.

2 Implémentations commerciales 2.1 Adax http://www.adax.com http://www.adax.com/aps_sctp.html Adax est une entreprise fondée en 1982 en Californie qui fourni des solutions pour la signalisation à des entreprises comme Lucent, Nortel, Ericsson, Alcatel, Hughes et Siemens. Adax a produit un module (APS-SCTP/T) utilisable avec le Adax Protocol Software (APS) permettant la signalisation téléphonique sur IP. L’implémentation supporte les systèmes d’exploitation compatibles UNIX. 2.2 Compaq http://www.compaq.com http://www.compaq.com/products/software/in7/SPD_SCTP.pdf Compaq, entreprise active dans le domaine des ordinateurs et des serveurs d’application, a implémenté le protocole SCTP pour ses serveurs Compaq Tru63 UNIX Alpha. Elle fournit un environnement de type Socket API qui permet la programmation en TCP-Sytle ou UDP-Style. 2.3 DataConnection http://www.dataconnection.com http://www.dataconnection.com/sctp/default.htm Data Connection est une entreprise anglaise spécialisée dans le développement de noyaux software. L’implémentation SCTP développée par Data Connection supporte les systèmes d’exploitations Windows, Solaris et VxWorks. WindRiver (http://www.windriver.com), propriétaire du système d’exploitation VxWorks (et d’autres systèmes comme BSD), n’a pas procédé à l’implémentation de SCTP, mais elle offre la solution Data Connection.

26/65


2.4 Sun Microsystems http://www.sun.com http://playground.sun.com/sctp/ Sun Microsystems est une entreprise internationale active dans le marché des stations de travail, des serveurs et dans le développement software (logiciel et systèmes d’exploitation). Les systèmes d’exploitation développés chez SUN sont Solaris et, récemment, Sun Linux. Les laboratoires Sun proposent une implémentation prototype orientée kernel de SCTP pour leur système d’exploitation Solaris 8 (pour processeur SPARC ou Intel). L’implémentation est conforme à Error! Reference source not found.. La version actuelle est la 1.2 (date du 28 juin 2001), mais elle est disponible seulement pour le marché nord-américain sous licence de Sun Microsystems. 2.5 Cisco http://www.cisco.com http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122newft/122t/122t8/ft_sctp2.pdf

Cisco Systems est une entreprise leader dans le marché des télécommunications. Elle produit des équipements réseaux (comme Switch et Routers), et possède un système d’exploitation propriétaire qui est le IOS (Internetwork Operating System). Cisco a développé sa propre distribution de SCTP, qui est intégrée aux IOS à partir de la version 12.2(4T). Actuellement, la release 2 de SCTP est intégrée dans le Cisco IOS version 12.2(8T). Cette distribution permet aux routeurs Cisco de transmettre la signalisation SS7 sur IP au moyen d’une fonctionnalité appelée ITP (IP Transfert Point). 2.6 Ericsson http://www.ericsson.com/signaling/pdf/sigtran.pdf http://ericsson-signaling.com/sctp/ Ericsson, entreprise d’importance mondiale dans la téléphonie mobile, a développé une implémentation de SCTP pour Solaris, le système d’exploitation propriétaire de Sun Microsystems. SCTP peut être utilisé à l’intérieur d’un réseau de téléphonie mobile pour le transport de la signalisation sur réseau IP. 2.7 Siemens Siemens est une entreprise active dans tous les pays dans le domaine de l’électronique, avec des divisions s’occupant de l’informatique et des télécommunications. Elle propose une solution de Signaling Transfer Point et Signaling Gateway appelée SURPASS hiS (High-speed signaling on the IP super-highway) qui permet de transmettre du SS7 sur TDM, ATM et IP. Pour la transmission de SS7 sur IP, SURPASS hiS utilise SCTP. Aucune mention n’est faite à propos de l’implémentation de SCTP, qui peut être propriétaire ou acquise. Comme mentionné auparavant, Siemens participe activement au projet SCTP en collaboration avec l’Université de Essen.

27/65


2.8 Trillium

http://www.trillium.com http://www.trillium.com/tech/1078191.html http://www.trillium.com/products/ss7-telephony/ Trillium est une entreprise appartenant à Intel, leader dans les solutions software pour les communications. Des importantes entreprises comme Motorola, s’appuient à Trillium pour le développement de modules software. Le produit de Trillium basé SCTP s’appelle SS7/IP. Il permet la convergence des systèmes communiquant avec SS7 vers les réseaux IP. 2.9 Ulticom http://www.ulticom.com Ulticom est une entreprise internationale spécialisée dans la production de software pour les télécommunications. Ulticom propose sa propre implémentation de SCTP dans un produit appelé Signalware NextGen. Il s’agit d’une solution software permettant de développer des applications dans un environnement SS7-IP. 2.10 Motorola http://www.motorola.com Motorola, importante entreprise active dans le domaine de la microélectronique, participe à la standardisation de SCTP en tant que sponsor du SIGTRAN. Actuellement, elle utilise la solution de Trillium pour ses produits. 2.11 Autres entreprises Autres entreprises, parmi lesquelles Nokia, sont aussi actives dans SCTP, mais actuellement aucune distribution propriétaire ou participation active à des projets courants a été annoncée.

28/65


3 Comparaison entre les différentes applications OS Licence implémentation R. Stewart Linux

FreeBSD Solaris

GNU LibraryGPL

Deamon

UNI Essen (Siemens)

Linux FreeBSD Mac OS X

GNU LGNU

Deamon Socket API

LKSCTP PROJECT (IBM)

Linux GPL Socket API

Kame project BSD FreeBSD OpenBSD NetBSD

BSD Socket API

Open SS7 Linux Comp. UNIX

GPL SocketAPI

RivuS FreeBSD n/a User space, kernel module Adax Comp. UNIX Propriétaire n/a Compaq Comp. UNIX Propriétaire Socket API Dataconnection Windows

Solaris VxWorks

Propriétaire n/a

SUN Microsystem Solaris Propriétaire n/a Cisco IOS Propriétaire n/a Ericsson Solaris Propriétaire n/a Trillium - Propriétaire n/a Ulticom Solaris Propriétaire n/a

Table 3 : Comparaison entre les applications

Dans cette table de comparaison, on peut noter que presque la totalité des distributions ont été développées pour des systèmes compatibles UNIX (Linux, FreeBSD, NetBSD, OpenBSD, Solaris, VxWorks). En ce qui concerne les licences, il y a une répartition assez homogène entre les logiciels libres et ceux propriétaires. La majorité des implémentations est de type socket. En effet, l’implémentation de type deamon, est souvent une étape intermédiaire avant d’attaquer le kernel.

Tests et plateforme de test

29/65

Chapitre

IX Tests et plateforme de test

1 Générateur de trafic SCTP/TCP/UDP Le logiciel utilisé pour générer du trafic SCTP a été développé dans le cadre de ce projet en se basant sur l’implémentation originale de R. Stewart. Ce logiciel, qui peut fonctionner en mode Client ou Serveur, permet d’engendrer un flux de données SCTP sur plusieurs streams ordonnés / non ordonnés avec la notion de multi-homing. Différents paramètres de configuration permettent de varier la taille des données transportées. Pour la génération du trafic TCP, c’est le logiciel IPerf [IPERF] qui est utilisé. Il s’agit d’un logiciel libre développé par l’Université de l’Illinois, qui permet de transmettre des données entre client et serveur. 1.1 Développement du logiciel Comme mentionné auparavant, le logiciel utilisé sur la plate-forme pour la génération du trafic SCTP se base sur l’implémentation originale de Stewart. Il s’agit donc d’une version basée « deamon ». Le choix d’utiliser cette distribution plutôt qu’une autre est dû à plusieurs facteurs :

Elle a été développée par la même équipe qui a écrit le RFC Elle est libre, et toutes les modifications sont permises Elle est assez bien documentée dans le livre de Stewart [STE2002]

Le logiciel permet de générer un flux de données entre deux points terminaux (client / serveur), avec les caractéristiques suivantes :

Multi-homing Multi-stream Choix du port source et destination Données ordonnées ou non-ordonnées

Choix de la taille des données dans les chunks Le générateur de trafic développé dans le cadre de ce projet peut être utilisé en ligne de commande : [buntschu@camelot buntschu]$ tragen --help Usage: tragen [-c|-s] [-h dest4] [-p destport] [-m myPort] [-o sendOpts] Client/Server : -m <port> : source port -f [kKmM] : speed output format Server specific: -s : run in server mode -w # : set Advertised Receiver Window Credit (a_rwnd) size Client specific: -c : run in client mode -h <host> : destination IPv4 host -p <port> : destination port -z # : send data size [bytes]

30/65


-i # : iterations -u # : non ordered streams -n # : ordered streams Miscellaneous: -? : print this message and quit [buntschu@camelot buntschu]$ De plus, l’interface graphique du logiciel IPerf a été modifiée pour pouvoir piloter notre générateur de trafic SCTP.

Figure 12 : JPERF, Interface graphique du générateur de trafic SCTP, mode server

31/65


Figure 13 : JPERF, Interface graphique du générateur de trafic SCTP, mode client

Dans le cadre de ce projet, nous avons écrit des scripts utilisant le mode en ligne de commande de ce générateur, qui nous a permit d’automatiser les mesures.

2 Plateforme de test Cet environnement de test devra permettre de simuler différents types de trafics et différentes conditions de charge du réseau. Parmi les principaux paramètres qui seront évalués, citons:

• robustesse de SCTP en cas d'interruption d'une connexion, grâce au concept de "multihoming" • résistance à l'inter blocage entre flux, en cas de perte de paquets IP, grâce au séquencement

individuel des flux multiplexés dans une même session SCTP • temps de traversée du réseau et gigue • amélioration de la sécurité (élimination de la possibilité d'engorgement de type "TCP SYN storms").

32/65


2.1 Architecture logique La plateforme de test choisie permettant de mettre en œuvre le protocole SCTP ainsi que les protocoles de transport courants tel que TCP et UDP aura l’allure suivante :

Figure 14 : Structure générale de la plateforme de test

Cette architecture devra permettre de simuler un réseau réel et permettre de générer et mesurer du trafic SCTP de manière similaire à TCP et UDP. Les éléments composant cette plateforme seront réalisés de la manière suivante :

• IP Network 1 et IP Network 2 :

Figure 15 : IP Network 1 & 2, réseaux émulés

Les réseaux IP 1 et 2 sont des réseaux émulés par l’application NITSnet ([NISNET]). L'émulateur de réseau de NISTnet est un outil d'usage universel pour émuler de manière dynamique les performances dans des réseaux IP. L'outil est conçu pour permettre des expériences reproductibles du fonctionnement d’un réseau et des protocoles circulant dans ce réseau, tout cela dans un arrangement simple de laboratoire. Par son fonctionnement au niveau d'IP, NISTnet peut émuler les caractéristiques de performance de bout en bout d’un réseau WAN classique (exemple : perte de

NISTnet

Nœud A: « merlin »

Nœud D: « camelot »

Nœud B: « perceval »

IP Network 1

IP Network 2

IP Network 3

Nœud C: « morgan »

33/65


paquet, congestion, …) ou des diverses autres technologies de sous-réseau (exemple : situations asymétriques de largeur de bande du xDSL et des modems CaTV).

• IP Network 3 :

Figure 16 : IP Network 3, réseau réel

Le réseau IP 3 est composé d’éléments actifs standard. Cette structure nous permettra de valider le fonctionnement et le comportement du protocole SCTP en parallèle aux protocoles de transports usuels, ainsi que de mettre en œuvre divers types de configuration, comme par exemple le Wireless LAN, HDLC ou encore MPLS.

• Stations clients/servers Les spécifications 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

lab-gw.eif.ch

vpn-gw.eif.ch

sctp-gw.eif.ch

firewall ap-c10.eif.ch

« newton »

« perceval »

34/65


2.2 Architecture physique L’architecture physique de cette plateforme sera la suivante :

Figure 17 : Architecture physique

Dans le cadre de nos mesures, nous aurons la possibilité de synchroniser les analyseurs AN-1 et AN-2 au moyen d’un GPS ou directement par un câble. Cette fonctionnalité sera très utile pour examiner le comportement dans le cadre du multihoming et dans les situations de congestion et d’erreurs.

Network Analyzer « Analyzor 1 » (160.98.30.170)

Récepteur GPS

10.1.2.0/24 10.1.1.0/24

10.1.3.0/24

10.1.4.0/24

.1

.2

.1

.2.2

.2

.1

.1

.3 .3

.3 .3

Nœud A: « merlin »

Nœud D: « camelot »

Nœud B: « perceval »

Nœud C: « morgan »

Network Advisor « Advisor 1 »

(160.98.30.175)

Network Advisor « Advisor 2 »

(160.98.30.176)

NISTnet 1 « NI-1 »

Network Analyzer « AN-2 »

(160.98.30.171)

35/65


3 Mesures Dans le cadre de ce rapport nous allons synthétiser les résultats obtenus sur notre plateforme de test avec le générateur de trafic développer dans le cadre de ce projet et divers autres outils. Le détail complet des mesures et des commentaires liés à chacune de ces mesures se trouve dans le document en annexe à ce rapport [BB-TEST]. 3.1 Tests fonctionnels & comparaisons avec UDP, TCP Dans cette partie des tests nous allons observer le fonctionnement pratique du protocole SCTP et faire les comparaisons qui s’impose avec ses rivaux UDP et TCP. 3.1.1 Etablissement et libération d’une association Le fonctionnement du protocole correspond aux spécifications faites dans le RFC, nous n’avons ici pas découvert de dysfonctionnement distinct pour ce qui est de l’établissement et la fermeture d’une association. 3.1.2 Echange de données Pour la transmission de données sur une liaison single-homed et sans erreur, nous pouvons faire les remarques suivantes :

- SCTP émet un certain nombre de trames ayant un seul DATA chunk avant de regrouper les DATA chunk en attente dans la queue d’émission, comme nous le montre la Figure 18

- Le rendement théorique du protocole SCTP est supérieur à TCP et UDP jusqu’à MTU/2, du fait que ce protocole peut regrouper plusieurs flux de donnée dans une même trame. Ce comportement est représenté sur la Figure 19.

- Lorsque la taille des données est petite (par ex. D= 50 bytes), la queue de réception annoncée au travers des SACK décroît dès qu’un certain volume de donnée est reçu.

- Le comportement en cas de fragmentation est comparable à TCP et UDP. - SCTP offre un mécanisme d’acquittement sélectif (SACK chunk) permettant d’annoncer

l’arrivée d’information dupliquée ou de requérir une retransmission d’une partie des données uniquement.

- Dans l’acquittement des données reçues, le récepteur à aussi la possibilité d’annoncer son état de congestion au niveau des queues de réception, cela permet à l’émetteur de réajuster le débit de transmission (paramètre a_rwnd)

36/65


0

5000

10000

15000

20000

25000

30000

35000

1 21 41 61 81 101 121 141 161 181 201 221 241 261 281 301

Transmitted frame #

a_rw

nd [b

ytes

]

0

200

400

600

800

1000

1200

1400

1600

Fram

e si

ze [b

ytes

]

a_rwnd (SACK)Frame size

Figure 18 : Mesure F22-001, a_rwnd & Frame Size, D=50 bytes

Si l’on compare la transmission de données par SCTP avec TCP et UDP, nous pouvons faire les calculs ci-dessous. Admettons vouloir transmettre VD MBytes de données avec des paquets de D bytes de données (on admettra par exemple VD = 10 MBytes = 106 bytes). Le calcul du nombre de trames émises (i) se fera de la manière suivante :

DnVi D

⋅⋅

=610

Avec n=1 dans le cas de TCP et UDP et n≥1 dans le cas de SCTP (correspond au nombre de DATA chunk émis par trame SCTP, nous admettons que chaque chunk a la même taille de donnée D) La volume total des données transmises sera calculé de la manière suivante :

)( DHiV +⋅= avec HiVH ⋅= Avec H correspondant aux en-têtes transmis sur une trame Ethernet :

• TCP : H = 58 bytes (18 Ethernet + 20 IP + 20 TCP) • UDP : H = 46 bytes (18 Ethernet + 20 IP + 8 UDP) • SCTP : H = 18 Ethernet + 20 IP + 12 SCTP + n · 16 DATA chunk + n · 1..3 padding

Le calcul du rendement se fera de la manière suivante :

100)(⋅

+=

DH

D

VVVη

37/65


0.0

10.0

20.0

30.0

40.0

50.0

60.0

70.0

80.0

90.0

100.0

50 100

150

200

250

300

350

400

450

500

550

600

650

700

750

800

850

900

950

1000

1050

1100

1150

1200

1250

1300

1350

1400

1450

Taille des données (D) [bytes]

Ren

dem

ent [

%]

SCTPTCPUDP

Figure 19 : Rendement théorique SCTP vs TCP vs UDP, pour VD=10 MB

3.1.3 Multihoming et comportement en cas d’erreurs Comme on l’a vu précédemment, le multihoming est une des fonctionnalités principale 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 20 et la Figure 21. L1 correspond au lien primaire et L3 au lien secondaire.

- Une retransmission 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 22 et la Figure 23, où le récepteur va annoncer à l’émetteur qu’il lui manque des DATA chunk ou que des données ont été reçues plusieurs fois.

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

38/65


0

2

4

6

8

10

12

14

1.59

7

1.59

9

1.60

4

1.60

5

1.60

6

1.61

1

1.61

2

1.61

6

2.23

6

3.44

0

3.64

5

3.84

8

6.05

5

6.25

7

10.4

63

10.6

65

Relative Time [s]

Chu

nk T

ype

#

Chunk type on L3Chunk type on L1

A

D

B

625.5 ms

623.6 ms

C

Figure 20 : Mesure F23-002-m3, Echange de données, détails

0

2

4

6

8

10

12

14

0.00

0.06

12.9

2

45.0

0

71.9

6

100.

23

130.

09

172.

16

201.

62

231.

18

272.

35

297.

52

320.

64

352.

61

382.

28

416.

04

452.

70

480.

77

509.

04

539.

59

569.

17

599.

04

629.

31

652.

87

685.

34

713.

39

739.

66

832.

51

865.

57

889.

84

948.

20

989.

07

1018

.73

1045

.60

Relative Time [s]

Chu

nk T

ype

#


B

A

Figure 21 : Mesure F23-005-m2, Echange de données sur le lien primaire et secondaire

39/65


0

100

200

300

400

500

600

24.1

5324

.554

24.9

5525

.356

26.2

5728

.358

30.0

0530

.810

32.5

6332

.865

33.2

6633

.667

34.9

6935

.270

35.6

7136

.972

37.2

7437

.678

38.0

8038

.481

38.8

8239

.283

39.6

8440

.585

42.6

8642

.987

43.3

8943

.790

44.1

9144

.596

44.9

9745

.398

46.6

9947

.000

47.4

0247

.803

48.2

0449

.104

49.3

0549

.706

Relative time [s]

TSN

0

1

2

3

4

GA

P &

DU

P #

TSN (tx) on L1Cumulative TSN (SACK) on L1TSN (tx) on L3Cumulative TSN (SACK) on L3a_rwnd (SACK)GAP Block (SACK) on L1DUP (SACK) on L1

C

B

A

D

E

Figure 22 : Mesure F23-005-m2, Echange de données, TSN vs Cumulatvie TSN, détails

0

50

100

150

200

250

300

350

400

450

0.00

0

0.40

6

0.41

1

0.91

5

2.04

0

2.76

6

126.

956

254.

747

446.

454

634.

778

858.

135

Relative time [s]

TSN

0

1

2

3

4

5

6

7

8

9

10

# of

GA

P bl

oc o

r du

plic

ate

TSN

TSN (tx)Cumulative TSN (SACK)Duplicate (SACK)GAP Block (SACK)

DB C

A

Figure 23 : Mesure F24-008-m2, Lien L2, TSN et informations des SACK

40/65


3.1.4 Contrôle de congestion Pour tester le contrôle de congestion, nous avons utilisé uniquement une liaison single-homed. Le débit de la liaison entre le lien L1 et L2 est limité à différentes valeurs au moyen de NISTnet. Seule la constatation suivante peut être faite :

- On voit que SCTP s’adapte au débit en utilisant le RTT et cwnd1 pour diminuer son débit de transmission (points C de la Figure 24).

0

2

4

6

8

10

12

14

0.00

00.

001

0.08

60.

257

0.25

70.

258

0.25

80.

259

0.26

00.

260

0.26

10.

261

0.31

30.

665

0.85

01.

036

1.40

51.

590

1.77

52.

146

2.51

52.

516

2.88

63.

255

3.44

03.

626

3.99

54.

180

4.36

64.

735

4.92

05.

110

6.88

57.

087

8.87

08.

871

10.6

4612

.225

12.4

2614

.209

15.9

8517

.769

19.5

4521

.325

23.1

0924

.885

26.6

6928

.444

30.2

2430

.931

30.9

32

Relative Time [s]

Chu

nk T

ype

#


A B C C

Figure 24 : Mesure F25-001-m1, Echange de données, r1-2 = 6.4 kb/s

3.1.5 Robustesse Le but de cette mesure est de démontrer que la notion de head-of-line blocking (HOL), c’est-à-dire le fait que la transmission ne puisse pas continuer avant que le segment perdu ne soit retransmis, présente dans TCP, n’existe pas dans le protocole SCTP. Cette lacune de TCP n’est pas du tout présente dans SCTP grâce à l’utilisation de l’acquittement sélectif. Voici un extrait du trafic observé par les analyseurs :

AN-1 (perceval) Direction

AN-2 (camelot)

Perdu … <- Frame 6, DATA, TSN=0x01 Frame 7, DATA, TSN=0x02 <- Frame 7, DATA, TSN=0x02

Perdu … <- Frame 8, DATA, TSN=0x03 Frame 8, DATA, TSN=0x04 <- Frame 9, DATA, TSN=0x04 Frame 9, DATA, TSN=0x05 <- Frame 10, DATA, TSN=0x05 … Frame 27, DATA, TSN=0x17 <- Frame 28, DATA, TSN=0x17 Frame 28, SACK, cTSNack=0x00, -> Frame 30, SACK, cTSNack=0x00,

1 cwnd = congestion window, est une variable stockée sur l’émetteur représentant quel volume de donnée peut être injecté dans le réseau (voir [BB-DES] pour plus de détail)

41/65


nGAP=1, B1start=2, B1stop=2, nDUP=0

nGAP=1, B1start=2, B1stop=2, nDUP=0

Frame 29, DATA, TSN=0x18 <- Frame 29, DATA, TSN=0x18 Frame 30, DATA, TSN=0x19 <- Frame 31, DATA, TSN=0x19 Frame 31, DATA, TSN=0x1A <- Frame 32, DATA, TSN=0x1A Frame 32, SACK, cTSNack=0x00, nGAP=2, B1start=2, B1stop=2, B2start=4, B2stop=4, nDUP=0

-> Frame 33, SACK, cTSNack=0x00, nGAP=2, B1start=2, B1stop=2, B2start=4, B2stop=4, nDUP=0

Frame 33, SACK, cTSNack=0x00, nGAP=2, B1start=2, B1stop=2, B2start=4, B2stop=5, nDUP=0

-> Frame 34, SACK, cTSNack=0x00, nGAP=2, B1start=2, B1stop=2, B2start=4, B2stop=5, nDUP=0

… Frame 103, DATA, TSN=0x01, TSN=0x03, TSN=0x12F, TSN=0x130, …

<- Frame 102, DATA, TSN=0x01, TSN=0x03, TSN=0x12F, TSN=0x130, …

Frame 104, SACK, cTSNack=0x138, nGAP=1, B1start=3, B1stop=14, nDUP=0

-> Frame 103, SACK, cTSNack=0x138, nGAP=1, B1start=3, B1stop=14, nDUP=0

Table 4 : Mesure F27-001, échange de données

Camelot émet vers Perceval les trames avec un TSN de 0x01 à 0x17. Le réseau étant perturbé par NISTnet-1, les chunks avec les TSN 0x01 et 0x03 sont perdus. Perceval indique au travers de la trame 28 (SACK) qu’il attend toujours le chunks avec le TSN 0x01 et que le chunk 0x03 est manquant (GAP block). La transmission des données continue et à la trame 102, Perceval effectue une retransmission des chunks avec les TSN 0x01 et 0x03 et inclus dans cette même trame d’autre chunk de flux différents (groupage). Cette méthode permet d’acquitter sélectivement les données reçues et évite la retransmission complète des chunks. SCTP est aussi totalement insensible aux SYN Attack présent dans TCP, uniquement grâce à l’établissement de l’association en quatre temps et au fait qu’aucune ressource n’est réservé sur le destinataire tant que le COOKIE-ACK n’est pas retransmis par l’initiateur de la connexion. 3.2 Performances 3.2.1 Débit La mesure de débit doit nous permettre d’observer les performances de SCTP par rapport à TCP et UDP. Dans le cadre de nos mesures nous avons pris comme base de comparaison un volume de donnée constant de 2.8 MB. Nous avons ensuite mesuré quel était le temps nécessaire à chaque protocole pour émettre ce volume de donnée et nous en avons par la suite déduit le débit moyen en fonction de la taille des trames émises. Les résultats obtenus sont les suivants :

- Comme nous l’avions déjà mentionné précédemment, SCTP à un rendement de transmission meilleure que TCP et UDP pour des tailles de DATA chunk inférieur à MTU/2. Ce rendement supérieur nous donnera donc un débit théorique quasiment constant pour SCTP, quel que soit la taille des données (grâce au regroupement de DATA chunk dans une trame).

- On constate aussi que le rapport entre volume d’acquittement 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ée est faible (<100 KB) ce rapport est grand (>90%).

Dans la Figure 25, nous avons représenté les débits théoriques pour TCP, UDP et SCTP pour une taille des données variant entre 50 et 1450 bytes.

42/65


Nous utiliserons les variables suivantes pour nos calculs : δ = Débit brut [b/s] D = taille des données transmises [bytes] H = taille de l’entête (ethernet + IP + TCP/UDP/SCTP) [bytes] HACK = taille des trames d’acquittement (ethernet + IP + TCP/SCTP) [bytes] VD = Volume des données transmises [bytes] VH = Volume des entêtes [bytes] VACK = Volume des acquittements [bytes] tD = temps nécessaire pour transmettre VD et VH [s] tACK = temps nécessaire pour transmettre les acquittements (ACK ou SACK) [s] iD = nombre de trames à envoyer pour atteindre le volume VD iACK = nombre de trames à envoyer pour atteindre le volume VACK pour un buffer de réception de taille B. n = nombre de data chunk pouvant être regroupé dans une trame IP sans dépasser le PMTU. tb = temps de transmission pour 1 bits [s] tf = temps inter-trames [s] Admettons vouloir transmettre VD bytes de données avec des paquets de D bytes de données. Le calcul du nombre de trames émises (iD) et d’acquittement (iACK)se fera de la manière suivante :

DnVi D

D ⋅=

DBiACK =

Avec n=1 dans le cas de TCP et UDP et n≥1 dans le cas de SCTP (correspond au nombre de chunk émis par trame SCTP, nous admettons que chaque chunk a la même taille de donnée D) La volume total des données transmises sera calculé de la manière suivante :

DHutile

ACKD

DACKACKDDACKDH

VVVDHBV

DnHVHiVHiVVVV

+=

⋅++

⋅⋅

=⋅++⋅=++=

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 :

fDDbD tiitHDnt ⋅+⋅⋅⋅+⋅= 8)(

fACKACKbACKSACK tiitHt ⋅+⋅⋅⋅= 8)(

43/65


Le calcul du débit utile1 se calculera de la manière suivante :

ACKD

utile

ttV+

⋅= 8δ

Si nous représentons de manière graphique le débit théoriques des différents protocoles pour VD = 2.8 Mb/s sur une liaison à 100 Mb/s, B = 32768 bytes et sans aucune erreur sur les différents médiums, nous aurons les résultats représentés sur la Figure 25 et la Figure 26. On constate que lorsque le VD est supérieur à 1 Mb/s, la perte de débit des données due aux acquittements devient négligeable (pour SCTP et TCP). On voit aussi que pour UDP les débits atteints sont indépendants du volume à transmettre. Nous avons une cassure dans le débit SCTP calculé pour D=750 bytes. Cela provient du fait que notre calcul se base 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 à une taille de données différentes pour chaque chunk, le rendement ainsi obtenu sera meilleur, ainsi que le débit.

0.0

10.0

20.0

30.0

40.0

50.0

60.0

70.0

80.0

90.0

100.0

50 100

150

200

250

300

350

400

450

500

550

600

650

700

750

800

850

900

950

1000

1050

1100

1150

1200

1250

1300

1350

1400

1450


Déb

it [M

b/s]

0.000%

0.200%

0.400%

0.600%

0.800%

1.000%

1.200%

(S)A

CK

vs

DA

TA [%

]

TCPUDPSCTPTCP: ACK vs DATASCTP: SACK vs DATA

Figure 25 : Débit théoriques SCTP/TCP/UDP vs taille des données

1 Par débit utile nous entendons le débit atteint pour la transmission des données avec les entêtes nécessaire à leur transmission.

44/65


0.0

10.0

20.0

30.0

40.0

50.0

60.0

70.0

80.0

90.0

100.0

50 100

150

200

250

300

350

400

450

500

550

600

650

700

750

800

850

900

950

1000

1050

1100

1150

1200

1250

1300

1350

1400

1450


Déb

it [M

b/s]

TCP (1)UDP (1)SCTP (1)TCP (2)UDP (2)SCTP (2)

Figure 26 : Débit théoriques SCTP/TCP/UDP vs taille des données. VD(1) = 2.8 MB, VD(2)= 28 KB

On constate que les débits théoriques et mesurés correspondent, sauf dans le cas de SCTP (Figure 27). La différence provient principalement de l’implémentation de notre générateur de trafic, ce qui ne nous permettra pas dans le cadre de ce projet de faire une comparaison réelle des performances avec ces concurrents principaux. Le point de la même figure représente un autre problème de notre générateur qui n’arrive pas à transmettre le volume de donnée voulu pour une taille des DATA chunks de 50 bytes.

0

10000

20000

30000

40000

50000

60000

70000

80000

90000

100000

100

200

500

800

1000

1400

1470

Data Size [bytes]

Déb

it [k

b/s]

0.00%

20.00%

40.00%

60.00%

80.00%

100.00%

120.00%

140.00%

Ren

dem

ent [

%]

Débit SCTPDébit TCPDébit UDPRendement SCTPRendement TCPRendement UDP

A

Figure 27 : Mesure F31-001..13, Débit et rendement vs Data size pour SCTP, TCP et UDP

45/65


3.2.2 Temps de réponse Les temps de réponses que nous allons explorer dans ce chapitre sont subjectifs, du fait que les performances de notre générateur ne sont pas représentatives d’une implémentation réelle. Au travers de nos mesures, nous avons mesuré un temps d’établissement moyen de 1.8 ms pour le protocole SCTP. Au travers de mesures similaires, nous avons pu constater que le temps moyen d’établissement pour TCP était de 0.3 ms. Dans le cadre de la libération d’une association, nous avons mesuré un temps de libération moyen de 7 ms pour le protocole SCTP et pour TCP. Les deux protocoles utilisent une libération en trois phases. 3.3 Tests en réseau réel Les tests en réseau réel nous permettent de valider que le protocole SCTP peut être transporter dans un réseau de routeurs et de switches de manière aussi transparente que UDP/TCP. La plateforme de test sera la suivante :

Figure 28 : Tests en réseau réel

Les mesures effectuées seront de deux types :

1. Génération de trafic entre Newton et Camelot au travers d’un réseau « réel » 2. Génération de trafic TCP entre Perceval et Camelot en parallèle au trafic générer entre Newton et

Camelot. Dans les deux cas de figure, le trafic SCTP générer depuis Newton traversera le réseau de l’école, en parallèle à tout le trafic existant (email, http, ftp, novell, etc…). Nous n’allons par contre pas tester la mise en place de QoS, notre générateur de trafic n’étant pas suffisamment performant pour ce genre de simulation.

NISTnet 1 10.1.2.0/24 10.1.1.0/24

.2.2 .3 .3

« camelot » « perceval »

« newton »

160.98.161.250

160.98.160.0/23160.98.8.0/23

160.98.30.0/2

160.98.2.0/23

.1

.17

.1.3.2

.1

.10NAT

lab-gw.eif.ch

vpn-gw.eif.ch

sctp-gw.eif.ch

firewall

46/65


Les résultats obtenus sont les suivants :

- Le comportement constaté est identique à celui constaté lors des mesures sur notre maquette de test

- Les débits atteints sont de l’ordre de 70 kb/s (avec VD = 8 Kbytes) et de 2.71 Mb/s (avec VD = 200 Kbytes)

- L’infrastructure réseau est totalement transparente pour le transport du protocole SCTP. 3.4 Tests d’applications SCTP L’application SCTP testée dans le cadre de ce projet est le navigateur Mozilla [MOZ] fonctionnant sur FreeBSD 4.6 effectuant une connexion de type « HTTP over SCTP » sur un serveur distant utilisant une version modifiée de Apache [APA]. Notre plateforme de test est la suivante :

Afin que cette configuration fonctionne, il est nécessaire d’utiliser la version [KAME] de FreeBSD. Les versions modifiées de Apache et de Mozilla permettant le support de SCTP sur [KAME] se trouve sur le site internet : http://www.sctp.org. Les résultats obtenus sont les suivants :

- Le comportement constaté est identique à celui constaté lors des mesures sur notre maquette de test, si ce n’est :

a/ le regroupement de DATA chunks n’est pas fait b/ le navigateur établi plusieurs association avec le serveur, au lieu de regrouper des streams au sein de la même association. Suite à un email avec R.Stewart, nous constater qu’il s’agit d’une modification rapide des codes sources, sans prendre en compte tous les avantages du SCTP [BB-TEST].

- La connexion SCTP au travers d’Internet fonctionne parfaitement. On voit donc que l’intégration

« douce » de ce protocole est possible dans les réseaux IP existants.

160.98.163.0/24 .6

.1

SCTP Client arthur.eif.ch

SCTP Server www.sctp.org

INTERNET

Fribourg, Suisse

Illinois, USA

Agilent Advisor « AD-1 »

Mozilla InternetBrowser

APACHE Server

66.93.186.36

67.38.193.238

Problèmes rencontrés

47/65

Chapitre

X Problèmes rencontrés

1 Plateforme de développement Dans l’état actuel du développement du protocole SCTP et de son implémentation, il n’a pas été possible de réaliser un générateur de trafic suffisamment puissant pour générer du trafic atteignant (ou s’approchant) des débits théoriques calculés précédemment. Cette contrainte ne nous a pas permis de faire des tests de fonctionnement de SCTP avec l’introduction de QoS dans un réseau, mais nous avons pu effectuer l’ensemble des tests fonctionnels prévus, ainsi que d’effectuer une comparaison complète avec ses concurrents directs que sont TCP et UDP.

2 Equipements de mesure Les équipements Agilent « Distributed Network Analyzer » utilisés dans le cadre de ce projet sont un nouveau produit de ce constructeur. La version des équipements reçues en fin d’année 2002 fonctionnait avec la version 1.2.30 avec laquelle nous avons rencontré quelques difficultés, comme par exemple l’activation des filtres de mesures ou encore la synchronisation avec le GPS de la marque DATUM. Suite au second problème nous avons envoyé nos deux analyseurs aux USA pour une mise-à-jour hardware (fin février) et lors de la réception de ceux-ci (mi-juin 2003 !) un des deux équipements ne fonctionnait toujours pas correctement. Une dernière mise-à-jour à la version 2.1 du software de ces équipements nous a permis de terminer nos mesures.

3 Planning Suite à une charge supplémentaire provenant de nos activités annexes (Academie Cisco, séminaires, projets d’étudiants), le projet n’a pas pu être terminé fin 2002 comme prévu, mais fin août 2003.

Conclusions

48/65

Chapitre

XI Conclusions

1 Aspect innovateur L’aspect innovateur du projet est le protocole lui-même. Les nouvelles caractéristiques apportées permettront de faire face aux limitations imposées par les protocoles actuels et laisser la voie libre aux nouvelles applications temps réels. Le fait d’avoir travaillé avec un protocole extrêmement récent, dont les premières implémentations commencent à se faire remarquer, a été une expérience très enrichissante. Des changements importants arrivent chaque semaine, comme par exemple de nouvelles fonctions supportées pour une implémentation de SCTP ou des nouvelles applications utilisant SCTP comme protocole de transport. Au cours de l’élaboration du projet, les informations traitant le protocole SCTP se sont rapidement multipliés sur l’Internet. En effet, toujours plus de personnes sont intéressées par cette technologie.

2 Future du protocole SCTP 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.. R. » 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é dans leur globalité pour n’en retirer que le meilleur afin de définir le SCTP. Parmi les points les plus importants, on trouve le multihoming, le concept de streams, l’acquittement sélectif et l’augmentation de la fiabilité. Le multihoming 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 type différent (UDP,

49/65

Conclusions

TCP), ce qui implique l’utilisation de plusieurs ports et des difficultés de la gestion de réseau. Prenons l’exemple d’une transmission VoIP (Voice over Interet Protocol) : 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’on montré les tests en laboratoire concernant les fonctionnalités et les performances du protocole, même étant 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

3 Suite du projet Le projet présente plusieurs documents de référence pour l’étude de SCTP, en incluant des aspects liés aux implémentations existantes, aux acteurs du marché et à des mesures en laboratoire. Certains points, comme par exemple des tests dans un environnement IPv6 et des tests de performances plus complets ainsi que l’application de QoS, méritent d’être traités plus dans le détail. Pour autant, qu’un nouveau générateur de trafic soit développé, ou l’accent sera mis sur la performance de celui-ci.

Annexes

50/65

Chapitre

XII Annexes

1 Contenu du CDROM Le CDROM joint au rapport peut être découvert à l’aide d’un navigateur web en ouvrant le fichier index.html qui se trouve au répertoire racine. Voici le contenu du CDROM :

Development : contient les codes source de notre application ainsi que les codes de R.Stewart pour freeBSD et Linux. Doc : contient les quatre documents associés à ce projet.

- Rapport - Description du protocole - Plateforme de test & mesures - Socket API

Software :

Iperf, l’outil de mesure de performance dans les réseaux IP ;

L’implémentation de base de Randall R. Stewart ; Tragen, le logiciel développé pour les tests.

Tests : dans chaque sous-répertoire se trouvent tous les fichiers des mesures et de configuration des tests effectués en laboratoire

Index

51/65

Chapitre

XIII Index

A a_rwnd, 11 ABORT, 8 association, ii, iii, 4, 5, 6, 8, 9, 10, 11, 58

C chunk, 8, 11 congestion, 8, 11 cookie, 9 Cookie, 8

D DATA, 8, 11

E ERROR, 8

H HEARTBEAT, 8, 13

I IANA, 4 IETF, ii, 54 INIT, 8, 9, 11 INIT-ACK, 11 IPv4, 7, 8 IPv6, 8

M multihomed. See multihoming multihoming, ii, 5

P point terminal, 4, 6

S SACK, 8, 11 SCTP, ii, iii, 4, 5, 6, 7, 8, 9, 53, 54, 57, 58 SHUTDOWN, 8 signalisation, ii SSN, 13 stream, 1, ii, 12, 13, 52, 54, 57

T TCP, ii, iii, 7, 9, 52 TLS, 14, 54, 58 TLV, 58 TSN, 11, 58

U UDP, ii, iii, 4, 7

V VoIP, ii

52/65

Références

Chapitre

XIV Références

[ADDIP] IETF draft: Stream Control Transmission Protocol (SCTP) Dynamic Address Reconfiguration, February 2003 http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-addip-sctp-07 [APA] HTTP Server, version libre http://www.apache.org/ [BB-DES] F.Buntschu, A. Bernasconi, SCTP – Description du protocole, Projet HES-SO no TI01- 02, juillet 2003 [BB-API] F.Buntschu, A. Bernasconi, SCTP – Socket API, Projet HES-SO no TI01- 02, juillet 2003 [BB-TEST] F.Buntschu, A. Bernasconi, SCTP – Plateforme de tests & Mesures, Projet HES-SO no TI01-02, juillet 2003 [BER-TCP] J. Mo, R. La, V. Anantharam and J. Walrand, Analysis and comparisons of TCP Reno and Vegas, Infocomm 1999 http://www.eecs.berkeley.edu/~ananth/1999-2001/Richard/MoLaInfocom1999.pdf

[BER-EIFEL] University of Berkeley, California. Summary of eifel resources http://iceberg.cs.berkeley.edu/downloads/tcp-eifel/ [BER-RETR] R. Ludwig, K. Sklower, The Eifel retransmission timer, July 2000 http://iceberg.cs.berkeley.edu/papers/Ludwig-Eifel-Xmit/eifel_xmit_timer.pdf

[BOV1999] 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 [CER1996] CERT : TCP SYN Flooding and IP Spoofing Attacks, CERT Advisory CA-1996-21, September 1996. http://www.cert.org/advisories/CA-1996-21.html [COM-1996] Douglas Comer : TCP/IP Architecture, protocoles, applications. Troisième edition, InterEdition, ISBN 2-7296-0599-1, 1996 [DRAFT-IPv6m] IETF draft: Stream Control Transmission Protocol (SCTP) Dynamic Address Reconfiguration, August 2002 http://www.ietf.org/internet-drafts/draft-ietf-mobileip- ipv6-22.txt [EIFEL-ALG] R. Ludwig, Ericsson Research, The Eifel Algorithm for TCP, February 2001, expired August 2001

http://iceberg.cs.berkeley.edu/downloads/tcp-eifel/ draft-ietf-tsvwg-tcp-eifel-alg-00.txt

[FLO-CON] Floyd, S., Fall, K., Promoting the Use of End-to-End Congestion Control in the

53/65

Références

Internet, Submitted to IEEE Transactions on Networking. [FU-MOB] S.Fu, M. Atiquzzaman and William Ivancic: Effect of Delay Spike on SCTP, TCP Reno, and Eifel in a WirelessMobile Environment, University of Oklahoma, NASA Glenn research center http://www.cs.ou.edu/~atiq/papers/02icccn-long-del.pdf [IAN-SCTP] Internet Assigned Numbers Authority: Protocol Numbers and assigned services, SCTP.

http://www.iana.org/assignments/sctp-parameters [IPERF] NLANR, University of Illinois, UDP/TCP Traffic generator http://dast.nlanr.net/Projects/Iperf/ [ISOC-TCP] K. Kurata, G. Hasegawa, M. Murata, Fairness Comparisons between TCP Reno and TCP Vegas for future deployment of TCP Vegas, ISOC, 2000 http://www.isoc.org/inet2000/cdproceedings/2d/2d_2.htm [ITU-Q700] ITU-T Recommentation Q.700: Introduction to CCITT Signalling System No.7, International Telecommunication Union, Geneva, March 1993 [JAC-CON] V. Jacobson, Congestion Avoidance and Control, ACM SIGCOMM, 1988 [KAME] KAME Project, Japan, free IPv6 and IPsec for the FreeBSD http://www.kame.net/ [KRA1997] Krawczyk H., Bellare M. and Canetti R.: HMAC: Keyed-Hashing for Message Authentication, RFC 2104, February 1997 http://www.ietf.org/rfc/rfc2104.txt [MA1998] Ma G., T/UDP: UDP for TCAP, Internet draft, expired May 1999 http://www.watersprings.org/pub/id/draft-ma-tudp-00.txt [MOL-MPEG] 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 [MOZ] Internet browser: Mozilla http://www.mozilla.org/ [MSCTP] IETF draft: Architecture of Mobile SCTP for IP Mobility Support, June 2003 http://www.ietf.org/internet-drafts/draft-sjkoh-sctp- mobility-01.txt [NBS1995] National Bureau of Standards: Secure Hash Standard, Federal Information Processing Standards Publication 180-1, April 1995 http://csrc.nist.gov/publications/fips/fips180-1/fip180-1.txt [NISNET] National Institute of Standards and Technology (NIST), Network Emulator http://www.snad.ncsl.nist.gov/itg/nistnet [RFC147] IETF, The definition of a Socket, May 1971 http://www.ietf.org/rfc/rfc147.txt [RFC768] IETF: User Datagram Protocol, August 1980 http://www.ietf.org/rfc/rfc768.txt [RFC793] IETF: Transmission Control Protocol, September 1981 http://www.ietf.org/rfc/rfc793.txt [RFC1644] Braden, R., T/TCP—TCP Extensions for Transactions Functional Specification, July 1994.

54/65

Références

http://www.ietf.org/rfc/rfc1644.txt [RFC2018] IETF: TCP Selective Acknoledgment Options, October 1996 http://www.ietf.org/rfc/rfc2018.txt [RFC2267] IETF: Networking Ingress filtering: defeating denial of service attacks which

employ IP Source address spoofing, January 1998 http://www.ietf.org/rfc/rfc2267.txt [RFC2481] IETF: A proposal to add explicit congestion notification (ECN) to IP, January 1999 http://www.ietf.org/rfc/rfc2481.txt [RFC2488] IETF: Enhancing TCP Over Satellite Channels using standard Mechanisms, January 1999 http://www.ietf.org/rfc/rfc2488.txt [RFC2581] IETF: TCP Congestion Control, April 1999 http://www.ietf.org/rfc/rfc2581.txt [RFC2760] IETF: Stream Ongoing TCP Research Related to Satellites, February 2000 http://www.ietf.org/rfc/rfc2760.txt [RFC2960] IETF: Stream Control Transmission Protocol, October 2000 http://www.ietf.org/rfc/rfc2960.txt [RFC3309] IETF: Stream Control Transmission Protocol Checksum change, September 2002 http://www.ietf.org/rfc/rfc3309.txt [RFC3436] IETF: Transport Layer Security (TLS) over SCTP, December 2002 http://www.ietf.org/rfc/rfc3436.txt [RFC3344] IETF: IP Mobility Support for IPv4, August 2002 http://www.ietf.org/rfc/rfc3309.txt [Riv1992] Rivest R.L.: The MD5 Message-Digest Algorithm, RFC 1321, April 1992 http://www.ietf.org/rfc/rfc1321.txt [SIG-WG] IETF SIGTRAN Working Group http://www.ietf.org/html.charters/sigtran-charter.html [STE2002] Randall R. Stewart and Qiaobing Xie: Stream Control Transmission Protocol (SCTP), Addison Wesley, ISBN 0-201-72186-4, November 2001 [STE-TCP] W. Richard Stevens, TCP/IP Illustrated, Volume 1: The Protocols. Reading, Massachusetts: Addison-Wesley, 1994. [SCTP-API] IETF: Socket API Extensions for Stream Control Transmission Protocol,

Internet Draft, May 2002 http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-sctpsocket-05.txt

55/65

Liste des tables

Chapitre

XV Liste des tables

Table 1 : Chunk type ..........................................................................................................................................8 Table 2 : Différences entre UDP-TCP-SCTP...................................................................................................15 Table 3 : Comparaison entre les applications...................................................................................................28 Table 4 : Mesure F27-001, échange de données ..............................................................................................41

56/65

Liste des figures

Chapitre

XVI Liste des figures

Figure 1 : Modèle OSI....................................................................................................................................... ii Figure 2 : Association SCTP............................................................................................................................ iii Figure 3 : Structure de la documentation ...........................................................................................................2 Figure 4 : Multihoming et transport ...................................................................................................................5 Figure 5 : Exemple d'une association SCTP ......................................................................................................6 Figure 6 : Encapsulation de SCTP sur IPv4 .......................................................................................................7 Figure 7 : En-tête SCTP .....................................................................................................................................8 Figure 8 : Processus d'établissement en quatre temps ........................................................................................9 Figure 9 : Processus de libération.....................................................................................................................10 Figure 10 : Opérations T/TCP..........................................................................................................................17 Figure 11 : Implémentation de SCTP...............................................................................................................21 Figure 12 : JPERF, Interface graphique du générateur de trafic SCTP, mode server ......................................30 Figure 13 : JPERF, Interface graphique du générateur de trafic SCTP, mode client .......................................31 Figure 14 : Structure générale de la plateforme de test ....................................................................................32 Figure 15 : IP Network 1 & 2, réseaux émulés ................................................................................................32 Figure 16 : IP Network 3, réseau réel...............................................................................................................33 Figure 17 : Architecture physique ....................................................................................................................34 Figure 18 : Mesure F22-001, a_rwnd & Frame Size, D=50 bytes ...................................................................36 Figure 19 : Rendement théorique SCTP vs TCP vs UDP, pour VD=10 MB ....................................................37 Figure 20 : Mesure F23-002-m3, Echange de données, détails .......................................................................38 Figure 21 : Mesure F23-005-m2, Echange de données sur le lien primaire et secondaire...............................38 Figure 22 : Mesure F23-005-m2, Echange de données, TSN vs Cumulatvie TSN, détails .............................39 Figure 23 : Mesure F24-008-m2, Lien L2, TSN et informations des SACK....................................................39 Figure 24 : Mesure F25-001-m1, Echange de données, r1-2 = 6.4 kb/s ............................................................40 Figure 25 : Débit théoriques SCTP/TCP/UDP vs taille des données ...............................................................43 Figure 26 : Débit théoriques SCTP/TCP/UDP vs taille des données. VD(1) = 2.8 MB, VD(2)= 28 KB...........44 Figure 27 : Mesure F31-001..13, Débit et rendement vs Data size pour SCTP, TCP et UDP .........................44 Figure 28 : Tests en réseau réel ........................................................................................................................45

57/65

Liste des abréviations et des acronymes

Chapitre

XVII Liste des abréviations

et des acronymes HMAC Keyed-Hashing algorithm for Message Authentication HTTP Hyper Text Transmission Protocol IETF Internet Engineering Task Force IP Internet Protocol ITU-T International Telecommunication Union – Telecom Standardization LAN Local Area Network MD5 Message Digest 5 MDTP Multi-network Datagram Transmission Protocol OS Operating System OSI Open Systems Interconnection PMTU Path Maximum Transmission Unit La taille maximum (en octet) q’un datagramme IP peut avoir sur un chemin particulier avant que celui-ci ne soit fragmenté. PSTN Public Switched Telephone Network QoS Quality of Service RFC Request For Comments SACK Selective Acknowledgment SCTP Stream Control Transmission Protocol SHA-1 Secure Hash Standard 1 SIGTRAN Signaling Transport SS7 Signaling System #7 SSN Stream Sequence Number RTO Retransmission TimeOut

58/65

Liste des abréviations et des acronymes

Délai après lequel SCTP retransmet un DATA chunk. RTT Round Trip Time Temps de transmission d’un signal dans un circuit fermé. TCB Transmission Control Block Structure de donnée interne contenant les informations pour l’opération et le maintien d’une association SCTP. TCP Transmission Control Protocol TLV Format d’une structure de données qui comprend toujours les trois champs Type, Length (longueur) et Value (valeur). TLS Transport Layer Security TSN Transmission Sequence Number UDP User Datagram Protocol ULP Upper Layer Protocols VoIP Voice over IP

59/65

Historique

Chapitre

XVIII Historique

Issue par :

Approuvé par :

Recipient(s) Departement(s) Recipient(s) Departement(s) François Buntschu

EIA-FR Telecom

Antoine Delley Rudolf Scheurer

EIA-FR Telecom EIA-FR Telecom

HISTORIQUE Date Remarques 30.01.2003 30.08.2003

Document de base 1.0, draft Document 1.0 définitif

sctp rapport v11 -...

Documents

Transcript of sctp rapport v11 -...