PPP PDF

rfc1661
RFC : 1661
Remplace: 1548
Statut: Standard
Le Protocole Point--Point (PPP)

Edition originale : W. Simpson / Juillet 1994
Traduction : V.G. Frmaux / EISTI / Janvier 1998
Notes de traduction
Ce document est une traduction conforme et intgrale, sans omission ni rajout, du texte original de la
norme. Par mesure de cohrence avec d'autres documents pouvant faire rfrence au prsent, et non encore
traduits, les abrviations de termes explicits ou de noms symboliques n'ont pas t (ou du moins pratiquement
pas) modifies, ce qui peut paratre un petit peu confus lorsque seules ces abrviations sont utilises.
Nanmoins, ce choix permettra de se reporter cette version lorsque vous rencontrerez ces abrviations dans
d'autres RFC traitant d'aspects similaires ou associs.
Statut de ce mmo
Ce document constitue une dfinition de standard pour un protocole de communication point point pour la
communaut Internet, et admet discussion et suggestions pour son amlioration. Reportez vous l'dition en
cours de la dfinition des protocoles Internet "Internet Official Protocol Standards" (STD 1) pour connatre le
dernier tat de ce protocole. La distribution du prsent est libre.
Contexte
Le protocole Point Point (PPP) propose une mthode standard pour le transport de datagrammes multiprotocoles sur une liaison simple point point. PPP comprend trois composants principaux:
Une mthode pour encapsuler les datagrammes de plusieurs protocoles.
Un protocole de contrle du lien "Link Control Protocol" (LCP) destin tablir, configurer, et tester la
liaison de donnes.
Une famille de protocoles de contrle de rseau "Network Control Protocols" (NCPs) pour l'tablissement et
la configuration de plusieurs protocoles de la couche "rseau".
Ce document dfinit l'organisation et les mthodes utilises par PPP, ainsi que l'encapsulation effectue par
ce protocole, un mcanisme extensible de ngociation d'options capable de ngocier une large gamme de
paramtres de configuration et apportant des fonctions tendues de gestion. Le protocole PPP Link Control
Protocol (LCP) est dcrit dans le contexte de ce mcanisme.
Table des Matires

1. Introduction
Encapsulation
Protocole de contrle de liaison (Link Control Protocol)
Protocole de gestion rseau (Network Control Protocol)
Configuration
1.1. Note sur la smantique
1.2. Terminologie
2. Encapsulation PPP
Champ protocole
Champ Information
Bourrage
3. Fonctionnement d'une liaison PPP
3.1. Vue d'ensemble
3.2. Diagramme d'tats
3.3. "Link Dead" (couche physique non prte)
3.4. Etablissement
3.5. Authentification
3.6. Phase de ngociation rseau
3.7. Fermeture de liaison
4. L'automate de ngociation d'options
4.1. Table de transition d'tats
4.2. Etats
Initial
Dmarrage (Starting)
Ferm (Closed)
Arrt (Stopped)
Fermeture en cours (Closing)
Arrt en cours (Stopping)
Connexion-demande (Request-Sent)
Connexion-Acquitte (Ack-Received)
Aquittement-connexion (Ack-Sent)
Ouvert (Opened)
4.3. Evnements
Up
Down
Ouverture (Open)
Fermeture (Close)
Temporisation (TO+,TO-)
Requte-Configuration-Reue (RCR+,RCR-)
Acquitement-Configuration-Reue (RCA)
Configuration-NonAcquitte/Rejete-Reue (RCN)
Requte-Fermeture-Reue (RTR)
Acquittement-Fermeture-Reue (RTA)
Code-Inconnu-Reu (RUC)
Code-Rejet-Reu, Protocole-Rejet-Reu (RXJ+,RXJ-)
Requte-Echo-Reu, Rponse-Echo-Reu, Requte-Elimination-Reu. (RXR)
4.4. Actions
Evnement-Illgal (-)
Ouvrir (tlu)
Fermer (tld)
Dmarrer (tls)
Terminer (tlf)
Init-Compteur-Reprise (irc)
Zero-Compteur-Reprise (zrc)
Emission-Requte-Configuration (scr)
Emission-Configuration-Acquitte (sca)
Emission-Configuration-NonAcquitte (scn)
Emision-Requte-Fermeture (str)
Emission-Fermeture-Acquitte (sta)
Emission-Code-Rejet (scj)
Emission-Rponse-Echo (ser)
4.5. Elimination de rebouclages
4.6. Compteurs et Temporisations
Temporisation de Reprise
Max-Fermeture
Max-Configuration
Max-Echec
5. Formats de paquets LCP
Code
Identificateur
Longueur
Donnes
5.1. Requte-Configuration
5.2. Configuration-Acquitte
5.3. Configuration-NonAcquitte
5.4. Configuration-Rejete
5.5. Requte-Fermeture et Fermeture-Acquitte
5.6. Code-Rejet
5.7. Protocole-Rejet
5.8. Requte-Echo et Rponse-Echo
5.9. Requte-Elimination
6. Options de Configuration LCP
Philosophie
Type
Longueur
Donnes
6.1. Unit-Rception-Maximale (URM)
6.2. Protocole-Authentification
6.3. Protocole-Qualit
6.4. Nombres-Magiques
6.5. Compression-Champ-Protocole (PFC)
6.6. Compression-Adresse-et-Contrles (ACFC)
Considrations scuritaires
Rfrences
Remerciements
Contact
1. Introduction
Le protocole Point--Point est utilis pour des liaisons simples transportant des paquets de donnes entre
deux lments. Ces liens permettent une communication simultane bidirectionnelle (full-duplex), et sont
supposs transmettre des paquets dans l'ordre. PPP propose une solution commune pour un raccordement ais
d'une grande varit d'htes, de ponts et de routeurs [1].
Encapsulation
L'encapsulation PPP permet le multiplexage de diffrentes connexions protocolaires au niveau rseau
simultanes sur la mme liaison physique. Cette encapsulation a t conue dans l'exigence d'une excellente
compatibilit avec la plus grande varit de matriels.
Seuls 8 octets supplmentaires sont ncessaires pour accomplir l'encapsulation lorsque ce protocole est
utilis dans des trames de type HDLC. Dans des environnements dans lesquels la bande passante est une
proccupation majeure, cette encapsulation et la mise en trame peut tre rduite 2 ou 4 octets.
Pour permettre des implmentations haute vitesse, l'encapsulation par dfaut utilise des champs
lmentaires, un seul d'entre eux devant tre examin pour raliser le dmultiplexage. L'en-tte par dfaut et les
champs d'information tombent toujours sur des limites de mots de 32-bits, la fin de message pouvant tre
complte par des octets de "bourrage".
Protocole de contrle de liaison (Link Control Protocol)

Afin d'tre suffisamment souple pour pouvoir tre port dans de nombreux environnements, le protocole
PPP dispose d'un protocole de contrle de liaison (Link Control Protocol - LCP). Le LCP est utilis pour
effectuer la ngociation automatique des options de format d'encapsulation, la gestion de tailles variables de
paquets, la dtection d'un rebouclage de liaison ainsi que d'autres erreurs courantes de configuration, ainsi que
pour grer la rupture de liaison. Les autres fonctionnalits apportes concernent l'authentification de l'identit
de l'hte dans lequel il est implment, ainsi que la dtection de fautes de fonctionnement sur la liaison.
Protocole de gestion rseau (Network Control Protocol)

Les liaisons Point--Point tendent mettre en exergue de nombreux problmes vis vis de protocoles
rseaux communs. Par exemple, l'assignation et la gestion des adresses IP, pouvant poser des problmes y
compris dans l'environnement limit d'un LAN, est particulirement dlicate lorsque la liaison passe par un
rseau de type circuit commut (par exemple une connexion modem via rseau tlphonique). Ces problmes
sont grs par une famille de protocoles de gestion rseau (Network Control Protocols - NCPs), chacun traitant
des aspects particuliers la gestion de tel ou tel type de protocole de niveau rseau. Ces protocoles NCPs sont
dfinis dans des documents associs.
Configuration
Le but des liaisons PPP est qu'elles soient facilement configurables. Du fait de leur design, les paramtres
standard par dfaut correspondent aux configurations les plus communes. Les implmenteurs pourront passer
dans un mode amlior, dont les paramtres seront automatiquement transmis au correspondant sans aucune
intervention de l'oprateur. En fin, l'oprateur pourra configurer explicitement certaines options ncessaires au
fonctionnement de la liaison dans son environnement, laquelle configuration ne pourrait tre effectue
autrement.
L'auto-configuration de la liaison est implmente grce un mcanisme de ngociation d'options
extensible, par lequel chaque extrmit de la liaison renseigne l'autre de ses possibilits et de ses contraintes
propres. Bien que ce mcanisme de ngociation d'options ne soit dcrit dans ce document qu'en rapport avec le
Link Control Protocol (LCP), les fonctionnalits en sont suffisamment gnrales pour pouvoir tre rutilises
par d'autres protocoles de contrle, parmi lesquels la famille des protocoles NCP.
1.1. Note sur la smantique

Dans ce document, plusieurs mots diffrents sont utiliss pour exprimer la force d'une obligation ou le statut
d'une recommandation. Ces mots seront souvent crits en capitales.
DOIT, DEVRA
Ce mot, ou l'utilisation des adverbes "ncessairement" ou "obligatoirement", signifie que le comportement
exprim est une condition sine qua non remplir pour la conformit au standard.
NE DOIT PAS
Cette expression, ou l'utilisation des adjectifs "interdit" ou "prohib" indique une interdiction absolue du
comportement dcrit.
DEVRAIT
Associ la smantique de "recommand", signifie qu'il peut exister des raisons valables et lgitimes pour
que dans certaines circonstances, le comportement dcrit soit ignor, mais que ne pas implmenter ce dernier
doit tre le rsultat d'une analyse minutieuse des consquences. Une implmentation complte devra se tenir
implmenter ces comportements "conseills".
POURRAIT, POURRA
Associ la smantique "optionnel", signifie que ce comportement est un autoris parmi une srie
d'alternatives possibles. Une implmentation qui ignore cette option DEVRA nanmoins s'attendre
interoprer avec une autre implmentation qui peut, quant elle, l'utiliser.
1.2. Terminologie
Ce document utilise abondamment les termes suivants:
Datagramme
L'unit de transmission de la couche rseau (par exemple IP). Un datagramme peut tre encapsul dans un
ou plusieurs paquets passs la couche liaison.
Trame
L'unit de transmission de la couche liaison. Une trame peut comporter une en-tte et/ou une queue, et bien
sr des octets de donnes.
Paquet
L'unit d'encapsulation de base, passant entre la couche rseau et la couche liaison de donnes. Un paquet
est en gnral associ une trame; sauf pour les cas particuliers o une fragmentation du paquet doit tre
opre, o lorsque plusieurs paquets sont insres dans une trame unique.
Correspondant (peer)
L'autre extrmit d'une liaison point--point.
Paquets ignors
Se dit lorsque l'implmentation limine et dtruit le paquet sans autre traitement ultrieur.
L'implmentation DEVRAIT proposer la possibilit d'archiver l'erreur, y compris le contenu du paquet dtruit,
et DEVRAIT pouvoir tablir des statistiques sur ce genre d'vnements.
2. Encapsulation PPP
L'encapsulation PPP est utilise pour lever l'ambigut sur des datagrammes provenant de protocoles
diffrents. Cette encapsulation ncessite l'usage d'un tramage dont le but principale est d'indiquer le dbut et la
fin de l'encapsulation. Des mthodes pour raliser ce tramage sont dcrites dans des documents associs au
prsent.
Une explicitation sommaire de l'encapsulation PPP est donne 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 reu l'octet le plus significatif en tte.
La structure de ce champ est conforme aux mcanismes dfinis 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 cods de sorte que le bit le moins significatif
de l'octet le plus significatif soit gal "0". Les trames reues qui ne se conforment pas ces rgles DOIVENT
tre considres comme transportant un Protocole non identifi.
Les valeurs du champ Protocole comprises dans la plage "0***" "3***" identifient un protocole de niveau
rseau de paquets spcifiques, et des valeurs entre "8***" et "b***" identifient des paquets appartenant aux
Network Control Protocols (NCPs) associs, le cas chant.
Des valeurs de champ de protocole comprises entre "4***" et "7***" sont utilises 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 rcentes tablies pour ce champ Protocole sont listes dans le document "Assigned
Numbers" [2]. La spcification suivante rserve les valeurs :
Valeur (en hexa)
0001
0003 001f
007d
00cf
00ff
8001 801f
807d
80cf
80ff
c021
c023
c025
c223
Nom de protocole
Protocole de bourrage
rserv (non transparents)
rserv (Control Escape)
rserv (PPP NLPID)
rserv (non comprimables)
non utilis
non utilis
non utilis
non utilis
Link Control Protocol
Password Authentication Protocol
Link Quality Report
Challenge Handshake Authentication Protocol
Les dveloppeurs de nouveaux protocoles DOIVENT obtenir un numro de protocole de l'Internet Assigned
Numbers Authority (IANA), IANA@isi.edu.
Champ Information
Le champ Information contient zro octets au minimum. Il contient le datagramme du protocole spcifi
dans le champ Protocole.
La longueur maximum du champ Information, y compris le bourrage, mais hors champ Protocole, est limit
l'Unit de Rception Maximale (URM), par dfaut 1500 octets. Par ngociation, des implmentations de PPP
plus "librales" pourront utiliser d'autres valeurs d'URM.
Bourrage
En transmission, le champ Information PEUT tre complt d'un nombre arbitraire d'octets de "bourrage"
dans la limite de la rgle de l'URM. C'est chaque protocole que revient le travail de dissocier les octets de
bourrage de l'information utile.
3. Fonctionnement d'une liaison PPP

