Résumé

  • Un identifiant de partie appelée pouvait sélectionner PPP sur un accès ISDN partagé, mais cette indication provenait du commutateur local et n’ouvrait pas le service.
  • Sans événement administratif Open dans LCP, RFC 1618 imposait de rejeter l’appel ; accepter puis raccrocher ou ignorer les paquets était interdit.
  • Après l’admission restaient d’autres preuves : codage, tramage, disponibilité physique, négociation LCP, authentification, NCP et résultat applicatif.

Le bon numéro ne valait pas consentement

Publié en mai 1994, RFC 1618 cherchait des points d’accord pour transporter PPP sur des circuits ISDN commutés. Son texte écartait d’emblée l’idée d’un ISDN mondial et monolithique. Les commutateurs, abonnements et équipements formaient un paysage trop varié ; le document choisissait donc quelques comportements communs sans prétendre uniformiser toutes les installations.

Un canal B constituait le support point à point naturel. Une interface PRI pouvait en offrir plusieurs simultanément. Le canal D pouvait parfois transporter PPP avec le bon tramage, mais sa capacité était réduite et sa portée souvent limitée au commutateur local. Ces propriétés décrivaient le support disponible, pas la volonté du terminal de rendre chaque service accessible.

Le même accès physique pouvait recevoir plusieurs numéros. L’administrateur associait chacun à un service, et l’identifiant de partie appelée fourni par le commutateur local permettait de choisir le traitement correspondant. L’information répondait à « quel numéro a été composé ? ». Elle ne répondait ni à « qui appelle ? » ni à « ce service est-il autorisé maintenant ? ».

Une signalisation trop fragile pour fixer le tramage

Un autre champ semblait offrir davantage de sens : le LLC Information Element. Il aurait pu annoncer hors bande le protocole, le codage ou le tramage avant tout échange PPP. L’expérience citée par RFC 1618 conduisait à la conclusion inverse. L’élément ne traversait pas la chaîne de commutation de manière assez fiable ; les commutateurs compatibles étaient trop peu répandus et les politiques d’abonnement des fournisseurs trop différentes.

Aucune valeur LLC-IE n’était alors attribuée à PPP. Une autre valeur reçue n’était pas une description valable du service PPP et pouvait être ignorée. Surtout, le champ ne devait pas déterminer le codage ni le tramage.

La limite est architecturale. Un signal hors bande n’est commun que si chaque intermédiaire conserve sa présence, sa portée et sa signification. La variété des fournisseurs ne pouvait pas être effacée par un octet plus ambitieux. RFC 1618 préférait une information locale, plus pauvre mais mieux située, puis une décision du terminal.

Open appartenait à l’administrateur

Le cœur du mécanisme tient en une règle brève. Si le récepteur utilisait l’identifiant de partie appelée — ou recevait un jour une valeur LLC propre à PPP — alors que LCP n’avait pas reçu son événement administratif Open, l’appel devait être rejeté. Il ne fallait pas accepter le circuit pour le fermer aussitôt ou laisser ses paquets sans réponse.

RFC 1548, contemporain de ce texte, puis RFC 1661, définissent l’événement. Open signifie qu’un administrateur, humain ou programme, déclare la liaison autorisée à s’ouvrir. Up vient de la couche inférieure et indique sa disponibilité. Opened est un état ultérieur de l’automate LCP, atteint après l’échange de configuration.

Trois mots proches appartiennent ainsi à trois preuves. Un circuit peut être présenté par le commutateur sans autorisation locale. Un service peut être autorisé alors que le support reste indisponible. Le support et l’autorisation peuvent être présents sans que les deux pairs aient conclu leur négociation. Un voyant unique appelé « ouvert » supprimerait précisément les frontières utiles au diagnostic.

Le refus précoce avait aussi une valeur économique. Accepter un circuit commuté consommait une ressource avant de révéler que le service était fermé. Un silence tardif transformait une décision volontaire en panne ambiguë : mauvais tramage, pair absent, perte de paquets ou politique ? En refusant à l’entrée, le terminal rattachait la conséquence à l’autorité qui l’avait décidée.

Détecter revenait à essayer

