Transmission de IP et ARP sur des réseaux FDDI

Statut du présent mémoire

La présente RFC spécifie un protocole en cours de normalisation par l’IAB pour la communauté de l’Internet, et appelle à des discussions et suggestions pour son amélioration. Prière de se reporter à l’édition en cours des "Normes officielles des protocoles de l’IAB" pour connaître l’état de normalisation et le statut de ce protocole. La distribution du présent mémoire n’est soumise à aucune restriction.

Résumé

Le présent mémoire définit une méthode pour l’encapsulation des datagrammes du protocole Internet (IP) et des demandes et réponses du protocole de résolution d’adresse (ARP, Address Resolution Protocol) sur les réseaux à interface de données avec distribution par fibre optique (FDDI, Fiber Distributed Data Interface).

Cette RFC a été produite par le groupe de travail IP sur FDDI de l’Internet Engineering Task Force (IETF).

Remerciements

Le présent mémoire tire beaucoup de ses concepts et de son texte de la RFC 1042 [3], écrite par Jon Postel et Joyce K. Reynolds du USC/Information Sciences Institute. Les auteurs tiennent aussi à remercier pour leurs contributions les membres du groupe de travail IP sur FDDI de l’IETF, les membres du groupe de travail ANSI ASC X3T9.5, et d’autres de la communauté FDDI.

Conventions

Les conventions de langage suivantes sont utilisées dans les éléments de spécification du présent document :

"Doit," "Devra," ou "Obligatoire"—l’élément est une exigence absolue de la spécification.

"Devrait" ou "Recommandé"—l’élément devrait généralement être suivi sauf circonstances exceptionnelles.

"Peut" ou "Facultatif"—l’élément est vraiment facultatif et peut être suivi ou ignoré selon les besoins de la mise en œuvre.

Introduction

Le but de la présente spécification est de permettre des mises en œuvre compatibles et interopérables pour la transmission des datagrammes IP [1] et des demandes et réponses ARP [2].

Les spécifications de l’interface de données avec distribution par fibre optique (FDDI) définissent une famille de normes pour les réseaux de zone locale (LAN, Local Area Network) qui fournissent la couche Physique et la sous-couche de commande d’accès au support de la couche de liaison des données définie par le modèle de référence d’interconnexion de système ouvert de l’ISO (ISO/OSI, Open System Interconnection Reference Model). Les documents sont dans des états d’avancement divers par rapport à la normalisation internationale pour la commande d’accès au support (MAC, Media Access Control) [4], le protocole de couche physique (PHY, Physical Layer Protocol) [5], la couche physique dépendante du support (PMD) [6], et la gestion de station (SMT) [7]. La famille des normes FDDI corresponds aux normes de la couche MAC de IEEE 802 [8, 9, 10].

Le reste du service de liaison des données est fourni par le service IEEE 802.2 de commande de liaison logique (LLC) [11]. La pile des services résultante apparaît comme suit :

Le présent mémoire décrit l’utilisation de IP et d’ARP dans cet environnement. À l’heure actuelle, il n’est pas nécessaire que l’utilisation de IP et d’ARP soit cohérente entre les réseaux FDDI et IEEE 802, mais c’est l’intention du présent mémoire de ne pas empêcher l’interopérabilité de couche de liaison des données au moment où les normes la définiront.

L’intention explicite du présent mémoire est de permettre l’interopérabilité de IP et d’ARP entre les stations qui sont sur des réseaux FDDI et les stations qui sont sur des réseaux Ethernet via des ponts de traduction.

La norme FDDI définit les stations MAC aussi bien solitaires que duales. Le présent document décrit seulement l’utilisation de IP et ARP sur les stations MAC solitaires (à rattachement unique ou double).

Format de paquet

Les datagrammes IP et les demandes et réponses ARP envoyées sur les réseaux FDDI doivent être encapsulés au sein des couches LLC 802.2 et des couches de liaison des données du protocole d’accès de sous-réseau (SNAP) [12] et des couches MAC et physique FDDI. Le protocole SNAP doit être utilisé avec un code d’organisation indiquant que l’en-tête SNAP contient le code EtherType (selon la liste des Numéros alloués [13]).

