RFC: 1661
Statut : Standard
Retour à l'index des normes : INDEX FRANCAIS

# POINT TO POINT PROTOCOL - PPP

## SPECIFICATION

W. Simpson / Juillet 1994
Traduction : Valéry G. FREMAUX Ingénieur Professeur / EISTI
Edition originale : Mai 1996 / Version FR: Janvier 1998

Retour au sommaire - Précédent - Suivant

## 2. Encapsulation PPP

L'encapsulation PPP est utilisée pour lever l'ambiguïté sur des datagrammes provenant de protocoles différents. Cette encapsulation nécessite l'usage d'un tramage dont le but principale est d'indiquer le début et la fin de l'encapsulation. Des méthodes pour réaliser ce tramage sont décrites dans des documents associés au présent.

Une explicitation sommaire de l'encapsulation PPP est donnée ci-dessous. Les champs sont toujours transmis de gauche à droite.

`

    +-----------+-------------+----------+
    | Protocole | Information | Bourrage |
    | 8/16 bits |      *      |    *     |
    +-----------+-------------+----------+

`

#### Champ protocole

Le Protocole comprend un ou deux octets, et sa valeur identifie le datagramme encapsulé dans le champ Information du paquet. Ce champ est transmis et reçu l'octet le plus significatif en tête.

La structure de ce champ est conforme aux mécanismes définis par l'ISO 3309 pour l'extension des champs d'adresse. Tous les Protocoles DOIVENT être impairs; le bit le moins significatif de l'octet le moins significatif DOIT être égal à "1". De plus, tous les Protocoles DOIVENT être codés de sorte que le bit le moins significatif de l'octet le plus significatif soit égal à "0". Les trames reçues qui ne se conforment pas à ces règles DOIVENT être considérées comme transportant un Protocole non identifié.

Les valeurs du champ Protocole comprises dans la plage "0***" à "3***" identifient un protocole de niveau réseau de paquets spécifiques, et des valeurs entre "8***" et "b***" identifient des paquets appartenant aux Network Control Protocols (NCPs) associés, le cas échéant.

Des valeurs de champ de protocole comprises entre "4***" et "7***" sont utilisées pour des protocoles de faible trafic et ne disposant pas de NCP associé. Les valeurs entre "c***" et "f***" identifient des paquets appartenant aux Link Control Protocols (comme LCP).

Les valeurs les plus récentes établies pour ce champ Protocole sont listées dans le document "Assigned Numbers" [2]. La spécification suivante réserve les valeurs :

Valeur (en hexa) | Nom de protocole
0001 | Protocole de bourrage
0003 à 001f | réservé (non transparents)
007d | réservé (Control Escape)
00cf | réservé (PPP NLPID)
00ff | réservé (non comprimables)
8001 à 801f | non utilisé
807d | non utilisé
80cf | non utilisé
80ff | non utilisé
c021 | Link Control Protocol
c023 | Password Authentication Protocol
c025 | Link Quality Report
c223 | Challenge Handshake Authentication Protocol

Les développeurs de nouveaux protocoles DOIVENT obtenir un numéro de protocole de l'Internet Assigned Numbers Authority (IANA), à IANA@isi.edu.

#### Champ Information

Le champ Information contient zéro octets au minimum. Il contient le datagramme du protocole spécifié dans le champ Protocole.

La longueur maximum du champ Information, y compris le bourrage, mais hors champ Protocole, est limité à l'Unité de Réception Maximale (URM), par défaut 1500 octets. Par négociation, des implémentations de PPP plus "libérales" pourront utiliser d'autres valeurs d'URM.

#### Bourrage

En transmission, le champ Information PEUT être complété d'un nombre arbitraire d'octets de "bourrage" dans la limite de la règle de l'URM. C'est à chaque protocole que revient le travail de dissocier les octets de bourrage de l'information utile.

Retour au sommaire - Précédent - Suivant