Protocole Internet sur les systèmes réseau HYPERchannel – Spécification du protocole

Statut du présent mémoire

L’intention du présent document est de fournir un exposé complet des protocoles et techniques utilisés pour incorporer des datagrammes standard de protocole Internet du DoD (et de leurs protocoles de couche supérieure associés) sur les équipements HYPERchannel [1] de Network Systems Corporation. La distribution du présent mémoire n’est soumise à aucune restriction.

Le présent document est destiné à la planification et au développement de réseau et suppose une certaine familiarité avec la série des protocoles TCP/IP et les techniques utilisées pour porter le trafic TCP/IP sur les réseaux courants tels que le DDN ou Ethernet. On suppose que les produits NSC sont moins familiers ; un appendice est consacré à un survol des technologies et protocoles NSC.

Au moment de la première édition de cette RFC, le contenu du présent document a déjà été révisé par environ une douzaine de fabricants et utilisateurs actifs dans l’utilisation de TCP/IP sur un support HYPERchannel. Les commentaires et suggestions (utiles à la mise en œuvre) sont cependant toujours les bienvenus.

Tout commentaire ou question sur la présente spécification peut être adressé à :

Table des matières

1 Objectifs du présent document
2 Messages réseau HYPERchannel de base
2.1 En-tête propre de message de base (adresse de 16 bits)
2.1.1 Circuits à essayer
2.1.2 Fanions de message
2.1.3 Code d’accès
2.1.4 Adresse TO
2.1.5 Adresse FROM
2.1.6 Type de message
3 Adresses TO et architecture de pilote ouverte
3.1 En-tête étendu (adresse de 32bits) de message propre
3.2 Reconnaissance d’adresse et transmission de message
3.3 Champs de message de 32 bits
3.3.1 Gabarit de circuit
3.3.2 Fanions de message
3.3.3 Adresse TO
3.3.4 Adresse FROM
3.3.5 Type de message
3.3.6 Compte de péremption
3.3.7 Décalage du prochain en-tête et décalage de fin d’en-tête
4 Diffusion
4.1 Circuits à essayer et fanions de message
4.2 Adresse de diffusion
4.3 Canal de diffusion
4.4 Adresse FROM
4.5 Type de message
4.6 Compte de péremption
5 Spécification du protocole
5.1 Encapsulation de message de base (16 bits)
5.1.1 Gabarit de circuit
5.1.2 Fanions de message
5.1.3 Code d’accès
5.1.4 Adresse TO
5.1.5 Adresse FROM
5.1.6 Type de message
5.2 Décalage d’en-tête IP
5.3 Désignateur de type IP
5.4 Décalage d’en-tête IP
5.5 Contenu du datagramme IP
6 Compatibilité avec les mises en œuvre existantes
6.1 Le protocole "Cray-NASA Ames"
6.2 Le protocole "Tektronix-Berkeley"
6.3 Quel protocole est le meilleur ?
7 Encapsulation de message étendu (32 bits)
7.1 Gabarit de circuit
7.2 Fanions de message
7.3 Adresse TO
7.4 Adresse FROM
7.5 Type de message
7.6 Décalage d’en-tête IP
7.7 Contenu des datagrammes IP
8 Protocole de résolution d’adresse
9 Unité maximum de transmission
10 Résolution d’adresse
10.1 Troncature d’adresse IP
10.2 Résolution d’adresse locale
10.3 Format de fichier de configuration
10.4 Serveurs ARP
10.5 ARP en diffusion
Appendice A. Architecture et adressage de produit NSC
A.1 Technologies HYPERchannel de systèmes réseau
A.2 Rattachement aux ordinateurs hôtes
A.2.1 Rattachement de canal de données "cœur de chaîne"
A.2.2 Rattachement de mini-ordinateurs et de stations de travail
A.2.3 Coprocesseurs de réseau
Appendice B. Protocoles HYPERchannel des systèmes réseau
Références

1 Objectifs du présent document

Ce document comporte quatre objectifs techniques majeurs :

1. Consacrer une norme "de facto" pour IP sur HYPERchannel mise en œuvre par Tektronix, Cray, NASA Ames, et d’autres. Il tente de résoudre des problèmes d’interopérabilité avec cette norme de façon à minimiser les changements au logiciel IP sur HYPERchannel existant. Si des ambiguïtés subsistent dans la norme de facto, on souhaite aider à leur résolution.

2. Pour s’adresser à de plus grands réseaux, les produits réseau les plus récents de NSC passent à des adresses de 32 bits pour les adresses TO actuelles à 16 bits. Le présent document veut introduire l’extension d’adressage à la communauté des utilisateurs et spécifier comment les datagrammes IP vont fonctionner dans le nouveau mode d’adressage.

3. Pour définir un protocole de résolution d’adresse pour HYPERchannel et autres produits NSC. Il est probablement bien connu que les produits NSC actuels ne prennent pas en charge les modes de diffusion qui rendent ARP particulièrement utile. Cependant, beaucoup ont exprimé leur intérêt pour les "serveurs ARP" à une adresse réseau connue. Ces serveurs pourraient disparaître lorsque apparaîtront des produits NSC avec une capacité de diffusion. Les pilotes d’hôte qui peuvent générer et reconnaître ce protocole ARP seront prêts à en tirer parti lorsque les morceaux du puzzle s’assembleront.

4. Une partie de cet effort consiste à normaliser le champ non officiel "type de message" qui réserve l’octet 8 du message réseau HYPERchannel. Pour permettre une meilleure interopérabilité, NSC va initier un "registre de protocoles réseau" dans lequel toute partie intéressée peut obtenir une valeur unique dans l’octet 8 (ou les octets 8 et 9) pour leur propre protocole public, privé, commercial ou propriétaire. Les listes de numéros de type de protocole alloués et leurs "propriétaires" seront publiés périodiquement par NSC et seront rendus disponibles aux parties intéressées.

2 Messages réseau HYPERchannel de base

À la différence de la plupart des systèmes de livraison de datagrammes, le message réseau HYPERchannel comporte deux parties :

La première partie est un en-tête de message qui peut aller jusqu’à 64 octets de long. Les 10 premiers octets contiennent les informations requises pour la livraison du message entier, et le reste peut être utilisé par les protocoles de niveau supérieur. La seconde partie du message, les "données associées," peuvent facultativement être incluses avec le message propre. Dans la plupart des cas (transmission sur des circuits HYPERchannel A), la longueur des données associées est littéralement illimitée. Dans d’autres cas (comme ceux des circuits HYPERchannel B ou de transmission au sein d’un adaptateur local HYPERchannel A A400) on limite la taille des données associées à 4 koctet. Si les informations envoyées peuvent être contenues dans le message propre, il n’est pas nécessaire d’envoyer les données associées.

Les protocoles HYPERchannel de liaison inférieurs traitent les messages avec et sans données associées de façon assez différente ; les transmissions de "Message seul" sont envoyées en utilisant des protocoles abrégés et peuvent être mis en file d’attente dans l’adaptateur réseau de réception, ce qui minimise donc le temps nécessaire pour envoyer et recevoir les messages. Lorsque des données associées sont fournies, les adaptateurs HYPERchannel A libèrent leurs ressources logiques afin de piloter l’interface hôte et les circuits coaxiaux.

2.1 En-tête propre de message de base (adresse de 16 bits)

Les dix premiers octets du Message propre réseau sont examinés par les adaptateurs réseau pour vérifier la livraison du message réseau. Son format est le suivant :

2.1.1 Circuits à essayer

Ils consistent en deux gabarits de quatre bits qui indiquent lequel des quatre circuits de données coaxiaux HYPERchannel A possibles est à utiliser pour transmettre le message et le retourner. Si un bit dans le gabarit est ON (à 1), le logiciel d’adaptateur va alors l’ajouter logiquement (ET logique) au gabarit des interfaces de circuits installés et utiliser le résultat comme liste des interfaces candidates. Chaque fois qu’une des "trames" internes est envoyée pour communiquer avec l’adaptateur de destination, le matériel de transmission choisit de façon électronique le premier circuit non occupé sur la liste des candidats. Et donc, le choix d’un circuit de données est mieux fait par l’adaptateur lui-même que par l’hôte. "Dédier" des circuits pour des applications spécifiques n’a de sens que pour des applications très critiques en temps réel telles que des données en direct sortant directement de périphériques à haut débit.

Un second gabarit de circuit est fourni pour l’adaptateur de réception lorsqu’il renvoie des trames à l’émetteur, car il est possible de construire des configurations "asymétriques" de circuits de données où le circuit 1 sur une boîte est connecté à l’interface du circuit 3 d’un second. De telles configurations sont vivement déconseillées, mais la structure d’adressage les prend en charge si nécessaire.

Le champ "circuits à essayer" n’est utilisé que par l’HYPERchannel A. Pour assurer une interopérabilité maximale, une valeur de 0xFF devrait être placée dans ce champ pour assurer la livraison sur n’importe quelle technologie. Les autres valeurs ne devaient être utilisées que si le matériel de ce site particulier est configuré de façon à n’être pas physiquement connecté via ces circuits.

2.1.2 Fanions de message

Ils contiennent les options de la livraison du message. Dans le type de message de base, trois bits sont utilisés :

Données associées présentes (ASSOCIATED DATA PRESENT) (A/D) est ON si un bloc de données associées suit le message propre. 0 si seul un message propre est présent dans le message réseau. La valeur de ce bit est mise en application par le logiciel d’adaptateur réseau.

