Tutoriel — Le protocole de liaison de données point-à-point (PPP)

Rédigé par Ghislaine Labouret et Jean-Christophe Lator — Juin 1996
Document réalisé dans un cadre académique, à Télécom Paris.
Reproduction autorisée à condition de mentionner les auteurs originaux et de donner l’URL de ce document.

Introduction

Le protocole point à point (PPP) est un protocole de liaison de données assurant l'échange de données de manière fiable sur une liaison point à point (par exemple, une liaison RTC). Sa principale caractéristique est, une fois la liaison établie et configurée, de permettre à plusieurs protocoles de transférer des données simultanément. De ce fait, ce protocole est très utilisé dans l'environnement de l'internet.

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 :

  • sa manière permettre à deux ordinateurs de communiquer
  • son intérêt par rapport aux autres protocoles

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.

1. Caractéristiques principales et principe de fonctionnement

1.1. Pré-requis matériels

Le protocole point à point, comme son nom l'indique, est destiné à des liaisons point à point, comme c'est le cas pour deux machines reliées par une ligne téléphonique par exemple.

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).

1.2. Principe de fonctionnement

1.2.1. Les composantes de PPP et leurs rôles respectifs

Le protocole PPP est composé de trois éléments :
  • Un protocole de contrôle de liaison (Link Control Protocol, LCP) qui a pour rôle d'établir, de configurer, de tester et de fermer la liaison de données.
  • Une famille de protocoles de contrôle (Network Control Protocols, NCPs) pour lancer et configurer différents protocoles de la couche réseau (Network Protocols, NPs).
  • Une méthode d'encapsulation permettant de transporter sur la même ligne les données en provenance de plusieurs protocoles de la couche réseau en même temps.

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).

Principes de base de PPP

Les différentes phases qu'implique ce schéma sont détaillées ci-dessous.

1.2.2. Les grandes étapes

Lors d'une tentative de connexion, il est nécessaire de franchir un certain nombre d'étapes avant d'envoyer des données. On s'assure ainsi que la communication est bien possible entre les deux intervenants et qu'ils sont bien d'accord sur la façon d'échanger les informations. Ces étapes sont représentées dans le schéma 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).

2. Description des trames

2.1. La trame standard : description des champs

Les trames du protocoles PPP basées sur celles du protocole HDLC. Elles sont très proches des trames de ce protocole, et donc de celles de LAP-B. La structure des trames standard du protocole PPP est la suivante :

   +----------+----------+----------+-----------+-------------+
   |   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 :

  • De 0000 à 3FFF : protocoles de la couche réseau (NPs)
    0021 : Internet Protocol version 4 (IPv4)
    0029 : Appletalk
    002b : Novell IPX
  • De 4000 à 7FFF : protocoles de la couche réseau sans NCP associé
  • De 8000 à BFFF : protocoles de contrôle associés aux premiers NPs (NCPs)
    8021 : Internet Protocol Control Protocol (IPCP)
    8029 : Appletalk Control Protocol
    802b : Novell IPX Control Protocol
  • De C000 à FFFF : protocoles de contrôle de la couche liaison de données
    C021 : Link Control Protocol (LCP)
    C023 : Password Authentication Protocol (PAP)
    C025 : Link Quality Report (LQR)

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.

2.2. Les variantes possibles

2.2.1. La compression des champs Adresse et Contrôle

Pour les réseaux hauts débits, où on cherche à limiter les répétitions inutiles, les trames peuvent être compressée en supprimant les champs Adresse et Contrôle. Cela n'est bien sûr possible si ces derniers sont laissés à leur valeur par défaut dans la phase LCP. A l'arrivée, si les deux premiers octets ne sont pas 0xFF et 0x03, le récepteur en déduit que la trame a été compressée et agit en conséquence.

2.2.2. La compression du champ Protocole

A priori codé sur 2 octets, ce champ peut être réduit à 1 octet si sa compression a été négociée par le LCP. Le champ Protocole n'est jamais compressé lorsque la trame contient des données du LCP.

2.2.3. La numérotation des trames