3.1. Vue d'ensemble
Afin d'tablir une communication sur un lien point--point, chaque extrmit du lien PPP DOIT d'abord
mettre des paquets LCP pour configurer et tester le support de liaison. Une fois la liaison tablie, le
correspondant POURRA tre authentifi.
Ensuite, PPP DOIT envoyer des paquets NCP pour choisir et configurer un ou plusieurs protocoles rseau
disponibles. Une fois que les protocoles rseau choisis ont t configurs, les datagrammes pour chacun de ces
protocoles rseau peuvent tre envoys sur la liaison.
La liaison restera disponible et configure pour la communication jusqu' ce que des paquets LCP ou NCP
ne ferment explicitement la liaison, moins qu'un vnement extrieur ne survienne (par exemple une
temporisation d'inactivit, ou l'intervention de l'administrateur).
3.2. Diagramme d'tats

Dans les processus de configuration, de maintien et de clture de liaison point--point, le lien PPP rencontre
un certain nombre d'tats dcrits de faon sommaire par le schma suivant :
+------+
+-------------+
+----------------+
|
| UP
|
|Ouverture|
|SUCCES/NONE
|"Dead"|------->|Etablissement|-------->|Authentification|--+
|
|
|
|
|
| |
+------+
+-------------+
+----------------+ |
^
|
|
|
|
Echec |
Echec |
|
+<--------------+
+-------------+
|
|
|
|
|
+-----------+
|
+-----------+
|
|
DOWN |
|
| Fermeture |
|
|
+---------|
Fin
|<---+<----------| Connexion |<----+
|
|
|
|
+-----------+
+-----------+
Toutes les transitions possibles ne sont pas explicites dans ce diagramme. La smantique suivante DOIT
tre adopte.
3.3. "Link Dead" (couche physique non prte)

Une communication dbute et se termine ncessairement dans cet tat. Lorsqu'un vnement extrieur
(comme une dtection de porteuse ou la configuration par l'administrateur rseau) indique que le niveau
physique est en tat pour un processus de connexion, PPP passera la liaison en phase d'tablissement.
Durant cette phase, l'automate LCP (dcrit plus loin) sera dans l'tat Initial ou Dmarrage. Le passage
l'tat Etablissement sera signale par un vnement Up l'automate LCP.
Note d'implmentation :
Typiquement, une liaison doit retomber dans cet tat aprs toute dconnexion du modem. Dans le cas d'une
liaison filaire permanente, cette tat pourra n'tre maintenu que pendant une trs courte dure cependant
suffisamment longue pour pouvoir simuler un tat repos effectif.
3.4. Etablissement
Le protocole de liaison Link Control Protocol (LCP) est utilis pour tablir la connexion grce l'change
de paquets de Configuration. Cet change est totalement rsolu, et l'automate LCP entre dans l'tat Ouvert,
lorsque des paquets d'acquittement Configuration-Acquitte (dcrits plus loin) ont t reus des deux cts.
Toutes les options de Configuration sont supposes tre leur valeur par dfaut avant d'tre modifies par
l'change de configuration. Voir le chapitre sur les options de configuration LCP pour plus de dtails.
Il est important de noter que seules les options de configuration indpendantes de tout protocole rseau sont
configures par LCP. La configuration de chacun des protocoles rseau est ralise via des protocoles Network
Control Protocols (NCPs) spcifiques durant la phase de configuration rseau. Tout paquet non-LCP reu
pendant cette phase DOIT tre ignor.
La rception d'une requte pour configuration LCP provoque un retour l'tat d'tablissement de liaison
partir de l'tat de configuration rseau ou de la phase d'authentification.
3.5. Authentification
Sur certaines liaisons il peut tre pertinent d'imposer une authentification du correspondant avant de
permettre toute ngociation protocolaire au niveau rseau.
Par dfaut, l'authentification n'est pas demande. Lorsqu'une implmentation impose que le correspondant
s'authentifie l'aide d'un protocole d'authentification particulier, alors il DOIT explicitement demander l'usage
de ce protocole d'authentification pendant la phase d'tablissement de la liaison.
L'authentification DEVRAIT tre faite le plus tt possible aprs la conclusion de la phase d'tablissement.
La dtermination de la qualit de la liaison POURRA tre ralise dans le mme temps. Toutefois, une
implmentation correcte NE DOIT PAS permettre un change de paquets de mesure de la qualit de liaison,
dans le but de retarder indfiniment le processus d'authentification.
Le passage de la phase d'authentification la phase de ngociation de protocole rseau NE DOIT PAS tre
accept avant que l'authentification n'ait abouti avec succs. Si l'authentification choue, l'authentificateur
DEVRAIT plutt entamer une phase de fermeture de liaison.
Les paquets LCP, d'authentification, et de mesure de qualit de liaison sont les seuls autoriss pendant cette
phase. Tout autre forme de paquet DOIT tre ignor.
Notes d'implmentation :
Une implmentation NE DOIT PAS faire chouer un processus d'authentification sur une simple
temporisation ou une absence de rponse. L'authentification DEVRAIT permettre un certain nombre de
tentatives, et ne conclure un chec seulement lorsque le nombre de tentatives maximum est "consomm".
C'est dans tous les cas l'implmentation qui a refus d'authentifier son correspondant qui doit entamer la
phase de fermeture de liaison.
3.6. Phase de ngociation rseau

Une fois que PPP a achev les procdures prcdentes, chaque protocole rseau (tels qu'IP, IPX, ou
AppleTalk) DOIT tre configur sparment via un protocole Network Control Protocol (NCP). Chaque NCP
DEVRAIT pouvoir tre Ouvert et Ferm tout moment.
Notes d'implmentation :
Comme il se peut que certaines implmentations demandent un temps non ngligeable pour mesurer la
qualit de liaison, les modules PPP DEVRAIENT viter l'utilisation de temporisations dure fixe entre la fin
de l'authentification et le dbut d'une ngociation NCP.
Lorsqu'un NCP atteint l'tat Ouvert, la liaison PPP est alors prte vhiculer les paquets du protocole rseau
associ. Tout paquet dans un protocole gr par NCPs arrivant alors que le NCP associ (ou associable) est en
tat ferm doit tre ignor.
Lorsque le LCP est dans son tat ouvert, tout paquet protocolaire non support par l'implmentation DOIT
tre retourn l'metteur dans un paquet Protocole-Rejet (dcrit plus loin). Seuls les protocoles grs (mais de
NCP ferms) sont ignors.
Dans cet tat, le trafic sur le lien est compos de toute combinaison de paquets LCP, NCP, et datagrammes
rseau.
3.7. Fermeture de liaison

PPP peut fermer la liaison tout moment. Ceci peut survenir suite une perte de porteuse, l'chec d'une
authentification, la dtection d'une qualit de liaison insuffisante, la chute d'une temporisation d'attente, ou la
fermeture de la liaison du fait d'une dcision humaine.
Le protocole LCP est utilis pour procder la clture de la liaison par l'change de paquets de Clture.
Lors de la fermeture, PPP en informe tout d'abord les couches rseau afin que ces dernires puissent prendre
leurs dispositions.
Aprs l'change des paquets de Clture, l'implmentation DEVRAIT signaler la couche physique de
procder la dconnexion physique, particulirement utile dans le cas de l'chec d'une authentification.
L'metteur d'une Requte pour Clture DEVRAIT se dconnecter juste aprs avoir reu un acquittement de
Clture, ou au plus tard aprs que la temporisation de Reprise soit coule. Le rcepteur d'une Requte pour
Clture DEVRAIT attendre la dconnexion du correspondant, et NE DOIT PAS se dconnecter pendant au
moins la dure d'une temporisation de Reprise compte partir de l'mission de l'acquittement de Clture. PPP
DEVRAIT passer en tat "Link Dead".
Tout paquet autre que LCP reu durant cette phase DOIT tre ignor.
La fermeture d'une liaison par LCP est suffisante. Les diffrents NCP actifs n'ont pas l'obligation d'envoyer
chacun leur salve de paquets de clture. Inversement, la rupture d'une communication rseau par un NCP n'est
pas une raison suffisante pour la coupure de la liaison PPP, mme s'il s'agit du dernier NCP actif sur la liaison.
4. L'automate de ngociation d'options

L'automate nombre d'tats fini est dfini par des vnements, des actions et des transitions entre tats. Les
vnements incluent la rception de commandes externes telles que Open et Close, la retombe de la
temporisation de Reprise, et la rception de paquets via la liaison. Les actions comprennent le dmarrage de la
temporisation de Reprise et l'mission de paquets vers le correspondant.
Certains types de paquets -- Configuration-NonAcquitte et Configuration-Rejete, ou Code-Rejet et
Protocole-Rejet, ou Requte-Echo, Rponse-Echo et Requte-Elimination ne sont pas diffrentis dans la
description de l'automate. Comme ceci sera dcrit plus tard, ces paquets correspondent cependant des usages
diffrents. Ils gnrent cependant toujours des transitions identiques.
Evnements
Actions
Up = couche infrieure prte

Down = couche infrieure non prte
Open = commande administrateur Open
Close = commande administrateur Close
TO+ = Temporisation non expire > 0
TO- = Temporisation expire
RCR+ = Requte-Configuration-Reue (Correcte)
RCR- = Requte-Configuration-Reue (Incorrecte)
RCA = Configuration-Acquitte-Reu
RCN = Configuration-NonAcquitte/Rejete-Reu
RTR = Requte-Fermeture-Reue
RTA = Fermeture-Acquitte-Reu
RUC = Code-Inconnu-Reu
RXJ+ = Code-Rejet-Reu (non critique)
ou Protocole-Rejet-Reu
RXJ- = Code-Rejet-Reu (critique)
ou Protocole-Rejet-Reu
RXR = Requte-Echo-Reu
RRR = Rponse-Echo-Reu
ou Requte-Elimination-Reu
tlu = Couche prte