Mode rafale (BURST MODE) (BST) Active un mode spécial pour des transferts en temps critique où un seul circuit coaxial HYPERchannel A est dédié durant la transmission du message réseau. N’est pas recommandé tout ce qui ne causerait pas un débordement de l’appareil périphérique si les données ne sont pas livrées une fois que commence la transmission des messages.

EXCEPTION (EXC) Indique à des interfaces d’hôte de canal programmé que le message est "hors bande" d’une certaine façon et exige un traitement spécial.

2.1.3 Code d’accès

Dispositif qui permet aux adaptateurs de partager l’utilisation d’un câble tout en permettant une "matrice d’accès" de quelles boîtes d’adaptateurs parlent physiquement à quelles autres. N’est actuellement utilisé par personne, sa prise en charge a été abandonnée.

2.1.4 Adresse TO

Comporte trois parties. Les 8 bits de poids fort contiennent l’adresse physique de la boîte d’adaptateur de réseau qui doit recevoir le message. Les 8 bits de moindre poids sont interprétés de différentes façons selon la nature de l’adaptateur de réseau receveur. Si l’adaptateur receveur a différents accès d’hôte, les bits de moindre poids du champ TO sont utilisés pour désigner quelle interface va recevoir le message. Sur les canaux de données d’IBM, tout le champ TO "logique" est interprété comme le sous-canal sur lequel les données entrantes sont à présenter. Les parties du champ logique TO qui ne sont pas interprétées par l’adaptateur réseau sont passées à l’hôte pour interprétation ultérieure.

2.1.5 Adresse FROM

L’adresse FROM n’est pas utilisée physiquement durant le processus de transmission d’un message réseau, mais est passée à l’hôte qui reçoit de façon qu’une réponse puisse être retournée au point d’origine. En général, si on inverse les champs d’adresse TO et FROM de 16 bits, les gabarits de circuit TO et FROM peuvent bien retourner un message à sa destination.

2.1.6 Type de message

Les deux octets suivants sont réservés pour NSC. Les utilisateurs ont été invités à mettre un zéro dans l’octet 8 et rien du tout dans l’octet 9 de façon à ne pas entrer en conflit avec le traitement interne des messages par le logiciel NSC. Dans le passé, ce champ a été défini de façon vague comme portant des informations intéressantes pour les équipement NSC qui portent le message et non comme un champ formel de type de protocole. Par exemple, 0xFF00 dans les octets 8 et 9 du message causera le renvoi en boucle du message par l’adaptateur de réception sans livraison à l’hôte de rattachement.

À la différence du présent document, il est dans l’intention de NSC d’utiliser les deux octets 8 et 9 comme désignation formelle du "type de protocole". Les protocoles majeurs se verront allouer une valeur unique dans l’octet 8 qui ne va pas (chez les bons citoyens) dupliquer une valeur générée par un protocole différent. Les protocoles mineurs se verront allouer des valeurs de 16 bits de sorte qu’on n’en sera pas à court lorsqu’on dépasse 256 protocoles. Toute partie intéressée pourra obtenir un ou des numéros de protocole en les demandant à NSC. Dans le présent document, les types de protocole spécifiques des protocoles IP sont alloués.

3 Adresses TO et architecture de pilote ouverte

Comme les 16 bits de l’adresse TO ne sont pas tous utilisés pour la livraison physique du message réseau, le reste est considéré comme "logique" en ce que sa signification est déterminée physiquement par le logiciel de l’ordinateur hôte ou (dans des cas comme celui du canal de données FIPS) par le matériel de l’interface d’hôte.

Comme HYPERchannel est utilisé pour la prise en charge d’une grande diversité de protocoles généraux et spécialisés et le sera encore plus à l’avenir, il est souhaitable que plusieurs serveurs de protocoles indépendants soient capables de partager de façon indépendante l’interface réseau HYPERchannel. Les mises en œuvre de nombreux pilotes d’appareil NSC ainsi que celles d’autres parties (comme Cray Research) prennent en charge ce service. Chaque serveur de protocole qui souhaite envoyer ou recevoir des messages réseau HYPERchannel se connecte logiquement à un pilote d’appareil HYPERchannel en spécifiant l’adresse TO complète à 16 bits qu’il va "posséder" en ce sens que tout message réseau avec cette adresse TO sera livré à ce serveur de protocole.

Le champ TO logique sert une fonction similaire à celle de l’octet TYPE dans l’en-tête de message Ethernet 802.2, mais en diffère en ce que la longueur du champ TO logique varie d’un hôte à l’autre, et qu’aucune valeur de l’adresse logique TO n’est réservée pour des protocoles particuliers. D’un autre côté, il est possible d’avoir plusieurs protocoles "identiques" (comme deux copies indépendantes de IP avec des adresses HYPERchannel différentes) qui partagent la même interface HYPERchannel physique. Cela rend l’approche d’adressage NSC identique au concept OSI que le serveur de protocole à atteindre est incorporé à l’adresse, plutôt qu’à la notion IP d’adressage d’un "hôte" et d’identification d’un serveur à travers un type de message.

Comme l’en-tête HYPERchannel a aussi un champ "type de message", il y a une certaine ambiguïté en ce qui concerne les rôles respectifs du type de message et des champs TO logiques :

o Le champ TO logique est toujours utilisé pour identifier le serveur de protocole qui va recevoir le message. Une fois qu’un serveur a spécifié l’adresse TO complète pour les messages qu’il souhaite recevoir, le message ne sera pas livré à un serveur de protocole différent indépendamment du contenu du champ type de message.

o Bien que le champ "type" ne puisse changer le serveur de protocole à la destination finale du message, le champ type peut être utilisé par des processus intermédiaires sur le réseau pour traiter le message avant qu’il n’atteigne le serveur de destination. Un exemple évident en est la fonction de type bouclage arrière du message 0xFF00, où le traitement réseau de bouclage arrière du message résulte en la non livraison à l’adresse TO. À l’avenir, les nœuds intermédiaires ne pourront traiter les messages "en transit" sur la base du type du message que pour des besoins comme la validation de sécurité, la péremption de certains datagrammes, et la gestion de réseau.

3.1 En-tête étendu (adresse de 32bits) de message propre

Dans les premiers jours de HYPERchannel, la limitation à 256 "boîtes" d’adaptateur pouvant être adressées dans un message réseau était réputée suffisante lorsque environ 40 adaptateurs était considéré comme un "grand" réseau. Comme avec l’Ethernet, les réseaux les plus récents ont montré le besoin de s’adresser à des plus grands réseaux. Bien que peu de modes ad hoc aient existé pour s’adresser à de plus grands réseaux HYPERchannel pendant plusieurs années, de nouvelles technologies d’équipements HYPERchannel ont étendu logiquement le message réseau pour qu’il prenne en charge 32 bits d’adressage, avec 24 de ces bits pour désigner un adaptateur réseau physique.

L’en-tête à 32 bits a été conçu de sorte que les adaptateurs réseau existants soient capables d’envoyer et recevoir ces messages. Seuls les ponts réseau ont besoin d’intelligence pour choisir les messages conçus pour eux.

3.2 Reconnaissance d’adresse et transmission de message

Avec la forme d’adressage à 32 bits, , NSC s’en tient à l’idée que l’adresse HYPERchannel native comporte une relation directe avec la position de l’équipement dans un réseau HYPERchannel étendu.

Chaque collection d’adaptateurs réseau NSC rattachés "localement" qui sont connectés par câble coaxial ou fibre optique (avec l’ajout éventuel de répéteurs non sélectifs comme ceux de la série ATRn) est considérée comme un "réseau". Chaque réseau peut avoir jusqu’à 256 adaptateurs directement adressables rattachés qui peuvent être atteints par le message réseau au format de base.

Les ponts existants ou "adaptateurs de liaison" peuvent être programmés pour devenir des "répéteurs sélectifs" en ce qu’ils peuvent recevoir des messages réseau contenant un sous-ensemble d’adresses réseau, les envoyer sur le support pont (s’il en est un) et les réintroduire sur l’autre réseau. De tels réseaux de zone locale interconnectés sont considérés comme un seul réseau du point de vue de l’adressage.

Un grand réseau NSC peut avoir jusqu’à 64 000 réseaux interconnectés de façon complexe par des réseaux ponts et/ou des réseaux "dorsaux" qui distribuent les données entre les autres réseaux. Pour simplifier la mécanique de la transmission de message, le champ réseau de 16 bits est divisé en deux quantités de huit, un "numéro de réseau" qui identifie quel réseau doit recevoir le message et un "numéro de domaine" qui spécifie quel réseau des réseaux est le receveur.

Les adaptateurs de technologie de pont qui déplacent les messages entre les réseaux ont un matériel de reconnaissance d’adresse qui examine tous les 24 bits des octets 2 à 5 de l’en-tête de message réseau pour déterminer si le pont devrait accepter le message à retransmettre. À tout instant donné sur le réseau, chaque pont aura une liste des réseaux et des domaines qu’il devrait accepter de transmettre à un réseau à l’autre extrémité du pont. Chaque adaptateur (y compris les adaptateurs d’hôte des plus nouvelles technologies) contiennent dans le matériel de reconnaissance d’adresse :

o domainmask – un gabarit de 256 bits des numéros de domaine dont il devrait accepter la transmission (sans traitement local) par cet adaptateur.

o MyDomain – la valeur du domaine sur lequel cet adaptateur d’hôte ou extrémité de pont est installé.

o NetworkMask – un gabarit de 256 bits de numéros de réseau qui devraient être acceptés à la transmission par cet adaptateur.