Contrairement au protocole LAP-B, PPP ne numérote pas les trames, les paquets transportés étant par défaut en mode sans connexion. Cependant, dans certains cas où il est nécessaire d'avoir une transmission très fiable, il est possible de négocier l'utilisation d'un mode où les trames seront numérotées (Numbered-Mode) pendant la phase d'établissement de la liaison. Ce mode est par exemple utile lorsque les données sont compressées : en effet, le dictionnaire permettant de déchiffrer les données compressées étant transmis en même temps que celles-ci, la perte d'une partie des données corrompt le dictionnaire ; il est donc primordial de ne pas perdre de paquet.

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.

2.3. L'adaptation à la nature de la ligne

Le protocole PPP peut être utilisé à la fois sur des liaisons synchrones ou asynchrone, orientées bit ou orientées caractère. Chaque cas implique quelques variantes au niveau de la délimitation des trames, de la méthode utilisée pour la transparence et du remplissage inter-trames (Inter-frame time fill).

2.3.1. Les liaisons orientées caractère (asynchrones ou synchrones)

Les trames sont délimitées à l'aide du fanion 01111110, et le flot de données est examiné octet par octet à la recherche de ce fanion.

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.

2.3.2. Les liaisons orientées bit (synchrones)

Les trames sont délimitées à l'aide du fanion 01111110, et le flot de données est examiné bit par bit à la recherche de cette séquence.

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.

3. Le Link Control Protocol

3.1. Les paquets du LCP

Tout comme les autres protocoles utilisant PPP, le LCP transmet ses données en les encapsulant dans les trames de PPP. Un paquet et un seul est encapsulé dans le champ Information de chaque trame PPP dont le champ Protocole a pour valeur 0xC021 (le code du LCP).

3.1.1. Le format des paquets

Tous les paquets respectent le format suivant :

   +----------+------------+-----------+------------------------
   |   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 :

  • de 1 à 4 : paquets de configuration (Configure-Request, Configure-Ack, Configure-Nak, Configure-Reject).
  • de 5 à 6 : paquets de terminaison (Terminate-Request et Terminate-Ack).
  • de 7 à 11 : paquets de maintenance (Code-Reject, Protocol-Reject, Echo-Request, Echo-Reply, Discard-Request)

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.

3.1.2. Les différents types de paquets et leurs rôles respectifs

On distingue trois types de paquets susceptibles d'être émis par le LCP : les paquets de configuration (Configure Packets), utilisés pour établir et configurer la liaison, les paquets de terminaison (Terminate Packets), qui servent à fermer la liaison et les paquets de maintenance (Maintenance Packets) qui permettent la gestion de la liaison.

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 :

  • Configure-Ack si tout est correct dans le Configure-Request. Les champs Identificateur et Données du Configure-Ack sont alors des copies de ceux du Configure-Request auquel le paquet répond.
  • Configure-Nack si des options prennent des valeurs non acceptables pour celui qui les reçoit (qui vont à l'encontre des paramètres physiques de la liaison, ou de la configuration définie par l'administrateur). Le champ Données contient alors une copie des options rejetées.
  • Configure-Reject si des options ne sont pas connues du récepteur.

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 :

  • Code-Reject : si un paquet du LCP présentant un code inconnu est reçu, cela traduit le fait que l'autre machine utilise une version différente de LCP. Ceci est signalé à la machine en cause par l'envoi d'un paquet Code-Reject. Lorsqu'elle recevra ce paquet, la machine distante devra signaler le problème et fermer la connexion.
  • Protocol-Reject : si une trame présentant un numéro de protocole inconnu est reçue, le problème est signalé à la machine distante par l'envoi d'un paquet Protocol-Reject. Lorsqu'elle recevra ce paquet, la machine distante devra arrêter dès que possible l'envoi de paquets du protocole en cause. Les paquets de ce type ne peuvent être utilisés qu'une fois LCP à l'état ouvert.
  • Echo-Request et Echo-Reply : ces paquets fournissent un moyen de tester les deux directions de la liaison (loopback mechanism). Ils sont utilisés pour le déboggage, la détermination de la qualité de la liaison, des tests de performance,... A la réception d'un Echo-Request, un Echo-Reply est transmis en réponse.
  • Discard-Request : ce paquet fournit un moyen de tester la liaison dans le sens local vers distant (sink mechanism). Il est également utilisé pour le déboggage, la détermination de la qualité de la liaison, des tests de performance,... Un paquet de ce type est écarté silencieusement à la réception.

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.

