Xerox-Netzwerksysteme - Xerox Network Systems

XNS
Protokollstapel
Zweck LAN
Entwickler Xerox
Eingeführt 1977 ; Vor 44 Jahren  ( 1977 )
Beeinflusst 3 + Share , Net / One, IPX / SPX , VINES
Hardware Ethernet

Xerox Network Systems ( XNS ) ist eine von Xerox im Rahmen der Xerox Network Systems Architecture entwickelte Protokollsuite für Computernetzwerke . Es bot allgemeine Netzwerkkommunikation, Internetwork- Routing und Paketzustellung sowie Funktionen auf höherer Ebene wie einen zuverlässigen Stream und Remoteprozeduraufrufe . XNS war älter als die Entwicklung des OSI-Netzwerkmodells ( Open Systems Interconnection ) und hatte in den 1980er Jahren großen Einfluss auf das lokale Netzwerkdesign . Es hatte jedoch nur geringe Auswirkungen auf TCP / IP , das zuvor entwickelt wurde.

XNS wurde Anfang der 1980er Jahre von der Xerox-Systementwicklungsabteilung entwickelt, die damit beauftragt war, die Forschung von Xerox Parc auf den Markt zu bringen. XNS basiert auf der früheren (und ebenso einflussreichen ) Suite PARC Universal Packet (PUP) aus den späten 1970er Jahren. Einige der Protokolle in der XNS-Suite waren leicht modifizierte Versionen der Protokolle in der Pup-Suite. XNS fügte das Konzept einer Netzwerknummer hinzu, mit der größere Netzwerke aus mehreren kleineren aufgebaut werden können, wobei Router den Informationsfluss zwischen den Netzwerken steuern.

Die Spezifikationen der Protokollsuite für XNS wurden 1977 öffentlich zugänglich gemacht . Dies half XNS, das kanonische lokale Netzwerkprotokoll zu werden , das von praktisch allen in den 1990er Jahren verwendeten Netzwerksystemen in unterschiedlichem Maße kopiert wurde. XNS wurde unverändert verwendet von 3Com 's 3 + Teile und Ungermann-Bass ' s Net / One. Mit Modifikationen wurde es auch als Grundlage für Novell NetWare und Banyan VINES verwendet . XNS wurde als Basis für das AppleNet- System verwendet, dies wurde jedoch nie kommerzialisiert. Eine Reihe von XNS-Lösungen für häufig auftretende Probleme wurden beim AppleNet-Ersatz AppleTalk verwendet .

Beschreibung

Gesamtkonzept

Im Vergleich zu den 7 Schichten des OSI-Modells ist XNS ein fünfschichtiges System, wie die spätere Internetprotokollsuite .

Die physischen und Datenverbindungsschichten des OSI-Modells entsprechen der physischen Schicht (Schicht 0) in XNS, die den Transportmechanismus der zugrunde liegenden Hardware verwendet und die Datenverbindung nicht trennt. Insbesondere ist die physische Schicht von XNS tatsächlich das lokale Ethernet- Netzwerksystem , das gleichzeitig von Xerox entwickelt wird, und eine Reihe seiner Entwurfsentscheidungen spiegeln diese Tatsache wider. Das System wurde so konzipiert, dass Ethernet durch ein anderes System ersetzt werden kann, dies wurde jedoch nicht durch das Protokoll definiert (und musste es auch nicht sein).

Der Hauptteil von XNS ist die Definition der internen Transportschicht (Schicht 1), die der Netzwerkschicht von OSI entspricht, und hier wird das primäre Internetworking-Protokoll IDP definiert. XNS kombinierte die Sitzungs- und Transportschichten des OSI zu einer einzigen Interprozesskommunikationsschicht (Schicht 2). Schicht 3 war Resource Control, ähnlich wie die Präsentation des OSI.

Über beiden Modellen befindet sich schließlich die Anwendungsschicht, obwohl diese Schichten im XNS-Standard nicht definiert wurden.

Grundlegendes Netzwerkprotokoll

Das Hauptinterschicht - Protokoll ist das Internet Datagram Protocol ( IDP ). IDP ist ein enger Nachkomme des Internetwork-Protokolls von Pup und entspricht in etwa der IP-Schicht ( Internet Protocol ) in der Internet Protocol Suite.

