Systèmes réseau Xerox - Xerox Network Systems

XNS

Pile de protocoles
Objectif	LAN
Développeur (s)	Photocopier
Introduit	1977 ; Il y a 44 ans  ( 1977 )
Influencé	3 + Partager , Net / One, IPX / SPX , VINES
Matériel	Ethernet

Xerox Network Systems ( XNS ) est une suite de protocoles de mise en réseau informatique développée par Xerox dans le cadre de l' architecture des systèmes de réseau Xerox . Il a fourni des communications réseau à usage général, le routage interréseau et la livraison de paquets, ainsi que des fonctions de niveau supérieur telles qu'un flux fiable et des appels de procédure à distance . XNS a précédé et influencé le développement du modèle de réseau OSI ( Open Systems Interconnection ) et a été très influent dans les conceptions de réseaux locaux au cours des années 1980. Cependant, cela a eu peu d'impact sur TCP / IP , qui a été conçu plus tôt.

XNS a été développé par le département de développement des systèmes Xerox au début des années 80, chargé de commercialiser les recherches de Xerox Parc . XNS était basé sur la suite PARC Universal Packet (PUP) antérieure (et tout aussi influente) de la fin des années 1970. Certains des protocoles de la suite XNS étaient des versions légèrement modifiées de ceux de la suite Pup. XNS a ajouté le concept d'un numéro de réseau, permettant de construire de plus grands réseaux à partir de plusieurs plus petits, avec des routeurs contrôlant le flux d'informations entre les réseaux.

Les spécifications de la suite de protocoles pour XNS ont été placées dans le domaine public en 1977. Cela a aidé XNS à devenir le protocole de réseau local canonique , copié à divers degrés par pratiquement tous les systèmes de réseau utilisés dans les années 1990. XNS a été utilisé inchangé par 3Com 's 3 + Partager et Ungermann-Bass Net / One s. Il a également été utilisé, avec des modifications, comme base pour Novell NetWare et Banyan VINES . XNS a été utilisé comme base pour le système AppleNet , mais cela n'a jamais été commercialisé; un certain nombre de solutions XNS aux problèmes courants ont été utilisées dans le remplacement d'AppleNet, AppleTalk .

La description

Conception générale

Par rapport aux 7 couches du modèle OSI , XNS est un système à cinq couches, comme la suite de protocoles Internet plus récente .

Les couches physique et liaison de données du modèle OSI correspondent à la couche physique (couche 0) dans XNS, qui a été conçue pour utiliser le mécanisme de transport du matériel sous-jacent et ne séparait pas la liaison de données. Plus précisément, la couche physique de XNS est en réalité le système de réseau local Ethernet , également développé par Xerox en même temps, et un certain nombre de ses décisions de conception reflètent ce fait. Le système a été conçu pour permettre à Ethernet d'être remplacé par un autre système, mais cela n'a pas été défini par le protocole (et n'a pas dû l'être).

La partie principale de XNS est sa définition de la couche de transport interne (couche 1), qui correspond à la couche réseau d'OSI, et c'est ici que le protocole d'interréseau principal, IDP, est défini. XNS a combiné les couches Session et Transport de l'OSI en une seule couche de communications interprocessus (couche 2). La couche 3 était le contrôle des ressources, similaire à la présentation de l'OSI.

Enfin, au-dessus des deux modèles, se trouve la couche Application, bien que ces couches n'aient pas été définies dans la norme XNS.

Protocole interréseau de base

La principale Internetwork couche de protocole est le protocole Internet Datagram ( de personnes déplacées ). IDP est un descendant proche du protocole interréseau de Pup et correspond à peu près à la couche IP ( Internet Protocol ) de la suite de protocoles Internet.

IDP utilise l'adresse 48 bits d'Ethernet comme base pour son propre adressage réseau , en utilisant généralement l' adresse MAC de la machine comme identifiant unique principal. A cela s'ajoute une autre section d'adresse de 48 bits fournie par l'équipement réseau; 32 bits sont fournis par les routeurs pour identifier le numéro de réseau dans l'interréseau, et 16 bits supplémentaires définissent un numéro de socket pour la sélection de service au sein d'un seul hôte. La partie de numéro de réseau de l'adresse comprend également une valeur spéciale qui signifiait "ce réseau", pour une utilisation par des hôtes qui ne connaissaient pas (encore) leur numéro de réseau.

