DE60218631T2

DE60218631T2 - Status - basierende Verfahrensverwaltungsmethode für ein Kommunikationstransportnetz

Info

Publication number: DE60218631T2
Application number: DE60218631T
Authority: DE
Inventors: Canali Massimo; Molgora Paolo
Original assignee: Alcatel Lucent SAS
Current assignee: Alcatel Lucent SAS
Priority date: 2002-04-25
Filing date: 2002-04-25
Publication date: 2007-11-08
Anticipated expiration: 2022-04-26
Also published as: US20030202518A1; EP1357698B1; EP1357698A1; CN1453961A; ATE356487T1; CN1249958C; DE60218631D1

Description

Die vorliegende Erfindung betrifft ein status-basierendes Richtlinienverwaltungsverfahren (policy management method) für ein Kommunikationstransportnetz nach dem Oberbegriff des Anspruchs 1 und ein Netzelement und einen Richtlinien-Server nach dem Oberbegriff der Ansprüche 5 bzw. 9.
Herkömmliche Kommunikationstransportnetze sorgen für starre Kommunikationsdienste. Die sogenannten "intelligenten Transportnetze" werden für flexible Kommunikationsdienste sorgen.
Außerdem werden bei diesen neuen Kommunikationstransportnetzen die Nutzer in der Lage sein, ihre Kommunikationstransportdienste direkt bereitzustellen, während bei den herkömmlichen Netzen die Bereitstellung von Diensten in zentralisierter Weise durch eine Netzverwaltungsanwendung vorgenommen wird. In dieser Hinsicht hat die International Telecommunication Union [ITU] kürzlich einige Standardisierungsaktivität ausgeführt, die die sogenannten "automatisch geschalteten Transportnetze" [ASTN] betreffen. Der Genauigkeit halber: die Standardisierungsaktivität der ITU, die eine neue Generation von Kommunikationstransportnetzen betrifft, war hauptsächlich auf die sogenannten "optischen Transportnetze" [OTN] konzentriert, wahrscheinlich weil zukünftige Kommunikationstransportnetze sehr häufig über optische Fasern ausgeführt sein werden.
Für das Internet-Netz schlug die Internet Engineering Task Force [IETF], eine wohlbekannte internationale Gemeinschaft, die mit der Entwicklung der Internetarchitektur und des – betriebs beschäftigt ist, ein Netzsteuerprotokoll, "RSVP" genannt, vor, um Internetanwendungen zu ermöglichen, verschiedene Dienstqualitäten für verschiedene Arten von Datenströmen zu erhalten; dies wurde insbesondere im Hinblick auf die Übertragung von Information in Echtzeit und mit hoher Bandbreite über das Internet getan. Das RSVP gestattet einer Internetanwendung, einige Netzressourcen zum Ausführen einer eigenen Übertragung zu reservieren; das RSVP sorgt für periodische Auffrischnachrichten, um jene Ressourcen als reserviert aufrechtzuerhalten; bei Nichtvorhandensein von Auffrischnachrichten werden jene Ressourcen freigegeben.
Kürzlich schlug die IETF eine Architektur und ein Protokoll, "COPS" genannt, zur Richtliniensteuerung vor, das für das Internetz-Netz geeignet ist, wie in den Druckschriften RFC 2753 bzw. RFC 2748 beschrieben; diese Architektur sorgt für einen Richtlinien-Server und eine Vielzahl von Richtlinien-Clients; die IETF sorgte auch für eine Ausweitung des RSVP, um eine Richtlinien-Steuerung zu gestatten, und für Nutzungsdirektiven von COPS für RSVP-Umgebungen, wie in den Druckschriften RFC 2750 bzw. RFC 2749 beschrieben.
Jedes Kommunikationstransportnetz und insbesondere ein intelligentes Transportnetz [ITN], ob optisch oder nicht, erfordert eine Richtlinien-Steuerung; mit anderen Worten: das Netz muss die Möglichkeit haben zu ermitteln, ob einem Netznutzer, der außerhalb des Netzes ist, Zugriff und Nutzung einer internen Netzressource gewährt werden sollte. Um in der Lage zu sein, durch das Netz bereitgestellte Kommunikationstransportdienste zu nutzen, benötigt ein Nutzer eine Dienstgütevereinbarung bzw. ein Service-Level-Agreement (nachfolgend als Service-Level-Agreement bezeichnet) [SLA].
Insbesondere in den Fällen, wenn ein Nutzer häufig und/oder direkt verschiedene Netzressourcen anfordert und freigibt, ist es wichtig, dass die für die Richtlinienverwaltung verantwortlichen Einheit oder Einheiten sofort über jede erfolgreiche Anforderung und Freigabe durch einen Nutzer informiert wird. Solche Fällen warn bei den herkömmlichen Transportnetzen äußerst selten, bei denen die Bereitstellung von Diensten in zentralisierter Weise durch eine Netzverwaltungsanwendung vorgenommen wurde, und die Lösung dieses Problems war einfach: der zentralisierte Netzverwalter informierte den zentralisierten Richtlinien-Verwalter über jede Änderung in der Zuweisung von Ressourcen.
Die Idee, die für das Internet-Netz entwickelten, oben genannten Lösungen bei den Kommunikationstransportnetzen anzuwenden, lässt ein sehr wichtiges Problem ungelöst: wie und wann ist der Richtlinien-Server zu informieren, dass eine Verbindung im Transportnetz entfernt wurde.
Natürlich wäre es möglich, dass der Richtlinien-Server direkt beim Transportnetz den Status der Verbindungen im Netz prüft und dann seine Archive aktualisiert; diese Lösung brächte jedoch viel Arbeit und einige Aktualisierungsverzögerung mit sich.
Die Druckschrift R. Ramanujan – An Automated Resource Management Tool for Policy-Drifen QoS Control within Integrated Services Intranets (11. Okt. 1998) offenbart einen Verwalter (Block "QoS Manager" in 3), der in zentralisierter Weise die dynamische Zuweisung und Neukonfiguration von Netzverbindungen steuert und Richtlinien steuert, die die Dienstequalität des Netzes definieren.
Die internationale Patentanmeldung mit der Veröffentlichungsnummer WO 00/31929 offenbart einen Unternehmenskontrollpunkt (Block 50 in 4), der dafür verantwortlich ist, in zentralisierter Weise reservierte Ressourcen in einem Telekommunikationsnetz zu verwalten; der Unternehmenskontrollpunkt identifiziert eine Verbindung in einem Netz, die der angeforderten Dienstqualitätsklasse genügt und die angeforderten Ressourcen entlang der Verbindung reserviert.
Es ist Aufgabe der vorliegenden Erfindung, eine einfachere Lösung für das oben genannte Problem bereitzustellen.
Diese Aufgabe wird im Wesentlichen durch das Richtlinienverwaltungsverfahren gelöst, das die Funktionalitäten aufweist, die im unabhängigen Anspruch 1 dargelegt sind.
Die dem vorliegenden Verfahren zu Grunde liegende Grundidee ist, dass, wenn eine Verbindung im Transportnetz entfernt wird, der oder jeder zu einer solchen Verbindung gehörige Richtlinien-Client die Löschung der zu einer solchen Verbindung gehörige Richtlinieninformation im Richtlinien-Server bewirkt und danach der Richtlinien-Server eine solche Verbindung als entfernt betrachtet.
Weitere vorteilhafte Funktionalitäten des vorliegenden Verfahrens sind in den abhängigen Ansprüchen dargelegt.
Gemäß weiteren Aspekten betrifft die vorliegende Erfindung auch ein Netzelement und einen Richtlinien-Server zur Implementierung des vorliegenden Verfahrens und die die in den unabhängigen Ansprüchen 5 bzw. 9 dargelegten Merkmale aufweisen; weitere vorteilhafte Merkmale des Elements und des Servers sind in den jeweiligen abhängigen Ansprüchen dargelegt.
Die Erfindung wird aus der folgenden Beschreibung deutlicher, die in Verbindung mit der beigefügten Zeichnung betrachtet werden soll, in der 1 ein Blockdiagramm eines intelligenten Transportnetzes ITN zeigt, das mit einem Richtlinien-Server PS versehen ist, wo beispielsweise die vorliegende Erfindung verwendet werden kann; ein Netznutzer ist ebenfalls in 1 schematisch gezeigt.
Das Netz ITN umfasst eine Vielzahl von Netzelementen NE; der Einfachheit wegen sind nur zwei Netzelemente NE in 1 gezeigt und sind nur für einen von ihnen einige interne Einzelheiten gezeigt; die physikalischen Verbindungen der Netzelemente sind nur schematisch gezeigt.
Das Netz ITN kann beispielsweise ein intelligentes optisches Transportnetz [ION] sein.
Das Netz ITN wird von einem administrativen Standpunkt aus von einer Richtlinienverwaltungsanwendung verwaltet. Zu diesem Zweck umfasst das Netz ITN einen Richtlinien-Server PS, und einige der Netzelemente NE des Netzes ITN umfassen einen eigenen Richtlinien-Client PC. Der Richtlinien-Server PS ist mit Richtlinien-Clients PC verbunden und kommuniziert mit ihnen. Im Beispiel von 1 entspricht die Richtlinienarchitektur der Architektur, die in der IETF-Druckschrift RFC 2753 beschrieben ist, und findet die Richtlinienkommunikation gemäß dem COPS-Protokoll statt, wie in der IETF-Druckschrift RFC 2748 beschrieben.
Der Richtlinien-Server PS ist die Einheit des Netzes ITN, die die Aufgabe hat, die Service-Level-Agreements [SLA] der Nutzer des Netzes ITN zu verwalten. Zu diesem Zweck umfasst der Richtlinien-Server PS eine Anwendung PDP für den Richtlinienentscheidungspunkt, die beispielsweise im Wesentlichen als Softwareprozess implementiert ist, und eine Richtlinien-Speicherbibliothek PR zum Speichern wenigstens der Information, die mit Service-Level-Agreements zusammenhängt.
Richtlinien-Clients PC sind die Einheiten des Netzes ITN, die die Aufgabe haben, Service-Level-Agreements [SLA] durchzusetzen, d.h. sicherzustellen, dass ein Nutzer einen Dienst nur in Übereinstimmung mit seinem Service-Level-Agreement erhalten und nutzen kann. Zu diesem Zweck umfasst der Richtlinien-Client PC eine Anwendung PEP für den Richtliniendurchsetzungspunkt, die beispielsweise im Wesentlichen als Softwareprozess implementiert ist.
Der Genauigkeit halber: Richtlinienkommunikation findet zwischen der Anwendung PDP für den Richtlinienentscheidungspunkt und den Anwendungen PEP für den Richtliniendurchsetzungspunkt über das COPS-Protokoll statt.
Die Richtlinienverwaltung findet im Netz ITN über einen Austausch von Nachrichten zwischen den Anwendungen PEP und der Anwendung PDP statt; gemäß einer vereinfachten Beschreibung der Richtlinienverwaltungsaktivität sendet eine Anwendunge PEP Anforderungsnachrichten an die Anwendung PDP und die Anwendung PDP antwortet an jene PEP mit Entscheidungsnachrichten; sowohl die PEP als auch die PDP verfolgen die Paare Anforderung/Entscheidung als Statusinformation; Status von verschiedenen Ereignissen (Paare Anforderung/Entscheidung) können untereinander verbunden sein. Im Allgemeinen bringt die Einrichtung einer neuen Verbindung im Netz eine Anzahl von Ereignissen mit sich. Gemäß dem COPS-Protokoll identifiziert ein Handle eindeutig einen Status für sowohl eine PEP als auch die PDP. Die PDP kann Statusinformation in der Speicherbibliothek PR speichern.
Das Richtlinienverwaltungsverfahren gemäß der vorliegenden Erfindung basiert auf der Verwendung von Statusinformation; es ist für ein Kommunikationsnetz geeignet, das eine Vielzahl von Netzelementen umfasst und bei dem geboten wird, dass die Nutzer des Transportnetzes direkt Kommunikationsdienste bereitstellen; außerdem ist es dafür ausgelegt, in einem Richtliniennetz implementiert zu werden, das einen Richtlinien-Server und eine Vielzahl von Richtlinien-Clients umfasst, die zu Netzelementen des Transportnetzes gehören.
Um die oben genannte Aufgabe zu lösen, bietet das Verfahren gemäß der vorliegenden Erfindung, dass, wenn eine Verbindung im Transportnetz entfernt wird, der oder jeder zu einer solchen Verbindung gehörige Richtlinien-Client die Löschung des oder der zu einer solchen Verbindung gehörigen Status im Richtlinien-Server bewirkt und danach der Richtlinien-Server die Verbindung als entfernt betrachtet.
Um eine geringe Verzögerung zwischen dem Zeitpunkt zu haben, zu dem die Verbindung im Netz entfernt wird, und dem Zeitpunkt, zu dem der Richtlinien-Server dessen gewahr wird, kann vorteilhafterweise vorgesehen sein, dass der Richtlinien-Server die Verbindung als entfernt betrachtet, sobald der letzte zu einer solchen Verbindung gehörige Status gelöscht ist. Die kann beispielsweise auf die folgende Weise erreicht werden: wenn der Programmcodeabschnitt (z.B. ein Unterprogramm oder ein Prozess), der im Richtlinien-Server läuft und für das Löschen von Statusinformation verantwortlich ist, eine Statuslöschungsanforderung empfängt, löscht er den Status, ermittelt er, ob eine Verbindung zu einem solchen Status gehört und bei Bejahung prüft er, ob wenigstens ein zu einer solchen Verbindung gehöriger Status im Richtlinien-Server verbleibt; wenn dies nicht geschieht, d.h. wenn das der letzte zu jener Verbindung gehörige Status war, signalisiert er, dass die Verbindung im Netz entfernt wurde.
Falls der Richtlinien-Server eine Richtlinien-Speicherbibliothek umfasst, kann er vorteilhafterweise seine Richtlinien-Speicherbibliothek aktualisieren, wenn der Richtlinien-Server eine Verbindung als entfernt betrachtet.
Um zu gewährleisten, dass die Nutzer des Netzes ihre SLAs jederzeit vollständig ausnutzen, sieht das Verfahren gemäß der vorliegenden Erfindung vorteilhafterweise vor, dass, wenn der Richtlinien-Server eine Verbindung als entfernt betrachtet, er Nutzerinformation in seiner Richtlinien-Speicherbibliothek für alle zur entfernten Verbindung gehörigen Richtlinien-Clients aktualisiert; beispielsweise wenn ein Nutzer gemäß seiner SLA berechtigt ist, eine bestimmte Anzahl von Verbindungen zu haben und bestimmte Ressourcen des Netzes für seine Verbindungen zu nutzen, kann der Richtlinien-Server, wenn eine von diesem Nutzer angeforderte Verbindung entfernt wird, seine Richtlinien-Speicherbibliothek durch Erhöhung der Anzahl von Verbindungen, die für diesen Nutzer noch verfügbar sind, und durch Markieren der freigegebenen Ressourcen als für Verbindungen verfügbar aktualisieren.
Um das Verfahren der vorliegenden Erfindung zu implementieren, müssen sowohl die Netzelemente als auch der Richtlinien-Server geeignet gestaltet und ausgeführt sein.
Das Netzelement gemäß der vorliegenden Erfindung umfasst einen Richtlinien-Client, der dafür ausgelegt ist, mit einem Richtlinien-Server des Transportnetzes zusammenzuarbeiten, um ein status-basierendes Richtlinienverwaltungsverfahren zu implementieren.
Um dafür ausgelegt zu sein, das Verfahren gemäß der vorliegenden Erfindung zu implementieren, umfasst das Netzelement weitere Mittel zum Senden wenigstens einer Anforderung zur Richtlinienstatuslöschung an den Richtlinien-Server, wenn eine Verbindung im Transportnetz entfernt wird; Die Anzahl von Statuslöschungsanforderungen kann von der speziellen Implementierung des Verfahrens und/oder von der speziellen Verbindung, die entfernt wurde, abhängen.
Wenn das Netzelement auch Mittel zum internen Speichern von Richtlinien-Status, die zu Verbindungen im Transportnetz gehören, und Mittel zum internen Löschen des oder jedes Richtlinien-Status umfasst, der zu einer entfernten Verbindung im Transportnetz gehört, können die Sendemittel ferner vorteilhafterweise dafür ausgelegt sein, den Richtlinien- Server aufzufordern, intern den oder jeden Richtlinien-Status zu löschen, der zur entfernten Verbindung im Transportnetz gehört.
Im Falle des COPS-Modells kann der Richtlinien-Server, da es eine perfekte Entsprechung zwischen den Status des Richtlinien-Clients und den Status des Richtlinien-Servers gibt, (über das eindeutige Handle) genau spezifizieren, welche Status zu löschen sind.
Solch ein Netzelement kann ferner für die Implementierung der verschiedenen weiteren Funktionalitäten des Verfahrens gemäß der vorliegenden Erfindung ausgelegt sein.
Der Richtlinien-Server gemäß der vorliegenden Erfindung ist dafür ausgelegt, mit den Richtlinien-Clients des Transportnetzes zusammenzuarbeiten, um ein status-basierendes Richtlinienverwaltungsverfahren zu implementieren.
Um dafür ausgelegt zu sein, das Verfahren gemäß der vorliegenden Erfindung zu implementieren, umfasst der Richtlinien-Server Mittel zum Empfangen der Anforderungen zur Richtlinienstatuslöschung von den Richtlinien-Clients und Mittel zum Verarbeiten solcher Löschungsanforderungen, die dafür ausgelegt sind, zu verstehen, wenn eine Verbindung im Transportnetz entfernt wurde.
Wenn der Richtlinien-Server auch Mittel zum Speichern von Richtlinienstatus, die zu Verbindungen im Transportnetz gehören, und Mittel zum Löschen von Richtlinienstatus umfasst, die zu Verbindungen im Transportnetz gehören, können die Verarbeitungsmittel ferner vorteilhafterweise dafür ausgelegt sein, zu prüfen, wann der oder jeder Richtlinien-Status, der zu einer Verbindung gehört, gelöscht wurde, und daraus herzuleiten, dass eine solche Verbindung entfernt wurde.
Im Falle des COPS-Modells kann der Richtlinien-Server, da es eine perfekte Entsprechung zwischen den Status des Richtlinien-Clients und den Status des Richtlinien-Servers gibt, von den Richtlinien-Clients eine genaue Spezifikation (über das eindeutige Handle) der Status empfangen, die gelöscht werden müssen.
Solch ein Richtlinien-Server kann ferner für die Implementierung der verschiedenen weiteren Funktionalitäten des Verfahrens gemäß der vorliegenden Erfindung ausgelegt sein.
Das Verfahren und die Vorrichtungen gemäß der vorliegenden Erfindung können teilweise oder vollständig in Software implementiert sein.
Daher besteht ein erster weiterer Aspekt der vorliegenden Erfindung in einem Prozessorprogrammprodukt, das Programmcodeabschnitte umfasst, die für die Implementierung des Verfahrens gemäß der vorliegenden Erfindung ausgelegt sind, wenn sie von einem Prozessor ausgeführt werden.
Ein zweiter weiterer Aspekt der vorliegenden Erfindung besteht in Speichermitteln, die ein Prozessorprogrammprodukt speichern, das Programmcodeabschnitte umfasst, die für die Implementierung des Verfahrens gemäß der vorliegenden Erfindung ausgelegt sind, wenn sie von einem Prozessor ausgeführt werden.

