3. Protocol Overview (Vue d'ensemble du protocole)
L2TP utilise deux types de messages : les messages de contrôle (control messages) et les messages de données (data messages). Les messages de contrôle sont utilisés dans l'établissement, la maintenance et la suppression des tunnels et des appels. Les messages de données sont utilisés pour encapsuler les trames PPP transportées sur le tunnel. Les messages de contrôle utilisent un canal de contrôle fiable (reliable Control Channel) au sein de L2TP pour garantir la livraison (voir la section 5.1 pour plus de détails). Les messages de données ne sont pas retransmis en cas de perte de paquets.
+-------------------+
| PPP Frames |
+-------------------+ +-----------------------+
| L2TP Data Messages| | L2TP Control Messages |
+-------------------+ +-----------------------+
| L2TP Data Channel | | L2TP Control Channel |
| (unreliable) | | (reliable) |
+------------------------------------------------+
| Packet Transport (UDP, FR, ATM, etc.) |
+------------------------------------------------+
Figure 3.0 Structure du protocole L2TP
La figure 3.0 représente la relation entre les trames PPP et les messages de contrôle sur les canaux de contrôle et de données L2TP. Les trames PPP sont transmises sur un canal de données non fiable, encapsulées d'abord par un en-tête L2TP puis par un transport de paquets tel que UDP, Frame Relay, ATM, etc. Les messages de contrôle sont envoyés sur un canal de contrôle L2TP fiable qui transmet les paquets en bande sur le même transport de paquets.
Les numéros de séquence doivent (MUST) être présents dans tous les messages de contrôle et sont utilisés pour fournir une livraison fiable sur le canal de contrôle. Les messages de données peuvent (MAY) utiliser des numéros de séquence pour réordonner les paquets et détecter les paquets perdus.
Toutes les valeurs sont placées dans leurs champs respectifs et envoyées dans l'ordre réseau (octets de poids fort en premier).
3.1 L2TP Header Format (Format de l'en-tête L2TP)
Les paquets L2TP pour le canal de contrôle et le canal de données partagent un format d'en-tête commun. Dans chaque cas où un champ est optionnel, son espace n'existe pas dans le message si le champ est marqué comme non présent. Notez que bien qu'optionnels sur les messages de données, les champs Length, Ns et Nr marqués comme optionnels ci-dessous doivent (MUST) être présents sur tous les messages de contrôle.
Cet en-tête est formaté ainsi :
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|T|L|x|x|S|x|O|P|x|x|x|x| Ver | Length (opt) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tunnel ID | Session ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ns (opt) | Nr (opt) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Offset Size (opt) | Offset pad... (opt)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3.1 En-tête de message L2TP
Le bit Type (T) indique le type de message. Il est défini à 0 pour un message de données et à 1 pour un message de contrôle.
Si le bit Length (L) est à 1, le champ Length est présent. Ce bit doit (MUST) être défini à 1 pour les messages de contrôle.
Les bits x sont réservés pour les extensions futures. Tous les bits réservés doivent (MUST) être définis à 0 sur les messages sortants et ignorés sur les messages entrants.
Si le bit Sequence (S) est défini à 1, les champs Ns et Nr sont présents. Le bit S doit (MUST) être défini à 1 pour les messages de contrôle.
Si le bit Offset (O) est à 1, le champ Offset Size est présent. Le bit O doit (MUST) être défini à 0 (zéro) pour les messages de contrôle.
Si le bit Priority (P) est à 1, ce message de données devrait (SHOULD) recevoir un traitement préférentiel dans sa mise en file d'attente et sa transmission locales. Les requêtes d'écho LCP utilisées comme keepalive pour le lien, par exemple, devraient (SHOULD) généralement être envoyées avec ce bit défini à 1. Sans cela, un intervalle temporaire de congestion locale pourrait entraîner une interférence avec les messages keepalive et une perte inutile du lien. Cette fonctionnalité est uniquement destinée aux messages de données. Le bit P doit (MUST) être défini à 0 pour tous les messages de contrôle.
Ver doit (MUST) être 2, indiquant la version de l'en-tête de message de données L2TP décrite dans ce document. La valeur 1 est réservée pour permettre la détection des paquets L2F [RFC2341] s'ils arrivent mélangés avec des paquets L2TP. Les paquets reçus avec un champ Ver inconnu doivent (MUST) être rejetés.
Le champ Length indique la longueur totale du message en octets.
Tunnel ID indique l'identifiant de la connexion de contrôle. Les tunnels L2TP sont nommés par des identifiants qui n'ont qu'une signification locale. C'est-à-dire que le même tunnel recevra des Tunnel ID différents à chaque extrémité du tunnel. Le Tunnel ID dans chaque message est celui du destinataire prévu, et non de l'expéditeur. Les Tunnel ID sont sélectionnés et échangés en tant qu'AVP Assigned Tunnel ID lors de la création d'un tunnel.
Session ID indique l'identifiant d'une session au sein d'un tunnel. Les sessions L2TP sont nommées par des identifiants qui n'ont qu'une signification locale. C'est-à-dire que la même session recevra des Session ID différents à chaque extrémité de la session. Le Session ID dans chaque message est celui du destinataire prévu, et non de l'expéditeur. Les Session ID sont sélectionnés et échangés en tant qu'AVP Assigned Session ID lors de la création d'une session.
Ns indique le numéro de séquence pour ce message de données ou de contrôle, commençant à zéro et s'incrémentant d'un (modulo 2**16) pour chaque message envoyé. Voir les sections 5.8 et 5.4 pour plus d'informations sur l'utilisation de ce champ.
Nr indique le numéro de séquence attendu dans le prochain message de contrôle à recevoir. Ainsi, Nr est défini sur le Ns du dernier message reçu dans l'ordre plus un (modulo 2**16). Dans les messages de données, Nr est réservé et, s'il est présent (comme indiqué par le bit S), doit (MUST) être ignoré à la réception. Voir la section 5.8 pour plus d'informations sur l'utilisation de ce champ dans les messages de contrôle.
Le champ Offset Size, s'il est présent, spécifie le nombre d'octets après l'en-tête L2TP auquel les données de charge utile doivent commencer. Les données réelles dans le remplissage d'offset ne sont pas définies. Si le champ offset est présent, l'en-tête L2TP se termine après le dernier octet du remplissage d'offset.
3.2 Control Message Types (Types de messages de contrôle)
L'AVP Message Type (voir section 4.4.1) définit le type spécifique de message de contrôle envoyé. Rappelons de la section 3.1 que cela concerne uniquement les messages de contrôle, c'est-à-dire les messages avec le bit T défini à 1.
Ce document définit les types de messages de contrôle suivants (voir les sections 6.1 à 6.14 pour plus de détails sur la construction et l'utilisation de chaque message) :
Gestion de la connexion de contrôle (Control Connection Management)
- 0 (reserved) réservé
- 1 (SCCRQ) Start-Control-Connection-Request
- 2 (SCCRP) Start-Control-Connection-Reply
- 3 (SCCCN) Start-Control-Connection-Connected
- 4 (StopCCN) Stop-Control-Connection-Notification
- 5 (reserved) réservé
- 6 (HELLO) Hello
Gestion des appels (Call Management)
- 7 (OCRQ) Outgoing-Call-Request
- 8 (OCRP) Outgoing-Call-Reply
- 9 (OCCN) Outgoing-Call-Connected
- 10 (ICRQ) Incoming-Call-Request
- 11 (ICRP) Incoming-Call-Reply
- 12 (ICCN) Incoming-Call-Connected
- 13 (reserved) réservé
- 14 (CDN) Call-Disconnect-Notify
Rapport d'erreurs (Error Reporting)
- 15 (WEN) WAN-Error-Notify
Contrôle de session PPP (PPP Session Control)
- 16 (SLI) Set-Link-Info