| We need Your Support. Make a Donation now! or |  |
Groupe de travail Réseau |
W. Simpson, Daydreamer |
Request for Comments : 1973 |
juin 1996 |
Catégorie : En cours de normalisation |
Traduction Claude Brière de L’Isle |
Statut du présent mémoire
Le présent document spécifie un protocole en cours de normalisation de l’Internet pour la communauté de l’Internet, et appelle à des discussion et suggestions pour son amélioration. Prière de se référer à l’édition en cours des "Normes officielles des protocoles de l’Internet" (STD 1) pour connaître l’état de la normalisation et le statut de ce protocole. La distribution du présent mémoire n’est soumise à aucune restriction.
Résumé
Le protocole point à point (PPP) [1] fournit une méthode standard pour transporter des datagrammes multi-protocoles sur des liaisons point à point.
Le présent document décrit l’utilisation du relais de trame pour le tramage des paquets encapsulés en PPP.
Applicabilité
La présente spécification est destinée aux mises en œuvre qui désirent utiliser les facilités qui sont définies pour PPP, telles que le protocole de commande de liaison, les protocole de commande de couche réseau, l’authentification, et la compression. Ces capacités exigent une relation point à point entre des homologues, et ne sont pas conçues pour des environnements multipoints ou multi-accès.
Table des matières
1. Introduction
2. Exigences de la couche physique
3. Couche de liaison des données
3.1 Format de trame
3.2 Modification de la trame de base
4. Démultiplexage de protocole dans la bande
5. Signalisation hors bande
6. Détails de configuration
Considérations pour la sécurité
Références
Remerciements
Adresse du président
Adresse de l’auteur
Le relais de trame [2] est un nouveau venu relatif par rapport à la communauté des liaisons en série. Comme X.25, le protocole a été conçu pour fournir des circuits virtuels aux connexions entre les stations rattachées au même réseau de relais de trame. L’amélioration par rapport à X.25 est que Q.922 se restreint à la livraison des paquets, et se dispense du séquençage et du contrôle du flux, simplifiant immensément le service.
PPP utilise le HDLC de la norme ISO 3309 comme base de son tramage [3].
Lorsque le relais de trame est configuré comme circuit point à point, PPP peut utiliser le relais de trame comme mécanisme de mise en trame, en ignorant ses autres caractéristiques. Ceci est équivalent à la technique utilisée pour transporter les en-têtes SNAP en relais de trame [4].
À un moment, il avait été espéré que PPP dans les trames de type HDLC et le relais de trames pourraient coexister sur les mêmes liaisons. Malheureusement, la méthode Q.922 pour développer l’adresse de 1 à 2 à 4 octets n’est pas sans différences avec la méthodes de la norme ISO 3309, du fait de la structure de ses sous-champs d’identifiant de connexion de liaison de données (DLCI, Data Link Connection Identifier). La coexistence est empêchée.
PPP traite la mise en trame du relais de trame comme celle d’une liaison à synchronisation binaire. La liaison DOIT être bidirectionnelle, mais PEUT être dédiée (permanente) ou commutée.
Format d’interface
PPP présente une interface d’octet à la couche physique. Il n’y a pas de disposition pour la fourniture ou l’acceptation de sous octets.
Débit de transmission
PPP n’impose aucune restriction au débit de transmission, autre que celles de l’interface de relais de trame particulière.
Signaux de contrôle
La mise en œuvre du relais de trame exige la fourniture de signaux de contrôle, qui indiquent quand la liaison est connectée ou déconnectée. Ils fournissent à leur tour les événements Up et Down à l’automate à état LCP.
Parce que PPP n’exige normalement pas l’utilisation de signaux de contrôle, l’échec de tels signaux NE DOIT PAS affecter le fonctionnement correct de PPP. les implications en sont exposées en [2].
Codage
La définition des divers codages est le la responsabilité de l’équipement de DTE/DCE utilisé, et sort du domaine d’application de la présente spécification.
Alors que PPP fonctionne sans considération de la représentation sous-jacente du flux binaire, le relais de trame exige le codage NRZ.
La présente spécification utilise les principes, la terminologie, et la structure de trame décrits dans "Interconnexion multi protocoles sur relais de trame" [4].
L’objet de la présente spécification n’est pas de documenter ce qui a déjà été normalisé dans [4]. Le présent document essaye plutôt de faire un résumé concis et de souligner les options et caractéristiques spécifiques utilisées par PPP.
Comme décrit dans [4], les champs d’adresse et de contrôle de l’en-tête Q.922 sont combinés avec l’identifiant de protocole de couche réseau (NLPID), qui identifie l’encapsulation qui suit. 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 |
||||||||||
Fanion (0x7e) |
|||||||||||||||||||||||||||||||||||||||||
Adresse Q.922 |
Contrôle |
NLPID (0xcf) |
|||||||||||||||||||||||||||||||||||||||
Protocole PPP |
|||||||||||||||||||||||||||||||||||||||||
Le champ protocole PPP et les champs qui le suivent d’Information et de Bourrage sont décrits dans l’encapsulation du protocole point à point [1].
Le protocole de contrôle de liaison peut négocier des modifications de la structure de base de la trame. Cependant, les trames modifiées seront toujours clairement distinctes des trames standard.
Compression de champ d’adresse et de contrôle
Parce que les valeurs de champ d’adresse et de contrôle ne sont pas constantes, et sont modifiées lorsque la trame est transportée par système de commutation du réseau, la compression de champ d’adresse et de contrôle NE DOIT PAS être négociée.
Compression du champ de protocole
Noter qu’à la différence de PPP dans le tramage de type HDLC, le tramage de relais de trame n’aligne pas le champ Information sur une limite de 32 bits. L’alignement sur une frontière de 32 bits survient lorsque le NLPID est retiré et que le champ Protocole est compressé en un seul octet. Lorsque ceci améliore le débit, la compression du champ Protocole DEVRAIT être négociée.
Les champs NLPID (CF hex) et Protocole de PPP distinguent facilement l’encapsulation PPP des autres encapsulations de NPLID décrites en [4].
La jonction des espaces de numérotation de PPP et du NLPID a un avantage supplémentaire, en ce que le Protocol-Reject (rejet de protocole) LCP peut être utilisé pour indiquer les NLPID qui ne sont pas reconnus. Cela peut éliminer les "trous noirs" qui surviennent lorsque du trafic n’est pas pris en charge.
Pour les protocoles de couche réseau qui n’ont pas d’allocation de protocole PPP, ou qui n’ont pas encore été mis en œuvre avec l’encapsulation PPP, ou qui n’ont pas réussi à être négociés par un NCP PPP, une autre méthode d’encapsulation définis en [4] DEVRAIT être utilisée.
Actuellement, il n’y a pas de conflit entre les valeurs du NLPID et du Protocole PPP. Si une mise en œuvre future est configurée pour envoyer une valeur de NLPID qui serait la même qu’un champ Protocole compressé, ce champ Protocole NE DOIT PAS être envoyé compressé.
À réception, le premier octet suivant l’en-tête est examiné. Si l’octet est zéro, il DOIT être supposé que le paquet est formaté conformément à [4].
Les paquets encapsulés en PPP ont toujours un octet non zéro qui suit l’en-tête. Si l’octet n’est pas la valeur du NLPID (CF hex) PPP, et si la Compression de champ Protocole est activée, et si le NCP associé a été négocié, on s’attend alors à ce que ce soit une valeur Protocole PPP compressé. Autrement, on DOIT supposer que le paquet est formaté conformément à [4].
La valeur 0x00cf du champ Protocole n’est pas permise (réservée) pour éviter des ambiguïtés lorsque Compression du champ Protocole est activé. La valeur PEUT être traitée comme un Protocole PPP qui indique qu’un autre paquet Protocole PPP suit.
Les paquets LCP initiaux contiennent la séquence cf-c0-21 à la suite de l’en-tête. Lorsqu’un paquet LCP Demande de configuration est reçu et reconnu, la liaison PPP entre dans la phase Établissement de liaison.
La connexion accidentelle d’une liaison pour alimenter un réseau multipoint (ou un groupe de diffusion groupée) DEVRAIT résulter en une indication de mauvaise configuration. Ceci peut être détecté par plusieurs réponses à la Demande de configuration LCP avec le même identifiant, venant de différentes adresses de tramage. Certaines mises en œuvre peuvent être physiquement incapables d’enregistrer ou rapporter de telles informations.
Une fois que PPP est entré dans la phase Établissement de liaison, les paquets avec d’autres valeurs de NLPID NE DOIVENT PAS être envoyées, et à réception de tels paquets DOIVENT être éliminés en silence, jusqu’à ce que la liaison PPP entre dans la phase Protocole de couche réseau.
Une fois que PPP est entré dans la phase Protocole de couche réseau, et a négocié avec succès un NCP particulier pour un protocole PPP, si une trame arrive en utilisant une autre encapsulation de données équivalente définie dans [4], la liaison PPP DOIT revenir à la phase Établissement de liaison et envoyer une nouvelle Demande de configuration LCP. Ceci empêche les "trous noirs" qui surviennent lorsque l’homologue perd l’état.
Une mise en œuvre qui exige une configuration de liaison PPP, et d’autres caractéristiques PPP négociées (telles que l’authentification) PEUT entrer dans la phase Terminaison lorsque la configuration échoue. Autrement, lorsque l’envoyeur de la Demande de configuration atteint la limite Max-Configure, il DOIT revenir à l’envoi des seules trames encapsulées conformément à [4].
Il n’y a pas de méthode généralement acceptée de signalisation hors bande. Jusqu’à ce qu’une telle méthode soit universellement disponible, une mise en œuvre DOIT utiliser le démultiplexage de protocole dans la bande aussi bien pour les circuits virtuels permanents que commutés.
Les options de configuration suivantes sont recommandées :
Nombre magique
Compression du champ Protocole
La configuration LCP standard par défaut s’applique aux liaisons en relais de trame, excepté l’unité de réception maximum (MRU, Maximum-Receive-Unit).
Pour assurer l’interopérabilité avec les mises en œuvre existantes de relais de trame, le MRU initial est de 1600 octets [4]. Cela n’affecte que l’espace minimum de mémoire tampon exigée disponible pour recevoir les paquets, et non la taille des paquets envoyés.
Le réseau qui aliment normalement la liaison va vraisemblablement avoir une MRU de 1500, ou 2048 ou supérieure. Pour éviter la fragmentation, l’unité de transmission maximum (MTU, Maximum-Transmission-Unit) à la couche réseau NE DEVRAIT PAS excéder 1500, sauf si une MRU d’homologue de 2048 ou plus est spécifiquement négociée.
Certains commutateurs de relais de trame ne sont capables d’accepter que des trames de 262 octets. Il n’est pas recommandé à quiconque de mettre en place ou utiliser un commutateur dont la capacité serait inférieure à 1600 octets de trame. Cependant, les mises en œuvre de PPP DOIVENT pouvoir par configuration limiter la taille des paquets LCP qui sont envoyés à 259 octets (ce qui laisse de la place pour les champs NLPID et Protocole), jusqu’à ce que la négociation LCP soit achevée.
Il n’est pas exigé que la négociation XID soit prise en charge pour les liaisons qui sont capables d’effectuer la négociation PPP.
La prise en charge de l’ARP inverse n’est pas exigée pour les liaisons PPP. Cette fonction est fournie par la négociation NCP de PPP.
Les questions de sécurité ne sont pas abordées dans le présent mémoire.
[1] W. Simpson, éditeur, "Protocole point à point (PPP)", STD 51, RFC 1661, juillet 1994.
[2] Recommandation CCITT Q.922, "Spécification de la couche de liaison des données RNIS pour les services support en mode trame", Comité international télégraphique et téléphonique, 1992.
[3] W. Simpson, éditeur, "PPP dans un tramage similaire à HDLC", STD 51, RFC 1662, juillet 1994.
[4] T. Bradley, C. Brown et A. Malis, "Interconnexion multi protocoles en relais de trame", RFC 1490, juillet 1993. (Rendue obsolète par la RFC 2427, STD 55.)
[5] ISO/CEI TR 9577:1990(E), "Technologies de l’information – Échanges de télécommunications et d’informations entre les systèmes - Identification de protocole dans la couche réseau", 15 octobre 1995.
Ce concept a été inspiré par l’article "Parameter Negotiation for the Multiprotocol Interconnect", Keith Sklower et Clifford Frost, University of California, Berkeley, 1992, non publié.
Le groupe de travail peut être contacté via le président actuel :
Karl Fox
Ascend Communications
3518 Riverside Drive, Suite 101
Columbus, Ohio 43221
mél : karl@ascend.com
Les questions sur le présent mémoire peuvent aussi être adressées à :
William Allen Simpson
Daydreamer
Computer Systems Consulting Services
1384 Fontaine
Madison Heights, Michigan 48071
wsimpson@UMich.edu
wsimpson@GreenDragon.com (préferée)