Aller au contenu principal

4. Fonctionnement du protocole de tunnel (Tunnel Protocol Operation)

Les données utilisateur transportées par le protocole PPTP sont des paquets de données PPP. Les paquets PPP sont transportés entre le PAC et le PNS, encapsulés dans des paquets GRE qui à leur tour sont transportés sur IP. Les paquets PPP encapsulés sont essentiellement des paquets de données PPP moins tous les éléments de tramage spécifiques au média. Aucun drapeau HDLC, insertion de bits, caractères de contrôle ou échappements de caractères de contrôle ne sont inclus. Aucun CRC n'est envoyé à travers le tunnel. Les paquets IP transmis sur les tunnels entre un PAC et un PNS ont la structure générale suivante :

+--------------------------------+
|          Media Header          |
|        (En-tête média)         |
+--------------------------------+
|           IP Header            |
|         (En-tête IP)           |
+--------------------------------+
|           GRE Header           |
|        (En-tête GRE)           |
+--------------------------------+
|           PPP Packet           |
|         (Paquet PPP)           |
+--------------------------------+

4.1. En-tête GRE amélioré (Enhanced GRE Header)​

L'en-tête GRE utilisé dans PPTP est légèrement amélioré par rapport à celui spécifié dans la spécification actuelle du protocole GRE [1,2]. La principale différence concerne la définition d'un nouveau champ de numéro d'accusé de réception (Acknowledgment Number), utilisé pour déterminer si un paquet GRE particulier ou un ensemble de paquets est arrivé à l'extrémité distante du tunnel. Cette capacité d'accusé de réception n'est pas utilisée conjointement avec une retransmission de paquets de données utilisateur. Elle est plutôt utilisée pour déterminer le débit auquel les paquets de données utilisateur doivent être transmis sur le tunnel pour une session utilisateur donnée. Le format de l'en-tête GRE amélioré est le suivant :

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|C|R|K|S|s|Recur|A| Flags | Ver |         Protocol Type         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    Key (HW) Payload Length    |       Key (LW) Call ID        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                  Sequence Number (Optional)                   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|               Acknowledgment Number (Optional)                |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Description des champs​

C (Bit 0) - Checksum Present (Somme de contrôle présente)

  • Mettre à 0.

R (Bit 1) - Routing Present (Routage présent)

  • Mettre à 0.

K (Bit 2) - Key Present (Clé présente)

  • Mettre à 1.

S (Bit 3) - Sequence Number Present (Numéro de séquence présent)

  • Mettre à 1 si un paquet de charge utile (données) est présent. Mettre à 0 si la charge utile n'est pas présente (le paquet GRE est un accusé de réception uniquement).

s (Bit 4) - Strict Source Route Present (Route source stricte présente)

  • Mettre à 0.

Recur (Bits 5-7) - Recursion Control (Contrôle de récursion)

  • Mettre à 0.