o MyNetwork – la valeur du réseau sur lequel cet adaptateur d’hôte ou extrémité de pont est installé.

o AddressMask – un gabarit de 256 bits des adresses de réseau local qui devraient être acceptées par l’adaptateur.

o MyAddress – "adresse de base" de la boîte, qui doit être fournie dans tout message dirigé sur la commande des processus au sein de l’adaptateur, comme un message de bouclage arrière.

La reconnaissance d’adresse a lieu en utilisant l’algorithme :

IF Domain IN DomainMask OR

IF (Domain = MyDomain AND Network IN NetworkMask) OR

IF (Domain = MyDomain AND Network = MyNetwork AND

Address IN AddressMask) THEN accept-message

ELSE ignore-message.

Cet algorithme signifie qu’une logique de reconnaissance d’adresse de matériel d’un adaptateur va accepter tout message adressé à la boîte elle-même, à toute adresse secondaire ou alias d’adresse locale possédée par l’adaptateur, et tout message dirigé sur un réseau ou domaine distant que cet adaptateur particulier est prêt à transmettre.

3.3 Champs de message de 32 bits

3.3.1 Gabarit de circuit

Comme dans le message réseau de base, les messages qui sont à livrer en dehors du réseau immédiat devraient avoir 0xFF dans cet octet de façon que tous les circuits possibles dans les réseaux intermédiaires soient essayés. Les messages de 32 bits délivrés localement devraient toujours contenir des gabarits de circuit taillés sur mesure pour satisfaire aux besoins de la livraison locale.

3.3.2 Fanions de message

Les bits actuellement définis restent comme auparavant. Trois nouveaux bits ont été définis depuis lors.

CRC (INTÉGRITÉ DE MESSAGE DE BOUT EN BOUT). Les adaptateurs d’hôte des technologies les plus récentes sont capables de générer un CRC de 32 bits pour le message réseau tout entier aussitôt qu’il est reçu sur le canal ou l’interface de bus de la part de l’hôte. Ce CRC de 32 bits est ajouté à la fin du bloc de données associées et il est préservé à travers tout le processus de livraison jusqu’à ce qu’il soit vérifié par l’adaptateur d’hôte qui est le receveur ultime du message, et qui le retire. Cette vérification d’intégrité de bout en bout est conçue pour fournie un haut degré d’assurance que les données ont été correctement déplacées à travers tous les LAN intermédiaires, liens géographiques, et matériels et processus d’adaptateur internes.

SRC (ADRESSE FROM DE SOURCE CORRECTE). Ce bit est fourni pour tirer parti de la nature physique de l’adresse réseau en vérifiant facultativement que l’adresse FROM de 32 bits fournie dans le message réseau est en fait la localisation d’origine du message. Si le bit n’est pas mis (à 1) par l’hôte émetteur, aucun traitement particulier ne survient sur le message. Si le bit est mis (à 1), tous les adaptateurs intermédiaires impliqués dans la livraison du message ont le pouvoir de mettre le bit à zéro si l’adresse FROM du message reçu n’est pas une adresse TO qui serait livrée à l’origine au cas où le message irait dans la direction opposée.

Si le message est reçu par un ordinateur hôte avec ce bit encore établi, il est alors garanti que l’adresse FROM est correcte au sens où le retour d’un message avec les informations TO et FROM inversées résulterait en la délivrance du message au processeur qui en est réellement à l’origine. Une attention soutenue à la sécurité physique des adaptateurs et liens intermédiaires entre les réseau peut apporter un haut niveau de sécurité aux systèmes qui examinent simplement l’adresse FROM d’un message pour déterminer la légitimité de la demande qui y est associée.

GNA (ADRESSAGE DE RÉSEAU MONDIAL). Ce bit ON (à 1) indique la présence de l’adressage à 32 bits dans le message. Quand ce bit est mis, les octets 2-3 (numéro de domaine et numéro de réseau) devraient aussi être non zéro.

3.3.3 Adresse TO

Quatre octets contiennent l’adresse TO, qui est utilisée pour délivrer le message réseau comme décrit à la page 8 de "Reconnaissance d’adresse et transmission de message". La partie "logique" de l’adresse TO est utilisée pour désigner un serveur de protocole exactement comme dans l’en-tête de message réseau au format de base.

Le champ "adresse" existant a son bit de plus fort poids réservé comme bit hors réseau pour la compatibilité avec les équipements existants d’adaptateur de réseau de série A. S’il n’y avait pas ce bit, les adaptateurs de série A tenteraient d’accepter les messages qui "traversent" le réseau local en allant ailleurs, simplement parce que le champ d’adresse correspondait alors que les numéros de domaine et de réseau (ignorés par les adaptateurs de série A) sont assez différents.

Ce bit "hors réseau" est utilisé de la façon suivante :

o Tous les adaptateurs réseau (de tout type) dans un ensemble étendu de réseaux contenant des adaptateurs de série A qui vont un jour utiliser de l’adressage à 32 bits doivent avoir leurs adresses dans la gamme 00-7F (hex.)

o Si un message doit être envoyé à destination d’un réseau et domaine non local sur un tel réseau étendu, le bit de plus fort poids du champ adresse est mis à un.

o Lorsque le dernier pont de la chaîne réalise qu’il est sur le point de transmettre le message à sa destination finale (les numéros de domaine et de réseau sont locaux), il met alors le bit Hors-réseau à zéro. Il en résultera une livraison locale à l’adaptateur de destination.

3.3.4 Adresse FROM

L’adresse FROM suit la même logique que l’adresse TO en ce que tout message peut être retourné à sa source en inversant les champs FROM et TO du message. Comme de si nombreux protocoles examinent l’octet 8 du message pour déterminer son type, le champ FROM a été partagé de sorte que les numéros de domaine et de réseau s’étendent sur les octets 10-11.

3.3.5 Type de message

Ce champ (qui était défini de façon informelle dans le passé) a été étendu à 16 bits de sorte qu’une valeur unique puisse être allouée à tout protocole présent ou futur qui s’appuie sur les messages HYPERchannel pour utilisation privée ou publique.

3.3.6 Compte de péremption

Ce champ sert au même objet que la "durée de vie" de IP, en ce qu’il empêche les datagrammes de circuler sans fin dans un réseau mal configuré. Chaque fois qu’un message de 32 bits passe à travers un pont, le compte de péremption est décrémenté de un. Lorsque le résultat est zéro, le message est éliminé par le pont.

3.3.7 Décalage du prochain en-tête et décalage de fin d’en-tête

Ils sont utilisés comme champs pour fournir un "routage à origine indéterminée" facultatif, où une liste d’adresses TO à 32 bits peut être fournie par l’émetteur pour déterminer explicitement le chemin d’un message à travers le réseau. Si ce dispositif n’est pas utilisé, ces champs contiendront tous deux la valeur 16 (en décimal) pour indiquer que les adresses TO supplémentaires sont absentes et que le début des données de protocole qui suivent l’en-tête HYPERchannel est dans l’octet 16.

Bien qu’on puisse concevoir qu’un processus IP HYPERchannel pourrait utiliser cette capacité d’acheminement de source pour diriger des messages sur des hôtes ou des passerelles, cette capacité n’est pas jugée de valeur suffisante pour que IP l’installe dans un protocole IP HYPERchannel.

À l’avenir, tous les protocoles de niveau supérieur devraient être capables d’examiner le décalage de fin d’en-tête pour déterminer le début des informations de protocole de niveau supérieur.

4 Diffusion

Les protocoles de transmission de message NSC utilisent des protocoles de liaison de bas niveau pour négocier la transmission d’un message à sa prochaine destination sur le réseau. De plus, les boîtes de réseau NSC "ventilent" souvent de sorte que plusieurs hôtes partagent le même équipement de transmission réseau comme dans l’adaptateur A400. Ces deux caractéristiques signifient que la fourniture d’une authentique capacité de diffusion n’est pas une tâche triviale, et en fait aucune mise en œuvre actuelle de technologie NSC ne prend en charge une capacité de diffusion.

Les dernières années ont vu une maturation des applications de diffusion au point que leur utilité sur une base locale et parfois au niveau d’un campus n’est virtuellement pas mise en doute. En conséquence, de nouvelles technologies NSC prendront en charge une capacité de diffusion. Les informations sur l’utilisation de cette capacité figurent ici car elles sont essentielles pour l’exposé du protocole de résolution d’adresse plus loin dans le présent document.

La capacité de diffusion ne sera prise en charge qu’avec le format étendu de message (adresses à 32 bits). Un message de diffusion aura l’apparence générale suivante :

4.1 Circuits à essayer et fanions de message

Ces champs sont définis juste comme avec un message normal de 32 bits. Tous les bits dans le champ Fanions de message sont valides dans les modes de diffusion.

4.2 Adresse de diffusion

Pour les champs d’adresse de domaine, de réseau et d’adaptateur, la valeur 0xFF est réservée pour l’utilisation du mécanisme de diffusion. Une valeur de 0xFF dans le champ d’adresse d’adaptateur indique au matériel de réseau local que ce message est à envoyer à tous les équipements de réseau connectés sur le réseau individuel.

Une valeur de 0xFF dans le champ de réseau ou de domaine, indique respectivement une demande dont la portée de diffusion excède le réseau local. Les adaptateurs de liaison de pontage vont recevoir le message en diffusion comme tous les autres et vont examiner le champ "Canal de diffusion" et leurs commutateurs internes pour déterminer si le message devrait être retransmis aux autres réseaux distants.