3.2. Le temporisateur et les compteurs

LCP utilise un temporisateur, le Restart Timer, qui correspond au temporisateur T1 de LAP-B : il indique la durée maximale d'attente d'une réponse après l'envoi d'un paquet. L'expiration de ce temporisateur entraîne la retransmission du paquet laissé sans réponse.

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.

3.3. Les options négociées par LCP

3.3.1. Le principe de la négociation des options de LCP

Le paquet Configure-Request contient en paramètre les options à négocier, les options non négociées étant prises à leurs valeurs par défaut. Les options négociées ici sont entièrement indépendantes de tout protocole de la couche réseau, les options de chacun de ces protocoles étant négociées par le NCP associé. En général, les options négociées par LCP s'appliquent en semi-duplex, dans le sens de la réception pour celui qui a envoyé le Configure-Request.

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 :

  1. MRU (Maximum Receive Unit)
    Nombre représentant la taille maximale en octets du champ Information des trames.

  2. ACCM (Asynchronous Control Character Map)
    Liste des caractères de contrôle à échapper (voir chapitre 3.3.3 ci-dessous).

  3. Authentication Protocol
    L'éventuel protocole d'authentification (par exemple PAP)

  4. Quality Protocol
    L'éventuel protocole de contrôle de la qualité de la transmission (par exemple LQR)

  5. Magic Number
    Nombre permettant de détecter les boucles sur la liaison (voir chapitre 3.3.2 ci-dessous).

  6. Protocol Field Compression (PFC)
    L'éventuelle compression du champ Protocole (voir chapitre 2.2.2).

  7. Adress and Control Field Compression (ACFC)
    L'éventuelle compression des champs Adresse et Contrôle (voir chapitre 2.2.1).

3.3.2. Le Magic Number

Cette option de la configuration du LCP permet de détecter les liaisons qui constituent une boucle dans le circuit du message. Par défaut, il n'est pas utilisé, et la valeur 0 (sur 4 octets) est insérée dans les champs qui devraient contenir de Magic Number. L'utilisation d'un protocole de qualité de liaison peut requérir le choix d'un Magic Number : 0 est alors remplacé par un nombre choisi au hasard (random). Chacune des deux machines choisit un Magic Number, les deux nombres ainsi définis devant être distincts. C'est pour cette raison que les Magic Number sont choisis au hasard, de manière à diminuer la probabilité de collisions.

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.

  • Si les deux numéros sont différents, c'est que la liaison ne contient pas de boucles, et que le Configure-Request reçut est bien le Configure-Request de la machine B.

  • Si les deux numéros sont égaux, alors il y a une grande probabilité que ce soit le paquet Configure-Request que A a envoyé qui soit revenu, à cause d'une boucle dans le circuit de liaison. Dans ce cas un paquet Configure-Nack est envoyé par A avec un autre Magic Number. A attend alors que B réponde en envoyant aussi un Configure-Nack. A la réception de ce Configure-Nack par A, deux cas sont possibles :
    • Si les Magic Number des Configure-Nack sont différents, alors la liaison est sans boucle.
    • Si les Magic Number sont égaux, la probabilité d'existence d'une boucle augmente.
    Dans tous les cas, une fois arrivé à ce stade (envoi d'un Configure-Request, réception d'un Configure-Request de Magic Number similaire, envoi d'un Configure-Nack, réception d'un Configure-Nack), toute la séquence est reprise depuis le début, jusqu'à ce que le compteur Max-Failure soit atteint, entraînant la terminaison de la liaison.

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

3.3.3. L'ACCM

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.

4. Un exemple pratique