tld = Couche non prte
tls = Dmarrer
tlf = Terminer
irc = Initialiser-Reprise
zrc = Rinitialiser-compteur
scr = Emission-Requte-Configuration
sca = Emission-Configuration-Acquitte
scn = Emission-Configuration-NonAcquitte/Rejete
str = Emission-Requte-Fermeture
sta = Emission-Fermeture-Acquitte
scj = Emission-Code-Rejet
ser = Emission-Echo-Rponse
4.1. Table de transition d'tats

La table complte des transitions d'tat est donne ci-aprs. Les tats sont indiqus horizontalement, et les
vnements verticalement. Les transitions entre tats et les actions sont reprsents sous la forme d'un couple
action/nouvel-tat. Des actions multiples sont spares par des virgules, et peuvent tre exprimes sur plusieurs
lignes successives; les actions multiples pourront tre implmentes dans n'importe quel ordre. L'tat peut tre
suivi d'une lettre, renvoyant une note explicative. Le tiret ('-') marque une transition illgale.
| Etat
|
0
1
2
3
4
5
Events| Initial
Starting Closed
Stopped
Closing
Stopping
------+----------------------------------------------------------Up
|
2
irc,scr/6
Down |
0
tls/1
0
1
Open |
Close|
|
TO+ |
TO- |
|
RCR+ |
RCR- |
RCA |
RCN |
|
RTR |
RTA |
|
RUC |
RXJ+ |
RXJ- |
|
RXR |
tls/1
0
1
tlf/0
irc,scr/6
2
3r
2
5r
4
5r
4
str/4
tlf/2
str/5
tlf/3
sta/2 irc,scr,sca/8
sta/2 irc,scr,scn/6
sta/2
sta/3
sta/2
sta/3
4
4
4
4
5
5
5
5
sta/2
2
sta/3
3
sta/4
tlf/2
sta/5
tlf/3
scj/2
2
tlf/2
scj/3
3
tlf/3
scj/4
4
tlf/2
scj/5
5
tlf/3
| State
|
6
7
8
9
Events| Req-Sent Ack-Rcvd Ack-Sent
Opened
------+----------------------------------------Up
|
Down |
1
1
1
tld/1
Open |
6
7
8
9r
Close|irc,str/4 irc,str/4 irc,str/4 tld,irc,str/4
|
TO+ | scr/6
scr/6
scr/8
TO- | tlf/3p
tlf/3p
tlf/3p
|
RCR+ | sca/8
sca,tlu/9
sca/8
tld,scr,sca/8
RCR- | scn/6
scn/7
scn/6
tld,scr,scn/6
RCA | irc/7
scr/6x irc,tlu/9
tld,scr/6x
RCN |irc,scr/6
scr/6x irc,scr/8
tld,scr/6x
|
RTR | sta/6
sta/6
sta/6
tld,zrc,sta/5
RTA |
6
6
8
tld,scr/6
|
RUC | scj/6
scj/7
scj/8
scj/9
RXJ+ |
6
6
8
9
RXJ- | tlf/3
tlf/3
tlf/3
tld,irc,str/5
|
RXR |
6
7
8
ser/9
Les tats dans lesquels la temporisation Reprise tourne sont identifiables par la possibilit d'vnements TO.
Seules les actions Emission-Requte-Configuration, Emission-Requte-Fermeture et Rinitialiser-Compteur
dmarrent ou redmarrent la temporisation de Reprise. La temporisation est arrte lors de toute transition d'un
tat permettant le comptage de temporisation vers un tat ne la permettant pas.
Les vnements et les actions sont implmentes selon une architecture d'change de messages, plutt que
par gestion de signaux. Si l'on dsire qu'une action contrle certains signaux (par exemple DTR), des actions
supplmentaires devront tre dfinies.
[p] Option passive; voir Arrt(Stopped).
[r] Option de redmarrage; voir l'vnement ouverture.
[x] Connexion croise; voir l'vnement RCA.
4.2. Etats
Ce qui suit est une description plus dtaille de chaque tat de l'automate.
Initial
Dans l'tat Initial, la couche physique est indisponible (Down), et aucune demande d'ouverture n'est
intervenue. La temporisation de Reprise ne tourne pas dans l'tat Initial.
Dmarrage (Starting)
L'tat de dmarrage est la rponse une demande d'ouverture par une commande administrateur Open
partir de l'tat Initial. Cet tat survient ds rception de l'ordre Open, bien que la couche physique ne soit
toujours pas disponible (Down). La temporisation de Reprise ne tourne pas dans cet tat.
Ds que la couche physique devient prte (Up), une Requte de Configuration est mise.
Ferm (Closed)
L'tat Ferm rsulte d'une action de fermeture alors que le lien physique est disponible (Up), mais que le
lien n'est pas dans un tat oprationnel. La temporisation de Reprise ne tourne pas dans cet tat.
Sur rception d'une Requte-Configuration, un paquet Fermeture-Acquitte est mis. Les paquets
Fermeture-Acquitte sont ignors pour viter un fonctionnement en boucle.
Arrt (Stopped)
L'tat arrt (Stopped) est la consquence d'une fermeture partir d'un tat ouvert du lien. Il est atteint
lorsque l'automate attend un vnement Down aprs l'action de fermeture, ou aprs avoir envoy un message
Emission-Fermeture-Acquitte. La temporisation de Reprise ne court pas dans cet tat.
Lorsqu'un paquet Requte-Configuration est reu, une rponse approprie est envoye. La rception de tout
autre paquet entrane l'mission d'un paquet Fermeture-Acquitte. Ces mmes paquets Fermeture-Acquitte
seront ignors en rception pour viter de boucler le protocole.
Justification :
L'tat arrt (Stopped) est un tat intermdiaire lors de la coupure d'une liaison, l'chec d'une configuration,
et d'autres modes d'chec de l'automate. Ces tats priori distincts ont t combins dans cette tape.
Il existe une concurrence temporelle entre la rponse par l'vnement Down (attendu aprs l'action
Terminer de la couche PPP) et l'apparition possible d'un vnement Requte-Configuration-Reue. Lorsqu'une
Requte-Configuration arrive avant la chute de ligne (Down), ce dernier vnement prvaudra et la ligne
reviendra l'tat initial ds sa rception. Ceci protge le protocole contre les attaques par rptition.
Option d'implmentation :
Lorsque le distant ne parvient pas rpondre une Requte-Configuration locale, l'implmentation
POURRA attendre la rception d'une Requte-Configuration distante. Dans ce cas, l'action Terminer ne sera
pas effectue lorsque l'vnement TO- survient dans les tats Connexion-demande, Connexion-Acquitte et
Acquitement-connexion.
Cette option est utile dans le cas de lignes permanentes ddies, ou circuits ne disposant pas de signalisation
d'tat physique de ligne, mais doit tre proscrite pour des lignes cbles sur un rseau commut.
Fermeture en cours (Closing)

En Fermeture, une tentative est faite pour fermer la connexion. Une Requte-Fermeture a t mise et la
temporisation de Reprise tourne, l'acquittement de fermeture n'a pas encore t reu.
En rponse un vnement Fermeture-Acquitte-reu, l'automate passe en tat Ferm.
Lorsque la temporisation de Reprise expire, une nouvelle Requte-Fermeture est mise, et la temporisation
relance. Lorsque la temporisation a expir un nombre de fois fix, l'automate passe alors en tat Ferm.
Arrt en cours (Stopping)