Si les champs Réseau et Domaine contiennent le réseau et le domaine local, le message en diffusion sera alors seulement diffusé au sein du réseau local. Si un Réseau et un Domaine distants sont spécifiés, alors le message sera délivré comme un seul message au réseau distant et y sera diffusé.

4.3 Canal de diffusion

Comme les hôtes individuels et serveurs de protocole ne sont généralement pas intéressés par tous les messages en diffusion qui naviguent sur le réseau, un mécanisme de filtrage est fourni dans l’en-tête et les équipements d’adaptateur de réseau de sorte que seules les classes appropriées de messages en diffusion soient délivrés au point d’extrémité.

Les numéros de canal de diffusion dans la gamme 00-0xFF seront alloués par NSC un peu comme le champ "type de message". Les serveurs de protocole hôtes spécifient une adresse TO spécifique qui contient un numéro de canal (comme 0xFF04) lorsque ils se lient eux-mêmes au pilote d’appareil HYPERchannel.

Le pilote et l’équipement sous-jacent ne livreront que des messages en diffusion avec le numéro de canal correct au serveur de protocole. Si un serveur de protocole souhaite recevoir plusieurs messages en diffusion différents, il doit se lier lui-même au pilote plusieurs fois avec les adresses désirées.

Les adaptateurs de liens qui sont prêts à traiter des messages en diffusion multi-réseaux peuvent être équipés de commutateurs pour déterminer quels canaux de diffusion seront propagés dans le prochain réseau. Comme la diffusion multi-réseau est un arrangement qui doit être configuré avec soin, ces commutateurs sont débranchés par défaut.

4.4 Adresse FROM

L’adresse FROM est construite juste comme avec un message réseau de 32 bits normal. Le bit Adresse de source correcte est traité juste comme avec un message normal.

4.5 Type de message

Le type de message est défini comme avec les messages normaux. On peut supposer que les applications de diffusion auront des types de message uniques qu’on ne trouve généralement pas dans les messages normaux.

4.6 Compte de péremption

Le compte de l’âge est d’une importance vitale dans un diffusion multi-réseau car des "boucles" dans le réseau peuvent causer une grande quantité d’activité jusqu’à ce que toute la progéniture du message de diffusion original s’éteigne.

5 Spécification du protocole

La présente section contient des informations sur la technique utilisée pour encapsuler les datagrammes IP sur le message réseau HYPERchannel. Elle contient trois paragraphes pour décrire trois paquetages de protocoles :

o La technique utilisée pour encapsuler les datagrammes IP sur le message réseau à 16 bits de base. C’est une norme de fait qui a été utilisée pendant plusieurs années et qui est mentionnée ici pour la rendre officielle.

o La technique d’encapsulation pour les datagrammes IP sur les messages réseau à 32 bits.

o La définition d’un protocole de résolution d’adresse sur HYPERchannel.

5.1 Encapsulation de message de base (16 bits)

5.1.1 Gabarit de circuit

À l’avantage d’un pilote IP, tout gabarit de circuit est valide tant qu’il réussit à bien livrer à sa destination le message réseau HYPERchannel. Il n’y a aucune raison de vérifier la validité de ce champ à réception du message. La spécification du Gabarit de circuit en sortie est une affaire locale qui pourrait être spécifiée par les tableaux de résolution d’adresse du pilote émetteur.

5.1.2 Fanions de message

Il n’est pas fait usage du champ Fanions (octet 1) en dehors d’établir de façon appropriée le bit Données associées. Les bits Mode rafale et Exception ne devraient pas être utilisés avec IP.

5.1.3 Code d’accès

Bien que certaines mises en œuvre actuelles de IP sur HYPERchannel prennent en charge le code d’accès, personne ne semble l’utiliser à l’heure actuelle. Comme ce champ est actuellement réservé pour l’utilisation des adresses à 32 bits, aucune valeur autre que 0000 ne devrait être placée dans ce champ.

5.1.4 Adresse TO

Le champ TO est généralement obtenu par un pilote IP local à travers un algorithme de recherche de tableau qui trouve une adresse TO à 16 bits correspondant à l’adresse IP d’un hôte ou routeur local. Les bits de plus fort poids de l’adresse TO se réfèrent bien sûr au numéro d’adaptateur que l’adaptateur a rattaché à l’hôte de destination.

Le champ TO logique devrait contenir l’adresse de serveur de protocole du pilote IP HYPERchannel pour cet hôte, telle que déterminée par l’administrateur de système de l’hôte. De nombreux pilotes TCP/IP HYPERchannel dans le champ ne sont pas aujourd’hui "ouverts" en ce que aucun message réseau livré à cet hôte ne sera présumé être un datagramme IP sans considération du champ logique TO ; cependant, tout processus de transmission IP devrait être capable de générer le champ TO à 16 bits entier afin de générer un message capable d’atteindre un processus IP de destination.

Le processus de détermination de quelle adresse HYPERchannel va recevoir un datagramme IP sur la base de son adresse IP est un sujet majeur qui est traité dans "Résolution d’adresse".

5.1.5 Adresse FROM

L’adresse FROM est remplie avec l’adresse que le pilote local s’attend à recevoir de la part du réseau, mais aucune utilisation particulière n’est faite de l’adresse FROM.

5.1.6 Type de message

Les systèmes réseau demandent qu’une valeur de 5 (décimal) soit placée dans cet octet pour indiquer de façon univoque que le message réseau est utilisé pour porter du trafic IP. Aucun autre protocole bien conformé utilisant HYPERchannel ne devrait dupliquer cette valeur de 5.

De nombreuses mises en œuvre actuelles de IP sur HYPERchannel placent un zéro ou d’autres valeurs dans ce champ simplement parce qu’aucune valeur n’était réservée pour l’utilisation de IP. Les versions de IP qui émettent devraient toujours placer un 5 dans ce champ ; les receveurs de IP devraient présumer un message délivré comme étant un datagramme IP jusqu’à preuve du contraire sans considération du contenu du champ Type de message.

Les développeurs devraient noter qu’il est souvent pratique de permettre la réception de la valeur 0xFF00 dans les octets 8 et 9 du datagramme IP. L’émission d’un message avec cette valeur causera son rebouclage arrière sur l’adaptateur de destination et son retour sur le serveur de protocole désigné dans l’adresse FROM. Cela permet au développeur d’avoir des applications d’hôte qui parlent aux autres sur le même hôte pour les besoins de l’interface réseau ou autres débogages de protocole.

5.2 Décalage d’en-tête IP

L’octet 9 contient le décalage par rapport au début de l’en-tête IP au sein du message propre, de telle sorte que l’adresse de Message propre plus le décalage de l’en-tête IP génère l’adresse du premier octet de l’en-tête IP (au moins sur les machines à octets adressables.)

Ce champ est redondant avec le champ décalage de l’octet 11, et il est présent pour une compatibilité superficielle avec les mises en œuvre à 32 bits. À réception, la valeur de l’octet 11 devrait prendre le pas.

Au titre de la migration vers de plus grands en-têtes HYPERchannel, ce champ deviendra significatif pour le format d’adressage à 32 bits, car la longueur de l’en-tête ne sera plus de 10 octets et l’octet 11 sera utilisé à d’autres fins.

5.3 Désignateur de type IP

Les premières mises en œuvre de pilotes IP sur HYPERchannel voulaient laisser les octets 8 et 9 pour l’usage de NSC et placer un champ "type de message" plus loin dans le message. Une valeur de 0x34 a été choisie par les premiers développeurs pour des raisons qui n’ont plus maintenant qu’un intérêt historique. Une fois encore, les mises en œuvre devraient générer cette valeur à l’émission, mais ne pas la vérifier en entrée, en supposant qu’un datagramme IP est présent dans le message.

5.4 Décalage d’en-tête IP

Cette valeur est utilisée par un certain nombre de mises en œuvre commerciales de IP sur HYPERchannel pour aligner le début de l’en-tête IP au sein du message réseau. Ce décalage se rapporte à l’octet 12 du message réseau de sorte qu’une valeur de zéro indique que l’en-tête IP commence à l’octet 12. Cette valeur devrait à la fois être générée correctement à l’émission, et toujours respectée par le traitement d’entrée.

Le décalage maximum permis dans ce champ est de 52 qui indique que l’en-tête IP commence au début du bloc de données associées.

5.5 Contenu du datagramme IP

Commençant au décalage désigné à l’octet 11, le datagramme IP est traité comme un bloc contigu de données qui s’écoulent depuis l’octet 63 du message propre dans le premier octet des données associées, de sorte le message entier plus les données est traité comme un seul bloc contigu.

Si l’en-tête IP est assez petit pour tenir au sein du message réseau entier, seul le message propre est alors transmis. La longueur du message propre envoyé devrait toujours être de 64 octets, même si le datagramme IP et l’en-tête HYPERchannel n’occupent pas tous les 64 octets du message propre.

Si le datagramme déborde dans les données associées, alors le message et les données sont envoyés tous les deux. Comme un certain nombre de machines ne peuvent pas envoyer une longueur de données à l’HYPERchannel qui soit un nombre exact d’octets (du fait des 16 à 64 bits sur le canal bus) la longueur des données associées reçues ne devrait pas être utilisée comme guide de la longueur du datagramme IP – celle-ci devrait être extraite de l’en-tête IP. Un pilote devrait vérifier, bien sûr, que les données associées reçues sont au moins aussi longues que nécessaire pour contenir le datagramme IP entier.

6 Compatibilité avec les mises en œuvre existantes

