Transmission de trafic IP sur des réseaux ARCNET

Statut du présent mémoire

Le présent mémoire définit un protocole pour la transmission de paquets IP et ARP sur le réseau de zone locale ARCnet. La présente RFC spécifie un protocole en cours de normalisation par l’IAB pour la communauté de l’Internet, et appelle à des discussion et à des suggestions pour son amélioration. Prière de se référer à la dernière édition des "Normes officielles de protocoles de l’IAB" 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.

1 Introduction

Le présent mémoire spécifie une méthode d’encapsulation des datagrammes de protocole Internet (IP) [1] et de protocole de résolution d’adresse (ARP) [2] à transmettre sur ARCNET [3] en utilisant la "norme de définition d’en-tête de paquet ARCNET" [4]. Le présent mémoire remplace la RFC 1051. La RFC 1051 utilise un protocole de tramage ARCNET qui limite les paquets IP non fragmentés à 508 octets [5].

2 Format de paquet ARCNET

En 1989, Apple Computers, Novell, ACTINET Systems, Standard Microsystems, et Pure Data Research se sont mis d’accord pour utiliser le protocole datalink d’ARCNET défini dans la "norme de définition d’en-tête de paquet ARCNET" [4]. Commençons par une brève description de ce protocole.

2.1 Tramage ARCNET

Le matériel ARCNET accepte deux types de trames : les trames courtes, qui font toujours 256 octets, et les trames longues, qui font toujours 512 octets. Toutes les trames commencent par un en-tête de matériel et se terminent par les données du client précédées par un en-tête de logiciel. Le logiciel place un bourrage au milieu du paquet entre l’en-tête de matériel et l’en-tête de logiciel pour que la trame ait la longueur fixe appropriée. À l’insu du logiciel, le matériel retire ce bourrage durant la transmission.

Les trames courtes peuvent contenir de 0 à 249 octets de données du client. Les longues trames peuvent contenir de 253 à 504 octets de données de client. Pour traiter des trames de 250, 251, ou 252 octets de données, le protocole datalink introduit un troisième type de trame : la trame d’exception.

Ces trois formats de trame sont indiqués ci-dessous. Sauf mention contraire, chaque bloc représente un octet.

Ces formats de paquets sont présentés comme ils seraient vus par le logiciel à travers un matériel ARCNET. Le document [3] se réfère à cela sous le nom de "format de mémoire tampon". Le format réel des paquets sur le réseau est un petit peu différent : l’identifiant de destination est dupliqué, le bourrage entre le champ de décalage et le champ d’identifiant de protocole n’est pas transmis, et il y a des informations de mise en trame matérielle. De plus, le matériel transmet des paquets spéciaux, pour l’allocation de la mémoire tampon et les accusés de réception, qui ne sont pas décrits ici [3].

2.2 Fragmentation de couche de liaison des données

Le matériel ARCNET limite les trames individuelles à 512 octets, ce qui permet 504 octets de données client. Ce protocole de liaison de données ARCNET permet à la couche de liaison des données de couper les paquets en fragments, jusqu’à 120, pour la transmission. Cela permet aux clients ARCNET de transmettre jusqu’à 60 480 octets dans chaque paquet.

Le "fanion de fragmentation" décrit les fragments de paquet de la couche de liaison des données. Il y a trois cas : un paquet non fragmenté, le premier fragment d’un paquet fragmenté, et tout autre fragment d’un paquet fragmenté.

Les paquets non fragmentés ont toujours un fanion de fragmentation de zéro.

Le premier fragment d’un paquet fragmenté a le fanion de fragmentation égal à ((T-2)*2)+1, où T est le nombre total de fragments à attendre pour le paquet.

Les fragments suivants d’un paquet fragmenté ont un fanion de fragmentation égal à ((N-1)*2), où N est le nombre de ces fragments. Par exemple, le quatrième fragment d’un paquet aura toujours une valeur de fanion de fragmentation de six ( (4-1)*2 ).

La station réceptrice peut identifier le dernier fragment d’un paquet parce que la valeur de son fanion de fragmentation de 8 bits sera supérieure de un à celle du fanion de fragmentation du premier fragment du paquet.

Une précédente version de cette définition de protocole de liaison de données ARCNET ne permettait que des paquets qui pouvaient être contenus dans deux fragments. Dans cette ancienne norme, les seuls fanions de fragmentation légaux étaient 0, 1, et 2. La compatibilité avec cette ancienne norme peut être conservée en configurant la longueur maximum des données de client à 1008 octets.

Il n’est pas permis plus de 120 fragments. La plus forte valeur de fanion de fragmentation est EE hex. (Remarquer que la valeur de fanion de fragmentation FF hex est utilisée pour signaler des paquets d’exception dans ce qui serait autrement un champ de fanion de fragmentation de paquet long.)

