|
Sujet :
| Présentation du protocole point-à-point (PPP)
| Contexte :
| Version HTML d'un rapport réalisé dans le cadre de cours de premières année à l'ENST.
| Date :
| 17 Juin 1996 (document original) | 13 Avril 1998 (version HTML) Auteurs :
| Ghislaine Labouret, Jean-Christophe Lator
| Droits d'auteur :
| Reproduction autorisée à condition de mentionner les auteurs originaux et de donner l'URL de ce document.
| |


Ce dossier a pour but de donner au lecteur une vision synthétique du protocole PPP en mettant en relief deux éléments clés :
Nous allons, dans une première partie, donner une vision globale du fonctionnement de PPP, afin que le lecteur sache quelles sont les grandes lignes de ce protocole. Puis nous réaliserons une analyse plus détaillée, en explicitant le format des trames utilisé par PPP et le principe de l'encapsulation. Pour finir, nous détaillerons le fonctionnement du sous-protocole chargé d'établir et de configurer la liaison, LCP, et nous donnerons un exemple d'ouverture de liaison.
PPP peut être utilisé sur une ligne synchrone (orientée bit ou octet) ou sur une ligne asynchrone (8 bits sans parité).
En mode standard, PPP ne nécessite pas l'utilisation des signaux de contrôle du modem tels que RTS (Request To Send), CTS (Clear To Send), DCD (Data Carrier Detect) ou DTR (Data Terminal Ready). En revanche, ces signaux sont utilisés dans le mode numéroté (Numbered-Mode, voir chapitre 2.2.3).
Dans tous les cas, la ligne doit être exploitable en duplex intégral. Elle peut en revanche être soit orientée connexion (dedicated), soit sans connexion (circuit-switched).
Le schéma ci-dessous indique la place respective des différentes composantes suivant les couches et leur répartition temporelle (le temps s'écoule de gauche à droite).

Les différentes phases qu'implique ce schéma sont détaillées ci-dessous.
+------+ +-----------+ +--------------+
| Mort | UP | Etablir | OUVRIR | Identifier | SUCCÈS/AUCUN
|(Dead)|---->|(Establish)|-------->|(Authenticate)|----+
+------+ +-----------+ +--------------+ |
^ | | |
| ECHEC | ÉCHEC | |
+<------------+ +---------+ |
| | |
| | |
| | |
| | |
| DOWN +-----------+ | FERMER +----------+ |
+-------| Terminer |<---+<-----------| Réseau |<--+
|(Terminate)| | (Network)|
+-----------+ +----------+
Phase liaison morte (Dead)
Cet état correspond à un moment où la liaison n'est pas prête à recevoir des données. Toute connexion commence par cette étape. PPP passe à l'étape suivante (événement "UP") lorsqu'un événement extérieur se produit (détection d'une porteuse par exemple).
Phase d'établissement de la liaison (Establish)
C'est durant cette phase que le LCP (Link Control Protocol) est utilisé pour établir et configurer la liaison (voir détails au chapitre 3).
Phase d'identification (Authenticate)
Cette phase est facultative. Si l'utilisation d'un protocole d'authentification (PAP, CHAP, EAP) a été demandée pendant les négociations du LCP, on lance ce protocole avant tout autre échange de données. Si cette phase échoue, la liaison est coupée (événement "DOWN").
Phase de configuration et d'utilisation des différents protocole de la couche réseau (Network)
Une fois la liaison établie par le LCP, un ou plusieurs NCPs doivent être configurés pour permettre aux protocoles correspondants de transférer des données par encapsulage dans les trames de PPP. Dès qu'un NCP a atteint l'état ouvert, le NP correspondant peut transporter des données jusqu'à la fermeture de son NCP.
Phase de terminaison (Terminate)
Pour fermer la liaison, on utilise à nouveau le LCP, en échangeant des paquets du type Terminate. Le LCP informe alors les protocoles de la couche réseau (Network Protocols, NPs) que la liaison va être coupée. Si la terminaison est provoquée de manière délibérée par envoi d'un paquet de type Terminate-Request, il faut attendre l'arrivée d'un paquet de type Terminate-Ack avant de fermer effectivement la liaison par l'événement "DOWN" (voir chapitre 3.1.2).
+----------+----------+----------+-----------+-------------+ | Flag | Adress | Control | Protocol | Information | | 01111110 | 11111111 | 00000011 | 8/16 bits | * | +----------+----------+----------+-----------+-------------+ +---------+------------+------------+---------------------- | Padding | FCS | Flag | Inter-frame Fill | * | 16/32 bits | 01111110 | ou Adresse suivante +---------+------------+------------+---------------------- (les champs sont transmis de la gauche vers la droite)
Le fanion (Flag)
Tout comme pour le protocole LAP-B, les trames sont délimitées par un fanion, en l'occurrence la séquence binaire 01111110 (0x7E).
Le champ Adresse (Adress)
En mode standard, ce champ contient l'adresse de diffusion à tous les récepteurs, 11111111 (0xFF). L'intérêt est que si un réseau est relié derrière la liaison point à point, toutes les machines en aval recevront les messages qui transitent par la liaison point à point. Cela simplifie la diffusion de messages à un ensemble de machines, car il suffit pour cela d'envoyer le message à une adresse unique.
Le champ Contrôle (Control)
La séquence standard 00000011 (0x03) indique que la trame est une trame d'information non numérotée (UI, Un-numbered Information). Il est possible d'utiliser un mode numéroté pour plus de fiabilité (voir chapitre 2.2.2). La valeur 00000011 correspond également à un bit P/F positionné à 0.
Le champs Protocole (Protocol)
Ce champ ne vient pas de HDLC mais est propre à PPP. Codé sur 1 ou 2 octets, il indique quel protocole transmet des données dans le champs Information. C'est là le principe de l'encapsulation, qui permet à un protocole de la couche réseau de transférer des données par l'intermédiaire du champ Information d'une trame PPP standard. À tout protocole est associé un numéro :
La liste des derniers numéros en date peut être consultée sur http://www.iana.org/assignments/ppp-numbers.
Le champs Information (Information)
Le champs d'information, de longueur variable, contient les données à transmettre, et en particulier toutes les données envoyées par les NPs.
Le champs Bourrage (Padding)
Afin de pouvoir mettre en oeuvre le contrôle d'erreur, la longueur d'une trame est limitée par le MRU (Maximum Receive Unit), dont la valeur par défaut est de 1500 octets. Le champs Bourrage contient des bits non significatifs qui complètent toute trame de longueur utile inférieure au MRU. C'est au protocole auquel sont destinées les données de faire la différence entre les champs Information et Bourrage.
Le champs Détection d'erreurs (Frame Check Sequence)
Le code correcteur d'erreur place ici de l'information redondante afin de détecter si une erreur s'est produite. Le calcul est effectué sur l'ensemble des champs Adresse, Contrôle, Protocole, Information et Bourrage, avant l'ajout des bits ou octets de transparence (voir chapitre 2.3) et des bits start ou stop. Le système utilisé est un contrôle polynomial de polynôme générateur 1+x^5+x^12+x^16 si le codage se fait sur 16 bits (valeur par défaut). Il est également possible de négocier une FCS de 32 bits ; cela réduit le taux d'erreur résiduelle, mais diminue le débit car chaque trame s'allonge. Ce champ est transmis de bit de poids faible au bit de poids fort. A la réception, on supprime les bits ou octets de transparence et les bits start ou stop avant de vérifier l'absence d'erreur.
Au niveau physique, la différence avec le PPP standard est que le Numbered-Mode implique une orientation connexion. Il requiert en particulier, tout comme LAP-B, l'utilisation de signaux de contrôle pour indiquer la connexion et la déconnexion. Ce sont ces signaux qui envoient les ordres Up et Down au LCP (voir chapitre 1.2).
Au niveau de la couche liaison de données, le Numbered-Mode se rapproche beaucoup de LAP-B. Par rapport au PPP standard, seuls les champs Adresse et Contrôle sont différents, le reste de la trame restant conforme à la description donnée au chapitre 2.1. Au cours de la négociation des options du Numbered-Mode, les machines s'accordent sur une valeur pour le champ Adresse, conformément à la norme ISO 3309 ; pour une liaison simple, on utilise généralement la valeur 1 ou 3. Cette valeur sera ensuite utilisée à la place de la valeur par défaut, 0xFF. Le champ Contrôle peut prendre n'importe laquelle des valeurs valides de la norme ISO 7776. Durant la négociation, les machines s'accordent également sur la largeur des fenêtres, qui peut varier de 1 à 127 ; si ce nombre est inférieur à 8, on travaillera modulo 8, sinon on travaillera modulo 128.
La transparence utilise le caractère d'échappement (Control Escape), dont la valeur est 01111101. Après le calcul et l'ajout de la FCS, l'émetteur examine l'ensemble de la trame entre les deux fanions. Le caractère d'échappement, le fanion et les caractère cochés dans l'ACCM (voir chapitre 3.3.3) sont remplacés par un ensemble de deux octets : le caractère d'échappement suivi du caractère original auquel on a appliqué un ou-exclusif avec 0x20. A la réception, chaque caractère d'échappement est retiré, et on applique un ou-exclusif avec 0x20 au caractère suivant.
Sur une ligne asynchrone, le remplissage inter-trames est effectué en envoyant une série ininterrompue de "1". Pour une ligne synchrone, on transmet la fanion de façon répétée.
Sur une ligne asynchrone, les octets sont transmis du bit de poids faible au bit de poids fort, avec un bit start avant et un bit stop après. Pour une ligne synchrone, le choix de la méthode de transmission utilisée est laissé à l'équipement matériel.
La transparence est obtenue en ajoutant un "0" après chaque suite de 5 "1" consécutifs. Cette opération est effectuée après l'ajout de la FCS. A la réception, les bits ajoutés sont supprimés avant de vérifier la FCS.
Le plus souvent, le remplissage inter-trame est obtenu en transmettant le fanion de façon répétée. Il peut également être nécessaire, pour certaines lignes, de transmettre une suite d'au moins 15 "1" consécutifs entre deux fanions pendant l'inter-trame.
Les octets sont transmis du bit de poids faible au bit de poids fort.
+----------+------------+-----------+------------------------ | Code | Identifier | Length | Data... | 8 bits | 8 bits | 16 bits | +----------+------------+-----------+------------------------
Le champ Code (Code)
Il indique le type de paquet émis par un numéro prédéfini :
Le champ Identificateur (Identifier)
Chaque fois qu'une machine envoie un paquet, elle lui attribue un numéro différent ; la réponse à ce paquet devra porter le même numéro. Cette méthode aide à faire se correspondre les demandes et les réponses.
Le champ Longueur (Length)
Ces deux octets servent à donner la longueur du paquet dans sa totalité (entre 4 et 2^(16-1)).
Le champ Données (Data)
Il contient les éventuels paramètres des options négociées (paquets de configuration) ou d'autres informations utiles. Comme sa longueur est variable, la valeur du champ Longueur est le seul moyen de savoir où se termine le paquet et où commence le bourrage.
Les Configure Packets
Une machine désireuse d'établir une liaison doit commencer par transmettre un paquet de configuration du type Configure-Request. Le champ Données de ce type de paquet contient les changements désirés par rapport aux valeurs par défaut des options.
Quand une machine reçoit ce paquet, elle peut envoyer en réponse un paquet des types suivant :
La configuration est complète lorsque les deux machines ont envoyé un Configure-Request et reçu un acquittement de ce paquet par un Configure-Ack. Si cette phase de LCP échoue, PPP renvoi la liaison à l'état Dead.
Les Maintenance Packets
Ces paquets sont utilisés à des fin de test et de détermination de la performance du réseau. Ils sont au nombre de 5 :
Les Terminate Packets
Lors de la demande de terminaison de liaison, ou après échec de l'identification, des paquets de terminaison sont échangés par les deux machines. L'un d'eux est un Terminate-Request, l'autre un Terminate-Ack. Tant qu'aucun Terminate-Ack n'a été reçu en réponse au Terminate-Request, la liaison n'est pas coupée et on envoie d'autre Terminate-Request.
LCP requiert également l'utilisation d'un compteur, Max-Terminate, qui indique le nombre de Terminate-Request à envoyer sans recevoir acquittement par un Terminate-Ack avant d'en déduire que l'autre machine est dans l'impossibilité de répondre. Il est également possible d'utiliser un compteur, Max-Configure, pour le nombre de Configure-Request à envoyer sans recevoir de réponse avant d'abandonner. Enfin, le compteur Max-Failure peut être utiliser pour indiquer le nombre de Configure-Nack qu'il est possible d'envoyer avant de considérer que l'accord ne sera jamais atteint. Tous ces paramètres doivent être configurables.
Le champ Données des paquets de configuration a le format suivant :
+--------+--------+----------- ---+----------+--------+-------- | Type | Length | Data | Type | Length | Data... | 8 bits | 8 bits | | 8 bits | 8 bits | +--------+--------+----------- ---+----------+--------+--------
Chaque groupe de trois champs (Type, Length et Data) correspond à une option.
Le champ Type indique l'option qui est négociée. Les options les plus courantes sont :
Le principe de fonctionnement est le suivant. Lors de l'envoi du paquet Configure-Request, la machine A inclus son Magic Number dans la liste des options négociées avec la machine B. Lorsque A reçoit, un peu plus tard, un Configure-Request, A compare le Magic Number du paquet reçu à celui du paquet qu'elle avait émis.
A titre informatif, voici des exemples de probabilité de collisions entre Magic Number, en supposant qu'ils suivent une distribution uniforme :
| Nombre de collisions | Probabilité |
| 1 | 1/2^32 = 2.3 x 10^-10 |
| 2 | 1/2^64 = 5.4 x 10^-20 |
| 3 | 1/2^96 = 1.3 x 10^-29 |
Cette option permet de négocier l'utilisation d'une méthode de transparence pour certains des caractères de contrôle (codes ASCII de 0 à 31) sur les liaisons asynchrones.
Chaque extrémité de la liaison maintient deux cartes (Map) : une pour la réception et une pour l'émission, d'où un total de 4 cartes. La carte de réception est d'une longueur de 32 bits et sa valeur par défaut pour une ligne asynchrone est 0xFFFFFFFF, ce qui veut dire que les 32 premiers caractères doivent être échappés (voir ci-dessous). La carte d'émission fait également 32 bits en général, mais elle peut aller jusqu'à 256 bits ; sa valeur par défaut est 0xFFFFFFFF, plus le caractère Control Escape, le fanion et tout autre caractère que l'on souhaite échapper. Pour une ligne synchrone, l'ACCM n'étant pas nécessaire, elle a pour valeur par défaut 0.
L'ACCM est codée avec la méthode big-endian, dans laquelle chaque bit correspond au caractère ASCII de la même valeur (voir chapitre 4 pour un exemple d'ACCM). Si un bit est à 0, alors le caractère correspondant n'a pas besoin d'être échappé ; si le bit est à 1, alors le caractère doit être échappé (voir chapitre 2.3.1). Par exemple, si le bit 19 est à 0, alors le caractère de code ASCII 19 (DC3, Ctrl-S) sera envoyé en clair.
Dans un premier temps, la liaison est établie au niveau matériel (PPP n'est pas encore actif) :
Executing script c:\enst\winsock\login.cmd.
PPP[C021] state = starting (C021 = LCP, Link Control Protocol)
PPP[8021] state = starting (8021 = IPCP, Internet Protocol Control Protocol)
PPP DISABLED
Il s'agit d'une liaison par modem ; on compose le numéro :
atdt45.81.76.66
CONNECT 14400
La ligne téléphonique est ouverte, il reste à se connecter à la machine chargée des liaisons PPP :
Network Access SW V1.5 for DS700-16 (FT95B.16-34)
Serveur CAL-8, LAT, TCP/IP
local> connect stud-ppp
Soliciting...Resolving Name...Trying...
Local -009- Session 1 to STUD-PPP established
UNIX(r) System V Release 4.0 (elvire)
login: Plogin
Password: ********
Script completed
Remarque : l'authentification ayant déjà eu lieu avant l'ouverture de PPP, on aura pas besoin d'utiliser le PAP.
La liaison matérielle est maintenant correctement établie ; on lance PPP :
PPP ENABLED
LCP (code C021) entre en jeu en premier et configure la liaison. Pour cela, la machine locale envoie un paquet Configure-Request :
PPP[C021] SND CONFREQ ID=02 LEN=24 MRU(05DC) ACCM(00000000)
MAGIC(00081F0E) PFC ACFC
Ce paquet porte l'identificateur 02 : la réponse portera donc le même identificateur. Les options négociées ici sont : un MRU de 1500 (0x05DC), une ACCM de 00000000 c'est-à-dire sans caractère à échapper, et 00081F0E comme Magic Number. On a également demandé la compression du champ Protocole (PFC, Protocol Field Compression) et des champs Adresse et Contrôle (ACFC, Adress and Control Field Compression). Le paquet LCP correspondant à tout ceci donne le codage suivant (en hexadécimal) :
SND[C021] 0000:01 02 00 18 01 04 05 DC 02 06 00 00 00 00 05 06 00 08 1F 0E
SND[C021] 0014:07 02 08 02
LCP passe alors dans l'état Req-Sent.
PPP[C021] state = reqsent
Pendant ce temps, la machine distante procède de même et envoie elle aussi un Configure-Request :
RCV[C021] 0000:01 4D 00 18 01 04 05 DC 02 06 00 0A 05 00 05 06 29 AA 20 61
RCV[C021] 0014:07 02 08 02
PPP[C021] RCV CONFREQ ID=4D LEN=24 MRU(05DC) ACCM(000A0500)
MAGIC(29AA2061) PFC ACFC
L'ACCM demandée à la valeur 000A0500, ce qui se déchiffre de la façon suivante :
Hexadécimal 0 0 0 A 0 5 0 0
Binaire 0000 0000 0000 1010 0000 0101 0000 0000
| | | |
Code ascii 19 17 10 8
Les caractères de code 8, 10, 17 et 19 devront donc être échappés.
En réponse au paquet Configure-Request qu'elle vient de recevoir, la machine locale envoie un paquet Configure-Ack dont l'identificateur, 4D, est bien sur le même que celui du paquet Configure-Request.
PPP[C021] SND CONFACK ID=4D LEN=24 MRU(05DC) ACCM(000A0500)
MAGIC(29AA2061) PFC ACFC
SND[C021] 0000:02 4D 00 18 01 04 05 DC 02 06 00 0A 05 00 05 06 29 AA 20 61
SND[C021] 0014:07 02 08 02
La machine passe alors dans l'état Ack-Sent.
PPP[C021] state = acksent
Pendant ce temps, la machine distante a elle aussi envoyé un Configure-Ack en réponse au Configure-Request de la machine locale.
RCV[C021] 0000:02 02 00 18 01 04 05 DC 02 06 00 00 00 00 05 06 00 08 1F 0E
RCV[C021] 0014:07 02 08 02
PPP[C021] RCV CONFACK ID=02 LEN=24 MRU(05DC) ACCM(00000000)
MAGIC(00081F0E) PFC ACFC
Les deux machines se sont accordées sur tous les points : LCP passe donc à l'état ouvert.
PPP[C021] state = opened
C'est maintenant aux NCPs de prendre le relais. Le protocole IPCP (Internet Protocol Control Protocol, code 8021) configure la liaison pour permettre à des paquets du protocole IP (Internet Protocol) de circuler.
PPP[8021] SND CONFREQ ID=02 LEN=16 IPCP(002D0F01) IPADDR(89C2AA0B)
PPP[8021] state = reqsent
La machine locale a donné son adresse IP (89C2AA0B = 137.194.170.11) et a demandé à utiliser l'IPCP (Internet Protocol Compression Protocol) avec l'option 002D (compression Van Jacobson).
PPP[8021] RCV CONFREQ ID=4F LEN=14 IPCP(0037) IPADDR(89C2AA01)
La machine distante a elle comme adresse IP 89C2AA01 (137.194.170.1), et elle voudrait comprimer ses données avec l'option 0037 de l'IPCP. Malheureusement, la machine locale ne connaît pas cette option. Elle envoie donc un paquet Configure-Reject ou elle reprend les parties qui lui sont inconnues :
PPP[8021] SND CONFREJ ID=4F LEN=8 IPCP(0037)
Pendant ce temps, la machine distante a répondu positivement au Configure-Request de la machine locale :
PPP[8021] RCV CONFACK ID=02 LEN=16 IPCP(0002D0F01) IPADDR(89C2AA0B)
PPP[8021] state = ackrcvd
Devant l'échec de sa première proposition, la machine distante propose une autre configuration, que la machine locale accepte :
PPP[8021] RCV CONFREQ ID=50 LEN=16 IPCP(002D0F01) IPADDR(89C2AA01)
PPP[8021] SND CONFACK ID=50 LEN=16 IPCP(002D0F01) IPADDR(89C2AA01)
PPP[8021] state = opened
Les deux machines s'étant accordées, IPCP passe à l'état ouvert et le protocole IP peut maintenant envoyer des données par l'intermédiaire de la liaison PPP.
Autre composante importante de PPP, le Link Control Protocol (LCP) est un point fort qui permet une bonne portabilité de PPP. Il permet en effet, par l'intermédiaire des multiples options qu'il gère, une adaptation à l'environnement et aux exigences de la ligne. De plus, c'est lui qui se charge de l'ouverture et de la fermeture de la liaison de données, d'une éventuelle authentification, de la détection des erreurs et donc de la qualité de la liaison, ainsi que de la détection d'éventuelles bouclages.
chapitre 3.3.3
chapitre 2.2.1
chapitre 2.3.1
chapitre 1.2.2
chapitre 1.2.2
chapitre 2.1 (le champs protocole)
chapitre 2.1 (le fanion)
chapitre 2.1 (le champ détection d'erreurs)
schéma du chapitre 2.1 et
chapitre 2.3
chapitre 2.1 (Le champs Protocole) et
chapitre 4
chapitre 4
chapitre 2.1 (Le champs Protocole) et
chapitre 4
chapitre 3
chapitre 3.1.1
chapitre 3.1.2
chapitre 2.1 (le champ Bourrage)
chapitre 1.2 et exemple au chapitre 4
chapitre 1.2 et chapitre 2.1
(le champ Protocole)
chapitre 2.2.3
chapitre 1.2.2
chapitre 2.2.2
ce dossier en entier !
chapitre 3.2
chapitre 1.2.1
chapitre 2.1 (le champ Contrôle)
chapitre 1.2.2
Le principe de fonctionnement de PPP [chapitres 1 à 3]
Le Link Control Protocol (LCP), sauf l'ACCM [chapitres 4 à 6]
Le format des trames de PPP [chapitre 3]
L'adaptation à la nature de la ligne [chapitres 2, 4 et 5]
L'ACCM [chapitre 7]
Des paquets et des options négociables par LCP non traités
dans la RFC 1661.
Le contrôle de la qualité de la liaison.
Le Numbered-mode.
Liste complète des numéros assignés
aux différents protocoles et des numéros des options
négociables par LCP entre autres [pages 200 à 206]
Le protocole de contrôle IPCP.