Vous êtes sur la page 1sur 34

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) Nom de protocole 0001 Protocole de bourrage

0003 001f 007d 00cf 00ff 8001 801f 807d 80cf 80ff c021 c023 c025 c223

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.

Note d'implmentation :
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 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 Actions 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 | tls/1 1 irc,scr/6 3r 5r 5r Close| 0 tlf/0 2 2 4 4 | TO+ | str/4 str/5 TO- | tlf/2 tlf/3 | RCR+ | sta/2 irc,scr,sca/8 4 5 RCR- | sta/2 irc,scr,scn/6 4 5 RCA | sta/2 sta/3 4 5 RCN | sta/2 sta/3 4 5 | RTR | sta/2 sta/3 sta/4 sta/5 RTA | 2 3 tlf/2 tlf/3 | RUC | scj/2 scj/3 scj/4 scj/5 RXJ+ | 2 3 4 5 RXJ- | tlf/2 tlf/3 tlf/2 tlf/3 | RXR | 2 3 4 5

| 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 FermetureAcquitte 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 RequteConfiguration 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 Acquitementconnexion. 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. Note d'implmentation : 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. Note d'implmentation : 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. Note d'implmentation : 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. Note d'implmentation : 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. Note d'implmentation : 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 Max-Configuration). Le compteur est dcrment chaque transmission, y compris la premire. Note d'implmentation : 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. Note d'implmentation :

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 RequteConfiguration 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 ConfigurationRejete 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. Note d'implmentation : 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 Requte-Configuration. 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. 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
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
Le champ d'Options est de longueur variable, et contient une liste de zro ou plus Options de Configuration 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. 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
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
Le champ d'Options est de longueur variable, et contient une liste de zro ou plus Options de Configuration 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. 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 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. 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 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. 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 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. 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 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 transmis de gauche droite.

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 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 | 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 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-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 RequteConfiguration 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 Nombres-Magiques. 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 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 | 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