IDP verwendet die 48-Bit-Adresse von Ethernet als Grundlage für seine eigene Netzwerkadressierung und verwendet im Allgemeinen die MAC-Adresse des Geräts als primäre eindeutige Kennung. Dazu kommt ein weiterer 48-Bit-Adressabschnitt, der von den Netzwerkgeräten bereitgestellt wird. 32-Bit werden von Routern bereitgestellt , um die Netzwerknummer im Netzwerk zu identifizieren, und weitere 16-Bit definieren eine Socket-Nummer für die Dienstauswahl innerhalb eines einzelnen Hosts. Der Netzwerknummernabschnitt der Adresse enthält auch einen speziellen Wert, der "dieses Netzwerk" bedeutet, zur Verwendung durch Hosts, die ihre Netzwerknummer (noch) nicht kannten.

Im Gegensatz zu TCP / IP sind Socket-Nummern Teil der vollständigen Netzwerkadresse im IDP-Header, sodass Protokolle der oberen Schicht kein Demultiplexing implementieren müssen. IDP liefert auch Pakettypen (wiederum im Gegensatz zu IP). IDP enthält auch eine Prüfsumme, die das gesamte Paket abdeckt, ist jedoch optional und nicht obligatorisch. Dies spiegelt die Tatsache wider, dass LANs im Allgemeinen niedrige Fehlerraten aufweisen. Daher hat XNS die Fehlerkorrektur aus den Protokollen niedrigerer Ebene entfernt, um die Leistung zu verbessern. Die Fehlerkorrektur kann optional auf höheren Ebenen im Protokollstapel hinzugefügt werden, beispielsweise im XNS-eigenen SPP-Protokoll. XNS wurde aufgrund dieses Designhinweises allgemein als schneller als IP angesehen.

In Übereinstimmung mit den LAN-Verbindungen mit geringer Latenz, auf denen es ausgeführt wird, verwendet XNS eine kurze Paketgröße, die die Leistung bei niedrigen Fehlerraten und kurzen Durchlaufzeiten verbessert. IDP-Pakete sind bis zu 576 Byte lang, einschließlich des 30-Byte-IDP- Headers . Im Vergleich dazu müssen alle Hosts für IP mindestens 576 unterstützen, unterstützen jedoch Pakete mit bis zu 65 KByte. Einzelne XNS-Hostpaare in einem bestimmten Netzwerk verwenden möglicherweise größere Pakete, es ist jedoch kein XNS-Router erforderlich, um sie zu verarbeiten, und es ist kein Mechanismus definiert, um festzustellen, ob die dazwischenliegenden Router größere Pakete unterstützen. Außerdem können Pakete nicht wie in IP fragmentiert werden.

Das Routing Information Protocol (RIP), ein Nachkomme des Gateway Information Protocol von Pup , wird als Router-Informationsaustauschsystem verwendet und wird (geringfügig geändert, um der Syntax der Adressen anderer Protokollsuiten zu entsprechen) bis heute in anderen Protokollsuiten verwendet , wie die Internet Protocol Suite.

XNS implementiert auch ein einfaches Echo-Protokoll auf der Internetwork-Ebene, ähnlich dem Ping von IP , arbeitet jedoch auf einer niedrigeren Ebene im Netzwerkstapel. Anstatt die ICMP-Daten wie beim Ping als Nutzdaten in ein IP-Paket einzufügen, platzierte das XNS-Echo den Befehl direkt im zugrunde liegenden IDP-Paket. Dasselbe kann bei IP erreicht werden, indem das Feld ICMP- Protokoll des IP-Headers erweitert wird.

Transportschichtprotokolle

Es gibt zwei Protokolle der primären Transportschicht, die sich stark von ihrem Pup-Vorgänger unterscheiden:

  • Das Sequenced Packet Protocol ( SPP ) ist ein anerkanntes Transportprotokoll, analog zu TCP . Ein technischer Hauptunterschied besteht darin, dass die Sequenznummern die Pakete zählen und nicht die Bytes wie in TCP und PUPs BSP. Es ist der direkte Vorläufer von Novells IPX / SPX .
  • Das Packet Exchange Protocol ( PEP ) ist ein verbindungsloses, nicht zuverlässiges Protokoll, das UDP ähnelt und dem PXP von Novell vorausgeht.

XNS verwendet wie Pup auch EP , das Fehlerprotokoll , als Berichtssystem für Probleme wie verworfene Pakete. Dies lieferte einen einzigartigen Satz von Paketen, die gefiltert werden können, um nach Problemen zu suchen.

Anwendungsprotokolle

Kurier RPC