Contrairement à TCP / IP, les numéros de socket font partie de l'adresse réseau complète dans l'en-tête IDP, de sorte que les protocoles de couche supérieure n'ont pas besoin d'implémenter le démultiplexage; IDP fournit également des types de paquets (encore une fois, contrairement à IP). IDP contient également une somme de contrôle couvrant l'intégralité du paquet, mais elle est facultative et non obligatoire. Cela reflète le fait que les réseaux locaux ont généralement de faibles taux d'erreur, de sorte que XNS a supprimé la correction d'erreur des protocoles de niveau inférieur afin d'améliorer les performances. La correction d'erreurs pourrait être éventuellement ajoutée à des niveaux plus élevés dans la pile de protocoles, par exemple, dans le propre protocole SPP de XNS. XNS était largement considéré comme plus rapide que IP en raison de cette note de conception.

Conformément aux connexions LAN à faible latence sur lesquelles il s'exécute, XNS utilise une taille de paquet courte, ce qui améliore les performances en cas de faibles taux d'erreur et de délais d'exécution courts. Les paquets IDP ont une longueur maximale de 576 octets, y compris l'en- tête IDP de 30 octets . En comparaison, IP exige que tous les hôtes prennent en charge au moins 576, mais prend en charge les paquets jusqu'à 65 Ko. Les paires d'hôtes XNS individuelles sur un réseau particulier peuvent utiliser des paquets plus volumineux, mais aucun routeur XNS n'est requis pour les gérer, et aucun mécanisme n'est défini pour découvrir si les routeurs intermédiaires prennent en charge des paquets plus volumineux. De plus, les paquets ne peuvent pas être fragmentés, comme ils le peuvent dans IP.

Le Routing Information Protocol (RIP), un descendant du Pup's Gateway Information Protocol , est utilisé comme système d'échange d'informations du routeur et (légèrement modifié pour correspondre à la syntaxe des adresses d'autres suites de protocoles), reste utilisé aujourd'hui dans d'autres suites de protocoles. , comme la suite de protocoles Internet.

XNS implémente également un protocole d'écho simple au niveau de la couche interréseau, similaire au ping d'IP , mais fonctionnant à un niveau inférieur dans la pile réseau. Au lieu d'ajouter les données ICMP en tant que charge utile dans un paquet IP, comme dans le ping, l'écho de XNS a placé la commande directement dans le paquet IDP sous-jacent. La même chose pourrait être obtenue dans IP en développant le champ Protocole ICMP de l'en-tête IP.

Protocoles de couche de transport

Il existe deux protocoles de couche de transport principaux, tous deux très différents de leur prédécesseur Pup:

• Le protocole SPP ( Sequenced Packet Protocol ) est un protocole de transport reconnu, analogue à TCP ; une différence technique principale est que les numéros de séquence comptent les paquets, et non les octets comme dans TCP et le BSP de PUP; c'est l'antécédent direct de l' IPX / SPX de Novell .
• Le protocole PEP ( Packet Exchange Protocol ) est un protocole non fiable sans connexion, de nature similaire à UDP et à l'antécédent du PXP de Novell .

XNS, comme Pup, utilise également EP , le protocole d'erreur , comme système de rapport pour les problèmes tels que les paquets perdus. Cela a fourni un ensemble unique de paquets qui peuvent être filtrés pour rechercher des problèmes.

Protocoles d'application

Courrier RPC