L'tat Arrt en Cours est l'tat Arrt ce que la Fermeture en Cours est l'tat Ferm. Une RequteFermeture a t mise et la temporisation de Reprise tourne, un Fermeture-Acquitte n'a pas encore t reu.
Justification :
L'tat Arrt en Cours dfinit parfaitement comment terminer une communication avant de permettre le
passage de nouvelles donnes. Une fois la liaison coupe, une nouvelle configuration peut tre demande par
l'tat Arrt ou Dmarrage.
Connexion-demande (Request-Sent)
Dans l'tat Connexion-demande, une configuration peut prendre place pour initialiser la liaison. Un paquet
Requte-Configuration a t mis et la temporisation de Reprise est mise en route. Dans cet tat, un paquet
Configuration-Acquitte n'a ni t reu, et encore moins mis.
Connexion-Acquitte (Ack-Received)
Dans l'tat de Connexion-Acquitte (Ack-Received), un paquet Requte-Configuration a t mis et un
Configuration-Acquitte distant reu. La temporisation de Reprise tourne toujours, dans la mesure o le paquet
local Configuration-Acquitte n'a pas t encore envoy.
Aquittement-connexion (Ack-Sent)
Dans l'tat d'Acquittement-Connexion, un paquet de Requte-Configuration et un Configuration-Acquitte
ont tous deux t mis, mais le distant n'a toujours pas acquitt son tour la configuration ngocie. La
temporisation de Reprise tourne, tant que cette rponse n'est pas parvenue au local.
Ouvert (Opened)
Dans l'tat Ouvert, les acquittements de configuration ont t changs. La temporisation de Reprise
s'arrte.
Lorsque cet tat est atteint par l'automate, l'implmentation DEVRAIT mettre vers la couche suprieure un
vnement Up. A l'inverse, lorsque cet tat est quitt, l'implmentation DEVRAIT mettre un signal Down vers
la couche suprieure.
4.3. Evnements
Les transitions et les actions de l'automate sont causs par des vnements.
Up
Cet vnement survient lorsque la couche basse de protocole est prte transporter des paquets de donnes.
Typiquement, cet vnement est gnr par un pilote de modem, ou par toute autre interface entre PPP et un
gestionnaire de mdia physique, pour signaler au LCP que la liaison entre dans la phase d'Etablissement.
Il sera l'occasion pour le LCP de signaler chaque NCP que la liaison admet dsormais un fonctionnement
au niveau rseau., l'action Couche-Prte du LCP dclenchera les actions Up de chaque NCP.
(NdT: cette couche devenant alors la couche infrieure des NCP).
Down
Cet vnement survient lorsque la couche basse de protocole n'est plus en mesure de transporter des paquets
de donnes.
Typiquement, cet vnement est gnr par un pilote de modem, ou par toute autre interface entre PPP et un
gestionnaire de mdia physique, pour signaler au LCP que la liaison entre dans un tat non oprationnel.
Il sera l'occasion pour le LCP de signaler chaque NCP que la liaison quitte le fonctionnement au niveau
rseau., l'action Couche-non-Prte du LCP dclenchera les actions Down de chaque NCP.
Ouverture (Open)
Cet vnement indique que la mise en uvre de la liaison est demande par l'administrateur humain ou une
couche suprieure. Lorsqu'il apparat, et que la liaison n'est pas dj dans l'tat Ouverte, l'automate essayera
d'mettre des paquets de configuration au distant.
Si l'automate est dans l'impossibilit de commencer cette configuration (la ligne est physiquement
indisponible, ou une commande Close prcdente n'est pas encore totalement traite), l'tablissement de la
nouvelle communication est automatiquement diffr.
Lorsqu'une Requte-Fermeture est reue, ou tout autre vnement qui rend le lien non disponible,
l'automate progressera vers un tat dans lequel une rouverture de la ligne est possible. Aucune autre
intervention de l'administrateur n'est ncessaire.
Option d'implmentation :
L'exprience a dmontr que les utilisateurs relancent en gnral une nouvelle commande Open lorsqu'ils
dsirent rengocier la liaison. Cette action indique en gnral que les paramtres de la liaison sont modifier.
Comme il ne s'agit pas de la smantique exacte de l'vnement d'Ouverture, il est suggr que
l'implmentation lance un vnement Down immdiatement suivi d'un vnement Up, lorsqu'une commande
Open est excute alors que l'automate est dans l'un des tats Ouvert, Fermeture en Cours, Arrt en Cours, ou
Arrt. On prendra garde dans ce cas que l'avnement de l'vnement Down ne puisse tre provoqu par une
autre cause.
La succession d'un Down puis d'un Up va provoquer une rengociation de la liaison, en suivant la
progression passant par les tats Dmarrage et Connexion-demande. La connexion est ainsi rengocie sans
effets de bords notable.
Fermeture (Close)
Cet vnement indique que la liaison ne doit plus vhiculer de donnes; en d'autre termes, l'administrateur
de rseau (humain ou logiciel) a avis que la liaison ne doit plus rest en tat Ouvert. Lorsque cet vnement
survient, et la liaison n'est pas dj Ferme, l'automate va tenter d'interrompre la connexion. Des tentatives
ultrieures de reconfiguration de la liaison seront refuses tant qu'un nouvel vnement Open n'intervient pas.
Lorsque une authentification choue, la liaison DEVRAIT tre coupe, pour viter une attaque par
rptition et le refus de service aux autres utilisateurs. Comme la liaison est encore administrativement
disponible (par dfinition), ceci pourrait tre accompli en simulant une commande Close donne au LCP,
immdiatement suivie d'une commande Open. On prendra garde dans ce cas que l'avnement de l'vnement
Close ne puisse tre provoqu par une autre cause.
L'vnement Close suivi d'un Open provoque une coupure normale de la ligne, progressant depuis l'tat
Fermeture en Cours vers l'tat Arrt en Cours, l'action Terminer entrane la dconnexion physique de la ligne.
L'automate attend alors la prochaine demande de connexion dans l'tat Arrt ou Dmarrage.
Temporisation (TO+,TO-)
Cet vnement indique l'expiration de la temporisation de Reprise. Cette temporisation sert quantifier
l'attente maximum d'une rponse une Requte-Configuration et une Requte-Fermeture.
L'vnement TO+ indique que le compteur de Reprise est toujours positif, ce qui provoque la rmission
d'un paquet Requte-Configuration ou Requte-Fermeture suivant le cas.
L'vnement TO- indique que le compteur de Reprise est pass zro, et aucun paquet de Requte ne doit
tre rmis dans ce cas.
Requte-Configuration-Reue (RCR+,RCR-)
Cet vnement survient lorsqu'un paquet Requte-Configuration distant est reu. Cette RequteConfiguration indique que le distant souhaite ouvrir une communication et peut y spcifier des options de
configuration. Le paquet Requte-Configuration est prsent en dtail plus loin.
L'vnement RCR+ indique que la Requte-Configuration est lgitime, et dclenche la transmission d'un
paquet Configuration-Acquitte.
L'vnement RCR- indique que la Requte-Configuration n'est pas lgitime, ou acceptable, et dclenche la
transmission d'un paquet Configuration-Rejete ou Configuration-NonAcquitte.
Ces vnements peuvent survenir sur une connexion ouverte. L'implmentation DEVRA tre prpar
rengocier immdiatement les options de configuration.
Acquitement-Configuration-Reue (RCA)
Cet vnement survient lorsqu'un paquet Configuration-Acquitte distant est reu. Ce paquet est une rponse
positive une Requte-Configuration. Un paquet hors contexte ou invalide pour une autre raison est ignor.
Dans la mesure ou des paquets conformes ont dj t reus avant que les tats Acquitement-ConfigurationReu ou Ouvert, il reste trs peu de chances qu'un paquet non conforme arrive dans cette phase. Comme il est
spcifi, tout paquet d'acquittement/non-acquittement/Rejet invalide est ignor, et n'affecte pas les transitions
de l'automate.
Cependant, il n'est pas impossible qu'un paquet pourtant correct arrive accidentellement pendant un tat
transitoire. Souvent, cela rsultera d'une imperfection de l'implmentation. Au pire, ce cas POURRAIT tre
enregistr dans le rapport d'erreurs.
Configuration-NonAcquitte/Rejete-Reue (RCN)
Cet vnement survient lorsqu'un paquet distant Configuration-NonAcquitte ou Configuration-Rejete est
reu. Les paquets Configuration-NonAcquitte et Configuration-Rejete constituent les rponses ngatives
une Requte-Configuration. Un paquet hors contexte ou invalide pour une autre raison est ignor.
Bien que les vnements Configuration-NonAcquitte et Configuration-Rejete cause les mmes transitions
d'tat dans l'automate, ces paquets ont des effets diffrents quant aux options de configurations envoyes par la
Requte-Configuration rsultante.
Requte-Fermeture-Reue (RTR)
Cet vnement survient lorsqu'une Requte-Fermeture est arrive du distant. La Requte-Fermeture indique
que le distant souhaite suspendre la communication.
Cet vnement n'a pas la mme signification que la commande Close (voir ci-avant), qui impose l'mission
d'une commande d'ouverture par l'administrateur local pour rpondre des sollicitations d'ouverture.
L'implmentation DOIT se prparer recevoir une nouvelle Requte-Configuration sans aucune autre
intervention de l'administrateur local.
Acquittement-Fermeture-Reue (RTA)
Cet vnement signifie qu'un paquet Fermeture-Acquitte a t reu du distant. Ce paquet est dans la
plupart des cas une rponse une Requte-Fermeture antrieure. Ce paquet peut aussi indiquer que le distant
est dans l'tat Ferm ou Arrt, et sert dans ce cas la resynchronisation de la configuration de la liaison.
Code-Inconnu-Reu (RUC)
Cet vnement est lanc lorsqu'un paquet reu du distant ne peut tre interprt. Un paquet Code-Rejet est
renvoy en rponse.
Code-Rejet-Reu, Protocole-Rejet-Reu (RXJ+,RXJ-)

Cet vnement signifie qu'un paquet Code-Rejet ou Protocole-Rejet a t reu du distant.
L'vnement RXJ+ intervient lorsque la valeur est acceptable selon le point de vue du LCP, comme pour le
rejet d'un code d'extension valide, ou le rejet d'un protocole NCP. Ces vnements sont dans le contexte d'in
fonctionnement normal. L'implmentation DOIT arrter d'mettre un tel type de paquet.
L'vnement RXJ- intervient lorsque la valeur rejete a une signification critique, comme le rejet d'un code
de configuration, ou le rejet du protocole LCP! Cet vnement indique la prsence d'une erreur fatale qui
provoque la fin force de la communication.
Requte-Echo-Reu, Rponse-Echo-Reu, Requte-Elimination-Reu. (RXR)

Cet vnement survient lorsqu'un paquet Requte-Echo, Rponse-Echo ou Requte-Elimination est reu du
distant. Le paquet Rponse-Echo est une rponse un paquet Requte-Echo. Il n'y a pas de rponse fournir
un paquet Rponse-Echo ou Requte-Elimination.
4.4. Actions
Les actions dans l'automate sont dclenches par les vnements et signifie typiquement la transmission de
paquets et/ou le dpart ou l'arrt de la temporisation de Reprise.
Evnement-Illgal (-)
Cette action indique un vnement non conforme une implmentation correcte. L'implmentation affiche
une erreur interne, laquelle devrait tre signale et archive. Aucune transition n'est initie, et l'implmentation
NE DOIT ni se bloquer, ni tre rinitialise.
Ouvrir (tlu)
Cette action indique aux couches suprieures que l'automate entre dans l'tat Ouvert. Typiquement, cette
action est mene par le LCP pour lancer un vnement Up vers un NCP, un protocole d'Authentification, ou le
protocole de mesure de Qualit de Liaison, ou POURRAIT tre mene par un NCP pour indiquer que la liaison
et prte faire transiter des donnes rseau.
Fermer (tld)
Cette action indique aux couches suprieures que l'automate quitte l'tat Ouvert. Typiquement, cette action
est mene par le LCP pour signaler la fermeture de ligne un NCP, un protocole d'Authentification, ou le
protocole de mesure de Qualit de Liaison, ou POURRAIT tre mene par un NCP pour indiquer que la liaison
n'est plus en mesure de faire transiter des donnes rseau.
Dmarrer (tls)
Cette action indique aux couches infrieures que l'automate entre dans l'tat Dmarrage, et requiert la mise
en route de celles-ci pour l'tablissement de la liaison. La couche infrieure DEVRAIT rpondre par un
vnement Up lorsque celle-ci s'est tablie.
Les rsultats de cette action dpendent fortement de l'implmentation.
Terminer (tlf)
Cette action indique aux couches infrieures que l'automate entre dans l'tat Initial, Ferm ou Arrt, et que
le niveau de protocole infrieur n'est plus ncessaire. La couche infrieure DEVRAIT rpondre par un
vnement Down lorsque les oprations de clture de la couche infrieure sont acheves.
Typiquement, cette action DEVRAIT tre mene par le LCP pour avancer vers la phase Link Dead, ou par
un NCP pour indiquer au LCP que la liaison peut tre coupe ds qu'il ne restera plus de NCP ouvert.
Les rsultats de cette action dpendent fortement de l'implmentation.
Init-Compteur-Reprise (irc)
Cette action initialise le compteur de Reprise la valeur approprie (Max-Fermeture ou MaxConfiguration). Le compteur est dcrment chaque transmission, y compris la premire.
En plus d'initialiser le compteur de Reprise, l'implmentation DOIT rinitialiser la temporisation d'attente
sa valeur initiale.
Zero-Compteur-Reprise (zrc)
Met le compteur de Reprise zro.
Cette action permet au FSA de faire une pause avant de passer l'tat final vis, permettant ainsi au trafic
restant d'tre trait par le distant. En plus de mettre le compteur de Reprise zro, l'implmentation DOIT
initialiser la temporisation de Reprise une valeur approprie.
Emission-Requte-Configuration (scr)
Un paquet Requte-Configuration est mis. Il indique le dsir d'tablir une communication selon un
ensemble d'Options de Configuration spcifi. La temporisation de Reprise est dmarre lorsque ce paquet est
mis, afin de se prmunir contre une perte de celui-ci. Le compteur de Reprise est dcrment chaque fois
qu'une Requte-Configuration est envoye.
Emission-Configuration-Acquitte (sca)
Un paquet Configuration-Acquitte est mis. Il acquitte la rception d'une Requte-Configuration et de son
ensemble d'Options de Configuration, juges alors acceptables.
Emission-Configuration-NonAcquitte (scn)
Un paquet Configuration-NonAcquitte ou Configuration-Rejete est mis, selon le cas. Cette rponse
ngative rend compte de la rception d'une Requte-Configuration correcte mais dans laquelle certaines
Options de Configuration sont incorrectes.
Les paquets Configuration-NonAcquitte sont utiliss pour refuser une valeur d'Option de Configuration, et
pour en suggrer une autre, acceptable par l'appel. Les paquets Configuration-Rejete sont utiliss pour
refuser toute ngociation sur les Options de Configuration, en principe parce que l'option demande est
inconnue ou non implmente. Les conditions d'utilisation des paquets Configuration-NonAcquitte plutt que
Configuration-Rejete sont dcrits plus avant dans le chapitre dtaillant les formats de paquets LCP.
Emision-Requte-Fermeture (str)
Un paquet Requte-Fermeture est mis. Il indique le dsir de clore une connexion. La temporisation de
Reprise est dmarre lorsque la Requte-Fermeture est envoye, pour se prmunir des pertes d'un tel paquet. Le
compteur de Reprise est dcrment chaque mission de Requte-Fermeture.
Emission-Fermeture-Acquitte (sta)
Un paquet Fermeture-Acquitte est mis. Il rend compte de la rception d'un paquet Requte-Fermeture ou
peut aussi servir la synchronisation des automates.
Emission-Code-Rejet (scj)
Un paquet Code-Rejet est transmis. Il indique la rception d'un paquet non interprtable.
Emission-Rponse-Echo (ser)
Un paquet Rponse-Echo est transmis. Il accuse rception d'un paquet Requte-Echo.
4.5. Elimination de rebouclages

Le protocole est conu de sorte ne laisser que peu de chances l'tablissement d'une boucle protocolaire
lors de la ngociation d'Options de Configuration. Cependant, le protocole NE garantit PAS qu'une boucle ne
puisse rsulter d'une squence particulire. Comme pour toute ngociation, il n'est pas impossible de tomber sur
le cas de deux implmentations de PPP aux stratgies contradictoires et pour lesquelles la ngociation ne
converge jamais. Il sera alors possible de changer de stratgie de ngociation pour obtenir la convergence, mais
cette pratique consommera ncessairement un certain temps. Les dveloppeurs doivent garder l'esprit ce
problme et DEVRAIENT ajouter des mcanismes de dtection de boucle ou un autre tage de temporisation.
4.6. Compteurs et Temporisations

Temporisation de Reprise
L'automate utilise une temporisation spciale. La temporisation de Reprise est utilise pour donner un cadre
temporel aux changes de paquets Requte-Configuration et Requte-Fermeture. L'expiration de la
temporisation de Reprise constitue un vnement TO, et provoque la retransmission de la Requte
correspondante. La dure de la temporisation DOIT tre configurable, mais POURRA avoir une valeur par
dfaut de trois (3) secondes.
La temporisation de Reprise DEVRAIT tre adaptative selon la vitesse de transmission de la liaison. La
valeur par dfaut est donne pour des liaisons lentes (2400 9600 bauds), et dans le cas de lignes commutes
basculement lent (lignes tlphoniques). Des lignes plus rapides, ou commutation rapide, POURRAIENT
bnficier de dlais d'attente infrieurs.
Plutt qu'utiliser une valeur constante, la temporisation de Reprise POURRAIT tre d'abord fixe une
valeur faible puis tre augmente progressivement jusqu' sa valeur finale thorique selon une progression
gomtrique de facteur 2 (doublement pour chaque nouvelle valeur). La valeur initiale DEVRAIT tre
suffisamment grande en rapport la taille des paquets, au moins deux fois le temps d'aller-retour d'un paquet
la vitesse de transmission nominale de la ligne, avec au moins une marge supplmentaire de 100 millisecondes
pour donner au distant le temps de traiter le paquet avant de rpondre. Certains circuits ajouteront une marge
supplmentaire de 200 millisecondes pour un transfert "satellite". Les temps d'aller-retour pour des modems
oprant 14400 bauds sont mesurs entre environ 160 plus de 600 millisecondes.
Max-Fermeture
Un compteur de Reprise au moins doit traiter les paquets Requte-Fermeture. Max-Fermeture indique le
nombre de paquets Requte-Fermeture mis et n'ayant pas reu de paquet Fermeture-Acquitte avant qu'il ait
pu tre tabli que le distant n'est plus en tat de rpondre. Max-Fermeture DOIT tre configurable, mais
DEVRAIT proposer une valeur par dfaut de deux (2) missions.
Max-Configuration
Il est recommand d'effectuer un compte similaire des paquets Requte-Configuration. Max-Configuration
indique le nombre de paquets Requte-Configuration mis sans avoir reu de paquet Configuration-Acquitte,
Configuration-NonAcquitte ou Configuration-Rejete valides avant qu'il ait pu tre tabli que le distant n'est
plus en tat de rpondre. Max-Configuration DOIT tre configurable, mais DEVRAIT proposer une valeur par
dfaut de dix (10) missions.
Max-Echec
Un comptage des missions de Configuration-NonAcquitte est ncessaire. Max-Echec donne le nombre de
paquets Configuration-NonAcquitte mis sans avoir mis de Configuration-Acquitte et avant de pouvoir
dterminer que les configurations ne convergent pas vers un accord probable. Tout nouveau paquet
Configuration-NonAcquitte destin au distant doit tre converti en paquets Configuration-Rejete, et les
options souhaites par le local ne sont plus transmises. Max-Echec DOIT tre configurable, mais DEVRAIT
proposer une valeur par dfaut de cinq (5) missions.
5. Formats de paquets LCP

Il existe trois classes de paquets LCP :
1. Les paquets de Configuration de Liaison utiliss pour tablir et configurer une communication (RequteConfiguration, Configuration-Acquitte, Configuration-NonAcquitte et Configuration-Rejete).
2. Les paquets de Fermeture de Liaison utiliss pour couper une communication (Requte-Fermeture et
Fermeture-Acquitte).
3. Les paquets de Maintenance de Liaison utiliss pour grer et dverminer une liaison (Code-Rejet,
Protocole-Rejet, Requte-Echo, Rponse-Echo, et Requte-Elimination).
Par souci de simplicit, il n'existe pas de champ de version dans les paquets LCP. Une implmentation LCP
fonctionnelle correcte rpondra toujours des Protocoles et des Codes inconnus par un paquet LCP
parfaitement univoque, ce qui procure un mcanisme automatique de reconnaissance de version non
compatibles.
Quelles que soient les options de Configuration actives, tous les paquets LCP de Configuration, Fermeture
et Rejet de Code (codes 1 7) seront systmatiquement envoys comme si aucune option de Configuration
n'avait t ngocie. En particulier, chaque option de Configuration est attribue une valeur par dfaut. Ceci
assure que tel paquet LCP restera toujours reconnaissable, mme lorsqu'une extrmit de la ligne considre par
erreur que la ligne est ouverte.
Un et un seul paquet LCP est encapsul dans le champ d'information PPP, lorsque le champ Protocole du
paquet PPP indique une valeur hexadcimale c021 (Link Control Protocol).
Un rsum des formats de paquets LCP est donn ci-aprs. Les champs sont transmis de la gauche vers la
droite.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Code
| Identificateur|
Longueur
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Donnes ...
+-+-+-+-+
Code
Le champ Code comporte un octet, et identifie le type de paquet LCP. Lorsqu'un paquet reu affiche un code
inconnu, un paquet Code-Rejet est transmis en retour.
Les valeurs de codes LCP reconnus les plus rcents sont mentionns dans la RFC "Assigned Numbers" [2].
Cette spcification donne les codes de base suivants :
1
2
3
4
5
6
7
8
9
10
11
Requte-Configuration
Configuration-Acquitte
Configuration-NonAcquitte
Configuration-Rejete
Requte-Fermeture
Fermeture-Acquitte
Code-Rejet
Protocole-Rejet
Requte-Echo
Rponse-Echo
Requte-Elimination
Identificateur
Le champ Identificateur comporte un octet, et fournit un moyen d'associer requtes et rponses. Lorsqu'un
paquet prsente un Identificateur invalide, il est ignor sans affecter l'automate.
Longueur
Le champ Longueur comporte deux octets, et donne la longueur du paquet LCP, y compris l'octet de Code,
d'Identificateur, le champ Longueur lui-mme et le champ Donnes. La longueur NE DOIT PAS excder
l'URM de la liaison.
Les octets reus en dehors de la plage dfinie par le champ Longueur sont traits comme des octets de
bourrage et sont ignors. Lorsqu'un paquet affiche une Longueur invalide, il est ignor sans affecter le
fonctionnement de l'automate.
Donnes
Le champ Donnes comporte zro ou un nombre quelconque d'octets, selon l'indication du champ
Longueur. Le format interne du champ Donnes dpend de la valeur prsente dans le champ Code.
5.1. Requte-Configuration
Description
Une implmentation dsireuse d'initialiser une communication DOIT transmettre une RequteConfiguration. Le champ d'Options est renseign avec tous les changements faire par rapport la
configuration par dfaut. Les Options de Configuration NE DOIVENT PAS y apparatre lorsqu'elles ont leur
valeur par dfaut.
Sur rception d'une Requte-Configuration, une rponse approprie DOIT tre mise.
Le format de ce paquet est exprim ci-dessous. Les champs sont transmis de gauche droite.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Code
|Identificateur |
Longueur
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options ...
+-+-+-+-+
Code
1 pour signifier Requte-Configuration.
Identificateur
Le champ Identificateur DOIT changer lorsque le contenu des Options change, et dans la mesure o une
rponse valide a t reu pour la requte prcdente. Pour toute retransmission, l'Identificateur PEUT demeurer
inchang.
Options
Le champ d'Options est de longueur variable, et contient une liste de zro ou plus Options de Configuration
que l'metteur dsire rengocier. Toutes les Options de Configuration sont ngociables simultanment. Le
format des Options de Configuration est dcrit dans un des chapitres suivants.
5.2. Configuration-Acquitte
Description
Si toutes les Options de Configuration reues dans une Requte-Configuration est reconnaissable et toutes
les valeurs valides, alors l'implmentation DOIT transmettre un paquet Configuration-Acquitte. La
confirmation des Options de Configuration NE DOIT PAS en changer l'ordre ni les valeurs.
Sur rception d'un paquet Configuration-Acquitte, le champ Identificateur DOIT correspondre en valeur
celui de la dernire Requte-Configuration reue. De plus, la liste d'Options de Configuration d'un paquet
Configuration-Acquitte DOIT correspondre en tous points celle de la Requte-Configuration prcdente. Des
paquets invalides sont ignors.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Code
|Identificateur |
Longueur
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options ...
+-+-+-+-+
Code
2 pour signifier Configuration-Acquitte.
Identificateur
Le champ Identificateur contient une copie de l'identificateur de la Requte-Configuration motivant l'envoi
de ce paquet.
Options
Le champ d'Options varie en longueur, et contient une liste de zro ou plus Options de Configuration
acquitter. Toutes les Options de Configuration sont toujours Acquittes collectivement.
5.3. Configuration-NonAcquitte
Description
Si toutes les instances d'Options de Configuration reues peuvent tre reconnues, mais avec pour certaines
des valeurs non valides, alors l'implmentation DOIT transmettre un paquet Configuration-NonAcquitte. Le
champ d'Options est renseign avec les Options de Configuration non acceptables de la requte correspondante.
Toutes les Options valides doivent tre filtres dans le paquet Configuration-NonAcquitte, celles qui restent
dans la rponse ne DEVANT PAS tre changes d'ordre.
Le rejet d'Options sans champ de valeur (options boolennes) DOIT s'effectuer l'aide de paquets
Configuration-Rejete.
A toute Option de Configuration dont une seule instance peut tre prsente DOIT tre attribue une valeur
acceptable pour l'metteur de l'accus de rception. La valeur par dfaut PEUT tre utilise, lorsque celle-ci est
diffrente de la valeur requise par l'initiateur.
Pour toute Option de Configuration pouvant apparatre plusieurs fois avec des valeurs diffrentes, le paquet
Configuration-NonAcquitte DOIT fournir une liste de toutes les valeurs acceptable par l'metteur de
l'acquittement. Cette liste inclura les valeurs acceptes prsentes dans la requte.
Finalement, une implmentation peut tre configure pour requrir la ngociation d'une Option de
Configuration spcifique. Si cette option n'apparat pas dans la requte, elle PEUT tre ajoute la liste
d'Options de Configuration dans l'accus de rception, de sorte inciter l'initiateur spcifier cette option lors
de l'mission de la Requte corrective suivante. Cette option DEVRA figurer avec toutes les valeurs acceptes
par l'metteur de l'accus de rception.
Sur rception d'un paquet Configuration-NonAcquitte, le champ Identificateur DOIT contenir la mme
valeur que celle prsente dans la dernire Requte-Configuration. Des paquets non valides seront ignors.
Un paquet Configuration-NonAcquitte valide indique son rcepteur qu'une nouvelle RequteConfiguration est demande, en indiquant les valeurs attendues et permises. Lorsqu'une Option de
Configuration apparat en plusieurs exemplaires dans l'accus de rception, listant ainsi les valeurs permises,
l'initiateur DEVRA en choisir une pour la constitution de la requte corrective suivante.
Certaines Options de Configuration sont de longueur variable. Comme l'option retourne par l'accus a t
modifie entre temps par le distant, l'implmentation DOIT pouvoir traiter un retour d'Option de longueur
diffrente celle mise initialement dans la Requte-Configuration. Le format de ce paquet est exprim cidessous. Les champs sont transmis de gauche droite.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Code
|Identificateur |
Longueur
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options ...
+-+-+-+-+
Code
3 pour signifier Configuration-NonAcquitte.
Identificateur
L'identificateur doit tre la copie de celui prsent dans le Requte-Configuration l'origine de cet accus de
rception.
Options
dont l'metteur accuse rception. Toutes les Options de Configuration sont traites en une fois.
5.4. Configuration-Rejete
Description
Lorsque certaines Options de Configuration reues dans une requte ne sont pas reconnaissables ou ne sont
pas ngociables (parce que par exemple configures en fixe par un administrateur rseau), alors
l'implmentation DOIT rpondre par un paquet Configuration-Rejete. Le champ d'Options est renseign avec
les seules Options de Configuration non conformes prsentes dans la requte. Toutes les Options reconnues et
ngociables sont expurges de la requte originale, celles qui restent ne devant en AUCUN CAS tre
rordonnes ni modifies.
L'identificateur du paquet Configuration-Rejete, DOIT ncessairement correspondre celui de la requte
initiale. De plus, l'ensemble des Options de Configuration figurant dans un rejet DOIT tre exclusivement un
sous ensemble de ceux transmis dans la requte originatrice. Les paquets non valides sont ignors.
Un paquet Configuration-Rejete indique son rcepteur que dans toute requte ultrieure corrective NE
DEVRA figurer AUCUNE des Options stipules dans le rejet.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Code
|Identificateur |
Longueur
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options ...
+-+-+-+-+
Code
4 pour signifier Configuration-Rejete.
Identificateur
L'identificateur doit tre la copie de celui prsent dans le Requte-Configuration l'origine de cet accus de
rejet.
Options
que l'metteur rejette. Toutes les Options de Configuration sont rejetes en une fois.
5.5. Requte-Fermeture et Fermeture-Acquitte

Description
Le LCP inclue des codes particuliers de Requte-Fermeture et Fermeture-Acquitte afin d'inclure un
mcanisme de clture d'une connexion.
Une implmentation dsireuse de suspendre une connexion DEVRAIT transmettre un paquet RequteFermeture. Ces paquets DEVRAIENT tre mis continuellement jusqu' rception d'un paquet FermetureAcquitte, ou jusqu' ce que la couche infrieure ait signal sa dsactivation, ou encore jusqu' ce que le nombre
de requtes soit suffisant pour que le distant puisse tre raisonnablement considr comme dconnect.
Sur rception d'une Requte-Fermeture, un paquet Fermeture-Acquitte DOIT tre renvoy.
La rception d'un paquet Fermeture-Acquitte sans sollicitation indique que le distant est dans un des tats
Ferm ou Arrt, ou rclame une rengociation de la liaison.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Code
|Identificateur |
Longueur
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Donnes ...
+-+-+-+-+
Code
5 pour signifier Requte-Fermeture;
6 pour signifier Fermeture-Acquitte.
Identificateur
Lors de l'mission, la valeur d'identification DOIT tre modifie chaque fois que le contenu du champ de
donnes change, et ds qu'une rponse valide a t reue pour une requte antrieure. Lors de la retransmission
d'une mme requte, la valeur d'identification reste inchange.
Sur rception, la valeur d'identification de la Requte-Fermeture est recopie dans le champ d'identification
du paquet Fermeture-Acquitte mis en rponse.
Donnes
Le champ de Donnes est de longueur zro ou plus d'octets, et contient les donnes non interprtes par
l'metteur. Les donnes peuvent tre constitues de n'importe quelle squence d'octets binaires. La fin de ce
champ est donne par calcul l'aide du champ Longueur.
5.6. Code-Rejet
Description
La rception d'un paquet LCP affichant un code non reconnaissable indique que le distant dispose d'une
autre version de protocole que celle utilise par le rcepteur. Ceci DOIT tre report l'metteur du paquet
litigieux par l'mission d'un paquet Code-Rejet.
Sur rception d'un rejet d'un code mis et implmentant une fonction indispensable pour la version de
protocole implmente, l'implmentation DEVRAIT signaler le problme et avorter le processus de connexion,
dans la mesure o il est fortement improbable que le problme puisse tre corrig automatiquement.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Code
|Identificateur |
Longueur
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Paquet-rejet ...
+-+-+-+-+-+-+-+-+
Code
7 pour signifier Code-Rejet.
Identificateur
La valeur d'identification DOIT changer chaque mission d'un nouveau rejet.
Paquet-Rejet
Le champ Paquet-Rejet contient une copie du paquet LCP ayant t refus. Il commence par le champ
d'Information, et ne contient aucune en-tte Data Link Layer ni de FCS. Le Paquet-Rejet DOIT tre tronqu si
ncessaire pour se conformer la valeur d'URM maximale du distant.
5.7. Protocole-Rejet
Description
La rception d'un paquet PPP dont le champ Protocole affiche une valeur inconnue indique que le distant
essaie d'utiliser un protocole qui n'est pas support par le rcepteur. Ceci peut arriver lorsque le distant essaie
de configurer un nouveau protocole. Si l'automate LCP est dans l'tat Ouvert, le caractre illicite de cette
opration DOIT tre signal au distant par l'mission d'un paquet Protocole-Rejet.
Sur rception d'un paquet Protocole-Rejet, l'implmentation DOIT cesser toute mission de paquets de ce
protocole aussi rapidement qu'il le peut.
Les paquets Protocole-Rejet ne peuvent tre mis que par un LCP en tat Ouvert. Les paquets ProtocoleRejet reus lorsque le LCP est dans tout autre tat que le prcdent doivent tre ignors.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Code
|Identificateur |
Longueur
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Protocole-Rejet
|
Information-Rejete...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Code
8 pour signifier Protocole-Rejet.
Identificateur
La valeur d'identification DOIT tre modifie chaque nouveau rejet mis.
Protocole-Rejet
Le champ Protocole-rejet est de deux octets, et contient la copie du champ de protocole PPP du paquet
refus.
Information-Rejete
Le champ Information-Rejete contient une copie du paquet ayant t refus. Il commence par le champ
d'Information, et ne contient aucune en-tte Data Link Layer ni de FCS. L'Information-Rejete DOIT tre
tronqu si ncessaire pour se conformer la valeur d'URM maximale du distant.
5.8. Requte-Echo et Rponse-Echo

Description
Le LCP prvoit les paquets Requte-Echo et Rponse-Echo pour introduire un mcanisme de rebouclage du
lien de donnes permettant d'implmenter des fonctions de test. Ce rebouclage permet notamment le
dverminage d'un nouveau prototype d'implmentation, la mesure de la qualit de la ligne, la mesure de
performances, ainsi que de nombreuses autres fonctions annexes.
Sur rception d'une Requte-Echo en tat Ouvert, le LCP DOIT rpondre par un paquet Rponse-Echo.
Les paquets Requte-Echo et Rponse-Echo ne DOIVENT tre transmis que lorsque les LCP sont dans
l'tat Ouvert. Ces deux types de paquets, lorsqu'ils sont reus dans tout autre tat de l'automate, doivent tre
ignors par celui-ci.
Le format de ces paquets est exprim ci-dessous. Les champs sont transmis de gauche droite.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Code
|Identificateur |
Longueur
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Nombre-magique
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Donnes ...
+-+-+-+-+
Code
9 pour signifier Requte-Echo;
10 pour signifier Rponse-Echo.
Identificateur
En transmission, la valeur d'identification DOIT tre change ds que le contenu du champ de Donnes est
modifi, ou qu'une rponse valide a t reue pour une requte donne. Lors des retransmissions, La valeur
d'identification PEUT rester inchange.
En rception, l'identificateur d'une Requte-Echo sera copi dans la Rponse-Echo mise en retour.
Nombre-Magique
Le Nombre-Magique a une longueur de quatre octets, et permet de dtecter des liaisons en condition de
rebouclage. Tant que l'Option de Configuration relative aux Nombres-Magiques n'a pas t ngocie avec
sucs, Le Nombre-Magique DOIT tre transmis zro. Voir le paragraphe concernant l'Option de
Configuration Nombres-Magiques pour plus de dtails.
Donnes
Le champ de Donnes contient zro ou plus d'octets, et contient des donnes non interprtes. Ces donnes
peuvent constituer n'importe quelle squence d'octets binaires. La fin de ce champ est obtenue par calcul grce
l'indication de Longueur.
5.9. Requte-Elimination
Description
Le LCP dispose d'un code de Requte-Elimination dans le but de fournir un mcanisme de test de la liaison
de donne dans le sens local vers distant. Ce mcanisme permet la mise en uvre de fonctions de dverminage
de nouveaux prototypes, de fonctions de mesure de performances, et d'autres fonctions accessoires.
Les paquets Requte-Elimination NE DOIVENT ETRE mis que par un LCP en l'tat Ouvert. Sur
rception, ces paquets doivent tre ignors par le rcepteur.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Code
|Identificateur |
Longueur
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Nombre-Magique
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Donnes ...
+-+-+-+-+
Code
11 pour signifier Requte-Elimination.
Identificateur
La valeur d'identification DOIT changer chaque mission.
Nombre-Magique
Le Nombre-Magique a une longueur de quatre octets, et permet de dtecter des liaisons en condition de
rebouclage. Tant que l'Option de Configuration relative aux Nombres-Magiques n'a pas t ngocie avec
sucs, Le Nombre-Magique DOIT tre transmis zro. Voir le paragraphe concernant l'Option de
Configuration Nombres-Magiques pour plus de dtails.
Donnes
Le champ de Donnes contient zro ou plus d'octets, et contient des donnes non interprtes. Ces donnes
peuvent constituer n'importe quelle squence d'octets binaires. La fin de ce champ est obtenue par calcul grce
l'indication de Longueur.
<A NAME="6"></A>
6. Options de Configuration LCP
Les Options de Configuration du LCP permettent la ngociation de certaines modifications des valeurs par
dfaut des paramtres d'une liaison Point Point. Si une Option de Configuration n'est pas mentionne dans
une Requte-Configuration, on suppose que c'est la valeur par dfaut qui est requise pour cette Option.
Certaines Options de Configuration PEUVENT apparatre plus d'une fois. Cette possibilit est spcifique
certaines Options de Configuration, et est annonce dans la description de chaque Option de Configuration.
(aucune des Options de Configuration dcrites dans ce document ne peut tre mentionne plus d'une fois).
La fin de la liste d'Options de Configuration peut tre identifie par calcul l'aide du champ Longueur dans
le paquet LCP.
Sauf mention contraire, toutes les Options de Configuration concernent une transmission "half-duplex", soit
une moiti de la communication; typiquement, elles spcifient les caractristiques attendues en rception du
point de vue de l'metteur de la Requte.
Philosophie
Les options indiquent soit la disponibilit soit la ncessit d'implmentation de l'option demande par la
requte. Une implmentation ne pouvant interprter aucune option DEVRAIT nanmoins pouvoir fonctionner
avec une autre qui les reconnat toutes.
Des valeurs par dfaut sont spcifies pour chacune des options, permettant ainsi la liaison de pouvoir
s'tablir sans aucune ngociation, mais peut tre sur un mode rduit ou non optimis.
Sauf mention explicite, l'acquittement des options n'impose pas au distant l'utilisation d'une autre valeur que
celle par dfaut.
Il n'est donc pas ncessaire d'mettre les options requises avec les valeurs par dfaut dans une RequteConfiguration.
Un prototype du format gnral des Options de Configuration est donn ci-dessous. Les champs sont
0
1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Type
|
Longueur
|
Donnes ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
Le champ Type est dfini sur un octet, et indique le type d'Option de Configuration. Ce document liste
quelques options de base tablies la construction du protocole. Les dernires Options valides sont indiques
dans la RFC "Assigned Numbers" [2]. Voici les valeurs initialement admises :
0
1
3
4
5
7
8
RESERVE
Unit-Rception-Maximale
Protocole-Authentification
Protocole-Qualit
Nombres-Magiques
Compression-Protocoles
Compression-Adresses-et-Contrles
Longueur
Le champ Longueur est dfini sur un octet, et indique la longueur de l'Option de Configuration en comptant
l'octet de Type, la longueur elle-mme et le champ de Donnes.
Si une Option de Configuration dans une Requte-Configuration porte un numro valide, mais spcifie une
longueur errone ou non interprtable, un paquet Configuration-NonAcquitte DEVRAIT tre transmis
explicitant l'Option de Configuration demande, avec sa Longueur et ses Donnes rgulires.
Donnes
Le champ de Donnes peut transporter zro ou un nombre quelconque d'octets, et contient des informations
spcifiques l'Option de Configuration. Le format et la longueur du champs Donnes est dtermin par calcul
l'aide du champ de Type et de Longueur.
Lorsque la longueur mentionne semble prtendre que les donnes s'arrtent au del de la longueur du
champ Information du paquet LCP, ce paquet entier doit tre ignor sans affecter pour autant l'automate.
6.1. Unit-Rception-Maximale (URM)

Description
Cette Option de Configuration peut tre utilise pour informer le distant que cette implmentation peut
accepter des paquets plus grands que l'URM standard, ou l'inverse pour forcer le distant envoyer des paquets
plus courts.
La valeur par dfaut est de 1500 octets. Si des paquets plus courts sont demands par une implmentation,
celle-ci DEVRA nanmoins rester capable de recevoir des paquets de 1500 octets au cas ou la synchronisation
de la ligne serait perdue.
Note d'Implmentation :
Cette option est utilise pour indiquer une performance de l'implmentation. Le distant n'est pas tenu
d'exploiter cette performance. Par exemple, lorsqu'une implmentation indique une URM de 2048 octets, le
distant n'est pas oblig d'envoyer des paquets de cette taille. Le distant n'a pas non plus ncessairement
refuser la ngociation de l'option et peut librement mettre des paquets de 1500 octets, dans la mesure o toute
implmentation doit au moins accepter des paquets de cette taille.
Le format de l'Option de Configuration Unit-Rception-Maximale est donn ci-dessous. Les champs sont
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Type
|
Longueur
|
Unit-Rception-Maximum
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
1
Longueur
4
Unit-Rception-Maximum
Le champ Unit-Rception-Maximale est cod sur deux octets, et spcifie le nombre maximum d'octets que
doit comporter un ensemble Information plus Bourrage. Il ne compte pas les octets de trame, le champ de
Protocole, le FCS, ni aucun bits ou octets "transparents".
6.2. Protocole-Authentification
Description
Sur certaines liaisons, il peut tre utile de demander au distant de s'authentifier avant de permettre le transit
de protocoles de niveau rseau.
Cette Option de Configuration procure une mthode pour ngocier l'usage d'un protocole d'authentification
spcifique. Par dfaut, aucune authentification n'est demande.
Une implmentation NE DOIT PAS faire figurer plusieurs Options Protocole-Authentification dans ses
paquets de Requte-Configuration. Au lieu de cela, elle DEVRAIT tenter de configurer le protocole le plus
"adquat" en premier. Si ce protocole est rejet par la ngociation, alors l'implmentation DEVRAIT tenter de
ngocier le protocole suivant dans l'ordre de prfrence dans un nouveau paquet Requte-Configuration.
L'implmentation mettant la Requte-Configuration indique qu'il attend que le distant s'authentifie. Si le
distant acquitte cette option, alors il accepte de s'authentifier avec le protocole spcifi dans la requte. Une
implmentation recevant un acquittement pour cette option DEVRAIT attendre l'identification du distant en
activant le protocole indiqu.
Il n'y a aucune obligation que l'authentification soit faite dans les deux sens, ni que le mme protocole soit
utilis dans les deux directions pour effectuer une "reconnaissance" bilatrale. Il est tout fait acceptable que
deux protocoles distincts soient utiliss pour les deux sens d'authentification. Ceci dpendra videmment du
rsultat de la ngociation.
Le format pour l'Option de Configuration Protocole-Authentification est donn ci-dessous. Les champs sont
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Type
|
Longueur
| Protocole-Authentification
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Donnes ...
+-+-+-+-+
Type
3
Longueur
>= 4
Protocole-Authentification
Le champ Protocole-Authentification est dcrit par deux octets, et indique le protocole d'authentification
dsir. Les valeurs de ce champ sont toujours les mmes que celles mentionnes dans le champ de protocole
PPP pour ce mme protocole d'authentification.
Ce document liste quelques valeurs de protocoles d'authentification tablies la construction de ce
protocole. Les derniers protocoles valids sont indiqus dans la RFC "Assigned Numbers" [2]. Voici les valeurs
initialement admises :
Identificateur (hexa) de Protocole

c023
c223
PAP (protocole d'identification par mot de passe)

CHAP (protocole par change de certificats)
Donnes
Le champ de donne contient zro ou un nombre quelconque d'octets, et contient des donnes additionnelles
selon le protocole spcifi.
6.3. Protocole-Qualit
Description
Sur certaines liaisons, il peut tre souhaitable de dterminer quand, et dans quelle proportion la liaison perd
des donnes. Ce procd est appel contrle de qualit de liaison.
Cette Option de Configuration procure une mthode pour ngocier l'usage d'un protocole particulier pour le
contrle de qualit de liaison. Par dfaut, le contrle de qualit de liaison est dsactiv.
L'implmentation mettant la Requte-Configuration indique qu'elle demande au distant de lui envoyer des
donnes pour tester la qualit de liaison. Si un distant acquitte cette option, alors il dclare accepter l'usage de
ce protocole. Une implmentation recevant un acquittement pour cette option DEVRAIT attendre du distant un
change sur le protocole convenu.
Il n'y a aucune obligation que le contrle de qualit soit fait dans les deux sens, ni que le mme protocole
soit utilis dans les deux directions. Il est tout fait acceptable que deux protocoles distincts soient utiliss pour
les deux sens de la mesure. Ceci dpendra videmment du rsultat de la ngociation.
Le format pour l'Option de Configuration Protocole-Qualit est donn ci-dessous. Les champs sont transmis
de gauche droite.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Type
|
Longueur
|
Protocole-Qualit
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Donnes ...
+-+-+-+-+
Type
4
Longueur
>= 4
Protocole-Qualit
Le Protocole-Qualit est dcrit sur deux octets, et indique le type de protocole de contrle de qualit
demand. Les valeurs de ce champ sont toujours les mmes que celles mentionnes dans le champ de protocole
PPP pour ce mme protocole de mesure.
Ce document liste quelques valeurs de protocoles de contrle tablies la construction de ce protocole. Les
derniers protocoles valids sont indiqus dans la RFC "Assigned Numbers" [2]. Voici les valeurs initialement
admises :
Identificateur (hexa) de Protocole

c025
Link Quality Report
Donnes
Le champ de donne contient zro ou un nombre quelconque d'octets, et contient des donnes additionnelles
selon le protocole spcifi.
6.4. Nombres-Magiques
Description
Cette Option de Configuration procure une mthode pour dtecter des liaisons reboucles et d'autres
anomalies au niveau Liaison de Donnes. Cette Option de Configuration POURRA tre ncessaire selon la
prsence ou l'absence d'autres Options de Configuration telles que l'option Protocole-Qualit. Par dfaut,
l'option Nombres-Magiques n'est pas ngocie, et la valeur zro doit tre utilise l o un Nombre-Magique
aurait du tre inscrit.
Avant de requrir cette Option de Configuration, une implmentation DOIT choisir son propre NombreMagique. Il est conseill de choisir ce Nombre-Magique de la faon la plus alatoire possible de sorte qu'il
puisse tre garanti avec une trs forte probabilit que ce nombre soit unique pour deux implmentation en
contact. Un bonne mthode pour obtenir l'unicit de ce nombre est de prendre comme base de calcul un nombre
lui-mme unique. Rpondent cette dfinition les numros de srie des machines, ou d'autres adresses
matrielles dans le rseau, des horloges dates, etc. Des nombres prsentant un bon facteur d'alatoire sont
obtenus par mesure prcise du temps entre deux vnements tels que la rception de paquets sur une autre
connexion rseau, le temps de rponse d'un serveur, ou la cadence de frappe d'un utilisateur humain. Il peut
tre aussi suggr de combiner plusieurs source alatoires pour augmenter la probabilit d'unicit.
Lorsqu'une Requte-Configuration prcise une Option de Configuration Nombres-Magiques, le NombreMagique reu est compar avec le Nombre-Magique de la dernire requte mise vers un distant. Si ces deux
Nombres-Magiques sont distincts, la ligne est considre comme non boucle, et le Nombre-Magique
DEVRAIT tre acquitt. Si les deux Nombres-Magiques sont gaux, alors il est probable, mais pas certain, que
la ligne est reboucle et que la requte reue est en fait la dernire mise. Pour s'assurer de cette ventualit, un
paquet Configuration-NonAcquitte DOIT tre mis avec une nouvelle valeur de Nombre-Magique. Une
nouvelle Requte-Configuration NE DEVRAIT PAS tre mise vers le distant tant qu'une raction normale
n'est pas obtenue (c'est dire, un paquet Configuration-NonAcquitte est reu ou la temporisation de Reprise
expire).
La rception d'un paquet Configuration-NonAcquitte prsentant un Nombre-Magique diffrent de celui
transmis dans le dernier paquet Configuration-NonAcquitte mise vers le distant prouve que la liaison n'est
pas boucle, en liminant le cas possible bien qu'improbable de Nombres-Magiques gaux par pur hasard. Si les
deux Nombres-Magiques des paquets Configuration-NonAcquitte sont gaux, la probabilit d'tre en prsence
d'une boucle augmente, et un nouveau Nombre-Magique DOIT tre choisi. Dans les deux cas, une nouvelle
Requte-Configuration DEVRAIT tre mise avec ce nouveau Nombre-Magique.
Si la ligne est effectivement en tat reboucl, cette squence (transmission d'une Requte-Configuration,
rception d'une Requte-Configuration, transmission d'un Configuration-NonAcquitte, rception d'un
Configuration-NonAcquitte) se reproduira encore et encore. Si la ligne n'tait pas boucle, au pire cette
squence pourrait se produire un certain nombre (petit) de fois, mais aurait vraiment trs peu de chance de se
rpter continuellement. Selon toute attente, les Nombres-Magiques choisis des deux cts de la liaison
devraient rapidement diverger, arrtant ainsi cette squence. La table suivante montre la probabilit de
collisions en supposant que les deux extrmits choisissent des Nombres-Magiques selon une loi de distribution
parfaitement uniforme :
Nombre de Collisions
-------------------1
2
3
Probabilit
--------------------1/2**32
= 2.3 E-10
1/2**32**2 = 5.4 E-20
1/2**32**3 = 1.3 E-29
Pour que cette divergence puisse survenir, il faut assurer un caractre alatoire et unique suffisant. Si une
source prsentant ces qualits intrinsques suffisantes ne peut tre trouve, il est conseill de ne pas activer
cette Option de Configuration; Des Requte-Configuration ne DOIVENT PAS tre mises avec cette option et
toute Option de Configuration Nombre-Magique mise par le distant DOIT tre soit Acquitte soit rejete. Dans
ce cas, l'implmentation n'a pas la possibilit de dtecter avec suffisamment d'assurance une situation de
rebouclage, bien que cette dernire puisse l'tre par le distant.
Si une implmentation met effectivement une Requte-Configuration affichant une Option de
Configuration Nombres-Magiques, alors elle de DOIT PAS rpondre a une Requte-Configuration distante
avec la mme option par un paquet Configuration-Rejete. En d'autres termes, si une implmentation dsire
utiliser l'option Nombres-Magiques, alors elle DOIT alors accepter que le distant en fasse de mme. Si une
implmentation reoit un paquet Configuration-Rejete en rponse une Requte-Configuration, cela
signifiera seulement que le lien n'est pas reboucl, et que le distant ne dsira pas utiliser les NombresMagiques. Dans ce cas, une implmentation DEVRAIT ragir comme si la ngociation avait abouti (comme si
une Configuration-Acquitte avait t reue la place).
Le Nombre-Magique peut aussi tre utilis pour dtecter un rebouclage de ligne pendant une phase de
fonctionnement normale, en plus d'une phase de ngociation d'options. Tous les paquets LCP Requte-Echo,
Rponse-Echo, et Requte-Elimination ont un champ Nombre-Magique. Si les Nombres-Magiques ont t
ngocis avec sucs, une implmentation DOIT transmettre ces paquets avec le Nombre-Magique ngoci.
Le champ Nombre-Magique de ces paquets DEVRAIT tre test sur rception. Tous les champs NombresMagiques reus DOIVENT avoir une valeur soit nulle soit gale au Nombre-Magique unique dfini pour le
distant, suivant le rsultat de la ngociation de cette option entre les deux entits.
La rception d'un champ Nombre-Magique de valeur gale au Nombre-Magique dfini par l'implmentation
locale signifie la possibilit d'une liaison reboucle. La rception d'un Nombre-Magique de valeur diffrente
que celle ngocie comme local, ou de la valeur distante, ou nulle si des valeurs n'ont pas t ngocies, indique
que la liaison a t mal configure.
Les procdures pour se rcuprer de l'un ou l'autre cas de figure ne sont pas prcises, et peuvent varier
d'une implmentation l'autre. Une mthode quelque peu pessimiste est d'assimiler ces situations un
vnement Down du LCP. Une rouverture relancera le processus pour ngocier de nouveau la liaison,
processus qui ne pourra tre achev tant que perdurent les causes de rebouclage de la liaison, et tant que des
Nombres-Magiques conformes n'ont pu tre ngocis. Une mthode plus optimiste (dans le cas d'un lien en
boucle) est d'entamer la transmission de paquets Requte-Echo LCP jusqu' ce que soit reu un paquet
Rponse-Echo conforme, indiquant de ce fait la fin d'une telle situation.
Le format pour l'Option de Configuration Nombres-Magiques est donne ci-dessous. Les champs sont
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Type
|
Longueur
|
Nombres-Magiques
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Nombres-Magiques(suite)
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
5
Longueur
6
Nombres-Magiques
Le champ Nombres-Magiques est dcrit sur quatre octets, et donne un nombre suppos tre unique vis vis
de l'autre extrmit. Une valeur nulle est illgale et DOIT tre refuse, si l'Option Nombres-Magiques n'est pas
elle-mme rejete.
6.5. Compression-Champ-Protocole (PFC)