Im ursprünglichen Xerox-Konzept verwendeten Anwendungsprotokolle wie Remote-Drucken, Ablegen und Versenden usw. ein Remote-Prozedur- Aufrufprotokoll namens Courier . Courier enthielt Grundelemente, um die meisten Funktionen der Funktionsaufrufe der Mesa-Programmiersprache von Xerox zu implementieren . Anwendungen mussten Funktionsaufrufe in Courier manuell serialisieren und de-serialisieren. Es gab keine automatische Möglichkeit, einen Funktionsaktivierungsrahmen in einen RPC zu übersetzen (dh es war kein "RPC-Compiler" verfügbar). Da Courier von allen Anwendungen verwendet wurde, wurden in den XNS-Anwendungsprotokolldokumenten nur Schnittstellen für Kurierfunktionsaufrufe und Modul + Funktionsbindungstupel angegeben. In Courier gab es eine spezielle Einrichtung, mit der ein Funktionsaufruf Massendaten senden oder empfangen konnte.

Anfänglich wurde der Standort des XNS-Dienstes über das Senden von Remoteprozeduraufrufen unter Verwendung einer Reihe von expandierenden Ringsendungen ausgeführt (in Absprache mit dem lokalen Router, um Netzwerke in zunehmender Entfernung zu erhalten). Später wurde der 3-Ebenen-Verzeichnisdienst des Clearinghouse-Protokolls für die Ausführung erstellt Der Servicestandort und die Erweiterungsringsendungen wurden nur verwendet, um ein erstes Clearinghouse zu lokalisieren.

Aufgrund der engen Integration mit Mesa als zugrunde liegender Technologie waren viele der traditionellen übergeordneten Protokolle nicht Teil des XNS-Systems. Dies bedeutete, dass Anbieter, die die XNS-Protokolle verwendeten, alle ihre eigenen Lösungen für die Dateifreigabe und Druckerunterstützung entwickelten . Während viele dieser Produkte von Drittanbietern theoretisch auf Paketebene miteinander kommunizieren konnten, gab es kaum oder gar keine Möglichkeit, die Anwendungsdienste des jeweils anderen aufzurufen. Dies führte zu einer vollständigen Fragmentierung des XNS-Marktes und wurde als einer der Gründe dafür angeführt, dass IP ihn leicht verdrängte.

Authentifizierung

Die XNS-Protokolle enthielten auch ein Authentifizierungsprotokoll und einen Authentifizierungsdienst, um dies zu unterstützen. Die "starken Anmeldeinformationen" basierten auf demselben Needham-Schroeder-Protokoll , das später von Kerberos verwendet wurde. Nachdem Sie sich mit dem Authentifizierungsdienst in Verbindung gesetzt hatten, um Anmeldeinformationen zu erhalten, bot dieses Protokoll eine einfache Möglichkeit, Courier-Prozeduraufrufe digital zu signieren, sodass Empfänger die Signatur überprüfen und Absender über das XNS-Internet authentifizieren konnten, ohne den Authentifizierungsdienst für die Dauer des Protokollkommunikationssitzung.

Drucken

Die Drucksprache von Xerox, Interpress , war ein binär formatierter Standard zur Steuerung von Laserdruckern. Die Designer dieser Sprache, John Warnock und Chuck Geschke, verließen später Xerox PARC, um Adobe Systems zu starten . Bevor sie gingen, erkannten sie die Schwierigkeit, eine binäre Drucksprache anzugeben, bei der Funktionen zum Serialisieren des Druckauftrags umständlich waren und das Debuggen fehlerhafter Druckaufträge schwierig machte. Um den Wert der Angabe eines programmierbaren und leicht zu debuggenden Druckauftrags in ASCII zu erkennen, haben Warnock und Geschke die Postscript-Sprache als eines ihrer ersten Produkte bei Adobe erstellt.

Remote-Debug-Protokolle

Da auf allen über 8000 Computern im Intranet des Xerox-Unternehmens die Wildflower-Architektur (von Butler Lampson entworfen) ausgeführt wurde, gab es ein Remote-Debug-Protokoll für Mikrocode. Grundsätzlich könnte eine Peek-and-Poke-Funktion den Mikrocode-Status einer Maschine der C- oder D-Serie irgendwo auf der Erde anhalten und manipulieren und dann die Maschine neu starten.