La communication de type 1 de LLC 802.2 (qui doit être mise en œuvre par toutes les stations conformes à 802.2) est utilisée de façon exclusive. Toutes les trames doivent être transmises en format d’information non numérotée de type 1 LLC de la norme 802.2, avec les champs DSAP et SSAP de l’en-tête 802.2 réglés à la valeur SAP globale allouée [11]. Le code d’organisation de 24 bits dans le SNAP doit être zéro, et les 16 bits restants sont le EtherType des Numéros alloués [13] (IP = 2048, ARP = 2054).

La longueur totale de l’en-tête LLC et de l’en-tête SNAP est de 8 octets.

La valeur de K1 est 170 (décimal).

La valeur de K2 est 0 (zéro).

La valeur de contrôle est 3 (Information non numérotée).

Résolution d’adresse

La transposition des adresses Internet de 32 bits en adresses FDDI de 48 bits doit être faite via la procédure de découverte dynamique du protocole de résolution d’adresse (ARP) [2].

Les adresses Internet sont attribuée de façon arbitraire sur les réseaux Internet. Chaque mise en œuvre d’hôte doit connaître sa propre adresse Internet et répondre de façon appropriée aux demandes de résolution d’adresse. Elle doit aussi utiliser ARP pour traduire les adresses Internet en adresses FDDI lorsque nécessaire.

Le protocole ARP a plusieurs champs qui paramètrent son utilisation dans tout contexte spécifique [2]. Ces champs sont :

Le code de type de matériel alloué pour les réseaux IEEE 802 est 6 [13]. Le code de type de matériel alloué pour les réseaux Ethernet est 1 [13]. Malheureusement, des valeurs différentes entre les réseaux Ethernet et IEEE 802 causent des problèmes d’interopérabilité dans des environnements avec ponts. Pour ne pas empêcher l’interopérabilité avec les réseaux Ethernet dans un environnement avec pont, les paquets ARP doivent être transmis avec un code de type de matériel de 1. Les paquets ARP doivent être accepté si ils sont reçus avec un code de type de matériel de 1.

Le code de type de protocole pour IP est 2048 [13].

La longueur d’adresse de matériel est de 6.

La longueur d’adresse de protocole (pour IP) est 4.

Le code d’opération est 1 pour une demande et 2 pour une réponse.

Afin de ne pas empêcher l’interopérabilité dans un environnement de pont, les adresses de matériel dans les paquets ARP (ar$sha, ar$tha) doivent être transportés dans l’ordre binaire "canonique", avec le bit Group positionné comme bit de moindre poids du premier octet. Comme les adresses FDDI sont normalement exprimées avec le bit Group dans la position binaire d’ordre supérieur, les adresses doivent avoir leurs bits inversés au sein de chaque octet.

Bien que ce soit en dehors du domaine d’application du présent document, il est recommandé que les adresses MAC soient représentées dans l’ordre canonique dans tous les protocoles de couche Réseau portés au sein du champ d’information d’une trame FDDI.

Adresse de diffusion

L’adresse de diffusion Internet (l’adresse sur ce réseau, qui a une partie hôte toute en uns binaires) doit être transposée en adresse de diffusion FDDI (toute en uns binaires) (voir en [14]).

Prise en charge de la diffusion groupée

Une méthode de prise en charge de la diffusion groupée IP est spécifiée dans [15]. Cette méthode doit être utilisée dans les réseaux FDDI si la diffusion IP de groupe doit être prise en charge. L’utilisation de cette méthode peut exiger la capacité de copier les trames adressées à un nombre quelconque d’adresses de diffusion groupée.

Une adresse IP de diffusion groupée est transposée en une adresse de groupe FDDI en plaçant les 23 bits de moindre poids de l’adresse IP dans les 23 bits de moindre poids de l’adresse de groupe FDDI 01-00-5E-00-00-00 (en ordre "canonique"). [Voir en 13, page 29.]

Par exemple, l’adresse IP de diffusion groupée : 224.255.0.2 se transpose en l’adresse de groupe FDDI 01-00-5E-7F-00-02