Le format de base décrit ici est clairement un compromis entre plusieurs mises en œuvre de IP sur HYPERchannel. Toutes les mises en œuvre existantes ne sont pas interopérables avec la norme décrite ci-dessus. Actuellement, il existe deux "familles" connues de pilotes HYPERchannel IP :

6.1 Le protocole "Cray-NASA Ames"

Ce protocole est le plus largement produit et a le plus grand nombre de pilotes pris en charge actuellement. Il est interopérable et identique à la norme décrite ci-dessus avec la seule exception que les octets 8 et 9 sont mis à zéro par ces pilotes. Comme ces octets sont ignorés par la plupart des mises en œuvre de ce pilote, il leur a été alloué des valeurs pour formaliser l’utilisation du champ Type de message et pour le rendre cohérent avec le protocole à 32 bits.

6.2 Le protocole "Tektronix-Berkeley"

Ce protocole était historiquement la première mise en œuvre développée de IP sur HYPERchannel (chez Tektronix) et il a ensuite été adopté par Berkeley et BSD UNIX. Ce protocole n’est pas interopérable avec la norme décrite ci-dessus du fait de plusieurs différences.

D’abord, les octets 8 à 11 sont toujours à zéro. L’en-tête IP commence toujours sur l’octet 12. Les commentaires sur certains de ces pilotes désignent l’octet 11 comme un champ de "décalage d’en-tête IP", mais apparemment cette valeur n’est jamais traitée.

La différence (et incompatibilité) majeure concerne la mise en paquet du datagramme IP dans le message réseau. Du fait de difficultés historiques au début des années 80 avec l’envoi et la réception de très petits blocs de données associées sur les VAX, ce protocole a adopté une approche curieuse du placement de l’en-tête IP et des en-têtes des protocoles de niveau supérieur (tels que TCP ou UDP.)

o Si la longueur totale du datagramme IP est de 54 octets ou moins, il est possible de faire tenir le datagramme entier et l’en-tête HYPERchannel dans le message propre de 64 octets. Dans ce cas, aucune donnée associée n’est envoyée ; seul un message propre est utilisé pour porter les données. La longueur du message propre transmis est la longueur exacte nécessaire pour inclure le datagramme IP ; aucun octet de bourrage n’est envoyé à la fin du message.

o Si la longueur de l’en-tête IP est supérieure à 54 octets, alors :

- Toutes les informations de protocole de niveau supérieur (en-tête TCP/UDP et leurs champs de données associées) sont placées dans le bloc des données associées, avec l’en-tête TCP/UDP commençant au début du bloc des données associées.

- À l’émission, la longueur du message propre transmis est réglée à la longueur de l’en-tête HYPERchannel plus l’en-tête IP – elle n’est pas bourrée à 64 octets. La longueur des données associées envoyées devrait être suffisante pour s’accommoder de l’en-tête TCP/UDP et de ses champs de données.

6.3 Quel protocole est le meilleur ?

Pour déterminer lequel choisir, l’approche "Cray-Ames" a été retenue pour plusieurs raisons :

1. Cray Research a effectué un travail exemplaire en traitant avec les autres fabricants pour fournir IP sur HYPERchannel pour les ordinateurs Cray aux autres hôtes. Il en résulte que 4 ou 5 mises en œuvre qui prennent en charge IP sur HYPERchannel utilisent cette approche.

2. La structure en deux parties du message propre a son utilité lorsqu’une machine souhaite prendre des décisions de protocole avant de mettre en scène le transfert d’un immense bloc de données associées en mémoire. De nombreux coprocesseurs de réseau et de sous-systèmes intelligents I/O trouvent plus simple de lire le message réseau entier avant de décider ce qu’il convient d’en faire. Le chaînage arbitraire des deux composants fait pour le mieux et permettra le dévidage des messages à partir d’adaptateurs de réseau de technologies à venir.

3. Certains utilisateurs de TCP (surtout des sites du DoD très sécurisés) ont l’intention de charger à l’avenir des datagrammes IP avec des champs facultatifs. La mise en œuvre Tektronix-Berkeley a des problèmes si la longueur de l’en-tête IP excède 54 octets.

7 Encapsulation de message étendu (32 bits)

7.1 Gabarit de circuit

À l’avantage d’un pilote IP, tout gabarit de circuit est valide s’il a pour résultat la bonne livraison du message réseau HYPERchannel à sa destination. Il n’y a pas de raison de vérifier la validité de ce champ à réception du message. La spécification du Gabarit de circuit en sortie est une affaire locale qui peut être spécifiée par les tableaux de résolution d’adresse du pilote émetteur.

L’utilisation de 0xFF dans cette valeur est vivement encouragée pour tout message autre que ceux qui utilisent des configurations exotiques de circuit sur un seul réseau local.

7.2 Fanions de message

Plusieurs nouveaux bits ont été définis ici.

EXTENDED ADDRESSING (adressage étendu). Ce bit devrait être établi (à un) chaque fois qu’une adresse à 32 bits (numéros de réseau et/ou de domaine non à zéro) est présente dans le message. Il devrait toujours être à zéro avec l’en-tête de message à 16 bits. Si ce bit est établi à tord, la livraison du message à la destination (apparente) est improbable.

END-TO-END CRC (CRC de bout en bout). Certains adaptateurs de technologie récente sont équipés pour placer un CRC de 32 bits des données associées à la fin du bloc des données associées lorsque ce bit est mis. Des adaptateurs équipés de façon similaire examineront les 32 bits d’en-queue des données associées (lorsque le bit est mis) pour déterminer si le contenu du message a été corrompu à un stade quelconque de la transmission.

Les pilotes d’appareil de transmission devraient inclure la capacité à établir ce bit à l’émission comme une option de configuration similaire à l’interface d’appareil HYPERchannel spécifique utilisé. Le bit devrait être généré pour être établi si le pilote IP HYPERchannel est rattaché à un adaptateur équipé pour générer une information de CRC – il devrait être laissé à zéro dans toutes les autres circonstances.

Si un message arrive à l’hôte avec le bit de CRC encore établi, cela indique que les informations de CRC ont été placées à la fin des données associées par l’adaptateur d’émission et n’ont pas été retirées par l’adaptateur de réception ; et donc les données associées seront plus longues de quatre octets qu’attendu autrement. Comme la longueur du datagramme IP est auto contenue dans le message réseau, cela ne devrait pas avoir d’impact sur les pilotes IP.

Il est possible que les ordinateurs hôtes génèrent et vérifient à la fois ces informations de CRC pour les confronter à la génération assistée par le matériel et à la logique de vérification dans les adaptateurs de réseau les plus récents. Contacter NSC si des applications particulières requièrent une intégrité de données exceptionnelle qui pourrait bénéficier de la génération et de la vérification par l’hôte.

FROM ADDRESS CORRECT (adresse de source correcte). Ce bit devrait être établi par tous les pilotes IP d’émission qui ont entrepris de fournir une adresse FROM complètement correcte qui reflète de façon appropriée l’interface d’adaptateur utilisée. Aucune action ne devrait être entreprise sur ce bit à ce moment par le pilote IP de réception. Des travaux supplémentaires doivent être effectués pour déterminer l’action que devrait entreprendre un pilote IP si il détecte une "violation de sécurité" réelle ou imaginaire si un message devait arriver sans ce bit.

7.3 Adresse TO

L’adresse TO constitue logiquement les octets 2 à 5 du message réseau.

NETWORK AND DOMAIN NUMBERS (Numéros de réseau et de domaine). Les numéros de réseau et de domaine devraient tous deux être non zéro losqu’on utilise l’adressage à 32 bits. Si le message est local par nature, les numéros de réseau et domaine locaux devraient être placés dans ce champ.

ADAPTER ADDRESS (Adresse d’adaptateur). Contient l’adresse de l’adaptateur comme dans le message de base. Le bit de plus fort poids de ce champ de huit bits (le bit "outnet") devrait être mis à zéro si le réseau et le domaine de destination sont les mêmes que ceux de l’hôte émetteur. Le bit de plus fort poids devrait être mis à un si l’hôte de destination n’est pas dans le réseau ou domaine local.

LOGICAL TO AND SUBADDRESS (destination logique et sous-adresse). Le champ TO logique devrait contenir l’adresse du serveur de protocole du pilote IP HYPERchannel pour cet hôte comme déterminé par l’administrateur système de l’hôte.

7.4 Adresse FROM

L’adresse FROM est remplie avec l’adresse que le pilote local s’attend à recevoir de la part du réseau, mais aucune utilisation particulière n’est faite de l’adresse FROM.

7.5 Type de message

La valeur 6 doit être placée dans cet octet pour indiquer de façon univoque que le message réseau est utilisé pour porter du trafic IP. Aucun protocole de comportement correct qui utilise HYPERchannel ne devrait reproduire cette valeur de 6.

Noter que tous les pilotes IP devraient être prêts à envoyer et recevoir des messages réseau au format de base en utilisant les adresses HYPERchannel à 16 bits. Le pilote peut distinguer un message réseau entrant par la valeur de l’octet 8 – les messages de 32 bits auront toujours un 6 dans l’octet 8, alors que les messages de 16 bits devraient avoir là un 5. Pour l’interopérabilité avec les pilotes plus anciens, une valeur de 0 à cet endroit devrait être traitée comme un message à adresse de 16 bits.

7.6 Décalage d’en-tête IP

L’octet 9 contient le décalage du début de l’en-tête IP au sein du message propre, de sorte que l’adresse du message propre plus le décalage de l’en-tête IP génère l’adresse du premier octet de l’en-tête IP (au moins sur les machines à octets adressables.)