Description
Cette Option de Configuration procure une mthode pour ngocier la compression du champ Protocole PPP.
Par dfaut, toutes les implmentations DOIVENT transmettre des paquets avec un champ Protocole PPP de
deux octets.
Les valeurs pour le champ Protocole PPP sont choisis de sorte que certaines valeurs puissent tre exprimes
sous une forme rduite d'un octet, et de faon tout fait univoque par rapport leur expression en deux octets.
Cette Option de Configuration est envoye pour informer le distant que le local accepte des valeurs de Protocole
compresses sur un octet.
Comme indiqu prcdemment, le champ Protocole utilise un mcanisme d'extension conforme au
mcanisme de l'ISO 3309 concernant les champs d'Adresse; le bit de poids faible (LSB) de chaque octet est
utilis pour indiquer l'extension du champ Protocole. Un "0" binaire comme LSB indique que l'octet suivant
code la suite du champ Protocole. Un "1" binaire comme LSB marque le dernier octet du champ Protocole.
Notez qu'ainsi, un nombre quelconques d'octets nuls peuvent tre placs avant le champ, indiquant toujours la
mme valeur (considrez les deux reprsentations pour la valeur 3, 00000011 et 00000000 00000011).
Sur des liaisons bas dbit, il est souhaitable de prserver la bande passante utile en envoyant le moins de
donnes redondantes ou non significatives possible. L'Option de Configuration Compression-Champ-Protocole
permet de privilgier tantt simplicit d'implmentation, tantt optimisation de la bande utile. Si la ngociation
se droule avec sucs, le mcanisme d'extension ISO 3309 peut tre utilis pour compresser le champ Protocole
sur un octet au lieu de deux. La grande majorit des paquets mis par la suite peuvent tre compresss dans la
mesure o la plupart des valeurs de protocoles utilises sont infrieures 256.
Des champs Protocoles ne doivent JAMAIS tre compresss sauf si cette Option de Configuration a t
ngocie. Une fois cette option ngocie, les implmentations PPP DOIVENT accepter des paquets PPP de
champ Protocole un ou deux octets, SANS distinction AUCUNE entre les deux formes.
Le champ Protocole n'est JAMAIS compress lors de l'envoi de paquets LCP. Cette rgle garantit une
reconnaissance univoque des paquets LCP.
Lorsqu'un champ Protocole est compress, le champ FCS de la couche donnes (Data Link Layer) est
calcul sur la trame compresse, et non sur la trame originale.
Le format de l'Option de Configuration Compression-Champ-Protocole est donn ci-dessous. Les champs
sont transmis de gauche droite.
0
1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Type
|
Longueur
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
7
Longueur
2
6.6. Compression-Adresse-et-Contrles (ACFC)