Tous les fragments d’un seul paquet portent le même numéro de séquence.

2.3 Réassemblage de couche de liaison des données

La précédente section fournit suffisamment d’informations pour mettre en œuvre le réassemblage de liaison des données. Pour éviter les problèmes d’allocation de mémoire tampon durant le réassemblage, on recommande d’allouer assez d’espace pour le paquet réassemblé tout entier lorsque arrive le premier fragment.

Comme les fragments sont envoyés dans l’ordre, la procédure de réassemblage abandonne un paquet si elle reçoit un fragment décalé . Il y a cependant une exception. Il est possible de retransmettre des fragments reçus avec succès. Le logiciel de réassemblage devrait ignorer les fragments répétés sans abandonner le paquet.

Comme les fragments sont envoyés avec rapidité, la procédure de réassemblage peut abandonner un paquet partiellement réassemblé s’il n’arrive pas pour lui de fragments supplémentaires dans les quelques secondes.

2.4 Retransmission de couche de liaison des données

Pour chaque paquet ARCNET en envoi individuel, le matériel indique à l’envoyeur si le receveur a ou non accusé réception du paquet. Pour améliorer la fiabilité, les mises en œuvre de couche de liaison des données sont invitées à retransmettre les paquets ou fragments de paquet sans accusé de réception. Plusieurs retransmissions peuvent être nécessaires. Cependant, les paquets en diffusion ne reçoivent jamais d’accusé de réception, et donc ils ne devraient jamais être retransmis.

Les paquets qui sont bien reçus peuvent n’être pas acquittés avec succès. Par conséquent, la retransmission par la mise en œuvre de couche de liaison des données peut causer des paquets dupliqués ou des fragments dupliqués. Les paquets dupliqués ne posent pas de problème pour IP ou ARP. Comme indiqué à la section précédente, la prise en charge du réassemblage ARCNET devrait ignorer tout fragment redondant.

3 Transmission des datagrammes IP et ARP

Les datagrammes IP et ARP sont portés dans la zone des données client des paquets ARCNET. La prise en charge de liaison des données place chaque datagramme dans une trame ARCNET de taille appropriée, en fragmentant les datagrammes IP supérieurs à 504 octets en plusieurs trames, comme décrit à la section précédente.

4 Transpositions d’adresses IP

La présente section explique comment chacun des trois types d’adresse internet de 32 bits est transposé en adresse ARCNET de 8 bits.

4.1 Adresses en envoi individuel

Une adresse IP en envoi individuel est transposée en une adresse ARCNET de 8 bits en utilisant ARP comme spécifié en [2]. Un paragraphe ultérieur traite des valeurs spécifiques qui devraient être utilisées dans les paquets ARP envoyés sur les réseaux ARCNET.

Il est possible d’allouer des adresses IP telles que les huit derniers bits soient les mêmes que l’adresse ARCNET de 8 bits. Cela permettrait une transposition directe de l’adresse IP en adresse ARCNET sans utiliser de protocole de découverte. Certaines mises en œuvre pourrait fournir cela en option, mais ce n’est pas une pratique recommandée. Bien qu’une telle transposition incorporée soit apparemment séduisante, l’expérience montre que ARP est une approche beaucoup plus souple et pratique à un très faible coût.

4.2 Adresses de diffusion

Toutes les adresses de diffusion IP doivent être transposées en l’adresse de diffusion ARCNET de 0.

À la différence des paquets en envoi individuel, ARCNET n’essaye pas de garantir la livraison des paquets en diffusion, aussi peuvent-ils être perdus. Cela n’aura pas d’impact majeur sur IP car ni IP ni ARP ne prétendent livrer tous les paquets.

4.3 Adresses de diffusion groupée

Comme ARCNET ne fournit pas de prise en charge de la diffusion groupée, toutes les adresses IP en diffusion groupée doivent être transposées en l’adresse de diffusion ARCNET de 0.

5 ARP

La longueur d’adresse matérielle est d’un octet pour les paquets ARP envoyés sur les réseaux ARCNET. Le type de matériel ARP pour ARCNET est 7. Les paquets de demande ARP sont diffusés en les dirigeant sur l’adresse de diffusion ARCNET, qui est 0.

6 RARP

Les paquets du protocole de résolution inverse d’adresse (RARP, Reverse Address Resolution Protocol) [6] peuvent aussi être transmis sur ARCNET. Pour les besoins de l’émission et la réception de liaison des données, RARP est identique à ARP et peut être traité de la même façon. Il y a cependant quelques différences qui doivent être mentionnées entre RARP sur ARCNET, qui a une adresse matérielle d’un octet, et sur Ethernet, qui a une adresse matérielle de six octets.