À la différence de l’en-tête à 16 bits, les pilotes IP récepteurs devraient supposer que ce champ contient un décalage correct de l’en-tête IP et examiner les informations à ce décalage pour la conformité avec un en-tête de datagramme IP.

Les décalages valides sont dans la gamme de 16 à 44 octets, inclus. La limitation à 44 octets est imposée de sorte que les décisions d’acheminement pour la grande majorité des datagrammes IP puissent être prises en examinant seulement le message propre, car le datagramme IP de base va tenir dans le message propre si il commence à un décalage de 44.

7.7 Contenu des datagrammes IP

Le message et les données sont traités comme des entités logiquement contiguës où le premier octet des données associées suit immédiatement le 64 ème octet du message propre.

Si le datagramme IP entier est inférieur ou égal à (64 moins le décalage) octets, il va tenir dans le message propre. S’il en est ainsi, seul un message propre contenant l’en-tête HYPERchannel et le datagramme IP est envoyé sur le réseau.

Si le datagramme IP est supérieur à cette longueur, le datagramme IP s’étend sur les données associées. À l’émission, un message propre de 64 octets est envoyé, suivi par autant d’octets de données associées que nécessaire pour envoyer le datagramme entier.

À réception, le message propre peut être lu au début d’une mémoire tampon IP et les données associées sont lues dans la mémoire à 64 octets du début du message. Si le message reçu est en fait un message d’adresse de 32 bits, aucun "battage" du message ne sera nécessaire pour construire un datagramme IP contigu – il est là directement à mémoire tampon + 16.

8 Protocole de résolution d’adresse

Le protocole de résolution d’adresse a eu un grand succès sur Ethernet car il permet à un réseau IP local de se configurer lui-même si chaque nœud connaît sa propre adresse IP. Ceux qui ne sont pas familiarisés avec les intentions, le protocole, et la logique du protocole de résolution d’adresse devraient se reporter à la RFC-826, "Protocole de résolution d’adresse Ethernet" [2].

Un paragraphe ultérieur du présent document décrit quatre techniques qui permettent d’obtenir une adresse HYPERchannel cible étant donnée l’adresse IP de destination. Le protocole est défini dans la présente section par souci d’exhaustivité.

La disposition des champs de ce message ARP est un exercice très direct connaissant les normes de ARP et l’en-tête de message de 32 bits. Quelques champs méritent une remarque :

8.1 Adresse TO

L’adresse TO d’un message ARP sera d’une des deux classes d’adresse. Une adresse "normale" indique que le message est une réponse ARP, ou que c’est une demande ARP dirigée sur un serveur ARP à une adresse bien connue sur le réseau local. Pour les réseaux HYPERchannel qui sont équipés pour la diffusion, une valeur de 0xFFFFFF07 dans l’adresse TO ne sera (par convention) reprise que par les serveurs de protocole qui sont prêts à interpréter les messages ARP et à y répondre.

La question de savoir quelle adresse utiliser dans une demande ARP est exposée à la section Résolution d’adresse.

8.2 Adresse FROM

Elle doit être l’adresse FROM correcte du serveur de protocole utilisateur qui produit une demande ARP. Le bit Source Correct dans l’octet Fanions de message devrait être établi par ce serveur demandeur, car certains serveurs ARP pourraient un jour choisir de produire les informations d’ARP en fonction des besoins dans des environnements sécurisés. Avec une réponse ARP, l’adresse FROM contiendra l’adresse HYPERchannel "normale" du serveur de protocole répondant à l’adresse ARP, même si ce serveur a été atteint via des mécanismes de diffusion.

Les réponses ARP sont retournées à la partie spécifiée dans l’adresse FROM spécifiée dans l’en-tête de message, plutôt qu’à l’adresse du champ "Adresse HYPERchannel de source" au sein du corps du message ARP.

8.3 Type de message

La valeur 0x0700 de 16 bits est réservée à l’usage exclusif de ARP. À la différence des messages IP, aucune disposition n’est prise pour que le message ARP commence à un décalage arbitraire au sein du message propre, aussi la valeur dans l’octet 9 est une extension du type de message.

8.4 Décalage de fin d’en-tête

ARP utilise la convention de l’adressage à 32 bits que l’octet 15 contient le décalage par rapport au début du protocole d’utilisateur (et donc la fin des informations de protocole d’utilisateur). Noter qu’il ne s’agit pas d’un substitut des champs de décalage IP, car ce champ sert aussi de fin des informations d’en-tête HYPERchannel – un code futur de traitement de message NSC pourrait bien marquer une exception à la "mise à la poubelle" entre la fin réelle d’en-tête et le début des données d’utilisateur.

8.5 Code de type de matériel HYPERchannel

Ce nombre de 16 bits reçoit un type formel de matériel ARP de 8.

8.6 Type de protocole HYPERchannel

Sur Ethernet, ce champ est utilisé pour distinguer IP de tous les autres protocoles qui pourraient exiger la résolution d’adresse. Pour être logiquement cohérent, ce champ est identique aux octets 8 et 9 0x0600 dans un message HYPERchannel à adresse de 32 bits qui porte un datagramme IP.

8.7 Longueur d’adresse HYPERchannel

Elle contient la valeur 6, nombre d’octets suffisant pour s’accommoder des quatre octets de l’adresse HYPERchannel et des deux octets pour indiquer la plus grande taille de datagramme IP que peuvent traiter la source et la destination.

8.8 Adresse HYPERchannel de source et de destination

Ce champ contient l’adresse de domaine, réseau, et adaptateur/accès, respectivement, de source et de destination. Une valeur de 0000 dans les champs Domaine et Réseau a une signification particulière car elle est interprétée comme une demande d’envoyer et recevoir des en-têtes HYPERchannel à 16 bits plutôt qu’à 32. Si des en-têtes à 32 bits doivent être utilisés au sein d’un seul réseau HYPERchannel, les numéros de domaine et de réseau locaux peuvent être spécifiés.

9 Unité maximum de transmission

La technologie LAN d’HYPERchannel est telle que des messages de longueur illimitée peuvent être envoyés entre les hôtes. Comme le débit d’un hôte sur un réseau est généralement limité par le débit auquel les équipements de réseau peuvent fonctionner, de plus grandes tailles de transmission résultent en meilleures performances de transfert brut. Comme tous les hôtes ne sont pas capables de traiter la taille maximum de datagramme IP, un moyen plus souple de négociation de taille de MTU (unité maximum de transmission) que de simplement câbler la même valeur dans chaque hôte du réseau est nécessaire. Grâce à ce champ, chaque hôte déclare la taille maximum de datagramme IP (et non la taille du bloc de données associées) qu’il est prêt à recevoir. Les pilotes IP d’émission devraient être prêts à envoyer le minimum des tailles IP de source et de destination négociées au moment de l’ARP.

La taille de MTU envoyée se réfère à la taille maximum d’en-tête IP + les données. Elle n’inclut pas la longueur de l’en-tête matériel HYPERchannel ou d’aucun décalage entre l’en-tête et le début du datagramme IP. Comme c’est une option des hôtes émetteurs d’utiliser un décalage allant jusqu’à 44 octets, un hôte receveur doit dans tous les cas être prêt à recevoir un message propre de 64 octets et un bloc de données associées de MTU-20 (c’est à dire, 64 - 44, ou la longueur de l’en-tête IP de base).

Un exemple de paquet de 16 bits typique est :
12 octets d’en-tête matériel.
12 octets de décalage.
40 octets d’en-tête IP/TCP.
4 096 octets de données.
Cela donne une MTU de 4 136.

Un exemple de paquet de 32 bits typique est :
16 octets d’en-tête matériel.
8 octets de décalage.
40 octets d’en-tête IP/TCP.
4 096 octets de données.
Cela donne une MTU de 4 136.

Les valeurs de décalage sont choisies de telle sorte que le paquet normal cause l’alignement des données d’utilisateur sur le début de la zone des données associées. C’est une décision de la mise en œuvre, qui peut certainement être modifiée en tant que de besoin.

L’unité maximum de transmission maximale est de 65 536, la plus grande taille actuelle de datagramme IP. Pour permettre que cette valeur tienne dans un champ de 16 bits, la longueur du décalage n’est pas incluse dans la MTU. Cette taille de MTU n’est pas l’exigence qu’un hôte local soit équipé pour envoyer ou recevoir des datagrammes de cette taille ; elle indique simplement la capacité maximale de l’hôte qui reçoit.

Note sur les gabarits de circuits :

Il n’y a pas de champ pour spécifier les gabarits de circuit. C’est volontaire, car le nouveau matériel NSC contiendra des informations sur l’accessibilité des circuits, qui élimineront pour un hôte le besoin d’entretenir un affichage de la configuration matérielle. Tous les messages HYPERchannel générés suite à une réponse ARP devraient utiliser 0xFF dans le gabarit de circuit.

10 Résolution d’adresse

Cette section décrit les techniques utilisées par un pilote IP pour déterminer l’adresse et l’en-tête HYPERchannel qu’un message devrait contenir étant donné un datagramme IP contenant une adresse IP. Elle décrit les techniques qui sont locales pour des hôtes spécifiques (et peuvent donc être modifiées sans considération des activités ou techniques des autres hôtes) aussi bien que les techniques pour utiliser le protocole de résolution d’adresse sur les équipements HYPERchannel existants pour mieux gérer les adresses IP.

Elle expose aussi la migration de la résolution de nom sur une des quatre étapes suivantes.

