DE60121350T2

DE60121350T2 - System, einrichtung und verfahren zur verwaltung von kommunikationsdiensten in einem optischen kommunikationssystem

Info

Publication number: DE60121350T2
Application number: DE60121350T
Authority: DE
Inventors: A. Bruce Tyngsboro SCHOFIELD; R. William Hollis HAWE; D. Paul Carlisle CALLAHAN; S. Indermohan Lexington MONGA; Stephen Suryaputra; N. Andre Groton FREDETTE
Original assignee: Nortel Networks Ltd
Current assignee: Nortel Networks Ltd
Priority date: 2000-08-15
Filing date: 2001-08-15
Publication date: 2006-11-16
Anticipated expiration: 2021-08-16
Also published as: AU2001284907A1; EP1323251B1; EP1705813A1; US7706687B1; US7437449B1; US20140219649A1; US9225417B2; WO2002015442A1; US20030212829A1; US20090074404A1; US7321932B1; CA2419793C; US7840692B1; DE60135165D1; DE60121350D1; US7849225B2; US7738359B1; EP1323251A4; EP1323251A1; CA2419793A1

Description

Die vorliegende Erfindung bezieht sich allgemein auf optische Netzwerke und insbesondere auf die Verwaltung von Kommunikationsdiensten in einem optischen Kommunikationssystem.
Im heutigen Informationszeitalter werden Kommunikationsnetze im wachsenden Ausmaß zum Übertragen von Informationen zwischen einer Vielzahl von Kommunikationsgeräten verwendet. Mit der wachsenden Nachfrage nach Kommunikationsdiensten ist auch ein weiteres Anwachsen der Nachfrage bei diesen Kommunikationsnetzwerken im Hinblick auf die Übertragung immer größerer Informationsmengen bei steigenden Geschwindigkeiten verbunden. Daher werden Kommunikationsnetzwerke entwickelt, die dieser wachsenden Nachfrage gerecht werden.
Eine Richtung, in die sich Kommunikationsnetzwerke entwickeln, ist die Verwendung von optischen Kommunikationseinrichtungen. Optische Kommunikationseinrichtungen transportieren Informationen über optische Kommunikationsmedien (z. B. Lichtleitfasern). Derartige optische Kommunikationsnetzwerke bieten sowohl über kurze als auch über lange Distanzen enorme Mengen an Bandbreite.
Das optische Kommunikationsnetzwerk ist in der Lage, seinen Benutzern die verschiedensten Kommunikationsdienste bereitzustellen. Traditionell sind solche Kommunikationsdienste sehr teuer und müssen sehr langfristig entwickelt und geplant werden. Das liegt teilweise daran, dass Änderungen am optischen Kommunikationsnetzwerk wie z. B. die Bereitstellung und Schaltung von optischen Kommunikationswegen ein hohes Maß an Eingreifen durch den Menschen erforderten.
Eine Diskussion zur Realisierbarkeit der Implementierung eines Steuerungs- und Verwaltungssystems in einem WDM-Netzwerk über eine COBRA-fähige (Common Object Request Broker Architecture) und zuverlässige verteilte Plattform ist einer Publikation zu entnehmen, die von Wei J. Y. et al stammt und den Titel trägt „Network Control and Management of a Reconfigurable WDM Network", Military Communications Conference, 1996, Conference Proceedings IEEE Maclean, VA, USA, 21.-24. Oktober 1996, Seiten 581-586. Darin wird auch die Realisierbarkeit der Verwendung eingebetteter optischer Wellenlänge zur Unterstützung der Datenkommunikationskanäle des Netzwerkverwaltungssystems diskutiert.
Ein Peer-to-Peer-Kommunikationssystem wird in einer Publikation beschrieben, die von Dr. Michah Lerner stammt und den Titel trägt „Project Summary Peer Communication", Programming and Design of Modern Internet Platforms, 24. Dezember 1999, Seiten 1 bis 17. Wenn ein Peer wie beispielsweise ein Internet-Benutzer versucht, mit einem anderen Peer über ein Kommunikationssystem wie das Internet zu kommunizieren, wird die Kommunikation zwischen diesen beiden Peers im öffentlich zugänglichen Internet bloßgelegt. In dem in der Lerner-Publikaton beschriebenen System wird Middleware-Ausrüstung bereitgestellt, die sichere und zuverlässige Verbindungen für die Kommunikation zwischen Peers bietet. Der Versuch eines Peers zur Kommunikation mit einem anderen Peer wird durch einen sicheren Kanal erzwungen, der durch die Middleware-Ausrüstung bereitgestellt wird. Um jedoch die Middleware-Ausrüstung verwenden zu können, müssen sich die Peers durch Registrierung an der Middleware-Ausrüstung bekannt machen.
Gemäß einem Aspekt der Erfindung wird ein optischer Service-Agent (OSA) zur Verwaltung von Kommunikationsdiensten für einen Benutzer in einem optischen Kommunikationssystem bereitgestellt, wobei der optische Service-Agent umfasst: eine Benutzernetzwerkschnittstelle (User to Network Interface – UNI) als Schnittstelle zu einem optischen Kommunikationsnetzwerk; und optische Service-Logik zum Erreichen optischer Kommunikationsdienste vom optischen Kommunikationsnetzwerk über die UNI und zum Verwalten der optischen Kommunikationsdienste für den Benutzer; wobei der optische Service-Agent dadurch gekennzeichnet ist, dass er des Weiteren umfasst: Auto-Erkennungslogik zum automatischen Erkennen von Peer-Benutzern; Peer-to-Peer-Signalisierungslogik zum Kommunizieren mit Peer-Benutzern; wobei die optische Service-Logik die Kommunikationsdienste mit Peer-Benutzern über die Peer-to-Peer-Signalisierungslogik koordiniert. Der OSA kann praktisch jeden Kommunikationsdienst verwalten, der manuell gehandhabt werden kann.
Gemäß einem anderen Aspekt der Erfindung wird ein Verfahren zum Verwalten von Kommunikationsdiensten für Peer-Benutzer in einem optischen Kommunikationssystem bereitgestellt, wobei das optische Kommunikationssystem ein optisches Kommunikationsnetzwerk einschließlich einer Vielzahl von Randknoten umfasst, über die die Peer-Benutzer auf das optische Kommunikationsnetzwerk zugreifen, und einschließlich eines optischen Service-Servers "OSS" zum Koordinieren verschiedener Kommunikationsdienste, die durch das optische Kommunikationsnetzwerk bereitgestellt werden, wobei das Verfahren umfasst: das Registrieren von Peer-Benutzern beim OSS; und das Verteilen von Peer-Informationen an die Peer-Benutzer durch den OSS; wobei das Verfahren dadurch gekennzeichnet ist, dass es umfasst: das automatische Erkennen und Authentifizieren von Peer-Benutzern durch das Registrieren eines ersten Peer-Benutzers beim OSS; und das Registrieren eines zweiten Peer-Benutzers beim OSS; und wobei das Registrieren des ersten Peer-Benutzers beim OSS umfasst: das Senden einer Registrierungsanforderung durch den ersten Peer-Benutzer an einen ersten Randknoten; das Authentifizieren des ersten Peer-Benutzers durch den ersten Randknoten; und das Senden einer Beitrittsmeldung durch den ersten Randknoten an den OSS zur Identifizierung des ersten Peer-Benutzers.
Verschiedene Aspekte der vorliegenden Erfindung können auf ein agiles Transportnetzwerk angewendet werden, zum Beispiel auf ein automatisch schaltendes Optik-/Transportnetzwerk (Automatically Switched Optical/Transport Network – ASON/ASTN).
KURZE BESCHREIBUNG DER ZEICHNUNGEN
Die beiliegenden Zeichnungen haben folgende Bedeutung:
1 ist ein Netzwerkdiagramm und zeigt eine Darstellung eines Kommunikationssystems, in dem Benutzer über ein automatisch geschaltetes Optiknetzwerk (ASON) kommunizieren, gemäß einer Ausführungsform der vorliegenden Erfindung;
2 ist ein Netzwerkdiagramm und zeigt ein Beispiel-ASON gemäß einer Ausführungsform der vorliegenden Erfindung;
3 ist ein Blockdiagramm und zeigt die relevanten Komponenten eines Beispiel-ASON-Geräts gemäß einer Ausführungsform der vorliegenden Erfindung;
4 ist ein Blockdiagramm und zeigt einen ASON-fähigen Benutzer einschließlich einer ASON-fähigen Benutzeranwendung gemäß einer Ausführungsform der vorliegenden Erfindung;
5 ist ein Netzwerkdiagramm und zeigt ein Beispiel-Kommunikationssystem, in dem ASON-fähige Benutzer über ein ASON kommunizieren, gemäß einer Ausführungsform der vorliegenden Erfindung;
6. ist ein Blockdiagramm und zeigt einen OSA-fähigen Benutzer einschließlich eines eingebetteten OSA gemäß einer Ausführungsform der vorliegenden Erfindung;
7 ist ein Diagramm und zeigt die Beziehung zwischen einer Benutzeranwendung und dem OSA gemäß einer Ausführungsform der vorliegenden Erfindung;
8 ist ein Diagramm und zeigt die Beziehung zwischen dem OSA-A und dem OSA-N gemäß einer Ausführungsform der vorliegenden Erfindung;
9 ist ein Diagramm und zeigt ein Beispielsystem, in dem der OSA-N sich beim OSA-fähigen Benutzer im Randsystem befindet, gemäß einer Ausführungsform der vorliegenden Erfindung;
10 ist ein Diagramm und zeigt ein Beispielsystem, in dem der OSA-N sich im ASON-Gerät am Rand des ASON befindet, gemäß einer Ausführungsform der vorliegenden Erfindung;
11 ist ein Diagramm und zeigt ein Beispielsystem, in dem der OSA-N sich außerhalb des OSA-fähigen Benutzers und des ASON-Geräts in einer Proxy-Anordnung befindet, gemäß einer Ausführungsform der vorliegenden Erfindung;
12 ist ein Diagramm zur Darstellung, wie die OSA-N-Funktionalität durch den OSS gehandhabt wird, gemäß einer Client-Server-Ausführungsform der vorliegenden Erfindung;
13 ist ein Meldungs-Flussdiagramm zur Darstellung der verschiedenen Austausche zwischen dem OSA-N und dem OSS gemäß einer Client-Server-Ausführungsform der vorliegenden Erfindung;
14 ist ein Diagramm zur Darstellung, wie die Authentifizierung durch den OSA gemäß einer verteilten Flutungsausführungsform der vorliegenden Erfindung gehandhabt wird;
15 ist ein Meldungs-Flussdiagramm zur Darstellung der verschiedenen Austausche zwischen dem OSA-N und dem OSS gemäß einer verteilten Flutungsausführungsform der vorliegenden Erfindung;
16 ist ein Diagramm zur Darstellung, wie die Authentifizierung und die Flutung durch den OSS gemäß einer Hybrid/Proxy-Ausführungsform der vorliegenden Erfindung gehandhabt wird;
17 ist ein Meldungs-Flussdiagramm zur Darstellung der verschiedenen Austausche zwischen dem OSA-N und dem OSS gemäß einer Hybrid/Proxy-Ausführungsform der vorliegenden Erfindung;
18 ist ein Netzwerkdiagramm und zeigt ein Beispiel-Kommunikationssystem, in dem ein OSA-fähiger Benutzer mit einem ASON-fähigen Benutzer über das ASON kommuniziert, gemäß einer Ausführungsform der vorliegenden Erfindung;
19 ist ein Netzwerkdiagramm und zeigt ein Beispiel-Kommunikationssystem, in dem zwei OSA-fähige Benutzer über das ASON kommunizieren, gemäß einer Ausführungsform der vorliegenden Erfindung;
20 ist ein Blockdiagramm und zeigt die relevanten Komponenten des OSA gemäß einer Ausführungsform der vorliegenden Erfindung;
21 ist ein Logik-Flussdiagramm und zeigt Beispiel-OSA-Logik zur Verwaltung von Kommunikationsdiensten gemäß einer Ausführungsform der vorliegenden Erfindung;
22 ist ein Meldungs-Flussdiagramm zur Veranschaulichung eines authentifizierten Auto-Erkennungsprozesses gemäß einer Ausführungsform der vorliegenden Erfindung.
23 ist ein Meldungs-Flussdiagramm zur Veranschaulichung des Ablaufs beim Entfernen eines OSA-fähigen Benutzers aus einer Peer-Gruppe gemäß einer Ausführungsform der vorliegenden Erfindung.
BESCHREIBUNG EINER BEVORZUGTEN AUSFÜHRUNGSFORM
In einer Ausführungsform der vorliegenden Erfindung verwaltet ein innerhalb der Domäne des Netzwerkbenutzers operierender optischer Service-Agent (OSA) verschiedene Kommunikationsdienste im Auftrag des Netzwerkbenutzers. Der OSA interagiert mit dem optischen Kommunikationsnetzwerk, um verschiedene Kommunikationsdienste zu erreichen, und verwaltet diese Kommunikationsdienste für den Netzwerkbenutzer auf der Basis vorgegebener Parameter, die vom Netzwerkbenutzer definiert wurden. Im Wesentlichen stellt dann das optische Kommunikationsnetzwerk ein "Kernset" an Kommunikationsdiensten bereit, auf die durch den OSA zugegriffen werden kann, und der OSA stellt erweiterte Kommunikationsdienste für den Netzwerkbenutzer bereit, indem er das "Kernset" der Kommunikationsdienste verwendet, das durch das optische Kommunikationsnetzwerk bereitgestellt wird.
In einem agilen Transportnetzwerk werden verschiedene Kommunikationsdienste, die bisher manuell ausgeführt wurden, durch "intelligente" optische Kommunikationsgeräte innerhalb des Netzwerks automatisch ausgeführt. Insbesondere entwickelt sich die optische Internet-Infrastruktur von einem statisch bereitgestellten, auf einem SONET-Ring basierenden Transportnetzwerk hin zu einem eher dynamisch bereitgestellten Maschennetzwerk.
Ein Beispiel für ein agiles Transportnetzwerk ist ein automatisch schaltendes Optik-/Transportnetzwerk (Automatically Switched Optical/Transport Network – ASON/ASTN). Das ASON umfasst typischerweise optische Cross-Connect-Schalter (OXCs), die zur Bildung des Maschennetzwerks verwendet werden, und optische Kanalsteuereinheiten (Optical Channel Controller – OCCs), die optische Kommunikationswege dynamisch erstellen, löschen und ändern, indem die OXCs über eine Verbindungssteuerschnittstelle (Connection Control Interface – CCI) gesteuert werden. Der Übersichtlichkeit halber werden die OXCs und OCCs im Folgenden gemeinsam als ASON-Geräte bezeichnet. Die ASON-Geräte, und insbesondere die OCCs, sind typischerweise Netzwerk-Router, die mit einem Link-State-Routing-Protokoll (z. B. OSPF) zur Verteilung von Link-Attributen (zum Beispiel Verfügbarkeit optischer Kanäle) und mit einem Signalisierungsprotokoll (z. B. MPLS oder GMPLS) zur End-to-End-Verwaltung der optischen Kommunikationswege arbeiten. Diese Protokolle ermöglichen dem ASON das schnelle Erstellen, Löschen und Ändern von optischen Kommunikationswegen. Das ASON enthält typischerweise auch einen optischen Service-Server (OSS) zum Koordinieren der verschiedenen Kommunikationsdienste, die vom ASON bereitgestellt werden. Damit bietet das ASON eine größere Agilität, indem es vom manuellen Bereitstellen zum automatischen Bereitstellen über Schaltung und Signalisierung übergeht.
Im Wesentlichen ist das ASON damit ein Optik-/Transportnetzwerk, das über dynamische Verbindungsmöglichkeiten verfügt. Unter anderem ermöglicht das ASON die Erkennung der physischen Topologie von optischen Elementen, die effiziente Verwendung der verfügbaren Bandbreite durch dynamisches Erstellen von optischen Kommunikationswegen sowie End-to-End-Schutz und -Wiederherstellung von Verbindungen.
1 zeigt eine Darstellung eines Kommunikationssystems 100, in dem zwei Benutzer 110, 130 über ein ASON 120 kommunizieren. Die Benutzer 110, 130 können optische Schalt-Router sein, die als Randknoten ihrer jeweiligen Benutzernetzwerke positioniert sind, um als Schnittstelle zum ASON 120 zu dienen. Das ASON 120 stellt den Benutzern 110, 130 über die automatische Service-Logik verschiedene Kommunikationsdienste bereit. Im weiteren Verlauf werden verschiedene ASON-Kommunikationsdienste im Detail beschrieben.
Jedes ASON-Gerät enthält eine ASON-Steuereinheit zur Unterstützung automatisierter Kommunikationsdienste innerhalb des ASON 120. Unter anderem ermöglicht die ASON-Steuereinheit jedem ASON-Gerät das automatische Bereitstellen, Schalten und Signalisieren optischer Kommunikationswege innerhalb des ASON 120. Die ASON-Steuereinheit ermöglicht Betreibern und Dienstanbietern das Anbieten vieler Mehrwertdienste für ihre Kunden.
Damit die Benutzer 110, 130 die Kommunikationsdienste vom ASON 120 steuern und überwachen können, stellt die ASON-Steuereinheit eine Benutzernetzwerk schnittstelle (User to Network Interface – UNI) bereit, über die die Benutzer 110, 130 mit der ASON-Steuereinheit interagieren, um die Kommunikationsdienste innerhalb des ASON 120 zu steuern und zu überwachen. Über die ASON-UNI können die Benutzer 110, 130 auf verschiedene steuerbare Funktionen des ASON 120 zugreifen. So können die Benutzer 110, 130 über die ASON-UNI beispielsweise einen optischen Kommunikationsweg mit bestimmten Attributen anfordern, die Attribute des optischen Kommunikationswegs neu aushandeln, das Schalten des optischen Kommunikationswegs steuern, den optischen Kommunikationsweg beenden und den Betrieb des ASON 120 überwachen, um nur einige Möglichkeiten zu nennen.
Innerhalb des ASON 120 kann jedes ASON-Gerät verschiede Funktionen zur Unterstützung der automatischen Kommunikationsdienste ausführen. Einige dieser Funktionen können durch ein einzelnes ASON-Gerät ausgeführt werden, während andere Funktionen die Koordinierung zwischen mehreren ASON-Geräten voraussetzen. Deshalb stellt die ASON-Steuereinheit eine Netzwerk-zu-Netzwerk-Schnittstelle (Network to Network Interface – NNI) bereit, welche die Kommunikation zwischen ASON-Geräten zur Koordinierung verschiedener Kommunikationsfunktionen ermöglicht. Über die ASON-NNI können die verschiedenen ASON-Geräte ASON-Routing-Informationen austauschen und solche Dinge koordinieren wie das Einrichten und Beenden von optischen Kommunikationswegen, das Schalten optischer Kommunikationswege und das Schützen und Wiederherstellen von optischen Kommunikationswegen, um nur einiges zu nennen.
2 zeigt eine Beispiel-Ausführungsform des ASON 120 mit vier ASON-Geräten 210, 220, 230, 240 und einem OSS 250. Der Übersichtlichkeit halber stellen die durchgezogenen Linien zwischen den ASON-Geräten 210-240 optische Kommunikationswege dar, bei denen es sich um volloptische Wege (Lichtwege) oder teilweise optische Wege (Schaltwege) handeln kann, und die gestrichelten Linien zwischen den ASON-Geräten 210-240 zeigen den Schnittstellentyp (UNI oder NNI). Die Benutzer 110, 130 verbinden sich mit dem ASON 120 über das ASON-Gerät 210 bzw. das ASON-Gerät 240. Die ASON-Geräte 210, 240 stellen jeweils eine UNI für die Benutzer 110 bzw. 130 bereit, über die die Benutzer 110, 130 die vom ASON 120 bereitgestellten Kommunikationsdienste steuern und überwachen können, und insbesondere über die ASON-Steuereinheit in den ASON-Geräten 210-240. Die ASON-Geräte 210-240 sind über die NNI miteinander verbunden und verwenden die NNI zum Zusammenwirken, um verschiedene Kommunikationsfunktionen zu koordinieren. Es muss darauf hingewiesen werden, dass die ASON-NNI Kommunikationswege nutzen kann, die separat von den optischen Kommunikationswegen sind. Der OSS 250 koordiniert die verschiedenen Kommunikationsdienste, die durch die ASON-Geräte 210-240 bereitgestellt werden.
Das Herzstück der verschiedenen automatisierten Kommunikationsdienste bildet das automatische Schalten der optischen Kommunikationswege. Um das automatische Schalten der Kommunikationswege innerhalb des ASON 120 zu unterstützen, enthalten die ASON-Geräte 210-240 typischerweise eine Form optischer Schaltlogik, z. B. optische/photonische Switching Fabric, zur Durchführung der optischen/photonischen Schaltung der optischen Kommunikationswege. Die optische Switching Fabric kann auf einer Vielzahl von optischen/photonischen Schalttechnologien basieren, einschließlich, jedoch nicht darauf beschränkt, auf der MEMS-Technologie (Micro Electro Mechanical System), auf der MOEMS-Technologie (Micro Opto Electro Mechanical System), auf der Lithiumniobat-Technologie, auf der Flüssigkristall-Technologie oder auf anderen optischen/photonischen Schalttechnologien. Die optische Schaltlogik kann unter Steuerung der ASON-Steuereinheit für solche Vorgänge konfiguriert werden wie das Durchlassen optischer Datenströme von einer Anzahl ankommender Lichtleitfasern zu einer Anzahl von abgehenden Lichtleitfasern (d. h. Schalten), das Hinzufügen eines optischen Datenstroms zu einer abgehenden Lichtleitfaser und das Entfernen eines optischen Datenstroms von einer ankommenden Lichtleitfaser zur lokalen Verarbeitung durch das ASON-Gerät, um nur einige zu nennen.
3 zeigt die relevanten Komponenten eines Beispiel-ASON-Geräts 300. Das ASON-Gerät 300 umfasst unter anderem eine Anzahl ankommender optischer Schnittstellen 310, eine Anzahl abgehender optischer Schnittstellen 330, optische Schaltlogik 320, die ASON-Steuereinheit 340, die ASON-UNI 350, die ASON-NNI 360, die ASON-NMI 370 (Network Management Interface – Netzwerkverwaltungsschnittstelle) sowie Netzwerkverwaltungs- und -optimierungselemente 380. Die ankommende(n) optische(n) Schnittstelle(n) 310 ist (bzw. sind) an eine Anzahl ankommender Lichtleitfasern koppelbar, um optische Datenströme verschiedener Wellenlängen zu empfangen. Die abgehende(n) optische(n) Schnittstelle(n) 330 ist (bzw. sind) an eine Anzahl abgehender Lichtleitfasern koppelbar, um optische Datenströme verschiedener Wellenlängen auszugeben. Die optische Schaltlogik 320 ist zwischen die ankommende(n) optische(n) Schnittstelle(n) 310 und die ausgehende(n) optische(n) Schnittstelle(n) 330 geschaltet, um die optischen Datenströme zu schalten, was solche Vorgänge einschließen kann wie das Durchlassen bestimmter optischer Datenströme, die über die ankommende(n) optische(n) Schnittstelle(n) 330 empfangen wurden, das Entfernen von einem oder mehreren optischen Datenströmen, die über die ankommende(n) optische(n) Schnittstelle(n) 310 empfangen wurden, um lokal durch das ASON-Gerät 300 verarbeitet zu werden, und das Hinzufügen von einem oder mehreren optischen Datenströmen zu der bzw. zu den abgehenden optischen Schnittstelle(n) 330, um nur einige zu nennen. Die ASON-Steuereinheit 340 automatisiert bestimmte Kommunikationsdienste, indem sie unter anderem die ankommende(n) optische(n) Schnittstelle(n) 310, die optische Schaltlogik 320 und die abgehende(n) optische(n) Schnittstelle(n) 330 steuert. Die ASON-UNI 350 ermöglicht einem Benutzer die Steuerung und Überwachung der von der ASON-Steuereinheit 340 bereitgestellten Kommunikationsdienste. Die ASON-NNI 360 ermöglicht es der ASON-Steuereinheit 340 innerhalb des ASON-Geräts 300, mit der ASON-Steuereinheit in anderen ASON-Geräten zu interagieren, um die Kommunikationsdienste innerhalb des ASON 120 zu koordinieren. Die ASON-UNI 350 und die ASON-NNI 360 sind typischerweise in die ASON-Steuereinheit 340 integriert, werden hier jedoch der Übersichtlichkeit halber separat gezeigt. Die ASON-NMI 370 ist eine Netwerkverwaltungsschnittstelle zwischen der ASON-Steuereinheit 340 und verschiedenen Netzwerkverwaltungs- und -optimierungselementen 380. Unter anderem liefert die ASON-Steuereinheit 340 Netzwerkstatusinformationen an die Netzwerkverwaltungs- und -optimierungselemente 380 und empfängt Netzwerkaktualisierungen von den Netzwerkverwaltungs- und – optimierungselementen 380 über die ASON-NMI 370.
Ohne Einschränkung kann das ASON 120 praktisch jeden Kommunikationsdienst bereitstellen, der bisher manuell ausgeführt wurde. Einige Beispiel-Kommunikationsdienste, die durch das ASON 120 bereitgestellt werden können, sind „Plug and Play" für optische Elemente, das Modellieren optischer Kommunikationswege, das automatische Bereitstellen optischer Kommunikationswege, das von Benutzerseite angeforderte Schalten optischer Kommunikationswege, das automatische Schalten auf SLA-Basis (Service Level Agreement), das automatische Schalten für Schutz und Wiederherstellung, die Bandbreitenverwaltung und das Berichten statistischer und anderer Informationen, um nur einige zu nennen. Es muss darauf hingewiesen werden, dass die vorliegende Erfindung in keiner Weise eingeschränkt ist auf bestimmte Kommunikationsdienste, die vom ASON 120 bereitgestellt werden.
Wie bereits oben erläutert wurde, ermöglicht die ASON-UNI den Benutzern die Steuerung und Überwachung der vom ASON 120 bereitgestellten Kommunikationsdienste. Die ASON-UNI bietet eine standardisierte Schnittstelle zum ASON 120 und insbesondere zur ASON-Steuereinheit 340 im ASON-Gerät. Vom Konzept her bietet die ASON-UNI eine Reihe von „Steuerknöpfen", über die die Benutzer die ASON-Kommunikationsdienste steuern und überwachen können.
Eine Möglichkeit für einen Benutzer, auf die ASON-Kommunikationsdienste zuzugreifen, besteht in der Implementierung eines Teils oder der gesamten ASON-UNI-Funktionalität. So kann die ASON-UNI-Funktionalität beispielsweise in eine Benutzeranwendung integriert sein, so dass die Benutzeranwendung auf ASON-Kommunikationsdienste zugreifen kann. Der Übersichtlichkeit halber wird ein solcher Benutzer im Folgenden als ASON-fähiger Benutzer und eine solche Benutzeranwendung als ASON-fähige Benutzeranwendung bezeichnet.
4 zeigt einen ASON-fähigen Benutzer einschließlich einer ASON-fähigen Benutzeranwendung 410. Die ASON-fähige Benutzeranwendung 410 implementiert einen Teil oder die gesamte ASON-UNI-Funktionalität. Die ASON-fähige Benutzeranwendung 410 kommuniziert mit der ASON-Steuereinheit 340 im ASON-Gerät über einen ASON-Signalisierungskanal 420 unter Verwendung der ASON-UNI, um vom ASON 120 Kommunikationsdienste zu erreichen. Der ASON-Signalisierungskanal 420 kann zum Beispiel ein Inband-Signal sein, das über einen SONET-Datenkommunikationskanal (Data Communication Channel – DCC) übertragen wird.
5 zeigt ein Beispiel-Kommunikationssystem 500, in dem zwei ASON-fähige Benutzer 510, 520 über das ASON 120 kommunizieren. Jeder der ASON-fähigen Benutzer 510, 520 implementiert einen Teil oder die gesamte ASON-UNI und sind deshalb in der Lage, bestimmte Kommunikationsdienste zu überwachen und zu steuern, die vom ASON 120 bereitgestellt werden. Beispielsweise können die ASON-fähigen Benutzer 510, 520 mithilfe der ASON-UNI einen optischen End-to-End-Kommunikationsweg einrichten, um über das ASON 120 zu kommunizieren. Der optische Kommunikationsweg hat bestimmte Attribute, die sowohl zwischen den beiden ASON-fähigen Benutzern 510, 520 als auch zwischen den ASON-fähigen Benutzern 510, 520 und dem ASON 120 ausgehandelt werden.
Leider ist es nicht immer praktisch, die ASON-UNI in jeder Benutzeranwendung zu implementieren, die ASON-Kommunikationsdienste benötigt. Deshalb besteht für den Benutzer eine andere Möglichkeit zum Zugriff auf ASON-Kommunikationsdienste darin, einen optischen Service-Agent (OSA) einzusetzen, der die Kommunikationsdienste für den Benutzer verwaltet. Der OSA ist ein intelligenter, eingebetteter Signalisierungsagent, der innerhalb des Benutzers am Rand des ASON 120 betrieben wird. Der OSA implementiert anwendungsspezifische Dienste und Intelligenz sowie die ASON-UNI und andere Mechanismen zur Kommunikation mit der ASON-Steuereinheit 340 über die ASON-UNI. Der OSA kann als ein Untersystem angesehen werden, das die Benutzeranforderungen versteht und im Auftrag des Benutzers verschiedene Kommunikationsdienste verwaltet, um die Benutzeranforderungen zu erfüllen. Insbesondere interagiert der OSA mit dem ASON 120 über die ASON-UNI, um verschiedene Kommunikationsdienste zu erreichen, und verwaltet diese Kommunikationsdienste für den Benutzer auf der Basis vorgegebener Parameter, die durch den Benutzer definiert wurden. Von der Architektur her liegt der OSA in einer Ebene oberhalb der ASON-UNI und verwendet die ASON-UNI zum Verwalten und Steuern der ASON-Kommunikationsdienste, die die ASON-Steuereinheit 340 bereitgestellt werden. Im Wesentlichen stellt der OSA damit erweiterte Kommunikationsdienste für den Benutzer bereit, der die von der ASON-UNI bereitgestellten „Steuerknöpfe" verwendet. Aus Gründen der Übersichtlichkeit wird ein Benutzer, der zum Verwalten von Kommunikationsdiensten einen OSA verwendet, im Weiteren als OSA-fähiger Benutzer bezeichnet.
6 zeigt einen OSA-fähigen Benutzer einschließlich eines eingebetteten OSA 610. Der OSA 610 implementiert anwendungsspezifische Dienste und Intelligenz sowie die ASON-UNI und andere Mechanismen zur Kommunikation mit der ASON-Steuereinheit 340 über die ASON-UNI. Der OSA 160 kommuniziert mit den Netzwerkverwaltungs- und -optimierungselementen 380 im ASON 120 über eine Netzwerkverwaltungsschnittstelle 620 (Netzwerk-NMI) und kommuniziert mit der ASON-Steuereinheit 340 im ASON-Gerät über die ASON-UNI 630, um Kommunikationsdienste vom ASON 120 zu erreichen, insbesondere durch Senden von Dienstandorderungen an die ASON-Steuereinheit 340 und Empfangen von Dienstantworten von der ASON-Steuereinheit 340. Der OSA 610 verwaltet die Kommunikationsdienste für den Benutzer auf der Basis von vorgegebenen Parametern, die vom Benutzer definiert wurden. Die ASON-Steuereinheit 340 liefert Netzwerkstatusinformationen an die Netzwerkverwaltungs- und -optimierungselemente 380 und empfängt Netzwerkaktualisierungen von den Netzwerkverwaltungs- und -optimierungselementen 380 über die ASON-NMI 370.
Der OSA 610 wird typischerweise in Software implementiert und kann plattformabhängig und plattformunabhängig implementiert werden. In einer plattformabhängigen OSA-Implementierung ist der OSA 610 speziell für eine bestimmte Plattform implementiert und ist typischerweise nicht auf andere Plattformen übertragbar. In einer plattformunabhängigen OSA-Implementierung ist der OSA 610 für die Zusammenarbeit mit mehreren Plattformen implementiert, zum Beispiel durch die Trennung plattformspezifischer Funktionen von den höheren Protokollen und Algorithmen und durch Implementieren der plattformspezifischen Funktionen getrennt von den höheren Protokollen und Algorithmen, so dass die höhere Protokoll-/Algorithmus-„Ebene" mit der plattformspezifischen „Ebene" für eine bestimmte Plattform verwendet werden kann. Die Eignung einer bestimmten Programmiersprache zur Implementierung des OSA 610 kann vom Typ der Implementierung (plattformabhängig oder plattformunabhängig) sowie von der Ausführungshäufigkeit des OSA 610 abhängen. Zum Beispiel kann eine Java-Implementierung für eine plattformunabhängige Implementierung geeignet sein, bei der der OSA 610 weniger häufig ausgeführt wird, während eine C++-Implementierung besser für plattformabhängige Implementierungen geeignet sein kann sowie für Anwendungen, bei denen der OSA 610 häufiger ausgeführt wird.
Unabhängig davon, ob der OSA 610 plattformabhängig oder plattformunabhängig implementiert wird, weist der OSA 610 typischerweise verschiedene vom Benutzer steuerbare und anpassbare Funktionen auf. Damit eine Benutzeranwendung auf diese vom Benutzer steuerbaren und anpassbaren Funktionen zugreifen kann, weist der OSA 610 typischerweise eine OSA-API (Application Program Interface – Anwendungsprogrammschnittstelle) auf, die verschiedene Grundelemente zum Zugriff auf die vom Benutzer steuerbaren und anpassbaren Funktionen des OSA 610 einschließt. Die OSA-API ist typischerweise einfacher als die ASON-UNI, insbesondere weil die OSA-API typischerweise eine interne Software-Schnittstelle ist, bei der nicht die Komplexitäten der ASON-UNI implementiert werden müssen (z. B. Mechanismen zur Kommunikation über einen UNI-Signalisierungskanal).
7 zeigt die Beziehung zwischen einer Benutzeranwendung 710 und dem OSA 610. Der OSA 610 bietet eine OSA-API, über die die Benutzeranwendung 710 auf den OSA 610 zugreifen kann. Die OSA-API enthält verschiedene Grundelemente zum Zugriff auf die vom Benutzer steuerbaren und anpassbaren Funktionen des OSA 610.
In einer typischen Ausführungsform des OSA 610 ist der OSA 610 in zwei Komponenten getrennt, das heißt, in eine Anwendungskomponente (im Weiteren als der OSA-A bezeichnet) und eine Netzwerkkomponente (im Weiteren als der OSA-N bezeichnet), Der OSA-A und der OSA-N kommunizieren über eine Steuerschnittstelle, die in Abhängigkeit von der Platzierung des OSA-N (weiter unten erläutert) die ASON-UNI oder eine andere Steuerschnittstelle sein kann.
Der OSA-A ist der Anwendungsteil des OSA 610. Der OSA-A implementiert anwendungsspezifische Dienste und Intelligenz. Weil der OSA-A so eng an die Benutzeranwendung gekoppelt ist, befindet sich der OSA-A typischerweise auf der Benutzerplattform im Randssystem. Der OSA-A verwaltet die Kommunikationsdienste im Auftrag des Benutzers, insbesondere durch das Anfordern von Kommunikationsdiensten vom ASON 120 über den OSA-N und das Zuordnen der Kommunikationsdienste vom ASON 120 zum Benutzernetzwerk oder zur Benutzeranwendung.
Der OSA-N ist das Netzwerkteil des OSA 610. Unter anderem stellt der OSA-N die Funktionalität für Benutzerauthentifizierung, -registrierung und -mitgliedschaft bereit, Die Authentifizierungsfunktionalität ermöglicht dem Netzwerk die Authentifizierung des Benutzers, um sicherzustellen, dass der Benutzer zum Zugriff auf die ASON-Kommunikationsdienste berechtigt ist. Die Registrierungsfunktionalität ermöglicht dem Benutzer das Registrieren einer Benutzerkennung im Netzwerk. Beispielsweise ist in einer ISP-Anwendung (Internet Service Provider) die Benutzerkennung typischerweise die Adresse des Routeranschlusses an das ASON-Gerät (d. h. die IP-Adresse der ASON-Steuereinheit und die Kennung des UNI-Steuerkanals), die als L1/L2-Adresse der Routerschnittstelle angezeigt werden können. Die Mitglied schaftsfunktionalität ermöglicht dem Benutzer das Beitreten zu einer Multicast-Gruppe zusammen mit anderen Peer-Benutzern des ASON 120. Der OSA-N kann sich auf der Benutzerplattform im Randsystem oder im ASON-Gerät am Rand des ASON 120 befinden.
8 zeigt die Beziehung zwischen dem OSA-A 810 und dem OSA-N 820. Der OSA-A implementiert anwendungsspezifische Dienste und Intelligenz zur Verwaltung von Kommunikationsdiensten im Auftrag des Benutzers. Der OSA-N stellt die Funktionalität für Benutzerauthentifizierung, -registrierung und -mitgliedschaft bereit. Der OSA-A und der OSA-N kommunizieren über die OSA-Steuerschnittstelle 830.
9 zeigt ein Beispielsystem, in dem der OSA-N 820 sich im OSA-fähigen Benutzer im Randsystem befindet. Insbesondere enthält der OSA-fähige Benutzer sowohl den OSA-A 810 als auch den OSA-N 820. Der OSA-A 810 und der OSA-N 820 kommunizieren über die OSA-Steuerschnittstelle 830. In diesem Fall handelt es sich bei der OSA-Steuerschnittstelle 830 typischerweise um eine Software-Schnittstelle zwischen den Komponenten OSA-A 810 und OSA-N 820. Der OSA-A 810 implementiert anwendungsspezifische Dienste und Intelligenz. Der OSA-N 820 stellt die Funktionalität für Benutzerauthentifizierung, -registrierung und -mitgliedschaft bereit und implementiert die ASON-UNI und andere Mechanismen zum Kommunizieren mit der ASON-Steuereinheit 340 im ASON-Gerät. Bei dieser Konfiguration kann der OSA-N 820 als ein Gerätetreiber für die spezifische UNI-Signalisierungskanalschnittstelle zwischen dem OSA-fähigen Benutzer und dem ASON-Gerät implementiert werden. Der OSA-A 810 kann über verschiedene Typen von UNI-Signalisierungskanälen verwendet werden, beispielsweise durch Installieren eines geeigneten OSA-N-Gerätetreibers, der den UNI-Signalisierungskanal für eine bestimmte Anwendung unterstützt.
10 zeigt ein Beispielsystem, in dem der OSA-N 820 sich im ASON-Gerät am Rand des ASON 120 befindet. Insbesondere enthält das ASON-Gerät den OSA-N 820 und die ASON-Steuereinheit 340. Der OSA-A 810 im OSA-fähigen Benutzer kommuniziert mit dem OSA-N 820 im ASON-Gerät über die ASON-UNI. Mit dem im ASON-Gerät befindlichen OSAN-N 820 kann das ASON-Gerät (d. h. der Dienstanbieter) dem OSA-fähigen Benutzer erweiterte Kommunikationsdienste bereitstellen, die durch den OSA-A 810 gesteuert werden.
11 zeigt ein Beispielsystem, in dem der OSA-N 820 sich außerhalb des OSA-fähigen Benutzers und des ASON-Geräts in einer Proxy-Anordnung befindet. In dieser Proxy-Anordnung ist es nicht erforderlich, dass der OSA-fähige Benutzer den ASON-UNI-Signalisierungskanal über den Trägerkanal 1110 unterstützt. Stattdessen kann ein separater Steuerkanal 830 für die Kommunikation zwischen dem OSA-A 810 im OSA-fähigen Benutzer und dem OSA-N 820 eingerichtet werden. Der OSA-A 810 sendet Anforderungen für ASON-Dienste zum OSA-N 820, und der OSA-N 820 führt die Anforderungen unter Verwendung der ASON-UNI aus. Eine derartige Proxybasierte OSA/UNI kann nützlich sein bei der Ausdehnung von ASON-Diensten auf ältere optische Randausrüstung.
Um den Service für seine Benutzer zu garantieren und die Integrität des optischen Kerns beizubehalten, muss das ASON 120 eine Sicherheits- und Authentifizierungsebene bereitstellen. Die Tatsache, dass es eine aktivierte physische Verbindung zwischen einem ASON-fähigen Benutzer und dem ASON-Gerät gibt, kann für den ASON-fähigen Benutzer bereits eine ausreichende Authentifizierung darstellen, um auf das ASON 120 zuzugreifen. Allerdings wird das ASON 120 mit steigender ASON-Nutzung und mit OSA-Einsatz die OSA-fähigen Benutzer authentifizieren müssen, sodass nur autorisierte OSA-fähige Benutzer in der Lage sind, auf das ASON 120 zuzugreifen. Daher wird das ASON 120 jeden OSA-fähigen Benutzer authentifizieren, der sich bei der ASON-Steuereinheit registriert.
In einer Ausführungsform wird zur Authentifizierung der OSA-fähigen Benutzer ein Authentifizierungsserver verwendet. Der Authentifizierungsserver ist typischerweise eine zentrale Datenbank, die ein Authentifizierungsprotokoll für die Authentifizierung verwendet. Das Authentifizierungsprotokoll kann eine Vielzahl von Authentifizierungstechniken verwenden, z. B. anfragebasierte Handshake-Authentifizierung oder einfache Authentifizierung auf der Basis von Benutzername und Passwort.
In einer anderen Ausführungsform verwendet jede ASON-Steuereinheit 340 eine öffentliche Schlüsseltechnologie (d. h. Authentifizierungszertifikate) zum Authentifizieren von OSA-fähigen Benutzern, die sich bei ihr registrieren. Dazu ist es erforderlich, dass der OSA die Authentifizierungszertifikate für den OSA-fähigen Benutzer verstehen und verwalten kann.
Die Datensicherheit ist eine benutzerbasierte Funktion, die am Rand des Enterprise-Netzwerks implementiert werden muss. Die OSA-Software muss nicht die Datenintegrität unterstützen.
Von der Architektur her kann die OSA-N-Funktionalität auf verschiedene Weise implementiert werden. Die Eignung einer bestimmten OSA-N-Architektur hängt von einer Reihe von Charakteristika ab, zum Beispiel von der Implementierungskomplexität, der Fehlertoleranz, der UNI-Bandbreitennutzung, der UNI-Signalisierungsverzögerung, der Speichernutzung und der Rechenkomplexität. Da sich der OSA-N in einer höheren Ebene befindet als die ASON-UNI, stellt die UNI-Bandbreitennutzung und die Signalisierungsverzögerung für die OSA-Signalisierung eine wichtige Überlegung dar. Die Latenz ist wichtig, weil sie sich auf den Typ der Anwendungen auswirkt, die der OSA unterstützen kann.
Hier werden mehrere Beispiel-OSA-N-Architekturen erläutert, konkret eine Client-Server-Architektur, eine verteilte Flutungsarchitektur, eine Hybrid/Proxy-Architektur und eine ASON-gekoppelte Architektur. Es muss jedoch darauf hingewiesen werden, dass die vorliegende Erfindung in keiner Weise auf eine der hier beschriebenen OSA-N-Implementierungen oder überhaupt auf eine bestimmte OSA-N-Implementierung beschränkt ist.
In der Client-Server-Architektur wird der Großteil der OSA-N-Funktionalität, einschließlich Authentifizierung, Registrierung und Gruppenmitgliedschaft durch einen optischen Service-Server (OSS) gehandhabt, wie das in 12 gezeigt wird. Der OSS führt Authentifizierungs-, Registrierungs- und Gruppenmitgliedschaftsinformationen für mehrere OSA-fähigen Geräte. Der OSA-fähige Benutzer ist typischerweise mit einer Gruppenkennung vorkonfiguriert. Wenn der OSA-fähige Benutzer mit dem ASON 120 verbunden wird, sendet der OSA-N eine Registrierungsmeldung an den OSS. Der OSA-N schließt seine Gruppenkennung in die Registrierungsmeldung ein. Der OSS speichert die Gruppenkennung in seiner Registrierungsdatenbank. Der OSA-N fragt den OSS ab, um Gruppenmitgliedschaftsinformationen zu erhalten, die die Identität und die Position von Peer-Benutzern enthalten.
13 ist ein Meldungs-Flussdiagramm zur Darstellung der verschiedenen Austausche zwischen dem OSA-N und dem OSS in der Client-Server-Architektur.
Der OSA-N sendet eine Registrierungsmeldung 1302 zum OSS, die die Gruppenkennung (ID) für den OSA-fähigen Benutzer enthält. Der OSS speichert die Gruppenkennung in seiner Registrierungsdatenbank. Der OSA-N sendet dann eine Abfragemeldung 1304 an den OSS, um Gruppenmitgliedschaftsinformationen zu erhalten, welche die Identität und die Position der Peer-Benutzer enthalten. Der OSS sendet Peer-Informationen 1306 an den OSA-N als Antwort auf die Abfrage 1304.
Die Client-Server-Architektur weist eine Anzahl von Charakteristika auf, die als Vorteile angesehen werden. Erstens lässt sich die Client-Server-Architektur relativ einfach implementieren. Zweitens ist der Betrag an Signalisierungsbandbreite (UNI und NNI) relativ klein, zum Teil weil die Gruppenmitgliedschaftsinformationen durch den OSS geführt und verteilt werden, weshalb es keine Notwendigkeit zum Advertisement von Gruppenmitgliedschaftsinformationen im Netzwerk gibt. Die Signalisierungsbandbreite kann weiter reduziert werden, indem man den OSA-N die vom OSS abgerufenen Gruppenmitgliedschaftsinformationen zwischenspeichern lässt und eine periodische Aktualisierungstechnologie verwendet, damit der Zwischenspeicher über aktuelle Daten verfügt.
Die Client-Server-Architektur weist eine Anzahl von Charakteristika auf, die als Nachteile angesehen werden. Erstens stellt der OSS einen Single Point of Failure (SPOF) dar, sodass das Netzwerk beim Ausfall des OSS keine Authentifizierungs-, Registrierungs- und Gruppenmitgliedschaftsfunktionen ausführen kann. Dieses Problem kann gemildert werden, indem ein „Backup"-OSS betrieben und ein Synchronisierungsprotokoll verwendet wird, zum Beispiel das SCSP (Server Cache Synchronization Protocol) gemäß RFC 2334, um die Synchronisation zwischen den Servern zu gewährleisten, obwohl dadurch die Implementierungskomplexität steigt. Zweitens hängt das Netzwerk – weil die Client-Server-Architektur serverbasiert ist – stark von der Verfügbarkeit, Zuverlässigkeit und Leistung des OSS ab, was zu einem Engpass für die Systemgesamtleistung werden kann, insbesondere unter dem Gesichtspunkt der Verzögerung. Drittens ist die Client-Server-Architektur wie andere Typen zentralisierter Lösungen nicht skalierbar. Viertens muss der OSA-fähige Benutzer manuell mit seiner Gruppenkennung konfiguriert werden, um beim OSS registriert werden zu können.
In der verteilten Flutungsarchitektur wird die Authentifizierung durch den OSS gehandhabt, wie das in 14 gezeigt wird. Der OSS führt Authentifizierungsinformationen für mehrere OSA-fähige Benutzer und führt auch eine Gruppenkennung für jeden OSA-fähigen Benutzer. Nach dem Authentifizieren eines OSA-fähigen Benutzers informiert der OSS den OSA-fähigen Benutzer über seine Gruppenkennung. Der OSA-fähige Benutzer informiert dann die anderen OSA-fähigen Benutzer im Netzwerk über seine Gruppenmitgliedschaft, insbesondere durch Flutung eines Advertisements über das Netzwerk, zum Beispiel in einer Weise ähnlich dem OSPF-TE- und PNNI-Augmented Routing. Diese Flutung erfolgt periodisch und übernimmt – da die Prozedur der von OSPF und PNNI ähnelt – die Vorteile von beiden Protokollen. Das LSA (Link State Advertisement) und die Nachbardatenbank werden nicht in der Netzwerkdomäne geführt, sondern in der Benutzerdomäne.
15 ist ein Meldungs-Flussdiagramm zur Darstellung der verschiedenen Austausche zwischen dem OSA-N und dem OSS in der verteilten Flutungsarchitektur. Der OSS authentifiziert den OSA-N durch eine Anzahl von Austauschen 1502. Nach der Authentifizierung des OSA-N ermittelt der OSS die Gruppenkennung (ID) für den OSA-fähigen Benutzer und sendet eine Gruppenkennung (ID) 1504 an den OSA-N. Der OSA-N sendet eine Advertisement-Meldung 1506 in das ASON. Die Advertisement-Meldung 1506 wird durch das gesamte Netzwerk geflutet.
Die verteilte Flutungsarchitektur weist eine Reihe von Charakteristika auf, die als Vorteile der verteilten Flutungsarchitektur angesehen werden. Erstens erlaubt sie eine zentralisierte Richtlinie hinsichtlich der Frage, welche OSA-fähigen Benutzer einer Gruppe beitreten können. Zweitens erfordert sie keine manuelle Konfiguration der Gruppenkennung und verwendet stattdessen den OSS zum Verteilen der Gruppenkennung im Anschluss an die Authentifizierung des OSA-fähigen Benutzers. Drittens ist sie gut für IP-Router-Endsysteme geeignet, da OSPF aufgrund von opaken LSAs (Link State Advertisements) ein erweiterungsfähiges IP-Protokoll ist.
Die verteilte Flutungsarchitektur weist eine Reihe von Charakteristika auf, die als Nachteile der verteilten Flutungsarchitektur angesehen werden. Erstens kann sich der OSA-fähige Benutzer nicht authentifizieren und seine Gruppenkennung nicht ermitteln, wenn der OSS außer Betrieb ist, sodass der OSA-fähige Benutzer dann nicht seine Peers automatisch ermitteln kann. Dieses Problem kann gemildert werden, indem die Peer-Informationen dem OSA-fähigen Benutzer manuell zur Verfügung gestellt werden, was das Herstellen von Verbindungen unter Verwendung des ASON ermöglichen würde. In dieser Hinsicht trennt die verteilte Flutungsarchitektur vorteilhafterweise den optischen Netzwerkbetrieb von der Verfügbarkeit des OSS und ermöglicht es dem OSA, den Großteil der Intelligenz zu besitzen. Zweitens verwendet der Flutungsmechanismus zusätzliche Bandbreite im ASON-Signalisierungsnetzwerk (UNI und NNI), was insbesondere dann problematisch sein kann, wenn die UNI nur eingeschränkte Bandbreite hat. Drittens erfolgt die Flutung erst, nachdem die Authentifizierung abgeschlossen ist. Viertens erfordert ein OSPF-basierter Flutungsmechanismus IP-Unterstützung und ist deshalb nicht für Nicht-IP-Router geeignet. Fünftens müssen – weil das LSA und die Nachbardatenbank nicht in der Netzwerkdomäne geführt werden, sondern in der Benutzerdomäne – topologische Informationen zum OSA-fähigen Benutzer „durchgelassen" werden, was durch Implementierung einer Form von NNI in der UNI erreicht werden kann, wodurch die Trennung zwischen der NNI und der UNI verwischt wird.
In der Hybrid/Proxy-Architektur werden Authentifizierung und Flutung durch den OSS gehandhabt, wie das in 16 gezeigt wird. Der OSS führt Authentifizierungsinformationen für mehrere OSA-fähigen Benutzer und führt auch eine Gruppenkennung für jeden OSA-fähigen Benutzer. Nach der Authentifizierung eines OSA-fähigen Benutzers flutet der OSS das Advertisement im Auftrag des OSA-fähigen Benutzers, zum Beispiel durch Verwenden eines Mechanismus ähnlich Proxy-PAR.
17 ist ein Meldungs-Flussdiagramm zur Darstellung der verschiedenen Austausche zwischen dem OSA-N und dem OSS in der Hybrid/Proxy-Architektur. Der OSS authentifiziert den OSA-N durch eine Anzahl von Austauschen 1702. Nach der Authentifizierung des OSA-N ermittelt der OSS die Gruppenkennung (ID) für den OSA-fähigen Benutzer und sendet eine Advertisement-Meldung 1706 in das ASON. Die Advertisement-Meldung 1706 wird durch das gesamte Netzwerk geflutet.
Die Hybrid/Proxy-Architektur ähnelt der verteilten Flutungsarchitektur und weist deshalb viele der vorteilhaften und nachteiligen Charakteristika wie auch die verteilte Flutungsarchitektur auf. Da jedoch nicht der OSA-N, sondern der OSS das Advertisement flutet, müssen vom OSS keine topologischen Informationen zum OSA-fähigen Benutzer „durchgelassen" werden. Deshalb gibt es keine Verwischung bei der Trennung zwischen der NNI und der UNI.
In der ASON-gekoppelten Architektur werden die verschiedenen unter Bezug auf die Client-Server-Architektur beschriebenen OSS-Dienste durch ASON-Geräte an der Peripherie des ASON 120 gehandhabt, wobei jedes ASON-Gerät als der OSS für sein direkt verbundenes OSA-fähiges Gerät agiert. Die ASON-gekoppelte Architektur weist viele Charakteristika auf, die als Vorteile der ASON-gekoppelten Architektur angesehen werden. Erstens hängt die Netzwerkleistung – weil es keinen zentralen Server gibt – nicht von der Verfügbarkeit und Zuverlässigkeit eines einzelnen Servers ab. Zweitens betrifft ein Ausfall des ASON-Geräts – weil ein ASON-Gerät immer nur seinen direkt verbundenen OSA-fähigen Benutzer bedient – nur das direkt verbundene OSA-fähige Gerät. Drittens ist die ASON-gekoppelte Architektur skalierbar, insbesondere aufgrund der Eins-zu-eins-Zuordnung zwischen Clients und Servern und auch weil das ASON-Gerät nur Advertisements für die Gruppe führen muss, die ihrem direkt verbundenen OSA-fähigen Benutzer zugeordnet ist. Viertens ist der Betrag an UNI-Signalisierungsbandbreite relativ gering. Fünftens kann das ASON-Gerät – weil die LSAs (Link State Advertisements) nicht in der Benutzerdomäne gespeichert werden, sondern durch das ASON-Gerät – einen Ausfall seines direkt verbundenen OSA-fähigen Benutzers erkennen und das LSA für den OSA-fähigen Benutzer ungültig machen, wodurch die Peer-Benutzer schneller den Ausfall des OSA-fähigen Benutzers erkennen können (ansonsten müssten die Peer-Benutzer auf die Zeitüberschreitung für ein LSA warten, um den Ausfall zu erkennen, wobei die Wartezeit im Fall von OSPF üblicherweise einer Maximaldauer (MaxAge) von 1 Stunde entspricht. Sechstens ist – weil das ASON-Gerät bereits ASON-spezifische OSPF ausführt – das Hinzufügen zusätzlicher LSAs in die Link-State-Datenbank relativ einfach. Siebtens gibt es eine klare Trennung zwischen der NNI und der UNI, weil keine topologischen Informationen zum OSA-fähigen Benutzer „durchgelassen" werden müssen. Achtens muss der OSA-fähige Benutzer nicht notwendigerweise OSPF implementieren, weil die LSAs durch das ASON-Gerät gehandhabt werden, was in bestimmten Anwendungen ein großer Vorteil sein kann.
Von den oben beschriebenen vier OSA-N-Implementierungsarchitekturen erscheint die ASON-gekoppelte Architektur für typische Anwendungen am besten geeignet, insbesondere aufgrund ihrer klar definierten Trennung von UNI und NNI, aufgrund der flexiblen Implementierungsplattformen und aufgrund der Einfachheit für Clientsysteme. OSA-A muss auf einer Fall-zu-Fall-Basis angepasst werden und erfordert eine Menge enger Zusammenarbeit mit dem Kunden.
Wie oben beschrieben wurde, implementiert sowohl der ASON-fähige Benutzer als auch der OSA-fähige Benutzer mindestens einen Teil der ASON-UNI-Funktionalität, um die Kommunikationsdienste vom ASON 120 zu erreichen. Der OSA-fähige Benutzer schließt zusätzlich den OSA 610 ein, um eine Vielzahl erweiterter Kommunikationsdienste vom ASON 610 unter Verwendung der ASON-UNI auszuführen.
Wie oben unter Bezug auf 5 gezeigt und beschrieben wurde, können zwei ASON-fähige Benutzer über das ASON 120 unter Verwendung der ASON-UNI kommunizieren. Allerdings sind die Typen der für die ASON-fähigen Benutzer verfügbaren Kommunikationsdienste im Wesentlichen auf solche Typen beschränkt, die direkt durch das ASON 120 bereitgestellt werden.
Andererseits kann ein OSA-fähiger Benutzer mit ASON-fähigen Benutzern und/oder mit anderen OSA-fähigen Benutzern über das ASON 120 zusammenwirken. Beim Zusammenwirken mit anderen OSA-fähigen Benutzern ist die End-to-End-Unterstützung eines vollständigen Sets von OSA-fähigen Funktionen über das ASON 120 möglich. Beim Zusammenwirken mit einem ASON-fähigen Benutzer, der keinen OSA unterstützt, ist nur die End-to-End-Unterstützung eines beschränkten Sets von Funktionen über das ASON 120 möglich (zum Beispiel das Einrichten eines optischen Kommunikationswegs über das ASON 120).
18 zeigt ein Beispiel-Kommunikationssystem 1800, in dem ein OSA-fähiger Benutzer 1810 mit einem ASON-fähigen Benutzer 1820 über das ASON 120 kommuniziert. Der ASON-fähige Benutzer 1820 implementiert einen Teil oder die gesamte ASON-UNI. Der OSA-fähige Benutzer 1810 implementiert erweiterte Funktionen unter Verwendung der ASON-UNI. Weil der ASON-fähige Benutzer 1820 keine OSA-Funktionalität implementiert, ist für den OSA-fähigen Benutzer 1810 und den ASON-fähigen Benutzer 1820 über das ASON 120 nur die End-to-End-Unterstützung eines begrenzten Sets an Funktionen möglich. Zum Beispiel können der OSA-fähige Benutzer 1810 und der ASON-fähige Benutzer 1820 einen optischen End-to-End-Kommunikationsweg für die Kommunikation über das ASON 120 einrichten.
19 zeigt ein Beispiel-Kommunikationssystem 1900, in dem zwei OSA-fähige Benutzer 1910, 1920 über das ASON 120 kommunizieren. Die OSA-fähigen Benutzer 1910, 1920 implementieren erweiterte Funktionen unter Verwendung der ASON-UNI. Da beide OSA-fähigen Benutzer 1910, 1920 die OSA-Funktionalität implementieren, ist für die OSA-fähigen Benutzer 1910, 1920 die End-to-End-Unterstützung eines vollständigen Sets an Funktionen über das gesamte ASON 120 möglich.
Um verschiedene Kommunikationsdienste zu verwalten, enthält der OSA 610 optische Service-Logik, die anwendungsspezifische Dienste und Intelligenz implementiert. Die optische Service-Logik interagiert mit dem ASON 120 über die ASON-UNI. Die optische Service-Logik interagiert über einen Peer-to-Peer-Signalisierungsmechanismus auch mit anderen OSA-fähigen Benutzern. Der Peer-to-Peer-Signalisierungsmechanismus ermöglicht die Kommunikation zwischen OSA-fähigen Benutzern innerhalb eines Benutzernetzwerks und/oder im gesamten ASON 120. Damit können OSA-fähige Benutzer innerhalb des Benutzernetzwerks unter Verwendung des Peer-to-Peer-Signalisierungsmechanismus über domäneninterne Signalisierungskanäle zusammenwirken, und OSA-fähige Benutzer am Rand des ASON 120 können über ASON-Signalisierungskanäle über das ASON 120 kommunizieren. Unter anderem erweitert der Peer-to-Peer-Signalisierungsmechanismus die OSA-Funktionalität effektiv auf OSA-fähige Benutzer, die sich nicht am Rand des ASON 120 befinden.
Es muss darauf hingewiesen werden, dass – während die OSA-fähigen Benutzer am Rand des ASON 120 die ASON-UNI implementieren und mit dem ASON 120 über die ASON-UNI interagieren – die OSA-fähigen Benutzer, die nicht an das ASON 120 angrenzen, nicht in der Lage sind, direkt mit dem ASON 120 über die ASON-UNI zu interagieren. Daher können solche OSA-fähigen Benutzer nicht direkt auf ASON-Dienste zugreifen. Solche OSA-fähigen Benutzer kanalisieren jedoch ASON-Dienstanforderungen über den Peer-to-Peer-Signalisierungsmechanismus durch den OSA-fähigen Benutzer am Rand des ASON 120. Insbesondere leitet ein OSA-fähiger Benutzer eine ASON-Dienstanforderung an einen OSA-fähigen Benutzer am Rand des ASON 120 mithilfe des Peer-to-Peer-Signalisierungsmechanismus weiter. Der OSA-fähige Benutzer am Rand des ASON 120 interagiert wiederum über die ASON-UNI mit dem ASON 120, um die ASON-Dienstanforderung auszuführen, und antwortet falls erforderlich unter Verwendung des Peer-to-Peer-Signalisierungsmechanismus.
Bestimmte Kommunikationsdienste können durch einen einzigen OSA-fähigen Benutzer verwaltet werden. Dagegen erfordern andere Kommunikationsdienste, dass eine Anzahl von OSA-fähigen Benutzern zusammenwirken, um die Kommunikationsdienste zu koordinieren. Das gilt insbesondere, wenn eine End-to-End-Koordinierung von Kommunikationsdiensten zwischen OSA-fähigen Peer-Benutzern über das ASON 120 erfolgt. Damit OSA-fähige Benutzer zusammenwirken können, muss jeder OSA-fähige Benutzer seine OSA-fähigen Peer-Benutzer identifizieren und verschiedene Typen von Peer-Informationen für jeden OSA-fähigen Peer-Benutzer erreichen, zum Beispiel eine Verbindungsadresse, die für die Einrichtung eines optischen Kommunikationswegs zum OSA-fähigen Peer-Benutzer verwendet wird. Deshalb enthält der OSA typischerweise Mechanismen zum Identifizieren von OSA-fähigen Peer-Benutzern und zum Erreichen der Peer-Informationen.
In einer typischen Ausführungsform der vorliegenden Erfindung enthält der OSA Auto-Erkennungslogik, mit der ein OSA-fähiger Benutzer automatisch seine OSA-fähigen Peer-Benutzer erkennt und die verschiedenen Typen von Peer-Informationen für jeden seiner OSA-fähigen Peer-Benutzer erreicht. Die Auto-Erkennungslogik verwendet typischerweise einen Advertisement-Mechanismus, um die Peer-Informationen zwischen den OSA-fähigen Benutzern auszutauschen, ähnlich dem Austauschen von LSAs (Link State Advertisements) durch OSPF, obwohl die Auto-Erkennungslogik nicht auf einen bestimmten Advertisement- oder Erkennungsmechanismus eingeschränkt ist. Jeder OSA-fähige Benutzer enthält typischerweise eine Peer-Datenbank, in der die Peer-Informationen gespeichert werden. Es muss darauf hingewiesen werden, dass die Peer-Informationen auch manuell konfiguriert werden können, zum Beispiel durch einen Netzwerkadministrator.
Zusätzlich zum Identifizieren der OSA-fähigen Peer-Benutzer ist es typischerweise für jeden OSA-fähigen Benutzer notwendig oder wünschenswert, seine Peers zu authentifizieren. Die Peer-Authentifizierung ist wichtig, weil sich OSA-Operationen unter anderem auf die Integrität des ASON 120 und des Netzwerks insgesamt auswirken können. Daher enthält der OSA typischerweise Peer-Authentifizerungslogik zum Authentifizieren von OSA-fähigen Peer-Benutzern. Die Peer-Authentifizierungslogik verwendet typischerweise öffentliche oder private Schlüsseltechnologien zur Authentifizierung, obwohl die Peer-Authentifizerungslogik nicht auf einen bestimmten Peer-Authentifizierungsmechanismus beschränkt ist.
20 zeigt die relevanten Komponenten des OSA 610. Unter anderem enthält der OSA 610 Netzwerkverwaltungslogik 2010, optische Service-Logik 2020, eine Peer-Datenbank 2030, Auto-Erkennungslogik 2040, die ASON-UNI 2050, Peer-to-Peer-Signalisierungslogik 2060 und Peer-Authentifizierungslogik 2070.
Die Netzwerkverwaltungslogik 2010 sorgt für die Konfiguration und Steuerung des OSA 610. Unter anderem nimmt die Netzwerkverwaltungslogik 2010 über die Netzwerkverwaltungsschnittstelle 620 Verbindung zu den Netzwerkverwaltungs- und -optimierungselementen 380 im ASON-Gerät auf und ermöglicht auch die Fernsteuerung des OSA 610 durch einen Netzwerkadministrator. Zum Beispiel kann der Netzwerkadministrator über die Netzwerkverwaltungslogik 2010 manuell Peer-Informationen in der Peer-Datenbank 2030 konfigurieren.
Die optische Service-Logik 2020 implementiert anwendungsspezifische Dienste und Intelligenz. Die optische Service-Logik 2020 interagiert mit dem ASON 120 über die ASON-UNI 2050. Die optische Service-Logik 2020 interagiert über die Peer-to-Peer-Signalisierungslogik 2060 auch mit anderen OSA-fähigen Benutzern. Die optische Service-Logik 2020 kann möglicherweise Peer-Informationen nutzen, die in der Peer-Datenbank 2030 gespeichert sind.
Die Peer-to-Peer-Signalisierungslogik 2060 ermöglicht dem OSA-fähigen Benutzer die Kommunikation mit anderen OSA-fähigen Benutzern innerhalb eines Benutzernetzwerks und/oder im gesamten ASON 120. Unter anderem erweitert der Peer-to-Peer-Signalisierungsmechanismus die OSA-Funktionalität effektiv auf OSA-fähige Benutzer, die sich nicht am Rand des ASON 120 befinden. Die Peer-to-Peer-Signalisierungslogik 2060 kann möglicherweise Peer-Informationen nutzen, die in der Peer-Datenbank 2030 gespeichert sind.
Die Auto-Erkennungslogik 2040 ermöglicht dem OSA-fähigen Benutzer das automatische Erkennen von OSA-fähigen Peer-Benutzern innerhalb eines Benutzernetzwerks und/oder im gesamten ASON 120. Die Auto-Erkennungslogik 2040 verwendet typischerweise einen Advertisement-Mechanismus zum Austauschen von Peer-Informationen zwischen OSA-fähigen Benutzern, ähnlich dem Austauschen von LSAs durch OSPF, obwohl die Auto-Erkennungslogik 2040 nicht auf einen bestimmten Advertisement- oder Erkennungsmechanismus beschränkt ist. Die Auto-Erkennungslogik 2040 speichert Peer-Informationen in der Peer-Datenbank 2030.
Die Peer-Authentifizierungslogik 2070 ermöglicht dem OSA-fähigen Benutzer die Authentifizierung von OSA-fähigen Peer-Benutzern. Die Peer-Authentifizierung ist wichtig, weil sich OSA-Operationen unter anderem auf die Integrität des ASON 120 und des Netzwerks insgesamt auswirken können. Die Peer-Authentifizierungslogik 2070 verwendet typischerweise öffentliche oder private Schlüsseltechnologien zur Authentifizierung, obwohl die Peer-Authentifizerungslogik 2070 nicht auf einen bestimmten Peer-Authentifizierungsmechanismus beschränkt ist. Die Peer-Authentifizierungslogik 2070 kann möglicherweise Peer-Informationen nutzen und speichern, die in der Peer-Datenbank 2030 gespeichert sind.
21 zeigt Beispiel-OSA-Logik 2100 zur Verwaltung von Kommunikationsdiensten. Beginnend bei Block 2102 erkennt die Logik in Block 2104 OSA-fähige Peer-Benutzer mithilfe eines vorgegebenen Auto-Erkennungsmechanismus. Die Logik authentifiziert dann in Block 2106 die OSA-fähigen Peer-Benutzer mithilfe eines vorgegebenen Peer-Authentifizierungsmechanismus. Dann wirkt die Logik in Block 2108 mit den OSA-fähigen Peer-Benutzern zusammen, um Kommunikationsdienste zu verwalten und zu koordinieren. Die Logik 2100 endet in Block 2199.
In einer Beispielausführungsform der vorliegenden Erfindung wird ein authentifizierter Auto-Erkennungsmechanismus, der sowohl die Auto-Erkennung als auch die Peer-Authentifizierung kombiniert, zum automatischen Identifizieren und Authentifizieren von OSA-fähigen Peer-Benutzern verwendet. Der authentifizierte Auto-Erkennungsmechanismus setzt voraus, dass jeder OSA-fähige Benutzer sich mithilfe eines authentifizierten Registrierungsmechanismus beim ASON registriert. Ein vom OSS verwaltetes zentralisiertes Advertisement-Schema wird verwendet, um Peer-Informationen zu sammeln und an die OSA-fähigen Peer-Benutzer zu verteilen, die einer bestimmten Peer-Gruppe zugeordnet sind. Jeder OSA-fähige Benutzer führt die vom OSS empfangenen Peer-Informationen in seiner Peer-Datenbank.
Konkret heißt das: Wenn ein OSA-fähiger Benutzer auf das ASON zugreifen muss, richtet er zuerst die ASON-UNI mit einem entsprechenden ASON-Gerät am Rand des ASON ein und aktiviert sie. Der OSA-fähige Benutzer registriert sich dann beim ASON durch Senden einer Registrierungsmeldung an das ASON-Randgerät. Die Registrierungsmeldung enthält unter anderem eine Gruppenkennung, mit der die Peer-Gruppe für den OSA-fähigen Benutzer identifiziert wird.
Bei Empfang der Registrierungsmeldung vom OSA-fähigen Benutzer sendet das ASON-Randgerät eine Abfragemeldung an den OSA-fähigen Benutzer. Die Abfragemeldung bietet dem OSA-fähigen Benutzer eine Möglichkeit, sich beim ASON positiv zu identifizieren, wozu ein kryptografischer Authentifizierungsmechanismus verwendet wird, zum Beispiel unter Verwendung vorgegebener öffentlicher und/oder privater Schlüsseltechnologien.
Bei Empfang der Abfragemeldung vom ASON-Randgerät formatiert der OSA-fähige Benutzer eine Abfrageantwortmeldung. Die Abfrageantwortmeldung identifiziert den OSA-fähigen Benutzer positiv beim ASON-Gerät mithilfe der kryptografischen Authentifizierungsmeldung. Der OSA-fähige Benutzer sendet die Abfrageantwortmeldung an das ASON-Randgerät.
Bei Empfang der Abfrageantwortmeldung vom OSA-fähigen Benutzer authentifiziert das ASON-Randgerät die Informationen in der Abfrageantwortmeldung, um den OSA-fähigen Benutzer zu verifizieren und positiv zu identifizieren. Diese Authentifizierung kann möglicherweise ein Interagieren mit anderen Netzwerkelementen erfordern, zum Beispiel mit einer Zertifizierungsstelle für die öffentliche Schlüsselauthentifizierung oder das Abrufen eines Verschlüsselungsschlüssels von einem sicheren Server (möglicherweise dem OSS) für die private Schlüsselauthentifizierung. Wenn das ASON-Randgerät den OSA-fähigen Benutzer durch die in der Abfrageantwortmeldung gelieferten Informationen verifizieren und positiv authentifizieren kann, sendet das ASON-Randgerät eine Erfolgsmeldung an den OSA-fähigen Benutzer, um anzuzeigen, dass der Registrierungsprozess abgeschlossen ist. Ansonsten, d. h. wenn das ASON-Randgerät den OSA-fähigen Benutzer durch die in der Abfrageantwortmeldung gelieferten Informationen nicht verifizieren und positiv authentifizieren kann, lehnt das ASON-Randgerät die Registrierung ab, beispielsweise durch Senden einer Ablehnungsmeldung an den OSA-fähigen Benutzer.
Bei erfolgreicher Registrierung des OSA-fähigen Benutzers sendet das ASON-Randgerät auch eine Beitrittsmeldung an den OSS, um den OSA-fähigen Benutzer zu dessen Peer-Gruppe hinzuzufügen. Die Beitrittsmeldung enthält unter anderem eine Gruppenkennung zum Identifizieren der Peer-Gruppe, eine Benutzerkennung zum Identifizieren des OSA-fähigen Benutzers und eine Trägerkennung zur Identifizierung des Trägerkanals, der dem OSA-fähigen Benutzer zugeordnet ist.
Der OSS führt Gruppenmitgliedschaftsinformationen für die verschiedenen OSA-fähigen Benutzer, die sich im ASON registriert haben. Bei Empfang der Beitrittsmeldung vom ASON-Randgerät speichert der OSS die Gruppenmitgliedschaftsinformationen für den neuen OSA-fähigen Benutzer, der in der Beitrittsmeldung identifiziert wurde. Wenn der neue OSA-fähige Benutzer der erste Benutzer ist, der sich in der betreffenden Peer-Gruppe registriert, sendet der OSS eine Datenbanksynchronisierungsmeldung an das ASON-Randgerät, in der keine OSA-fähigen Peer-Benutzer aufgelistet sind (d. h. eine NULL-Liste). Wenn jedoch der neue OSA-fähige Benutzer nicht der erste Benutzer ist, der sich in der betreffenden Peer-Gruppe registriert, sendet der OSS eine Datenbanksynchronisierungsmeldung an das ASON-Randgerät, in der die anderen OSA-fähigen Peer-Benutzer aufgelistet sind, und sendet außerdem eine Advertisement-Meldung an die verschiedenen ASON-Geräte, die registrierte OSA-fähige Benutzer unterstützen, in der mindestens der neue OSA-fähige Benutzer aufgelistet ist.
Bei Empfang der Datenbanksynchronisierungsmeldung vom OSS ermittelt das ASON-Randgerät, ob in der Datenbanksynchronisierungsmeldung irgendwelche OSA-fähigen Peer-Benutzer aufgelistet sind. Wenn in der Datenbanksynchronisierungsmeldung mindestens ein OSA-fähiger Peer-Benutzer aufgelistet ist, sendet das ASON-Randgerät eine Neuer-Nachbar-Meldung an den OSA-fähigen Benutzer, in der die OSA-fähigen Peer-Benutzer und ihre jeweiligen Trägerkennungen aufgelistet sind. Wenn jedoch in der Datenbanksynchronisierungsmeldung keine OSA-fähigen Peer-Benutzer aufgelistet sind (d. h. die Liste eine NULL-Liste ist), sendet das ASON-Randgerät typischerweise nicht die Neuer- Nachbar-Meldung an den OSA-fähigen Benutzer, da die vom OSA-fähigen Benutzer geführte Peer-Datenbank standardmäßig NULL ist.
Jedes ASON-Gerät, das vom OSS eine Advertisement-Meldung empfängt, sendet eine Neuer-Nachbar-Meldung an seinen jeweiligen OSA-fähigen Benutzer, die eine Liste der OSA-fähigen Peer-Benutzer aus der Advertisement-Meldung enthält. Die Neuer-Nachbar-Meldung identifiziert den neuen OSA-fähigen Benutzer gegenüber allen vorhandenen OSA-fähigen Benutzern in der Peer-Gruppe.
Bei Empfang einer Neuer-Nachbar-Meldung von seinem entsprechenden ASON-Gerät speichert ein OSA-fähiger Benutzer die Peer-Informationen aus der Neuer-Nachbar-Meldung in seiner Peer-Datenbank.
Wenn sich anschließend ein neuer OSA-fähiger Benutzer bei der Peer-Gruppe registriert, sendet der OSS eine Advertisement-Meldung an solche ASON-Geräte, die registrierte OSA-fähige Geräte in der Peer-Gruppe unterstützen. Die Advertisement-Meldung identifiziert mindestens den neuen OSA-fähigen Benutzer und seine Trägerkennung (Träger-ID) und kann außerdem einige oder alle der anderen OSA-fähigen Peer-Benutzer und ihre jeweiligen Trägerkennungen auflisten. Jedes ASON-Gerät, das eine Advertisement-Meldung vom OSS erhält, sendet eine Neuer-Nachbar-Meldung an seinen jeweiligen OSA-fähigen Benutzer, in der die OSA-fähigen Peer-Benutzer und ihre jeweiligen Trägerkennungen aufgelistet sind. Jeder OSA-fähigen Benutzer, der eine Neuer-Nachbar-Meldung von seinem entsprechenden ASON-Gerät empfängt, speichert die Peer-Informationen in seiner Peer-Datenbank.
22 ist ein Meldungs-Flussdiagramm zur Veranschaulichung eines authentifizierten Auto-Erkennungsprozesses zwischen einem OSA-fähigen Benutzer A und einem OSA-fähigen Benutzer B. Der OSA-fähige Benutzer A greift über das ASON-Gerät O1 auf das ASON zu. Der OSA-fähige Benutzer B greift über das ASON-Gerät O2 auf das ASON zu. In diesem Beispiel wird angenommen, dass der OSA-fähige Benutzer A der erste Benutzer ist, der sich in der Peer-Gruppe G registriert, und dass der OSA-fähige Benutzer B der zweite Benutzer ist, der sich in der Peer-Gruppe G registriert.
Um sich im ASON zu registrieren, sendet der OSA-fähige Benutzer A eine Registrierungsmeldung 2202 an das ASON-Gerät O1, in der die Peer-Gruppe G angegeben wird. Das ASON-Gerät O1 sendet die Abfragemeldung 2204 an den OSA-fähigen Benutzer A. Der OSA-fähige Benutzer A sendet die Abfrageantwortmeldung 2206 an das ASON-Gerät O1. Das ASON-Gerät O1 sendet die Erfolgsmeldung 2208 an den OSA-fähigen Benutzer A und sendet außerdem die Beitrittsmeldung 2210 an den OSS, die die Gruppenkennung für die Peer-Gruppe G, die Benutzerkennung für den OSA-fähigen Benutzer A sowie die Trägerkennung (Anmerkung des Übersetzers: Die Trägerkennung wird in der Zeichnung fälschlicherweise mehrfach als Träger-IP bezeichnet, es müsste wohl Träger-ID heißen) für den Trägerkanal zum OSA-fähigen Benutzer A enthält. Der OSS sendet die Datenbanksynchronisierungsmeldung (DBsync) 2212 an das ASON-Gerät O1 mit einer NULL-Liste der OSA-fähigen Peer-Benutzer. Das ASON-Gerät O1 sendet keine Neuer-Nachbar-Meldung an den OSA-fähigen Benutzer A.
Um sich im ASON zu registrieren, sendet der OSA-fähige Benutzer B eine Registrierungsmeldung 2214 an das ASON-Gerät O2, in der die Peer-Gruppe G angegeben wird. Das ASON-Gerät O2 sendet die Abfragemeldung 2216 an den OSA-fähigen Benutzer B. Der OSA-fähige Benutzer B sendet die Abfrageantwortmeldung 2218 an das ASON-Gerät O2. Das ASON-Gerät O2 sendet die Erfolgsmeldung 2220 an den OSA-fähigen Benutzer B und sendet außerdem die Beitrittsmeldung 2222 an den OSS, die die Gruppenkennung für die Peer-Gruppe G, die Benutzerkennung für den OSA-fähigen Benutzer B sowie die Trägerkennung für den Trägerkanal zum OSA-fähigen Benutzer B enthält. Der OSS sendet die Datenbanksynchronisierungsmeldung (DBsync) 2228 an das ASON-Gerät O2 mit einer Liste, die den OSA-fähigen Benutzer A als OSA-fähigen Peer-Benutzer enthält und sendet auch eine Advertisement-Meldung 2226 an das ASON-Gerät O1, in der der OSA-fähige Benutzer B als neuer OSA-fähige Peer-Benutzer angegeben wird. Das ASON-Gerät O1 sendet die Neuer-Nachbar-Meldung 2224 an den OSA-fähigen Benutzer A, die Peer-Informationen für den OSA-fähigen Benutzer B enthält, und der OSA-fähige Benutzer A fügt den OSA-fähigen Benutzer B zu seiner Peer-Datenbank hinzu. Das ASON-Gerät O2 sendet die Neuer-Nachbar-Meldung 2230 an den OSA-fähigen Benutzer B, die Peer-Informationen für den OSA-fähigen Benutzer A enthält, und der OSA-fähige Benutzer B fügt den OSA-fähigen Benutzer A zu seiner Peer-Datenbank hinzu. An dieser Stelle hat der OSA-fähige Benutzer A den OSA-fähigen Benutzer B erfolgreich identifiziert und authentifiziert, und der OSA-fähige Benutzer B hat den OSA-fähigen Benutzer A erfolgreich identifiziert und authentifiziert.
Jedes ASON-Gerät überwacht die Verbindung zu seinem entsprechenden OSA-fähigen Benutzer. Wenn das ASON-Gerät einen Verlust oder eine Verschlechterung der Verbindung zum OSA-fähigen Benutzer erkennt (z. B. aufgrund eines Ausfalls der ASON-UNI, des Trägerkanals oder des OSA-fähigen Geräts selbst), sendet das ASON-Gerät eine Verlassen-Meldung an den OSS, um den OSA-fähigen Benutzer aus der Peer-Gruppe zu entfernen. Der OSS entfernt den OSA-fähigen Benutzer aus der Peer-Gruppe und sendet eine Advertisement-Meldung an die verschiedenen ASON-Geräte, die registrierte OSA-fähige Benutzer unterstützen, in der die entfernten OSA-fähigen Benutzer angegeben werden. Daraufhin sendet jedes ASON-Gerät eine Aktualisierungsmeldung an seinen entsprechenden OSA-fähigen Benutzer, in der der entfernte OSA-fähige Benutzer angegeben wird. Jeder OSA-fähige Benutzer löscht den entfernten OSA-fähigen Benutzer aus seiner jeweiligen Peer-Datenbank.
23 ist ein Meldungs-Flussdiagramm zur Veranschaulichung des Ablaufs beim Entfernen eines OSA-fähigen Benutzers aus einer Peer-Gruppe. Beim Erkennen des Verlusts oder der Verschlechterung der Verbindung zum OSA-fähigen Benutzer, der hier durch 2302 gekennzeichnet ist, sendet das ASON-Gerät O1 die Verlassen-Meldung 2304 an den OSS. Der OSS entfernt das OSA-fähige Gerät A aus der Peer-Gruppe und sendet die Advertisement-Meldung 2306 an das ASON-Gerät O2. Das ASON-Gerät O2 sendet die Aktualisierungsmeldung 2308 an den OSA-fähigen Benutzer B, in der angegeben wird, dass der OSA-fähige Benutzer A kein Mitglied der Peer-Gruppe mehr ist, und der OSA-fähige Benutzer B entfernt den OSA-fähigen Benutzer A aus einer Peer-Datenbank.
Es muss darauf hingewiesen werden, dass es beim Interagieren eines OSA-fähigen Benutzers mit einem ASON-fähigen Benutzer, wie das unter Bezug auf 18 oben gezeigt und beschrieben wurde, im Wesentlichen keine Peer-to-Peer-Beziehung zwischen dem OSA-fähigen Benutzer und dem ASON-fähigen Benutzer gibt. Konsequenterweise stehen viele der Peer-to-Peer-Mechanismen des OSA nicht für das Zusammenwirken zwischen dem OSA-fähigen Benutzer und dem ASON-fähigen Benutzer zur Verfügung. Insbesondere unterstützt der ASON-fähige Benutzer nicht die OSA-Mechanismen für Auto-Erkennung, Peer-Authentifizierung und Peer-to-Peer-Signalisierung. Deshalb kann der OSA-fähige Benutzer typischerweise den ASON-fähigen Benutzer nicht automatisch erkennen, ihn nicht authentifizieren und keine Peer-to-Peer-Signalisierung mit ihm durchführen. Das hat bestimmte praktische Implikationen. Zum Beispiel wäre ein ASON-fähiger Benutzer, der eine Anfrage von einem OSA-fähigen Benutzer empfängt, nicht in der Lage, den OSA-fähigen Benutzer zu authentifizieren und müsste deshalb die Anfrage im Allgemeinen bedingungslos akzeptieren. Dies stellt jedoch ein Sicherheits-/Zuverlässigkeitsrisiko dar, das in einigen Situationen inakzeptabel sein kann.
Es muss auch darauf hingewiesen werden, dass optische Kommunikationsdienste durch mehrere Dienst- und Infrastrukturanbieter zur Verfügung gestellt werden können. Der OSA kann die Kommunikationsdienste verwalten, die von diesen mehreren Dienst- und Infrastrukturanbietern zur Verfügung gestellt werden.
Wie oben erläutert wurde, ist der OSA ein intelligenter Agent, der verschiedene Kommunikationsdienste im Auftrag des Netzwerkbenutzers verwaltet. Der OSA interagiert mit dem ASON, um verschiedene Kommunikationsdienste zu erreichen und verwaltet diese Dienste für den Netzwerkbenutzer auf der Basis von vorgegebenen Parametern, die durch den Netzwerkbenutzer definiert wurden. Der OSA kann praktisch alle Kommunikationsdienste verwalten, die bisher manuell verwaltet wurden.
Es muss darauf hingewiesen werden, dass der Begriff „Router" hier verwendet wird, um ein Kommunikationsgerät zu beschreiben, das in einem Kommunikationssystem verwendet werden kann, und nicht in einer Weise ausgelegt werden soll, der die vorliegende Erfindung auf einen bestimmten Kommunikationsgerätetyp einschränkt. Damit kann es sich bei einem Kommunikationsgerät unter anderem, jedoch nicht darauf beschränkt, um eine Brücke, einen Router, einen Brücken-Router (Brouter), einen Schalter, einen Knoten oder um ein anderes Kommunikationsgerät handeln.
Es muss auch darauf hingewiesen werden, dass der Begriff „Paket" hier verwendet wird, um eine Kommunikationsmeldung zu beschreiben, die von einem Kommunikationsgerät verwendet werden kann (z. B. durch das Kommunikationsgerät erstellt, übertragen, empfangen, gespeichert oder verarbeitet) oder durch ein Kommunikationsmedium transportiert werden kann, und nicht in einer Weise ausgelegt werden soll, die die vorliegende Erfindung auf einen bestimmten Kommunikationsmeldungstyp, ein bestimmtes Kommunikationsmeldungsformat oder ein bestimmtes Kommunikationsmeldungsprotokoll einschränkt. Damit kann es sich bei einem Kommunikationsgerät unter anderem, jedoch nicht darauf beschränkt, um einen Frame, ein Paket, ein Datagramm, ein Benutzerdatagramm, eine Zelle oder um einen anderen Typ von Kommunikationsmeldung handeln.
Es muss auch darauf hingewiesen werden, dass die Logik-Flussdiagramme hier verwendet werden, um verschiedene Aspekte der Erfindung zu veranschaulichen, und nicht in einer Weise ausgelegt werden sollen, die die vorliegende Erfindung auf einen bestimmten Logik-Fluss oder auf eine bestimmte Logik-Implementierung einschränkt. Die beschriebenen Logik kann in verschiedene Logik-Blöcke partitioniert sein (z. B. Programme, Module, Funktionen oder Unterroutinen), ohne die Gesamtergebnisse zu verändern oder anderweitig den eigentlichen Umfang der Erfindung zu verlassen. Oftmals können Logik-Elemente hinzugefügt, modifiziert, weggelassen, in anderer Reihenfolge ausgeführt oder unter Verwendung anderer logischer Grundelemente (z. B. logische Gatter, Schleifen-Grundelemente, bedingte Logik und andere Logik-Grundelemente) implementiert werden, ohne dass dadurch die Gesamtergebnisse verändert oder anderweitig der eigentliche Umfang der Erfindung verlassen wird.
Die vorliegende Erfindung kann in vielen unterschiedlichen Formen ausgeführt werden, einschließlich, jedoch in Keiner Weise darauf beschränkt, in Form von Computerprogrammlogik zur Verwendung mit einem Prozessor (z. B. einem Mikroprozessor, Mikrocontroller, digitalen Signalprozessor oder einem Allzweckcomputer), in Form von programmierbarer Logik zur Verwendung mit einem programmierbaren Logikelement (Programmable Logic Device – PLD) (z. B. einem FPGA (Field Programmable Gate Array – frei programmierbares Verknüpfungsfeld) oder einem anderen PLD), in Form von diskreten Bauelementen, in Form von integrierten Schaltungen (z. B. anwendungsspezifischen integrierten Schaltungen (Application Specific Integrated Circuitry – ASIC)) oder in jeder anderen Form und einschließlich jeder Kombination daraus. In einer typischen Ausführungsform der vorliegenden Erfindung wird überwiegend die gesamte OSA-Logik als ein Set von Computerprogrammanweisungen implementiert, das in eine computerausführbare Form konvertiert, als solches auf einem computerlesbaren Medium gespeichert und durch einen Mikroprozessor innerhalb des OSA-fähigen Benutzer unter Steuerung eines Betriebssystems ausgeführt wird.
Die Computerprogrammlogik zur Implementierung der gesamten oder eines Teils der hier beschriebenen Funktionalität kann in verschiedenen Formen ausgeführt werden, einschließlich, jedoch in keiner Weise darauf beschränkt, in eine Quellcode-Form, in einer computerausführbaren Form und in verschiedenen Zwischenformen (z. B. Formen, die von einem Assembler, Compiler, Linker oder Lokalisierer generiert werden). Der Quellcode kann eine Reihe von Computerprogrammanweisungen einschließen, die in jeder von verschiedenen Programmiersprachen (z. B. in einem Objektcode, in einer Assemblersprache oder einer höheren Programmiersprache wie Fortran, C, C++, JAVA oder HTML) implementiert werden, die mit verschiedenen Betriebssystemen oder Betriebsumgebungen verwendet werden können. Der Quellcode kann verschiedene Datenstrukturen und Kommunikationsmeldungen definieren und verwenden. Der Quellcode kann in einer computerausführbaren Form (z. B. über einen Interpreter) vorliegen, oder der Quellcode kann in eine computerausführbare Form konvertiert werden (z. B. über einen Umsetzer, Assembler oder Compiler).
Das Computerprogramm kann in jeder Form (z. B. in Quellcode-Form, in computerausführbarer Form oder in einer Zwischenform) entweder permanent oder transitorisch in einem greifbaren Speichermedium fixiert sein, zum Beispiel in einem Halbleiterspeicherelement (z. B. in einem RAM, ROM, PROM, EEPROM oder Flashprogrammierbaren RAM), in einem Magnetspeichergerät (z. B. auf einer Diskette oder Festplatte), in einem optischen Speichergerät (z. B. auf einer CD-ROM), auf einer PC-Karte (z. B. auf einer PCMCIA-Karte) oder auf einem anderen Speichergerät. Das Computerprogramm kann in jeder Form in einem Signal fixiert werden, das zu einem Computer übertragen werden kann, wozu verschiedenste Kommunikationstechnologien verwendet werden können, einschließlich, jedoch in keiner Weise darauf beschränkt, Analogtechnologien, Digitaltechnologien, optische Technologien, Drahtlos-Technologien (z. B. Bluetooth), Netzwerktechnologien und netzwerkübergreifende Technologien. Die Verteilung des Computerprogramms kann in jeder Form als Wechselspeichermedium mit begleitender gedruckter oder elektronischer Dokumentation (z. B. in Schrumpffolienverpackung), vorgeladen auf ein Computersystem (z. B. im System-ROM oder auf der Festplatte) oder von einem Server oder einem Electronic Bulletin Board aus über das Kommunikationssystem (z. B. über das Internet oder World Wide Web) erfolgen.
Die Hardware-Logik (einschließlich der programmierbaren Logik zur Verwendung mit einem programmierbaren Logikelement) zur Implementierung der gesamten oder eines Teils der zuvor beschriebenen Funktionalität kann unter Verwendung traditioneller manueller Methoden entworfen werden oder kann elektronisch unter Verwendung verschiedener Hilfsmittel wie zum Beispiel Computer Aided Design (CAD), einer Hardware-Beschreibungssprache (z. B. VHDL oder AHDL) oder einer PLD-Programmiersprache (z. B. PALASM, ABEL oder CUPL) entworfen, erfasst, simuliert oder dokumentiert werden.
Die programmierbare Logik kann entweder permanent oder transitorisch in einem greifbaren Speichermedium fixiert sein, zum Beispiel in einem Halbleiterspeicherelement (z. B. in einem RAM, ROM, PROM, EEPROM oder Flash-programmierbaren RAM), in einem Magnetspeichergerät (z. B. auf einer Diskette oder Festplatte), in einem optischen Speichergerät (z. B. auf einer CD-ROM) oder auf einem anderen Speichergerät. Die programmierbare Logik kann in einem Signal fixiert werden, das zu einem Computer übertragen werden kann, wozu verschiedenste Kommunikationstechnologien verwendet werden können, einschließlich, jedoch in keiner Weise darauf beschränkt, Analogtechnologien, Digitaltechnologien, optische Technologien, Drahtlos-Technologien (z. B. Bluetooth), Netzwerktechnologien und netzwerkübergreifende Technologien. Die Verteilung der programmierbaren Logik kann als Wechselspeichermedium mit begleitender gedruckter oder elektronischer Dokumentation (z. B. in Schrumpffolienverpackung), vorgeladen auf ein Computersystem (z. B. im System-ROM oder auf der Festplatte) oder von einem Server oder einem Electronic Bulletin Board aus über das Kommunikationssystem (z. B. über das Internet oder World Wide Web) erfolgen.
Die vorliegende Erfindung kann anderen spezifischen Formen ausgeführt werden, ohne dass dabei der eigentliche Umfang der Erfindung verlassen wird. Die beschriebenen Ausführungsformen sind in allen Aspekten lediglich als beispielhaft und nicht als einschränkend zu betrachten.

Claims

Ein optischer Service-Agent (610) zur Verwaltung von Kommunikationsdiensten für einen Benutzer (110, 130) in einem optischen Kommunikationssystem (120), wobei der optische Service-Agent umfasst: eine Benutzernetzwerkschnittstelle (630) (User to Network Interface – UNI) als Schnittstelle zu einem optischen Kommunikationsnetzwerk (120); und optische Service-Logik (2020) zum Erreichen optischer Kommunikationsdienste vom optischen Kommunikationsnetzwerk über die UNI (630) und zum Verwalten der optischen Kommunikationsdienste für den Benutzer; wobei der optische Service-Agent (610) dadurch gekennzeichnet ist, dass er des Weiteren umfasst: Auto-Erkennungslogik (2040) zum automatischen Erkennen von Peer-Benutzern; Peer-to-Peer-Signalisierungslogik (2060) zum Kommunizieren mit Peer-Benutzern; wobei die optische Service-Logik (2020) so ausgelegt ist, dass sie Kommunikationsdienste über die Peer-to-Peer-Signalisierungslogik (2060) mit Peer-Benutzern koordiniert.
Der optische Service-Agent (610) gemäß Anspruch 1, wobei dieser des Weiteren Peer-Authentifizierungslogik (2070) zum Authentifizieren von Peer-Benutzern umfasst.
Der optische Service-Agent (610) gemäß Anspruch 1 oder Anspruch 2, wobei die Auto-Erkennungslogik (2040) einen Advertisement-Mechanismus zum Senden und Empfangen von Peer-Informationen umfasst.
Ein Gerät (110, 130), umfassend: eine Benutzeranwendung (710), die so ausgelegt ist, dass sie Kommunikationsdienste von einem optischen Kommunikationsnetzwerk (120) anfordert; und einen optischen Service-Agent (610), umfassend: optische Service-Logik (2020) zum Erreichen optischer Kommunikationsdienste vom optischen Kommunikationsnetzwerk über eine Benutzernetzwerkschnittstelle (630) (User to Network Interface – UNI) als Schnittstelle zu dem optischen Kommunikationsnetzwerk (120) und zum Verwalten der optischen Kommunikationsdienste für die Benutzeranwendung (710); dadurch gekennzeichnet, dass der optische Service-Agent (610) des Weiteren umfasst: Auto-Erkennungslogik (2040) zum automatischen Erkennen von Peer-Benutzern; Peer-to-Peer-Signalisierungslogik (2060) zum Kommunizieren mit Peer-Benutzern; wobei die optische Service-Logik (2020) so ausgelegt ist, dass sie Kommunikationsdienste über die Peer-to-Peer-Signalisierungslogik (2060) mit Peer-Benutzern koordiniert.
Das Gerät (110, 130) gemäß Anspruch 4, wobei der optische Service-Agent (610) des Weiteren Peer-Authentifizierungslogik (2070) zum Authentifizieren von Peer-Benutzern umfasst.
Das Gerät (110, 130) gemäß Anspruch 4 oder Anspruch 5, wobei die Auto-Erkennungslogik (2040) einen Advertisement-Mechanismus zum Senden und Empfangen von Peer-Informationen umfasst.
Ein System, umfassend: ein optisches Kommunikationsnetzwerk (120) und einen ersten Netzwerkbenutzer (110), der an das optische Kommunikationsnetzwerk gekoppelt ist, wobei der erste Netzwerkbenutzer (110) einen optischen Service-Agent (610) umfasst, wobei der optische Service-Agent umfasst: optische Service-Logik (2020) zum Erreichen optischer Kommunikationsdienste vom optischen Kommunikationsnetzwerk über eine Benutzernetzwerkschnittstelle (630) (User to Network Interface – UNI) als Schnittstelle zu dem optischen Kommunikationsnetzwerk (120) und zum Verwalten der optischen Kommunikationsdienste für die Benutzeranwendung (710); dadurch gekennzeichnet, dass der optische Service-Agent (610) des Weiteren umfasst: Auto-Erkennungslogik (2040) zum automatischen Erkennen von Peer-Benutzern; Peer-to-Peer-Signalisierungslogik (2060) zum Kommunizieren mit Peer-Benutzern; wobei die optische Service-Logik (2020) so ausgelegt ist, dass sie Kommunikationsdienste über die Peer-to-Peer-Signalisierungslogik (2060) mit Peer-Benutzern koordiniert.
Das System gemäß Anspruch 7, wobei der optische Service-Agent (610) des Weiteren Peer-Authentifizierungslogik (2070) zum Authentifizieren von Peer-Benutzern umfasst.
Das System gemäß Anspruch 7 oder Anspruch 8, wobei die Auto-Erkennungslogik (2040) einen Advertisement-Mechanismus zum Senden und Empfangen von Peer-Informationen umfasst.
Ein Verfahren zum Verwalten von Kommunikationsdiensten für Peer-Benutzer (110, 130) in einem optischen Kommunikationssystem (120), wobei das optische Kommunikationssystem ein optisches Kommunikationsnetzwerk (120) einschließlich einer Vielzahl von Randknoten (210, 220, 230, 240) umfasst, über die die Peer-Benutzer (110, 130) auf das optische Kommunikationsnetzwerk zugreifen, und einschließlich eines optischen Service-Servers "OSS" (250) zum Koordinieren verschiedener Kommunikationsdienste, die durch das optische Kommunikationsnetzwerk bereitgestellt werden, wobei das Verfahren umfasst: das Registrieren von Peer-Benutzern (110, 130) beim OSS (250); und das Verteilen von Peer-Informationen an die Peer-Benutzer durch den OSS; wobei das Verfahren dadurch gekennzeichnet ist, dass es umfasst: das automatische Erkennen und Authentifizieren von Peer-Benutzern (110, 130) durch das Registrieren eines ersten Peer-Benutzers (110) beim OSS; und das Registrieren eines zweiten Peer-Benutzers (130) beim OSS; und wobei das Registrieren des ersten Peer-Benutzers (110) beim OSS umfasst: das Senden einer Registrierungsanforderung durch den ersten Peer-Benutzer an einen ersten Randknoten (210); das Authentifizieren des ersten Peer-Benutzers (110) durch den ersten Randknoten (210); und das Senden einer Beitrittsmeldung durch den ersten Randknoten (210) an den OSS (250) zur Identifizierung des ersten Peer-Benutzers (110).
Das Verfahren gemäß Anspruch 10, wobei die Registrierungsanforderung eine Gruppenkennung zur Identifizierung einer Peer-Gruppe umfasst.
Das Verfahren gemäß Anspruch 11, wobei die Beitrittsmeldung umfasst: die Gruppenkennung zur Identifizierung der Peer-Gruppe; sowie eine Benutzerkennung zur Identifizierung des ersten Peer-Benutzers (110).
Das Verfahren gemäß Anspruch 11 oder Anspruch 12, wobei das Authentifizieren des ersten Peer-Benutzers (110) durch den ersten Randknoten (210) umfasst: das Senden einer Abfragemeldung durch den ersten Randknoten an den ersten Peer-Benutzer, wodurch dem ersten Peer-Benutzer eine Möglichkeit gegeben wird, sich selbst positiv beim optischen Kommunikationsnetzwerk (120) zu identifizieren; das Senden einer Abfrageantwortmeldung durch den ersten Peer-Benutzer an den ersten Randknoten, mit der dieser sich selbst über einen kryptografischen Authentifizierungsmechanismus positiv beim optischen Kommunikationsnetzwerk identifiziert; und das Authentifizieren des ersten Peer-Benutzers durch den ersten Randknoten auf der Basis der Abfrageantwortmeldung.
Das Verfahren gemäß Anspruch 13, wobei das Authentifizieren des ersten Peer-Benutzers durch den ersten Randknoten auf der Basis der Abfrageantwortmeldung umfasst: das Interagieren mit einem Netzwerkelement als Bestandteil des kryptografischen Authentifizierungsmechanismus.
Das Verfahren gemäß jedem der Ansprüche 11 bis 14, des Weiteren umfassend: das Senden einer Erfolgsmeldung durch den ersten Randknoten an den ersten Peer-Benutzer bei erfolgter Authentifizierung des ersten Peer-Benutzers, um die Authentifizierung und Registrierung des ersten Peer-Benutzers zu bestätigen.
Das Verfahren gemäß jedem der Ansprüche 11 bis 15, des Weiteren umfassend: das Speichern von Informationen in Bezug auf den ersten Peer-Benutzer in einer Peer-Datenbank beim Empfang der Beitrittsmeldung vom ersten Randknoten.
Das Verfahren gemäß jedem der Ansprüche 10 bis 16, wobei das Verteilen von Peer-Informationen an die Peer-Benutzer (110, 130) durch den OSS (250) umfasst: das Senden von Informationen in Bezug auf den zweiten Peer-Benutzer (130) an den ersten Peer-Benutzer (110) oder das Senden von Informationen in Bezug auf den ersten Peer-Benutzer (110) an den zweiten Peer-Benutzer (130).