Voici un exemple d'ouverture et de configuration d'une ligne avec PPP.

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.

Conclusion

La principale caractéristique de PPP qu'il faudra retenir et à la fois son principal avantage est la possibilité qu'il offre, grâce au principe de l'encapsulation, de transporter simultanément des données de plusieurs protocoles de la couche réseau. De plus, ces données sont toutes transportées par l'intermédiaire d'une trame standard, la distinction se faisant à l'aide du champ Protocole, ce qui rend l'ensemble modulable ; il est en particulier facile de prendre en compte de nouveaux protocoles de la couche réseau au fur et à mesure de leur apparition : il suffit pour cela de définir un protocole de contrôle associé et de leur attribuer un numéro.

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.

Glossaire

ACCM (Asynchronous Control Character Map)
Liste des caractères de contrôle à échapper. Sa valeur est négociée par le LCP.
▷ chapitre 3.3.3

ACFC (Adress and Control Field Compression)
Compression des champs Adresse et Contrôle : ces champ des trames de PPP sont omis pour gagner en rapidité.
▷ chapitre 2.2.1

Control Escape
Caractère d'échappement, dont la valeur est 01111101, utilisé pour la transparence sur les liaisons orientées caractère.
▷ chapitre 2.3.1

Dead
État dans lequel la connexion est coupée (de façon matérielle ou logicielle).
▷ chapitre 1.2.2

Down
Événement de fermeture de la liaison.
▷ chapitre 1.2.2

Duplex intégral
Mode de fonctionnement d'une liaison dans lequel les deux machines peuvent envoyer et recevoir des paquets simultanément.

Encapsulation
Méthode qui permet à différents protocoles de transmettre des données sur la ligne par l'intermédiaire des trames de PPP : ces données sont contenues dans le champ Information des trame PPP, le protocole utilisé étant repéré par un numéro transmis dans le champ protocole.
▷ chapitre 2.1 (le champs protocole)

Fanion (Flag)
Séquence binaire (01111110) servant à délimiter les trames
▷ chapitre 2.1 (le fanion)