1. Troncature de l’adresse IP pour former une adresse HYPERchannel.

2. Résolution locale des adresses HYPERchannel à travers des fichiers de configuration.

3. Résolution centralisée des adresses HYPERchannel à travers un "serveur ARP" piloté par un fichier de configuration.

4. Résolution répartie des adresses HYPERchannel en utilisant un protocole de résolution d’adresse "réel" sur de futurs supports HYPERchannel prenant en charge le mode diffusion.

10.1 Troncature d’adresse IP

Un certain nombre de mises en œuvre HYPERchannel sur IP prennent en charge des modes où l’adresse HYPERchannel est générée en plaçant les 16 bits de plus faible poids de l’adresse IP dans l’adresse TO du message propre. Cela traite plus ou moins un ensemble de boîtes HYPERchannel adressables par des adresses HYPERchannel à 16 bits comme un réseau IP de classe B.

Cette approche a l’avantage certain de la simplicité : les adresses IP sont simplement choisie pour correspondre aux adresses HYPERchannel et il n’est pas besoin de conserver de "fichiers de configuration" des adresses IP. Bien que cette approche fonctionne dans un environnement où HYPERchannel constitue entièrement un réseau de classe B, ou lorsque la connexion à un plus grand réseau IP n’est pas un problème, son utilisation à long terme est déconseillée pour plusieurs raisons :

o Cela ne marche tout simplement pas avec les adresses de classe C (l’adresse TO physique n’est pas contrôlable) ou les adresses de classe A (où les adresses d’hôte sont généralement administrées avec soin.) De plus, cela n’accepte pas les sous-réseaux. C’est donc assez incompatible avec les adresses HYPERchannel à 32 bits.

o En découplant les adresses IP et HYPERchannel par une résolution d’adresse plus complexe, les caractères des deux adresses permettent un plus grande souplesse de site : l’adresse IP devient "logique" en caractères, de sorte qu’une adresse peut se déplacer sur un site avec l’utilisateur ou l’hôte ; l’adresse HYPERchannel maintient son caractère physique de sorte qu’une adresse HYPERchannel identifie soigneusement la localisation physique de la source et de la destination au sein du réseau HYPERchannel étendu.

10.2 Résolution d’adresse locale

L’état actuel de l’art de la résolution d’adresse avec IP sur HYPERchannel fonctionne comme suit : étant donnée une adresse IP arbitraire, le pilote HYPERchannel IP cherche une entrée ayant cette adresse dans un tableau (généralement haché). Si il en trouve une, l’entrée du tableau contient les six premiers octets de l’en-tête HYPERchannel qui est utilisé pour envoyer le datagramme IP au prochain nœud IP sur l’internet. Comme des mises en œuvre telles que la IP 4.3BSD UNIX sont assez intelligentes pour fournir à leurs pilotes de niveau inférieur l’adresse IP du prochain routeur ainsi que l’adresse de destination sur l’internet (en supposant que le message n’est pas délivré localement sur l’HYPERchannel) le nombre des entrées dans ce tableau est plus ou moins gérable, car il doit seulement contenir les adresses des hôtes et routeurs IP qui sont directement accessibles sur l’HYPERchannel.

10.3 Format de fichier de configuration

Tant que cette technique de résolution d’adresse est employée, les techniques utilisées sont exclusivement locales pour l’hôte en ce sens que les techniques utilisées pour générer et mémoriser les informations dans le tableau ne sont pas pertinentes pour les autres hôtes.

On montre ici un format de fichier typique. Ce fichier devrait probablement être généré par un programme à partir d’une base de données, car les configurations asymétriques de fichier et les hôtes à rattachement multiple peuvent causer des différences dans l’acheminement physique et l’utilisation des circuits. Ce format est donné ici pour illustrer quelle sorte d’informations doivent être conservées à la couche de liaison.

Le fichier consiste en lignes de source dont chacune est de la forme :

<type> <nom-d’hôte> <circuits/fanions> <domaine/réseau> <adresse> <MTU>

par exemple :

<type> <hostname> <t/f> <dom/net> <addr> <MTU>

# Extrémité frontale aléatoire

host hyper.nsco.com FF88 0103 3702 4148

# parce qu’on veut montrer le format à 4 octets

host 192.12.102.1 FF00 0000 2203 1024

# Petits paquets, trafic interactif.

host cray-b.nas.nasa.gov FF88 0103 4401 4148

# L’autre interface, pour les gros paquets.

ahost cray-b.nas.nasa.gov FF88 0103 4501 32768

# Une interface de bouclage arrière, (quoi d’autre)

loop loop37.nsco.com FF00 0000 3700 4148

# et bien sûr, un exemple de service arp.

arpserver hcgate.nsco.com FF88 0103 7F07

Les commentaires peuvent commencer par # ou par ;.

La casse n’est significative dans aucun champ.

<type> indique le type d’entité à définir.

Les types actuellement défini sont "host," "ahost", "loop," "address," et "arpserver".

host : Ce jeton indique un hôte IP. Le champ suivant est supposé être un nom qui peut se résoudre en une adresse IP.

ahost : Ce champ indique une interface réseau supplémentaire au même hôte. Il peut être utilisé pour l’amélioration des performances.

loop : Met un fanion dans l’entrée pour cet hôte de sorte que 0xFF00 est placé dans les octets 8 et 9 du message. Cela amènera le datagramme IP à être dirigé vers l’hôte spécifié (qui doit cependant être un nom d’hôte valide) et à un bouclage arrière au sein de l’adaptateur distant. Cette facilité sert à la fois d’aide au déboguage et de preuve directe de la disponibilité de l’adaptateur réseau distant.

arpserver : Indique une adresse à utiliser pour diriger les demandes ARP sur le réseau. Si plusieurs adresses arpserver sont spécifiées, elles seront essayées tour à tour jusqu’à recevoir une réponse (ou qu’on soit à court de serveurs.) Un arpserver avec l’adresse de diffusion appropriée de FFFF FF07 causerait la mise en place d’une diffusion ARP lorsque la diffusion deviendra disponible. Les adresses de diffusion et les adresses spécifiques peuvent être utilisées en combinaison.

<nom-d’hôte> Ce champ est le nom logique de la destination. Pour un hôte, c’est le nom logique à donner au service de désignation local pour déterminer l’adresse IP associée. Ce champ peut contenir quatre nombres décimaux séparés par des points, auquel cas on suppose que c’est l’adresse IP explicite.

<circuits/fanions> Ce champ est la valeur à placer dans les octets 0 et 1 de l’en-tête de message lors de l’envoi à cet hôte. Le bit de données associées n’a pas besoin d’être fourni car le pilote doit le contrôler. Tous les autres bits sont envoyés comme ils sont fournis. Ce champ est un nombre hexadécimal.

<domaine/réseau> Ce champ est la valeur à placer dans le champ numéro de domaine et de réseau du message. Une valeur de 0000 dans ce champ indique que la destination devrait être atteinte en construisant un en-tête HYPERchannel de 16 bits, plutôt que de 32.

<adresse> Ce champ est la valeur à placer dans le champ TO de 16 bits pour atteindre le <nom-d’hôte>. Ce champ est un nombre hexadécimal.

<MTU> Ce champ contient la plus grande taille de datagramme IP que l’hôte de destination est prêt à recevoir. Ce champ est un nombre décimal ; il est facultatif. S’il n’est pas présent, une valeur de 4148 est supposée. Voir l’exposé précédent sur l’Unité maximum de transmission pour des précisions.

10.4 Serveurs ARP

Le principal problème avec la résolution d’adresse d’hôte local est que les changements ou les ajouts aux hôtes sur le réseau local doivent être répliqués sur chaque hôte HYPERchannel de ce réseau. Si cela reste gérable jusqu’à une demi douzaine d’hôtes, cela devient assez ingérable pour de plus grands réseaux. Une approche qui peut être mise en œuvre en utilisant la technologie HYPERchannel existante est d’avoir un serveur sur le réseau HYPERchannel qui fournisse l’adresse de destination HYPERchannel qui est associée à une adresse IP.

Bien que ce soit strictement un dialogue demande/réponse point à point entre deux nœuds de réseau, le protocole de résolution d’adresse qui a été à l’origine conçu pour Ethernet (mais intelligemment construit pour fonctionner avec toute paire de liaison et d’adresse réseau) effectue un excellent travail.

Les serveurs ARP peuvent être atteints simplement en plaçant l’adresse du serveur dans l’adresse TO de 32 bits du message réseau. Un serveur ARP "écoute" seulement les messages qui arrivent sur l’adresse normale bien connue ; il ne répond pas aux messages ARP en diffusion. Les pilotes IP équipé de façon appropriée devraient répondre aux messages en diffusion lorsqu’ils apparaissent.

Si un serveur ARP reçoit un message qui contient une adresse IP dont il ne sait pas comment la résoudre, il ignore le message de façon qu’un autre serveur ARP puisse être l’adresse de la prochaine tentative de la source.

Si l’adresse est résoluble, il place l’adresse HYPERchannel connue et la taille de MTU dans la réponse et les retourne à la localisation de l’adresse FROM de l’en-tête HYPERchannel.

À la différence d’un ARP en diffusion, le serveur ARP sera obligé de servir deux demandes lorsque deux hôtes qui sont initialement inconnus l’un de l’autre tentent de se mettre en relation. Comme la destination n’a pas reçu la demande ARP, elle doit contacter le serveur ARP lorsque ses protocoles de niveau supérieur génèrent d’abord un datagramme pour répondre au premier datagramme IP de la source qui arrive jusqu’à la destination.