dans laquelle le bit de diffusion groupée est le bit de moindre poids du premier octet (en ordre canonique). Lorsque les bits sont inversés pour la transmission dans le champ d’adresse MAC de destination d’une trame FDDI (en ordre natif), elle devient : 80-00-7A-FE-00-40 c’est-à-dire, avec le bit de diffusion groupée comme bit de plus fort poids du premier octet, étant le premier bit transmis sur le support.

Formats d’en-queues

Certaines versions de Unix 4.x bsd utilisent une méthode d’encapsulation différente afin d’obtenir de meilleures performances du réseau avec l’architecture de mémoire virtuelle VAX. Les hôtes connectés directement aux réseaux FDDI ne doivent pas utiliser d’en-queues.

Ordre des octets

Comme décrit à l’Appendice B de la spécification du protocole Internet [1], le datagramme IP est transmis sur les réseaux FDDI comme une série d’octets de 8 bits. Cet ordre de transmission des octets a été appelé "gros boutien" [16].

Précisions sur la couche MAC

Taille de paquet

La spécification de MAC FDDI [4] définit une taille maximum de trame de 9000 symboles (4500 octets) pour tous les champs de trame, y compris quatre symboles (deux octets) de préambule. Ceci laisses environ 4470 octets pour les données après la prise en compte de l’en-tête LLC/SNAP.

Cependant, afin de permettre des extensions futures des champs d’en-tête et de statut de trame MAC, il est souhaitable de réserver de l’espace supplémentaire pour la redondance de MAC.

Donc, la MTU des réseaux FDDI doit être de 4352 octets. Cela fournit 4096 octets de données et 256 octets d’en-tête à la couche réseau et au-dessus. Les mises en œuvre ne doivent pas envoyer de paquets plus grands que la MTU.

Les mises en œuvre de passerelles doivent être prêtes à accepter des paquets aussi grands que la MTU et à les fragmenter si nécessaire. Les mises en œuvre de passerelles devraient être capables d’accepter des paquets aussi grands qu’elles peuvent en porter dans les limites de la taille maximum de trame FDDI et de les fragmenter.

Les mises en œuvre d’hôte devraient être prêtes à accepter des paquets aussi grands que la MTU ; cependant, les hôtes ne doivent pas envoyer de datagrammes plus longs que 576 octets à moins qu’ils n’aient une connaissance explicite de ce que la destination est prête à les accepter. Les mises en œuvre d’hôte peuvent accepter des paquets aussi grands qu’ils peuvent en porter dans une taille maximum de trame FDDI. Un hôte peut communiquer sa préférence de taille dans les applications fondées sur TCP via l’option de Taille maximum de segment TCP [17].

Les datagrammes sur les réseaux FDDI peuvent être plus longs que la taille générale maximum de paquet Internet par défaut de 576 octets. Les hôtes connectés à un réseau FDDI devraient garder cela en mémoire lors de l’envoi de datagrammes à des hôtes qui ne sont pas sur le même réseau local. Il peut être approprié d’envoyer de plus petits datagrammes pour éviter des fragmentations inutiles au passerelles intermédiaires. Prière de se reporter à [17] pour des informations complémentaires.

Il n’y a pas de restrictions de taille minimum de paquet sur les réseaux FDDI.

Afin de ne pas empêcher l’interopérabilité avec Ethernet dans un environnement de pont, les mises en œuvre FDDI doivent être prêtes à recevoir (et ignorer) des octets de bourrage en-queue.

Autres problèmes de la couche MAC

La spécification MAC FDDI n’exige pas que les stations d’adresse de 16 bits et de 48 bits soient capables d’interopérer pleinement. Elle exige, cependant que les stations à 16 bits aient la pleine fonctionnalité à 48 bits, et que les deux types de stations soient capables de recevoir les trames envoyées avec l’une ou l’autre taille d’adresse de diffusion. Afin d’éviter les problèmes d’interopérabilité, seules les adresses de 48 bits doivent être utilisées avec IP et ARP.

La spécification MAC FDDI définit deux classes de trames de LLC, asynchrones et synchrones. Les trames asynchrones sont sous le contrôle d’un mécanisme de priorité et de deux classes de jetons, Restreint et Sans restriction. Seule l’utilisation des jetons Sans restriction et des trames asynchrones est exigée par la norme pour l’interopérabilité FDDI.

