DE69612302T2

DE69612302T2 - Verfahren und anordnung zur verwaltung von netzwerkbetriebsmitteln

Info

Publication number: DE69612302T2
Application number: DE69612302T
Authority: DE
Inventors: Christer Bohm; Markus Hidell; Per Lindgren; Lars Ramfelt; Peter Sjoedin
Original assignee: Dynarc AB
Current assignee: Dynarc AB
Priority date: 1995-12-28
Filing date: 1996-12-23
Publication date: 2001-11-22
Anticipated expiration: 2016-12-24
Also published as: ES2157019T3; EP0873629B1; DE69612302D1; SE515901C2; ATE200170T1; WO1997024846A1; CA2241554A1; EP0873629A1; JP2000502856A; SE9504681D0; US5982780A; SE9504681L; AU1404197A

Description

Technisches Gebiet der Erfindunci

Die vorliegende Erfindung bezieht sich in einem ersten Aspekt auf ein Verfahren für ein zentralisiertes Management der Kapazität in einem Wählbetrieb- bzw. Durchschalt-Netzwerk mit einer Bus- oder Ringstruktur und auf ein Wählbetrieb- bzw. Durchschalt-Netzwerk einer Bus- oder Ringstruktur zur Durchführung des Verfahrens.
In einem zweiten Aspekt bezieht sich die vorliegende Erfindung auch auf ein Verfahren für ein verteiltes Management der Kapazität in einem Durchschalt- Netzwerk mit einer Bus- oder Ringstruktur und auf ein Durchschalt-Netzwerk einer Bus- oder Ringstruktur zur Durchführung des Verfahrens.
Die vorliegende Erfindung bezieht sich auf eine Knotensteuer- bzw. -regeleinheit in einem Knoten in einem Durchschalt-Netzwerk mit einer Bus- oder Ringstruktur.
Die vorliegende Erfindung bezieht sich auf einen Knoten, welcher auch Serverknoten genannt wird, in einem Durchschalt-Netzwerk mit einer Bus- oder Ringstruktur.

Beschreibung des Standes der Technik