FCS (Frame Check Sequence)
Code pour le contrôle des erreurs, c'est-à-dire redondance introduite pour détecter d'éventuelles erreurs de transmission.
▷ chapitre 2.1 (le champ détection d'erreurs)

HDLC (High level Data Link Control)
Protocole normalisé très général des débuts des réseaux.

Inter-frame time fill
Remplissage inter-trames. Ensemble des caractères ou des bits circulant sur la liaison entre deux trames.
▷ schéma du chapitre 2.1 et chapitre 2.3

IP (Internet Protocol)
Protocole de la couche réseau utilisé pour la communication sur le réseau internet. Il permet notamment la gestion des adresses IP et la compression des données par l'intermédiaire de l'IPCP.
▷ chapitre 2.1 (Le champs Protocole) et chapitre 4

IPCP (Internet Protocol Compression Protocol)
Protocole de compression des données pour l'IP.
▷ chapitre 4

IPCP (Internet Protocol Control Protocol)
Protocole de contrôle pour le protocole IP.
▷ chapitre 2.1 (Le champs Protocole) et chapitre 4

LAP-B (Link Access Procedure - Balanced)
Protocole issu de HDLC, avec possibilité d'utilisation du mode équilibré pour les accès aux réseaux à commutation de paquets.

LCP (Link Control Protocol)
Protocole de contrôle de liaison. Sous protocole de PPP permettant de configurer, tester et fermer la liaison.
▷ chapitre 3

LQR (Link Quality Report)
Protocole de surveillance de la qualité de la liaison. Son utilisation est négociable par le LCP.
▷ chapitre 3.1.1

Magic Number
Nombre qui permet de s'assurer avec une grande probabilité qu'il n'y a pas de boucle (Loop-back link) dans la liaison.
▷ chapitre 3.1.2

MRU (Maximum Receive Unit)
Taille maximale des trames du protocoles. Un fanion doit être arrivé avant que MRU octets ne soient reçus.
▷ chapitre 2.1 (le champ Bourrage)

NCP (Network Control Protocol)
Protocole de contrôle pour un NP. Il permet de configurer la liaison pour permettre au NP associé de transférer des données.
▷ chapitre 1.2 et exemple au chapitre 4

NP (Network Protocol)
Protocole de la couche réseau. Ces protocoles transfèrent des données par encapsulation dans les trames de PPP.
▷ chapitre 1.2 et chapitre 2.1 (le champ Protocole)

Numbered-Mode
Mode dans lequel, contrairement au cas standard, les trames de PPP sont numérotées. Cela assure plus de sécurité pour la liaison, ainsi que le bon ordonnancement des paquets.
▷ chapitre 2.2.3

PAP (Password Authentication Protocol)
Protocole permettant de sécuriser une ligne en autorisant l'ouverture d'une liaison uniquement si l'authentification de l'interlocuteur a été un succès. Ce protocole permet ainsi d'assurer le filtrage des accès à un réseau.
▷ chapitre 1.2.2

PFC (Protocol Field Compression)
Compression du champ Protocole : ce champ des trames de PPP est compressé pour gagner en rapidité.
▷ chapitre 2.2.2

PPP (Point to Point Protocol)
Protocole point à point. PPP est un protocole de liaison de données assurant l'échange de données de manière fiable sur une liaison point à point. Sa principale caractéristique est, une fois la liaison établie et configurée, de permettre à plusieurs protocoles de transférer des données simultanément.
▷ ce dossier en entier !

Restart Timer
Temporisatuer indiquant la durée maximale d'attente d'une réponse après l'envoi d'un paquet. L'expiration de ce temporisateur entraîne la retransmission du paquet laissé sans réponse.
▷ chapitre 3.2

This layer up
Action servant à indiquer aux couches supérieures que LCP à atteint l'état ouvert (Opened).
▷ chapitre 1.2.1

UI (Un-numbered Information)
Trame standard de PPP dans laquelle on n'inclue pas de numérotation, par opposition au Numbered-Mode. La sécurité est alors moindre.
▷ chapitre 2.1 (le champ Contrôle)

Up
Événement d'ouverture de liaison.
▷ chapitre 1.2.2
Parfois utilisé comme raccourci de This layer Up.

Bibliographie

Ce dossier étant volontairement concis sur certains points, la biographie ci-dessous a surtout pour but d'indiquer au lecteur où trouver plus d'informations sur un point précis. C'est pourquoi, en plus des références normalisées des ouvrages, sont précisés les points traités par chaque document.

SIMPSON W., 1994, "The Point-to-Point Protocol (PPP)", RFC 1661.
▷ Le principe de fonctionnement de PPP [chapitres 1 à 3]
▷ Le Link Control Protocol (LCP), sauf l'ACCM [chapitres 4 à 6]

SIMPSON W., 1994, "PPP in HDLC-like Framing", RFC 1662.
▷ Le format des trames de PPP [chapitre 3]
▷ L'adaptation à la nature de la ligne [chapitres 2, 4 et 5]
▷ L'ACCM [chapitre 7]

SIMPSON W., 1994, "PPP LCP Extensions", RFC 1570.
▷ Des paquets et des options négociables par LCP non traités dans la RFC 1661.

SIMPSON W., 1992, "PPP Link Quality Monitoring", RFC 1333.
▷ Le contrôle de la qualité de la liaison.

RAND D., 1994, "PPP Reliable Transmission", RFC 1663.
▷ Le Numbered-mode.

REYNOLDS J. et POSTEL J., 1994, “Assigned numbers”, RFC 1700.
▷ 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]

McGREGOR G., 1992, "The PPP Internet Protocol Control Protocol(IPCP)", RFC 1332.
▷ Le protocole de contrôle IPCP.

PPP peut également être adapté dans certaines situations (ceci n'est pas traité dans ce dossier) :

SKLOWER K., LLOYD B., McGREGOR G., CARR D., 1994, "The PPP multilink Protocol", RFC 1717.

SIMPSON W.,1996, "PPP in Frame Relay", RFC 1973.