Toutes les trames IP et ARP doivent être transmises comme trames LLC asynchrones en utilisant les jetons Sans restriction, et la valeur de priorité est une affaire de convention locale. Les mises en œuvre devraient faire de la priorité un paramètre réglable pour une utilisation future. Il est recommandé que les mises en œuvre fournissent la réception des paquets IP et ARP dans des trames synchrones, aussi bien que dans des trames asynchrones restreintes.

Après la transmission du paquet, FDDI fournit les indicateurs Trame copiée (C) et Adresse reconnue (A). L’utilisation de ces indicateurs est une décision de mise en œuvre locale. Les mises en œuvre peuvent choisir d’effectuer une retransmission de niveau liaison, une invalidation d’entrée de mémoire cache ARP, etc., sur la base des valeurs de ces indicateurs et d’autres informations. La sémantique de ces indicateurs, en particulier en présence de ponts, n’est pas bien définie pour l’instant. Les développeurs sont invités à suivre les travaux du groupe ANSI ASC X3T9.5 sur ce sujet afin d’éviter les problèmes d’interopérabilité.

Détails de la norme IEEE 802.2

Bien que ce ne soit pas nécessaire pour la prise en charge de IP et d’ARP, toutes les mises en œuvre doivent prendre en charge le service standard de classe I de la norme IEEE 802.2 afin d’être conforme à 802.2. La fonctionnalité minimum nécessaire pour une station conforme est décrite ci-dessous. Certaines des fonctions ne se rapportent pas directement à la prise en charge du protocole SAP de SNAP (par exemple, de répondre aux commandes XID et TEST dirigées sur les adresses SAP nulles ou mondiales), mais font partie d’une mise en œuvre générale de LLC. Les développeurs devraient consulter la norme IEEE 802.2 [11] pour les détails.

La LLC de classe I de 802.2 exige la prise en charge des commandes d’Information non numérotée (UI), des commandes et des réponses d’identification d’échange (XID, eXchange IDentification) et des commandes et réponses TEST (TEST) de liaison. Les stations n’ont pas besoin d’être capables de transmettre les commandes XID et TEST, mais doivent être capables de transmettre les réponses.

Codages

Les trames de commandes sont identifiées parce qu’elles ont le bit de moindre poids de l’adresse SSAP remise à zéro. Les trames de réponse ont le bit de moindre poids de l’adresse SSAP mise à un.

La commande UI a une valeur de champ de commande LLC de 3.

La commande/réponse XID a une valeur de champ de commande LLC de 175 (en décimal) si le bit Poll/Final n’est pas mis ou de 191 (décimal) si le bit Poll/Final est mis.

La commande/réponse TEST a une valeur de champ de commande LLC de 227 (décimal) si le bit Poll/Final est à zéro ou de 243 (décimal) si le bit Poll/Final est à un.

Éléments de procédure

Les réponses UI et les commandes UI avec le bit Poll mis à un doivent être ignorées. Les commandes UI qui ont autre chose que le SAP SNAP dans les champs DSAP ou SSAP ne doivent pas être traitées comme des paquets IP ou ARP.

Lorsqu’on reçoit une commande XID ou TEST, on doit retourner une réponse appropriée. Les commandes XID et TEST ne doivent recevoir une réponse que si le DSAP est le SAP SNAP (170 en décimal), le SAP Nul (0 en décimal), ou le SAP Mondial (255 en décimal). Les commandes XID et TEST reçues avec d’autres valeurs DSAP ne doivent pas recevoir de réponse sauf si la station prend en charge le service visé. Les réponses aux trames XID et TEST doivent être construites comme suit :

Destination MAC : Copiée de la Source MAC de la commande

Source MAC : Réglée à l’adresse de la MAC qui reçoit la commande

DSAP : Copié du SSAP de la commande

SSAP : Réglé à 171 décimal (SAP SNAP + bit de réponse) si le DSAP dans la commande était le SAP SNAP ou le SAP Mondial ; réglé à 1 décimal (SAP Nul + bit de réponse) si le DSAP dans la commande était le SAP Nul.

Pour répondre à une commande XID ou TEST, la valeur du bit Final dans la réponse doit être copié de la valeur du bit Poll dans la commande.

