Seuls 8 octets supplémentaires sont nécessaires 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 préoccupation majeure, cette encapsulation et la mise en trame peut être réduite à 2 ou 4 octets.
Pour permettre des implémentations à ha 1000 ute vitesse, l'encapsulation par défaut utilise des champs élémentaires, un seul d'entre eux devant être examiné pour réaliser le démultiplexage. L'en-tête par défaut et les champs d'information tombent toujours sur des limites de mots de 32-bits, la fin de message pouvant être complétée par des octets de "bourrage".
L'auto-configuration de la liaison est implémentée grâce à un mécanisme de négociation d'options extensible, par lequel chaque extrémité de la liaison renseigne l'autre de ses possibilités et de ses contraintes propres. Bien que ce mécanisme de négociation d'options ne soit décrit dans ce document qu'en rapport avec le Link Control Protocol (LCP), les fonctionnalités en sont suffisamment générales pour pouvoir être réutilisées par d'autres protocoles de contrôle, parmi lesquels la famille des protocoles NCP.
Une explicitation sommaire de l'encapsulation PPP est donnée ci-dessous. Les champs sont toujours transmis de gauche à droite.
+-----------+-------------+----------+ | Protocole | Information | Bourrage | | 8/16 bits | * | * | +-----------+-------------+----------+
La structure de ce champ est conforme aux mécanismes définis par l'ISO 3309 pour l'extension des champs d'adresse. Tous les Protocoles DOIVENT être impairs; le bit le moins significatif de l'octet le moins significatif DOIT être égal à "1". De plus, tous les Protocoles DOIVENT être codés de sorte que le bit le moins significatif de l'octet le plus significatif soit égal à "0". Les trames reçues qui ne se conforment pas à ces règles DOIVENT être considérées comme transportant un Protocole non identifié.
Les valeurs du champ Protocole comprises dans la plage "0***" à "3***" identifient un protocole de niveau réseau de paquets spécifiques, et des valeurs entre "8***" et "b***" identifient des paquets appartenant aux Network Control Protocols (NCPs) associés, le cas échéant.
Des valeurs de champ de protocole comprises entre "4***" et "7***" sont utilisées pour des protocoles de faible trafic et ne disposant pas de NCP associé. Les valeurs entre "c***" et "f***" identifient des paquets appartenant aux Link Control Protocols (comme LCP).
Les valeurs les plus récentes établies pour ce champ Protocole sont listées dans le document "Assigned Numbers" [2]. La spécification suivante réserve les valeurs :
Valeur (en hexa) | Nom de protocole |
0001 | Protocole de bourrage |
0003 à 001f | réservé (non transparents) |
007d | réservé (Control Escape) |
00cf | réservé (PPP NLPID) |
00ff | réservé (non comprimables 1000 ) |
8001 à 801f | non utilisé |
807d | non utilisé |
80cf | non utilisé |
80ff | non utilisé |
c021 | Link Control Protocol |
c023 | Password Authentication Protocol |
c025 | Link Quality Report |
c223 | Challenge Handshake Authentication Protocol |
Les développeurs de nouveaux protocoles DOIVENT obtenir un numéro de protocole de l'Internet Assigned Numbers Authority (IANA), à IANA@isi.edu.
La longueur maximum du champ Information, y compris le bourrage, mais hors champ Protocole, est limité à l'Unité de Réception Maximale (URM), par défaut 1500 octets. Par négociation, des implémentations de PPP plus "libérales" pourront utiliser d'autres valeurs d'URM.
Ensuite, PPP DOIT envoyer des paquets NCP pour choisir et configurer un ou plusieurs protocoles réseau disponibles. Une fois que les protocoles réseau choisis ont été configurés, les datagrammes pour chacun de ces protocoles réseau peuvent être envoyés sur la liaison.
La liaison restera disponible et configurée pour la communication jusqu'à ce que des paquets LCP ou NCP ne ferment explicitement la liaison, à moins qu'un événement extérieur ne survienne (par exemple une temporisation 1000 d'inactivité, ou l'intervention de l'administrateur).
+------+ +-------------+ +----------------+ | | UP | |Ouverture| |SUCCES/NONE |"Dead"|------->|Etablissement|-------->|Authentification|--+ | | | | | | | +------+ +-------------+ +----------------+ | ^ | | | | Echec | Echec | | +<--------------+ +-------------+ | | | | | +-----------+ | +-----------+ | | DOWN | | | Fermeture | | | +---------| Fin |<---+<----------| Connexion |<----+ | | | | +-----------+ +-----------+ |
Durant cette phase, l'automate LCP (décrit plus loin) sera dans l'état Initial ou Démarrage. Le passage à l'état Etablissement sera signalée par un événement Up à l'automate LCP.
Toutes les options de Configuration sont supposées être à leur valeur par défaut avant d'être modifiées par l'échange de configuration. Voir le chapitre sur les options de configuration LCP pour plus de détails.
Il est important de noter que seules les options de configuration indépendantes de tout protocole réseau sont configurées par LCP. La configuration de chacun des protocoles réseau est réalisée via des protocoles Network Control Protocols (NCPs) spécifiques durant la phase de configuration réseau. Tout paquet non-LCP reçu pendant cette phase DOIT être ignoré.
La réception d'une requête pour configuration LCP provoque un retour à l'état d'établissement de liaison à partir de l'état de configuration réseau ou de la phase d'authentification.
Par défaut, l'authentification n'est pas demandée. Lorsqu'une implémentation 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 tôt possible après la conclusion de la phase d'établissement. La détermination de la qualité de la liaison POURRA être réalis 1000 ée dans le même temps. Toutefois, une implémentation correcte NE DOIT PAS permettre un échange de paquets de mesure de la qualité de liaison, dans le but de retarder indéfiniment le processus d'authentification.
Le passage de la phase d'authentification à la phase de négociation de protocole réseau NE DOIT PAS être accepté avant que l'authentification n'ait abouti avec succès. Si l'authentification échoue, l'authentificateur DEVRAIT plutôt entamer une phase de fermeture de liaison.
Les paquets LCP, d'authentification, et de mesure de qualité de liaison sont les seuls autorisés pendant cette phase. Tout autre forme de paquet DOIT être ignoré.
C'est dans tous les cas l'implémentation qui a refusé d'authentifier son correspondant qui doit entamer la phase de fermeture de liaison.
Lorsqu'un NCP atteint l'état Ouvert, la liaison PPP est alors prête à véhiculer les paquets du protocole réseau associé. Tout paquet dans un protocole géré 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'implémentation DOIT être retourné à l'émetteur dans un paquet Protocole-Rejeté (décrit plus loin). Seuls les protocoles gérés (mais de NCP fermés) sont ignorés.
Dans cet état, le trafic sur le lien est composé de toute combinaison de paquets LCP, NCP, et datagrammes réseau.
Le protocole LCP est utilisé pour procéder à la clôture de la liaison par l'échange de paquets de Clôture. Lors de la fermeture, PPP en informe tout d'abord les couches réseau afin que ces dernières puissent prendre leurs dispositions.
Après l'échange des paquets de Clôture, l'implémentation DEVRAIT signaler à la couche physique de procéder à la déconnexion physique, particulièrement utile dans le cas de l'échec d'une authentification. L'émetteur d'une Requête pour Clôture DEVRAIT se déconnecter juste après avoir reçu un acquittement de Clôture, ou au plus tard après que la temporisation de Reprise soit écoulée. Le récepteur d'une Requête pour Clôture DEVRAIT attendre la déconnexion du correspondant, et NE DOIT PAS se déconnecter pendant au moins la durée d'une temporisation de Reprise comptée à partir de l'émission de l'acquittement de Clôture. PPP DEVRAIT passer en état "Link Dead".
Tout paquet autre que LCP reçu durant cette phase DOIT être ignoré.
Certains types de paquets -- Configuration-NonAcquittée et Configuration-Rejetée, ou Code-Rejeté et Protocole-Rejeté, ou Requête-Echo, Réponse-Echo et Requête-Elimination – ne sont pas différentiés dans la description de l'automate. Comme ceci sera décrit plus tard, ces paquets correspondent cependant à des usages différents. Ils génèrent cependant toujours des transitions identiques.
Evénements | Actions |
Up = couche inférieure prête | tlu = Couche prête |
Down = couche inférieure non prête | tld = Couche non prête |
Open = commande administrateur Open | tls = Démarrer |
Close = commande administrateur Close | tlf = Terminer |
TO+ = Temporisation non expirée > 0 | irc = Initialiser-Reprise |
TO- = Temporisation expirée | zrc = Réinitialiser-compteur |
RCR+ = Requête-Configuration-Reçue (Correcte) | scr = Emission-Requête-Configuration |
RCR- = Requête-Configuration-Reçue (Incorrecte) | |
RCA = Configuration-Acquittée-Reçu | sca = Emission-Configuration-Acquittée |
RCN = Configuration-NonAcquittée/Rejetée-Reçu | scn = Emission-Configuration-NonAcquittée/Rejetée |
RTR = Requête-Fermeture-Reçue | str = Emission-Requête-Fermeture |
RTA = Fermeture-Acquittée-Reçu | sta = Emission-Fermeture-Acquittée |
RUC = Code-Inconnu-Reçu | scj = Emission-Code-Rejeté |
RXJ+ = Code-Rejeté-Reçu
(non critique) ou Protocole-Rejeté-Reçu
RXJ- = Code-Rejeté-Reçu (critique) ou Protocole-Rejeté-Reçu |
|
RXR = Requête-Echo-Reçu | ser = Emission-Echo-Réponse |
RRR = Réponse-Echo-Reçu
ou Requête-Elimination-Reçu |
| 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- | - &nbs 1000 p; - 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/9Les états ans lesquels la temporisation Reprise tourne sont identifiables par la possibilité d'événements TO. Seules les actions Emission-Requête-Configuration, Emission-Requête-Fermeture et Réinitialiser-Compteur démarrent ou redémarrent la temporisation de Reprise. La temporisation est arrêtée lors de toute transition d'un état permettant le comptage de temporisation vers un état ne la permettant pas.
Les événements et les actions sont implémentées selon une architecture d'échange de messages, plutôt que par gestion de signaux. Si l'on désire qu'une action contrôle 1000 certains signaux (par exemple DTR), des actions supplémentaires devront être définies.
[p] Option passive; voir Arrêté(Stopped). [r] Option de redémarrage; voir l'événement ouverture. [x] Connexion croisée; voir l'événement RCA.
Sur réception d'une Requête-Configuration, un paquet Fermeture-Acquittée est émis. Les paquets Fermeture-Acquittée sont ignorés pour éviter un fonctionnement en boucle.
Lorsqu'un paquet Requête-Configuration est reçu, une réponse appropriée est envoyée. La réception de tout autre paquet entraîne l'émission d'un paquet Fermeture-Acquittée. Ces mêmes paquets Fermeture-Acquittée seront ignorés en réception pour éviter de boucler le protocole.
Justification : L'état arrêté (Stopped) est un état intermédiaire 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é combinés dans cette étape.
Il existe une concurrence temporelle entre la réponse par l'événement Down (attendu après l'action Terminer de la couche PPP) et l'apparition possible d'un événement Requête-Configuration-Reçue. Lorsqu'une Requête-Configuration 1000 arrive avant la chute de ligne (Down), ce dernier événement prévaudra et la ligne reviendra à l'état initial dès sa réception. Ceci protège le protocole contre les attaques par répétition.
Option d'implémentation :
Lorsque le distant ne parvient pas à répondre à une Requête-Configuration locale, l'implémentation POURRA attendre la réception d'une Requête-Configuration distante. Dans ce cas, l'action Terminer ne sera pas effectuée lorsque l'événement TO- survient dans les états Connexion-demandée, Connexion-Acquittée et Acquitement-connexion.
Cette option est utile dans le cas de lignes permanentes dédiées, ou circuits ne disposant pas de signalisation d'état physique de ligne, mais doit être proscrite pour des lignes câblées sur un réseau commuté.
En réponse à un événement Fermeture-Acquittée-reçu, l'automate passe en état Fermé.
Lorsque la temporisation de Reprise expire, une nouvelle Requête-Fermeture est émise, et la temporisation relancée. Lorsque la temporisation a expiré un nombre de fois fixé, l'automate passe alors en état Fermé.
Justification :
L'état Arrêt en Cours définit parfaitement comment terminer une communication avant de permettre le passage de nouvelles données. Une fois la liaison coupée, une nouvelle configuration peut être demandée par l'état Arrêté ou Démarrage.
Lorsque cet état est atteint par l'automate, l'implémentation DEVRAIT émettre vers la couche supérieure un événement Up. A l'inverse, lorsque cet état est quitté, l'implémentation DEVRAIT émettre un signal Down vers la couche supérieure.
Typiquement, cet événement est généré par un pilote de modem, ou par toute autre interface entre PPP et un gestionnaire de média 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 désormais un fonctionnement au niveau réseau., l'action Couche-Prête du LCP déclenchera les actions Up de chaque NCP.
(NdT: cette couche devenant alors la couche inférieure des NCP).
Typiquement, cet événement est généré par un pilote de modem, ou par toute autre interface entre PPP et un gestionnaire de média physique, pour signaler au LCP que la liaison entre dans un état non opérationnel.
Il sera l'occasion pour le LCP de signaler à chaque NCP que la liaison quitte le fonctionnement au niveau réseau., l'action Couche-non-Prête du LCP déclenchera les actions Down de chaque NCP.
Si l'automate est dans l'impossibilité de commencer cette configuration (la ligne est physiquement indisponible, ou une commande Clos 1000 e précédente n'est pas encore totalement traitée), l'établissement de la nouvelle communication est automatiquement différé.
Lorsqu'une Requête-Fermeture est reçue, ou tout autre événement qui rend le lien non disponible, l'automate progressera vers un état dans lequel une réouverture de la ligne est possible. Aucune autre intervention de l'administrateur n'est nécessaire.
Option d'implémentation :
L'expérience a démontré que les utilisateurs relancent en général une nouvelle commande Open lorsqu'ils désirent renégocier la liaison. Cette action indique en général que les paramètres de la liaison sont à modifier.
Comme il ne s'agit pas de la sémantique exacte de l'événement d'Ouverture, il est suggéré que l'implémentation lance un événement Down immédiatement suivi d'un événement Up, lorsqu'une commande Open est exécutée alors que l'automate est dans l'un des états Ouvert, Fermeture en Cours, Arrêt en Cours, ou Arrêté. On prendra garde dans ce cas que l'avènement de l'événement Down ne puisse être provoqué par une autre cause.
La succession d'un Down puis d'un Up va provoquer une renégociation de la liaison, en suivant la progression passant par les états Démarrage et Connexion-demandée. La connexion est ainsi renégociée sans effets de bords notable.
Note d'implémentation :
Lorsque une authentification échoue, la liaison DEVRAIT être coupée, pour éviter une attaque par répétition et le refus de service aux autres utilisateurs. Comme la liaison est encore administrativement disponible (par définition), ceci pourrait être accompli en simulant une commande Close donnée au LCP, immédiatement suivie d'une commande Open. On prendra garde dans ce cas que l'avènement de l'événement Close ne puisse être provoqué par une autre cause.
L'événement Close suivi d'un Open provoque une coupure normale de la ligne, progressant depuis l'état Fermeture en Cours vers l'état Arrêt en Cours, l'action Terminer entraîne la déconnexion physique de la ligne. L'automate attend alors la prochaine demande de connexion dans l'état Arrêté ou Démarrage.
L'événement TO+ indique que le compteur de Reprise est toujours positif, ce qui provoque la réémission d'un paquet Requête-Configuration ou Requête-Fermeture suivant le cas.
L'événement TO- indique que le compteur de Reprise est passé à zéro, et aucun paquet de Requête ne doit être réémis dans ce cas.
L'événement RCR+ indique que la Requête-Configuration est légitime, et déclenche la transmission d'un paquet Configuration-Acquittée.
L'événement RCR- indique que la Requête-Configuration n'est pas légitime, ou acceptable, et déclenche la transmission d'un paquet Configuration-Rejetée ou Configuration-NonAcquittée.
Note d'implémentation :
Ces événements peuvent survenir sur une connexion ouverte. L'implémentation DEVRA être préparé à renégocier immédiatement les options de configuration.
Note d'implémentation :
Dans la mesure ou des paquets conformes ont déjà été reçus avant que les états Acquitement-Configuration-Reçu ou Ouvert, il reste très peu de chances qu'un paquet non conforme arrive dans cette phase. Comme il est spécifié, 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 résultera d'une imperfection de l'implémentation. Au pire, ce cas POURRAIT être enregistré dans le rapport d'erreurs.
Note d'implémentation :
Bien que les événements Configuration-NonAcquittée et Configuration-Rejetée cause les mêmes transitions d'état dans l'automate, ces paquets ont des effets différents quant aux options de configurations envoyées par la Requête-Configuration résultante.
Note d'implémentation :
Cet événement n'a pas la même signification que la commande Close (voir ci-avant), qui impose l'émission d'une commande d'ouverture par l'administrateur local pour répondre à des sollicitations d'ouverture. L'implémentation DOIT se préparer à recevoir une nouvelle Requête-Configuration sans aucune autre intervention de l'administrateur local.
L'événement 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 événements sont dans le contexte d'in fonctionnement normal. L'implémentation DOIT arrêter d'émettre un tel type de paquet.
L'événement RXJ- intervient lorsque la valeur rejetée a une signification critique, comme le rejet d'un code de configuration, ou le rejet du protocole LCP! Cet événement indique la présence d'une erreur fatale qui provoque la fin forcée de la communication.
Les résultats de cette action dépendent fortement de l'implémentation.
Typiquement, cette action DEVRAIT être menée par le LCP pour avancer vers la phase Link Dead, ou par un NCP pour indiquer au LCP que la liaison peut être coupée dès qu'il ne restera plus de NCP ouvert.
Les résultats de cette action dépendent fortement de l'implémentation.
Note d'implémentation :
En plus d'initialiser le compteur de Reprise, l'implémentation DOIT réinitialiser la temporisation d'attente à sa valeur initiale.
Note d'implémentation :
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 à zéro, l'implémentation DOIT initialiser la temporisation de Reprise à une valeur appropriée.
Configuration-NonAcquittée sont utilisés pour refuser une valeur d'Option de Configuration, et pour en suggérer une autre, acceptable par l'appelé. Les paquets Configuration-Rejetée sont utilisés pour refuser toute négociation sur les Options de Configuration, en principe parce que l'option demandée est inconnue ou non implémentée. Les conditions d'utilisation des paquets Configuration-NonAcquittée plutôt que Configuration-Rejetée sont décrits plus avant dans le chapitre détaillant les formats de paquets LCP.
Emission-Fermeture-Acquitt&eacu
1000 te;e (sta)
Un paquet Fermeture-Acquittée
est émis. Il rend compte de la réception d'un paquet Requête-Fermeture
ou peut aussi servir à la synchronisation des automates.
Note d'implémentation :
La temporisation de Reprise DEVRAIT être adaptative selon la vitesse de transmission de la liaison. La valeur par défaut est donnée pour des liaisons lentes (2400 à 9600 bauds), et dans le cas de lignes commutées à basculement lent (lignes téléphoniques). Des lignes plus rapides, ou à commutation rapide, POURRAIENT bénéficier de délais d'attente inférieurs.
Plutôt qu'utiliser une valeur constante, la temporisation de Reprise POURRAIT être d'abord fixée à une valeur faible puis être augmentée progressivement jusqu'à sa valeur finale théorique selon une progression géométrique 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 supplémentaire de 100 millisecondes pour donner au distant le temps de traiter le paquet avant de 1000 répondre. Certains circuits ajouteront une marge supplémentaire de 200 millisecondes pour un transfert "satellite". Les temps d'aller-retour pour des modems opérant à 14400 bauds sont mesurés entre environ 160 à plus de 600 millisecondes.
Quelles que soient 1000 les options de Configuration activées, tous les paquets LCP de Configuration, Fermeture et Rejet de Code (codes 1 à 7) seront systématiquement envoyés comme si aucune option de Configuration n'avait été négociée. En particulier, à chaque option de Configuration est attribuée une valeur par défaut. Ceci assure que tel paquet LCP restera toujours reconnaissable, même lorsqu'une extrémité de la ligne considère 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 hexadécimale c021 (Link Control Protocol).
Un résumé des formats de paquets LCP est donné ci-après. 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Données ... +-+-+-+-+ |
1 | Requête-Configuration |
2 | Configuration-Acquittée |
3 | Configuration-NonAcquittée |
4 | Configuration-Rejetée |
5 | Requête-Fermeture |
6 | Fermeture-Acquittée |
7 | Code-Rejeté |
8 | Protocole-Rejeté |
9 | Requête-Echo |
10 | Réponse-Echo |
11 | Requête-Elimination |
Les octets reçus en dehors de la plage définie par le champ Longueur sont traités comme des octets de bourrage et sont ignorés. Lorsqu'un paquet affiche une Longueur invalide, il est ignoré sans affecter le fonctionnement de l'automate.
Sur réception d'une Requête-Configuration, une réponse appropriée 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 ... +-+-+-+-+ |
Sur réception d'un paquet Configuration-Acquittée, le champ Identificateur DOIT correspondre en valeur à celui de la dernière Requête-Configuration reçue. De plus, la liste d'Options de Configuration d'un paquet Configuration-Acquittée DOIT correspondre en tous points à celle de la Requête-Configuration précédente. Des paquets invalides sont ignorés.
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 ... +-+-+-+-+ |
Le rejet d'Options sans champ de valeur (options booléennes) DOIT s'effectuer à l'aide de paquets Configuration-Rejetée.
A toute Option de Configuration dont une seule instance peut être présente DOIT être attribuée une valeur acceptable pour l'émetteur de l'accusé de réception. La valeur par défaut PEUT être utilisée, lorsque celle-ci est différente de la valeur requise par l'initiateur.
Pour toute Option de Configuration pouvant apparaître plusieurs fois avec des valeurs différentes, le paquet Configuration-NonAcquittée DOIT fournir une liste de toutes les valeurs acceptable par l'émetteur de l'acquittement. Cette liste inclura les valeurs acceptées présentes dans la requête.
Finalement, une implémentation peut être configurée pour requérir la négociation d'une Option de Configuration spécifique. Si cette option n'apparaît pas dans la requête, elle PEUT être ajoutée à la liste d'Options de Configuration dans l'accusé de réception, de sorte à inciter l'initiateur à spécifier cette option lors de l'émission de la Requête corrective suivante. Cette option DEVRA figurer avec toutes les valeurs acceptées par l'émetteur de l'accusé de réception.
Sur réception d'un paquet Configuration-NonAcquittée, le champ Identificateur DOIT contenir la même valeur que celle présente dans la dernière Requête-Configuration. Des paquets non valides seront ignorés.
Un paquet Configuration-NonAcquittée valide indique à son récepteur qu'une nouvelle Requête-Configuration est demandée, en indiquant les valeurs attendues et permises. Lorsqu'une Option de Configuration apparaît en plusieurs exemplaires dans l'accusé de réception, listant ainsi les valeurs permises, l'initiateur DEVRA en choisir une pour la constitution de la requête corrective suivante.
Certaines Options de Configuration sont de longueur variable. Comme l'option retournée par l'accusé a été modifiée entre temps par le distant, l'implémentation DOIT pouvoir traiter un retour d'Option de longueur différente à celle émise initialement dans la Requête-Configuration. Le format de ce paquet est exprimé ci-dessous. Les champs sont transmis de gauche à droite.
0 1 2 1000 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 ... +-+-+-+-+ |
Le champ d'Options est de longueur variable, et contient une liste de zéro ou plus Options de Configuration dont l'émetteur accuse réception. Toutes les Options de Configuration sont traitées en une fois.
L'identificateur du paquet Configuration-Rejetée, DOIT nécessairement correspondre à celui de la requête initiale. De plus, l'ensemble des Options de Configuration figurant dans un rejet DOIT être exclusivement un sous ensemble de ceux transmis dans la requête originatrice. Les paquets non valides sont ignorés.
Un paquet Configuration-Rejetée indique à son récepteur que dans toute requête ultérieure corrective NE DEVRA figurer AUCUNE des Options stipulées 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1000 -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Options ... +-+-+-+-+ |
Une implémentation désireuse de suspendre une connexion DEVRAIT transmettre un paquet Requête-Fermeture. Ces paquets DEVRAIENT être émis continuellement jusqu'à réception d'un paquet Fermeture-Acquittée, ou jusqu'à ce que la couche inférieure ait signalé sa désactivation, ou encore jusqu'à ce que le nombre de requêtes soit suffisant pour que le distant puisse être raisonnablement considéré comme déconnecté.
Sur réception d'une Requête-Fermeture, un paquet Fermeture-Acquittée DOIT être renvoyé.
La réception d'un paquet Fermeture-Acquittée sans sollicitation indique que le distant est dans un des états Fermé ou Arrêté, ou réclame une renégociation 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Données ... +-+-+-+-+ |
Sur réception, la valeur d'identification de la Requête-Fermeture est recopiée dans le champ d'identification du paquet Fermeture-Acquittée émis en réponse.
Sur réception d'un rejet d'un code émis et implémentant une fonction indispensable pour la version de protocole implémentée, l'implémentation DEVRAIT signaler le problème et avorter le processus de connexion, dans la mesure où il est fortement improbable que le problème 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é ... +-+-+-+-+-+-+-+-+ |
Sur réception d'un paquet Protocole-Rejeté, l'implémentation 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 Protocole-Rejeté reçus lorsque le LCP est dans tout autre état que le précédent doivent être ignorés.
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-Rejetée... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
Sur réception d'une Requête-Echo en état Ouvert, le LCP DOIT répondre par un paquet Réponse-Echo.
Les paquets Requête-Echo et Réponse-Echo ne DOIVENT être transmis que lorsque les LCP sont dans l'état Ouvert. Ces deux types de paquets, lorsqu'ils sont reçus dans tout autre état de l'automate, doivent être ignorés 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Données ... +-+-+-+-+ |
10 pour signifier Réponse-Echo.
En réception, l'identificateur d'une Requête-Echo sera copié dans la Réponse-Echo émise en retour.
Les paquets Requête-Elimination NE DOIVENT ETRE émis que par un LCP en l'état Ouvert. Sur réception, ces paquets doivent être ignorés par le récepteur.
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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Données ... +-+-+-+-+ |
Les Options de Configuration
du LCP permettent la négociation de certaines modifications des
valeurs par défaut des paramètres d'une liaison Point à
Point. Si une
Option de Configuration
n'est pas mentionnée dans une Requête-Configuration, on suppose
que c'est la valeur par défaut qui est requise pour cette Option.
Certaines Options de Configuration
PEUVENT apparaître plus d'une fois. Cette possibilité est
spécifique à certaines Options de Configuration, et est annoncée
dans
la description de chaque
Option de Configuration. (aucune des Options de Configuration décrites
dans ce document ne peut être mentionnée plus d'une fois).
La fin de la liste d'Options de Configuration peut être identifiée 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
spécifient les caractéristiques
attendues en réception du point de vue de l'émetteur de la
Requête.
Philosophie
Les options indiquent soit
la disponibilité soit la nécessité d'implémentation
de l'option demandée par la requête. Une implémentation
ne pouvant interpréter aucune
option DEVRAIT néanmoins
pouvoir fonctionner avec une autre qui les reconnaît toutes.
Des valeurs par défaut
sont spécifiées pour chacune des options, permettant ainsi
à la liaison de pouvoir s'établir sans aucune négociation,
mais peut être sur un
mode réduit ou non
optimisé.
Sauf mention explicite, l'acquittement des options n'impose pas au distant l'utilisation d'une autre valeur que celle par défaut.
Il n'est donc pas nécessaire d'émettre les options requises avec les valeurs par défaut dans une Requête-Configuration.
Un prototype du format général
des Options de Configuration est donné ci-dessous. Les champs sont
transmis de gauche à droite.
0 1000 ;
1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type |
Longueur | Données ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
Le champ Type est défini
sur un octet, et indique le type d'Option de Configuration. Ce document
liste quelques options de base établies à la construction
du
protocole. Les dernières
Options validées sont indiquées dans la RFC "Assigned Numbers"
[2]. Voici les valeurs initialement admises :
0
RESERVE
1
Unité-Réception-Maximale
3
Protocole-Authentification
4
Protocole-Qualité
5
1000 ;
Nombres-Magiques
7
Compression-Protocoles
8
Compression-Adresses-et-Contrôles
Longueur
Le champ Longueur est défini
sur un octet, et indique la longueur de l'Option de Configuration en comptant
l'octet de Type, la longueur elle-même et le champ de
Données.
Si une Option de Configuration
dans une Requête-Configuration porte un numéro valide, mais
spécifie une longueur erronée ou non interprétable,
un paquet
Configuration-NonAcquittée
DEVRAIT être transmis explicitant l'Option de Configuration demandée,
avec sa Longueur et ses Données régulières.
Données
Le champ de Données
peut transporter zéro ou un nombre quelconque d'octets, et contient
des informations spécifiques à l'Option de Configuration.
Le format et la
longueur du champs Données
est déterminé par calcul à l'aide du champ de Type
et de Longueur.
Lorsque la longueur mentionnée
semble prétendre que les données s'arrêtent 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é-Réception-Maximale (URM)
Description
Cette Option de Configuration
peut être utilisée pour informer le distant que cette implémentation
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 défaut
est de 1500 octets. Si des paquets plus courts sont demandés par
une implémentation, celle-ci DEVRA néanmoins rester capable
de recevoir
des paquets de 1500 octets
au cas ou la synchronisation de la ligne serait perdue. Note d'Implémentation
:
Cette option est utilisée
pour indiquer une performance de l'imp 1000 lémentation. Le distant
n'est pas tenu d'exploiter cette performance. Par exemple, lorsqu'une
implémentation 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 nécessairement
à
refuser la négociation
de l'option et peut librement émettre des paquets de 1500 octets,
dans la mesure où toute implémentation doit au moins accepter
des paquets
de cette taille.
Le format de l'Option de
Configuration Unité-Réception-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é-Réception-Maximum
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
1
Longueur
4
Unité-Réception-Maximum
Le champ Unité-Réception-Maximale
est codé sur deux octets, et spécifie 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 réseau.
Cette Option de Configuration
procure une méthode pour négocier l'usage d'un proto 1000
cole d'authentification spécifique. Par défaut, aucune authentification
n'est
demandée.
Une implémentation
NE DOIT PAS faire figurer plusieurs Options Protocole-Authentification
dans ses paquets de Requête-Configuration. Au lieu de cela, elle
DEVRAIT tenter de configurer
le protocole le plus "adéquat" en premier. Si ce protocole est rejeté
par la négociation, alors l'implémentation DEVRAIT tenter
de
négocier le protocole
suivant dans l'ordre de préférence dans un nouveau paquet
Requête-Configuration.
L'implémentation émettant
la Requête-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
spécifié dans la requête. Une implémentation
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 même
protocole soit utilisé dans les deux directions pour effectuer une
"reconnaissance" bilatérale.
Il est tout à fait acceptable que deux protocoles distincts soient
utilisés pour les deux sens d'authentification. Ceci dépendra
évidemment
du résultat de la
négociation.
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Données ...
+-+-+-+-+
Type
3
Longueur
>= 4
Protocole-Authentification
Le champ Protocole-Authentification
est décrit par deux octets, et indique le protocole d'authentification
désiré. Les valeurs de ce champ sont toujours les mêmes
que celles mentionnées
dans le champ de protocole PPP pour ce même protocole d'authentification.
Ce document liste quelques
valeurs de protocoles d'authentification établies à la construction
de ce protocole. Les derniers protocoles validés sont indiqués
dans la
RFC "Assigned Numbers" [2].
Voici les valeurs initialement admises :
Identificateur (hexa) de Protocole
c023 PAP (protocole d'identification par mot de passe)
c223 CHAP (protocole par échange de certificats)
Données
Le champ de donnée contient zéro ou un nombre quelconque d'octets, et contient des données additionnelles selon le protocole spécifié.
6.3. Protocole-Qualité
Description
Sur certaines liaisons, il
peut être souhaitable de déterminer quand, et dans quelle
proportion la liaison perd des données. Ce procédé
est appelé contrôle de qualité
de liaison.
Cette Option de Configuration
procure une méthode pour négocier l'usage d'un protocole
particulier pour le contrôle de qualité de liaison. Par défaut,
le contrôle de
qualité de liaison
est désactivé.
L'implémentation émettant
la Requête-Configuration indique qu'elle demande au distant de lui
envoyer des données pour tester la qualité de liaison. Si
un distant
acquitte cette option, alors
il déclare accepter l'usage de ce protocole. Une implémentation
recevant un acquittement pour cette option DEVRAIT attendre du distant
un échange sur le
protocole convenu.
Il n'y a aucune obligation
que le contrôle de qualité soit fait dans les deux sens, ni
que le même protocole soit utilisé dans les deux directions.
Il est tout à fait
acceptable que deux
protocoles distincts soient utilisés pour les deux sens de la mesure.
Ceci dépendra évidemment du résultat de la négociation.
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é
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Données ...
+-+-+-+-+
Type
4
Longueur
>= 4
Protocole-Qualité
Le Protocole-Qualité
est décrit sur deux octets, et indique le type de protocole de contrôle
de qualité demandé. Les valeurs de ce champ sont toujours
les mêmes
que celles mentionnées
dans le champ de protocole PPP pour ce même protocole de mesure.
Ce document liste quelques
valeurs de protocoles de contrôle établies à la construction
de ce protocole. Les derniers protocoles validés sont indiqués
dans la RFC
"Assigned Numbers" [2].
Voici les valeurs initialement admises :
Identificateur (hexa) de Protocole
c025 Link Quality Report
Données
Le champ de donnée contient zéro ou un nombre quelconque d'octets, et contient des données additionnelles selon le protocole spécifié.
6.4. Nombres-Magiques
Description
Cette Option de Configuration
procure une méthode pour détecter des liaisons rebouclées
et d'autres anomalies au niveau Liaison de Données. Cette Option
de
Configuration POURRA être
nécessaire selon la présence ou l'absence d'autres Options
de Configuration telles que l'option Protocole-Qualité. Par défaut,
l'option
Nombres-Magiques n'est pas
négociée, et la valeur zéro doit être utilisée
là où un Nombre-Magique aurait du être inscrit.
Avant de requérir
cette Option de Configuration, une implémentation DOIT choisir son
propre Nombre-Magique. Il est conseillé de choisir ce Nombre-Magique
de
la façon la plus
aléatoire possible de sorte qu'il puisse être garanti avec
une très forte probabilité que ce nombre soit unique pour
deux implémentation en contact. Un
bonne méthode pour
obtenir l'unicité de ce nombre est de prendre comme base de calcul
un nombre lui-même unique. Répondent à cette définition
les numéros de
série des machines,
ou d'autres adresses matérielles dans le réseau, des horloges
datées, etc. Des nombres présentant un bon facteur d'aléatoire
sont obtenus par
mesure précise du
temps entre deux événements tels que la réception
de paquets sur une autre connexion réseau, le temps de réponse
d'un serveur, ou la cadence
de frappe d'un utilisateur
humain. Il peut être aussi suggéré de combiner plusieurs
source aléatoires pour augmenter la probabilité d'unicité.
Lorsqu'une Requête-Configuration
précise une Option de Configuration Nombres-Magiques, le Nombre-Magique
reçu est comparé avec le Nombre-Magique de
la dernière requête
émise vers un distant. Si ces deux Nombres-Magiques sont distincts,
la ligne est considérée comme non bouclée, 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 rebouclée et que la requête
reçue est en
fait la dernière
émise. Pour s'assurer de cette éventualité, un paquet
Configuration-NonAcquittée DOIT être émis avec une
nouvelle valeur de Nombre-Magique.
Une nouvelle Requête-Configuration
NE DEVRAIT PAS être émise vers le distant tant qu'une réaction
normale n'est pas obtenue (c'est à dire, un paquet
Configuration-NonAcquittée est
reçu ou la temporisation de Reprise expire).
La réception d'un
paquet Configuration-NonAcquittée présentant un Nombre-Magique
différent de celui transmis dans le dernier paquet
Configuration-NonAcquittée
émise vers le distant prouve que la liaison n'est pas bouclée,
en éliminant le cas possible bien qu'improbable de Nombres-Magiques
égaux par pur hasard.
Si les deux Nombres-Magiques des paquets Configuration-NonAcquittée
sont égaux, la probabilité d'être en présence
d'une boucle
augmente, et un nouveau
Nombre-Magique DOIT être choisi. Dans les deux cas, une nouvelle
Requête-Configuration DEVRAIT être émise avec ce nouveau
Nombre-Magique.
Si la ligne est effectivement
en état rebouclé, cette séquence (transmission d'une
Requête-Configuration, réception d'une Requête-Configuration,
transmission d'un
Configuration-NonAcquittée,
réception d'un Configuration-NonAcquittée) se reproduira
encore et encore. Si la ligne n'était pas bouclée, au pire
cette séquence
pourrait se produire un
certain nombre (petit) de fois, mais aurait vraiment très peu de
chance de se répéter continuellement. Selon toute attente,
les
Nombres-Magiques choisis
des deux côtés de la liaison devraient rapidement diverger,
arrêtant ainsi cette séquence. La table suivante montre la
probabilité de
collisions en supposant
que les deux extrémités choisissent des Nombres-Magiques
selon une loi de distribution parfaitement uniforme :
Nombre de Collisions Probabilité
-------------------- ---------------------
1
1/2**32 = 2.3 E-10
2
1/2**32**2 = 5.4 E-20
&n 1000 bsp;
3
1/2**32**3 = 1.3 E-29
Pour que cette divergence
puisse survenir, il faut assurer un caractère aléatoire et
unique suffisant. Si une source présentant ces qualités intrinsèques
suffisantes ne
peut être trouvée,
il est conseillé de ne pas activer cette Option de Configuration;
Des Requête-Configuration ne DOIVENT PAS être émises
avec cette option et
toute Option de Configuration
Nombre-Magique émise par le distant DOIT être soit Acquittée
soit rejetée. Dans ce cas, l'implémentation n'a pas la possibilité
de
détecter avec suffisamment
d'assurance une situation de rebouclage, bien que cette dernière
puisse l'être par le distant.
Si une implémentation
émet effectivement une Requête-Configuration affichant une
Option de Configuration Nombres-Magiques, alors elle de DOIT PAS
répondre a une Requête-Configuration
distante avec la même option par un paquet Configuration-Rejetée.
En d'autres termes, si une implémentation désire
utiliser l'option Nombres-Magiques,
alors elle DOIT alors accepter que le distant en fasse de même. Si
une implémentation reçoit un paquet Configuration-Rejetée
en réponse à
une Requête-Configuration, cela signifiera seulement que le lien
n'est pas rebouclé, et que le distant ne désira pas utiliser
les Nombres-Magiques.
Dans ce cas, une implémentation
DEVRAIT réagir comme si la négociation avait abouti (comme
si une Configuration-Acquittée avait été reçue
à la place).
Le Nombre-Magique peut aussi
être utilisé pour détecter un rebouclage de ligne pendant
une phase de fonctionnement normale, en plus d'une phase de négociation
d'options. Tous les paquets
LCP Requête-Echo, Réponse-Echo, et Requête-Elimination
ont un champ Nombre-Magique. Si les Nombres-Magiques ont été
négociés avec
sucés, une implémentation DOIT transmettre ces paquets avec
le Nombre-Magique négocié.
Le champ Nombre-Magique de
ces paquets DEVRAIT être testé sur réception. Tous
les champs Nombres-Magiques reçus DOIVENT avoir une valeur soit
nulle
soit égale au Nombre-Magique
unique défini pour le distant, suivant le résultat de la
négociation de cette option entre les deux entités.
La réception d'un
champ Nombre-Magique de valeur égale au Nombre-Magique défini
par l'implémentation locale signifie la possibilité d'une
liaison rebouclée. La
réception d'un Nombre-Magique de valeur différente
que celle négociée comme local, ou de la valeur distante,
ou nulle si des valeurs n'ont pas été négociées,
indique que la liaison a
été mal configurée.
Les procédures pour
se récupérer de l'un ou l'autre cas de figure ne sont pas
précisées, et peuvent varier d'une implémentation
à l'autre. Une méthode quelque peu
pessimiste est d'assimiler
ces situations à un événement Down du LCP. Une réouverture
relancera le processus pour négocier 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 négociés.
Une méthode
plus optimiste (dans le
cas d'un lien en boucle) est d'entamer la transmission de paquets Requête-Echo
LCP jusqu'à ce que soit reçu un paquet Réponse-Echo
conforme, indiquant de ce
fait la fin d'une telle situation.
Le format pour l'Option de
Configuration Nombres-Magiques est donnée 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) |
+-+-+-+- 1000 +-+-+-+-+-+-+-+-+-+-+-+-+
Type
5
Longueur
6
Nombres-Magiques
Le champ Nombres-Magiques
est décrit sur quatre octets, et donne un nombre supposé
être unique vis à vis de l'autre extrémité.
Une valeur nulle est illégale et
DOIT être refusée,
si l'Option Nombres-Magiques n'est pas elle-même rejetée.
6.5. Compression-Champ-Protocole (PFC)
Description
Cette Option de Configuration
procure une méthode pour négocier la compression du champ
Protocole PPP. Par défaut, toutes les implémentations 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
exprimées sous une forme réduite d'un octet, et de façon
tout à
fait univoque par rapport
à leur expression en deux octets. Cette Option de Configuration
est envoyée pour informer le distant que le local accepte des valeurs
de
Protocole compressées
sur un octet.
Comme indiqué précédemment,
le champ Protocole utilise un mécanisme d'extension conforme à
au mécanisme 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 placés
avant le champ, indiquant toujours la même valeur (considérez
les deux représentations pour la valeur 3, 00000011 et 00000000
00000011).
Sur des liaisons à
bas débit, il est souhaitable de préserver la bande passante
utile en envoyant le moins de données redondantes ou non significatives
possible.
L'Option de Configuration
Compression-Champ-Protocole permet de privilégier tantôt simplicité
d'implémentation, tantôt optimisation de la bande utile. Si
la
négociation se déroule
avec sucés, le mécanisme 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 compressés dans la mesure
où la plupart des valeurs de protocoles utilisées sont inférieures
à 256.
Des champs Protocoles ne
doivent JAMAIS être compressés sauf si cette Option 1000 de
Configuration a été négociée. Une fois cette
option négociée, les
implémentations 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 règle garantit une reconnaissance univoque des paquets LCP.
Lorsqu'un champ Protocole
est compressé, le champ FCS de la couche données (Data Link
Layer) est calculé sur la trame compressée, 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-Contrôles (ACFC)
Description
Cette Option de Configuration
procure une méthode pour négocier la compression des champs
d'Adresse et Contrôles de la couche de données (Data Link
Layer).
Par défaut, toutes
les implémentations DOIVENT transmettre des trames avec des champs
Adresse et Contrôles appropriés à la définition
de la trame
correspondante.
Dans la mesur 1000 e où
ces données ont souvent des valeurs statiques pour des liaisons
point-à-point, il est possible sans risque de les compresser. Cette
Option de
Configuration est envoyée
pour informer le distant que l'implémentation locale peut recevoir
des champs Adresse et Contrôles compressés. Si une trame compressée
est reçue alors que
cette option n'a pas été négociée, ces trames
devront être ignorées.
Les champs Adresse et Contrôle
NE DOIVENT PAS être compressés dans des paquets LCP. Cette
règle permet d'assurer une reconnaissance univoque des
paquets LCP. Lorsque les
champs Adresse et Contrôle sont compressés, le champ FCS de
la couche de données (Data Link Layer) est calculé sur la
trame
compressée et non
sur la trame originale.
Le format de L'Option de Configuration Compression-Adresse-et-Contrôle 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] Reynolds, J., and Postel, J., "Assigned Numbers", STD 2, RFC 1340, USC/Information Sciences Institute, July 1992.
La majeure partie de ce texte a été tirée des spécifications 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 conséquente; on lui doit le nouveau design des phases et états de négociation.
De nombreuses personnes ont contribué à la mise au point du Protocole Point-à-Point. La liste complète 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 matérielle et ses accès réseau ayant permis l'établissement de cette spécification.
Fred Baker
Advanced Computer Communications
315 Bollay Drive
Santa Barbara, California
93117
fbaker@acc.com
Toute question technique sur ce mémo peut être envoyée à :
William Allen Simpson
Daydreamer
Computer Systems Consulting
Services
1384 Fontaine
Madison Heights, Michigan
48071
Bill.Simpson@um.cc.umich.edu
bsimpson@MorningStar.com0