2 Méthode de transmission de données SUNA
Il existe deux méthodes de transmission de données dans les réseaux à commutation de paquets : le mode datagramme et le mode circuit virtuel. Le protocole TCP/IP utilise des datagrammes pour transmettre des données. En mode datagramme, il n’est pas nécessaire d’établir une connexion fixe entre l’hôte source et l’hôte de destination. Chaque paquet envoyé par l’hôte source choisit de manière indépendante un chemin de transmission. Chaque paquet peut atteindre l’hôte de destination depuis l’hôte source en empruntant différents chemins de transmission au sein du sous-réseau de communication. Le chemin de transmission n’étant pas fixe, le mode datagramme ne peut garantir que les paquets échangés entre l’hôte source et l’hôte de destination arriveront dans l’ordre.
Contrairement au protocole TCP/IP, SUNA utilise un circuit virtuel de bout en bout pour transmettre les données. Un circuit virtuel désigne un canal établi par un logiciel à partir des adresses réseau, reliant un nœud source à un nœud de destination. Le circuit virtuel de bout en bout signifie que pour des données ayant les mêmes adresses de nœuds source et de destination mais des types de service différents, des circuits virtuels distincts seront établis pour les transmettre. Avant d’utiliser la méthode du circuit virtuel pour envoyer des paquets, un chemin logique doit être établi entre l’expéditeur et le destinataire. Chaque paquet contient, en plus des données, un identifiant de circuit virtuel. Chaque nœud situé sur le chemin préétabli sait où acheminer ces paquets, et aucune décision de routage n’est plus nécessaire. Le chemin de transmission étant fixe, la méthode du circuit virtuel garantit que les paquets de données entre l’hôte source et l’hôte de destination arrivent dans l’ordre.
3. Le mécanisme fiable de transmission de données de SUNA 3.1 Problèmes liés au protocole traditionnel à fenêtre glissante
Le protocole TCP/IP utilise des fenêtres glissantes pour garantir une transmission fiable des données. Si la transmission de données de SUNA utilise directement le mécanisme traditionnel de fenêtre glissante TCP/IP, cela posera un problème de faible utilisation du réseau. En effet, lors du processus de transmission de données de SUNA, tant qu’aucun paquet de données n’est perdu, il n’y a pas de désordre dans l’ordre des paquets. Par conséquent, dès lors que le destinataire reçoit des paquets dans le désordre, il peut en déduire qu’un paquet de données a été perdu. Si le mécanisme traditionnel de fenêtre glissante TCP/IP est utilisé directement, même si le destinataire sait que des données ont été perdues, il ne peut pas demander à l’expéditeur de les retransmettre, mais doit attendre que le délai de retransmission de l’expéditeur expire avant de retransmettre la trame perdue.
Les problèmes actuels sont expliqués en détail ci-dessous. La figure 4 représente une fenêtre de réception d'une fenêtre glissante à 3 bits.
La limite inférieure de la fenêtre de réception est 2 et la limite supérieure est 5. À ce moment-là, le récepteur s'attendait à recevoir le paquet 2#, mais il a reçu le paquet 3#, puis les paquets 4# et 5#. Comme les trois paquets reçus se trouvaient tous dans la fenêtre de réception, ils ont été acceptés par le récepteur. Le récepteur a ensuite reçu successivement les paquets 6# et 7#. Comme le paquet 2# n’a pas été reçu, la fenêtre de réception ne peut pas avancer, et les paquets 6# et 7# qui viennent d’être reçus ne se trouvent pas dans la fenêtre de réception ; ils sont donc rejetés. Lorsque le délai d’expiration de l’expéditeur arrive à terme, celui-ci retransmet le paquet.
Paquet 2# : une fois le paquet 2# reçu, la fenêtre de réception défile vers l'avant et vous pouvez continuer à recevoir les paquets 6#, 7#, etc.
Comme le montre l’exemple ci-dessus, si l’on utilise directement le mécanisme traditionnel de fenêtre glissante TCP/IP, même si le destinataire sait que le paquet 2# a été perdu, il ne peut pas demander à l’expéditeur de le retransmettre, mais doit attendre que le temporisateur de retransmission de l’expéditeur arrive à expiration. En conséquence, la fenêtre de réception ne peut pas avancer, et les paquets 6# et 7# situés en dehors de la fenêtre doivent donc être rejetés. Cela réduit non seulement le débit du réseau, mais augmente également le délai de transmission des paquets de données.
Comme le montre l’exemple ci-dessus, si l’on utilise directement le mécanisme traditionnel de fenêtre glissante TCP/IP, même si le destinataire sait que le paquet 2# a été perdu, il ne peut pas demander à l’expéditeur de le retransmettre, mais doit attendre que le temporisateur de retransmission de l’expéditeur arrive à expiration. En conséquence, la fenêtre de réception ne peut pas avancer, et les paquets 6# et 7# situés en dehors de la fenêtre doivent donc être rejetés. Cela réduit non seulement le débit du réseau, mais augmente également le délai de transmission des paquets de données. 3.2 Protocole de fenêtre glissante amélioré
SUNA étant une architecture de réseau hiérarchique dépourvue de couche de liaison de données, il est possible d'assurer une transmission fiable des données simplement en utilisant le mécanisme de fenêtre glissante de bout en bout. Les fenêtres d'émission et de réception sont définies aux deux extrémités du circuit virtuel et servent respectivement à contrôler le rythme d'émission des paquets par l'émetteur et le rythme de réception des paquets par le récepteur.
La principale différence entre le protocole à fenêtre glissante amélioré et le protocole à fenêtre glissante traditionnel réside dans le fait que le destinataire peut déterminer s’il y a eu perte de paquet. Dès qu’un paquet est perdu, il avertit immédiatement l’expéditeur afin qu’il le retransmette, sans attendre que le temporisateur de retransmission de l’expéditeur arrive à expiration. Je viens de republier ce message. Le récepteur détermine si le paquet de données est hors séquence en se basant sur son numéro de séquence. Afin d’éviter les interférences entre les paquets de données retransmis, les améliorations suivantes doivent être apportées : marquer le paquet de données retransmis au niveau de l’émetteur ; définir une variable CURRENT au niveau du récepteur, en utilisant « To » pour représenter le numéro du paquet non retransmis reçu le plus récemment.
Examinons tout d'abord le mécanisme de mise en œuvre du récepteur. Supposons que la taille de la fenêtre glissante soit de 8. À un certain moment du processus de transmission, le récepteur reçoit un paquet de données portant le numéro r. Lorsque ce paquet n’est pas une retransmission et que son numéro r se trouve dans la fenêtre de réception, le récepteur procède différemment du protocole à fenêtre glissante traditionnel. Pour le paquet numéro r, effectuez les opérations suivantes :