Une fois le service autorisé, l’incertitude ne disparaissait pas. Pour PPP, le canal ISDN était une liaison synchrone en duplex intégral ; le codage et le brouillage relevaient cependant des équipements DTE/DCE, hors du champ propre de PPP. RFC 1618 recommandait NRZ par défaut au point T, proposait NRZI comme alternative configurée et déconseillait l’ancien NRZ inversé.

Pour reconnaître plusieurs codages simples, le seul procédé jugé fiable consistait à changer de mode. Le terminal envoyait deux fois une LCP Configure-Request dans un mode, attendait une réponse, puis passait au suivant. L’ensemble des essais devait cesser avant 59 secondes, et la limite habituelle de 30 secondes était préférable.

Ce n’était pas une découverte gratuite. Chaque essai occupait un canal et pouvait avoir un coût. La rotation avait donc un ordre, un compteur et une fin. Une absence de réponse ne révélait pas immédiatement sa cause ; elle autorisait seulement l’essai suivant dans une fenêtre bornée.

Le tramage avait sa propre base commune. Sans configuration préalable, le canal B commençait en HDLC bit-synchrone. Le HDLC octet-synchrone convenait lorsque les limites d’octets étaient disponibles et explicitement configurées. Le fait que HDLC, LAPB, LAPD et LAPF soient théoriquement reconnaissables n’autorisait pas leur emploi simultané sur le même canal.

Le texte déconseillait V.120 pour cet usage, car son tramage pouvait être difficile à distinguer de Frame Relay, et recommandait plutôt de transporter PPP dans Frame Relay. Cette préférence fixait un choix d’interopérabilité ; elle ne prouvait l’emploi d’aucune des deux méthodes sur un appel donné.

Le document compagnon RFC 1549 reliait le choix NRZI à une moindre capacité de détection pour le FCS 16 bits et recommandait alors de négocier un FCS 32 bits. La présence du circuit ne certifiait donc ni une représentation commune des bits ni une protection commune contre les erreurs.

Empêcher la demande de se reproduire elle-même

RFC 1618 recommandait une MTU de couche réseau au plus égale à 1 500, sauf négociation explicite avec le pair d’une MRU d’au moins 2 048. Il préconisait aussi un temporisateur de reprise exponentiel, de 250 millisecondes à trois secondes. Les fonctions de numérotation persistante ou de rappel devaient être limitées. Après un échec d’établissement, l’équipement pouvait vider la file d’émission ; cette opération supprimait temporairement le paquet qui relançait sans cesse l’appel.

La boucle est simple : une application met un paquet en attente, le paquet déclenche la communication, la liaison échoue, puis le même paquet déclenche une nouvelle tentative. Sans propriétaire de la limite et sans trace de la suppression, une demande unique devient une consommation répétée du réseau commuté.

RFC 1618 préférait aussi la procédure PPP Multilink à BONDING, dont la propre initialisation pouvait brouiller la détection. RFC 1990 décrivit ensuite l’agrégation logicielle de plusieurs canaux ISDN pour obtenir de la capacité à la demande. Mais même plusieurs supports disponibles ne formaient un bundle qu’après une option LCP acceptée.

Une admission n’était que le premier reçu

Après l’acceptation, le codage et le tramage devaient produire des trames valides. La couche inférieure passait à Up. LCP négociait jusqu’à Opened. Une authentification choisie devait réussir, puis chaque protocole réseau ouvrait son NCP. Enfin seulement les datagrammes correspondants pouvaient circuler ; leur circulation ne garantissait toujours pas le résultat de l’application.

Le registre RFC Editor établit la date, l’auteur et le statut Proposed Standard actuel. Il n’établit ni déploiement, ni comportement de produit, ni pratique contemporaine. La section sécurité de RFC 1618 ne traite pas la sécurité : l’identifiant appelé ne doit donc jamais devenir une preuve d’identité du correspondant.

La primauté du code en fonctionnement de Heng Lu aide à lire cette limite : un numéro et un état déclaré sont des entrées ; le refus réel, la négociation et l’effet observé sont d’autres couches de réalité. Sa spécification initiale minimale éclaire le choix de règles communes étroites, laissant l’admission au responsable local.

Le commutateur pouvait nommer le service demandé. Il ne pouvait pas parler à la place de l’administrateur du terminal. RFC 1618 plaça donc le « non » avant le circuit accepté, là où il restait visible, réversible et attribuable.

Sources