DE60314972T2

DE60314972T2 - Signalisierungsprotokoll und Schutzring-Architektur

Info

Publication number: DE60314972T2
Application number: DE60314972T
Authority: DE
Inventors: Kevin M. Plano Hardee
Original assignee: Alcatel Lucent SAS
Current assignee: Alcatel Lucent SAS
Priority date: 2002-12-16
Filing date: 2003-11-27
Publication date: 2008-04-10
Anticipated expiration: 2023-11-28
Also published as: ATE367694T1; US7340163B2; EP1432178B1; DE60314972D1; EP1432178A3; US20040114922A1; EP1432178A2

Description

Hintergrund der Erfindung
1. TECHNISCHES GEBIET
Diese Erfindung betrifft allgemein das Gebiet der Telekommunikation, konkret betrifft sie Schutzringe.
2. BESCHREIBUNG ZUM STAND DER TECHNIK
In den letzten zehn Jahren hat die Bedeutung der Telekommunikation dramatisch zugenommen. Um mit der enormen Menge der über Telekommunikationssysteme wie beispielsweise das öffentliche Telefonnetz (Public Switched Telephone Network, PSTN) und über Datennetze übertragenen Informationen Schritt zu halten, werden Kupferkabel durch Glasfaserkabel ersetzt, die erheblich mehr Informationen übertragen können.
Eine einzelne Glasfaser kann mithilfe von DWDM-Verfahren („Dense Wavelength Division Multiplexing", Dichte Wellenlängen-Multiplex) Informationen über zahlreiche verschiedene Kanäle übertragen. Durch Verbesserungen im Bereich der Glasfasertechnologie und der Elektronik kann in einer Glasfaser eine zunehmende Anzahl von Kanälen unterschieden werden, somit lassen sich mehr Informationen über eine einzige Faser übertragen.
Mit der Steigerung der Informationsbandbreite einer Faser steigt jedoch auch die Bedeutung der Bereitstellung von Mechanismen zum Umgehen von Fehlern im Netzwerk bis zu deren Behebung. Häufige Fehler sind beispielsweise ein Faserbruch (meist durch Bautätigkeiten, bei denen versehentlich ein Kabel durchtrennt wird), das versehentliche Abziehen von Kabeln in der Vermittlungsstelle und Ausfälle von Netzwerkelementen, beispielsweise Laser-Fehler.
Zur Aufrechterhaltung der Kommunikation trotz eines Fehlers werden häufig Ringarchitekturen eingesetzt. In einer Ringarchitektur ist eine Reihe von Netzwerkelementen ringförmig miteinander verbunden, wie in 1a gezeigt. Jeder Ring 10 umfasst mehrere Netzwerkelemente 12, die miteinander verbunden sind und eine geschlossene Schleife bilden. Normalerweise verbinden vier Fasern 14 die benachbarten Netzwerkelemente 10 miteinander – zwei aktive Fasern („working fibers") und zwei Schutzfasern („protection fibers"), auch wenn andere Konfigurationen möglich sind. Die aktiven Fasern (W) transportieren Daten zwischen den angrenzenden Knoten. Die Schutzfasern (P) stehen zur Übertragung des Datenverkehrs bei einem Ausfall einer aktiven Faser zur Verfügung. Die Schutzfasern ermöglichen außerdem die Übertragung von Steuerungsinformationen zwischen Netzwerkelementen; wenn sie für den Datenverkehr nicht genutzt werden, können die Schutzfasern Datenverkehr mit niedriger Priorität übertragen, der auch unterbrochen werden darf.
Bei der in 1a dargestellten Ringarchitektur handelt es sich um eine sehr einfache Architektur. In vielen Fällen können die mehrfachen Ringe 10 verschiedene Netzwerkelemente 12 miteinander verbinden, wie in 1b gezeigt. Wie in 1a dargestellt, können die Netzwerkelemente 12 von mehreren Ringen gemeinsam genutzt werden. Ein Ausfall einer aktiven Faser in einem der Ringe 10 kann dazu führen, dass Schutzleitungen in mehreren Ringen verwendet werden.
2a zeigt ein Verfahren gemäß dem Stand der Technik zum Umgehen eines Ausfalls einer aktiven Faser W. In dieser Ausführungsform weist ein Ring 10 mit fünf Netzwerkelementen 12 (als Netzwerkelemente 12a-12e einzeln aufgeführt) einen Bruch der aktiven Faser W zwischen den Netzwerkelementen 12c und 12d auf. Zur Illustration ist nur eine aktive Faser W und eine Schutzfaser P dargestellt; es ist jedoch klar, dass ein ähnliches Paar aus aktiver Faser und Schutzfaser auch für den Datenverkehr in umgekehrter Richtung verwendet wird. Zur Weiterleitung des Datenverkehrs zwischen den Netzwerkelementen 12c und 12d verbindet das Netzwerkelement 12d die aktiven Leitungen 16de mit den Schutzleitungen 18cd, und das Netzwerkelement 12c verbindet die aktiven Leitungen 16bc mit den Schutzleitungen 18cd. Mit anderen Worten, der Datenverkehr, der normalerweise über die aktiven Leitungen 16cd läuft, wird auf die zugeordneten Schutzleitungen 18cd umgeschaltet. Dies wird als „Spannen"-Umschaltung bezeichnet.
2b zeigte eine Situation, in der die aktive Leitung und die Schutzleitung zwischen den Netzwerkelementen 12c und 12d ausgefallen sind. In diesem Fall wird eine „Ring"-Umschaltung implementiert, wobei die aktive Leitung 16de auf die Schutzleitung 18de umgeschaltet wird und die aktive Leitung 16bc auf die Schutzleitung 18bc. Entsprechend transportieren die verbleibenden funktionsfähigen Schutzleitungen den gesamten Datenverkehr. Jedes Netzwerkelement kann weiterhin mit allen anderen Netzwerkelementen 12 im Ring kommunizieren.
In traditionellen SONST/SDH-Anwendungen verwendet das Protokoll des Transportverfahrens die K1/K2-Overhead-Bytes, die im „Innerband" übertragen werden, also auf dem gleichen Kanal wie der entsprechende Datenverkehr. Es gibt eine steigende Nachfrage zur Verwendung „transparenter" Netzwerkelemente, die die auf optischen Leitungen übertragenen Daten nicht in elektronische Form umsetzen, sondern bei denen der Datenverkehr über einen optischen Umschalter am Netzwerkelement umgeschaltet wird. Transparente Netzwerkelemente bieten zwar den Vorteil einer höheren Geschwindigkeit im Umschalter, andererseits können über diese Elemente dem Kanal keine Steuerungsdaten hinzugefügt werden. Die derzeitigen K1/K2-Overhead-Bytes können daher nicht verwendet werden.
Darüber hinaus bieten gemeinsame Schutzstrukturen zusätzliche Schutzfunktionen. Eine einfache Architektur mit gemeinsamem Ring ist in der Patentschrift WO 99/23773 (PCT/IB98/01955) von Elahmadi et al. beschrieben; dabei nutzen zwei Ringe einen Schutzpfad zwischen einem Paar gemeinsamer Netzwerkelemente gemeinsam. Diese Anwendung schlägt die Verwendung einer einzigen physischen Spanne (der gemeinsamen Schutzleitung) zwischen den gemeinsamen Netzwerkelementen vor, um einen Schutz der beiden Ringe bereitzustellen. Ein Ausfall an einem der Ringe kann durch Verwendung der gemeinsamen Schutzleitung zum Transport des Datenverkehrs behoben werden. Diese Architektur reduziert die Kosten, die erheblich sein können, wenn die Entfernung zwischen den gemeinsamen Netzwerkelementen groß ist oder wenn weitere Infrastrukturkosten hinzukommen, sie vergrößert jedoch das Risiko eines Datenverkehrsausfalls an einem Ring, wenn ein Ausfall auftritt, während an einem anderen Ring bereits ein Ausfall vorliegt.
Die Patentschriften EP1276263 mit dem Titel „Method and Apparatus for Signaling in a Shared Protection Ring Architecture" (Verfahren und Vorrichtung zur Signalverarbeitung in einer gemeinsamen Schutzringarchitektur) von Mazzurco et al., EP1259011 mit dem Titel „Common Protection Architecture For Optical Network" (Gemeinsame Schutzarchitektur für optische Netzwerke) von Mazzurco et al. und U.S. Ser. No. 09/858,098 mit dem Titel „Optical Shared Protection Ring For Multiple Spans" (Optischer gemeinsamer Schutzring für mehrere Spannen) von Mazzurco et al., schlagen weitere Merkmale für gemeinsame Ringstrukturen vor. Diese Merkmale werden von traditionellen K-Byte-Schutzschemata nicht unterstützt.
Vor dem Hintergrund dieser Probleme hat die IETF (Internet Engineering Task Force) einen Vorschlag für ein optisches automatisches Schutzumschaltungsprotokoll („Optical Automatic Protection Switching protocol", O-APS) für optische Ringe vorgelegt. Dieser Vorschlag verwendet den OSC (optischen Überwachungskanal) aller Verbindungen zur Weitergabe der Schutzsignalisierung. Das O-APS-Protokoll im Entwurf der IETF verbindet die Funktionen eines Signalisierungssystems mit denen eines Ringstatusmaschinenprozessors. Das Protokoll erfordert spezifische Schutzschaltungsprozeduren, die sich von den traditionellen, zeitgetesteten Umschaltprozeduren unterscheiden. Die Umschaltprozeduren sind eng gekoppelt mit der Weitergabe der Schutzsignaldaten in einem einzigen Protokoll. Das vorgeschlagene Protokoll verwendet zwar Informationen, die den K-Bytes für die SONST/SDH-Standards ähneln, die Daten werden jedoch in einem völlig anderen Format codiert.
Der Internet-Entwurf „Architecture Framework for Automatic Protection Provisioning in Dynamic Optical Rings" (Architektur-Rahmenlösung für den automatischen Schutz in dynamischen optischen Ringen) von N. Ghani et al. beschreibt dieses O-APS-Protokoll. Der Entwurf schlägt die Verwendung eines Außerband-Netzwerks zur Umschaltung der Signalisierung zwischen angrenzenden Knoten vor, um die Daten- und Steuerungsebenen klarer voneinander zu entkoppeln, und er erwähnt die Notwendigkeit zur Entwicklung einer vollständigen Definition einer Statusmaschine und entsprechender Regeln für die Implementierung des neuen O-APS-Protokolls.
Die Patentschrift EP 1239622 „Optical path crossconnect and optical wavelength multixplexing diversity communication system using the same" (Optische Pfad-Querverbindung und Diversity-Kommunikationssystem zum Multiplexen optischer Wellenlängen unter Verwendung desselben) betrifft ein Schutzsystem zum Schutz der Pfade der Internetzwerk-Kommunikation zwischen Wellenlängen-Multiplex-Ringnetzwerken (WDM) einschließlich einer Vielfalt optischer Wellenlängen-Multiplex-Netzwerke mit einer Vielzahl von Knoten und ein Netzwerkverwaltungssystem zur Überwachung der Bedingungen der Vielfalt von Knoten. Die Knoten umfassen einen ersten Knoten mit Funktionen zum Hinzufügen/Abzweigen optischer Wellenlängen-Multiplexing-Signale, einen zweiten Knoten mit einer Signalübertragungsfunktion sowie den Funktionen zum Hinzufügen/Abzweigen und einen dritten Knoten mit einer Internetzwerk-Verbindungsfunktion zwischen den Netzwerken. Jeder erste, zweite und dritte Knoten umfasst des Weiteren optische Pfad-Querverbindungs-Umschalter und eine Tabelle zur Angabe der Bedingungen der Pfad-Querverbindungs-Umschalter und einer am Knoten erkannten Fehlerbedingung.
Der IETF-Vorschlag „Automatic Switched Optical Network (ASON) Architecture and Its related Protocols" (Optische Netzwerkarchitektur mit automatischer Umschaltung/ASON und zugehörige Protokolle) von G. Grammel et al., IETF, [online] November 2001 (2001-11), Seite 1-22, (http://www.ietf.org/proceedings/O1dec/I-D/draft-ietf-ipoason-01.txt) betrifft optische Netzwerke mit automatischer Umschaltung und eine Steuerungsebene für optische Netzwerke mit Umschaltung. Das Steuerungsnetzwerk stellt die Transport-Infrastruktur für den Steuerungs-Datenverkehr dar; dabei kann es sich um ein Innerband- oder ein Außerband-Netzwerk handeln. Die Steuerungsebene kann von einer anderen physischen Topologie unterstützt werden als die des ihr zugrunde liegenden optischen Netzwerks mit automatischer Umschaltung.
Der IETF-Vorschlag „IP over Optical Networks: A Framework" (IP über optische Netzwerke: Eine Rahmenlösung) von B. Rajagolapan et al., IETF, [Online] März 2002 (2002-03), (http://www.ietf.org/proceedings/02mar/I-D/draft-ietf-ipoframework-O1.txt) betrifft die Übertragung von IP-Datenverkehr über optische Netzwerke, wobei für die optische Steuerungsebene IP-basierte Protokolle verwendet werden können. Ein Innerband- oder Außerband-IP-Steuerungskanal kann beispielsweise zwischen einem Edge-Router und jeder einzelnen optischen Querverbindung (OXC), an die er angeschlossen ist, implementiert werden. Dieser Steuerungskanal wird zum Austausch der Signalisierungs- und der Weiterleitungsnachrichten zwischen dem Router und der OXC verwendet.
Die Durchführung umfangreicher Änderungen bei den Umschaltungsprozeduren und den dazugehörigen Daten führt fast immer zu Fehlern und kann die Entwicklung der Einrichtungen erheblich verteuern.
Es hat sich daher ein Bedarf nach einer Schutzsignal-Architektur entwickelt, die zuvor entwickelte Protokolle nutzt und erweiterte Funktionen für gemeinsame Ringarchitekturen ermöglicht.
Kurze Zusammenfassung der Erfindung
In der vorliegenden Erfindung umfasst ein Netzwerkelement Eingangs-/Ausgangsschaltungen zum Senden und Empfangen von Datenverkehr über optische Verbindungen sowie Schutzstatusmaschinen zum Empfangen von Steuerungsinformationen von Eingangs-/Ausgangsschaltungen, die auf Übertragungsfehler hinweisen. Von den Schutzstatusmaschinen werden Fehlermeldungen empfangen, und Fehlerinformationen werden über ein Außerband-Netzwerk an die angrenzenden Netzwerkelemente weitergegeben.
Kurzbeschreibung der verschiedenen Ansichten der Zeichnungen
Für ein umfassenderes Verständnis der vorliegenden Erfindung und ihrer Vorteile wird an dieser Stelle auf die folgenden Beschreibungen in Verbindung mit den beigefügten Zeichnungen verwiesen, wobei gilt:
1a zeigt eine Reihe von Netzwerkelementen in einer Ringarchitektur;
1b zeigt eine Ringarchitektur mit mehreren sich überlappenden Ringen;
2a zeigt eine Spannenumschaltung in einer Ringarchitektur;
2b zeigt eine Ringumschaltung in einer Ringarchitektur;
3 zeigt ein Blockdiagramm eines Paars von Netzwerkelementen mit OF/OB-Netzwerkfunktionen („Out-of-Fiber, Out-of-Band", Außerfaser/Außerband) zur Kommunikation der Steuerungsinformationen, die mit den derzeitigen K-Byte-Protokollen kompatibel sind;
4 zeigt eine Ringarchitektur, die einen LSPR-Schutz („Line Shared Protection Ring", Schutzring mit gemeinsamer Leitung) ermöglicht;
5 zeigt einen mit KBSP-Nachrichten (K-Byte Signaling Protocol) verwendeten Nachrichtenkopf;
6 zeigt ein Format eines Nachrichtenkörpers für eine NAK-Nachricht;
7 zeigt ein Format eines Nachrichtenkörpers für eine Nicht-NAK-, Nicht-LSPR-Nachricht;
8 zeigt ein Format eines Nachrichtenkörpers für eine Nicht-NAK-, LSPR-Nachricht;
9 zeigt ein Übergangsdiagramm für die KBSP-Client-Statusmaschine aus 3;
10 zeigt ein Übergangsdiagramm für die KBSP-Server-Statusmaschine des APS-Signalcontrollers aus 3;
11 zeigt einen Verlauf von Synchronisationsnachrichten; und
12 zeigt einen APS-Änderungsnachrichtenverlauf.
Ausführliche Beschreibung der Erfindung
Die vorliegende Erfindung wird am besten verständlich mit Bezug auf die 1-12 der Zeichnungen, wobei für gleiche Elemente in den verschiedenen Zeichnungen gleiche Bezugszeichen verwendet werden.
3 zeigt ein Blockdiagramm eines Paars von Netzwerkelementen 20 (einzeln beschriftet als Netzwerkelement0 und Netzwerkelement1) mit OF/OB-Netzwerkfunktionen („Out-of-Fiber, Out-of-Band", Außerfaser/Außerband) zur Kommunikation der Steuerungsinformationen, die mit den derzeitigen K-Byte-Protokollen kompatibel sind.
Jedes Netzwerkelement 20 umfasst eine Steuerungs-Kommunikationsschaltung 22 zur Kommunikation der K1/K2-ähnlichen Steuerungsinformationen zwischen den Netzwerkelementen und der Datenkommunikationsschaltung 24 zur transparenten Kommunikation des Datenverkehrs. Die Steuerungskommunikation umfasst eine OAM&P-Schaltung 26 ("Operations, Administration, Maintenance, and Provisioning", Betrieb, Verwaltung, Wartung und Bereitstellung), IP Netzwerk-Kommunikationsschaltungen 28 und APS-Signalcontroller 30 („Automatic Protection Switching", Automatische Schutzumschaltung). Die Datenkommunikationsschaltung 24 umfasst E/A- und Fehlererkennungsschaltungen 32, gekoppelt über eine optische Querverbindung (OXC) 34. Die optische Querverbindung 34 wird über eine OXC-Steuerungsschaltung 36 gesteuert. Die Schutzstatusmaschinen („Protection state machines", PSM) 38 sind mit entsprechenden E/A- und Fehlererkennungsschaltungen 32 gekoppelt. KBSP-Statusmaschinen 40 (K-Byte Signalprotokollierung) sind mit entsprechenden Schutzstatusmaschinen 38 gekoppelt. Die kombinierten Schutzstatusmaschinen 38 und die entsprechenden Client-KBSP-Statusmaschinen 40 werden in diesem Dokument als die Ringstatusmaschine („Ring State Machine", RSM) 41 bezeichnet. Die Schutzstatusmaschinen 38 umfassen Statusmaschinen für jeden vom Netzwerkelement verwendeten Schutztyp (z. B., 1:1, 1:N usw.). Für jede Schutzgruppe gibt es eine separate Signalinstanz innerhalb des APS-Signalcontrollers 30, der KBSP-Signalcontroller 40 und der Schutzstatusmaschinen 38.
Im allgemeinen Betrieb wird der Datenverkehr zwischen Netzwerkelement0 und Netzwerkelement1 über die optische Verbindung 42 weitergegeben. Die Daten werden transparent (d. h. ohne Umwandlung in elektronische Signale) über die E/A- und Fehlererkennungsschaltungen 32 und die optische Querverbindung 34 zur Kommunikation mit anderen Netzwerkelementen 20 weitergegeben. Die E/A- und Fehlererkennungsschaltungen 32 können einen Fehler bei der Signalübertragung an einem eingehenden Kanal erkennen. Ein Fehler kann an einem einzelnen Kanal auftreten wegen einer Laser-Fehlfunktion, oder er kann gleichzeitig an mehreren Kanälen auftreten, wenn eine Glasfaser durchtrennt oder versehentlich von einem Netzwerkelement abgezogen wurde. An dieser Stelle wird ein Fehler an die entsprechende Schutzstatusmaschine 38 gesendet.
In einer traditionellen SONST/SDH-Anwendung sendet die Schutzstatusmaschine Nachrichten im Innerband über die K1/K2-Signalisierung. In einem transparenten Netzwerk ist das Einfügen von K1/K2-Bytes nicht möglich. In den Netzwerkelementen aus 3 werden diese Daten an die zugeordnete KBSP-Client-Statusmaschine 40 gesendet, die die Informationen an den APS-Signalcontroller 30 weiterleitet. Der APS-Signalcontroller 30 verwendete die IP-Netzwerk-Kommunikationsschaltung zur Weitergabe der Steuerungsinformationen von der KBSP-Client-Statusmaschine an die benachbarten Netzwerkelemente 20 über ein Außerfaser-Außerband-Netzwerk 44 (OF/OB). Das OF/OB-Netzwerk 44 könnte beispielsweise ein IP-Netzwerk sein. Die IP-Netzwerk-Kommunikationsschaltung 28 führt allgemeine Funktionen aus wie beispielsweise ein Verbindungsverwaltungsprotokoll (Link Management Protocol, LMP) zum Einrichten von Steuerungs-Sessions zwischen Knoten und den zugeordneten Steuerungskanälen mit Datenkanälen in einer Schutzgruppe. Darüber hinaus umfasst die IP-Netzwerk-Kommunikationsschaltung 28 einen Routing Manager für eine effiziente Weiterleitung der Steuerungsinformationen.
In einer Ausführungsform der Erfindung umfassen die Schutzstatusmaschinen 38 Schutzprotokolle, die gemeinsame Schutzleitungen unterstützen, die LSPR-Statusmaschine (Line Shared Protection Ring). In einem LSPR-Schutzschema ist eine einzige Glasfaser für den Schutz in zwei oder mehr Ringen verfügbar. 4 zeigt eine Ringarchitektur, die einen LSPR-Schutz ermöglicht. In dieser Figur sind zwölf Netzwerkelemente in fünf Ringschutzgruppen (Ring Protection Groups, RPGs) angeordnet. Zur Unterstützung von LSPR sind bestimmte zusätzliche Informationen erforderlich. Eine „Ringsequenz" ist eine sortierte Liste von Knoten, die die Sequenz von Knoten defi niert, auf denen RPGs aufgebaut sind. In 4 entspricht die Darstellung von RPG1 der sortierten Liste NE1-NE2-NE7-NE6-NE5. Ein „lokaler Knoten" ist die ganzzahlige Knotennummer, die die Knotenkennung des lokalen Netzwerkelements für die entsprechende Ringschutzgruppe angibt. Eine „Knotenadressliste" ist entweder eine indexierte Liste von IP-Adressen für die einzelnen Knoten in der Ringschutzgruppe oder die IP-Adresse der direkten Ost- und West-Knoten aus der Sicht des lokalen Knotens. Knotenadressen sind erforderlich, um den Kommunikationsfluss auf der Steuerungsebene zu ermöglichen. Die APS-Signalisierung gemäß der IP-Steuerungsebene erfordert lediglich eine Ost-West-Adressierung. Die Festlegung, ob die Ost-West-Adressierung beibehalten oder eine komplette Ringadressierung verwendet werden soll, kann entsprechend der ausführlichen Definition des für die Verteilungszuordnung der Ringverbindung erforderlichen Protokolls getroffen werden.
Ein „Schnelleinrichtungsschutz" (Fast Facility Protection, FFP) ist eine gemanagte Objektzuordnung von Einrichtungen und Schutzinformationen, die eine Instanz einer Schutzumschaltungskonstruktion definieren. Die Zuordnung kann eine von mehreren Schutzkonstruktionen definieren, beispielsweise 1+1-Leitungsschutz, m:n-Leitungsschutz oder verschiedene Ringschutzverfahren wie bidirektionale 4-Faser-Leitungsumschaltungsringe oder gemeinsame Leitungsschutzringe. Zum Hinzufügen gemeinsamer Leitungsschutzringe sind die folgenden Daten der Zuordnung von Bedeutung:
SCHEMA – definiert die Art der Schutzzuordnung wie beispielsweise 1+1 oder LSPR;
RPG ID – die Kennung der Ringschutzgruppe, der der FFP zugeordnet ist. Nur gültig für Ringschemata;
RING-ID – gibt die Kennung der einzelnen Ringinstanz innerhalb der RPG der Netzwerkebene an, der der FFP zugeordnet ist. Nur gültig für Ringschemata;
AKTIV – sortierte Liste für die aktiven Ost- und West-Einrichtungen für den zugeordneten FFP. Eine individuelle aktive Einrichtung kann nur einem FFP zugeordnet sein. Gültig für alle Schutzschemata;
SCHUTZ – sortierte Liste für die Ost- und West-Schutzeinrichtungen für den zugeordneten FFP. Durch Angabe einer individuellen Schutzeinrichtung für mehr als einen FFP wird diese Schutzeinrichtung als gemeinsame Schutz-Ressource festgelegt. Gültig für alle Schutzschemata; und
FFP EQPT ID – gibt die Kennung der Einrichtung für die Prozessorkarte an, der der FFP zugeordnet ist.
Diese Informationen können von der OAM&P-Schaltung 26 gepflegt werden. RPG-Daten werden von der Ringstatusmaschine 41 für die Verarbeitung der Statusmaschine benötigt und von der APS-Signalcontroller-Komponente für die Weiterleitung der APS-Signalnachrichten.
Der Betrieb des Netzwerkelements 10 wird im Folgenden ausführlicher beschrieben. Der APS-Signalcontroller 30 ist die Schnittstellenkomponente zwischen der Ringstatusmaschine 41 und der IP-Netzwerkkommunikationsschaltung 28. Jeder APS-Signalcontroller 30 und jede Schutzstatusmaschine 38 kommuniziert über die KBSP-Statusmaschine 40 auf der Client-Seite. Der APS-Signalcontroller 30 verschiedener Netzwerkelemente kommuniziert über eine in den APS-Signalcontrollern implementierte KBSP-Statusmaschine auf der Serverseite. Der Betrieb für die Statusmaschinen auf der Client- und auf der Server-Seite ist nachfolgend ausführlich beschrieben.
Die Ringstatusmaschine 41 ist die für die LSPR-Verarbeitung erforderliche zentrale Komponente, da sie den Algorithmus der Kern-LSPR-Statusmaschine umfasst. Die Ringstatusmaschine 41 besteht aus zwei Teilen: (1) der Schutzstatus maschine 38, die die Schutzentscheidungen umfasst, und (2) der KBSP-Statusmaschine 40 auf der Client-Seite.
Die Schutzstatusmaschine 38 der Ringstatusmaschine für LSPR führt die folgenden Funktionen aus:
Verarbeitung eingehender Einrichtungs-Fehlerereignisse;
Verarbeitung eingehender K-Byte-Statusereignisse;
Finite Statusmaschinenverarbeitung auf der Basis eingehender Ereignisse und des aktuellen Status;
Anfordern der Ausführung geeigneter Überbrückungs- und Umschaltfunktionen durch die OXC-Steuerung 36 auf der Basis von Statusübergängen; und
Bestimmen und Anfordern ausgehender K-Byte-Übertragungen.
Pro Schnellschutzeinrichtung gibt es eine Instanz einer Ringstatusmaschine 41.
Das hierin beschriebene K-Byte-Signalprotokoll definiert das Außerband-Signalisierungsprotokoll und die zugeordneten Statusmaschinen zur Übertragung K1/K2-ähnlicher Daten zwischen benachbarten APS-Signalcontrollern 30 sowie zwischen den APS-Signalcontrollern 30 und den zugeordneten Ringstatusmaschinen 41. Zusätzlich zu den traditionellen K1/K2-Daten umfasst KBSP in der bevorzugten Ausführungsform die erforderlichen zusätzlichen Daten, die das System zur Ausführung der LSPR-Funktionalität benötigt. KBSP ist so flexibel konzipiert, dass es zusätzliche neu entwickelte Funktionen unterstützen kann, sobald diese vorliegen. KBSP-Protokollnachrichten sind zur Übertragung über die Steuerungsebene in IP-Pakete eingekapselt.
KBSP nutzt ein leichtes Hello-Protokoll für die Peer-Erkennung/Synchronisation und zum Begrenzen der zwischen den Peers erforderlichen Bandbreite.

5 zeigt einen mit KBSP-Nachrichten verwendeten Nachrichtenkopf. Der Nachrichtenkopf umfasst acht Felder: Versionsnummer, Nachrichtentyp, Nachrichtenlänge, Schutztyp, Quellenverbindungs-ID, Zielverbindungs-ID, Sequenznummer und Prüfsumme. Die Versionsnummer gibt die Version des für die Nachricht verwendeten KBSP an. Der Nachrichtentyp gibt an, welche Art von Nachricht gesendet wird. Die derzeit definierten Nachrichtentypen (hexadezimal ausgedrückt) sind in Tabelle 1 aufgeführt. Tabelle 1 Nachrichtentypen

0x01	HELLO	Nachricht „Ich lebe noch", gesendet von einem APS-Signalcontroller
0x02	CLIENT HELLO	Nachricht „Ich lebe noch", gesendet von einer Client-KBSP-Statusmaschine
0x03	HELLO ACK	Erfolgreiche Bestätigung „Ich lebe noch" von einem APS-Signalcontroller
0x04	CLIENT HELLO ACK	Erfolgreiche Bestätigung „Ich lebe noch" von einer Client-KBSP-Statusmaschine
0x05	HELLO NAK	Nicht erfolgreiche Nicht-Bestätigung „Ich lebe noch" von einem APS-Signalcontroller
0x06	CLIENT HELLO NAK	Nicht erfolgreiche Nicht-Bestätigung „Ich lebe noch" von einer Client-KBSP-Statusmaschine
0x07	APS CHANGE	Eine Benachrichtigung zu einer Änderung in den K-Byte-Daten zur automatischen Schutzumschaltung von einem APS-Signalcontroller
0x08	CLIENT APS CHANGE	Eine Benachrichtigung zu einer Änderung in den K-Byte-Daten zur automatischen Schutzumschaltung von einer Client-KBSP-Statusmaschine
0x09	APS CHANGE ACK	Eine Bestätigung zu einer Änderung in den K-Byte-Daten zur automatischen Schutzumschaltung von einem APS-Signalcontroller
0x0A	CLIENT APS CHANGE ACK	Eine Bestätigung zu einer Änderung in den K-Byte-Daten zur automatischen Schutzumschaltung von einer Client-KBSP-Statusmaschine
0x0B	APS CHANGE NAK	Eine Nicht-Bestätigung zu einer Änderung in den K-Byte-Daten zur automatischen Schutzumschaltung von einem APS-Signalcontroller
0x0C	CLIENT APS CHANGE NAK	Eine Nicht-Bestätigung zu einer Ände-rung in den K-Byte-Daten zur automatischen Schutzumschaltung von einer Client-KBSP-Statusmaschine

Das Feld Nachrichtenlänge gibt die Länge (in Byte) der KBSP-Nachricht an einschließlich des KBSP-Nachrichtenkopfs. Das Feld Schutztyp gibt den verwendeten Schutztyp an. Die derzeit definierten Schutztypen sind in Tabelle 2 aufgeführt. Tabelle 2 Schutztypen

Wert	Schutztyp
0x01	1_P_1_UNI – 1 + 1 Unidirektionaler Leitungsschutz
0x02	1 P 1 BI – 1 + 1 Bidirektionaler Leitungsschutz
0x03	M F N – M : N Bidirektionaler Leitungsschutz
0x04	LSPR – Gemeinsamer Leitungsschutzring-Schutz
0x05	4FIBER_BI – 4 Glasfaser Bidirektionaler Ringschutz

Die Quellenverbindungs-ID ist eine nicht nummerierte Verbindungskennung für den Quellenknoten, der die KBSP-Nachricht sendet und über den die Verbindung zur Laufzeit überprüft wird. Die Zielverbindungs-ID ist eine nicht nummerierte Verbindungskennung für den Zielknoten, der die KBSP-Nachricht empfängt und über den die Nachricht an die entsprechende KBSP-Instanz und RSM-Instanz gesendet wird. Das Feld Sequenznummer umfasst eine inkrementelle KBSP-Nachrichtensequenznummer. Das Feld Prüfsumme umfasst die Standard-IP-Prüfsumme des gesamten Inhalts der KBSP-Nachricht einschließlich des Nachrichtenkopfs.

Das Format des Nachrichtenkörpers hängt von den Feldern Nachrichtentyp und Schutztyp ab. Das für alle NAK-Nachrichtentypen verwendete Format 52 des NAK-Nachrichtenkörpers ist in 6 dargestellt. Der NAK-Nachrichtenkörper umfasst ein einzelnes Feld mit einem Wert, der den Grund für die Nicht-Bestätigung (NAK) angibt. Die NAK-Felddefinitionen sind in Tabelle 3 dargestellt. Tabelle 3 NAK-Fehlercodes

Wert	Fehler
0x01	NOT_READY (Nicht bereit)
0x02	INVALID_STATE (Ungültiger Status)
0x03	VERSION_MISMATCH (Versionsfehler)
0x04	PROTECT-TYPE-MISMATCH (Schutztyp-Fehler)
0x05	CONNECTIVITY_MISMATCH (Verbindungsfehler)
0x06	RPG_ID_MISMATCH (RPG-ID-Fehler)
0x07	RING-ID-MISMATCH (Ring-ID-Fehler)

Alle Nicht-NAK-Nachrichten ohne LSPR-Schutztyp haben das in 7 dargestellte Nachrichtenformat 54. Das Nachrichtenformat 54 umfasst drei Felder: K1-Byte, K2-Byte und Reserviert. Im Feld K1-Byte wird das K1-Byte gespeichert gemäß der SONST/SDH-Definition des K1-Bytes. Im Feld K2-Byte wird das K2-Byte gespeichert gemäß der SONST/SDH-Definition des K2-Bytes. Das Feld Reserviert ist für zukünftige Erweiterungen vorgesehen.
Nicht-NAK-Nachrichten mit LSPR-Schutztyp verwenden das in 8 dargestellte Nachrichtenformat 56. Das Nachrichtenformat 56 umfasst vier Felder: K1-Byte, K2-Byte, RPG-ID und Ring-ID. Im Feld K1-Byte wird das K1-Byte gespeichert gemäß der SONST/SDH-Definition des K1-Bytes. Im Feld K2-Byte wird das K2-Byte gespeichert gemäß der SONST/SDH-Definition des K2-Bytes. Im Feld RPG-ID wird eine Kennung für die Ringschutzgruppe auf Netzwerkebene gespeichert zur Überprüfung der Konfiguration. Im Feld Ring-ID wird eine Kennung gespeichert mit der RPG zur Überprüfung der Konfiguration und zur Identifikation der Ringnummer an gemeinsamen Schutzleitungen.
Die Steuerungsinformationen werden zwischen der KBSP-Client-Statusmaschine 40 und dem APS-Signalcontroller 30 mit den in den 5-8 dargestellten Formaten weitergegeben. Die Client-Statusmaschine 40 sendet die Informationen an die Schutzstatusmaschinen 38 im richtigen Format, sodass zuvor entwickelte Schutzstatusmaschinen ohne oder mit nur geringen Veränderungen verwendet werden können.
9 zeigt ein Übergangsdiagramm für die KBSP-Client-Statusmaschine 40. Die KBSP-Client-Statusmaschine 40 kennt zwei Status: einen Status „Nicht aktiv" 60 und einen Status „Aktiv" 62. Die KBSP-Client-Statusmaschine 40 geht als Reaktion auf eine Init()-Nachricht in den Status „Nicht aktiv" 60. Im Status „Nicht aktiv" 60 verharrt die KBSP-Client-Statusmaschine 40 in diesem Status 60 als Reaktion auf eine der folgenden Nachrichten bzw. eines der folgenden Ereignisse: Hello, Client_Hello_Sync_Timeout, APS_Change, Client_APS_Change(). Die KBSP-Client-Statusmaschine 40 wechselt in den Status „Aktiv" 62 als Reaktion auf eine Nachricht Hello_Ack. Weitere Nachrichten oder Ereignisse sind vom Status „Nicht aktiv" aus ungültig. Im Status „Aktiv" 62 verharrt die KBSP-Client-Statusmaschine 40 in diesem Status als Reaktion auf eine der folgenden Nachrichten bzw. eines der folgenden Ereignisse: Hello, Hello_Ack, Client_Hello_Sync_Timeout, APS_Change, Client_APS_Change(), APS_Change_Ack, Client_APS_Change_Ack_Timeout. Die KBSP-Client-Statusmaschine 40 wechselt vom Status „Aktiv" 62 in den Status „Nicht aktiv" 60 als Reaktion auf eine Nachricht Client_Hello_Dead_Interval_Timeout oder APS_Change_Nak. Weitere Nachrichten oder Ereignisse sind vom Status „Aktiv" aus ungültig.

Tabelle 4 beschreibt die von der KBSP-Client-Statusmaschine 40 als Reaktion auf eingehende Nachrichten und Ereignisse ausgeführten Aktionen. Tabelle 4 KBSP-Client-Statusmaschine Aktionen

Aktueller Status	Eingehende Nachricht	Aktionen
–	Initialization(0)	• Status auf „Nicht aktiv" setzen • Nachricht Client_Hello mit aktuellen Sende-K-Bytes senden • Client_Hello_Sync_Timer setzen
Nicht aktiv	Hello empfangen (1)	• Im Status „Nicht aktiv" verharren • Nachricht Client_Hello_Nak mit Fehlercode NOT READY senden • Nachricht Client_Hello mit aktuellen Sende-K-Bytes senden • Client_Hello_Sync_Timer zurücksetzen
Nicht aktiv	Hello Ack empfangen (2)	• In den Status „Aktiv" wechseln. • Client_Hello_Sync_Timer zurücksetzen • Client_Hello_Dead_Interval_Timer setzen
Nicht aktiv	Client Hello Sync Timeout empfangen (3)	• Im Status „Nicht aktiv" verharren • Nachricht Client_Hello mit aktuellen Sende-K-Bytes senden • Client_Hello_Sync_Timer zurücksetzen
Nicht aktiv	APS Change empfangen (5)	• Im Status „Nicht aktiv" verharren • Nachricht Client_APS_Change_Nak mit Fehlercode NOT READY senden • Nachricht Client_Hello mit aktuellen Sende-K-Bytes senden • Client_Hello_Sync_Timer zurücksetzen
Nicht aktiv	Client APS Change() Ereignis (6)	• Im Status „Nicht aktiv" verharren • Nachricht Client_Hello mit aktuellen Sende-K-Bytes senden • Client_Hello_Sync_Timer zurücksetzen
Aktiv	Hello empfangen (1)	• Im Status „Aktiv" verharren • Empfangene K-Bytes an Schutzstatusmaschine weiterleiten • Nachricht Client_Hello_Ack mit aktuellen Sende-K-Bytes senden • Client_Hello_Sync_Timer zurücksetzen • Client_Hello_Dead_Interval_Timer zurücksetzen
Aktiv	Hello Ack empfangen (2)	• Im Status „Aktiv" verharren • Empfangene K-Bytes an Schutzstatusmaschine weiterleiten • Client_Hello_Sync_Timer zurücksetzen • Client_Hello_Dead_Interval_Timer zurücksetzen
Aktiv	Client Hello Sync Timeout empfangen (3)	• Im Status „Aktiv" verharren • Nachricht Client_Hello mit aktuellen Sende-K-Bytes senden • Client_Hello_Sync_Timer zurücksetzen
Aktiv	Client Hello Dead Interval Timeout empfangen (4)	• Status auf „Nicht aktiv" setzen • Nachricht Client_Hello mit aktuellen Sende-K-Bytes senden • Client_Hello_Sync_Timer zurücksetzen, sofern vorhanden • Client_Change_Ack_Timer löschen, sofern vorhanden, und Client_Hello_Sync_Timer setzen
Aktiv	APS Change empfangen (5)	• Im Status „Aktiv" verharren • Nachricht Client_APS_Change_Ack mit aktuellen Sende-K-Bytes senden • Empfangene K-Bytes an Schutzstatusmaschine weiterleiten • Client_Hello_Sync_Timer zurücksetzen • Client_Hello_Dead_Interval_Timer zurücksetzen
Aktiv	Client APS Change() Ereignis (6)	• Im Status „Aktiv" verharren • Nachricht Client_APS_Change mit aktuellen Sende-K-Bytes senden • Client_Hello_Sync_Timer löschen • Client_APS_Change_Ack_Timer setzen
Aktiv	APS Change Ack empfangen (7)	• Im Status „Aktiv" verharren • Client_Change_Ack_Timer löschen • Client_Hello_Sync_Timer setzen • Client_Hello_Dead_Interval_Timer zurücksetzen
Aktiv	APS Change Nak empfangen (8)	• Status auf „Nicht aktiv" setzen • Nachricht Client_Hello mit aktuellen Sende-K-Bytes senden • Client_Change_Ack_Timer löschen • Client_Hello_Dead_Interval_Timer löschen • Client_Hello_Sync_Timer setzen • Nak Error Code verarbeiten
Aktiv	Client APS Change Ack Timeout empfangen (9)	• Im Status „Aktiv" verharren • Nachricht Client_APS_Change mit aktuellen Sende-K-Bytes senden • Client_APS_Change_Ack_Timer setzen

10 zeigt ein Übergangsdiagramm für die Server-Statusmaschine des APS-Signalcontrollers 30. Der APS-Signalcontroller 30 kennt drei Status: Einen Status „Nicht aktiv" 70, einen Status „Sync" 72 und einen Status „Aktiv" 74. Der APS-Signalcontroller 30 geht als Reaktion auf eine Init()-Nachricht in den Status „Nicht aktiv" 70. Im Status „Nicht aktiv" 70 verharrt der APS-Signalcontroller 30 in diesem Status 70 als Reaktion auf eine Nachricht Hello oder APS_Change. Der APS-Signalcontroller 30 wechselt als Reaktion auf eine Nachricht Client_Hello vom Status „Nicht aktiv" 70 in den Status „Sync" 72. Weitere Nachrichten oder Ereignisse sind vom Status „Nicht aktiv" aus ungültig.
Vom Status „Sync" 72 aus verharrt der APS-Signalcontroller in diesem Status 72 als Reaktion auf Client_Hello, Hello_Nak, APS_Change, Client_APS_Change oder Hello_Sync_Timeout. Der APS-Signalcontroller 30 kehrt vom Status „Sync" 72 zurück in den Status „Nicht aktiv" als Reaktion auf ein Client_Hello_Dead_Interval_Timeout. Der APS-Signalcontroller 30 wechselt vom Status „Sync" 72 in den Status „Aktiv" 74 als Reaktion auf eine Nachricht Hello oder Hello_Ack.
Vom Status „Aktiv" 74 aus verharrt der APS-Signalcontroller in diesem Status 74 als Reaktion auf Hello, Client-Hello, Hello_Ack, Client_Hello_Ack, APS_Change, Client_APS_Change, APS_Change_Ack, Client_APS_Change_Ack, Hello_Sync_Timeout, Client_Hello_Sync_Timeout, APS_Change_Ack_Timeout oder Client_APS_Change_Ack_Timeout. Der APS-Signalcontroller wechselt vom Status „Aktiv" 74 in den Status „Sync" 72 als Reaktion auf ein Hello_Nak, ein APS_Change_Nak oder ein Hello_Dead_Interval_Timer. Der APS-Signalcontroller wechselt vom Status „Aktiv" 74 in den Status „Nicht aktiv" 70 als Reaktion auf ein Client_Hello_Nak, Client_APS_Change_Nak oder ein Client_Hello_Dead_Interval_Timeout.

Tabelle 5 beschreibt die vom APS-Signalcontroller 30 als Reaktion auf eingehende Nachrichten und Ereignisse ausgeführten Aktionen. Diese Tabelle zeigt den Protokollfluss auf hoher Ebene; sie stellt keine vollständige Liste über den gesamten Fehlerbedingungsfluss dar. Der allgemeine Datenfluss zwischen der KBPS-Client-Statusmaschine 40 und dem APS-Signalcontroller 30 ist die Synchronisation von Clients und Servern und die anschließende unabhängige Synchronisation von Peer-Servern. Tabelle 5 APS-Signalcontroller Aktionen

Aktueller Status	Eingehende Nachricht	Aktionen
–	Initialization(0)	• Status auf „Nicht aktiv" setzen • Aktuelle Empfangs-K-Bytes auf NULL setzen • Aktuelle Sende-K-Bytes auf NULL setzen
Nicht aktiv	Hello empfangen (1)	• Im Status „Nicht aktiv" verharren • Nachricht Hello_Nak mit Fehlercode NOT READY an Peer senden
Nicht aktiv	Client Hello empfangen (2)	• Status auf „Sync" setzen • Aktuelle Sende-K-Bytes speichern • Nachricht Hello_Ack mit aktuellen Empfangs-K-Bytes an Client senden • Nachricht Hello mit aktuellen Sende-K-Bytes an Peer senden • Client_Hello_Dead_Interval_Timer setzen • Hello_Sync_Timer setzen
Nicht aktiv	APS Change empfangen (7)	• Im Status „Nicht aktiv" verharren • Nachricht APS_Change_Nak mit Fehlercode NOT_READY an Peer senden
Sync	Hello empfangen (1)	• Status auf „Aktiv" setzen • Aktuelle Empfangs-K-Bytes speichern • Nachricht Hello_Ack mit aktuellen Sende-K-Bytes an Peer senden • Nachricht Hello mit aktuellen Empfangs-K-Bytes an Client senden • Client_Hello_Sync_Timer setzen • Hello_Sync_Timer zurücksetzen • Hello_Dead_Interval_Timer setzen
Sync	Client Hello empfangen (2)	• Im Status „Sync" verharren • Aktuelle Sende-K-Bytes speichern • Nachricht Hello_Ack mit aktuellen Empfangs-K-Bytes an Client senden • Client_Hello_Dead_Interval_Timer zurücksetzen
Sync	Hello Ack empfangen (3)	• Status auf „Aktiv" setzen • Aktuelle Empfangs-K-Bytes speichern • Nachricht Hello mit aktuellen Empfangs-K-Bytes an Client senden • Client_Hello_Sync_Timer setzen • Hello_Sync_Timer zurücksetzen • Hello_Dead_Interval_Timer setzen

Sync	Hello Nak empfangen (5)	• Im Status „Sync" verharren • Aktuelle Empfangs-K-Bytes auf NULL setzen • Hello_Sync_Timer zurücksetzen
Sync	APS Change empfangen (7)	• Im Status „Sync" verharren • Aktuelle Empfangs-K-Bytes auf NULL setzen • Nachricht APS_Change_Nak mit Fehlercode NOT_READY an Peer senden
Sync	Client APS Change empfangen (8)	• Im Status „Sync" verharren • Aktuelle Sende-K-Bytes speichern • Nachricht APS_Change_Ack mit aktuellen Empfangs-K-Bytes an Client senden • Client_Hello_Dead_Interval_Timer zurücksetzen
Sync	Hello Sync Timeout empfangen (13)	• Im Status „Sync" verharren • Nachricht Hello mit aktuellen Sende-K-Bytes an Peer senden • Hello_Sync_Timer setzen
Sync	Client Hello Dead Interval Timeout empfangen (16)	• Status auf „Nicht aktiv" setzen • Aktuelle Empfangs-K-Bytes auf NULL setzen • Aktuelle Sende-K-Bytes auf NULL setzen • Client_Hello_Sync_Timer löschen • Hello_Sync_Timer löschen • Hello_Dead_Interval_Timer löschen
Aktiv	Hello empfangen (1)	• Im Status „Aktiv" verharren • Aktuelle Empfangs-K-Bytes speichern • Nachricht Hello_Ack mit aktuellen Sende-K-Bytes an Peer senden • Hello_Sync_Timer zurücksetzen • Hello_Dead_Interval_Timer zurücksetzen
Aktiv	Client Hello empfangen (2)	• Im Status „Aktiv" verharren • Aktuelle Sende-K-Bytes speichern • Nachricht Hello_Ack mit aktuellen Empfangs-K-Bytes an Client senden • Client_Hello_Dead_Interval_Timer zurücksetzen
Aktiv	Hello Ack empfangen (3)	• Im Status „Aktiv" verharren • Aktuelle Empfangs-K-Bytes speichern • Hello_Sync_Timer zurücksetzen • Hello_Dead_Interval_Timer zurücksetzen
Aktiv	Client Hello Ack empfangen (4)	• Im Status „Aktiv" verharren • Aktuelle Sende-K-Bytes speichern • Client_Hello_Sync_Timer löschen • Client_Hello_Dead_Interval_Timer zurücksetzen

Aktiv	Hello Nak empfangen (5)	• Status auf „Sync" setzen • Aktuelle Empfangs-K-Bytes auf NULL setzen • Hello_Sync_Timer zurücksetzen • Hello_Dead_Interval_Timer löschen
Aktiv	Client Hello Nak empfangen (6)	• Status auf „Nicht aktiv" setzen • Aktuelle Empfangs-K-Bytes auf NULL setzen • Aktuelle Sende-K-Bytes auf NULL setzen • Client_Hello_Sync_Timer löschen • Client Hello_Dead_Interval_Timer löschen • Hello_Sync_Timer löschen • APS_Change_Nak_Timer löschen • Hello_Dead_Interval_Timer löschen
Aktiv	APS Change empfangen (7)	• Im Status „Aktiv" verharren • Aktuelle Empfangs-K-Bytes speichern • Nachricht APS Change Ack mit aktuellen Sende-K-Bytes an Peer senden • Nachricht APS Change mit aktuellen Empfangs-K-Bytes an Client senden • Client_APS_Change_Ack_Timer setzen • Hello_Sync_Timer zurücksetzen • Hello_Dead_Interval_Timer zurücksetzen
Aktiv	Client APS Change empfangen (8)	• Im Status „Aktiv" verharren • Aktuelle Sende-K-Bytes speichern • Nachricht APS Change mit aktuellen Sende-K-Bytes an Peer senden • Nachricht APS Change Ack mit aktuellen Empfangs-K-Bytes an Client senden • Hello_Sync_Timer löschen • APS_Change_Ack_Timer setzen • Client_Hello_Dead_Interval_Timer zurücksetzen
Aktiv	APS Change Ack empfangen (9)	• Im Status „Aktiv" verharren • Aktuelle Empfangs-K-Bytes speichern • APS Change_Ack Timer löschen • Hello_Sync_Timer setzen • Hello_Dead_Interval_Timer zurücksetzen
Aktiv	Client APS Change Ack empfangen (10)	• Im Status „Aktiv" verharren • Aktuelle Sende-K-Bytes speichern • Client_APS_Change_Ack_Timer löschen • Client_Hello_Dead_Interval_Timer zurücksetzen

Aktiv	APS Change Nak empfangen (11)	• Status auf „Sync" setzen • Aktuelle Empfangs-K-Bytes auf NULL setzen • APS Change_Ack Timer löschen • Nachricht Hello mit aktuellen Sende-K-Bytes an Peer senden • Hello_Sync_Timer setzen • Hello_Dead_Interval_Timer löschen
Aktiv	Client APS Change Nak empfangen (12)	• Status auf „Nicht aktiv" setzen • Aktuelle Empfangs-K-Bytes auf NULL setzen • Aktuelle Sende-K-Bytes auf NULL setzen • Client APS_Change_Nak_Timer löschen • Client_Hello_Dead_Interval_Timer löschen • Hello_Sync_Timer löschen • APS_Change_Nak_Timer löschen • Hello_Dead_Interval_Timer löschen
Aktiv	Hello Sync Timeout empfangen (13)	• Im Status „Aktiv" verharren • Nachricht Hello mit aktuellen Sende-K-Bytes an Peer senden • Hello_Sync_Timer setzen
Aktiv	Client Hello Sync Timeout empfangen (14)	• Im Status „Aktiv" verharren • Nachricht Hello mit aktuellen Empfangs-K-Bytes an Client senden • Client_Hello_Sync_Timer setzen
Aktiv	Hello Dead Interval Timeout empfangen (15)	• Status auf „Sync" setzen • Aktuelle Empfangs-K-Bytes auf NULL setzen • Nachricht Hello mit aktuellen Sende-K-Bytes an Peer senden • APS_Change_Ack_Timer löschen • Hello_Sync_Timer löschen • Hello_Sync_Timer setzen
Aktiv	Client Hello Dead Interval Timeout empfangen (16)	• Status auf „Nicht aktiv" setzen • Aktuelle Empfangs-K-Bytes auf NULL setzen • Aktuelle Sende-K-Bytes auf NULL setzen • Client_APS_Change_Nak_Timer löschen • Client_Hello_Sync_Timer löschen • Hello_Sync_Timer löschen • APS_Change_Nak_Timer löschen • Hello_Dead_Interval_Timer löschen
Aktiv	APS Change Ack Timeout empfangen (17)	• Im Status „Aktiv" verharren • Nachricht APS_Change mit aktuellen Sende-K-Bytes an Peer senden • APS_Change_Ack_Timer setzen
Aktiv	Client_APS_Change_Ack_Timeout	• Im Status „Aktiv" verharren • Nachricht APS_Change mit aktuellen Empfangs-K-Bytes an Client senden • Client_APS_Change Ack Timer setzen

Zur Illustration des KBPS zeigen die 11 und 12 die Szenarien des Nachrichtenflusses. 11 zeigt einen Verlauf von Synchronisationsnachrichten. Zum Zeitpunkt t0 empfängt die NE0 KBPS-Client-Statusmaschine 40 eine Initialisierungsnachricht, ebenso der NE0 APS-Signalcontroller 30. Als Reaktion auf den Empfang der Initialisierungsnachricht sendet die NE0 KBPS-Client-Statusmaschine 40 ein Client_Hello an den NE0 APS-Signalcontroller 30 (der in den Status „Aktiv" wechselt). Der APS-Signalcontroller 30 reagiert durch Senden eines Hello_Ack an die NE0 KBPS-Client-Statusmaschine 40 und einer Nachricht Hello an den NE1 APS-Signalcontroller 30. Außerdem wechselt der NE0 APS-Signalcontroller in den Status „Sync". Der NE1 APS-Signalcontroller 30 empfangt eine Initialisierungsnachricht zum Zeitpunkt t1, ist jedoch immer noch im Status „Nicht aktiv", wenn er das Hello vom NE0 APS-Signalcontroller empfängt; er sendet daher ein Hello_Nak an den NE0 APS-Signalcontroller 30.
Zum Zeitpunkt t2 empfangt die NE1 Client-Statusmaschine 40 eine Initialisierungsnachricht und reagiert durch Senden einer Nachricht Client_Hello an den NE1 APS-Signalcontroller 30.
Der NE1 APS-Signalcontroller 30 reagiert durch Senden eines Hello_Ack an die NE1 Client-Statusmaschine 40 (die in den Status „Aktiv" wechselt) und eines Hello an den NE0 APS-Signalcontroller 30, wenn sie in den Status „Sync" wechselt. Nach dem Empfang des Hello sendet der NE0 ein Hello an die NE0 Client-Statusmaschine 40 (die mit einem Client_Hello_Ack antwortet) und ein Hello_Ack an den NE1 APS-Signalcontroller 30. Der APS-Signalcontroller 30 wechselt ebenfalls in den Status „Aktiv".
Nach dem Empfang des Hello_Ack wechselt der NE1 APS-Signalcontroller 30 in den Status „Aktiv" und sendet ein Hello an die NE1 Client-Statusmaschine 40. Die NE1 Client-Statusmaschine 40 sendet ein Client_Hello_Ack.
12 zeigt einen APS-Änderungs-Nachrichtenverlauf. Die NE0 Client-Statusmaschine 40, der NE0 APS-Signalcontroller 30, die NE1 Client-Statusmaschine 40 und der NE1 APS-Signalcontroller 30 sind alle im Status „Aktiv". Ein Client_APS_Change wird an der NE0 Client-Statusmaschine 40 von der Schutzstatusmaschine 38 empfangen. Die NE0 Client-Statusmaschine 40 sendet die Nachricht Client_APS_Change mit den aktuellen K-Bytes an den NE0 APS-Signalcontroller 30. Als Reaktion auf den Empfang der Nachricht Client_APS_Change von der NE0 Client-Statusmaschine 40 sendet der NE0 APS-Signalcontroller 30 die Nachricht APS_Change_Ack an die Client-Statusmaschine 40 sowie eine Nachricht APS_Change an den NE1 APS-Signalcontroller 30 mit den aktuellen Sende-K-Bytes. Der NE1 APS-Signalcontroller 30 speichert die aktiven Empfangs-K-Bytes und antwortet dem NE0 APS-Signalcontroller 30 mit einem APS_Change_Ack. Der NE1 APS-Signalcontroller 30 sendet die Nachricht APS_Change an die NE1 Client-Statusmaschine 40. Die NE1 Client-Statusmaschine 40 antwortet mit einem Client_APS_Change_Ack an den NE1 APS-Signalcontroller 30 mit den aktuellen Sende-K-Bytes und leitet die empfangenen K-Bytes an die entsprechende Schutzstatusmaschine 38 weiter.
Die vorliegende Erfindung bietet erhebliche Vorteile gegenüber dem Stand der Technik. Zunächst kann ein transparentes Netzwerkelement mithilfe zuvor entwickelter und in der Praxis getesteter Schutzstatusmaschinen entworfen werden. Die Client-Statusmaschine und der APS-Signalcontroller geben die Steuerungsinformationen über ein Außerfaser- und Außerband-Netzwerk in einer Weise weiter, dass die von den Schutzstatus maschinen empfangenen K-Bytes in einem Standardformat vorliegen. Zum Zweiten kann eine neue Schutzstatusmaschine wie beispielsweise eine gemeinsame Schutzring-Statusmaschine problemlos hinzugefügt werden, ohne dass dies den Betrieb weiterer Schutzstatusmaschinen beeinträchtigt.
Auch wenn die ausführliche Beschreibung der Erfindung sich an bestimmten exemplarischen Ausführungsformen orientiert, sind verschiedene Änderungen dieser Ausführungsformen sowie alternative Ausführungsformen für den Fachmann klar ersichtlich. Die Erfindung umfasst alle Änderungen und alternativen Ausführungsformen im Rahmen des Anwendungsbereichs der Patentansprüche.

3

20: Netzwerkelement
22: Steuerungskommunikation
26: OAM&P
28: IP-Netzwerkkommunikation
30: APS-Signalcontroller
24: Datenkommunikation
40: KBSP-Client-Statusmaschine
38: PSM
36: OXC-Steuerung
40: KBSP-Client-Statusmaschine
38: PSM
32: E/A- und Fehlererkennung
34: OXC
32: E/A- und Fehlererkennung
44: OF/OB-Netzwerk
20: Netzwerkelement
22: Steuerungskommunikation
28: IP-Netzwerkkommunikation
26: OAM&P
30: APS-Signalcontroller
24: Datenkommunikation
40: KBSP-Client-Statusmaschine
38: PSM
36: OXC-Steuerung
40: KBSP-Client-Statusmaschine
38: PSM
32: E/A- und Fehlererkennung
34: OXC
32: E/A- und Fehlererkennung

5

: Versionsnummer Nachrichtentyp Nachrichtenlänge Schutztyp Quellenverbindungs-ID Zielverbindungs-ID Sequenznummer Prüfsumme

6

: Fehlercode

7

: K1-Byte K2-Byte Reserviert

8

: K1-Byte K2-Byte RPG-ID Ring-ID

9

: 1, 3, 5, 6 Nicht aktiv 2 4, 8 Aktiv 1, 2, 3, 5, 6, 7, 9
: 0: mit () 1: Hello 2: Hello_Ack 3: Client_Hello_Sync_Timeout 4: Client_Hello_Dead_Interval_Timeout 5: APS_Change 6: Client_APS_Change() 7: APS_Change_Ack 8: APS_Change_Nak 9: Client_APS_Change_Ack_Timeout

10

: Nicht aktiv Sanc Aktiv
: 0: mit () 1: Hello 2: ClientHello 3: Hello_Ack 4: Client_Hello_Ack 5: Hello_Nak 6: Client_Hello_Nak 7: APS_Change 8: Client_APS_Change 9: APS_Change_Ack 10: Client_APS_Change_Ack 11: APS_Change_Nak 12: Client_APS_Change_Nak 13: Hello_Sync_Timeout 14: Client_Hello_Sync_Timeout 15: Hello_Dead_Interval_Timeout 16: Client_Hello_Dead_Interval_Timeout 17: APS_Change_Acl_Timeout 18: Client_APS_Change_Acl_Timeout

11

: I0 Init NE0 CSM Nicht aktiv Aktiv
: Client_Hello Hello_Ack Hello Client_Hello_Ack
: I0 Init NE0 ASC Nicht aktiv Sync Aktiv
: Hello Hello_Nak Hello Hello_Ack
: I1 Init NE1 ASC Nicht aktiv Sync Aktiv
: Client_Hello Hello_Ack Hello Client_Hello_Ack
: I2 Init NE Nicht aktiv Aktiv

Claims

Netzwerkelement, das Folgendes umfasst: – Eingangs-/Ausgangsschaltung (32) zum Senden und Empfangen von Datenverkehr über optische Verbindungen; – Schutzstatus-Maschine (38) zum Empfangen von Steuerungsinformationen von der Eingangs-/Ausgangsschaltung (32) mit Hinweisen auf Übertragungsfehler; und – Steuerungsschaltungen mit einer Schnittstelle auf der Client-Seite als Schnittstelle zu dieser Schutzstatus-Maschine (38) und einer Schnittstelle auf der Server-Seite als Schnittstelle zu einem Außerband-Netzwerk (44); dadurch gekennzeichnet, dass – dieses Netzwerkelement mehr als eine Status-Maschine (38) für verschiedene Schutzarten umfasst und – die Steuerungsschaltungen so angepasst sind, dass sie Fehlernachrichten von diesen Schutzstatus-Maschinen (38) empfangen und Fehlerinformationen an angrenzende Netzwerkelemente über das Außerband-Netzwerk (44) weitergeben, wobei diese Schnittstelle auf der Client-Seite Folgendes umfasst: – Schaltungen zur Kommunikation mit dieser Schnittstelle auf der Server-Seite mit einem ersten Nachrichtenformat und – Schaltungen zur Kommunikation mit einer dieser Schutzstatus-Maschinen (38) über ein zweites Nachrichtenformat abhängig von der Schutzart, die von der jeweiligen Statusmaschine (38) unterstützt wird.
Netzwerkelement gemäß Anspruch 1, wobei die Steuerungsschaltung einen automatischen Schutzschaltungs-Signalcontroller (30) umfasst und der automatische Schutzschaltungs-Signalcontroller eine Schnittstellenkomponente zwischen den Schutzstatus-Maschinen (38) und dem Außerband-Netzwerk (44) darstellt.
Netzwerkelement gemäß Anspruch 2, das des Weiteren eine Signalprotokoll-Client-Statusmaschine (40) umfasst, wobei der automatische Schutzschaltungs-Signalcontroller (30) und die Schutzstatus-Maschinen (38) über die Signalprotokoll-Client-Statusmaschine (40) kommunizieren.
Netzwerkelement gemäß Anspruch 3, wobei die Signalprotokoll-Client-Statusmaschine (40) und der automatische Schutzschaltungs-Signalcontroller (30) so angepasst sind, dass sie Steuerungsinformationen über das Außerband-Netzwerk (44) derart weitergeben, dass die Schutzstatus-Maschinen K-Bytes in einem Standardformat erhalten.
Netzwerkelement gemäß einem der vorangegangenen Ansprüche, wobei die Steuerungsschaltung für die Kommunikation von K1/K2-ähnlichen Steuerungsinformationen zwischen den Netzwerkelementen angepasst wurde.
Netzwerkelement gemäß einem der vorangegangenen Ansprüche, wobei mindestens eine der Schutzstatus-Maschinen eine im Feld getestete Schutzstatus-Maschine ist.
Netzwerkelement gemäß einem der vorangegangenen Ansprüche, wobei diese Schutzstatus-Maschinen eine Statusmaschine für die Verarbeitung von Steuerungsinformationen zu den gemeinsam genutzten Schutzspannen umfassen.
Netzwerkelement gemäß einem der vorangegangenen Ansprüche, wobei diese Schutzstatus-Maschinen eine Statusmaschine für die Verarbeitung von Steuerungsinformationen in einem K1/K2-Byte SDH-Format umfassen.
Netzwerkelement gemäß einem der vorangegangenen Ansprüche, wobei dieses erste Nachrichtenformat einen Hinweis auf eine Ringschutzgruppe umfasst und einen Hinweis auf einen Ring innerhalb der Ringschutzgruppe, wenn die Schutzart eine gemeinsame Schutzart ist und der Nachrichtentyp kein Nak.
Verfahren zur Kommunikation zwischen Netzwerkelementen (20), das die folgenden Schritte umfasst: – Senden und Empfangen von Datenverkehr über optische Verbindungen (42); – Erzeugen von Fehlernachrichten mit Hinweisen auf Übertragungsfehler für verschiedene Schutzarten in unterschiedlichen Schutzstatus-Maschinen (38); – Weitergeben von Fehlerinformationen als Antwort auf diese Fehlernachrichten an angrenzende Netzwerkelemente über ein Außerband-Netzwerk (44) über ein erstes Nachrichtenformat; wobei diese von diesen Schutzstatus-Maschinen erzeugten Fehlernachrichten ein zweites Nachrichtenformat aufweisen, abhängig von der Schutzart, die von der jeweiligen Statusmaschine (38) unterstützt wird, und wobei dieses Verfahren des Weiteren den folgenden Schritt umfasst: – Umsetzen der Fehlernachrichten in dem zweiten Format in Fehlerinformationen im ersten Format.
Verfahren gemäß Anspruch 10, wobei dieser Erzeugungsschritt das Erzeugen von Fehlernachrichten zu den gemeinsamen Schutzspannen umfasst.
Verfahren gemäß Anspruch 10, wobei dieser Erzeugungsschritt das Erzeugen von Fehlernachrichten in einem K1/K2 Byte SDH-Format umfasst.