D’abord, il n’y a que 255 adresses de matériel différentes pour tout ARCNET donné alors qu’il y a un très grand nombre d’adresses Ethernet possibles. Ensuite, les adresses matérielles ARCNET ont plus de chances d’être dupliquées sur les différent réseaux ARCNET ; les adresses Ethernet seront normalement uniques au monde. Enfin, une adresse matérielle ARCNET n’est pas aussi constante qu’une adresse Ethernet : les adresses matérielles ARCNET sont établies par commutateur, et non fixées dans une mémoire en lecture seule comme sur Ethernet.

7 Unité de transmission maximum

La longueur maximum de paquet IP possible en utilisant cette méthode d’encapsulation est de 60 480 octets. Comme cette longueur est impraticable, toutes les mises en œuvre ARCNET sur un réseau ARCNET donné devront se mettre d’accord sur une valeur inférieure. Donc, la taille de paquet maximum DOIT être configurable dans les mises en œuvre de la présente spécification.

Dans tous les cas, les mises en œuvre doivent être capables d’envoyer et de recevoir des datagrammes IP d’une longueur allant jusqu’à 576 octets, et il est vivement recommandé de traiter les datagrammes IP jusqu’à 1500 octets.

Les mises en œuvre peuvent accepter en arrivée des datagrammes IP plus longs que leur unité de transmission maximum configurée. Elles ne sont pas obligées d’éliminer de tels datagrammes.

Pour minimiser la quantité de fragmentations ARCNET, les mises en œuvre peuvent vouloir viser une taille optimum de paquet IP de 504 octets. Cela évite la redondance de la fragmentation de liaison des données, mais aux dépends d’une augmentation du nombre des paquets IP qui doivent être traités par chaque nœud sur le chemin. En plus d’encourager les applications locales à générer de plus petits paquets, une mise en œuvre peut aussi utiliser l’option de taille maximum de segment de TCP pour indique le souhait de segments TCP de 464 octets [7], ou elle peut annoncer une MTU IP de 504 octets par le biais d’un mécanisme de découverte de MTU tel que décrit en [8]. Cela informerait les nœuds non ARCNET d’une taille optimum de paquet plus petite.

8 Numéros alloués

Datapoint Corporation alloue des identifiants de protocole ARCNET pour identifier les différents protocoles qui fonctionnent sur le même support ARCNET. Pour la mise en œuvre de la présente spécification, Datapoint a alloué 212 en décimal à IP, 213 en décimal à ARP, et 214 en décimal à RARP. Ce ne sont pas les numéros alloués à l’encapsulation IP définie par la RFC 1051 [5]. Les mises en œuvre de la RFC 1051 peuvent coexister sur le même ARCNET avec les mises en œuvre de la présente spécification, bien que les deux ne soient pas capables de communiquer ensemble.

L’Autorité d’allocation des numéros de l’Internet (IANA, Internet Assigned Numbers Authority) alloue les valeurs de type de matériel ARP. Elle a alloué à ARCNET le type de matériel ARP de 7 [9].

Remerciements

Plusieurs personnes ont révisé cette spécification et fourni d’utiles contributions. Je souhaite remercier Wesley Hardell de Datapoint et Troy Thomas du bureau Provo de Novell de m’avoir aidé à représenter ARCNET. De plus, j’ai particulièrement apprécié les efforts de James VanBokkelen de FTP Software qui m’a harcelé jusqu’à ce que tous les angles soient arrondis.

Le travail de pionnier sur la transmission du trafic IP sur les réseaux ARCNET a été effectué par Philippe Prindeville.

Références

[1] J. Postel, "Protocole Internet", RFC 791, DARPA, septembre 1981.

[2] D. Plummer, "Protocole de résolution d’adresse Ethernet", RFC 826, MIT, novembre 1982.

[3] Datapoint, Corp., "ARCNET Designer's Handbook", Document numéro 61610, 2 ème édition, Datapoint Corporation, 1988.

[4] Novell, Inc., "ARCNET Packet Header Definition Standard", Novell, Inc., novembre 1989.

[5] P. Prindeville, "Norme pour la transmission des datagrammes IP et des paquets ARP sur les réseaux ARCNET", RFC 1051, McGill University, mars 1988.

[6] R. Finlayson, T. Mann, J. Mogul et M. Theimer, "Protocole de résolution inverse d’adresse", RFC 903, Stanford, juin 1984.

[7] J. Postel, "Protocole de commande de transmission", RFC 793, DARPA, septembre 1981.

[8] J. Mogul, C. Kent, C. Partridge et K. McCloghrie, "Options de découverte de MTU IP", RFC 1063, DEC, BBN, TWG, juillet 1988.

[9] J. Reynolds et J. Postel, "Numéros alloués", RFC 1060, USC/Information Sciences Institute, mars 1990.

Considérations pour la sécurité

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

Adresse de l’auteur

Don Provan
Novell, Inc.
2180 Fortune Drive
San Jose, California, 95131
Téléphone : (408) 473-8440
mél : donp@Novell.Com