Description
Cette Option de Configuration procure une mthode pour ngocier la compression des champs d'Adresse et
Contrles de la couche de donnes (Data Link Layer). Par dfaut, toutes les implmentations DOIVENT
transmettre des trames avec des champs Adresse et Contrles appropris la dfinition de la trame
correspondante.
Dans la mesure o ces donnes ont souvent des valeurs statiques pour des liaisons point--point, il est
possible sans risque de les compresser. Cette Option de Configuration est envoye pour informer le distant que
l'implmentation locale peut recevoir des champs Adresse et Contrles compresss. Si une trame compresse
est reue alors que cette option n'a pas t ngocie, ces trames devront tre ignores.
Les champs Adresse et Contrle NE DOIVENT PAS tre compresss dans des paquets LCP. Cette rgle
permet d'assurer une reconnaissance univoque des paquets LCP. Lorsque les champs Adresse et Contrle sont
compresss, le champ FCS de la couche de donnes (Data Link Layer) est calcul sur la trame compresse et
non sur la trame originale.
Le format de L'Option de Configuration Compression-Adresse-et-Contrle est donn ci-dessous. Les
champs sont transmis de gauche droite.
0
1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Type
|
Longueur
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
8
Longueur
2
Considrations scuritaires
Certains aspects concernant la scurisation sont traits dans les sections Phase d'Authentification,
Evnement Close, et Option Protocole-Authentification.
Rfrences
[1] Perkins, D., "Requirements for an Internet Standard Point-to- Point Protocol", RFC 1547, Carnegie Mellon
University, December 1993.
[2] Reynolds, J., and Postel, J., "Assigned Numbers", STD 2, RFC 1340, USC/Information Sciences Institute,
July 1992.
Remerciements
Ce document est produit par le Point-to-Point Protocol Working Group de l'Internet Engineering Task Force
(IETF). Tout commentaire doit tre transmis la mailing list ietf-ppp@merit.edu.
La majeure partie de ce texte a t tire des spcifications du groupe de travail [1]; des RFCs 1171 & 1172,
par Drew Perkins, alors l'Universit Carnegie Mellon, et par Russ Hobby de l'Universit de Californie
Davis.
William Simpson est le premier avoir introduit des principes et une terminologie consquente; on lui doit
le nouveau design des phases et tats de ngociation.
De nombreuses personnes ont contribu la mise au point du Protocole Point--Point. La liste complte de
ces personnes est trop longue, mais nous attribuons des remerciements particuliers : Rick Adams, Ken
Adelman, Fred Baker, Mike Ballard, Craig Fox, Karl Fox, Phill Gross, Kory Hamzeh, Russ Hobby, David
Kaufman, Steve Knowles, Mark Lewis, Brian Lloyd, John LoVerso, Bill Melohn, Mike Patton, Drew Perkins,
Greg Satz, John Shriver, Vernon Schryver, et Asher Waldfogel.
Remerciements particuliers Morning Star Technologies pour son aide matrielle et ses accs rseau ayant
permis l'tablissement de cette spcification.
Contact
Le groupe de travail peut tre contact l'adresse suivante :
Fred Baker
Advanced Computer Communications
315 Bollay Drive
Santa Barbara, California 93117
fbaker@acc.com
Toute question technique sur ce mmo peut tre envoye :
William Allen Simpson
Daydreamer
Computer Systems Consulting Services
1384 Fontaine
Madison Heights, Michigan 48071
Bill.Simpson@um.cc.umich.edu
bsimpson@MorningStar.com