DTM, Dynamic Synchronous Transfer Mode, ist eine Breitband-Netzwerkarchitektur, welche auf einem raschen Durchschalten bzw. Schaltkreisumschalten, vermehrt um eine dynamische Neuzuordnung von Betriebsmitteln bzw. Ressourcen, basiert. Es stellt ein Service basierend auf Multicast-, Multirate-Kanälen mit einer kurzen Setup- Verzögerung zur Verfügung und unterstützt Anwendungen mit Echtzeitanforderungen an die Qualität des Services bzw. Dienstes als auch Anwendungen mit umfangreichem bzw. stoßartigem, asynchronem Verkehr. Diese Anmeldung beschreibt die DTM-Architektur und ihr Managementschema verteilter Ressourcen. Leistungsanalyseresultate von Netzwerksimulationen werden präsentiert. Die Analyse wird im Hinblick auf den Durchsatz und die Zutrittsverzögerung für zwei Netzwerktopologien durchgeführt: ein Dualbus und ein Gitter bzw. Raster von dualen Bussen. Die Effekte von variierenden Benutzeranforderungen, Abständen zwischen Knoten und Transfer- bzw. Übertragungsgrößen werden für einheitliche Verkehrs- bzw. Übertragungsmuster studiert. Die Resultate zeigen, daß der Overhead zum Aufbau der Kanäle gering ist (einige hundert Mikrosekunden), wobei dies einen hohen Grad an Verwendung selbst für kurze Übertragungen bzw. Transfers ergibt. Die Analyse zeigt auch, daß, wenn Kanäle sehr oft aufgebaut werden, die Signalübertragungskapazität die Leistung begrenzt.
Die nächste Generation von Netzwerken wird Dienste für unterschiedliche Arten von Anwendungen integrieren: verzögerungsunempfindliche, asynchrone Anwendungen, wie Telefax, Post bzw. Mail und Fileübertragung, und verzögerungsempfindliche Anwendungen mit Echtzeitanforderungen, wie beispielsweise Audio und Video. Diese unterschiedlichen Anwendungen wurden traditionellerweise durch unterschiedliche Netzwerktechnologien unterstützt. Eine asynchrone Kommunikation wurde durch Computernetzwerke zur Verfügung gestellt, welche paketgeschaltet sind und Store-and-Forward-Techniken verwenden, wie das Internet. Eine Echtzeitkommunikation wurde andererseits durch durchgeschaltete Zeitmultiplex- Telefonnetzwerke zur Verfügung gestellt.
Wählbetrieb- bzw. Durchschalt-Netzwerke weisen viele attraktive Eigenschaften auf. Schaltungen bzw. Schaltkreise sind voneinander in dem Sinn getrennt, daß ein Verkehr bzw. eine Übertragung an einer Schaltung bzw. einem Schaltkreis durch Aktivitäten an den anderen unbeeinflußt ist. Dies macht es möglich, eine garantierte Übertragungsqualität mit einer konstanten Verzögerung zur Verfügung zu stellen, wobei dies für Anwendungen mit Zeitanforderungen geeignet ist. Weiters sind die Daten und Kontrolle bzw. Steuerung in Durchschalt-Netzwerken getrennt. Eine Verarbeitung von Kontroll- bzw. Steuerinformation erfordert nur einen Platz beim Aufbau und Abbau von Schaltungen und der aktuelle Datentransfer kann ohne Bearbeitung des Datenstroms, einer Staukontrolle, etc. durchgeführt werden. Dies ermöglicht, daß große Mengen von Daten effizient übertragen werden (siehe den Artikel "The case for circuit switching in future wide bandwidth networks", von P. O'Reilly, In Proc. of IEEE ICC, Philadelphia, Pennsylvania, Juni 1988, S. 899-904). Wir glauben, daß dies in der Zukunft noch wichtiger sein wird, da Entwicklungen betreffend Photonen dramatisch die Kosten einer Übertragung senken werden und Schalter die wesentlichen Kommunikations- bzw. Übertragungsengpässe werden.
Die statische Natur von gewöhnlichen Durchschalt-Netzwerken macht diese für gewisse Arten von Verkehr bzw. Übertragung ungeeignet. Traditionellerweise weisen Schaltungen eine festgelegte Kapazität, eine große Aufbau- bzw. Einstellverzögerung und eine geringe Unterstützung für Multicast auf. Diese Nachteile machen es schwierig, effizient beispielsweise eine Computerkommunikation in einem Durchschalt-Netzwerk zu unterstützen. Dies hat eine Suche nach alternativen Lösungen motiviert und die überwiegende Ansicht ist, daß die nächste Generation von Telekommunikationsnetzwerken zellengeschaltet sein soll, basierend auf ATM (Asynchronous Transfer Mode) (siehe z. B. "Integrated Broadband Networks", von R. Händel und M. N. Huber, Addison-Wesley, 1991). Zellen sind kleine Pakete festgelegter Größe, so daß dies eine Orientierung zu einem Paketschalten bzw. Paketvermitteln ist (siehe den Artikel "New Directions in Communications (or Which Way to the Information Age?)", von J. S. Turner, IEEE Communications Magazine, Bd. 24, Nr. 10, S. 8-15, Oktober 1986). Dies bedeutet, daß viele der Schwachstellen eines Paketswitchens bzw. Paketschaltens auch in Zellschaltnetzwerken vorhanden sind, insbesondere in dem Bereich einer Bereitstellung einer garantierten Servicequalität. Daher sind zusätzliche Mechanismen, wie beispielsweise eine Zugangs- bzw. Zutrittsregelung bzw. -steuerung, eine Verkehrs- bzw. Übertragungsregelung, ein Listen von Paketen an Verbindungen und eine Resynchronisierung bei dem Empfänger, erforderlich, um eine Unterstützung für unterschiedliche Arten von Verkehr zu integrieren (siehe den Artikel "Real-Time Communication in Packet-Switched Networks", von C. M. Aras et al., Proceedings of the IEEE, Bd. 82, Nr. 1, S. 122-139, Jänner 1994). Eines der wesentlichen Bedenken bei Paketvermittlungsnetzwerken im allgemeinen und ATM im besonderen ist es, ob es möglich ist, diese Mechanismen in einer kostengünstigen Weise zu realisieren (siehe z. B. die Artikel "Management and Control Functions in ATM Switching Systems", von T. M. Chen et al., IEEE Network Magazine, Bd. 8, Nr. 4, S. 27-40, Juli/August 1994; "Open issues regarding the universal application of ATM for Multiplexing and switching in the B-ISDN", von M. Decina, In Proc. of IEEE ICC, Denver, Colorado, Juni 1991, S. 1258-1264; "Conceptual Issues for ATM", von J. Grechter et al., IEEE Network Magazine, Bd. 3, Nr. 1, S. 14-16, Jänner 1989; "ATM Network: goals and challenges", von B. G. Kim et al., Communications of the ACM, Bd. 38, Nr. 2, S. 39-44, Februar 1995; "The Latency/Bandwidth Tradeoff in Gigabit Networks", von L. Kleinrock, IEEE Communications Magazine, Bd. 30, Nr. 4, S. 36-40, April 1992; "What Should Be the Goal for ATM?", von C-T. Lea, IEEE Network Magazine, Bd. 6, Nr. 5, S. 60-66, September 1992; und "ATM concepts, architectures, and protocols", von R. J. Vetter, Communications of the ACM, Bd. 38, Nr. 2, S. 28-28, September 1992).
DTM, Dynamic Synchronous Transfer Mode, ist eine Breitband-Netzwerkarchitektur, welche am Royal Institute of Technology in Schweden entwickelt wurde. Es ist ein Versuch, die Vorteile eines Durchschaltens und Paketschaltens bzw. -vermittelns dahingehend zu kombinieren, daß es auf einem schnellen Schaltkreis-Schalten vermehrt um eine dynamische Neuzuordnung bzw. -zuweisung von Ressourcen bzw. Betriebsmitteln basiert, Multicast-Kanäle unterstützt und Mittel zur Bereitstellung einer kurzen Zutrittsverzögerung aufweist. Die DTM-Architektur erstreckt sich von einem Mediumzutritt, beinhaltend ein Synchronisationsschema, bis zu einem Routen bzw. Finden eines Leitungswegs und Adressieren von logischen Ports bei dem Empfänger. DTM ist konstruiert bzw. ausgebildet, um verschiedene Arten von Verkehr zu unterstützen und kann direkt für eine Anwendungs-zu-Anwendungs- Kommunikation oder als ein Trägernetzwerk für andere Protokolle, wie beispielsweise ATM oder IP (Internet-Protokoll), verwendet werden. Eine Prototypimplementation, basierend auf 622 Mbps optischen Fasern, war für zwei Jahre in Betrieb und es finden Arbeiten mit einer Wellenlängen-Unterteilungs- Multiplexversion mit vier Wellenlängen statt. Ein Überblick über DTM mit einer detaillierteren Beschreibung der Prototypimplementation wurde vorher in dem Artikel "The DTM Gigabit Network", von C. Bohm et al., Journal of High Speed Networks, Bd. 3, Nr. 2, S. 109-126, 1994, veröffentlicht.
Ein schnelles Schaltkreis-Schalten wurde für eine Verwendung in Telefonsystemen bereits in den frühen 80er-Jahren vorgeschlagen (siehe den Artikel "TASI-E Communications System", von R. L. Easton et al., IEEE Transactions on Communications, Bd. 30, Nr. 4, S. 803-807, April 1982). Ein schnelles Wählbetrieb- bzw. Durchschalt-Telefonnetzwerk versucht, einen Übertragungsweg einer gegebenen Datenrate einem Satz von Netzwerkbenutzern nur zuzuordnen, wenn sie aktiv Information übertragen. Dies bedeutet, daß eine Schaltung für jeden Informationsstoß aufgebaut wird (siehe die Artikel "Voice/Data Integration Using Circuit Switched Networks", von E. A. Harrington, IEEE Transactions on Communications, Bd. 28, Nr. 6, S. 781-793, Juni 1980; und "Communications Switching - From Operators to Photonics", von S. D. Personick et al., Proceedings of the 1EEE, Bd. 75, Nr. 10, S. 1380-1403, October 1987). Wenn Stille detektiert wird, wird die Übertragungskapazität rasch anderen Benutzern zugewiesen. In der in TASI-E (Time Assignment Speech Interpolation) verwendeten Form wurde ein rasches Durchschalten für die Interkontinentalkommunikation zwischen Europa und den Vereinigten Staaten verwendet. Ein Burst-Switching ist eine andere Form eines schnellen Schaltkreis- bzw. Durchschaltens, wo eine Signalfolge bzw. ein Burst (bestehend aus einem Header, einer willkürlichen Menge von Daten und einem Abschlußzeichen) in einem Zeitmultiplex- bzw. Zeitunterteilungskanal mit einer festgelegten Bitrate übertragen wird und somit mit anderen Bursts verwoben wird (siehe den Artikel "Burst Switching - An Update", von S. R. Amstutz, IEEE Communications Magazine, Bd. 27, Nr. 9, S. 50-57, September 1989). Dies macht ein Burst-Switchen unterschiedlich von einem Paket-Switchen, wo die Pakete jeweils eines zu einer Zeit mit einer vollständigen Verbindungsbandbreite gesandt werden. Darüber hinaus ist die Länge eines Bursts im Gegensatz zu einem Paket nicht vor dem Start einer Übertragung bestimmt.
Es wurde gezeigt, daß die Signalisier- bzw. Signalverzögerung, welche einem Erzeugen und einem Abstellen von Kommunikationskanälen zugeordnet ist, sehr viel der Effizienz eines raschen Wählbetriebs bzw. Durchschaltens bestimmt. DTM ist daher ausgebildet, Kanäle rasch innerhalb von einigen hundert Mikrosekunden zu erzeugen. DTM unterscheidet sich von einem Burst-Switchen dahingehend, daß die Steuerung bzw. Regelung und die Daten getrennt sind und daß es Multicast-, Multirate-Kanäle hoher Kapazität verwendet, um eine Vielzahl von unterschiedlichen Verkehrs- bzw. Übertragungsklassen zu unterstützen. Dies bedeutet beispielsweise, daß es möglich ist, die zugeordneten Ressourcen eines bestehenden Kanals zu erhöhen oder zu verringern. Obwohl ein DTM-Netzwerk das Potential haben kann, einen Kanal für jede Botschaft zu erzeugen, glauben wir nicht, daß dieser Zugang für alle Verkehrsklassen geeignet ist. Eher ist es Sache des Benutzers zu entscheiden, ob ein Kanal pro Informationsstoß bzw. -burst aufgebaut wird oder ob der Kanal selbst während Leerzeitperioden aufgebaut beibehalten wird.
Ein Ressourcenmanagement verwendet Token bzw. codierte Befehlsworte, um einen konfliktfreien Zugang bzw. Zutritt zu Zeitschlitzen bzw. -slots zu garantieren. Das DTM-Modell beinhaltet zwei unterschiedliche Tokenmanagement-Schemata. Das erste ist ein asymmetrisches Schema basierend auf einem zentralen Tokenmanager, welcher alle freien Token managt. Das zweite ist ein symmetrisches Schema basierend auf einem verteilten Tokenmanager, wo alle Knoten den Tokenpool bzw. -vorrat teilen. Token in dem verteilten Schema werden durch ein Neuzuteilungsprotokoll übergeben. Ein Tokenfragmentierungsproblem wird für das verteilte Schema identifiziert und es wird eine Lösung basierend auf einem Defragmentationsmechanismus präsentiert. Beide Modelle unterstützen eine Slot- bzw. Platzwiederverwendung und ein Schema für einen raschen Verbindungsaufbau.
Verkehrsgeneratoren für die Simulierung erzeugen Verkehr bzw. Übertragungen mit exponentiellen Verteilungen zwischen den Ankünften, burst- bzw. stoßartigen Ankünften oder asymmetrischem Client-Server-ähnlichem Verkehr. Resultate zeigen, daß der Overhead für den Verbindungsaufbau gering genug ist, daß eine Verwendung hoch sein kann und daß das Neuzuordnungsprotokoll gut arbeitet, selbst wenn eine Schaltung für jedes einzelne Paket aufgebaut wird. Wenn das Slot- bzw. Kanalwiederverwendungsschema eingeschaltet ist, steigt eine Verwendung nahezu um einen Faktor von 2 und andere Leistungsmaße verbessern sich ebenfalls. Schließlich identifizieren die Resultate eine Signalübertragungskapazität als den bedeutendsten, limitierenden Faktor, um eine hohe Leistung zu erhalten, wenn die durchschnittliche Paketgröße klein ist.
Neue Kommunikationsnetzwerke hoher Kapazität und Protokolle werden ständig durch die Kommunikationsindustrie und -wissenschaften entwickelt. Diese Entwicklung ändert sich häufig und neue Resultate sind wichtig für Anwendungsentwickler, welche Echtzeit-Audio-, -Video- und asynchrone Kommunikationsdienste in Anwendungen integrieren. Die Anwendungen können in einem weiten Bereich von Netzwerkzutrittsterminals gefunden werden. Terminals wirken als Netzwerkhosts und können nahezu jede elektronische Vorrichtung, beinhaltend kleine Taschentelefone bzw. Handys oder Fernsehgeräte, Multimedia-Arbeitsstationen oder Supercomputer im Wert von Millionen Dollar sein. Hosts unterscheiden sich um Größenordnungen in ihren Anforderungen für die Prozessorleistung und in ihren Anforderungen betreffend Kommunikationsdienste. Diese unterschiedlichen Anforderungen werden häufig in einem Satz von unabhängigen Netzwerkklassen wiedergespiegelt. Jede Netzwerkklasse ist für ihren speziellen Verkehr und ihre Anwendungen optimiert: Kabel-TV-Netzwerke verwenden unidirektionale Übertragungsnetzwerke, wo die Kapazität in Subkanäle fixierter Größe, welche Video übertragen, unterteilt ist. Ein Telefonnetzwerk verwendet nur 65 kbit/s Duplexschaltungen mit einem garantierten Durchsatz und streng kontrollierten Verzögerungsvariationen. Computernetzwerke, wie beispielsweise das Internet, erlauben eine große Anzahl von parallelen Netzwerksitzungen durch eine Verwendung eines verbindungslosen Paket-Switchens. Sie verwenden auch ein statistisches Multiplexen für ein effizientes Verwenden von Verbindungen. Ein Backbone-Netzwerk für Mobilsysteme erfordert eine zusätzliche Steuer-(oder Signal-)-kapazität, um dynamisch alle aktiven Terminals zu verfolgen.
Mit diesem weiten Spektrum von Anwendungen, welche derzeit existieren und in der Zukunft vermehrt werden, ist es nicht möglich, kontinuierlich neue, manchmal globale Netzwerke und ein neues Terminalinterface für jede neue Art von Service zu erfinden. Stattdessen muß ein Netzwerk mit integrierten Diensten, welches bestehende und neue Dienste unterstützt, entwickelt werden. Die globalen Zielsetzungen für ein derartiges Netzwerk sind eine Skalierbarkeit auf globale Größe und ein maximales Teilen bzw. gemeinsames Nutzen von teuren Netzwerkkomponenten, um Kosten zu minimieren. Von der optischen Übertragungstechnologie wurde gezeigt, daß sie die notwendige Link- bzw. Verbindungskapazität bei einem ausreichend niedrigen Preis zur Verfügung stellt, um Netzwerke mit integrierten Diensten eine realistische Lösung werden zu lassen.
Ein neues, integriertes, optisches Netzwerk mit einer viel höheren Kapazität wird jedoch neue Probleme mit sich bringen, welche nicht in spezialisierteren und Netzwerken geringerer Leistung heutzutage ersichtlich sind. Zuerst wird, wenn die Netzwerkkapazität ansteigt und die Informationsflutlatenz durch die Lichtgeschwindigkeit begrenzt bleibt, das zunehmende Bandbreiten- Verzögerungsprodukt höhere Anforderungen an Mechanismen stellen, welche einen Verkehr eines Benutzers von einem Netzwerkverkehr eines Dritten isolieren. Eine Telefonsitzung beispielsweise sollte nicht durch einen anderen Benutzer beeinflußt werden, welcher einen Videokanal hoher Kapazität öffnet. Zweitens werden Anwendungen und Protokolle zuverlässig mit einer zunehmenden Menge von zu übertragender Information arbeiten müssen, um von der erhöhten Netzwerkkapazität zu profitieren. Dies wird zu größeren Burst- und Transaktionsgrößen in dem Netzwerk führen.
Gegenwärtige Netzwerke, welche "Stateless Packet Switching Protokolle", wie beispielsweise das Internetprotokoll (IP) verwenden (siehe die Dokumente "Internet Protocol Request for Comments (Standard) RFC 791", vorn J. Postel, Internet Engineering Task Force, September 1981, Obsoletes RFC 0760; und "The Internet activities board. Network Working Group Request for Comments RFC 1120", von Vinton G. Cerf, NRI, September 1989) haben sich als extrem skalierbar erwiesen. Sie entwickelten sich aus kleinen Netzwerken, welche nur einige wenige Forschungscomputer der Defense Advanced Research Projects Agency (DARPA) (siehe das Dokument "Internetworking with TCP/IP, volume 1", von Douglas E. Comer, Prentice Hall, Englewood Cliffs, New Jersey, 1991) Mitte der 70er-Jahre verbunden haben, in das gegenwärtig globale und allgegenwärtige Internet (siehe den Artikel "The hitchhiker's guide to the Internet", von Ed Krol, Network Working Group Request for Comments RFC 1118, University of IIIinois, September 1989).
Local Area Networks (LAN) mit gemeinsamem Medium (siehe das Dokument "Data and Computer Communications", von W. Stallings, Macmillan Publishing Company, vierte Auflage, 1994), wie z. B. CSMA/CD, Token-Ring and FDDI (Fiber Distributed Data Interface), werden im Internet als einfache Baublöcke verwendet, welche durch Router oder Bridges verbunden werden. Die Kombination einer einfachen Expansion, gering ansteigenden Kosten für Knoten und eine Toleranz gegenüber fehlerhaften Knoten hat in einfachen, flexiblen und robusten Netzwerken resultiert. Darüber hinaus erlaubt das gemeinsam genutzte Medium eine effiziente Anwendung der neuen Multicast-Protokolle, wie beispielsweise IP-Multicast (siehe den Artikel "A study of slot reuse in dual bus multiple access networks", von M. W. Garrett et al., In Proceedings of the Conference on Computer Communications (IEEE Infocom), San Francisco, Kalifornien, Juni 1990).
Ein Nachteil des gemeinsam genutzten Mediums ist, daß es typischerweise nur erlaubt, daß ein einziges Terminal zu einem beliebigen Zeitpunkt überträgt, wodurch nicht alle Netzwerksegmente effizient genutzt werden. Ein Schema, welches erlaubt, daß die Kapazität des Mediums wiederum genutzt wird, kann ausgebildet werden (siehe die Artikel "Erasure node: Performance improvements for the IEEE 802.6 MAN", von M. A. Rodrigues, In Proceedings of the Conference on Computer Communications (IEEE Infocom), San Francisco, Kalifornien, Juni 1990; und "Incorporating continuation-of-message information, slot reuse, and fairness in DQDB networks", von S. Banerjee et al., Computer Networks and ISDN Systems, 24 : 153-169; 1992), wobei dies jedoch oft auf Kosten der Komplexität in der Hochgeschwindigkeits-Steuerhardware erfolgt. Zugangssteuermechanismen für ein gemeinsam genutztes Medium hängen auch stark von der Größe des Netzwerks ab und sind üblicherweise nur für Local Area Umgebungen effizient.
Die zwei Haupttypen eines Netzwerks sind verbindungsorientierte Durchschalt- Netzwerke, welche für Telefonie verwendet werden, und verbindungslose, paketgeschaltete Netzwerke, welche durch das Internet beispielhaft gegeben sind. Wenn ein Durchschalt-Netzwerk für eine Datenkommunikation verwendet wird, müssen Schaltungen zwischen Informationsstößen bzw. -bursts offen sein, wodurch Netzwerkkapazität vergeudet wird. Dieses Problem tritt auf, da Schaltungsmanagementvorgänge langsam im Vergleich zu dynamischen Variationen in der Benutzeranforderung sind. Eine andere Quelle eines Overheads in Durchschalt- Netzwerken ist die Begrenzung, daß symmetrische Duplexkanäle erforderlich sind, welche 100% Overhead mit sich bringen, wenn der Informationsfluß nur in einer Richtung erfolgt. Diese Beschränkung macht auch Multicast-Schaltungen uneffizient und schwierig zu implementieren. Einem verbindungslosen, paketgeschalteten Netzwerk mangelt es andererseits an Ressourcenreservierung und es muß eine Headerinformation jeder Botschaft vor der Übertragung hinzufügen. Darüber hinaus kann eine Latenz in einem verbindungslosen Paketschaltnetzwerk nicht genau vorhergesagt werden und Pakete können selbst aufgrund eines Pufferoverflows oder zerstörten Headers verloren werden. Die letzteren zwei Faktoren machen ein Unterstützen eines Echtzeitservices schwierig. Mechanismen zur Vermeidung eines Staus bzw. einer Überfüllung können Verkehrsströme unterschiedlicher Benutzer isolieren. Diese Schemata sind jedoch auf einen Betrieb auf einer Zeitskala vergleichbar zu der Umlaufzeit- bzw. Roundtrip-Paketverzögerung beschränkt.
Um die obengenannten Probleme zu adressieren, richtet die Kommunikationsindustrie ihr Augenmerk auf die Entwicklung des asynchronen Übertragungsmodus (Asynchronus Transfer Mode) ATM (siehe das Dokument "ATM Networks - concepts, protocols, applications", von R. Handel et al., ADDISINWESLEY, zweite Auflage, 1994). ATM wurde für LAN's und viele zukünfigte, öffentliche Netzwerke vorgeschlagen. International Telegraph and Telephone Consultative Committee (CCITT) hat es auch angenommen, um es als den Verbindungsstandard in Breitband-ISDN (B-ISDN) zu verwenden (siehe das Dokument "ISDN and broadband ISDN", von W. Stallings, Macmillan, TK 5103.7. S73 1992). ATM-Netzwerke sind verbindungsorientiert und bauen einen Kanal genauso wie Durchschalt-Netzwerke auf, wobei sie jedoch kleine Pakete fixierter Größe, welche Zellen genannt werden, für eine Informationsübertragung verwenden. Diese paketgeschaltete bzw. -vermittelte Natur von ATM bedeutet, daß das Netzwerk neue Mechanismen, wie Pufferressourcenmanager und Linkscheduler, aufweisen muß, um Echtzeitgarantien für eine Verbindung aufzubauen.
Unsere Lösung zur Bereitstellung von Echtzeitgarantien richtet sich im wesentlichen auf ein Durchschalt-Netzwerk und wir müssen daher Durchschaltbedenken wie die oben beschriebenen adressieren. Wir verwenden auch ein neues Shared-Medium- Steuerprotokoll und wir müssen daher auch übliche Probleme eines gemeinsamen Mediums betrachten bzw. berücksichtigen. Unser Design, der sogenannte Dynamic Synchronous Transfer Mode (DTM) (siehe die Artikel "Multi-gigabit networking based on DTM", von L. Gauffin et al., Computer Network and ISDN Systems, 24(2): 119- 130, April 1992; "The DTM Gigabit Network", von C. Bohm et al., Journal of High Speed Networks, 3(2): 109-126, 1994; und "Fast circuit switching for the next generation of high performance networks", von C. Bohm et al., IEEE Journal on Selected Areas in Communications, 14(2), Februar 1996) verwendet Kanäle als die Kommunikationsabstraktion. Unsere Kanäle unterscheiden sich von Telefonschaltungen in verschiedenen Arten. Zuerst ist eine Aufbauverzögerung kurz, so daß Ressourcen bzw. Betriebsmittel dynamisch zugewiesen/abgeschaltet werden können, so rasch wie sich die Anforderungen eines Benutzers ändern. Zweitens sind sie simplex und minimieren so den Overhead, wenn die Übertragung unidirektional ist bzw. in einer Richtung verläuft. Drittens bieten sie mehrfache Bitraten, um große Änderungen in den Anforderungen der Kapazität eines Benutzers zu unterstützen. Schließlich sind sie multicast, wobei sie jede Vielzahl von Bestimmungen erlauben.
DTM-Kanäle teilen viele günstige Eigenschaften mit Schaltungen bzw. Schaltkreisen. Es besteht keine Übertragung einer Kontroll- bzw. Steuerinformation nach dem Aufbau des Kanals, wobei dies in einer sehr hohen Benutzung der Netzwerkressourcen für große Datenübertragungen resultiert. Eine Unterstützung eines Echtzeitverkehrs ist selbstverständlich; es besteht keine Notwendigkeit für eine Überwachung, Stausteuerung oder Durchflußsteuerung innerhalb des Netzwerks. Die Steuerinformation ist von den Daten getrennt, wobei dies das Multicast weniger komplex macht. Die Übertragungsverzögerung ist vernachlässigbar (d. h. weniger als 125 us) und es besteht kein Potential für einen Datenverlust, welcher durch einen Pufferoverflow bewirkt wird, wie bei ATM. Bitfehlerraten hängen von den darunterliegenden Link- bzw. Verbindungstechnologien ab und Schalter sind einfach und schnell aufgrund der strikten Reservierung von Ressourcen beim Kanalaufbau. Das Ziel dieses Papiers ist es, die Leistung von DTM in den Bereichen zu studieren, wo traditionelle Durchschalt-Netzwerke nicht ausreichen: dynamische Bandbreitenzuordnung, Kanalaufbauverzögerung und wie Shared Media Netzwerke. Prinzipien für Ressourcenmanagement (sogenanntes Tokenmanagement) werden präsentiert und evaluiert. Wir berichten Resultate von Simulationen, wo wir DTM an Verkehrsmuster aussetzen, welche in den relativ kurzlebigen Übertragungen (4- 4000 Kilobyte), welche bei der Computerkommunikation gesehen werden, wahrscheinlicher sind. Verkehr mit stoßartigem Überschneiden der Ankünfte, Client- Server-orientiert ebenso wie mit exponentiell verteilten Inter-Arrival-Zeiten.
Der Artikel "Multi-gigabit networking based on DTM, A DTM medium access technique with dynamic bandwidth-allocation", von L. Gauffin et al., Computer Network and ISDN Systems, Bd. 24, Nr. 2, April 1992, S. 119-130, offenbart ein Distributed Management Protocol, gemäß welchem die Zeitslots bzw. -plätze gleichmäßig unter den Knoten verteilt werden. Dies impliziert ein vollständig symmetrisches System.
Das Dokument WO 89/08363 beschreibt das Konzept von DTM und definiert die Bedeutung von statischen und dynamischen Zeitslots. Das Dokument beschreibt auch ein Kommunikationssystem, welches in einem Netzwerk, umfassend verbundene Busse, verwendet wird. Das Dokument beschreibt, daß dynamische Zeitslots neu zwischen den Knoten an einem Bus verteilt werden können, wobei es jedoch nicht beschreibt, wie dies durchgeführt werden soll.
Das Dokument EP 0 451 426 A1 beschreibt ein Paketvermittlungssystem, welches CRMA (Cyclic Reservation Multiple Access) verwendet, wobei dies bedeutet, daß ein Knoten eine Botschaft an einen Server, welcher an dem Ende des Busses angeordnet ist, für jeden Zyklus sendet, in welchem der Knoten Daten senden möchte. CRMA ist nicht für ein synchrones Netzwerk gedacht.

Zusammenfassung der Erfindung

Es ist ein Ziel der Erfindung, ein Verfahren für ein zentralisiertes Management der Kapazität in einem Durchschalt-Netzwerk mit einer Bus- oder Ringstruktur zur Verfügung zu stellen. Das Netzwerk verwendet eine Bandbreite, welche in Zyklen unterteilt ist, welche wiederum in Kontroll- bzw. Steuerzeitslots bzw. -plätze für eine Signalübertragung und Datenzeitslots für eine Übertragung von Daten unterteilt sind, und worin jedem Datenzeitslot ein Token bzw. ein codiertes Befehlswort zugeordnet wird. Das Verfahren umfaßt die folgenden Schritte:
- daß einem ersten Knoten, welcher Serverknoten genannt wird, Token entsprechend allen Datenzeitslots zugeordnet werden, welche in einer Richtung in einem Bus oder Ring strömen,
- daß ein zweiter Knoten Token entsprechend einer gewissen Kapazität von dem Serverknoten anfordert,
- daß der Serverknoten Reservierungen für Token durchführt und diese entsprechend der angeforderten Kapazität zu dem anderen Knoten in dem Fall, daß der Serverknoten die angeforderte Kapazität unbenutzt aufweist, übermittelt und
- daß die übertragenen Token zu dem Server rückübertragen und freigegeben werden, wenn entsprechende Datenzeitslots nicht für ein Übertragen von Daten des anderen Knotens während einer beträchtlichen Zeitdauer verwendet wurden. Der Hauptvorteil bei diesem Verfahren ist, daß die Verwendung ansteigt und sich andere Leistungsmaßzahlen auch verbessern.
Vorzugsweise ist das Verfahren in einem Netzwerk des DTM-Typs (Dynamic Synchronous Transfer Mode) implementiert.
Vorzugsweise umfaßt das Verfahren den Schritt:
- daß übertragene Token zu dem Serverknoten rückübermittelt und freigegeben werden, wenn entsprechende Datenzeitslots nicht länger für ein Übertragen von Daten verwendet werden.
In vorteilhafter Weise umfaßt das Verfahren den Schritt:
- daß als der Serverknoten der Knoten ausgewählt wird, welcher ein Drittel der Knoten stromaufwärts angeordnet und zwei Drittel der Knoten stromabwärts angeordnet hat.
Ein anderes Ziel der Erfindung ist es, ein Verfahren zur verteilten Verwaltung der Kapazität in einem Wählbetrieb- bzw. Durchschalt-Netzwerk mit einer Bus- oder Ringstruktur zur Verfügung zu stellen. Das Netzwerk verwendet eine Bandbreite, welche in Zyklen unterteilt wird, welche wiederum in Kontroll- bzw. Steuerzeitslots für eine Signalübertragung und Datenzeitslots für eine Übertragung von Daten unterteilt werden, und worin jedem Datenzeitslot ein Token bzw. codiertes Befehlswort (Schreibzugang) zugeordnet wird. Das Verfahren umfaßt die folgenden Schritte:
- daß wenigstens zwei Knoten, welche Serverknoten genannt werden, definiert werden, zwischen welchen Token entsprechend allen Datenzeitslots verteilt werden, welche in einer Richtung in einem Bus oder einem Ring strömen,
- daß ein Knoten Token entsprechend einer gewissen Kapazität von wenigstens einem der Serverknoten anfordert,
- daß dieser Serverknoten Reservierungen für Token durchführt und diese entsprechend der angeforderten Kapazität an den anfordernden Knoten in dem Fall überträgt, daß der Serverknoten die angeforderte Kapazität unbenutzt aufweist, und
- daß übertragene Token zu dem entsprechenden Serverknoten rückübermittelt und freigegeben werden, wenn entsprechende Datenzeitslots nicht für eine Datenübertragung während einer beträchtlichen Zeitdauer verwendet wurden.
In vorteilhafter Weise wird das Verfahren in einem Netzwerk des DTM-Typs (Dynamic Synchronous Transfer Mode) implementiert.
Vorzugsweise umfaßt das Verfahren auch den Schritt:
- daß mehrere Serverknoten gefragt werden, Reservierungen für Token durchführen und diese, welche gemeinsam der vollständig angefragten Kapazität entsprechen, zu dem anfragenden bzw. anfordernden Knoten in dem Fall übertragen, daß die Serverknoten gemeinsam die angeforderte Kapazität unbenutzt aufweisen.
In vorteilhafter Weise umfaßt das Verfahren auch den Schritt:
- daß empfangene Token für ein Aufbauen von Kanälen durch Senden einer Kanalaufbaubotschaft an den Knoten oder die Knoten verwendet werden, welche als Empfänger von Daten in dem Fall bezeichnet werden, daß ein Knoten Token entsprechend der angeforderten Kapazität empfangen hat.
Vorzugsweise umfaßt das Verfahren auch den Schritt:
- daß einer oder mehrere Serverknoten Reservierungen für Token durchführen und diese entsprechend der gesamten der nicht verwendeten Kapazität zu dem anfordernden Knoten in dem Fall übertragen, daß die Serverknoten gemeinsam nicht die angeforderte Kapazität unbenutzt aufweisen.
In vorteilhafter Weise umfaßt das Verfahren auch den Schritt:
- daß einer oder mehrere Serverknoten nicht jegliche Token an den anfordernden Knoten in dem Fall übertragen, daß die Serverknoten gemeinsam nicht die angeforderte Kapazität unbenutzt aufweisen.
Vorzugsweise umfaßt das Verfahren auch den Schritt:
- daß Token durch einen Knoten in dem Fall angefordert werden, daß möglicherweise erhaltene Token nicht der angeforderten Kapazität entsprechen. In vorteilhafter Weise umfaßt das Verfahren auch den Schritt:
- daß in einem Knoten empfangene Token in dem Fall freigegeben werden, daß diese Token nicht der angeforderten Kapazität entsprechen.
Vorzugsweise umfaßt das Verfahren auch den Schritt:
- daß empfangene Token für einen Aufbau von Kanälen durch Senden einer Kanalaufbaubotschaft an den Knoten oder die Knoten verwendet werden, welche als Empfänger von Daten in dem Fall bezeichnet werden, daß ein Knoten nicht Token entsprechend der angeforderten Kapazität erhalten hat.
In vorteilhafter Weise umfaßt das Verfahren auch den Schritt:
daß jeder Serverknoten regelmäßig Information betreffend seine Frei- bzw. Leerkapazität an den Rest der Knoten sendet und jeder Knoten in einer Statustabelle Information, welche von den anderen Knoten erhalten wird, speichert.
Vorzugsweise umfaßt das Verfahren auch den Schritt:
- daß ein Knoten Token von dem Serverknoten anfordert, welcher im Moment die meiste unbenützte Kapazität aufweist.
In vorteilhafter Weise umfaßt das Verfahren auch den Schritt:
- daß ein Knoten Token von dem Serverknoten anfordert, welcher am nächsten liegt und im Moment die angeforderte Kapazität unbenutzt aufweist.
Vorzugsweise umfaßt das Verfahren auch den Schritt:
- daß der Serverknoten, von welchem Kapazität angefordert wird, durch eine Bezugnahme auf die Statustabelle gefunden wird.
In vorteilhafter Weise umfaßt das Verfahren auch den Schritt:
- daß alle Knoten in einem Bus oder einem Ring afs Serverknoten definiert werden und diesen wenigstens ein Token zugeordnet wird.
Vorzugsweise umfaßt das Verfahren auch den Schritt:
- daß allen Knoten in einem Bus oder einem Ring dieselbe Anzahl von Token zugeordnet wird.
In vorteilhafter Weise umfaßt das Verfahren auch den Schritt:
- daß übertragene Token zu dem entsprechenden Serverknoten rückübermittelt werden und freigegeben werden, wenn entsprechende Datenzeitslots nicht länger für eine Datenübertragung verwendet werden.
Vorzugsweise umfaßt das Verfahren auch den Schritt:
- daß übertragene Token freigegeben werden, wenn entsprechende Datenzeitslots nicht länger für eine Datenübertragung verwendet werden.
In vorteilhafter Weise umfaßt das Verfahren auch den Schritt:
- daß aufeinander folgende Token in einem Knoten durch ein Token, welches Block- Token genannt wird, repräsentiert werden, welches als eine Zahl auf dem ersten Zeitslot in einer Reihe und die Gesamtanzahl der Zeitslots in der Reihe angezeigt wird.
Vorzugsweise umfaßt das Verfahren auch den Schritt:
- daß ein Token in wenigstens zwei Token entsprechend demselben Zeitslot, jedoch unterschiedlichen Segmenten unterteilt wird, wo sich ein Segment auf ein Teil eines Übertragungsmediums bezieht, welches wenigstens zwei Knoten verbindet.
In vorteilhafter Weise umfaßt das Verfahren auch den Schritt:
- daß der Serverknoten in dem Fall, daß er verschiedene Zeitslot- oder Segmentfolge-Gruppen von Token für eine Auswahl unter diesen aufweist, Reservierungen für Token durchführt und diese übermittelt, welche von der kleinsten Gruppe von Zeitslot- oder Segmentfolge-Token stammen, welche eine Kapazitätsanforderung erfüllen, und worin die kleinste Gruppe als die Gruppe definiert ist, deren Produkt von Zeitslots und Segmenten mit vorbestimmter Gewichtung am geringsten ist.
Vorzugsweise umfaßt das Verfahren auch den Schritt:
- daß Gruppen von Token, welche wenigstens teilweise Segmentabfolgen sind, neu gruppiert werden, um die Anzahl von aufeinander folgenden Segmenten für jede Gruppe von Token auf Kosten der Anzahl von aufeinander folgenden Zeitslots zu maximieren.
Ein weiteres Ziel der Erfindung ist die Bereitstellung einer Knotenkontroll- bzw. -steuereinheit in einem Wählbetrieb- bzw. Durchschalt-Netzwerk mit einer Bus- oder Ringstruktur. Das Netzwerk verwendet eine Bandbreite, welche in Zyklen unterteilt ist, welche wiederum in Kontroll- bzw. Steuerzeitslots bzw. -plätze für eine Signalisierung bzw. Signalübertragung und Datenzeitsiots für eine Übertragung von Daten unterteilt sind, und worin jedem Datenzeitslot ein Token bzw. ein codiertes Befehlswort zugeordnet ist. Der Knotensteuereinheit werden Token entsprechend einer vorgegebenen Anzahl von Datenzeitslots zugeordnet, welche in einer Richtung in einem Bus oder einem Ring strömen. Die Knotensteuereinheit ist angeordnet bzw. ausgebildet, um Reservierungen für Token durchzuführen und diese an eine zweite Knotensteuereinheit in einem zweiten Knoten in dem Fall zu übertragen, daß sie eine Anforderung für Token von der zweiten Knotensteuereinheit erhält und daß sie angeforderte Kapazität unbenutzt aufweist. Die zweite Knotensteuereinheit ist angeordnet bzw. ausgebildet, um die übertragenen Token zu der Knotensteuereinheit zurückzuübertragen und diese freizugeben, wenn entsprechende Datenzeitslots nicht für ein Übertragen von Daten der zweiten Knotensteuereinheit während einer beträchtlichen Zeit verwendet wurden.
Vorzugsweise ist das Netzwerk vom DTM-Typ (Dynamic Synchronous Transfer Mode).
Ein weiteres Ziel der Erfindung ist die Bereitstellung eines Knotens, welcher auch Serverknoten genannt wird, in einem Wählbetrieb- bzw. Durchschalt-Netzwerk mit einer Bus- oder Ringstruktur. Das Netzwerk verwendet eine Bandbreite, welche in Zyklen unterteilt ist, welche wiederum in Kontroll- bzw. Steuerzeitslots für eine Signalübertragung und Datenzeitslots für eine Übertragung von Daten unterteilt sind, und worin jedem Datenzeitslot ein Token bzw. codiertes Befehlswort zugeordnet ist. Der Knoten ist gekennzeichnet durch eine Knotensteuereinheit, welcher Token entsprechend einer vorbestimmten Anzahl von Datenzeitslots zugeordnet sind, welche in einer Richtung in einem Bus oder Ring strömen, und welche angeordnet bzw. ausgebildet ist, um Reservierungen für Token durchzuführen und diese an eine zweite Knotensteuereinheit in einem zweiten Knoten in dem Fall zu übertragen, daß sie eine Anforderung für Token von der zweiten Knotensteuereinheit erhält und daß sie die angeforderte Kapazität unbenutzt aufweist.
Vorzugsweise ist das Netzwerk vom DTM-Typ (Dynamic Synchronous Transfer Mode).
Vorzugsweise sind dem Knoten Token entsprechend allen Datenzeitslots zugeordnet, welche in einer Richtung in einem Bus oder einem Ring strömen.
In vorteilhafter Weise weist der Knoten ein Drittel der Knoten der Bus- oder Ringstruktur stromaufwärts und zwei Drittel der Knoten der Bus- oder Ringstruktur stromabwärts auf.
Ein anderer Gegenstand der Erfindung ist die Bereitstellung eines Wählbetrieb- bzw. Durchschalt-Netzwerks mit einer Bus- oder Ringstruktur, welches Netzwerk eine Bandbreite verwendet, welche in Zyklen unterteilt ist, welche wiederum in Kontroll- bzw. Steuerzeitslots für eine Signalisierung bzw. Signalübertragung und Datenzeitslots für eine Übertragung von Daten unterteilt sind, und worin jedem Datenzeitkanal ein Token bzw. codiertes Befehlswort zugeordnet ist. Das Netzwerk ist gekennzeichnet durch einen Knoten, welcher auch Serverknoten genannt wird, welchem Token entsprechend einer vorbestimmten Anzahl von Datenzeitslots zugeordnet sind, welche in einer Richtung in einem Bus oder einem Ring strömen, und welcher angeordnet bzw. ausgebildet ist, um Reservierungen für Token durchzuführen und diese an einen zweiten Knoten in dem Fall zu übertragen, daß er eine Anforderung für Token von dem zweiten Knoten erhält und die angeforderte Kapazität unbenutzt auf.
Ein weiteres Ziel der Erfindung ist die Bereitstellung eines Wählbetrieb- bzw. Durchschalt-Netzwerks einer Bus- oder Ringstruktur. Das Netzwerk ist dadurch gekennzeichnet, daß wenigstens zwei Knoten, welche Serverknoten genannt werden, definiert sind, zwischen welchen Token entsprechend allen Zeitdatenslots, welche in einer Richtung in einem Bus oder Ring strömen, verteilt sind, und daß die Serverknoten angeordnet bzw. ausgebildet sind, um Reservierungen für Token durchzuführen und diese an einen dritten Knoten in dem Fall zu übertragen, daß die Serverknoten eine Anforderung für Token von dem dritten Knoten erhalten und daß sie die angeforderte Kapazität unbenutzt aufweisen.
In vorteilhafter Weise ist das Netzwerk ein Netzwerk des DTM-Typs (Dynamic Synchronous Transfer Mode).
Vorzugsweise ist ein Knoten angeordnet, um erhaltene Token für einen Aufbau von Kanälen durch ein Senden einer Kanalaufbaubotschaft an den Knoten oder die Knoten, welche als Empfänger von Daten gedacht sind, in dem Fall zu verwenden, daß der Knoten Token entsprechend der angeforderten Kapazität erhalten hat.
In vorteilhafter Weise sind einer oder mehrere Serverknoten angeordnet, um Reservierungen für Token durchzuführen und diese entsprechend der gesamten unbenutzten Kapazität an den anfordernden Knoten in dem Fall zu übertragen, daß die Serverknoten gemeinsam nicht die angeforderte Kapazität unbenutzt aufweisen.
Vorzugsweise sind einer oder mehrere Serverknoten angeordnet, um nicht jegliche Token zu dem anfordernden Knoten in dem Fall zu übertragen, daß die Serverknoten gemeinsam nicht die angeforderte Kapazität unbenutzt aufweisen.
In vorteilhafter Weise ist ein Knoten angeordnet, um eine Statustabelle, eine regelmäßig aktualisierte Liste der ungenutzten Kapazität von allen Serverknoten, für eine Entscheidung zu verwenden, von welchem Serverknoten Token anzufordern sind.
Ausführungsformen der Erfindung werden nun unter Bezugnahme auf die beigeschlossenen Zeichnungen beschrieben.

Kurze Beschreibung der Zeichnungen

Fig. 1 DTM-Multiplexformat.
Fig. 2 DTM-Knoten, welche in einer Netzwerkstruktur verbunden sind.
Fig. 3 Multi-Adressengruppe.
Fig. 4 Durchsatz und Zutrittsverzögerung für unterschiedliche Paketgrößen.
Fig. 5 Durchsatz und Verzögerung für eine Anforderung strikter Kapazität mit neuerlicher Anforderung (16 Kilobyte Übertragungen).
Fig. 6 Durchsatz und Zutrittsverzögerung für unterschiedliche Benutzeranforderungen (16 Kilobyte Übertragungen).
Fig. 7 Netzwerkdurchsatz und Durchtrittsverzögerung als eine Funktion der Buslänge (16 Kilobyte Übertragungen).
Fig. 8 Durchsatz und Zutrittsverzögerung in einem 20 · 20 Raster.
Fig. 9 DTM-Netzwerk einer Dualbus-Struktur.
Fig. 10 DTM 125 us Zyklus.
Fig. 11 Tokenmappe, welche Zeitslotnummer und -segment zeigt.
Fig. 12 Zeitslot-Segmentmappe, welche eine Wiederverwendung von Zeitslots zeigt.
Fig. 13 Distributed Token Server.
Fig. 14 Neuerliche Anforderung des Benutzers zur Erhöhung des Ausmaßes der Benutzung (15 kB).
Fig. 15 Defragmentation: Zutrittsverzögerung als eine Funktion der simulierten Zeit.
Fig. 16 Theoretischer Dualbus- und DTM-Durchsatz.
Fig. 17 Zentralisierter Tokenserver.
Fig. 18 Zentralisierter Tokenserver- und Zeitslot-Wiederverwendung.
Fig. 19 1.000 km Bus mit zentralisiertem Tokenserver.
Fig. 20 Verwendung und Zutrittsverzögerung: Distributed Token Server.
Fig. 21 1-1000 km Bus mit Distributed Token Server.
Fig. 22 Distributed Token Server.
Fig. 23-28 Zeitslot-Segment-Karten.

Detaillierte Beschreibung der Ausführungsformen

2. DTM - Dynamic Synchronous Transfer Mode

DTM ist ausgebildet bzw. konstruiert für ein unidirektionales Medium mit mehrfachem Zugang, d. h. ein Medium mit einer Kapazität, welche durch alle angeschlossenen Knoten geteilt bzw. gemeinsam genutzt wird. Es kann auf verschiedenen unterschiedlichen Topologien, wie beispielsweise einem Ring, gefaltetem Bus oder Dualbus, aufgebaut werden. Wir wählen den Dualbus, da er einen kürzeren, durchschnittlichen Abstand zwischen den Knoten als ein gefalteter Bus aufweist, und es wurde für das DTM-Synchronisationsschema gefunden, daß es einfacher auf einem dualen Bus als auf einem Ring zu implementieren ist.
Der Dienst bzw. das Service wird basierend auf Kanälen zur Verfügung gestellt. Ein Kanal ist ein Satz von Zeitslots bzw. -plätzen mit einem Sender und einer willkürlichen Anzahl von Empfängern; es wird sichergestellt, daß die Daten die Empfänger mit der Rate erreichen, welche durch die Kapazität des Kanals gegeben ist. Die Kanäle auf dem physikalisch geteilten bzw. gemeinsam genutzten Medium werden durch ein Zeitmultiplex-Schema (TDM) (Fig. 1) realisiert. Die Gesamtkapazität ist in Zyklen von 125 us unterteilt, welche weiter in 64-Bit-Plätze bzw. -Slots unterteilt sind.
Die Slots sind in Daten- und Kontroll- bzw. Steuerslots unterteilt. Jeder Knoten hat Zugang zu wenigstens einem Steuerslot, welcher für ein Senden von Kontroll- bzw. Steuerinformation zu den anderen Knoten verwendet wird. Kontroll- bzw. Steuerbotschaften können auf Anforderung von einem Benutzer, als Antwort auf Kontroll- bzw. Steuerbotschaften von anderen Knoten oder spontan für Managementzwecke gesandt werden. Die Kontrollslots bilden einen kleinen Teil der gesamten Kapazität, während der größere Teil der Slots Datenslots bzw. -plätze sind, welche Nutzlast tragen. Beim Systemstart werden die Datenslots den Knoten entsprechend einer gewissen vordefinierten Verteilung zugeteilt. Dies bedeutet, daß jedem Knoten ein Anteil der Datenslots "gehört". Ein Knoten braucht eine Eigentümerschaft eines Slots, um Daten in diesem zu senden, und die Eigentümerschaft der Slots kann sich dynamisch unter den Knoten während des Betriebs ändern.

2.1 Slotzuteilung

DTM verwendet einen verteilten Algorithmus für die Slotneuzuteilung, wo der Pool bzw. Vorrat von neuen Kanälen unter den Knoten verteilt wird. Es gab zwei Hauptgründe für eine Verwendung eines unterteilten Schemas anstelle eines zentralen Pools bzw. Vorrats an Slots. Zuerst gibt es, wenn ein Knoten einen Kanal lediglich unter Verwendung von Slots von dem lokalen Pool aufbauen kann, einen geringen Overhead in dem Kanalaufbau. Zweitens ist ein verteilter Algorithmus nicht von einem einzigen Knoten abhängig, so daß er eine gewisse Toleranz gegenüber Knotenausfällen aufweist. Der wesentliche Nachteil einer verteilten Implementierung ist der Overhead einer Kommunikation und Synchronisation zwischen Knoten.
Beim Erhalt einer Benutzeranforderung überprüft der Knoten zuerst seinen lokalen Pool bzw. Vorrat, um zu sehen, ob er ausreichend Slots bzw. Plätze aufweist, um die Anforderung zu erfüllen, und falls zutreffend, sendet er unmittelbar eine Kanalaufbaubotschaft an den nächsten Hop bzw. die nächste Einzelstrecke. Andernfalls muß der Knoten zuerst mehrere Slots von den anderen Knoten an dem Bus anfordern. Jeder Knoten enthält eine Statustabelle, welche Information über freie Slots in anderen Knoten enthält, und wenn mehr Slots erforderlich sind, konsultiert der Knoten seine Statustabelle, um zu entscheiden, welchen Knoten er um Slots fragen soll. Jeder Knoten sendet regelmäßig Statusbotschaften mit Information über seinen lokalen Pool bzw. Vorrat an Slots. Statusbotschaften haben eine geringere Priorität als andere Steuerbotschaften, so daß sie nur gesandt werden, wenn die Steuerslots andernfalls unbenutzt wären. Darüber hängt der Neuzuteilungsalgorithmus nicht von Knoten ab, um alle Statusbotschaften zu bearbeiten, so daß ein Knoten sicher Statusbotschaften ignorieren kann, während er beschäftigt ist.
Die Prozedur für eine Slot- bzw. Platzneuzuordnung ist einfach und arbeitet wie folgt: wenn ein Benutzer einen Kanal mit M Slots anfordert und der Knoten N freie Slots aufweist, wobei er Anforderungen mit einer Anfrage an Slots abschickt. Der Knoten startet durch ein Absenden einer Anforderung an den nächsten Knoten mit freien Slots. Wenn dieser Knoten nicht ausreichend viele freie Slots gemäß der Statustabelle aufweist, wird eine Anforderung auch an den zweitnächsten Knoten mit freien Slots abgesandt usw. Der Knoten wartet, bis eine Antwort für jede der Anforderungen empfangen wurde, und erteilt oder verwirft dann die Kanalanforderung in Abhängigkeit von dem Resultat der Neuzuweisungs- bzw. Neuzuordnungsprozedur.
Ein Knoten, welcher eine gewisse Menge J von freien Slots aufweist und eine Slotneuzuordnungsanfrage für K Slots erhält, wird immer min (J, K) Slots bereitstellen bzw. abgeben. Der Knoten antwortet durch Senden einer Slotneuzuordnungsbestätigung, welche anzeigt, welche Slots der Knoten abgibt. Wenn der angefragte Knoten keine freien Slots aufweist, antwortet er stattdessen mit einer Slotneuzuordnungsabsage. Zusätzlich zu diesem Algorithmus können Ressourcen bzw. Betriebsmittel durch ein Netzwerkmanagementsystem geregelt bzw. gesteuert werden. Um beispielsweise ein Aushungern des Netzwerks zu verhindern, kann ein Knoten konfiguriert werden, daß er nicht alle Slots abgibt, sondern daß er einen gewissen Teil seines ursprünglichen Anteils beibehält.

2.2 Umschalten bzw. Switchen

Ein DTM-Netzwerk kann durch ein Verbinden von mehreren Bussen mit Switch- bzw. Schaltknoten (siehe Fig. 2) erweitert werden. DTM verwendet ein dezentralisiertes Umschalten in dem Sinn, daß irgendein Knoten, welcher mit zwei oder mehr Bussen verbunden ist, Daten zwischen diesen schalten bzw. switchen kann. Ein Vorteil dabei ist, daß die Switchkapazität zunehmend bzw. stufenweise durch Hinzufügen von mehr Schaltknoten erhöht werden kann. Das Schalten ist synchron, wobei dies bedeutet, daß die Schaltverzögerung für einen Kanal konstant ist. Dies bedeutet, daß ein Multihop-Kanal ungefähr dieselben Eigenschaften wie ein Kanal auf einem einzelnen Bus aufweist. Der einzige Unterschied ist, daß ein geswitchter bzw. geschalteter Kanal eine etwas längere Verzögerung (bis zu 125 us für jeden Hop) aufweist. Vorausgesetzt, daß ein Switch- bzw. Schaltknoten einen Datenzyklus für jeden seiner Busse puffern bzw. speichern kann, kann kein Stau oder Overflow in dem Knoten auftreten.
Die Synchronisation zwischen den Bussen wird auf Basis eines einzelnen Zyklus durchgeführt - Zyklen werden mit derselben Frequenz auf allen Bussen gestartet. Dies wird erzielt, indem ein Netzwerkknoten zur periodischen Erzeugung der Zyklen an allen seinen ausgehenden Bussen verantwortlich gemacht wird. Für jeden neuen Zyklus erzeugt dieser Knoten eine Zyklusstartmarkierung, welche an alle Busse in dem Netzwerk abgegeben wird. Für jeden Bus besteht ein Switchknoten, welcher für eine Abgabe der Markierung auf den Bus verantwortlich ist. Diese Switchknoten müssen in einer derartigen Weise organisiert sein, daß die Markierung jeden Bus genau einmal erreicht. Wenn die Markierung einen Bus erreicht, wird der Zyklus an diesem Bus neu gestartet.
Die Zykluszeit und die Platz- bzw. Slotgröße sind beide konstant für alle Busse, wobei dies bedeutet, daß das Synchronisationsschema erlaubt, daß unterschiedliche Busse mit unterschiedlichen Bitraten betrieben werden. Dies macht es möglich, individuelle Busse in einem Netzwerk zu verbessern oder zu rekonfigurieren, ohne den Rest des Netzwerks zu beeinflussen.

2.3 DTM-Kanäle

Die Kanalabstraktion in DTM unterscheidet sich von gewöhnlichen Schaltungen bzw. Schaltkreisen dahingehend, daß die Kanäle die folgenden Eigenschaften aufweisen.
- Simplex: ein Kanal ist eingestellt bzw. aufgebaut von einem Sender zu empfangen. Eine Duplexverbindung besteht aus zwei Kanälen, einem in jeder Richtung.
- Multirate: Kanäle können aus einer beliebigen Anzahl von Datenslots bestehen, wobei dies bedeutet, daß die Kanalkapazität ein beliebiges Vielfaches von 512 Kbps bis zu der gesamten Datenkapazität des Busses sein kann.
- Multicast: ein Kanal kann verschiedene Empfänger aufweisen.
Ein Knoten erzeugt einen Kanal durch Zuordnen bzw. Zuweisen eines Satzes von Datenslots für den Kanal und durch Senden einer Kanalaufbau-Steuerbotschaft. Diese Kontroll- bzw. Steuerbotschaft wird entweder an einen einzelnen Knoten oder an eine Multicast-Gruppe adressiert und gibt bekannt, daß der Kanal errichtet wurde und welche Slots er verwendet.
Um einen Kanal zu erzeugen, müssen Slots beim Sender und bei jedem Switch- bzw. Schaltknoten entlang der Kanalroute zugeordnet werden. Derart weisen Switchknoten Slots für einen Kanal zugunsten des Senders zu. Die Switchknoten starten dann das Switchen bzw. Schalten des Kanals durch Kopieren der Slots des Kanals von dem einlangenden zu dem ausgehenden Bus. Ein Versuch, einen Multihop-Kanal aufzubauen, schlägt fehl, wenn einer der involvierten Switchknoten nicht die erforderliche Anzahl von Slots zuweisen kann. In diesem Fall muß eine andere Route versucht werden. In einer Raster- bzw. Gitterstruktur bestehen normalerweise verschiedene Routen zwischen jedem Paar von Knoten. Die gegenwärtige Version des Protokolls verwendet ein Source- bzw. Quellenrouten gemeinsam mit einem Adressierschema basierend auf (x, y)-Koordinaten in dem Raster. Ein einfaches Lastausgleichsschema für zwei Hops wird erreicht, indem ermöglicht wird, daß jeder Switchknoten Statusbotschaften verwendet, um Information über die Anzahl von freien Slots an seine ausgehenden Busse zu senden. Beispielsweise bestehen zwei mögliche Routen zwischen Knoten 1 und Knoten 4 in Fig. 2, so daß, falls Knoten 1 eine Verbindung zu Knoten 4 aufbauen bzw. einrichten will, er zwischen einer Verwendung des Switchknotens 2 und des Switchknotens 3 wählen kann. Der Knoten 1 erhält Statusinformation von Knoten 2 und 3 und kann seine Routingentscheidung basierend auf dieser Information durchführen. Dieser Algorithmus arbeitet auch gut für Netzwerke mit dichtem Gitter, wobei die meisten Routen nur zwei Hops bzw. Einzelstrecken verwenden, wobei ein allgemeiner Routing-Algorithmus für mehr zufällige bzw. willkürliche Topologien erforderlich ist.

2.3.1 Multicast-Kanäle

Eine traditionelle Schaltung ist eine Punkt-zu-Punkt-Verbindung zwischen einem Sender und einem Empfänger. DTM verwendet ein geteiltes bzw. gemeinsames Medium, welches inhärent Multicast unterstützt, da ein Slot durch verschiedene Knoten an einem Bus gelesen werden kann. Ein Multicast-Kanal kann leicht erweitert bzw. erstreckt werden, um sich über verschiedene Hops zu erstrecken, da der Switch- bzw. Schaltvorgang eigentlich ein Multicastvorgang in dem Sinn ist, daß er Daten auf einen anderen Bus dupliziert (siehe Fig. 3).

3. Netzwerkleistung

in diesem Abschnitt untersuchen wir den Durchsatz und die Verzögerung unter variierenden Verkehrsbedingungen. Wir haben Simulationen für zwei unterschiedliche Netzwerktopologien durchgeführt:
- Einen dualen Bus mit 100 Knoten.
- Ein vollständig verbundenes Gitter bzw. Raster von dualen Bussen mit 20 · 20 Knoten.
In dem Simulationsmodell erhalten Knoten Übertragungs- bzw. Transferanforderungen von einem Verkehrsgenerator und Steuerbotschaften von anderen Netzwerkknoten. Diese Vorfälle werden in eine Eingabeschlange bzw. -reihe an dem Knoten eingegeben und der Knoten verarbeitet einen Event bzw. einen Vorfall zu einer Zeit. Die Zeit zur Bearbeitung eines Events ist 5 us. Transferanforderungen werden durch Poisson-Verfahren erzeugt und Quellen- und Destinationsadressen werden einheitlich bzw. gleichmäßig verteilt. Für jede Transferanforderung versucht ein Knoten, Slots anzuweisen, und falls erfolgreich, baut er den Kanal auf, überträgt die Daten und baut den Kanal wieder ab. Dies bedeutet, daß Slots freigegeben werden, sobald der Transfer durchgeführt bzw. abgeschlossen ist.
Die Simulationen werden für unterschiedliche Transfergrößen (1 bis 256 Kilobyte), für unterschiedliche Arten von Benutzeranforderungen und für unterschiedliche Abstände zwischen Knoten (0,01 bis 10 km) durchgeführt. Die Verbindungsbitrate ist 4,8 Gbps, wobei dies eine Slotrate von 75 MHz und eine Zyklusgröße von 9.600 Slots ergibt. Jeder Transfer erfordert 40 Slots pro Zyklus. Dies entspricht 20,48 Mbps Kanälen, wobei dies bedeutet, daß ein 16 Kilobyte Transfer beispielsweise etwa 6 ms dauert.
Wie berechnen den Durchsatz durch Division der Gesamtmenge von übertragenen Userdaten durch die simulierte Zeit und normalisieren diesen Wert auf die Kapazität von einem dualen Bus (9,6 Gbps). Der maximale Durchsatz, welchen zu erzielen möglich ist, ist immer weniger als die Link- bzw. Verbindungskapazität, da eine gewisse Kapazität für Kontroll- bzw. Steuerbotschaften verwendet wird. In den Simulationen eines einzelnen Dualbusses mit 100 Knoten ist die Kontrollkapazität fünf Kontrollslots pro Knoten, wobei dies 5% Overhead entspricht. Der maximal mögliche Durchsatz ist dann 0,95.
Das Gitter bzw. der Raster weist mehr Knoten als der einzelne. Dualbus auf, jedoch weniger Knoten pro Bus (20 anstelle von 100). Da die Verkehrslast auf einem Bus über seine Knoten verteilt wird, bedeutet dies, daß bei einer gegebenen Buslast der Raster mehr Verkehr zu und von jedem Knoten aufweisen wird. Ein Knoten in dem Raster erfordert somit mehr Kontrollslots. Es weist jedoch ein Knoten eine begrenzte Kapazität zur Verarbeitung von Kontroll- bzw. Steuerbotschaften auf, und wir haben gefunden, daß mit einer Eventverarbeitungszeit von 5 ms eine sehr geringe Leistung erzielt wird, wenn mehr als 10 Kontrollslots pro Knoten verwendet werden. Wir verwenden daher 10 Kontrollslots pro Knoten in dem Raster, wobei dies einen maximal möglichen Durchsatz von 0,98 ergibt.
Die Zutrittsverzögerung ist die durchschnittliche Zeit von der Zeit, zu welcher eine Anforderung an einem Knoten anlangt, bis der Datentransfer startet. Sie ist eine Meßgröße des Overheads beim Kanalaufbau und beinhaltet die Zeit, welche es erfordert, um Slots zuzuordnen, eine Kanalaufbaubotschaft zu dem Empfänger zu senden und den ersten Datenslot zu senden. In dem Multihop-Fall wartet der Sender auf eine Bestätigung von dem Empfänger, daß der Kanal an beiden Bussen aufgebaut wurde, bevor er ein Senden von Daten startet. Für den Singelhop-Fall erzeugt nur der Sender alleine den Kanal zu dem Empfänger und kann daher mit dem Senden von Daten starten, sobald die Slots zugeteilt bzw. zugewiesen wurden.

3.1 Ein dualer Bus

Der erste Satz von Simulationen betrifft die Leistung von einem dualen Bus. Der Zweck dieser Simulationen ist vor allem, Slotzuteilungsschemata für unterschiedliche Benutzeranforderungen zu studieren. Da Slotzuweisungen an unterschiedlichen Bussen unabhängige Vorgänge sind, sind diese Resultate im allgemeinen für die Multihop-Fälle ebenfalls anwendbar.

3.1.1 Strikte Kapazitätsanforderung ohne Neuversuch

Fig. 4 zeigt die Resultate einer grundlegenden Simulation, wo ein Knoten höchstens einen Versuch macht, um die geforderte Kapazität für einen Kanal zuzuweisen, und die Anforderung verwirft, wenn die gesamte, angeforderte Kapazität nicht zugewiesen werden kann. Transfergrößen zwischen 1 und 256 Kilobyte werden simuliert. Die Simulation konnte nicht für die geringsten Transfers bzw. Übertragungen (1 und 2 Kilobyte in Fig. 4) bei hoher Last durchgeführt werden, da die Simulatoreventreihe zu groß wurde, was anzeigt, daß die Kontroll- bzw. Steuerkapazität erschöpft bzw. überfordert ist.
Bei niedriger Last werden die meisten Transferanforderungen unmittelbar akzeptiert und es steigt der Durchsatz linear mit der Last. Bei höherer Last wird die Slotneuzuteilung häufig, einige Transferanforderungen werden verworfen und der Durchsatz steigt nur marginal mit der Last bzw. Belastung. Wenn die Last noch höher wird, ist die Signalisierkapazität erschöpft und der Durchsatz steigt nicht an (oder geht zurück, wie in dem Fall für 1 Kilobyte Transfers in Fig. 4). Kleinere Transfers bzw. Übertragungen erfordern eine häufigere Kontroll- bzw. Steuersignalisierung als große Transfers bei einer gegebenen Last und es ist daher der Durchsatz geringer für kleinere Transfers als für größere (höchstens 0,47 wird erzielt für 1 Kilobyte Transfers, was 50% des maximal möglichen Durchsatzes ist, verglichen mit 85% für 256 Kilobyte Transfers). Der Durchsatz ist auch durch das strikte Benutzerverhalten begrenzt, welches erfordert, daß die gesamte, angeforderte Kapazität in einem einzigen Versuch zugewiesen wird. Die unten berichteten Simulationen zeigen, daß der Durchsatz durch ein Lockern dieser Anforderung erhöht werden kann.
Die Zutrittsverzögerung besteht bei geringer Last im wesentlichen aus der Zeit, welche für einen Knoten erforderlich ist, um die Transferanforderung zu verarbeiten, auf den ersten zur Verfügung stehenden Steuerslot (für die Kanalaufbaubotschaft) und dann auf den ersten Datenslot (80 ms insgesamt im Durchschnitt) zu warten. Wenn die Last ansteigt, müssen die Knoten Slots von anderen Knoten anfordern und eine größere Verzögerung wird eingebracht.

3.1.2 Strikte Kapazitätsanforderung mit Neuversuch

Es ist möglich, den Durchsatz zu erhöhen, wenn ermöglicht wird, daß ein Knoten neuerlich versucht, d. h. mehr als einen Versuch durchführt, um Slots für einen Kanal zuzuweisen. Fig. 5 zeigt den Durchsatz und die Zutrittsverzögerung für unterschiedliche Werte der maximalen Anzahl von zulässigen Neuversuchen. Wenn dem Knoten ein Neuversuch erlaubt bzw. zugestanden wird, können mehr Kanäle aufgebaut werden und der Durchsatz steigt an (bis zu 92% des maximal möglichen Durchsatzes), jedoch auf Kosten einer längeren Zutrittsverzögerung und einer größeren Signalisierung. Daher ist der Neuversuch am besten für Anwendungen geeignet, welche eine strikte Bandbreitenanforderung aufweisen, jedoch eine gewisse Zutrittsverzögerung tolerieren können. Wenn jedoch eine große Anzahl von Anforderungen beharrlich wiederum versucht wird (wie dies in einer Überlastsituation der Fall ist), wird die Leistung absinken. Fig. 5 zeigt, daß die Leistung absinkt, wenn die Last hoch ist und den Knoten erlaubt wird, es zwanzigmal neu zu versuchen, wobei dies anzeigt, daß die Signalisierkapazität nicht ausreichend für 20 Neuversuche ist.

3.1.3 Flexible Kapazitätsanforderung

Eine Anwendung mit weniger bindenden bzw. zwingenden Anforderungen betreffend die Kapazität kann vorbereitet werden, Kanäle mit weniger Kapazität als angefordert zu akzeptieren. Dies erlaubt, daß mehr Kanäle mit einem einzigen Slotzuweisungsversuch aufgebaut werden. Fig. 6 zeigt den Durchsatz und die Verzögerung für drei Fälle: wenn der Benutzer mit irgendeiner Kapazität (Minimum 1 Slot) zufriedengestellt ist, wenigstens die Hälfte der angeforderten Kapazität (20 Slots) erfordert und die volle Kapazität (40 Slots) benötigt. Der Durchsatz steigt an, wenn der Benutzer weniger anspruchsvoll ist. Wenn der Benutzer lediglich einen Slot erfordert, wird der erreichte Durchsatz 94% des maximal möglichen Durchsatzes. Die Slotneuzuweisungsprozedur ist jedoch dieselbe in allen drei Fällen, was erklärt, warum die Zutrittsverzögerung praktisch dieselbe in den drei Fällen ist.

3.1.4 Leistung als eine Funktion des Abstands

Wenn der Abstand zwischen Knoten ansteigt, erfordert es eine längere Zeit, Kontroll- bzw. Steuerbotschaften für eine Slotneuzuordnung auszutauschen. Dies kann in Fig. 7 ersehen werden, welche den Durchsatz und die Zutrittsverzögerung für unterschiedliche Buslängen (mit einer strikten Kapazitätsanforderung ohne Neuversuch, d. h. dasselbe Slotzuweisungsprinzip wie in Fig. 4) zeigt. Die Zutrittsverzögerung steigt signifikant an, wenn der Bus länger wird. Dies beeinflußt jedoch hauptsächlich die Erzeugung von Kanälen und der Durchsatz ist daher relativ unabhängig von dem Abstand. Ein anderer Effekt einer vergrößerten Buslänge ist es, daß längere Zeit dauert, Statusinformation weiterzugeben, was die Möglichkeit bzw. Wahrscheinlichkeit eines Slotneuzuweisungsfehlers erhöhen kann. Dies würde hauptsächlich den Durchsatz beeinflussen, wobei jedoch die Simulationsresultate andeuten, daß dies nur einen geringen Effekt bzw. Einfluß hat.

3.2 Rasternetzwerk

Fig. 8 zeigt das Resultat einer Simulation für Multihop-Kanäle. Das Netzwerk ist ein vollständig verbundenes Rasternetzwerk mit 20 · 20 Knoten. Kanäle verwenden wenigstens zwei Hops und die Routingentscheidung basiert auf der Information von Statusbotschaften. Das Slotzuweisungsprinzip ist dasselbe wie in Fig. 4, d. h. strikte Anforderung ohne Neuversuch.
Mit einer einheitlichen Verteilung von Source-Destinations-Paaren ist der theoretische, maximale Durchsatz eines vollständig verbundenen Netzwerks, wo n die Anzahl von Bussen ist. Mit 2,1% Signalisier-Overhead weist das 20 · 20 Raster einen maximal möglichen Durchsatz von etwa 20,6 auf. Fig. 8 zeigt, daß für 256 Kilobyte Transfers der maximale Durchsatz 97,5% des möglichen Maximums beträgt, verglichen mit 95,1% für 16 Kilobyte Transfers. Dies ist signifikant mehr als in dem Fall eines einzigen dualen Busses (Fig. 4) und unsere Erklärung dafür ist, daß weniger Knoten pro Bus in dem Raster existieren, wobei dies bedeutet, daß der Pool bzw. Vorrat von freien Slots weniger verteilt bzw. zerstreut ist und daß daher eine höhere Wahrscheinlichkeit besteht, daß eine Slotneuzuweisung erfolgreich ist.
Die Zutrittsverzögerung für einen Multihop-Kanal wird länger als für einen einzelnen Hop, da Slots an zwei Bussen zugewiesen werden müssen. Für 256 Kilobyte Transfers ist die Zutrittsverzögerung etwa 50% länger in dem Multihop-Fall verglichen mit dem Einzelhop-Fall. Man könnte erwarten, daß die Zutrittsverzögerung in dem Raster länger als dieses ist. Es bestehen zwei Hauptgründe, warum es nicht der Fall ist. Zuerst besteht ein gewisses Ausmaß an Parallelität beim Kanalaufbau über zwei Hops. Zweitens ist das Intervall zwischen Steuerslots kürzer in dem Raster, so daß ein Knoten weniger Zeit damit verbraucht, auf Steuerslots zu warten. Für 16 Kilobyte Transfers steigt die Verzögerung jedoch dramatisch für höhere Lasten an, wobei dies andeutet, daß die Signalisierkapazität unzureichend ist.

4. Schlußfolgerung und zukünftige Arbeit

Der Dynamic Synchronous Transfer Mode (DTM) ist eine Netzwerkarchitektur für integrierte Dienste. Er basiert auf einem schnellen Schaltkreisswitchen, und stellt Multirate-, Multicast-Kanäle mit kurzer Setup-Zeit zur Verfügung. Ein Kanal gibt eine garantierte Kapazität und konstante Verzögerung, was es gut geeignet für Echtzeitverkehr, wie beispielsweise Video und Audio, macht. Im Gegensatz zu traditionellen Durchschalt-Netzwerken stellt DTM auch eine dynamische Neuzuordnung bzw. Neuzuteilung von Ressourcen bzw. Betriebsmitteln zwischen Knoten zur Verfügung, um dynamisch variierenden Verkehr zu unterstützen.
Wir haben eine Leistungsanalyse durch Computersimulationen für verschiedene Konfigurationen berichtet. Die Analyse richtet sich vor allem auf paketartige Verkehrsmuster, da diese Art von Verkehr als die größte Herausforderung für ein Netzwerk basierend auf einem Schaltkreis-Switchen betrachtet wird. Die Intention ist zu studieren, wie eine Netzwerkverwendung und Zutrittsverzögerungen beeinflußt werden, wenn Kanäle häufig aufgebaut und freigegeben werden. Wir verwenden 20 Mbps Kanäle, wo ein Kanal für jeden Transfer aufgebaut wird, und die Transfergröße variiert zwischen 1 und 256 Kilobyte. Die Analyse wurde für zwei Arten von Topologien durchgeführt: ein dualer Bus und ein Raster von dualen Bussen. Das Protokoll erfordert, daß ein gewisser Anteil der gesamten Kapazität für Steuerinformation reserviert ist: wir verwendeten etwa 5% für den dualen Bus und 2 % für das Raster.
Die Resultate zeigen, daß, wenn der Verkehr aus kurzen, häufigen Transfers (von einigen Kilobytes) besteht, die Leistung durch die Menge der zur Verfügung stehenden Signalisierkapazität bestimmt wird. Für den dualen Bus werden gute Resultate erzielt, selbst wenn das Netzwerk mit Transfers belastet ist, welche nur einige wenige Kilobytes lang sind, während das Raster für 16 Kilobyte Transfers gesättigt war. Zusammenfassend zeigt die Anwendung, daß ein schnelles Schaltkreis-Switchen, wie in DTM angewandt, selbst für Paketverkehr gut arbeitet, welcher kurzlebige Verbindungen verwendet. Dies in Kombination mit seiner inhärenten Unterstützung für Echtzeitverkehr macht ein schnelles Schaltkreis-Switchen bzw. -Durchschalten zu einer interessanten Alternative für B-ISDN und darüber hinaus.
Für zukünftige Arbeit regen die Leistungsresultate an, daß man für ein Versenden von Paketen auf DTM zuerst ein Schema finden muß, um Pakete auf Kanälen zu multiplexen, welches Pakete gemeinsam in geringfügig größere Einheiten gruppiert. In der Annahme, daß Computer Verkehr erzeugen, welcher den Trainmodell-Bursts von Paketen entspricht, wo viele Pakete innerhalb eines Stoßes bzw. Bursts dieselbe Bestimmung bzw. Destination aufweisen, - ein einfaches Schema, ähnlich zu denjenigen, welche in den frühen, schnellen Durchschalt-Netzwerken verwendet wurden, scheint geeignet bzw. anwendbar. In einem derartigen Schema ist der Kanal geschlossen und seine Ressourcen werden freigegeben, wenn der Sender für mehr als eine vorbestimmte Zeitdauer untätig war. Dies ist jedoch ein Bereich, welcher eine weitere Untersuchung erfordert. Die Leistungsresultate sind ermutigend und wir werden weiter die Effekte von nicht-einheitlichen Verkehrsmodellen, beispielsweise stoßweisen Quellen und asymmetrischen Sender-Empfänger-Verteilungen untersuchen.

5. DTM-Medium-Zutrittskontrollprotokoll - DTM-MAC

Die grundlegende Topologie eines DTM-Netzwerks (siehe Fig. 9) ist ein Bus mit zwei unidirektionalen, optischen Fasern, welche alle Knoten verbinden. Mehrere Busse mit unterschiedlichen Geschwindigkeiten können miteinander verbunden werden, um ein willkürliches Multistage-Netzwerk zu bilden. In der gegenwärtigen Prototyp- Implementation können Busse in ein zweidimensionales Gitter bzw. Netz kombiniert werden. Ein Knoten an der Verbindung von zwei Bussen kann synchron Datenslots zwischen den zwei Bussen schalten bzw. switchen. Dies erlaubt ein effizientes Schalten mit einer konstanten Verzögerung durch den Knoten. Die primäre Kommunikationsabstraktion von DTM ist ein unidirektionaler Multirate- und Multicast-Kanal.
Das DTM-Medium-Zutrittskontrollprotokoll ist ein Zeitmultiplexschema. Die Bandbreite des Busses ist unterteilt in Zyklen von 125 us (Fig. 10), welche wiederum in Timeslots von 64 Bit (oder kurz Slots) unterteilt sind. Die Anzahl von Slots in einem Zyklus hängt derart von der Netzwerk-Bitrate ab; beispielsweise bestehen bei einem 6,5 Gbit/s-Netzwerk etwa 12.500 Slots pro Zyklus.
Die Slots bzw. Plätze werden in zwei Gruppen unterteilt, Kontroll- bzw. Steuerslots und Datenslots. Kontrollslots werden verwendet, um Botschaften für den interen Betrieb des Netzwerks zu tragen, wie beispielsweise Botschaften für einen Kanalaufbau und eine Bandbreiten-Neuzuweisung. Die Datenslots werden verwendet, um Benutzerdaten zu übertragen und werden nicht durch zwischenliegende Netzwerkknoten interpretiert. Zwischenliegende Knoten sind Knoten zwischen der Quelle und der Destination bzw. dem Adressaten.
In jedem Netzwerkknoten besteht ein Knotenkontroller, welcher den Zutritt zu Datenschlitzen bzw. -slots kontrolliert bzw. steuert und Netzwerkmanagementvorgänge, wie beispielsweise einen Netzwerkstart und eine Fehlersuche, durchführt. Die Hauptaufgaben des Knotenkontrollers sind, Kanäle auf Anforderung bzw. Anfrage von Benutzern zu erzeugen und zu schließen bzw. zu beenden und Netzwerkressourcen bzw. -betriebsmittel in Antwort auf Benutzeranforderungen und im Hintergrund zu managen.
Kontrollslots werden ausschließlich für Botschaften zwischen Knotenkontrollern verwendet. Jeder Knotenkontroller weist eine Schreiberlaubnis zu wenigstens einem Kontrollslot in jedem Zyklus auf, welchen er verwendet, um Kontrollbotschaften zu stromabwärts liegenden Knoten zu senden. Da der Schreibzutritt zu Kontrollslots exklusiv ist, hat der Knotenkontroller immer Zutritt zu seinen Kontrollslots, unabhängig von anderen Knoten und der Netzwerklast. Die Anzahl von Kontrollslots, welche ein Knoten verwendet, kann während des Netzwerkbetriebs variieren.

6. Tokenmanagement

Die Mehrheit der Slots in einem Zyklus sind Datenslots. Der Zugang zu Datenslots ändert sich mit der Zeit entsprechend den Verkehrsanforderungen. Ein Schreibzugang zu Slots wird durch Slottoken (oder kurz Token bzw. codierte Befehlswörter) geregelt bzw. gesteuert. Ein Knotenkontroller kann Daten in einen Slot nur schreiben, wenn er das entsprechende Token besitzt. Das Tokenprotokoll stellt sicher, daß der Slotzutritt konfliktfrei ist, wobei dies bedeutet, daß höchstens ein Knoten Daten in denselben Slot schreibt.
Kontroll- bzw. Steuerbotschaften für einen Kanalaufbau und eine Bandbreiten- Neuzuweisung tragen Sets von Token als Parameter. Eine Steuerbotschaft ist jedoch 64 Bit und kann daher nur eine geringe Anzahl von Parametern aufweisen. Dies bedeutet, daß es, wenn ein Benutzer einen Transfer mit einer großen Bandbreite anfordert, notwendig sein kann, mehrere Steuerbotschaften zu senden, um den Kanal aufzubauen. Dies bringt eine zusätzliche Zutrittsverzögerung und verbraucht Signalisierkapazität.
Wir überlegen verschiedene Mechanismen, um das Ausmaß an Information, welches während einer Kanalerzeugung und einer Tokenneuzuweisung gesendet werden muß, zu verringern. Die erste Optimierung im Tokenmanagement ist, Block- Token einzuführen. Ein Block-Token wird in einer einzigen Steuerbotschaft übermittelt und repräsentiert eine Gruppe von Token, wobei es jedoch nur für spezielle Kombinationen von Token verwendet werden kann. Beispielsweise ist in den in diesen Unterlagen beschriebenen Netzwerksimulationen ein Block-Token durch eine Slotnummer und einen Offset bezeichnet, welcher die Anzahl von aneinander anschließenden Slots in der Gruppe gibt. Die Block-Token-Optimierung nimmt an, daß der Tokenvorrat bzw. -pool nicht in kleine Teile fragmentiert ist. Das Ausmaß von kleinen Tokenblocks in dem Pool kann ein Problem sein und wird als Fragmentation bezeichnet.

6.1 Slotwiederverwendung

Das Tokenprotokoll garantiert, daß ein Datenslot niemals durch zwei Knoten gleichzeitig an dem Bus verwendet werden kann. Manchmal ist dieses Protokoll zu konservativ. Fig. 11 zeigt ein Beispiel, wie drei Token (A, B und C) für drei Kanäle reserviert sind. Knoten sind durch Bussegmente verbunden und Kanäle verwenden typischerweise einen Subsatz der Segmente auf dem Bus (graue Farbe) und der Rest ist reserviert (weiße Farbe), wobei er jedoch unbenutzt verbleibt und somit geteilte bzw. gemeinsam genutzte Ressourcen vergeudet. Eine bessere Alternative ist es, Kanäle nur Kapazität an den Segmenten zwischen dem Sender und dem Empfänger, wie das Beispiel in Fig. 12, reservieren zu lassen. Ein einzelner Slot kann in diesem Fall mehrfach auf dem Bus verwendet werden. Kanal D und E verwenden dieselben Slots wie Kanal A und C, jedoch an unterschiedlichen Segmenten. Dies wird als Slotwiederverwendung bezeichnet. Eine Slotwiederverwendung ermöglicht gleichzeitige Übertragungen in demselben Slot über nicht miteinander verbundene Segmente des Busses.
Slotwiederverwendung ist ein allgemeines Verfahren, um geteilte bzw. gemeinsame Links in Ring- und Busnetzwerken besser zu nutzen. Die Slotwiederverwendungsalgorithmen in DQDB (Distributed Queue Dual Bus), Simple und CRMA (Cyclic Reservation Multiple Access) hängen von Kontroll- bzw. Steuerinformation in den Slots ab. Puffereinführnetzwerke, wenn kombiniert mit einer Destinationsfreigabe wie METARING, können die Kapazität von einzelnen Links nochmals verwenden und eine gegebenenfalls bestehende Unstimmigkeit durch eine Verzögerung des einlangenden Paketstroms durch einen elastischen Puffer lösen.
Bei einer Slotwiederverwendung wird die Zutrittsschemakomplexität erhöht, unabhängig davon, ob dies in der Hardware wie in DQDB, Simple und CRMA, oder in der Software, wie in DTM, durchgeführt wird. Wenn in Systemen unterschiedlich von DTM implementiert, fügt eine Slotwiederverwendung auch komplexe Hardware zu dem kritischen Hochgeschwindigkeitsweg durch einen Knoten hinzu und erhöht daher die Knotenverzögerung.
Um eine Slotwiederverwendung in DTM zu erlauben, wird das Block-Token-Format erweitert, um Parameter zu beinhalten, welche das (die) Segment(e) beschreibt, welche(s) sie repräsentieren. Das Tokenmanagementprotokoll wird auch modifiziert, um Konflikte in der Slotanzahldimension als auch der Segmentdimension zu vermeiden. Die wichtigste Annahme ist, daß keine Hardware-Änderungen an der ursprünglichen Prototypimplementation erlaubt wurden oder erforderlich waren. Der Leistungsgewinn ist auch sehr klar: an einem Dualbus, wo Quellen- und Destinationspaare einheitlich bzw. gleichmäßig verteilt sind, wurde gezeigt, daß der Durchsatz um einen Faktor von 2 erhöht werden kann. Der potentielle Nachteil einer Slotwiederverwendung in einem DTM-Netzwerk ist die höhere Komplexität des Algorithmus und eine möglicherweise höhere Last an dem Knotenkontroller und den Signalisierkanälen (insbesondere, wenn die durchschnittliche Kanaldauer kurz ist).

6.2 Zentraler Tokenmanager

Zwei Tokenmanagementschemata wurden evaluiert. Das erste und einfachste ist es, einen einzelnen Knotenkontroller alle freien Token an einer Faser managen zu lassen. Diese Art eines zentralisierten Servermechanismus wurde auch in Systemen, wie CRMA [22], verwendet, wo der Kopfendknoten die Faserkapazität an alle anderen Knoten verteilt. Wir konfigurierten den Simulator so, daß für jede Faser ein Knoten ein Drittel entfernt von dem Supportgenerator der Tokenserver ist. Ein Tokenserver wird dann etwa dieselbe Anzahl von Verkehr auf beiden Seiten aufweisen.
Jedesmal, wenn eine Benutzeranforderung an einem Knoten anlangt, fordert der Knoten zuerst Token von dem Manager an und verriegelt diese dann durch die Kanallebensdauer. Wenn der Benutzer eine Anforderung zur Trennung des Kanals abgibt, werden die Token unmittelbar zu dem Manager retourniert. Alle Anforderungen werden während der Tokenanforderung verzögert und Zutritte werden durch den zentralen Manager in Serie angeordnet.

6.3 Verteilter Tokenmanager

Der verteilte Tokenmanager ist wesentlich komplizierter als der zentralisierte. Wir versuchten, ihn so einfach wie möglich zu halten. In unserem Verfahren übermittelt jeder Knoten regelmäßig Statusinformation, wieviele freie Token er aufweist. Die anderen Knoten speichern diese Information in ihren Statustabellen. Ein Knoten, welcher mehr Kapazität will, konsultiert seine Statustabelle, um zu entscheiden, von welchem Knoten er Slots anfordern soll. Das Protokoll an der Initialisierungsseite arbeitet wie folgt, wenn eine Benutzeranforderung an einem Knoten anlangt:
1. Wenn der Knoten ausreichend viele freie Token aufweist, um der Anforderung zu genügen, weist er die angeforderte Menge an Slots dem Benutzer zu und startet den Kanal durch Absenden einer Kanalaufbaubotschaft zu dem Destinationsknoten und dann Übertragen der Daten unter Verwendung der reservierten Slots.
2. Andernfalls markiert der Knoten seine verfügbaren Token als reserviert und überprüft dann seine Statustabelle: wenn die gesamte Menge an freien Token in dem Netzwerk nicht ausreichend ist, um die Anforderung zu erfüllen, wird die Anforderung verworfen (blockiert). Andernfalls fordert der Token von Knoten mit ungenutzter Kapazität an.
Wenn einer dieser Knoten, welcher eine Tokenanforderung erhält, nicht die angefragte Menge an freien Slots aufweist, gibt er dennoch alle seine Slots ab, über welche er verfügt. In jedem Fall sendet er eine Antwort zurück zu dem anfragenden Knoten. Ein Knoten erfüllt einlangende Anfragen in einer strikten FIFO-Reihenfolge (first in, first out).
Wenn ein Knoten eine Antwort von einer Tokenanforderung erhält, markiert er die Slots, welche er in der Antwort (gegebenenfalls) erhalten hat, als reserviert. Wenn der Knoten Antworten auf alle Anforderungen erhalten hat, welche er ausgesandt hat, startet er entweder die Kanäle oder verwirft die Useranforderung in Abhängigkeit davon, ob er eine ausreichende Kapazität erhalten hat. Wenn die Benutzeranforderung verworfen wird, werden die reservierten Slots als frei markiert.
Beim Hochfahren werden alle freien Token gleichmäßig unter den Netzwerkknoten verteilt und jeder Knoten nimmt zumindest einen seiner freien Token, bewegt ihn (sie) in den aktiven Status und bezeichnet ihn (sie) als einen Kontroll- bzw. Steuerslot. Benutzeranforderungen können nun akzeptiert werden und Token können zwischen Knoten auf Anforderung bewegt werden. Wenn der lokale Knoten genug Token enthält, um eine einlangende Benutzeranforderung zu erfüllen, kann die Anforderung ohne eine Tokenneuzuweisung akzeptiert werden.
Eine Schwäche bei diesem Schema ist, daß eine Slotneuzuordnung nur durch Benutzeranforderungen ausgelöst wird und daß Benutzeranforderungen durch eine anhängige Tokenneuzuordnung verzögert werden. Eine Optimierung, welche wir implementiert haben, um dies zu verbessern, ist, auch eine Slotneuzuordnung bzw. -zuweisung im Hintergrund durchzuführen. Dies resultiert in einer geringeren Notwendigkeit, Token für Anforderungen kleiner oder mittlerer Größen neu zuzuweisen.
Der Pool bzw. Vorrat an freien Token kann auf andere Weise als einheitlich bzw. gleichmäßig verteilt werden, um die Geschwindigkeit für eine erfolgreiche Neuzuweisung und Verwendung zu erhöhen. Wenn weniger Knoten den Vorrat managen, wird eine Kanalblockade als ein Resultat einer geringeren Möglichkeit bzw. Wahrscheinlichkeit, daß Token falsch zugewiesen werden, verringert.
Der komplette Tokenpool wird in diesem Fall proportional verteilt (Knoten nahe dem Slotgenerator werden mehr Token aufweisen als Knoten weit weg von diesem) unter allen Knoten. Die Übertragung von Knoten kann zwischen jedem Paar von Knoten stattfinden, anstatt immer den Serverknoten zu benutzen. Wenn der lokale Knoten eine ausreichende Anzahl von Token aufweist, um eine einlangende Benutzeranforderung zu erfüllen, kann die Anforderung ohne jede Tokenneuzuweisung akzeptiert werden. Darüber hinaus wird, solange die einlangenden Benutzeranforderungen gut durch die Poolverteiltung gehandhabt werden, keine Neuzuweisung jemals erforderlich sein.
Verschiedene Fragen müssen beantwortet werden, bevor entschieden wird, wie der Tokenpool verteilt wird. Wir adressieren die folgenden Problemkreise:
1. Wenn lokale Ressourcen bzw. Betriebsmittel in dem Knoten nicht ausreichend sind, um eine User- bzw. Benutzeranforderung zu erfüllen, welcher andere Knoten sollte für mehr Token befragt werden?
2. Wenn ein Knoten um Token von verschiedenen Knoten anfragt, wieviele Knoten soll er anfragen und sollte der Knoten den Kanal verwerfen, wenn er einen Bruchteil der angefragten Kapazität erhält?
3. Wenn sich die Token frei unter den Knoten bewegen, wird der Tokenvorrat in kleine Teile fragmentiert und das Block-Token-Optimierungsschema nutzlos machen?

6.3.1 Statusbotschaften

Wir entschieden, Statusbotschaften zu verwenden, um Information über den Vorrat an freien Token zu erteilen. Statusbotschaftinformation wird verwendet, um einem Knoten zu helfen, einen geeigneten Knoten auszuwählen, wenn er um mehr Ressourcen anfragt. Dieses Verfahren adressiert die obige, erste Frage.
Unser Schema arbeitet wie folgt. Jeder Knoten übermittelt regelmäßig Statusinformation, wieviele freie Token er aufweist. Die anderen Knoten speichern diese Information in ihren Statustabellen. Ein Knoten, welcher mehr Kapazität will, konsultiert seine Statustabelle, um zu entscheiden, von welchem Knoten er Slots anfragen soll. Die übertragene Statusinformation gibt einen ungefähren Überblick des gegenwärtigen Zustands von Tokeninformation, so daß Tokenanforderungen verworfen werden können, da sie an Knoten gesandt wurden, welche keinerlei weiteren Token abzugeben haben.
Statustabellen sind "weiche" Information in dem Sinn, daß das System selbst dann arbeiten wird, wenn sie nicht aktuell oder nicht verfügbar sind. Sie sollten jedoch die Erfolgsrate von Neuzuweisungsprozeduren verbessern.

6.3.2 Vermeiden von unnötigen Zurückweisungen

Wenn die Basisleistung des zentralisierten (Fig. 17) und des verteilten (Fig. 20) Tokenmanagements verglichen wird, können wir sehen, daß eine neue Art einer Zurückweisung von Benutzeranforderungen existiert, welche in dem verteilten System häufig sind, obwohl sich unverändert ungenutzte Ressourcen in dem System befinden.
Ein Knoten verwendet die Statustabelle, um einen bzw. mehrere Knoten auszuwählen, von welchem(n) er Token anfragt. Wenn die Anfrage den Zielknoten erreicht, kann sich die Menge an verfügbarer Kapazität geändert haben und eine geringere Menge als angefordert kann zu dem anfragenden Knoten retourniert werden, wobei dies in einer Benutzerzurückweisung resultiert.
Dieses Verhalten resultiert in unnotwendigen Tokenübertragungen und einer Verschwendung von Bandbreitenressourcen, da Slots während des Tokentransfers nicht verwendet werden. Der Statusbotschaftsmechanismus wird auch weniger effizient arbeiten, wenn Token häufiger bewegt werden.
Wenn der Pool bzw. Vorrat proportional unter einer großen Anzahl (einige hundert) von Knoten verteilt ist, wird die Größe des durchschnittlichen Pools relativ klein sein. Wenn die Belastung bzw. Last hoch ist, wird die Anzahl von freien Token in den Pools noch weiter abnehmen. Wenn Knoten auch Kanäle mit einer sehr hohen Geschwindigkeit erzeugen und zerstören, wird die Menge an freier Kapazität in einzelnen Knoten zwischen einer sehr geringen Kapazitätmenge und überhaupt keiner Kapazität variieren. Wenn nun die mittlere Kapazität, welche durch einen Benutzer angefragt wird, groß ist im Vergleich mit der Anzahl von freien Token an einem Knoten, müssen mehr Knoten befragt werden, um die Anforderung zu erfüllen. Zu diesem Zeitpunkt wird die Möglichkeit, daß die angefragten Knoten keine freie Kapazität aufweisen, zu einer Benutzerzurückweisung führen.
Es gibt viele Wege, um dieses Problem zu adressieren, ohne zu einem zentralisierten Modell zurückzukehren. Zuerst müssen wir nicht überhaupt irgendwelche Slots abgeben, wenn die vollständige Anforderung nicht erfüllt werden kann. Dieses Protokoll ist selbst dann anwendbar, wenn nur ein Knoten um freie Knoten befragt wird, wobei es jedoch, wenn mehrere Knoten befragt werden, unverändert in der Bewegung von Token resultieren kann oder darin, daß Token ungenutzt verriegelt bzw. blockiert sind. Zweitens können wir, wenn wir nach einer Tokenanforderung weniger Token als die angefragte Anzahl erhalten, einfach noch einmal und viele Male versuchen, die Prozedur für eine Tokenanforderung anzufordern bzw. durchzuführen. Dies wird die Möglichkeit für eine Benutzeranforderung erhöhen, daß sie akzeptiert wird und daß die erhaltenen Token verwendet werden. Der Aufwand für die wiederholte Überprüfung bzw. Abfrage wird ein erhöhtes Signalisieren und eine erhöhte Zutrittsverzögerung sein und kann die Leistung eines überladenen Netzwerks verschlechtern. Selbst die wiederholten Versuche durch den Benutzer führen zu längeren Setup-Verzögerungen für eine Anforderung, welche einer wiederholten Überprüfung unterworfen wurde. Drittens kann der Benutzer manchmal wünschen, einen Kanal mit weniger als der angeforderten Kapazität zu akzeptieren, anstatt verworfen bzw. zurückgewiesen zu werden. Wenn beispielsweise ein Benutzer 50% von dem erhält, was angefragt wurde, kann er willens sein zu akzeptieren. In Fig. 13 ist die Leistung für kleine (16 Kilobyte) Benutzeranforderungen mit unterschiedlichen, geringstmöglich akzeptierbaren Kapazitäten (100% (40 Slot), 50% (20 Slots) und 5% (1 Slot)) geoffenbart. Eine niedrigere, durchschnittliche, weniger akzeptable Bandbreite wird in einer höheren Benutzung resultieren. In Fig. 14 ist die Leistung geoffenbart, welche das Resultat sein wird, wenn der Benutzer wiederholte Versuche bis zu achtmal durchführt, bevor wir schließlich die Anforderung blockieren. Die Verwendung wird ansteigen (und das Blockieren wird ansteigen) auf Kosten einer größeren Signalübertragung und längerer Verzögerungen. Eine wiederholte Überprüfung in einer großen Anzahl wird der Produktivität entgegenwirken, falls sie oft auftritt.
Absolut gesehen besteht die Ausbeute mit einer Politik einer flexiblen Benutzeranforderung in einer geringeren Möglichkeit einer Zurückweisung und einem höheren Gesamtdurchsatz. Es kann für jede der Konfigurationen, welche in Fig. 13 und Fig. 14 geoffenbart sind, zu dem Zeitpunkt entschieden werden, wenn eine Anforderung eintrifft. Ein Benutzer, welcher strikte Anforderungen betreffend die Kapazität an einen Kanal aufweist, kann eine wiederholte Überprüfung anfordern, bis eine ausreichende Kapazität zugewiesen wird, während ein anderer Benutzer eher einen Kanal mit einer geringeren als der angeforderten Menge akzeptieren kann. Für den Rest der hier präsentierten Simulationen definieren wir die geringere, akzeptable Bandbreite, daß sie 50% der angeforderten Kapazität beträgt.

6.3.3 Fragmentation

In dem allgemeinen Fall ist die durchschnittliche Anzahl von zusammenhängenden, freien Blöcken in einem Knoten aufgrund der zufälligen bzw. willkürlichen Bewegung der Token und der variierenden Kapazität von Benutzeranforderungen gering. Diese Fragmentation macht die Block-Token-Optimierung praktisch nutzlos und die Zutrittsverzögerung wird relativ lang (ms) für Kanäle hoher Kapazität. Um die Blockzuweisung effizient zu machen, ist es notwendig, die Fragmentation von freien Token zu reduzieren, da andernfalls die Fragmentation bei weitem der Hauptbeitrag zu einer Zutrittsverzögerung für Kanäle hoher Bandbreite bei mittlerer bis hoher Belastung sein wird. Kanäle geringer Kapazität werden nahezu immer eine sehr kurze Kanalaufbauverzögerung unabhängig von dem gegenwärtigen Ausmaß der Fragmentation aufweisen. In dem Fall einer Slotwiederverwendung ist das Fragmentationsproblem noch schlimmer, da eine Fragmentation sowohl in Slot (Zeit) als auch Segment (Raum) Dimensionen (siehe Fig. 12) auftreten kann. Dies ist in der zentralisierten Serverversion eine spezielle Anwendung des allgemeinen Problems der dynamischen Speicherungs-Zuweisung. In dem verteilten bzw. distributed Tokenmanager ist der Hauptteil der Fragmentation ein Resultat der Verwendung von vielen freien Pools (einen für jeden Knoten). Zwei freie, benachbarte Knoten können nur zusammengefaßt werden, wenn sie in demselben Knoten gefunden werden.
Wir haben einen Mechanismus implementiert, welcher Defragmentationsschema genannt wird, welcher eine Fragmentation, falls möglich, zu vermeiden versucht und die durchschnittliche Blockgröße von freien Token in den Knoten erhöht. Dieses Schema wird sowohl mit als auch ohne eine Slotwiederverwendung verwendet.
Unser Schema arbeitet wie folgt:
1. Definiere einen Heimknoten für jeden Token beim Netzwerkstart und verteile Token in einer derartigen Weise, daß Token, welche denselben Heimknoten teilen bzw. gemeinsam nutzen, immer einen kontinuierlichen bzw. aneinander anschließenden Slotbereich definieren werden. Dies resultiert in einem großen, durchschnittlichen Tokenbereich in der in Fig. 12 gezeigten Tokenkarte bzw. -mappe.
2. Wenn zwei Token aufeinanderfolgender Slots mit demselben Slot- oder Segmentbereich in dem freien Pool existieren, führe diese in einen gemeinsamen Token zusammen (manchmal ist ein rekursiver Aufspaltungs- und Merge- bzw. Zusammenführvorgang erforderlich). Wenn ein Zusammenführen durchgeführt wird, verleihe einer Segmentzusammenführung immer eine höhere Priorität vor einer Slotnummernzusammenführung. Der Grund dafür ist, daß Token, welche sich über lediglich einige wenige Segmente erstrecken, weniger nützlich für andere Knoten sind als Token, welche sich über viele Segmente erstrecken.
3. Wenn ein Knoten eine Tokenanforderung von dem lokalen Benutzer oder einem entfernten Benutzer erhält, wähle einen Token aus dem Tokenpool unter Verwendung eines Best-Fit-Algorithmus in der Slotanzahl und Segmentnummerndimension (siehe Fig. 12). Der Wert eines Tokens wird als der Bereich eines Tokens in der Tokenkarte berechnet und wir versuchen, den Token mit dem geringsten Bereich auszuwählen, welcher die angeforderte Kapazität erfüllt.
4. Wenn ein Knoten Token von anderen Knoten anfordern muß, fragt er nicht für kleine Teile bzw. Stücke von mehreren Knoten, wenn es möglich ist, um größere Teile bzw. Stücke von weniger Knoten anzufragen. Die Statustabellen stellen diese Information zur Verfügung. Eine Übertragung von Token ist daher effizienter und es gibt weniger Aufbaubotschaften und weniger Fragmentation.
5. Freie Token werden zu Heimknoten zurückgesandt, wenn sie für eine bestimmte bzw. beträchtliche Zeit unbenutzt waren oder nach einem langen Transfer.
Dieses Schema retourniert Token zu "Heim"-Knoten als ein Weg, um die Wahrscheinlichkeit zu erhöhen, daß zwei aufeinanderfolgende Token in der freien Liste zusammengeführt werden können. Wenn die Heimknoten-"Schwerkraft" zu groß ist, wird dieses Schema in einem geringeren Teilen bzw. Nutzen von Ressourcen und einem unnotwendigen Signalisieren resultieren. Wenn sie zu schwach ist, wird die Fragmentation unverändert ein Problem bleiben.
Um den Defragmentationsmechanismus zu evaluieren, haben wir andere Sätze von Simulationen durchgeführt. Wir bezeichneten drei unterschiedliche Simulatoren (A, B, C). Der Simulator A wurde konfiguriert, um keinerlei Fragmentation zur Startzeit für die Simulation aufzuweisen und den oben beschriebenen Defragmentationsplan zu benutzen, B wurde mit einer maximalen Fragmentation des gesamten Ressourcenpools gestartet. Alle Token hatten nur einen Slot und keinerlei Token in den Heimknoten wurden vor dem Defragmentationsmechanismus verbunden. Schließlich wurde der Simulator C ohne die Verwendung des Defragmentationsmechanismus und mit dem Pool, welcher die maximale Fragmentation aufwies, gestartet. In allen Fällen wurde die Slotwiederverwendung eingeschaltet und die Last wurde mit 80% definiert.
Die Zutrittsverzögerung als eine Funktion der simulierten Zeit ist in Fig. 15 für ein Netzwerk von 10 km geoffenbart. Der Simulator C startete mit einer großen Zutrittsverzögerung und die Verzögerung stieg an, wenn die Signalkanäle überlastet waren und die Botschaftslinien bzw. -reihen anstiegen. Der Simulator B, welcher den Defragmentationsmechanismus verwendet, startet genauso schlecht wie C, wobei jedoch bereits nach 10 ms die durchschnittliche Zutrittsverzögerung unter 500 ms ist. Später, wenn eine Sekunde der simulierten Zeit verstrichen war, ist die B-Kurve in unmittelbarer Nähe mit A verbunden, d. h. sie konvergiert, wenn die Leistung des Simulators ohne jegliche Fragmentation gestartet wird. Die konvergierende Geschwindigkeit hängt von der Menge an freier Kapazität in dem Netzwerk und somit von der Last ab. Die Last während aller dieser Simulationen war 80%. Der Defragmentationsmechanismus verbessert klar die Zutrittsverzögerung und führt die Block-Token-Optimierung sinnvoll in der verteilten Realisierung durch.

6.4 DTM-Leistung

Wir sind insbesondere an zwei Arten von Leistungsmessungen in diesem Papier interessiert: Verwendung und Zutrittsverzögerung. Verwendung ist der Anteil der nominellen Netzwerkkapazität, welcher tatsächlich für einen Datentransfer verwendet wird, und ist eine Meßgröße der Effizienz des Netzwerks. Zutrittsverzögerung ist die Zeit von dem Einlangen einer Benutzeranforderung bis zum Senden der ersten Daten der Anforderung, welche wir als eine wesentliche Meßgröße erachten, wie gut der Computerkommunikationsverkehr unterstützt werden kann.
Es gibt zwei Hauptfaktoren, welche die Verwendung in DTM beeinflussen. Zuerst wird jedem Knoten eine Signalisierkapazität in der Form von Kontroll- bzw. Steuerslots zugeteilt, wobei dies bedeutet, daß weniger Slots für einen Datentransfer auf einem Bus mit vielen Knoten unter der Voraussetzung einer festgelegten Verbindungskapazität verfügbar sind. Zweitens bringt eine Tokenneuzuweisung einen Overhead mit sich, da, während ein Slottoken zwischen Knoten neu zugewiesen wird, der entsprechende Slot nicht für einen Datentransfer verwendet werden kann.
Die Zutrittsverzögerung hängt hauptsächlich von der Last an den Steuerslots ab und davon, wieviel Steuerbotschaften gesendet werden müssen, um einen Kanal aufzubauen. Die Zutrittsverzögerung ist typischerweise eine Summe von verschiedenen Verzögerungen (und typischen Werten): Knotenkontroller- Verarbeitungsverzögerung [5 us], Verzögerung beim Finden und Zuweisen von freien Token [100 us], Abwarten für das Passieren des ersten, verfügbaren Steuerslots [50 us] und schließlich Abwarten des Füllens des ersten, zugewiesenen Datenslots mit Userdaten [62, 5 us]. Zusätzlich werden Botschaften in Warteschlangen an dem Eingang zu Knotenkontrollern verzögert, welche auf eine Verarbeitung warten. In den in Sektion 5.2 präsentierten Simulationen beträgt die durchschnittliche Verzögerung bis zu einigen hundert Mikrosekunden.

7. Netzwerksimulationen.

In dem Simulationsmodell startet jeder Transfer mit der Ankunft eines neuen "Pakets" an Information. Der Knotenkontroller versucht, Ressourcen für den Transfer zuzuweisen, überträgt das Paket und gibt schließlich den Kanal frei. Dies ist eine Vereinfachung des Mechanismus in einem reellen System, wo ein Kanalaufbau, der Datentransfer und ein Kanalabbau unabhängige Vorgänge sind, welche durch den Benutzer initiiert bzw. eingeleitet werden. Beispielsweise kann ein Benutzer, welcher weiß, daß ein Transfer unmittelbar bevorsteht, die Kanalaufbauverzögerung durch ein vorhergehendes Anfordern eines Kanals "verbergen", so daß dieser bereits aufgebaut ist, wenn der Transfer startet. Zwischen einem Aufbau und einem Abbau ist die Kapazität des Kanals vollständig für den Benutzer reserviert. Die unmittelbarste Benutzung des Kanals ist für einen einzigen Transfer, wie beispielsweise einen Filetransfer oder eine Videoübertragung.
In Abhängigkeit von den Merkmalen der Anwendung ist es möglich, die Benutzung des Signals zu optimieren. Beispielsweise kann ein Kanal für eine Übertragung von Sequenzen von Botschaften höherer Ordnung, wie beispielsweise ATM-Zellen oder IP-Paketen, verwendet werden. Wenn es ein Multicast-Kanal ist, können Botschaften zu unterschiedlichen Destinationen auf diesem gemultiplext werden. Dies bedeutet, daß jede Botschaft jeden Empfänger an dem Multicast-Kanal erreichen wird und daß Empfänger fähig sein müssen, Botschaften zu filtern. Eine alternative Lösung ist, einen Kanal für jede Botschaft zu erzeugen und zu zerstören, jedoch die Token zwischen Botschaften zu reservieren, so daß die Token bereits für die nächste Botschaft in der Sequenz verfügbar sind. Wir haben diese Art eines Benutzerverhaltens nicht in die Simulationen aufgenommen, da sie Optimierungen für spezielle Anwendungen sind. Stattdessen konzentrieren wir uns darauf, wie das Netzwerk ohne Optimierungen auf Benutzerniveau arbeitet.
Der Sender kann mit dem Senden von Daten starten, sobald die Ressourcen zugewiesen sind, selbst bevor der Empfänger die Kanalaufbaubotschaft erhält. Dies wird ein schneller Kanalaufbau genannt. Der Empfänger wird schließlich mit einer Steuerbotschaft antworten, um den Kanal zu akzeptieren oder zu verwerfen.
Benutzeranforderungen weisen die folgenden Parameter auf:
* Paketgröße, welche die Menge von übertragenen Benutzerdaten zwischen dem Kanalaufbau und der Kanalfreigabe ist. Wir simulieren Paketgrößen von einigen Kilobytes bis zu einigen Megabytes.
* Angeforderte Kapazität für einen Kanal, welche die Anzahl von Slots ist, welche ein Knoten zuzuweisen versucht. Für alle dieses Simulationen in diesen Unterlagen ist die angeforderte Kapazität auf 40 Slots oder 20,48 Mbitls festgelegt.
* Minimale, akzeptierte Kapazität. Ein Knoten blockiert eine Anforderung bzw. Anfrage, wenn er nicht diese Anzahl von Slots zuweisen kann. Dies ist normalerweise auf 40 oder 20 Slots (100% oder 50% der angeforderten Kapazität) eingestellt.
* Quellenadresse.
* Destinationsadresse bzw. Bestimmungsadresse.
Die Quellen- und Destinationsadressen werden zufällig bzw. willkürlich (alle Knoten mit derselben Wahrscheinlichkeit) erzeugt und Benutzer-Zwischenankunftszeiten werden exponentiell verteilt. Die Simulationen untersuchen den Effekt des Overheads an Signalisierkapazität und Slotneuzuweisung bei der Verwendung, die Kanalaufbauverzögerung und -blockierung. Wir simulieren eine Topologie mit den folgenden Merkmalen:
* Ein Dualbus-Netzwerk mit 100 Knoten. Obwohl es theoretisch möglich ist, viel mehr Knoten an einem Bus zu verbinden, glauben wir, daß ein Management von Netzwerken mit mehr als 100 Knoten an einem Bus undurchführbar sein kann. Mit 100 Knoten ist das Kapazitätsteilen signifikant genug, um das Tokenmanagementprotokoll durchzuführen und zu testen.
* Die Kapazität von jedem Bus ist 6,4 Gbitls. Wir glauben, daß eine derartige Kapazität realistisch ist für das, was innerhalb von einem oder zwei Jahren realisierbar ist; 2,4 Gbit/s optische Links waren für einige Jahre verfügbar und 10 Gbitls Links wurden angekündigt, daß sie bald am Markt erscheinen sollen.
6,4 Gbitls entspricht einer 100 MHz-Slotrate, welche die Rate ist, bei welcher Slotbearbeitungs-MAC-Hardware arbeiten würde. 100 MHz ist mit gegenwärtiger CMOS-Technologie erreichbar.
* Die gesamte Signalisierkapazität ist dieselbe für alle Knoten, wobei jedoch die Slots zwischen den zwei Faserrichtungen proportional verteilt sind, in Abhängigkeit davon, wo die Knoten an dem Bus angeordnet bzw. positioniert sind. Je näher ein Knoten zu dem Slotgenerator ist, umso mehr Steuerkapazität ist erforderlich. Die Summe der Steuerkapazität an beiden Bussen wird jedoch für alle Knoten dieselbe sein. In dem Netzwerk mit zwei Tokenserver weisen die Server eine größere Steuerkapazität und eine höhere Prozessor- bzw. Bearbeitungskapazität als die anderen Knoten auf.
* Die Länge des Busses ist 10 km, wobei dies ein ausreichend großes Netzwerk ergibt, daß die Effekte einer Propagationsverzögerung nicht vernachlässigbar sind. Wir studieren weiters die Effekte einer Propagationsverzögerung in den Simulationen in Fig. 19 und Fig. 21, welche Buslängen von 1 km, 10 km, 100 km und 1.000 km verwenden.
* Zwei unterschiedliche Tokenmanagementschemata werden simuliert: ein asymmetrisches Schema, wo alle Token an einer Faser durch einen einzigen Tokenserver gemanagt werden, und ein symmetrisches Schema, wo jeder Knotenkontroller ein geringes Stück des gesamten Tokenpools managt.

8. Leistung

8.1 Ideales Protokoll

Wenn die Leistung des DTM-Dualbus-Netzwerks analysiert wird, muß der Punkt der maximalen, theoretischen Leistung adressiert bzw. angesprochen und mit der simulierten Leistung verglichen werden. Die maximale, theoretische Leistung wird auch in diesem Papier verwendet, um die unterschiedlichen Schemata und Implementationen zu vergleichen, welche wir evaluieren.
Der maximale Durchsatz eines Dualbussystems ohne Slotwiederverwendung kann als das Doppelte der Verbindungs- bzw. Linkkapazität definiert werden, unter der Voraussetzung, daß beide Fasern denselben Verkehr erhalten. In einem System mit einer Slotwiederverwendung hängt der Systemdurchsatz auch von der Quellen- Destinations-Verteilung ab. Um diesen Durchsatz für den Dualbus zu erhalten, verwendeten wir eine Monte-Carlo-Simulation, wo Quellen- und Destinationsadressen einheitlich bzw. gleichmäßig verteilt waren (siehe linker Graph in Fig. 16). In dem rechten Graph in Fig. 16 ist die Leistung eines DTM-Netzwerks inkludiert. Das DTM-Netzwerk verwendet einen zentralisierten Tokenmanager und Benutzeranforderungen, um 4 Megabyte Information jedesmal zu übertragen. In diesem System ist die Signalisierkapazität nicht ein Flaschenhals bzw. eine Beschränkung und es wird für die Verwendung gefunden, daß sie nahe dem idealen Fall ist. Realer Verkehr, welcher sich derart verhält, ist Datenverkehr großer Mengen und Audio/Video-Ströme. Die kleinen Unterschiede, welche gezeigt sind, sind Resultate von: erstens wird einige Kapazität in DTM für Steuerslots verwendet, welche die verfügbare Anzahl von durch Datentransfers zu verwendenden Slots senkt. Zweitens erzeugen Zufallsgeneratoren für die DTM-Simulationen nicht exakt dieselbe Menge an Verkehr in stromaufwärtigen und stromabwärtigen Richtungen und können in einer Blockade von einer der Richtungen resultieren, wenn Kapazität in der anderen verfügbar ist. Drittens können während des Kanalaufbaus Ressourcen momentan unbenutzt verriegelt bzw. blockiert sein, wodurch einige Kapazität verschwendet wird.

8.2 Zentraler Tokenmanager

In dem Fall eines zentralen Tokenmanagers brauchen die zwei handhabenden Knoten mehr Signalisierkapazität als andere Knoten (wir weisen achtmal so viele Steuerslots einem Serverknoten als anderen Knoten zu).
Resultate des ersten Satzes von Simulationen werden in Fig. 17 präsentiert. Benutzer fordern 20 Mbit/s Kanäle, Zwischenankunftszeiten sind exponentiell verteilt (erzeugt durch ein Poisson-Verfahren) und die Simulationen werden mit unterschiedlichen Paketgrößen durchgeführt. Wenn die gesamte Kapazität des Kanals nicht zugewiesen werden kann, wird die Anforderung verworfen und Token werden zu dem Tokenserver retourniert. Paketgrößen variieren von 4 Megabyte bis 2 Kilobyte, wobei wir an diesem Punkt eine Verschlechterung des Durchsatzes zu sehen beginnen.
Eine Durchsatzverschlechterung kann auftreten, wenn die Bearbeitungskapazität in Knoten oder die Steuerkanalkapazität zu gering ist. Die Serverknoten werden insbesondere überlastet. Das Resultat ist, daß Schlangen, welche Steuerbotschaften enthalten, sehr groß zu werden beginnen. Die Steuertoken repräsentieren ungenutzte Kapazität und es wird daher der Durchsatz verschlechtert bzw. herabgesetzt.
In den Simulationen mit 4 Kilobyte pro Kanal ist die Steuerkapazität der limitierende Faktor, und wenn mehr Steuerslots (Signalisierkapazität) hinzugefügt wird, können 4 Kilobyte und selbst kleinere Pakete effizienter unterstützt werden.
Der nächste Satz von. Kurven in Fig. 18 zeigt, wie der Slotwiederverwendungsmechanismus die Leistung des Systems verbessert. Der Durchsatz steigt nahezu um einen Faktor 2 an, bevor irgendeine signifikante Anzahl von Kanälen verworfen wird. Die einheitlichen Quellen- und Destinationsverteilungen von Kanälen begrenzen die Menge an erhöhter Kapazität, welche durch die Slotwiederverwendung gewonnen wird. Es wurde gezeigt, daß, wenn die Quelle und Destinationen gleichmäßig erzeugt werden, wie wir das tun, der Durchsatz auf einem dualen Bus verdoppelt werden kann. In den Simulationen kann auch ersehen werden, daß über eine angebotene Last von 2,5 wir tatsächlich einen Durchsatz von mehr als 2,0 erhalten können. Dieses Niveau des Durchsatzes kann jedoch nicht erreicht werden, ohne daß einige Kanäle verworfen werden. Die Kanäle mit der höchsten Wahrscheinlichkeit, verworfen bzw. zurückgewiesen zu werden, sind diejenigen, welche viele Slots oder Segmente verwenden. Daher "filtert" das System weniger anspruchsvolle Benutzeranforderungen und verwirft den Rest. Dies ist normalerweise nicht ein akzeptables Verhalten und wir untersuchen dieses daher nicht weiter.
Eine Durchsatzverschlechterung tritt bei einer angebotenen Last von 1 mit den 4 Kilobyte Transfers auf. Selbst wenn wir genug Ressourcen in dem Tokenserver haben, können wir die Kanäle nicht rasch genug aufbauen und abbauen, da der Steuerkanal überfüllt ist. Weiters sehen wir auch eine Durchsatzverschlechterung der 8 Kilobyte Simulationen bei einer angebotenen Last von 1,8 aus demselben Grund.
Es kann aus den Simulationen in Fig. 18 geschlossen werden, daß der Slotwiederverwendungsmechanismus den Systemdurchsatz mit nur geringen Änderungen an dem zentralisierten Tokenprotokoll nahezu verdoppelt, solange die Steuerungs- und Serverprozessorkapazität nicht ein Flaschenhals bzw. eine Engstelle ist. Aus den Kurven kann auch ersehen werden, daß die Zutrittsverzögerung tatsächlich abnimmt, wenn die Last von 0,1 bis 0,5 zunimmt. Dies ist ein Resultat davon, wieviele Slots einem Kanal zugewiesen werden, und steht nicht mit der Tokenanforderungsprozedur im Zusammenhang. Die Zeit, welche erforderlich ist, um Token von dem Server anzufordern, steigt strikt bzw. eng mit der Last an.
Wenn die DTM-Leistung in Fig. 18 mit den theoretischen Werten in Fig. 16 verglichen wird, sehen wir, daß selbst kurze Stöße bzw. Bursts (mit einer Dauer von einigen Millisekunden) wirksam unterstützt werden können.

8.2.1 Leistung des zentralen Tokenservers als eine Funktion der Buslänge

Wenn ein einzelner Tokenserver verwendet wird, erfordert jeder Kanalaufbau, daß ein Token von dem Server angefordert wird. Wenn die Länge des Busses erhöht wird, wird die Tokenanforderung eine längere Zeit erfordern und kann daher auch den Durchsatz begrenzen und die Zutrittsverzögerung erhöhen.
In Fig. 19 erhöhten wir die Länge des Busses um einen Faktor von 100 auf 1.000 km (Knoten-zu-Knoten-Verzögerung beträgt nun 50 us). Sowohl die Zutrittsverzögerung als auch der Durchsatz können nun durch die Umlaufzeit- bzw. Roundtriplatenz zu dem Tokenserver limitiert werden.
Die Zutrittsverzögerung hängt in diesem Fall von dem Abstand zu den Servern ab, wobei sie jedoch unabhängig von der Transfergröße ist. Der Durchsatz hängt stark von der durchschnittlichen Transfergröße ab, da die Aufbauphase gegenüber der Datentransferphase amortisiert ist.
Kanäle, welche große Mengen an Information, wie beispielsweise 256 Kilobyte, mit einer Dauer von einer Zehntelsekunde übertragen, werden unverändert effizient unterstützt, wenn die Buslänge 1.000 km ist.

8.2.2 Diskussion

Die Verwendung eines zentralisierten Tokenmanagers weist verschiedene Vorteile auf. Klienten können einfach sein, da sie nur Statusinformation im Zusammenhang mit ihren eigenen offenen Kanälen enthalten. Eine Slotwiederverwendung ist auch einfach und effizient, da der Slotserver alle der freien Token hat, um aus diesen auszuwählen, wenn er eine Benutzeranforderung zu erfüllen versucht. Der Server kann auch mit einer anderen Politik im Zusammenhang stehende Funktionen, wie eine Zutrittssteuerung und Fairness implementieren. Die Fragmentation des freien Tokenpools in dem Server ist normalerweise mäßig, wobei dies in sehr wenigen Verbindungsaufbaubotschaften pro Kanal selbst für Benutzeranforderungen hoher Kapazität resultiert.
Es gibt auch Nachteile. Ein Benutzer, welcher oftmals Kanäle aufbaut und abbaut, kann ein übermäßiges Signalisieren einführen, indem er Token nach der Verwendung immer retourniert, wobei er dann Token wiederum innerhalb einer kurzen Zeitperiode anfordert. Die Bearbeitungskapazität des Serverknotens kann überlastet werden, wenn sich viele Knoten an dem Bus befinden oder wenn die durchschnittliche Paketgröße sehr klein ist. Wenn die Medienlänge sehr groß im Vergleich zu dem Produkt aus Bitperiode, Bits pro Paket und Mediengeschwindigkeit ist, kann die Umlaufzeit bzw. Roundtripzeit zu dem Server auch die Leistung begrenzen. Schließlich enthält der Serverknoten Statusinformation, von welcher alle Knoten abhängig sind, um Kanäle zu erzeugen. Ein Serverknotenfehler kann daher alle Knoten beeinflussen.

8.3 Verteilte Tokensteuerleistung

In diesem Abschnitt simulieren und untersuchen wir die Eigenschaften eines vollständig verteilten Tokenmanagers.

8.3.1 Verteilter Tokenmanager bzw. distributed Tokenmanager

Wenn die Leistung des verteilten Tokenmanagers mit Slotwiederverwendung und Defragmentation evaluiert wird, verwendeten wir denselben Verkehr und die Parameter wie in Abschnitt 5.2, wobei wir jedoch eine Politik verwendeten, wo Anforderungen akzeptiert werden, wenn 50% der angeforderten Kapazität zugewiesen werden kann.
Die in Fig. 20 präsentierten Resultate stammen von den Simulationen mit einer Slotwiederverwendung, einem vollständig verteilten Tokenmanager, Statusbotschaften, welche beschreiben, wieviel Kapazität ein Token besitzt, und dem Defragmentationsschema. Alle Knoten weisen dieselbe Bearbeitungskapazität auf und die Prozeß- bzw. Bearbeitungslast ist viel geringer als die Last, welche die Server in Fig. 18 erhalten. Die Abhängigkeiten zwischen Knoten ist auch viel geringer, wobei dies in einem höheren Ausmaß an Zuverlässigkeit resultiert. Das System arbeitet besser als jedes andere System ohne Slotwiederverwendung, jedoch nicht so gut wie das oben beschriebene, zentralisierte System.
Im Vergleich zu dem zentralisierten Schema (siehe Fig. 18) ist das Blockieren höher und startet bei einer geringeren Belastung.
Ein nicht erwartetes Resultat war, daß die Leistung in der Realität absinkt, wenn die Paketgröße ansteigt. Nachdem wir noch einmal die Resultate überprüft haben, haben wir gefunden, daß eine große, mittlere Transfergröße in einer geringeren Mobilität für Token resultiert und daß die Statusinformation in der Realität ein noch schlechteres Erscheinen von freien Ressourcen in dem Netzwerk als für kurze Transfers ergibt. In diesem Fall kann eine Anforderung verworfen bzw. zurückgewiesen werden, wenn wir nicht glauben, daß wir jegliche Ressourcen finden werden. Dieser Mechanismus wurde eingeführt, um ein Verschwenden von Steuerkapazität zu vermeiden, wenn die Ressourcen erschöpft waren.
Der Grund dafür ist, daß die Statusbotschaften nur "globale" Token beschreiben, welche alle Segmente an dem Bus abdecken. Ein globales Token kann durch jeden Knoten verwendet werden und ist der einzige Typ von Token in einem DRM-System ohne Slotwiederverwendung. Bei Lasten von 1,0 oder höher wird eine große Anzahl von Token segmentiert und das Wiederverwendungsschema braucht diese bei neuen Anforderungen. Der Statusbotschaftsmechanismus, welchen wir verwenden, welcher für ein System ohne Wiederverwendung entwickelt wurde, ist daher beschränkt in seiner Fähigkeit, neuen Anforderungen zu helfen, freie Kapazität zu finden, und kann im schlechtesten Fall in einem höheren Ausmaß eines Blockierens resultieren.

8.3.2 Leistung des verteilten Tokenservers als eine Funktion der Buslänge

Der Durchsatz und die Verzögerungszeit des verteilten Tokenmanagers mit variierenden Buslängen von 1 km bis 1.000 km sind in Fig. 21 dargestellt. Ein 16 Kilobyte Paket wird zwischen einem Aufbau und einem Abbau des Kanals gesandt. Die Busse von 1 km und 100 km ergeben ungefähr denselben Durchsatz und Zutrittsverzögerung wie der 10 km Bus, da die Latenz, welche durch Verwendung eines 125 us Zyklus eingebracht wird, gegenüber der Zeit der Fluchtlatenz in dem System dominiert. Für den 1.000 km langen Bus sehen wir, daß für die Zutrittsverzögerung gefunden wird, daß sie kürzer ist als in dem 1.000 km System, welches einen zentralisierten Tokenserver verwendet (siehe Fig. 19). Bei niedriger Belastung werden Token als sehr nahe gefunden und die Zutrittsverzögerung ist ungefähr dieselbe für alle Systeme unabhängig von der Buslänge. Selbst bei sehr hoher Belastung ist die Zutrittsverzögerung etwa 1 ms kürzer als in dem zentralisierten System in Fig. 19.

8.3.3 Stoßartige und Client-Server-Verkehrsbedingungen

Das System eines zentralisierten Tokenmanagers wird dieselbe Leistung nahezu unabhängig von dem Verkehr aufweisen, solange die Bearbeitung und Signalisierung ausreichend sind. Um das verteilte System zu evaluieren, entschieden wir uns, zwei andere Verkehrsgeneratoren zu verwenden. Zuerst verwenden wir einen Generator, welcher Benutzeranforderungen simuliert, welche stoßweise einlangen: wenn eine Anforderung einlangt, wird eine neue Anforderung erzeugt, daß sie mit einer 90%-igen Wahrscheinlichkeit nach 200 us einlangt. Das Resultat ist, daß Bursts bzw. Stöße von Anforderungen an Knoten einlangen und einen hohen, zeitweiligen Verbleib an Quellenadressen erzwingen. Zweitens erhöhen wir, um einen Verkehr ähnlicher zu einem Client-Server-Verhalten zu erzeugen, die Menge an Verkehr, welche an fünf Serverknoten einlangt, auf 0, 25, 50, 75 und 99. Selbst die Wahrscheinlichkeit für eine Serverdestination ist auch höher.
In Fig. 22 präsentieren wir die Leistung für den Durchsatz und die Zutrittsverzögerung des Systems des verteilten Tokenservers.

8.3.4 Diskussion

Es ist klar, daß die verteilte Implementation verschiedene Vorteile im Vergleich zu dem zentralisierten Tokenserver aufweist: die Knoten können die Bearbeitungslast verteilen, es besteht ein geringeres Erfordernis für Tokenserver hoher Leistung, die Redundanz kann höher sein und die Zutrittsverzögerung kann für Anforderungen geringer Kapazität kürzer sein. Sie ist auch anpaßbar an längere Busse. Der Nachteil ist ein höheres Blockieren. Es ist auch klar, daß der Mechanismus der Statusbotschaft und Statustabellen geändert werden muß, um ein unnötiges Blockieren zu vermeiden, wenn eine Slotwiederverwendung zugelassen wird.

9. Zukünftige Arbeit und Schlußfolgerungen

Wir haben gezeigt, daß das DTM Fast Circuit Switching Protocol gut in einer Umgebung eines Dualbus Shared Medium arbeitet. Zwei Slot-(Token- )Managementschemata werden analysiert. Das zentralisierte Schema arbeitet am nächsten zu dem idealen Protokoll und ist relativ einfach.
Das verteilte Schema ist empfindlicher gegenüber dem Benutzerverhalten, greift auf Statusinformation zurück, welche häufig übertragen wird, und erfordert ein Defragmentationsschema. Der Hauptvorteil des verteilten Schemas ist, daß es wirksam die Zutrittsverzögerung von der Roundtripzeit an dem Bus entkoppelt.
Ein Resultat ist, daß das Statusbotschaftsschema nicht gut arbeitet bei einer Slotwiederverwendung und zukünftige Arbeit wird sein, es neu zu konstruieren. Weitere Arbeit ist, ein Schema zu evaluieren, welches den verteilten und den zentralisierten Tokenmanager unter Verwendung eines kleinen Satzes von Tokenserverknoten kombiniert.
Die Schlußfolgerungen sind, daß ein Overhead für den Kanalaufbau sehr gering sein kann, wobei dies in einer hohen Verwendung bzw. Benutzbarkeit selbst für kleine Transfers (von einigen Kilobyte) resultiert. Für die Zutrittsverzögerung wird gefunden, daß sie einige hundert Mikrosekunden selbst bei hoher Belastung ist. Das Slotwiederverwendungsschema kann die Durchsatzleistung um einen Faktor von 2 erhöhen und kann ohne Einführen von zusätzlicher Hardware in den Knoten implementiert werden.

10. Ergänzung

Das Netzwerk ist nicht auf einen Dualbus limitiert, sondern kann mit allen Typen von Strukturen, beispielsweise einer Ringstruktur, mit einer beliebigen Anzahl von Knoten realisiert werden. Das Übertragungsmedium kann anstelle einer optischen Faser ein Koaxialkabel oder ein anderes Übertragungsmedium mit einer hohen Bandbreite sein. In der Beschreibung des Übertragungsmediums wird dieses als eine optische Faser bezeichnet. Die Bandbreite des DTM-Dualbusses ist in der bevorzugten Ausführungsform unterteilt in Zyklen von 125 us, welche wiederum in Zeitslots von 64 Bit unterteilt sind. Die vorliegende Erfindung ist nicht auf DTM-Netzwerke mit diesen Werten beschränkt, sondern kann in Netzwerken mit Zyklen und Zeitslots mit willkürlicher Größe verwendet werden.
Die Erhöhung der Leistung bei einer Zeitslot-Wiederverwendung ist klar bei einem Dualbus, wo die Quellen- und Destinationspaare gleichmäßig bzw. einheitlich verteilt sind, wurde für den Durchsatz gezeigt, daß er um einen Faktor 2 erhöht wird. Die Erhöhung der Leistung kann bei anderen Typen von Netzwerken noch höher sein; d. h. in einer dualen Ringstruktur, wo die Quellen- und Destinationspaare einheitlich bzw. gleichmäßig verteilt sind, kann der Durchsatz um einen Faktor 4 erhöht werden.
Eine Konsequenz des DTM-Zeitslot-Neuzuweisungsmechanismus ist es, daß es längere Zeit erfordert, Kanäle aufzubauen, welche eine größere Bandbreite benötigen. Dieser "Handel" kann gerechtfertigt sein: die Art von Verkehr, welcher eine geringere, mittlere Zutrittsverzögerung erfordert, ist normalerweise weniger empfindlich auf die für die Übertragung zugewiesene Bandbreite und ein derartiger Verkehr kann daher akzeptiert werden, ohne viel das Neuzuweisungsprotokoll zu beanspruchen. Für Übertragungen, welche eine größere Bandbreite erfordern, wird die Zutrittsverzögerung höher sein und das Neuzuweisungsprotokoll wird nahezu immer verwendet. Diese Breitbandtransfers werden jedoch möglicherweise weniger empfindlich auf Zutrittsverzögerungen sein.
Die oben beschriebenen Simulationen haben gezeigt, daß das Durchschalt-Protokoll von DTM gut in einer Umgebung eines Dualbus-unterteilten Mediums arbeitet. Zwei Zeitslot-Managementschemata werden analysiert und beide arbeiten gut und können die Zeitslot-Wiederverwendung nutzen. Das zentralisierte Schema agiert am nächsten zu dem idealen Protokoll und ist zur selben Zeit leichter zu implementieren. Das verteilte System ist empfindlicher auf die Benutzerleistung und muß daher auf Statusinformation zurückgreifen, welche häufig gesandt wird, und auf den Defragmentationsmechanismus, um die Anzahl von Steuerbotschaften zu verringern, welche für einen Kanalaufbau und eine Zeitslot-Neuzuweisung erforderlich sind. Unter Verwendung des verteilten Modells mit dem Defragmentationsmechanismus an langen Bussen kann eine bessere Leistung erhalten werden, als wenn das zentralisierte Modell verwendet wird. Ein Betriebsmittel- bzw. Ressourcenmanagementsystem, welches das zentralisierte und das verteilte Modell kombiniert, ist unter Verwendung eines kleineren Satzes von Tokenserverknoten auch möglich.
Darüber hinaus kann der Overhead zum Verbindungsaufbau sehr gering sein, wobei dies in einem höheren Grad der Verwendung selbst für kleine Übertragungen (einige wenige Kilobyte) resultiert. Die Zutrittsverzögerung beträgt einige hundert Mikrosekunden bei hohen Belastungen. Das Verfahren der Zeitslot- Wiederverwendung kann die Leistung um einen Faktor 2 (an einem dualen Bus) erhöhen, ohne zusätzliche Hardware zu den Knoten hinzuzufügen. Wenn das Verfahren der Zeitslot-Wiederverwendung verwendet wird, ist es noch wichtiger, das Defragmentationsverfahren zu verwenden, da eine Fragmentation sowohl im Zeitslot- als auch Segmentweg durchgeführt werden kann.

11. Weitere detaillierte Beschreibung und Kommentare zu der obigen Beschreibung

In der obigen Beschreibung wird insbesondere ein zentralisiertes System beschrieben, welches dadurch gekennzeichnet ist, daß nur ein Heimknoten für alle Token existiert und daß freie (unbenutzte) Token immer direkt zu dem Heimknoten retourniert werden.
In dem vollständig verteilten System sind alle Knoten Heimknoten (Serverknoten) und Token werden gleichmäßig unter allen diesen Heimknoten verteilt.
Mit dem Defragmentationsverfahren können Token selbst zurück zu ihren Heimknoten nach dem Verstreichen einer beträchtlichen bzw. bestimmten Zeit (beispielsweise, wenn sie frei (unbenutzt) für eine gewisse Zeit waren, sogenannte "Leer-Zeit " oder wenn sie nicht in ihrem Heimknoten für eine gewisse Zeit waren, sogenannte "letzte Heimknoten-Zeit"). Man verwendet die Arbeitstendenz bzw. -neigung - eine geringe Tendenz entspricht einer langen, signifikanten Zeit und eine hohe Tendenz entspricht einer kurzen, signifikanten Zeit. Das oben erwähnte, zentralisierte System wird eine unendlich hohe Tendenz (signifikante Zeit = 0) und das verteilte System ohne Defragmentationsmechanismus wird eine Tendenz = 0 (signifikante Zeit = ∞) aufweisen.
Es wird darauf hingewiesen, daß das Ressourcenmanagementschema auf alles zwischen diesen zwei Spezialfällen anwendbar ist. Die Anzahl von Heimknoten kann von 1 zu der Gesamtanzahl von Knoten variieren. Die Tendenz kann unabhängig von 0 bis unendlich variieren. Beim Verbinden von benachbarten Block-Token sollte das Verbinden in Segmentrichtung Priorität gegenüber einem Verbinden in der Zeitslot-Richtung aufweisen.
Wir geben einige Beispiele im Zusammenhang mit den beigeschlossenen Zeichnungen zur Klarstellung.
In Fig. 23 ist ein Tokengraph mit zwei aufeinanderfolgenden Zeitslot-Block-Token A und B geoffenbart. Normalerweise wird kein Teilen/Verbindung durchgeführt, da die Segmente sonst kürzer wären.
In Fig. 24 werden zwei Segmenffolge-Block-Token C und D geoffenbart. Normalerweise wird ein Teil der zwei Block-Token C und D entsprechend der unterbrochenen Linie durchgeführt. Danach wird ein Verbinden der zwei gebildeten Block-Token C' und D' zu einem Token C'D' mit einem doppelt so fangen Segment durchgeführt. Dies resultiert insgesamt in drei neuen Block-Token C", D" und C'D'.
In Fig. 25 werden drei Block-Token E, F, G diskutiert. Vorzugsweise werden F und G zu FG verbunden bzw. vereinheitlicht, um die Segmentgröße zu erhöhen.
In Fig. 26 werden zwei Block-Token H und I geoffenbart. Die angeforderte Kapazität entspricht der Hälfte von H und der Gesamtheit von I und sollen von Knoten A, NA zu Knoten B, NB gesandt werden. H wird für den Transport ausgewählt, welches entsprechend der unterbrochenen Linie geteilt wird.
In Fig. 27 ist ein Token I geoffenbart. Die angeforderte Kapazität entspricht der Hälfte von I und sollte von Knoten A, NA zu Knoten B, NB gesandt werden. Ein Teil von I wird für den Transport gewählt, welcher Teil in der oberen Seite oder wie in Fig. 27 in der unteren Seite von I liegt. Der verbleibende Teil muß dann geteilt werden (das Block-Token ist normalerweise rechteckig). Vorzugsweise wird dies entsprechend der unterbrochenen Linie durchgeführt, um ein möglichst großes Segment zu bewahren.
Selbstverständlich muß dies nicht auf diese Weise durchgeführt werden. In einigen Anwendungen kann man überlegen, in der Zeitslot-Richtung vor einem Vereinigen in der Segmentrichtung zu vereinigen.
Normalerweise enthält die Statustabelle nur Information über Zeitslots, welche über alle Segmente frei sind. Man kann auch überlegen, daß selbst Information über ein Segment in diesen Statustabellen gefunden werden kann. Es wird dies jedoch viel mehr Information sein, welche zu den üblichen Knoten zu verteilen ist.
Ein anderer Mechanismus, welcher vorzugsweise implementiert werden kann, wird unten in Verbindung mit Fig. 28 beschrieben. Wenn Knoten O, NO Zutritt zu der Kapazität (b - a) und über das gesamte Segment aufweist, jedoch die Kapazität (b - a) nur zu Knoten N, NN entsenden soll, besteht keine Verwendung der Segmente NN und darüber hinaus. Diese können dann zu NN für zukünftige Anforderungen gesandt werden. Derselbe Weg, wenn Knoten N, NN Zutritt zu der Kapazität des Zeitslots (d - c) aufweist und dann diese Kapazität zu Knoten M, NM senden soll, wird dieser selbst die freien Segmente NM und darüber hinaus zu dem Knoten M, NM für zukünftige Anforderungen senden. Der Tokenblock (NO - NN) · (d - c) wird nach unten zu dem Knoten O, NO für gegebenenfalls zukünftige Anforderungen gesandt werden. In diesem Zusammenhang ist eine zusätzliche Signalisierung erforderlich, wodurch dieser Tokenblock (NO - NN) · (d - c) mit einer gegebenenfalls geringeren Priorität gesendet werden kann.

Claims

1. Verfahren zur zentralisierten Verwaltung der Kapazität in einem Wählbetrieb- bzw. Durchschalt-Netzwerk bzw. leitungsvermitteltes Netz mit einer Bus- oder Ringstruktur, welches Netzwerk eine Bandbreite verwendet, welche in Zyklen unterteilt wird, welche wiederum in Kontroll- bzw. Steuerzeitkanäle bzw. -slots für eine Signalisierung bzw. Signalübertragung und Datenzeitkanäle bzw. -slots für eine Übertragung von Daten unterteilt werden, und worin jedem Datenzeitslot ein Token bzw. codiertes Befehlswort zugeordnet wird,

dadurch gekennzeichnet,

- daß einem ersten Knoten, welcher Serverknoten genannt wird, Token entsprechend allen Datenzeitslots zugeordnet werden, welche in einer Richtung in einem Bus oder Ring strömen,

- daß ein zweiter Knoten Token entsprechend einer gewissen Kapazität von dem Serverknoten anfordert,

- daß der Serverknoten Reservierungen für Token durchführt und diese entsprechend der angeforderten Kapazität zu dem anderen Knoten in dem Fall, daß der Serverknoten die angeforderte Kapazität unbenutzt aufweist, übermittelt und

- daß die übertragenen Token zu dem Serverknoten rückübertragen und freigegeben werden, wenn entsprechende Datenzeitslots nicht für ein Übertragen von Daten des anderen Knotens während einer beträchtlichen bzw. vorbestimmten Zeitdauer verwendet wurden.

2. Verfahren nach Anspruch 1, dadurch gekennzeichnet, daß das Verfahren in einem Netzwerk des DTM-Typs (Dynamic Synchronous Transfer Mode) implementiert wird.

3. Verfahren nach Anspruch 1 oder 2, dadurch gekennzeichnet, daß übertragene Token zu dem Serverknoten rückübermittelt und freigegeben werden, wenn entsprechende Datenzeitslots nicht länger für ein Übertragen von Daten verwendet werden.

4. Verfahren nach einem der Ansprüche 1 bis 3, dadurch gekennzeichnet, daß als der Serverknoten der Knoten, welcher ein Drittel der Knoten stromaufwärts angeordnet und zwei Drittel der Knoten stromabwärts angeordnet hat, ausgewählt wird.

5. Verfahren zur verteilten Verwaltung der Kapazität in einem Wählbetrieb- bzw. Durchschalt-Netzwerk bzw. leitungsvermitteltes Netz mit einer Bus- oder Ringstruktur, worin die Bandbreite in Zyklen unterteilt wird, welche wiederum in Kontroll- bzw. Steuerzeitkanäle bzw. -slots für eine Signalübertragung und Datenzeitkanäle bzw. - slots für eine Übertragung von Daten unterteilt werden, und worin jedem Datenzeitslot ein Token bzw. codiertes Befehlswort (Schreibzugang) zugeordnet wird, dadurch gekennzeichnet,

- daß wenigstens zwei Knoten, welche Serverknoten genannt werden, definiert werden, zwischen welchen Token entsprechend allen Datenzeitslots verteilt werden, welche in einer Richtung in einem Bus oder einem Ring strömen,

- daß ein Knoten Token entsprechend einer gewissen Kapazität von wenigstens einem der Serverknoten anfordert,

- daß dieser Serverknoten Reservierungen für Token durchführt und diese entsprechend der angeforderten Kapazität an den anfordernden Knoten in dem Fall überträgt, daß der Serverknoten die angeforderte Kapazität unbenutzt aufweist, und

- daß übertragene Token zu dem entsprechenden Serverknoten rückübermittelt und freigegeben werden, wenn entsprechende Datenzeitslots nicht für eine Datenübertragung während einer beträchtlichen bzw. vorbestimmten Zeitdauer verwendet wurden.

6. Verfahren nach Anspruch 5, dadurch gekennzeichnet, daß das Verfahren in einem Netzwerk des DTM-Typs (Dynamic Synchronous Transfer Mode) implementiert wird.

7. Verfahren nach Anspruch 5 oder 6, dadurch gekennzeichnet, daß mehrere Serverknoten gefragt werden, Reservierungen für Token durchführen und diese, welche gemeinsam der vollständig angefragten Kapazität entsprechen, zu dem anfragenden bzw. anfordernden Knoten in dem Fall übertragen, daß die Serverknoten gemeinsam die angeforderte Kapazität unbenutzt aufweisen.

8. Verfahren nach einem der Ansprüche 5 bis 7, dadurch gekennzeichnet, daß empfangene Token für ein Aufbauen bzw. Einrichten von Kanälen durch Senden einer Kanalaufbau bzw. -einrichtbotschaft an den Knoten oder die Knoten verwendet werden, welche als Empfänger von Daten in dem Fall bezeichnet werden, daß ein Knoten Token entsprechend der angeforderten Kapazität empfangen hat.

9. Verfahren nach einem der Ansprüche 5 bis 7, dadurch gekennzeichnet, daß einer oder mehrere Serverknoten Reservierungen für Token durchführen und diese entsprechend der gesamten der nicht verwendeten Kapazität zu dem anfordernden Knoten in dem Fall übertragen, daß die Serverknoten gemeinsam nicht die angeforderte Kapazität unbenutzt aufweisen.

10. Verfahren nach einem der Ansprüche 5 bis 7, dadurch gekennzeichnet, daß einer oder mehrere Serverknoten nicht Token an den anfordernden Knoten in dem Fall übertragen, daß die Serverknoten gemeinsam nicht die angeforderte Kapazität unbenutzt aufweisen.

11. Verfahren nach Anspruch 9 oder 10, dadurch gekennzeichnet, daß weitere Token durch einen Knoten in dem Fall angefordert werden, daß möglicherweise erhaltene Token nicht der angeforderten Kapazität entsprechen.

12. Verfahren nach Anspruch 9 oder 10, dadurch gekennzeichnet, daß in einem Knoten empfangene Token in dem Fall freigegeben werden, daß diese Token nicht der angeforderten Kapazität entsprechen.

13. Verfahren nach Anspruch 9 oder 10, dadurch gekennzeichnet, daß empfangene Token für einen Aufbau bzw. Einrichten von Kanälen durch Senden einer Kanalaufbau- bzw. -einrichtbotschaft an den Knoten oder die Knoten verwendet werden, welche als Empfänger von Daten in dem Fall bezeichnet werden, daß ein Knoten nicht Token entsprechend der angeforderten Kapazität erhalten hat.

14. Verfahren nach einem der Ansprüche 5 bis 13, dadurch gekennzeichnet, daß jeder Serverknoten regelmäßig Information betreffend seine Frei- bzw. Leerkapazität an den Rest der Knoten sendet und jeder Knoten in einer Statustabelle Information, welche von den anderen Knoten erhalten wird, speichert.

15. Verfahren nach einem der Ansprüche 5 bis 14, dadurch gekennzeichnet, daß ein Knoten Token von dem Serverknoten anfordert, welcher im Moment die meiste unbenützte Kapazität aufweist.

16. Verfahren nach einem der Ansprüche 5 bis 14, dadurch gekennzeichnet, daß ein Knoten Token von dem Serverknoten anfordert, welcher am nächsten liegt und im Moment die angeforderte Kapazität unbenutzt aufweist.

17. Verfahren nach Anspruch 15 oder 16, dadurch gekennzeichnet, daß der Serverknoten, von welchem Kapazität angefordert wird, durch eine Bezugnahme auf die Statustabelle gefunden wird.

18. Verfahren nach einem der Ansprüche 5 bis 17, dadurch gekennzeichnet, daß alle Knoten in einem Bus oder einem Ring als Serverknoten definiert werden und diesen wenigstens ein Token zugeordnet wird.

19. Verfahren nach Anspruch 18, dadurch gekennzeichnet, daß allen Knoten in einem Bus oder einem Ring dieselbe Anzahl von Token zugeordnet wird.

20. Verfahren nach einem der Ansprüche 5 bis 19, dadurch gekennzeichnet, daß übertragene Token zu dem entsprechenden Serverknoten rückübermittelt werden und freigegeben werden, wenn entsprechende Datenzeitslots nicht länger für eine Datenübertragung verwendet werden.

21. Verfahren nach einem der Ansprüche 5 bis 19, dadurch gekennzeichnet, daß übertragene Token freigegeben werden, wenn entsprechende Datenzeitslots nicht länger für eine Datenübertragung verwendet werden.

22. Verfahren nach einem der Ansprüche 1 bis 21, dadurch gekennzeichnet, daß aufeinander folgende Token in einem Knoten durch ein Token, welches Block-Token genannt wird, repräsentiert werden, welches als eine Zahl auf dem ersten Zeitslot in einer Reihe und die Gesamtanzahl der Zeitslots in der Reihe angezeigt bzw. angegeben wird.

23. Verfahren nach einem der Ansprüche 1 bis 22, dadurch gekennzeichnet, daß ein Token in wenigstens zwei Token entsprechend demselben Zeitslot, jedoch unterschiedlichen Segmenten unterteilt wird, wo sich ein Segment auf ein Teil eines Übertragungsmediums bezieht, welches wenigstens zwei Knoten verbindet.

24. Verfahren nach einem der Ansprüche 1 bis 23, dadurch gekennzeichnet, daß der Serverknoten in dem Fall, daß er verschiedene Zeitslot- oder Segmentfolge-Gruppen von Token für eine Auswahl unter diesen aufweist, Reservierungen für Token durchführt und diese übermittelt, welche von der kleinsten Gruppe von Zeitslot- oder Segmentfolge-Token stammen, welche eine Kapazitätsanforderung erfüllen, und worin die kleinste Gruppe als die Gruppe definiert ist, deren Produkt von Zeitslots und Segmenten mit vorbestimmter Gewichtung am geringsten ist.

25. Verfahren nach einem der Ansprüche 1 bis 24, dadurch gekennzeichnet, daß Gruppen von Token, welche wenigstens teilweise Segmentabfolgen sind, neu gruppiert werden, um die Anzahl von aufeinander folgenden Segmenten für jede Gruppe von Token auf Kosten der Anzahl von aufeinander folgenden Zeitslots zu maximieren.

26. Knotenkontroll- bzw. -steuereinheit in einen Knoten in einem Wählbetrieb- bzw. Durchschalt-Netzwerk bzw. leitungsvermitteltes Netz mit einer Bus- oder Ringstruktur, welches Netzwerk eine Bandbreite verwendet, welche in Zyklen unterteilt ist, welche wiederum in Kontroll- bzw. Steuerzeitkanäle bzw. -slots für eine Signalisierung bzw. Signalübertragung und Datenzeitkanäle bzw. -slots für eine Übertragung von Daten unterteilt sind, und worin jedem Datenzeitkanal bzw. -slot ein Token bzw. codiertes Befehlswort zugeordnet ist, dadurch gekennzeichnet,

- daß der Knotensteuereinheit Token entsprechend einer vorbestimmten Anzahl von Datenzeitslots zugeordnet sind, welche in einer Richtung in einem Bus oder einem Ring strömen,

- daß die Knotensteuereinheit angeordnet bzw. ausgebildet ist, um Reservierungen für Token durchzuführen und diese an eine zweite Knotensteuereinheit in einem zweiten Knoten in dem Fall zu übertragen, daß sie eine Anforderung für Token von der zweiten Knotensteuereinheit erhält und daß sie die angeforderte Kapazität unbenutzt aufweist, und

- daß die zweite Knotensteuereinheit angeordnet bzw. ausgebildet ist, um die übertragenen Token zu der Knotensteuereinheit zurückzuübertragen und diese freizugeben, wenn entsprechende Datenzeitslots nicht für ein Übertragen von Daten der zweiten Knotensteuereinheit während einer beträchtlichen bzw. vorbestimmten Zeit verwendet wurden.

27. Knotensteuereinheit nach Anspruch 26, dadurch gekennzeichnet, daß das Netzwerk vom DTM-Typ (Dynamic Synchronous Transfer Mode) ist.

28. Knoten, welcher auch Serverknoten genannt wird, in einem Wählbetrieb- bzw. Durchschalt-Netzwerk bzw. leitungsvermitteltes Netz mit einer Bus- oder Ringstruktur, welches Netzwerk eine Bandbreite verwendet, welche in Zyklen unterteilt ist, welche wiederum in Kontroll- bzw. Steuerzeitkanäle bzw. -slots für eine Signalübertragung und Datenzeitkanäle bzw. -slots für eine Übertragung von Daten unterteilt sind, und worin jedem Datenzeitslot ein Token bzw. codiertes Befehlswort zugeordnet ist, gekennzeichnet durch eine Knotensteuereinheit, welcher Token entsprechend einer vorbestimmten Anzahl von Datenzeitslots zugeordnet sind, welche in einer Richtung in einem Bus oder Ring strömen, und welche angeordnet bzw. ausgebildet ist, um Reservierungen für Token durchzuführen und diese an eine zweite Knotensteuereinheit in einem zweiten Knoten in dem Fall zu übertragen, daß sie eine Anforderung für Token von der zweiten Knotensteuereinheit erhält und daß sie die angeforderte Kapazität unbenutzt aufweist.

29. Knoten nach Anspruch 28, dadurch gekennzeichnet, daß das Netzwerk vom DTM-Typ (Dynamic Synchronous Transfer Mode) ist.

30. Knoten nach Anspruch 28 oder 29, dadurch gekennzeichnet, daß dem Knoten Token entsprechend allen Datenzeitslots zugeordnet sind, welche in einer Richtung in einem Bus oder einem Ring strömen.

31. Knoten nach Anspruch 30, dadurch gekennzeichnet, daß der Knoten ein Drittel der Knoten der Bus- oder Ringstruktur stromaufwärts und zwei Drittel der Knoten der Bus- oder Ringstruktur stromabwärts aufweist.

32. Wählbetrieb- bzw. Durchschalt-Netzwerk bzw. leitungsvermitteltes Netz einer Bus- oder Ringstruktur, welches Netzwerk eine Bandbreite verwendet, welche in Zyklen unterteilt ist, welche wiederum in Kontroll- bzw. Steuerzeitkanäle bzw. -slots für eine Signalisierung bzw. Signalübertragung und Datenzeitkanäle bzw. -slots für eine Übertragung von Daten unterteilt sind, und worin jedem Datenzeitslot ein Token bzw. codiertes Befehlswort zugeordnet ist, gekennzeichnet durch einen Knoten, welcher auch Serverknoten genannt wird, welchem Token entsprechend einer vorbestimmten Anzahl von Datenzeitslots zugeordnet sind, welche in einer Richtung in einem Bus oder einem Ring strömen, und welcher angeordnet bzw. ausgebildet ist, um Reservierungen für Token durchzuführen und diese an einen zweiten Knoten in dem Fall zu übertragen, daß er eine Anforderung für Token von dem zweiten Knoten erhält und die angeforderte Kapazität unbenutzt aufweist.

33. Wählbetrieb- bzw. Durchschalt-Netzwerk bzw. leitungsvermitteltes Netz einer Bus- oder Ringstruktur, welches Netzwerk eine Bandbreite verwendet, welche in Zyklen unterteilt ist, welche wiederum in Kontroll- bzw. Steuerzeitkanäle bzw. -slots für eine Signalübertragung und Datenzeitkanäle bzw. -slots für eine Übertragung von Daten unterteilt sind, und worin jedem Datenzeitslot ein Token bzw. codiertes Befehlswort zugeordnet ist, dadurch gekennzeichnet, daß wenigstens zwei Knoten, welche Serverknoten genannt werden, definiert sind, zwischen welchen Token entsprechend allen Zeitdatenslots, welche in einer Richtung in einem Bus oder Ring strömen, verteilt sind, und daß die Serverknoten angeordnet bzw. ausgebildet sind, um Reservierungen für Token durchzuführen und diese an einen dritten Knoten in dem Fall zu übertragen, daß die Serverknoten eine Anforderung für Token von dem dritten Knoten erhalten und daß sie die angeforderte Kapazität unbenutzt aufweisen.

34. Durchschalt-Netzwerk nach Anspruch 32 oder 33, dadurch gekennzeichnet, daß das Netzwerk ein Netzwerk des DTM-Typs (Dynamic Synchronous Transfer Mode) ist.

35. Durchschalt-Netzwerk nach einem der Ansprüche 32 bis 34, dadurch gekennzeichnet, daß ein Knoten angeordnet ist, um erhaltene Token für einen Aufbau bzw. Einrichtung von Kanälen durch ein Senden einer Kanalaufbau- bzw. - einrichtbotschaft an den Knoten oder die Knoten, welche als Empfänger von Daten gedacht sind, in dem Fall zu verwenden, daß der Knoten Token entsprechend der angeforderten Kapazität erhalten hat.

36. Durchschalt-Netzwerk nach einem der Ansprüche 33 bis 35, dadurch gekennzeichnet, daß einer oder mehrere Serverknoten angeordnet sind, um Reservierungen für Token durchzuführen und diese entsprechend der gesamten unbenutzten Kapazität an den anfordernden Knoten in dem Fall zu übertragen, daß die Serverknoten gemeinsam nicht die angeforderte Kapazität unbenutzt aufweisen.

37. Durchschalt-Netzwerk nach einem der Ansprüche 33 bis 35, dadurch gekennzeichnet, daß einer oder mehrere Serverknoten angeordnet sind, um nicht jegliche Token zu dem anfordernden Knoten in dem Fall zu übertragen, daß die Serverknoten gemeinsam nicht die angeforderte Kapazität unbenutzt aufweisen.

38. Durchschalt-Netzwerk nach einem der Ansprüche 33 bis 37, dadurch gekennzeichnet, daß ein Knoten angeordnet ist, um eine Statustabelle, eine regelmäßig aktualisierte Liste der ungenutzten Kapazität von allen Serverknoten, für eine Entscheidung zu verwenden, von welchem Serverknoten Token anzufordern sind.