Claims

Status-basiertes Richtlinienverwaltungsverfahren (policy management method) für ein Kommunikationstransportnetz (ITN), das eine Vielzahl von Netzelementen (NE) umfasst, wobei das Verfahren dafür ausgelegt ist, in einem Richtlinien-Netz (policy network) implementiert zu sein, das einen Richtlinien-Server (policy server) (PS) umfasst, dadurch gekennzeichnet, dass dafür gesorgt wird, dass die Nutzer des Transportnetzes (ITN) Kommunikationstransportdienste direkt bereitstellen, und dass das Verfahren dafür ausgelegt ist, in dem Richtlinien-Netz implementiert zu sein, das ferner eine Vielzahl von Richtlinien-Clients (policy clients) (PC) umfasst, die zu Netzelementen (NE) des Transportnetzes (ITN) gehören, und dass, wenn eine Verbindung im Transportnetz (ITN) beseitigt wird, der oder jeder Richtlinien-Client (PC), der zu dieser Verbindung gehört, die Löschung des oder jedes zu dieser Verbindung gehörigen Status im Richtlinien-Server (PS) bewirkt und danach der Richtlinien-Server (PS) diese Verbindung als beseitigt betrachtet.
Verfahren nach Anspruch 1, bei dem der Richtlinien-Server (PS) die Verbindung als beseitigt betrachtet, sobald der letzte zu dieser Verbindung gehörige Status gelöscht ist.
Verfahren nach Anspruch 1 oder 2, bei dem der Richtlinien-Server (PS) eine Richtlinien- Speicherbibliothek (PR) umfasst und bei dem, wenn der Richtlinien-Server (PS) eine Verbindung als beseitigt betrachtet, er seine Richtlinien-Speicherbibliothek (PR) aktualisiert.
Verfahren nach Anspruch 3, bei dem, wenn der Richtlinien-Server (PS) eine Verbindung als beseitigt betrachtet, er Nutzerinformation in seiner Richtlinien-Speicherbibliothek (PR) für alle zur beseitigten Verbindung gehörigen Richtlinien-Clients aktualisiert.
Netzelement (NE) für ein Kommunikationstransportnetz (ITN), wobei das Netz einen Richtlinien-Server (PS) umfasst, um ein status-basiertes Richtlinienverwaltungsverfahren nach Anspruch 1 zu implementieren, dadurch gekennzeichnet, dass das Netzelement ferner einen Richtlinien-Client (PC) umfasst, der dafür ausgelegt ist, mit dem Richtlinien-Server zusammenzuarbeiten, und dass das Netzelement ferner umfasst: – Mittel zum Senden wenigstens einer Anfrage zur Richtlinienstatuslöschung an den Richtlinienserver (PS), wenn die Verbindung im Transportnetz (ITN) beseitigt ist.
Netzelement (NE) nach Anspruch 5, das ferner umfasst: – Mittel zum internern Speichern von Richtlinienstatus, die zu Verbindungen im Transportnetz (ITN) gehören, und – Mittel zum internern Löschen des oder jedes Richtlinienstatus, der zu einer beseitigten Verbindung im Transportnetz (ITN) gehört; wobei die Sendemittel dafür ausgelegt sind, den Richtlinien-Server (PS) aufzufordern, intern den oder jeden Richtlinienstatus zu löschen, der zur beseitigten Verbindung im Transportnetz (ITN) gehört.
Netzelement (NE) nach Anspruch 5 oder 6, bei dem die Sendemittel dafür ausgelegt sind, ein COPS-Protokoll zu implementieren.
Richtlinien-Server (PS) für ein Kommunikationsnetz (ITN), wobei das Netz (ITN) von der Art ist, die eine Vielzahl von Netzelementen (NE) umfasst, dadurch gekennzeichnet, dass das Netz ferner eine Vielzahl von Richtlinien-Clients (PC) umfasst, die zu Netzelementen (NE) des Netzes (ITN) gehören, und dass der Richtlinien-Server (PS) dafür ausgelegt ist, mit den Richtlinien-Clients (PC) zusammenzuarbeiten, um ein status-basiertes Richtlinienverwaltungsverfahren nach Anspruch 1 zu implementieren, wobei der Richtlinien-Server umfasst: – Mittel zum Empfangen von Anforderungen zur Richtlinienstatuslöschung von den Richtlinien-Clients (PC) her, und – Mittel zum Verarbeiten dieser Löschungsanforderungen, die dafür ausgelegt sind zu verstehen, wann eine Verbindung im Transportnetz (ITN) beseitigt wurde.
Richtlinien-Server (PS) nach Anspruch 8, der ferner umfasst: – Mittel zum Speichern von Richtlinienstatus, die zu Verbindungen im Transportnetz (ITN) gehören, – Mittel zum Löschen von Richtlinienstatus, die zu Verbindungen im Transportnetz (ITN) gehören; wobei die Verarbeitungsmittel dafür ausgelegt sind zu prüfen, wann der oder jeder zu einer Verbindung gehörige Richtlinienstatus gelöscht wurde und daraus herzuleiten, dass die Verbindung beseitigt wurde.
Richtlinien-Server (PS) nach Anspruch 8 oder 9, bei dem die Empfangsmittel dafür ausgelegt sind, ein COPS- Protokoll zu implementieren.
Prozessorprogrammprodukt, das Programmcodeabschnitte umfasst, die für die Implementierung jedes Schrittes des Verfahrens nach einem der Ansprüche 1 bis 4 ausgelegt sind, wenn es von einem Prozessor ausgeführt wird.
Speichermittel, die ein Prozessorprogrammprodukt speichern, das Programmcodeabschnitte umfasst, die für die Implementierung jedes Schrittes des Verfahrens nach einem der Ansprüche 1 bis 4 ausgelegt sind, wenn es von einem Prozessor ausgeführt wird.