A (Bit 8) - Acknowledgment Sequence Number Present (Numéro de séquence d'accusé de réception présent)

  • Mettre à 1 si le paquet contient un numéro d'accusé de réception à utiliser pour accuser réception des données précédemment transmises.

Flags (Bits 9-12)

  • Doit être mis à 0 (MUST).

Ver (Bits 13-15) - Version

  • Doit contenir 1 (GRE amélioré) (MUST).

Protocol Type (Type de protocole)

  • Mettre à hexadécimal 880B [8].

Key (Clé)

  • L'utilisation du champ Clé dépend de l'implémentation. PPTP l'utilise comme suit :
    • Payload Length (Longueur de charge utile) (2 octets supérieurs de la clé) : Taille de la charge utile, sans inclure l'en-tête GRE
    • Call ID (ID d'appel) (2 octets inférieurs) : Contient l'ID d'appel du pair pour la session à laquelle ce paquet appartient

Sequence Number (Numéro de séquence)

  • Contient le numéro de séquence de la charge utile. Présent si le bit S (Bit 3) est à 1.

Acknowledgment Number (Numéro d'accusé de réception)

  • Contient le numéro de séquence du paquet GRE le plus élevé reçu par le pair émetteur pour cette session utilisateur. Présent si le bit A (Bit 8) est à 1.

La section de charge utile contient un paquet de données PPP sans aucun élément de tramage spécifique au média.

Les numéros de séquence impliqués sont des numéros de séquence par paquet. Le numéro de séquence pour chaque session utilisateur est mis à zéro au démarrage de la session. Chaque paquet envoyé pour une session utilisateur donnée qui contient une charge utile (et a le bit S (Bit 3) mis à 1) se voit attribuer le prochain numéro de séquence consécutif pour cette session.

Ce protocole permet aux accusés de réception d'être transportés avec les données et rend le protocole global plus efficace, ce qui nécessite à son tour moins de mise en mémoire tampon des paquets.

4.2. Protocole à fenêtre glissante (Sliding Window Protocol)​

Le protocole à fenêtre glissante utilisé sur le chemin de données PPTP est utilisé pour le contrôle de flux par chaque côté de l'échange de données. Le protocole GRE amélioré permet aux accusés de réception de paquets d'être superposés sur les paquets de données. Les accusés de réception peuvent également être envoyés séparément des paquets de données. Encore une fois, le but principal du protocole à fenêtre glissante est le contrôle de flux - les retransmissions ne sont pas effectuées par les pairs du tunnel.

4.2.1. Taille de fenêtre initiale (Initial Window Size)​

Bien que chaque côté ait indiqué la taille maximale de sa fenêtre de réception, il est recommandé d'adopter une approche conservatrice lors du début de la transmission de données. La taille de fenêtre initiale sur l'émetteur est fixée à la moitié de la taille maximale demandée par le récepteur, avec une taille minimale d'un paquet. L'émetteur arrête d'envoyer des paquets lorsque le nombre de paquets en attente d'accusé de réception est égal à la taille de fenêtre actuelle. Au fur et à mesure que le récepteur digère avec succès chaque fenêtre, la taille de fenêtre sur l'émetteur est augmentée d'un paquet jusqu'à ce que le maximum soit atteint. Cette méthode empêche un système d'inonder un réseau déjà congestionné car aucun historique n'a été établi.

4.2.2. Fermeture de la fenêtre (Closing the Window)​

Lorsqu'un délai d'expiration se produit sur un paquet, l'émetteur ajuste la taille de la fenêtre de transmission à la moitié de sa valeur au moment de l'échec. Les fractions sont arrondies vers le haut, et la taille de fenêtre minimale est de 1.

4.2.3. Ouverture de la fenêtre (Opening the Window)​

Avec chaque transmission réussie d'une fenêtre de paquets sans délai d'expiration, la taille de fenêtre de transmission est augmentée d'un paquet jusqu'à ce qu'elle atteigne la taille de fenêtre maximale qui a été envoyée par l'autre côté lorsque l'appel a été connecté. Comme indiqué précédemment, aucune retransmission n'est effectuée lors d'un délai d'expiration. Après un délai d'expiration, la transmission reprend avec la fenêtre commençant à la moitié de la taille de la fenêtre de transmission lorsque le délai d'expiration s'est produit et s'ajustant vers le haut d'un chaque fois que la fenêtre de transmission est remplie de paquets qui sont tous accusés de réception sans délais d'expiration.

4.2.4. Débordement de fenêtre (Window Overflow)​

Lorsque la fenêtre d'un récepteur déborde avec trop de paquets entrants, les paquets excédentaires sont jetés. Cette situation ne devrait pas survenir si les procédures de fenêtre glissante sont correctement suivies par l'émetteur et le récepteur. On suppose que, du côté de l'émission, les paquets sont mis en mémoire tampon pour la transmission et ne sont plus acceptés de la source de paquets lorsque le tampon de transmission se remplit.

4.2.5. Accusé de réception multi-paquets (Multi-packet Acknowledgment)​

Une caractéristique du protocole à fenêtre glissante PPTP est qu'il permet l'accusé de réception de plusieurs paquets avec un seul accusé de réception. Tous les paquets en suspens avec un numéro de séquence inférieur ou égal au numéro d'accusé de réception sont considérés comme accusés de réception. Les calculs de délai d'expiration sont effectués en utilisant l'heure à laquelle le paquet correspondant au numéro de séquence le plus élevé accusé de réception a été transmis.

Les calculs de délai d'expiration adaptatifs ne sont effectués que lorsqu'un accusé de réception est reçu. Lorsque des accusés de réception multi-paquets sont utilisés, la surcharge de l'algorithme de délai d'expiration adaptatif est réduite. Le PAC n'est pas tenu (not required) de transmettre des accusés de réception multi-paquets ; il peut plutôt accuser réception de chaque paquet individuellement lorsqu'il est livré au client PPP.

4.3. Paquets hors séquence (Out-of-sequence Packets)​

Occasionnellement, les paquets perdent leur séquençage à travers un internetwork compliqué. Disons, par exemple, qu'un PNS envoie les paquets 0 à 5 à un PAC. En raison du reroutage dans l'internetwork, le paquet 4 arrive au PAC avant le paquet 3. Le PAC accuse réception du paquet 4 et peut supposer que le paquet 3 est perdu. Cet accusé de réception accorde un crédit de fenêtre au-delà du paquet 4.

Lorsque le PAC reçoit effectivement le paquet 3, il ne doit pas (MUST NOT) tenter de le transmettre au client PPP correspondant. Le faire pourrait causer des problèmes, car le fonctionnement correct du protocole PPP est basé sur la réception de paquets dans l'ordre. PPP gère correctement la perte de paquets, mais pas la réorganisation, donc les paquets hors séquence entre le PNS et le PAC doivent être silencieusement jetés (MUST), ou ils peuvent être réordonnés par le récepteur. Lorsque le paquet 5 arrive, il est accusé de réception par le PAC puisqu'il a un numéro de séquence plus élevé que 4, qui était le dernier paquet le plus élevé accusé de réception par le PAC. Des paquets avec des numéros de séquence en double ne devraient jamais se produire puisque le PAC et le PNS ne retransmettent jamais de paquets GRE. Une implémentation robuste jettera silencieusement les paquets GRE en double, si elle en reçoit.

4.4. Délais d'expiration d'accusé de réception (Acknowledgment Time-Outs)​

PPTP utilise des fenêtres glissantes et des délais d'expiration pour fournir à la fois un contrôle de flux de session utilisateur à travers l'internetwork et pour effectuer une mise en mémoire tampon de données efficace afin de maintenir les canaux de données PAC-PNS pleins sans provoquer de débordement de tampon de réception. PPTP exige qu'un délai d'expiration soit utilisé pour récupérer des paquets de données ou d'accusé de réception perdus. L'implémentation exacte du délai d'expiration est spécifique au fournisseur. Il est suggéré qu'un délai d'expiration adaptatif soit implémenté avec un recul pour le contrôle de la congestion. Le mécanisme de délai d'expiration proposé ici a les propriétés suivantes :

  • Délais d'expiration indépendants pour chaque session : Un dispositif (PAC ou PNS) devra maintenir et calculer des délais d'expiration pour chaque session active.
  • Un délai d'expiration maximum ajustable par l'administrateur (MaxTimeOut) : Unique à chaque dispositif.
  • Un mécanisme de délai d'expiration adaptatif : Qui compense le débit changeant. Pour réduire la surcharge de traitement des paquets, les fournisseurs peuvent choisir de ne pas recalculer le délai d'expiration adaptatif pour chaque accusé de réception reçu. Le résultat de cette réduction de surcharge est que le délai d'expiration ne répondra pas aussi rapidement aux changements rapides du réseau.
  • Recul du temporisateur lors du délai d'expiration : Pour réduire la congestion. La valeur du temporisateur reculé est limitée par la valeur de délai d'expiration maximum configurable. Le recul du temporisateur est effectué chaque fois qu'un délai d'expiration d'accusé de réception se produit.

En général, ce mécanisme a le comportement souhaitable de reculer rapidement lors d'un délai d'expiration et de diminuer lentement la valeur du délai d'expiration lorsque les paquets sont livrés sans délais d'expiration.

Définitions​

Packet Processing Delay (PPD) - Délai de traitement des paquets

  • Le temps nécessaire pour que chaque côté traite la quantité maximale de données mise en mémoire tampon dans leur fenêtre glissante de réception de paquets. Le PPD est la valeur échangée entre le PAC et le PNS lorsqu'un appel est établi. Pour le PNS, ce nombre devrait être petit. Pour un PAC effectuant des connexions modem, ce nombre pourrait être significatif.

Sample (Échantillon)

  • Le temps réel encouru pour recevoir un accusé de réception pour un paquet. L'échantillon est mesuré, pas calculé.

Round-Trip Time (RTT) - Temps aller-retour

  • Le temps aller-retour estimé pour qu'un accusé de réception soit reçu pour un paquet transmis donné. Lorsque le lien réseau est un réseau local, ce délai sera minimal (sinon nul). Lorsque le lien réseau est Internet, ce délai pourrait être substantiel et varier largement. Le RTT est adaptatif : il s'ajustera pour inclure le PPD et tous les délais réseau changeants qui contribuent au temps entre la transmission d'un paquet et la réception de son accusé de réception.

Adaptive Time-Out (ATO) - Délai d'expiration adaptatif

  • Le temps qui doit s'écouler avant qu'un accusé de réception soit considéré comme perdu. Après un délai d'expiration, la fenêtre glissante est partiellement fermée et l'ATO est reculé.

Le paramètre de délai de traitement des paquets (PPD) est un mot de 16 bits échangé pendant la phase de contrôle d'appel qui représente des dixièmes de seconde (64 signifie 6,4 secondes). Le protocole spécifie seulement que le paramètre est échangé, il ne spécifie pas comment il est calculé. La manière dont les valeurs pour PPD sont calculées dépend de l'implémentation et n'a pas besoin d'être variable (les délais d'expiration statiques sont autorisés). Le PPD doit être échangé (MUST) dans les séquences de connexion d'appel, même s'il reste constant dans une implémentation. Une façon possible de calculer le PPD est :

PPD' = ((PPP_MAX_DATA_MTU - Header) * WindowSize * 8) / ConnectRate
PPD = PPD' + PACFudge

Où :

  • Header est la taille totale des en-têtes IP et GRE, qui est de 36
  • MTU est le MTU global pour le lien internetwork entre le PAC et le PNS
  • WindowSize représente le nombre de paquets dans la fenêtre glissante et dépend de l'implémentation
  • La constante 8 convertit les octets en bits (en supposant que ConnectRate est en bits par seconde)
  • PACFudge n'est pas requis mais peut être utilisé pour prendre en compte la surcharge de traitement globale du PAC

La valeur de PPD est utilisée pour initialiser l'algorithme adaptatif avec la valeur initiale RTT[n-1].

4.4.1. Calcul du délai d'expiration d'accusé de réception adaptatif (Calculating Adaptive Acknowledgment Time-Out)​

Nous devons encore décider combien de temps allouer pour que les accusés de réception reviennent. Si le délai d'expiration est réglé trop haut, nous pouvons attendre inutilement longtemps pour les paquets perdus. Si le délai d'expiration est trop court, nous pouvons expirer juste avant l'arrivée de l'accusé de réception. Le délai d'expiration d'accusé de réception devrait également être raisonnable et réactif aux conditions réseau changeantes.

L'algorithme adaptatif suggéré détaillé ci-dessous est basé sur l'implémentation TCP 1989 et est expliqué dans [11]. 'n' signifie le paquet actuel et 'n-1' signifie le paquet précédent :

Err[n] = Sample[n] - RTT[n-1]
RTT[n] = RTT[n-1] + (g * Err[n])
Dev[n] = Dev[n-1] + h * (|Err[n]| - Dev[n-1])
ATO[n] = RTT[n] + (f * Dev[n])

Où :

  • g est le facteur de gain (valeur recommandée 0.125)
  • h est le facteur de gain de déviation (valeur recommandée 0.25)
  • f est le facteur de multiplication de déviation (valeur recommandée 4)

4.4.2. Contrôle de congestion : Ajustement pour le délai d'expiration (Congestion Control: Adjusting for Time-Out)​

Cette section décrit comment le calcul de l'ATO est modifié dans le cas où un délai d'expiration se produit. Lorsqu'un délai d'expiration se produit, la valeur du délai d'expiration devrait être ajustée rapidement vers le haut. Bien que les paquets GRE ne soient pas retransmis lorsqu'un délai d'expiration se produit, le délai d'expiration devrait être ajusté vers une limite maximale. Pour compenser les délais temporels internetwork changeants, une stratégie doit être employée pour augmenter le délai d'expiration lorsqu'il expire (notez qu'en plus d'augmenter le délai d'expiration, nous rétrécissons également la taille de la fenêtre comme décrit dans la section suivante).

Pour un intervalle dans lequel un délai d'expiration se produit :

ATO[n] = MIN(2 * ATO[n-1], MaxTimeOut)

Où MaxTimeOut est la valeur de délai d'expiration maximum configurée par l'administrateur.

Dernière mise à jour le