Le fichier de configuration de source décrit dans la section précédente a été explicitement conçu pour suffire comme base de données pour un serveur ARP aussi bien que pour un hôte individuel.

10.5 ARP en diffusion

Lorsque un réseau HYPERchannel local contient une capacité de diffusion, tout pilote IP qui souhaite effectuer une résolution d’adresse HYPERchannel peut être configuré pour émettre le message ARP en diffusion plutôt qu’à une adresse bien connue. Les pilotes IP sur les autres hôtes sont censés savoir si leur interface HYPERchannel locale peut envoyer des messages en diffusion ; s’ils le peuvent, ils s’arrangent pour "écouter" sur l’adresse TO de diffusion FF07 pour ARP.

Le traitement de la réception d’un message ARP en diffusion est autrement identique à celui de la RFC-826 :

o Il n’est répondu aux messages que si et seulement si le pilote IP de destination fait autorité pour l’adresse IP désignée.

o Chaque fois qu’un message ARP est traité, le pilote IP prend l’adresse HYPERchannel de source et la taille de MTU et les ajoute à ses tableaux de résolution d’adresse. Et donc le pilote est équipé pour orienter le datagramme IP qui arrive de l’hôte de destination lorsque le contact est fait.

Chaque pilote IP peut avoir des résolutions d’adresse qui sont établies grâce à un tableau d’acheminement statique (le fichier de configuration spécifié plus haut). Si les informations d’ARP arrivent en contradiction d’une entrée statique (par opposition aux informations d’ARP précédemment établies de façon dynamique) elles devraient alors être ignorées. Cette décision est prise en faisant l’hypothèse que le seul objet utile de l’acheminement statique dans un environnement de diffusion ARP est d’ajouter l’authentification, car il est facile de mentir avec ARP.

Appendice A. Architecture et adressage de produit NSC

Cette section est destinée à donner une révision concise de l’état de l’art dans les réseaux NSC et des techniques qu’ils fournissent pour la livraison des messages. Ceux qui sont bien familiarisés avec HYPERchannel peuvent souhaiter sauter cette section ; cependant, il y a des matériaux sur de nouvelles technologies et formats d’adressage qui ne sont pas encore très bien connus de la plupart des consommateurs de NSC.

A.1 Technologies HYPERchannel de systèmes réseau

Network Systems fabrique plusieurs technologies de réseau différentes qui utilisent des supports et des commandes de liaison très différents, mais fournissent une interface d’hôte commune au sens à la fois du protocole et du matériel. Ces quatre technologies sont :

o HYPERchannel A – Réseau CSMA à 50 mégabits, en bande de base, avec évitement de collision, qui utilise un bus en câble coaxial. Des "adaptateurs de réseau" HYPERchannel individuels peuvent contrôler jusqu’à quatre de ces "circuits" sur câble coaxial fournissant jusqu’à 200 mégabits de capacité sur un réseau pleinement interconnecté. HYPERchannel A est le premier produit de NSC et a été en production depuis 1977. Il est principalement utilisé pour interconnecter les plus grands ordinateurs et des périphériques de systèmes centraux à grande vitesse tels que des dévideurs de bandes magnétiques et des imprimantes laser.

o HYPERchannel B – Réseau CSMA à 10 mégabits, en bande de base, avec évitement de collision, qui utilise un seul bus en coaxial. Cette technologie est utilisée pour des communications directes d’hôte à hôte sous le nom de HYPERchannel B, et pour des connexions de terminaux sous le nom de HYPERbus. Il est actuellement utilisé pour trois applications majeures – réseaux locaux de terminaux ASCII , réseaux de terminaux IBM 3270, et communications d’hôtes à hôtes de plus petits ordinateurs.

o DATAPIPE[3] -- Réseau "cœur de chaîne" en fibre optique à 275 mégabits qui interconnecte des réseaux de zone locale à plus faibles vitesses dans une portée de 30 kilomètres, et pour fournir un réseau de très hautes performances pour la prochaine génération de supercalculateurs et systèmes de mémorisation optique. Une version prototype de DATApipe est actuellement en cours de développement sur le site d’un client.

o Extensions de distance de ponts et de réseau -- NSC a rapidement découvert que ses clients voulaient de très hautes vitesses sur des zones géographiques, et pas seulement dans la gamme des quelques kilomètres qui sont concevables avec un réseau en câble coaxial. Depuis 1978, NSC a commencé à construire une série "d’adaptateurs de liaison" qui sont des ponts intégraux entre les réseaux de zone locale. Ces adaptateurs de liaison prennent en charge des supports de communication à grande vitesse tels que les circuits Telco T1, des micro-ondes privées, des liaisons satellite à grande vitesse, des connexions point à point en fibre optique.

A.2 Rattachement aux ordinateurs hôtes

Les interfaces à grande vitesse de Network Systems utilisent les techniques de rattachement des périphériques aux plus grandes vitesses du fabricant afin de réaliser les taux de transfert par salves de dizaines de mégabits par seconde. Ces techniques de rattachement entrent dans trois catégories :

A.2.1 Rattachement de canal de données "cœur de chaîne"

L’adaptateur de réseau contient des tableaux d’interface et des micrologiciels à câbler au canal de données du fabricant, comme cela serait fait avec un disque ou un contrôleur de bande. Les adaptateurs de réseau de cœur de chaîne n’émulent aucun appareil d’un fabricant existant (comme un pilote de bande magnétique) mais sont pris en charge par des logiciels qui formatent le canal et l’adaptateur pour envoyer et recevoir des messages réseau.

Les modèles d’adaptateurs HYPERchannel sont disponibles essentiellement pour les grands ordinateurs dans le monde entier.

A.2.2 Rattachement de mini-ordinateurs et de stations de travail

Comme l’adaptateur réseau contient des logiciels coûteux à grande vitesse, une technique différente est utilisée pour fournir le rattachement des mini-ordinateurs et stations de travail.

Dans ce cas, NSC fournit un contrôleur DMA conçu pour une connexion directe au bus de plan arrière de ce miniordinateur. Ces contrôleurs DMA acceptent des fonctions et des blocs de données en salves provenant de la mémoire de l’hôte vers un canal de câble qui est connecté à un des quatre accès d’un "adaptateur d’ordinateur à usage général". Cet adaptateur multiplexe les transmissions de et vers les circuits HYPERchannel jusqu’à quatre processeurs rattachés.

A.2.3 Coprocesseurs de réseau

Pour environ dix systèmes de bus différents, Network Systems fournit un contrôleur DMA "intelligent" qui contient de la mémoire embarquée et un processeur de protocole Motorola 68010.

Cette classe d’interface fonctionne à travers l’accès direct du coprocesseur réseau. Les paquets de demande transmis et reçus du réseau sont placés dans une zone de "boîte aux lettres" commune et extraits par le coprocesseur. Le coprocesseur lit et écrit la mémoire système selon ce qui est nécessaire pour servir les demandes réseau dans le bon ordre. Les coprocesseurs fournissent actuellement un service pour lire ou écrire les messages réseau (appelé service Pilote car il est plus ou moins identique au pilote DMA muet HYPERchannel) et un service pour NETEX, qui est le protocole de communications de style OSI de NSC.

Appendice B. Protocoles HYPERchannel des systèmes réseau

Les protocoles mis en œuvre par NSC au sein de ses propres boîtes sont conçus pour les besoins des différentes technologies. Voici un résumé compact de ces protocoles :

Sans entrer dans un luxe de détails sur ces protocoles internes, quelques points sont particulièrement intéressants pour les concepteurs de systèmes :

o Les trois technologies fournissent la même interface à l’ordinateur hôte ou au coprocesseur réseau, un service d’envoi et de réception de messages réseau qui sont des datagrammes qui présentent pour l’hôte l’avantage que chacun contient des informations suffisantes pour délivrer le message de et par lui-même. Comme ce datagramme et ses champs d’en-tête sont du plus haut intérêt pour la mise en œuvre d’hôte, il est exposé en détail ci-dessous.

o Toutes les technologies utilisent des accusés de réception à un très bas niveau pour déterminer si les paquets ont bien été livrés. En plus de permettre un mécanisme de contention à réglage fin pour le support coaxial, il permet aussi à HYPERchannel A d’équilibrer la charge sur plusieurs câbles coaxiaux – un élément qui s’est révélé être très difficile sur Ethernet par exemple.

o Toutes les boîtes vont à une certaine distance pour s’assurer que les ressources existent dans la boîte receveuse avant que la transmission réelle n’ait lieu. HYPERchannel B utilise un circuit virtuel qui supporte plusieurs secondes d’inactivité après la première tentative d’un hôte d’envoyer un message à l’autre. Le trafic sur ces "circuits virtuels de travail" est à flux contrôlés de la source à la destination et les ressources de mémoire tampon sont réservées pour le chemin.

HYPERchannel A échange des trames à très hauts débits pour déterminer si le receveur est prêt à recevoir des données et contrôles ses flux lorsque les données se déplacent à travers le réseau.

Le délai de propagation de DATApipe est relativement long comparé au temps nécessaire pour envoyer un paquet interne de 2 K à 4 Koctets. Il en résulte que les contrôleurs DATApipe utilisent un protocole de transport rationalisé de type TP4 pour assurer la livraison des trames entre les boîtes DATApipe.

Références

[1] HYPERchannel est une marque déposée de Network Systems Corporation.

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

[3] DATApipe est une marque déposée de Network Systems Corporation.