Les trames de réponse XID doivent inclure un champ d’information XID 802.2 de 129.1.0 indiquant le service de classe I (sans connexion).

Les trames de réponse TEST doivent faire écho aux champs d’information reçus dans la trame de commande TEST correspondante.

Appendice sur les numéros

L’IEEE spécifie les numéros comme des chaînes binaires avec le bit de moindre poids en premier, ou ordre binaire petit boutien. Les protocoles de l’Internet sont documentés en ordre binaire gros boutien. Cela peut causer une certaine confusion sur les bonnes valeurs à utiliser pour les numéros. Ci-après figurent les conversions pou quelques numéros intéressants.

Différences entre le présent document et la RFC 1188

Ci-après figure un résumé des différences entre la RFC 1188 et le présent document

Retrait d’une référence à un futur document dual-MAC.

Ajout d’une déclaration d’intention explicite de prise en charge de l’interopérabilité FDDI/Ethernet.

L’acceptation des trames ARP portant le code 6 de type de matériel (IEEE 802) a été supprimée.

Les références ont été mises à jour.

L’adresse de l’auteur a été mise à jour.

Références

[1] J. Postel, "Protocole Internet", STD 5, RFC 791, USC/Information Sciences Institute, septembre 1981.

[2] D. Plummer, "Protocole de résolution d’adresses Ethernet - ou – Conversion des adresses de protocole réseau en adresses Ethernet à 48 bits pour la transmission sur matériel Ethernet", RFC 826, MIT, novembre 1982.

[3] J. Postel et J. Reynolds, "Norme pour la transmission des datagrammes IP sur les réseaux IEEE 802", RFC 1042, USC/Information Sciences Institute, février 1988.

[4] ISO, "Interface de données avec distribution par fibre optique (FDDI) – Commande d’accès au support", ISO 9314-2, 1989. Voir aussi ANSI X3.139-1987.

[5] ISO, "Interface de données avec distribution par fibre optique (FDDI) – Protocole de couche physique d’anneau à jetons", ISO 9314-1, 1989. Voir aussi ANSI X3.148-1988.

[6] ISO, "Interface de données avec distribution par fibre optique (FDDI) – Couche physique dépendante du support", ISO DIS 9314-3, 1989. Voir aussi ANSI X3.166-199x.

[7] ANSI, "Gestion de station FDDI", ANSI X3T9.5/84-49 Rev 7.1, 1992.

[8] IEEE, "Normes de l’IEEE pour les réseaux de zone locale : accès multiple avec surveillance de signal et détection de collision (CSMA/CD) Spécification de la méthode d’accès et de la couche physique", IEEE, New York, 1985.

[9] IEEE, "Normes de l’IEEE pour les réseaux de zone locale : Spécification de la méthode d’accès par bus à passage de jetons et de la couche physique", IEEE, New York, 1985.

[10] IEEE, "Normes de l’IEEE pour les réseaux de zone locale : Spécifications de la méthode d’accès par anneau à jeton et de la couche physique", IEEE, New York, 1985.

[11] IEEE, "Normes de l’IEEE pour les réseaux de zone locale : Commande de liaison logique", IEEE, New York, 1985.

[12] IEEE, "Projet de norme P802.1A – Généralités et architecture", 1989.

[13] J. Reynolds et J. Postel, "Numéros alloués", STD 2, RFC 1340, USC/Information Sciences Institute, juillet 1992.

[14] R. Braden et J. Postel, "Exigences pour les passerelles Internet", STD 4, RFC 1009, USC/Information Sciences Institute, juin 1987.

[15] S. Deering, "Extensions d’hôte pour diffusion groupée sur IP", STD 5, RFC 1112, Stanford University, août 1989.

[16] Cohen, D., "On Holy Wars and a Plea for Peace", Computer, IEEE, octobre 1981.

[17] Postel, J., "The TCP Maximum Segment Size Option and Related Topics", RFC 879, USC/Information Sciences Institute, novembre 1983.

Considérations pour la sécurité

Les questions de sécurité ne sont pas évoquées dans le présent mémoire.

Adresse de l’auteur

Dave Katz
cisco Systems, Inc.
1525 O'Brien Dr.
Menlo Park, CA 94025
Téléphone : (415) 688-8284
mèl : dkatz@cisco.com