Résumé

  • Le RFC 1294, document Standards Track de janvier 1992, décrit une encapsulation multiprotocole pour le routage et le pontage sur Frame Relay. Il exige de savoir à l’avance quelles méthodes d’encapsulation sont portées par quels circuits virtuels et limite la méthode à des VC explicitement configurés.
  • NLPID et SNAP indiquent au récepteur comment lire la PDU d’une trame donnée. Cette indication ne prouve ni la configuration du VC, ni l’accord des extrémités, ni l’acceptation, le pontage, le routage ou la livraison de la trame.

Le point décisif du RFC 1294 — Multiprotocol Interconnect over Frame Relay se trouve avant toute liste de champs : une méthode d’encapsulation ne peut être placée sur un circuit virtuel simplement parce que l’équipement sait la décoder. La compréhension d’une trame et le droit de l’utiliser sur un VC sont deux faits différents.

Dans la trame, le RFC donne au récepteur des moyens d’interprétation. Tous les protocoles prennent place dans une trame Q.922 Annex A. Le NLPID peut signaler un protocole directement, ou annoncer que suit un en-tête SNAP. Lorsque le protocole n’a pas de NLPID propre, la forme routée emploie NLPID 0x80, l’OUI 00-00-00 et un EtherType. Pour IP, le RFC indique aussi NLPID 0xCC. La station doit savoir accepter les deux formes routées.

Cette obligation concerne la grammaire du paquet reçu. Elle ne dit pas que n’importe quel circuit devient un support interchangeable pour les deux formes. L’abstract garde le second registre séparé : la correspondance entre VC et méthode doit être connue à l’avance, et l’encapsulation ne doit être employée que sur des circuits explicitement configurés. Une étiquette de décodage n’est pas une décision de configuration.

Le DLCI ne racontait pas toute la relation

Un groupe Frame Relay peut être complètement maillé ou seulement partiellement relié. Chaque circuit virtuel a, à chaque interface, un Data Link Connection Identifier. Le RFC précise que les DLCI ont, dans la plupart des cas, une signification strictement locale. Cela rend le numéro utile sans lui attribuer plus qu’il ne porte.

Le DLCI peut identifier la connexion virtuelle telle qu’elle est vue à une interface. Il ne fournit pas une identité portable du circuit, le nom d’un pair, le choix de l’encapsulation ou la preuve d’un état opérationnel. Le document explique plus loin que le réseau peut modifier le DLCI pendant le transit : le destinataire voit le numéro qui correspond localement à l’expéditeur. Le même trajet n’est donc pas une chaîne immuable de nombres identiques.

Cette limite protège l’enquête technique. Un relevé contenant un DLCI peut établir qu’une trame a été observée sur une interface donnée. Il ne suffit pas à établir le paramétrage du VC, l’accord des deux extrémités ou le résultat du traitement. La description doit conserver l’interface, l’heure et la configuration en vigueur plutôt que de faire du nombre une politique complète.

Lire une PDU n’assignait pas le circuit

Le champ de contrôle vaut normalement UI 0x03, sauf négociation différente. Les octets de bourrage servent à l’alignement et doivent être nuls. Le RFC refuse NLPID 0x00 dans cette encapsulation : il ne se distingue pas du bourrage et ne possède pas de signification utile dans ce contexte. Une étiquette ne devient utile qu’à la condition de pouvoir être distinguée de la structure qui l’entoure.

NLPID et SNAP répondent ainsi à une question limitée : « quelle procédure de réception convient à cette PDU ? » Ils ne répondent pas à « qui a autorisé cette méthode sur ce VC ? », « les extrémités sont-elles actuellement configurées de la même façon ? » ou « la procédure a-t-elle produit un résultat ? ». Le RFC rend ces questions séparables, ce qui est plus rigoureux qu’une affirmation générale de compatibilité.

Pour les trames pontées, NLPID 0x80 annonce SNAP, l’OUI 00-80-C2 renvoie à 802.1 et le PID indique la forme d’en-tête MAC ainsi que la conservation éventuelle du FCS d’origine. Là encore, la valeur classe une trame. Elle ne certifie ni l’authenticité de la trame d’origine, ni un transfert vers un LAN, ni l’état de la politique qui devait autoriser cette encapsulation.

XID avait une portée nommée

Le RFC décrit aussi l’Exchange Identification facultatif au démarrage du circuit. XID peut négocier N201, T200 et K. Sans cet échange, ces valeurs doivent être configurées statiquement d’un commun accord entre les extrémités DLC, ou suivre les valeurs par défaut de Q.922. Une station qui prend en charge XID et reçoit une trame XID doit répondre ; si le maximum distant est inférieur, elle réduit la taille qu’elle emploie sur ce DLC avant sa réponse.

Cette séquence montre ce qu’est une portée explicite. XID ne négocie pas tout ce qui peut être dit d’un VC : il concerne certains paramètres de liaison. Sa présence ne remplace ni l’assignation préalable de l’encapsulation, ni une preuve de transmission ultérieure. Son absence ne fait pas disparaître les paramètres ; elle déplace leur base vers un accord statique ou des valeurs par défaut. Chaque mécanisme conserve son objet.

Une chaîne de preuves vaut mieux qu’un champ rassurant

Une analyse fidèle distinguerait le DLCI local, l’assignation VC-encapsulation, l’éventuel XID ou accord statique, les octets de la trame Q.922, le décodage NLPID/SNAP, l’action du récepteur et tout résultat de niveau supérieur. Un champ correct peut soutenir une affirmation précise sur la forme de la PDU. Il ne ferme pas la chaîne.

Dire « la trame annonçait IP » est différent de dire « le circuit était configuré pour cette encapsulation ». Dire « l’en-tête indiquait un pontage Ethernet » est différent de dire « le pont a acheminé Ethernet ». Dire « XID a été échangé » est différent de dire « le service était disponible ». Le RFC 1294 aide à produire ces phrases étroites et vérifiables ; il ne permet pas de les fondre en un verdict de bon fonctionnement.

Sources et limites de preuve

La source est RFC 1294 — Multiprotocol Interconnect over Frame Relay. Elle établit le statut de janvier 1992, l’exigence de configuration explicite, le caractère local du DLCI, les formes Q.922/NLPID/SNAP, la distinction routage/pontage et la portée de XID. Elle n’établit pas un VC actuel, un opérateur, une configuration effective, une identité distante, une propriété de sécurité, un traitement réussi, une livraison ou un service.