PPP PDF

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

PPP PDF

Transféré par

Droits d'auteur :

Formats disponibles

rfc1661

Le Protocole Point--Point (PPP)

Table des Matires

Protocole de contrle de liaison (Link Control Protocol)

Protocole de gestion rseau (Network Control Protocol)

1.1. Note sur la smantique

3. Fonctionnement d'une liaison PPP

3.2. Diagramme d'tats

3.3. "Link Dead" (couche physique non prte)

3.6. Phase de ngociation rseau

3.7. Fermeture de liaison

4. L'automate de ngociation d'options

Up = couche infrieure prte

tlu = Couche prte

4.1. Table de transition d'tats

Fermeture en cours (Closing)

Arrt en cours (Stopping)

Code-Rejet-Reu, Protocole-Rejet-Reu (RXJ+,RXJ-)

Requte-Echo-Reu, Rponse-Echo-Reu, Requte-Elimination-Reu. (RXR)

4.5. Elimination de rebouclages

4.6. Compteurs et Temporisations

5. Formats de paquets LCP

5.5. Requte-Fermeture et Fermeture-Acquitte

5.8. Requte-Echo et Rponse-Echo

6.1. Unit-Rception-Maximale (URM)

Identificateur (hexa) de Protocole

PAP (protocole d'identification par mot de passe)

Identificateur (hexa) de Protocole

Link Quality Report

6.5. Compression-Champ-Protocole (PFC)

6.6. Compression-Adresse-et-Contrles (ACFC)

Vous aimerez peut-être aussi