5. Fonctionnement du Protocole
La configuration nécessaire pour tunneliser une session PPP avec L2TP consiste en deux étapes : (1) établir la connexion de contrôle pour un tunnel, et (2) établir une session déclenchée par une demande d'appel entrant ou sortant. Le tunnel et la connexion de contrôle correspondante DOIVENT être établis avant qu'un appel entrant ou sortant ne soit initié. Une session L2TP DOIT être établie avant que L2TP puisse commencer à tunneliser des trames PPP. Plusieurs sessions peuvent exister sur un seul tunnel et plusieurs tunnels peuvent exister entre le même LAC et LNS.
5.1 Établissement de la Connexion de Contrôle
La connexion de contrôle est la connexion initiale qui doit être réalisée entre un LAC et un LNS avant que les sessions puissent être établies. L'établissement de la connexion de contrôle comprend la sécurisation de l'identité du pair, ainsi que l'identification de la version L2TP du pair, des capacités de tramage et de support, etc.
Un échange de trois messages est utilisé pour configurer la connexion de contrôle. Voici un échange de messages typique :
LAC or LNS LAC or LNS
---------- ----------
SCCRQ ->
<- SCCRP
SCCCN ->
<- ZLB ACK
Le ZLB ACK est envoyé s'il n'y a plus de messages en attente dans la file d'attente pour ce pair.
5.1.1 Authentification du Tunnel
L2TP incorpore un système d'authentification de tunnel simple, optionnel, de type CHAP [RFC1994] lors de l'établissement de la connexion de contrôle. Si un LAC ou LNS souhaite authentifier l'identité du pair qu'il contacte ou par lequel il est contacté, un AVP Challenge est inclus dans le message SCCRQ ou SCCRP. Si un AVP Challenge est reçu dans un SCCRQ ou SCCRP, un AVP Challenge Response DOIT être envoyé dans le SCCRP ou SCCCN suivant, respectivement. Si la réponse attendue et la réponse reçue d'un pair ne correspondent pas, l'établissement du tunnel DOIT être refusé.
Pour participer à l'authentification du tunnel, un seul secret partagé DOIT exister entre le LAC et le LNS. C'est le même secret partagé utilisé pour le masquage AVP (voir section 4.3). Voir la section 4.4.3 pour les détails sur la construction des AVP Challenge et Response.
5.2 Établissement de Session
Après l'établissement réussi de la connexion de contrôle, des sessions individuelles peuvent être créées. Chaque session correspond à un flux PPP unique entre le LAC et le LNS. Contrairement à l'établissement de la connexion de contrôle, l'établissement de session est directionnel par rapport au LAC et au LNS. Le LAC demande au LNS d'accepter une session pour un appel entrant, et le LNS demande au LAC d'accepter une session pour passer un appel sortant.
5.2.1 Établissement d'Appel Entrant
Un échange de trois messages est utilisé pour configurer la session. Voici une séquence typique d'événements :
LAC LNS
--- ---
(Call
Detected)
ICRQ ->
<- ICRP
ICCN ->
<- ZLB ACK
Le ZLB ACK est envoyé s'il n'y a plus de messages en attente dans la file d'attente pour ce pair.
5.2.2 Établissement d'Appel Sortant
Un échange de trois messages est utilisé pour configurer la session. Voici une séquence typique d'événements :
LAC LNS
--- ---
<- OCRQ
OCRP ->
(Perform
Call
Operation)
OCCN ->
<- ZLB ACK
Le ZLB ACK est envoyé s'il n'y a plus de messages en attente dans la file d'attente pour ce pair.
5.3 Transfert des Trames PPP
Une fois l'établissement du tunnel terminé, les trames PPP du système distant sont reçues au LAC, dépouillées du CRC, du tramage de liaison et des octets de transparence, encapsulées dans L2TP et transférées sur le tunnel approprié. Le LNS reçoit le paquet L2TP et traite la trame PPP encapsulée comme si elle était reçue sur une interface PPP locale.
L'expéditeur d'un message associé à une session et un tunnel particuliers place le Session ID et le Tunnel ID (spécifiés par son pair) dans l'en-tête Session ID et Tunnel ID pour tous les messages sortants. De cette manière, les trames PPP sont multiplexées et démultiplexées sur un seul tunnel entre une paire LNS-LAC donnée. Plusieurs tunnels peuvent exister entre une paire LNS-LAC donnée, et plusieurs sessions peuvent exister dans un tunnel.
La valeur 0 pour Session ID et Tunnel ID est spéciale et NE DOIT PAS être utilisée comme Assigned Session ID ou Assigned Tunnel ID. Pour les cas où un Session ID n'a pas encore été attribué par le pair (c'est-à-dire pendant l'établissement d'une nouvelle session ou tunnel), le champ Session ID DOIT être envoyé comme 0, et l'AVP Assigned Session ID dans le message DOIT être utilisé pour identifier la session. De même, pour les cas où le Tunnel ID n'a pas encore été attribué par le pair, le Tunnel ID DOIT être envoyé comme 0 et l'AVP Assigned Tunnel ID utilisé pour identifier le tunnel.
5.4 Utilisation des Numéros de Séquence sur le Canal de Données
Les numéros de séquence sont définis dans l'en-tête L2TP pour les messages de contrôle et éventuellement pour les messages de données (voir section 3.1). Ceux-ci sont utilisés pour fournir un transport de messages de contrôle fiable (voir section 5.8) et un séquencement optionnel des messages de données. Chaque pair maintient des numéros de séquence séparés pour la connexion de contrôle et chaque session de données individuelle dans un tunnel.
Contrairement au canal de contrôle L2TP, le canal de données L2TP n'utilise pas les numéros de séquence pour retransmettre les messages de données perdus. Au lieu de cela, les messages de données peuvent utiliser des numéros de séquence pour détecter les paquets perdus et/ou restaurer la séquence d'origine des paquets qui peuvent avoir été réordonnés pendant le transport.
5.5 Keepalive (Hello)
Un mécanisme de keepalive est employé par L2TP afin de différencier les pannes de tunnel des périodes prolongées sans activité de contrôle ou de données sur un tunnel. Cela est accompli en injectant des messages de contrôle Hello (voir section 6.5) après qu'une période de temps spécifiée se soit écoulée depuis la dernière réception d'un message de données ou de contrôle sur un tunnel.
5.6 Démontage de Session
Le démontage de session peut être initié par le LAC ou le LNS et est accompli en envoyant un message de contrôle CDN. Après que la dernière session est effacée, la connexion de contrôle PEUT également être détruite (et c'est généralement le cas).
5.7 Démontage de la Connexion de Contrôle
Le démontage de la connexion de contrôle peut être initié par le LAC ou le LNS et est accompli en envoyant un seul message de contrôle StopCCN. Le récepteur d'un StopCCN DOIT envoyer un ZLB ACK pour accuser réception du message et maintenir suffisamment d'état de connexion de contrôle pour accepter correctement les retransmissions StopCCN sur au moins un cycle de retransmission complet (au cas où le ZLB ACK serait perdu). Le temps recommandé pour un cycle de retransmission complet est de 31 secondes (voir section 5.8).
Une implémentation peut arrêter un tunnel entier et toutes les sessions sur le tunnel en envoyant le StopCCN. Ainsi, il n'est pas nécessaire d'effacer chaque session individuellement lors du démontage de l'ensemble du tunnel.
5.8 Livraison Fiable des Messages de Contrôle
L2TP fournit un service de transport fiable de niveau inférieur pour tous les messages de contrôle. Les champs Nr et Ns de l'en-tête du message de contrôle (voir section 3.1) appartiennent à ce transport. Les fonctions de niveau supérieur de L2TP ne sont pas concernées par la retransmission ou l'ordonnancement des messages de contrôle.
Le numéro de séquence de message, Ns, commence à 0. Chaque message suivant est envoyé avec l'incrément suivant du numéro de séquence. Le numéro de séquence est donc un compteur en cours d'exécution représenté modulo 65536.
(Chapitre 5 terminé)