Dans le concept original de Xerox, les protocoles d'application tels que l'impression, le classement et l'envoi à distance , etc., utilisaient un protocole d' appel de procédure à distance appelé Courier . Courier contenait des primitives pour implémenter la plupart des fonctionnalités des appels de fonction du langage de programmation Mesa de Xerox . Les applications devaient sérialiser et désérialiser manuellement les appels de fonction dans Courier; il n'y avait pas de fonction automatique pour traduire une trame d'activation de fonction en un RPC (c'est-à-dire qu'aucun «compilateur RPC» n'était disponible). Étant donné que Courier était utilisé par toutes les applications, les documents de protocole d'application XNS ne spécifiaient que les interfaces d'appel de fonction de messagerie et les tuples de liaison module + fonction. Il y avait une fonction spéciale dans Courier pour permettre à un appel de fonction d'envoyer ou de recevoir des données en masse.

Initialement, la localisation du service XNS était effectuée via la diffusion d'appels de procédure à distance à l'aide d'une série de diffusions en anneau en expansion (en consultation avec le routeur local, pour obtenir des réseaux à des distances croissantes.) Plus tard, le service d'annuaire à 3 niveaux du protocole Clearinghouse a été créé pour effectuer l'emplacement du service, et les diffusions en boucle d'expansion ont été utilisées uniquement pour localiser un centre d'échange initial.

En raison de son intégration étroite avec Mesa en tant que technologie sous-jacente, de nombreux protocoles traditionnels de niveau supérieur ne faisaient pas partie du système XNS lui-même. Cela signifiait que les fournisseurs utilisant les protocoles XNS ont tous créé leurs propres solutions pour le partage de fichiers et la prise en charge des imprimantes . Alors que beaucoup de ces produits tiers pouvaient théoriquement communiquer entre eux au niveau des paquets, il y avait peu ou pas de capacité à appeler les services d'application de l'autre. Cela a conduit à une fragmentation complète du marché XNS et a été cité comme l'une des raisons pour lesquelles la propriété intellectuelle l'a facilement remplacé.

Authentification

Les protocoles XNS comprenaient également un protocole d'authentification et un service d'authentification pour le prendre en charge. Ses «informations d'identification fortes» étaient basées sur le même protocole Needham – Schroeder qui a ensuite été utilisé par Kerberos. Après avoir contacté le service d'authentification pour les informations d'identification, ce protocole a fourni un moyen léger de signer numériquement les appels de procédure Courier, afin que les destinataires puissent vérifier la signature et authentifier les expéditeurs sur Internet XNS, sans avoir à contacter à nouveau le service d'authentification pour la durée du session de communication de protocole.

Impression

Le langage d'impression de Xerox, Interpress , était une norme au format binaire pour contrôler les imprimantes laser. Les concepteurs de ce langage, John Warnock et Chuck Geschke, ont ensuite quitté Xerox PARC pour démarrer Adobe Systems . Avant de partir, ils ont réalisé la difficulté de spécifier un langage d'impression binaire, où les fonctions de sérialisation du travail d'impression étaient lourdes et qui rendaient difficile le débogage des travaux d'impression errants. Pour réaliser l'intérêt de spécifier un travail d'impression à la fois programmable et facilement déboguable en ASCII, Warnock et Geschke ont créé le langage Postscript comme l'un de leurs premiers produits chez Adobe.

Protocoles de débogage à distance

Étant donné que les 8000+ machines de l'intranet d'entreprise Xerox exécutaient l'architecture Wildflower (conçue par Butler Lampson), il existait un protocole de débogage à distance pour le microcode. Fondamentalement, une fonction peek and poke pourrait arrêter et manipuler l'état du microcode d'une machine de la série C ou de la série D, n'importe où sur la terre, puis redémarrer la machine.

En outre, il y avait un protocole de débogage à distance pour le débogueur d'échange de monde. Ce protocole pourrait, via le débogueur "nub", geler un poste de travail, puis jeter un coup d'œil et piquer diverses parties de la mémoire, changer les variables et continuer l'exécution. Si des symboles de débogage étaient disponibles, une machine en panne pourrait être déboguée à distance depuis n'importe où sur terre.

Histoire

Origines d'Ethernet et de PUP

Au cours de sa dernière année à l'Université de Harvard , Bob Metcalfe a commencé à interviewer dans un certain nombre d'entreprises et a été chaleureusement accueilli par Jerry Elkind et Bob Taylor de Xerox PARC , qui commençaient à travailler sur les postes de travail informatiques en réseau qui deviendraient le Xerox Alto . Il a accepté de rejoindre le PARC en juillet, après avoir soutenu sa thèse. En 1970, alors qu'il surfait sur un canapé au domicile de Steve Crocker alors qu'il assistait à une conférence, Metcalfe prit une copie des Actes de la conférence informatique conjointe d'automne dans le but de s'endormir en la lisant. Au lieu de cela, il est devenu fasciné par un article sur ALOHAnet , un ancien système de réseau étendu. En juin, il avait développé ses propres théories sur le réseautage et les avait présentées à ses professeurs, qui l'ont rejetée et il a été «jeté sur mon cul».

Metcalfe a été accueilli au PARC malgré sa thèse infructueuse, et a rapidement commencé le développement de ce qui était alors appelé "ALOHAnet dans un fil". Il a fait équipe avec David Boggs pour aider à la mise en œuvre électronique, et à la fin de 1973, ils construisaient du matériel fonctionnel à 3 Mbit / s. La paire a alors commencé à travailler sur un protocole simple qui fonctionnerait sur le système. Cela a conduit au développement du système PARC Universal Packet (Pup), et à la fin de 1974, Pup fonctionnait avec succès sur Ethernet. Ils ont déposé un brevet sur les concepts, Metcalfe ajoutant plusieurs autres noms parce qu'il pensait qu'ils méritaient d'être mentionnés, puis ont soumis un article sur le concept aux communications de l'ACM sur "Ethernet: commutation de paquets distribués pour les réseaux informatiques locaux", publié en juillet 1976.

PUP à XNS

En 1975, bien avant que PUP ne soit terminé, Metcalfe se frottait déjà sous la direction rigide de Xerox. Il pensait que l'entreprise devrait immédiatement mettre Ethernet en production, mais n'a trouvé que peu d'intérêt de la part de la haute direction. Un événement majeur a eu lieu quand les professeurs de MIT célèbre de Laboratoire d' intelligence artificielle approché Xerox en 1974 avec l'intention d'Ethernet d'achat pour une utilisation dans leur laboratoire. La direction de Xerox a refusé, estimant qu'Ethernet était mieux utilisé pour aider à vendre leur propre équipement. Le AI Lab allait ensuite créer sa propre version d'Ethernet, Chaosnet .

Metcalfe a finalement quitté Xerox en novembre 1975 pour Transaction Technology, une division de Citibank chargée du développement de produits avancés. Cependant, il a été attiré chez Xerox sept mois plus tard par David Liddle , qui avait récemment organisé la division de développement de systèmes au sein de Xerox spécifiquement pour mettre sur le marché les concepts de PARC. Metcalfe a immédiatement commencé à repenser Ethernet pour qu'il fonctionne à 20 Mbit / s et a commencé un effort pour réécrire Pup dans une version de qualité de production. Cherchant de l'aide sur Pup, Metcalfe a approché Yogin Dalal , qui terminait alors sa thèse sous la direction de Vint Cerf à l'Université de Stanford . Dalal a été également fortement recruté par Bob Kahn de ARPANET équipe (travail sur TCP / IP), mais quand Cerf gauche pour rejoindre la DARPA , Dalal a accepté de passer au PARC et il a commencé en 1977.

Dalal a formé une équipe comprenant William Crowther et Hal Murray, et a commencé par un examen complet de Pup. Dalal a également tenté de rester impliqué dans les efforts TCP en cours à la DARPA, mais a finalement abandonné et s'est concentré entièrement sur Pup. Dalal a combiné son expérience avec ARPANET avec les concepts de Pup et à la fin de 1977, ils avaient publié la première ébauche de la spécification Xerox Network System. Il s'agissait essentiellement d'une version de Pup avec le concept supplémentaire de sockets et d'un interréseau, qui permettait aux routeurs de transférer des paquets sur des réseaux connectés.

Au début de 1978, le nouveau système fonctionnait, mais la direction ne faisait toujours rien pour le commercialiser. Comme l'a dit Metcalfe:

Lorsque je suis revenu chez Xerox en 1976, nous étions à environ deux ans et demi de l'expédition du produit et en 1978, à environ deux ans et demi de l'expédition du produit.

Lorsqu'aucune autre action ne fut entreprise, Metcalfe quitta l'entreprise à la fin de 1978.

Impacter

Utilisé pour la dernière fois par Xerox pour communiquer avec le système de publication DocuTech 135, XNS n'est plus utilisé en raison de l'omniprésence de l'IP. Cependant, il a joué un rôle important dans le développement de la technologie de réseau dans les années 1980, en incitant les fournisseurs de logiciels et de matériel à considérer sérieusement la nécessité pour les plates-formes informatiques de prendre en charge simultanément plusieurs piles de protocoles réseau.

Une grande variété de systèmes de réseau propriétaires étaient directement basés sur XNS ou offraient des variations mineures sur le thème. Parmi ceux-ci figuraient Net / One, 3+, Banyan VINES et IPX / SPX de Novell . Ces systèmes ont ajouté leurs propres concepts en plus du système d'adressage et de routage XNS; VINES a ajouté un service d'annuaire parmi d'autres services, tandis que Novell NetWare a ajouté un certain nombre de services destinés aux utilisateurs tels que l'impression et le partage de fichiers. AppleTalk utilisait un routage de type XNS, mais avait des adresses incompatibles utilisant des numéros plus courts.

XNS a également aidé à valider la conception du sous-système de réseau 4.2BSD en fournissant une deuxième suite de protocoles, qui était significativement différente des protocoles Internet; en implémentant les deux piles dans le même noyau, les chercheurs de Berkeley ont démontré que la conception convenait à plus que la simple propriété intellectuelle. Des modifications BSD supplémentaires ont finalement été nécessaires pour prendre en charge la gamme complète des protocoles d' interconnexion de systèmes ouverts (OSI).

Voir également

• Guerres de protocole

• Norme de code de caractère Xerox

Les références

Citations

Bibliographie

Liens externes

• Architecture des systèmes réseau Xerox: Introduction aux systèmes réseau Xerox
• Architecture des systèmes réseau Xerox: Manuel d'informations générales
• Exemple d'implémentation réelle dans l'espace noyau