Außerdem gab es ein Remote-Debug-Protokoll für den World-Swap-Debugger. Dieses Protokoll kann über den Debugger "nub" eine Workstation einfrieren und dann verschiedene Teile des Speichers einsehen und durchsuchen, Variablen ändern und die Ausführung fortsetzen. Wenn Debugging-Symbole verfügbar wären, könnte ein abgestürzter Computer von überall auf der Welt aus per Fernzugriff debuggt werden.

Geschichte

Ursprünge in Ethernet und PUP

In seinem letzten Jahr an der Harvard University begann Bob Metcalfe mit Interviews bei einer Reihe von Unternehmen und wurde von Jerry Elkind und Bob Taylor von Xerox PARC herzlich willkommen geheißen , die anfingen , an den vernetzten Computerarbeitsplätzen zu arbeiten, aus denen der Xerox Alto werden sollte . Er erklärte sich bereit, im Juli zu PARC zu wechseln, nachdem er seine These verteidigt hatte. Während Metcalfe 1970 bei Steve Crockers Haus während einer Konferenz auf der Couch surfte , nahm er eine Kopie der Proceedings of the Fall Joint Computer Conference vom Tisch, um beim Lesen einzuschlafen. Stattdessen faszinierte ihn ein Artikel über ALOHAnet , ein früheres Weitverkehrsnetzwerk. Bis Juni hatte er seine eigenen Theorien zum Networking entwickelt und sie seinen Professoren vorgestellt, die sie ablehnten und "auf meinen Arsch geworfen" wurden.

Metcalfe wurde trotz seiner erfolglosen These im PARC begrüßt und begann bald mit der Entwicklung des damaligen "ALOHAnet in a wire". Er tat sich mit David Boggs zusammen , um bei der elektronischen Implementierung zu helfen, und Ende 1973 bauten sie funktionierende Hardware mit 3 Mbit / s. Das Paar begann dann an einem einfachen Protokoll zu arbeiten, das auf dem System ausgeführt werden sollte. Dies führte zur Entwicklung des PARC Universal Packet (Pup) -Systems, und Ende 1974 liefen die beiden Pup erfolgreich über Ethernet. Sie meldeten die Konzepte an, wobei Metcalfe mehrere andere Namen hinzufügte, weil er der Meinung war, dass sie Erwähnung verdienen, und reichten dann im Juli ein Papier über das Konzept bei Communications of the ACM zum Thema "Ethernet: Distributed Packet Switching für lokale Computernetzwerke" ein 1976.

PUP zu XNS

Bis 1975, lange bevor PUP abgeschlossen war, scheuerte Metcalfe bereits unter dem strengen Xerox-Management. Er war der Ansicht, dass das Unternehmen Ethernet sofort in Betrieb nehmen sollte, fand jedoch wenig Interesse beim oberen Management. Eine wegweisende Veranstaltung fand statt, als sich Professoren des berühmten MIT - Labors für künstliche Intelligenz 1974 an Xerox wandten, um Ethernet für die Verwendung in ihrem Labor zu kaufen. Das Xerox-Management lehnte ab und war der Ansicht, dass Ethernet besser für den Verkauf eigener Geräte eingesetzt werden kann. Das AI Lab würde dann eine eigene Version von Ethernet, Chaosnet , erstellen .

Metcalfe verließ Xerox schließlich im November 1975 für Transaction Technology, eine Abteilung der Citibank , die mit der fortschrittlichen Produktentwicklung beauftragt ist. Sieben Monate später wurde er jedoch von David Liddle zu Xerox zurückgelockt , der kürzlich die Abteilung für Systementwicklung innerhalb von Xerox speziell organisiert hatte, um PARCs-Konzepte auf den Markt zu bringen. Metcalfe begann sofort mit der Neugestaltung von Ethernet für 20 Mbit / s und bemühte sich, Pup in einer Version in Produktionsqualität neu zu schreiben. Metcalfe suchte Hilfe bei Pup und wandte sich an Yogin Dalal , der zu diesem Zeitpunkt seine Diplomarbeit bei Vint Cerf an der Stanford University abschloss . Dalal wurde auch von stark rekrutiert Bob Kahn ‚s ARPANET Team (Arbeits auf TCP / IP), aber wenn Cerf links beizutreten DARPA , Dalal vereinbart PARC und begann dort im Jahr 1977 zu bewegen.

Dalal baute ein Team aus William Crowther und Hal Murray auf und begann mit einer vollständigen Überprüfung von Pup. Dalal versuchte auch, weiterhin an den TCP-Bemühungen bei DARPA beteiligt zu sein, gab jedoch schließlich auf und konzentrierte sich voll und ganz auf Pup. Dalal kombinierte seine Erfahrungen mit ARPANET mit den Konzepten von Pup und hatte Ende 1977 den ersten Entwurf der Xerox Network System-Spezifikation veröffentlicht. Dies war im Wesentlichen eine Version von Pup mit dem zusätzlichen Konzept von Sockets und einem Netzwerk, das es Routern ermöglichte, Pakete über verbundene Netzwerke weiterzuleiten.

Anfang 1978 funktionierte das neue System, aber das Management unternahm immer noch keine Schritte, um es zu kommerzialisieren. Wie Metcalfe es ausdrückte:

Als ich 1976 zu Xerox zurückkam, waren wir ungefähr zweieinhalb Jahre vom Produktversand entfernt und 1978 waren wir ungefähr zweieinhalb Jahre vom Produktversand entfernt.

Als keine weiteren Maßnahmen ergriffen wurden, verließ Metcalfe das Unternehmen Ende 1978.

Einschlag

XNS wurde zuletzt von Xerox für die Kommunikation mit dem DocuTech 135 Publishing System verwendet und wird aufgrund der Allgegenwart von IP nicht mehr verwendet. Es spielte jedoch eine wichtige Rolle bei der Entwicklung der Netzwerktechnologie in den 1980er Jahren, indem es Software- und Hardwareanbieter dazu veranlasste, ernsthaft über die Notwendigkeit nachzudenken, dass Computerplattformen mehr als einen Netzwerkprotokollstapel gleichzeitig unterstützen.

Eine Vielzahl von proprietären Netzwerksystemen basierte direkt auf XNS oder bot geringfügige Variationen des Themas an. Darunter waren Net / One, 3+, Banyan VINES und Novells IPX / SPX . Diese Systeme haben ihre eigenen Konzepte zusätzlich zum XNS-Adressierungs- und Routing-System hinzugefügt. VINES fügte unter anderem einen Verzeichnisdienst hinzu , während Novell NetWare eine Reihe von benutzerbezogenen Diensten wie Drucken und Dateifreigabe hinzufügte. AppleTalk verwendete XNS-ähnliches Routing, hatte jedoch inkompatible Adressen mit kürzeren Nummern.

XNS half auch bei der Validierung des Designs des 4.2BSD- Netzwerksubsystems, indem es eine zweite Protokollsuite bereitstellte, die sich erheblich von den Internetprotokollen unterschied. Durch die Implementierung beider Stacks im selben Kernel haben Berkeley-Forscher gezeigt, dass das Design nicht nur für IP geeignet ist. Zusätzliche BSD-Modifikationen waren schließlich erforderlich, um die gesamte Palette der OSI-Protokolle ( Open Systems Interconnection ) zu unterstützen.

Siehe auch

Verweise

Zitate
Literaturverzeichnis
  • Stephens, Mark (6. März 1989). "OSI Layer 3 unterscheidet Systemsoftware" . InfoWorld : 15. }}
  • Cisco. "Xerox Network Systems" . cisco.com .
  • Pelkey, James (2007). "Unternehmerischer Kapitalismus und Innovation: Eine Geschichte der Computerkommunikation 1968-1988" .
  • Xerox-Systemintegrationsstandard - Internet-Transportprotokolle (Xerox, Stamford, 1981)
  • Xerox-Systemintegrationsstandard - Kurier: Das Remote Procedure Call-Protokoll (Xerox, Stamford, 1981)
  • Oppen, DC, und Dalal, YK, The Clearinghouse: Ein dezentraler Agent zum Auffinden benannter Objekte in einer verteilten Umgebung. Palo Alto: Xerox Corporation, Abteilung Office Systems, 1981 Oktober: Technischer Bericht OSD-T8103.
  • Israel, JE, und Linden, TA, Authentifizierung in Star- und Netzwerksystemen von Xerox. Palo Alto: Xerox Corporation, Abteilung Office Systems, Mai 1982: Technischer Bericht OSD-T8201.
  • Office Systems Technology - Ein Blick in die Welt der Produkte der Xerox 8000-Serie: Workstations, Services, Ethernet und Softwareentwicklung "(Herausgegeben von Ted Linden und Eric Harslem), Tech Report Xerox OSD-R8203, November 1982. Ein Kompendium von 24 Artikel, in denen alle Aspekte der Xerox STAR Workstation und der Netzwerkprotokolle beschrieben wurden. Die meisten davon waren Nachdrucke von Zeitschriften- und Konferenzpublikationen.

Externe Links