DE60027423T2

DE60027423T2 - Kommunikationseinrichtungen

Info

Publication number: DE60027423T2
Application number: DE60027423T
Authority: DE
Inventors: Mario Molinari
Original assignee: Marconi Communications SpA
Current assignee: Ericsson AB
Priority date: 1999-06-08
Filing date: 2000-06-08
Publication date: 2006-12-14
Anticipated expiration: 2020-06-09
Also published as: US7269176B1; GB9913239D0; RU2002100064A; JP2003501947A; NO20015977D0; WO2000076121A2; EP1186138A2; EP1186138B1; CN1369159A; WO2000076121A3; AU5098400A; ZA200109799B; NO20015977L; ATE323990T1; DE60027423D1

Description

Die Erfindung betrifft eine Kommunikationsanordnung, die einen Teil eines Kommunikationssystems bildet, insbesondere, aber nicht ausschließlich eines SDH-DCN-Kommunikationssystems.
Ein typisches OSI(Open Systems Interconnection)-Wegelenkungs- oder -Routingschema, welches das so genannte "IS-IS-Routing-Protokoll" beinhaltet, ist in 1 dargestellt. In 1 ist ein Weitbereichsnetz (WAN) gezeigt, das in zwei Domänen unterteilt ist, wobei jede Domäne in zwei Bereiche aufgespalten ist. Jeder Bereich enthält eine Anzahl von Systemen, die entweder als Endsysteme (ESs) oder Zwischensysteme, so genannte Intermediate Systems (ISs), bestimmt sind. Die ESs, welche Hosts oder verschiedene Geräte (z. B. Server) darstellen können, können mit einem oder mehreren ISs über entweder Punkt-zu-Punkt- oder Rundsende-Leitungen in einem LAN (lokalen Netz) oder, für einen geographisch größeren Bereich, einem MAN (Großstadtnetz) oder WAN (Weitbereichsnetz) verbunden sein.
Das Routen von Nachrichtenpaketen von einem beliebigen ES in einem Bereich zu einem anderen ES in dem gleichen oder einem anderen Bereich erfolgt herkömmlich unter getrennten Routing-Protokollen, welche einer bestimmten Routing-Hierarchie entsprechen. Die Wegelenkung zwischen ESs und ISs erfolgt mit dem ES-IS-Protokoll, diejenige zwischen zwei beliebigen ISs in dem gleichen Bereich erfolgt über das domäneninterne oder Intradomänen-IS-IS-Protokoll (Level 1), und diejenige zwischen zwei ISs in unterschiedlichen Bereichen erfolgt über das Intradomänen-IS-IS-Protokoll (Level 2). Die Wegelenkung zwischen zwei unterschiedlichen Domänen erfolgt außerhalb des Rahmens des IS-IS-Protokolls. Das Protokoll bietet jedoch eine Möglichkeit, die Daten für das Routen zwischen Domänen an alle Zwischenbereichs-Router oder Intermediate Systems des Levels 2, wie sie genannt werden, zu verbreiten.
Gunner et al. ( US 5,491,692 ) offenbart ein Kommunikationsnetzwerk, das Endeinheiten (EUs), Verteilungseinheiten (DUs) und eine Hybrideinheit (HU) umfasst, welche für EUs als eine DU wirkt, für DUs aber als eine EU. Eine DU ist dafür ausgelegt, sowohl Pakete weiterzuleiten, die ihren Ursprung bei ihr haben, als auch Pakete, die sie von anderen Einheiten empfängt, und sie wird als einem IS entsprechend identifiziert, während die Endeinheit als einem ES entsprechend identifiziert wird. Die HU von Gunner ist dafür ausgelegt, zwischen einer DU und einer oder mehreren EUs zu sitzen, ohne den Typ von Einheit zu modifizieren, mit welcher die DU und die eine oder die mehreren EUs verbunden zu sein scheinen.
Details zu dem IS-IS-Intradomänen-Routing-Protokoll zwischen Intermediate Systems sind angegeben in der ISO/IEC-Empfehlung 10589, 1. Ausgabe (1992-06-15) "Information technology – Telecommunications and information exchange between Systems – Intermediate system to Intermediate System intra-domain routeing information exchange protocol for use in conjunction with the protocol for providing the connectionless-mode Network Service (ISO 8473)". Die ITU-T-Empfehlung G.784 (06/99) "General Aspects Of Digital Transmission Systems; Terminal Equipments" wendet sich Verwaltungsaspekten von SDH zu, darunter den Steuer- und Überwachungsfunktionen, die für SDH-Netzelemente relevant sind.
Traditionell kommen zwei Arten von Wegelenkung zur Anwendung: das statische Routing und das dynamische Routing. Bei der statischen Wegelenkung speichern einige Intermediate Systems in einer Domäne verschiedene Arten von Routing-Kriterien. Solche Kriterien werden von dem Operator manuell eingegeben und werden genutzt, um die Zieladresse eines Pakets gegenüber den Kriterien abzugleichen, um festzustellen, ob das Paket auf der Leitung, welcher die statische Route zugeordnet ist, geroutet werden kann. Bei der dynamischen Wegelenkung unterhält jedes System eine Tabelle, die den Zustand aller Routen innerhalb seines Gültigkeitsbereichs enthält. Die Tabelle wird auf kontinuierlicher Basis aktualisiert. Da die dynamische Wegelenkung anpassbar ist, indem sie unterbrochenen Verbindungen zwischen Systemen Rechnung tragen kann oder außer Dienst befindlichen Systemen Rechnung tragen kann, und da sie außerdem dezentralisiert ist, weist sie klare Vorteile gegenüber der statischen Wegelenkung auf und stellt daher die dominante Form der derzeit angewandten Wegelenkung dar, zumindest unter dem Intradomänen-IS-IS-Protokoll.
Die ISs unterteilen sich in zwei Haupttypen: Level 1 (L1), die Pakete in einem bestimmten Bereich routen, und Level 2 (L2), die Pakete zwischen Bereichen und zwischen Domänen routen. Üblicherweise weist ein L2 IS auch eine L1 Routing-Funktion auf und stellt daher eigentlich ein L1/L2 IS dar.
Damit die dynamische Wegelenkung erfolgen kann, müssen folgende Bedingungen erfüllt sein:

– Jedes IS muss über den Zustand der ihm benachbarten ESs in Kenntnis gesetzt werden. In der gleichen Weise muss jedes ES über den Zustand der ihm benachbarten ISs in Kenntnis gesetzt werden.
– Jedes L1 IS muss über die Topologie des Bereichs, dem es angehört, in Kenntnis gesetzt werden.
– Jedes L2 IS muss über die Topologie der Level-2-Subdomäne, der es angehört, in Kenntnis gesetzt werden (d. h. die Aufteilung der Domäne, die aus L2 ISs und aus den Verbindungen zwischen diesen besteht).

Um dies zu erreichen, tauschen alle End- und Intermediate Systems in der Domäne "Hallo"-Pakete aus, um zu erfahren, wer ihre Nachbarn sind. Die ISs generieren außerdem LSPs und schicken diese flutartig aus (das LSP oder die Link-State-Protokoll-Dateneinheit ist ein Paket, das die Liste der Nachbarn des erzeugenden IS enthält), sodass sie Kenntnis von der Topologie der Aufteilung des Netzwerks innerhalb ihres Gültigkeitsbereichs erlangen (wobei der Gültigkeitsbereich für Level 1 ISs der Bereich und für Level 2 ISs die Level-2-Subdomäne ist). Auf diese Weise werden die ISs in die Lage versetzt, die entsprechenden Routing-Entscheidungen sowohl auf der L1- als auch der L2-Routing-Ebene zu treffen.
Der gerade beschriebene dynamische Aktualisierungsprozess der Verbindungszustände erfolgt jedoch nicht auf der Ebene zwischen Domänen, stattdessen muss aber ein statisches Wegelenkungsverfahren angewandt werden, um Pakete von einer Domäne zu einer anderen zu routen. Um dies zu erreichen, werden die Routing-Tabellen der L2 ISs mit "erreichbaren Adress-Präfixen" oder Präfixen für erreichbare Adressen (RAPs – Reachable Address Prefixes) ausgestattet, welche entweder manuell oder mit Hilfe eines dynamischen Interdomänen-Routing-Protokolls generiert werden. Solche RAPs liefern Routing-Kriterien für die Pakete, die nicht auf Basis der verfügbaren dynamischen Routing-Informationen geroutet werden können, (da sie nach außerhalb der Domäne adressiert sind). Das Kriterium besteht darin, dass, wenn die Zieladresse des Pakets mit einem Muster beginnt, das mit einem existenten Präfix übereinstimmt, dieses auf der Leitung weitergeleitet werden kann, der ein solches Präfix zugeordnet ist (wobei sich diese Leitung als eine Domänengrenze erweisen wird).
Bei einem tatsächlichen Routing-Prüfablauf wird ein L1 IS ein Paket von einem der ihm zugeordneten ESs empfangen (man beachte, dass, wenn ein System sowohl als ein Endsystem als auch als ein Intermediate System arbeitet, sich dies ausdrückt, indem das IS einen ES-Nachbarn für sich selbst darstellt). Wenn das Paket für ein ES in dem gleichen Bereich bestimmt ist, wird es von diesem L1 IS entweder direkt oder über ein oder mehrere andere L1 ISs zu dem Ziel-ES geroutet. Wenn das Paket für ein ES außerhalb des Quellbereichs bestimmt ist, wird das L1 IS das Paket zu dem nächstliegenden L2 (oder L1/L2) IS in dem Quellbereich weiterleiten (möglicherweise, indem es über ein oder mehrere andere ISs läuft). Sobald das Paket in die L2-Subdomäne gelangt, wird es zu einem entsprechenden L2 (oder L1/L2) IS in dem Zielbereich weitergeleitet. Schließlich wird das Paket durch L1-Routen an das Ziel-ES ausgeliefert, entweder direkt oder über ein oder mehrere andere L1 ISs.
Bei einer speziellen Art von Telekommunikationssystem, nämlich dem SDH(Synchrone Digitale Hierarchie)-System wird oft eine Ringanordnung von Systemen (die in der SDH-Terminologie als "Netzelemente" bezeichnet werden) angewandt. Dies ist in 2 dargestellt, bei welcher ein Ethernet-LAN 2 mit einem Ring 10 aus Netzelementen (NEs) A, B, C und D verbunden ist (der Einfachheit halber sind nur vier gezeigt), wobei eines davon – NE A – als das "Gateway-NE" (GNE) bestimmt ist. Das GNE (auch als der "Kopf des Rings" bezeichnet) ist dasjenige NE, welches für den Element-Manager (EM) Zugang zu den anderen NEs in dem Ring bereitstellt. Der EM ist ein System (das normalerweise auf einem Computer ausgeführt wird), welches administrative Vorgänge an SDH-NEs ausführt, wie etwa Konfiguration, Alarm und Funktionsdatenverwaltung. Das DCN (digitales Kommunikationsnetz) ist dasjenige Netz, welches die Unterstützung für den Dialog zwischen dem EM und dem NEs bietet. In der Praxis können Dutzende NEs in einem Ring vorgesehen sein, und es können viele Dutzend Ringe mit einem einzelnen GNE verbunden sein. Da die meisten dieser NEs als ISs fungieren müssen (da sie Pakete zu den weiteren NEs leiten müssen), sind üblicherweise alle NEs derart konfiguriert, dass sie als ISs wirken. Außerdem können in der Praxis auch eine Reihe von GNEs in einem LAN 2 vorhanden sein (2 zeigt einen zweiten Ring 20, mit seinem eigenen GNE, dem GNE 2), und einige der NEs in einem Ring können ihrerseits eigene Teilringe aufweisen.
An jedem NE in jedem Ring ist ein Paar von Datenkommunikationskanälen (DCCs) vorgesehen, über welche dieses mit dem nächsten und dem vorhergehenden NE in dem Ring kommuniziert. Diese DCCs sind in 2 als Kanäle "1" und "2" gezeigt, die den NEs A, B, C und D zugeordnet sind.
Der Element-Manager 11, der mit einem weiteren LAN, dem LAN 1, verbunden ist, kommuniziert mit den Ringen 10 und 20 über das Datenkommunikationsnetz (DCN) 12 über einen Router stromauf des DCN sowie über einen Router 14 stromab des DCN, der mit dem LAN 2 verbunden ist. Die Router stellen effektiv ISs dar.
In der normalen Konfiguration, bei welcher eine (bereits beschriebene) dynamische IS-IS-Wegelenkung angewandt wird, liegen der Router 14, alle GNEs in dem LAN 2 und alle NEs, die über diese GNEs erreichbar sind (darunter die NEs B, C und D) in dem gleichen IS-IS-Bereich. Da sich daher eine große Anzahl von ISs in diesem Bereich ergeben kann, können Probleme bei der Wegelenkung aufgrund der Beschränkungen bezüglich der Anzahl von ISs, welche das IS-IS-Protokoll aufgrund seiner Gestaltung behandeln kann, bewirkt werden. In der Praxis wird durch das Protokoll empfohlen, dass eine typische Domäne mit maximaler Konfiguration höchstens 400 L2 ISs und höchsten 100 L1 ISs pro Bereich enthält, während die Domäne bis zu 4000 Systeme umfassen darf.
Die vorstehend genannten Einschränkungen beruhen auf der Tatsache, dass jedes der NEs in dem Bereich bei der herkömmlichen Anordnung eine vollständige Übersicht über die Topologie des Bereichs hat (wie bereits erklärt). Somit muss ein NE, das über ein GNE in einem Ring erreichbar ist (z. B. das GNE 1) alle LSPs verarbeiten, die von jedem anderen NE in jedem Ring des gleichen Bereichs generiert werden (z. B. einem der NEs in dem Ring 20), und dies kann zu verschiedenen Problemen führen, beispielsweise Erschöpfung des Speichers, Überlastung der CPU und Verkehrshäufungen aufgrund der Routing-Nachrichten (solche so genannten Bursts können insbesondere kritisch sein, wenn eine plötzliche Änderung der Netztopologie auftritt).
Die vorliegende Erfindung zielt darauf ab, diese Einschränkung zu mindern, obgleich weiterhin das standardmäßige IS-IS-Protokoll zur Anwendung kommt. Dies gelingt durch die Erkenntnis, dass es für den Rest des Netzes nicht wichtig ist, exakt die Topologie jedes Rings zu kennen. Es ist nur wichtig, dass das DCN weiß, auf welchen DCCs ein NE erreicht werden kann. Es ist in einem realen System außerdem wünschenswert, dass ein Ausfall auf einer der Verbindungen eines Rings (z. B. der Verbindung zwischen dem NE B und NE D in dem Ring 10) es nicht unmöglichen machen sollte, ein NE zu erreichen, solange die andere Route zu diesem NE noch funktioniert.
Entsprechend der Erfindung wird ein Kommunikationssystem zur Verfügung gestellt, das ein oder mehrere lokale Netze (LAN 1) umfasst, wobei ein oder mehrere Gateway-Netzelemente (GNE A) mit jedem LAN verbunden sind und ein oder mehrere weitere Netzelemente (NE B, C, D) mit einem jeweiligen Gateway-Element verknüpft sind, welche zusammen mit dem einen oder den mehreren Gateway-Netzelement(en) zumindest einen Teil eines Routing-Bereichs bilden, wobei jedes Gateway-Netzelement dafür ausgelegt ist, Zugang auf sein jeweiliges LAN bereitzustellen und als eine Schnittstelle zwischen dem einen oder den mehreren weiteren Netzelement(en) und dem einen oder den mehreren LANs zu fungieren, wobei das eine oder die mehreren weitere(n) Netzelement(e) jeweils ein Intermediate System entsprechend dem IS-IS-Routing-Protokoll umfassen, dadurch gekennzeichnet, dass das eine oder die mehreren Gateway-Elemente und das eine oder die mehreren weitere(n) Netzelement(e) derart konfiguriert sind, dass bewirkt wird, dass das eine oder die mehreren weitere(n) Netzelement(e) als Endsysteme erscheinen, soweit es den Rest des Kommunikationssystems betrifft, wogegen jedes weitere Netzelement für jedes andere weitere Netzelement in dem Routing-Bereich als ein Intermediate System erscheint, wobei die Endsysteme dem Rest des Kommunikationssystems durch Link-State-Protokoll(LSP)-Pakete bekannt gegeben werden, die von dem einen oder den mehreren Gateway-Netzelement(en) generiert werden.
Bevorzugte Merkmale und verschiedene Realisierungen der Erfindung sind in den Unteransprüchen enthalten.
Ausführungen der Erfindungen sollen nun mit Hilfe der Zeichnungen beschrieben werden, wobei:
1 ein Schema ist, das die IS-IS-Routing-Hierarchie in einer typischen Kommunikationskonfiguration darstellt;
2 eine SDH-DCN-Ringanordnung zeigt;
3 zeigt, wie der Ring 10 aus 2 für den Rest des DCN erscheint, nachdem das GNE dieses Rings derart umkonfiguriert worden ist, dass es ermöglicht, die alternative IS-IS-Wegelenkung, die durch eine erste Ausführungsform der Erfindung definiert wird, anzuwenden; die
4 bis 6 stellen alternativen Ausführungsformen der Erfindung für den Fall dar, dass ein einziges GNE beteiligt ist; und die
7 und 8 stellen alternative Ausführungsformen der Erfindung für den Fall dar, dass mehrere GNEs beteiligt sind;
9 stellt eine SDH-DCN-Ringanordnung dar;
10 stellt dar, wie der Ring aus 9 für den Rest des DCN erscheint, nachdem NEs dieses Rings derart umkonfiguriert worden sind, dass sie eine periphere Domäne entsprechend einer weiteren Ausführungsform der Erfindung bereitstellen;
11 stellt einen Ring mit acht Netzelementen dar, wovon zwei Gateways sind;
12 stellt dar, wie der Ring aus 11 für den Rest des DCN erscheint, nachdem zwei periphere Domänen erzeugt worden sind;
13 zeigt, wie sich die in 12 dargestellte Topologie ändert, wenn die Verbindung zwischen den NEs F und G ausfällt.
Eine erste Ausführung der Erfindung soll nun beschrieben werden, bei welcher das Gateway-NE für den Ring 10, d. h. das NE A, derart umkonfiguriert wird, dass bewirkt wird, dass der Ring, soweit es den Rest des DCN betrifft, als eine Anzahl von ESs erscheint, die mit dem GNE verbunden sind. Um die Umkonfiguration auszuführen, wird bei dem NE A der Merker "externe Domäne" für beide Punkt-zu-Punkt-Leitungen, die dem DCC 1 und DCC 2 zugeordnet sind, auf GILT gesetzt. Dieses Setzen des Merkers (welches von dem Protokoll normalerweise zum Setzen einer Domänengrenze vorgesehen ist) gestattet in diesem Fall die Verhinderung eines IS-IS-Routings zum Rest des Rings 10. Außerdem werden durch den Operator manuell Endsystem-Umgebungen für die NEs B, C und D sowohl an dem DCC 1 als auch an dem DCC 2 des NE A eingegeben, sodass der Rest des Netzwerks die NEs B, C und D als ESs "sieht", die über den DCC 1 oder 2 erreichbar sind. Eine manuelle ES-Umgebung stellt eine statische Route dar, die manuell an einem IS eingegeben werden kann, um zu deklarieren, dass ein oder mehrere ESs im gleichen Bereich Nachbarn des IS auf einer gegebenen Leitung sind. Im Ergebnis dessen wird die Topologie, die in 3 dargestellt ist, bei welcher die NEs B, C und D als ESs erscheinen, die direkt an die DCCs 1 und 2 des GNE A angeschlossen sind, dem Rest des Systems mittels LSPs bekannt gegeben, die von dem GNE generiert werden.
Da bei dem NE A nun an dem DCC 1 und 2 der Merker "externe Domäne" gesetzt ist, werden keine IS-IS-LSPs auf den Ring weitergeleitet. Im Ergebnis dessen gibt es bei dieser Anordnung keinen Overhead aufgrund einer Verarbeitung, durch das GNE, von in dem Ring 10 generierten LSPs (oder in jedem anderen Ring, für welchen dieses in der Praxis als ein Gateway wirken kann), und keinen Overhead aufgrund einer Verarbeitung von auf einem anderen Ring (z. B. dem Ring 20) generierten LSPs in den NEs eines Rings (z. B. des Rings 10). Es gibt außerdem keine LSP-Bursts (die zuvor erwähnte "Überflutung"), in welche der Ring 10 einbezogen ist.
Obgleich das NE A geeignet umkonfiguriert worden ist, um aus dem Ring 10 effektiv eine separate Domäne zu machen, reicht dies an sich nicht aus, um ein funktionierendes System zu schaffen, da die anderen NEs in dem Ring, die NEs B, C und D, immer noch als normale ISs eingerichtet sind, welche sich auf den Empfang dynamischer Routing-Informationen aus dem Rest des Netzes verlassen, und jetzt gibt es keinen Austausch solcher dynamischen Routing-Informationen, in die dieser Ring einbezogen ist. Um beispielsweise dem NE B zu ermöglichen, Pakete aus dem Ring 10 heraus zu senden, wird dieses (manuell) als Level 2 (L2) IS konfiguriert, wobei dessen Attributmerker "externe Domäne" an dessen eigener DCC-1-Leitung auf GILT gesetzt wird. Außerdem wird für dieses auf dem gleichen DCC ein RAP (Präfix für erreichbare Adressen) der Länge Null bereitgestellt. Ein Präfix der Länge Null ist ein RAP, welcher für jede Zieladresse passt. Somit wird ein Paket mit einer beliebigen Zieladresse, das von dem NE B aus dem Ring heraus gesendet werden soll, automatisch zu dem Gateway NE A durchgeleitet, und heraus zu dem Rest des Netzwerks.
Ein analoger Prozess wird auf das NE C angewandt, d. h. dessen Attribut "externe Domäne" wird auf GILT gesetzt und es erhält ebenfalls einen Präfix der Länge Null, diesmal aber beides an der Leitung DCC 2, da dies die Leitung ist, welche unmittelbar mit dem NE A verbunden ist.
Was das NE D betrifft (und jedes weitere NE, das möglicherweise in dem Ring vorhanden ist), so braucht dieses überhaupt nicht manuell umkonfiguriert zu werden, sondern kann als ein normal konfiguriertes L1 IS beibehalten werden, ohne manuelle Routing-Informationen (d. h. ohne RAPs und ohne manuelle Umgebungen). In der Praxis wird das NE D seinen gesamten ausgehenden Verkehr zu entweder dem NE B oder dem NE C leiten, da diese NEs aufgrund ihrer RAP-Einstellung jeweils eine Auswärtsroute aufweisen. Das NE B oder C leitet seinerseits die Pakete, die es empfängt, zu dem NE A weiter. Sobald die Pakete an dem NE A sind, werden sie alle an ihren Bestimmungsort ausgeliefert, und zwar über eine normale dynamische IS-IS-Wegelenkung, da das NE A eine dynamisch abgeleitete Kenntnis zu der vor ihm befindlichen DCN-Topologie besitzt.
Was den eingehenden Verkehr betrifft, der in den Ring hereinkommt, so liefert das NE A jedes Paket, das an eines der NEs adressiert ist, für welches bei ihm manuelle Umgebungen konfiguriert sind, entweder auf dem DCC 1 oder auf dem DCC 2 aus. Der Rest des Netzwerks erhält Kenntnis von diesen Umgebungen, da diese in den LSPs des Levels 1 (bereichsintern, d. h. L1) von den NEs B und C zu dem Gateway übermittelt werden und von dort zum Rest des Systems weitergeleitet werden. Somit weiß der Rest des Netzwerks, dass Pakete mit einer Ring-10-Adresse an das Gateway-NE A zu senden sind.
Als erklärender Fakt sollte angemerkt werden, dass, obgleich die NEs in dem Ring für den Rest des DCN als ESs erscheinen, diese im Inneren des Rings füreinander weiterhin als eine als Ring konfigurierte Reihe von ISs innerhalb einer separaten "Domäne" erscheinen. Somit findet eine normale dynamische Wegelenkung innerhalb des Rings statt, aber nicht zwischen dem Ring und dem Rest des Systems.
Bis hierher wurde eine Basisausführung der Erfindung beschrieben. In der Realität bringt dieser neue Ansatz jedoch eine Reihe von Nachteilen mit sich. Diese sind:

(1) Es ist notwendig, an dem NE A für jedes NE in dem Ring zwei manuelle Endsystem-Umgebungen einzurichten. Da viele Elemente in dem Ring vorhanden sein können, stellt dies einen unerwünschten Verwaltungsaufwand im Hinblick auf die Intervention von technischem Personal dar.
(2) Da die manuellen Umgebungen statisch sind, gibt es keine dynamische Wiederherstellung beim Ausfall einer Verbindung in dem Ring. Tatsächlich besteht die Stärke der dynamischen Wegelenkung darin, dass ein solcher Ausfall umgangen werden kann. Es kann jedoch eine gewisse Fehlerbehebung für die dem Gateway benachbarten Verbindungen stattfinden. Für diese Leitungen ist es möglich, die Datenübertragungsverbindung zu überwachen, angenommen, dass der auf der Data Link Layer (Sicherungsschicht) gestattete Transferdienstmodus der AITS (Acknowledged Information Transfer Service) ist. In diesem Fall erweist sich die Sicherungsschicht als verbindungsorientiert. Unter diesen Umständen wird ein Verbindungsausfall prompt gegenüber der Network Layer (Vermittlungsschicht) und daher dem Gateway signalisiert. (Die Sicherungsschicht und die Vermittlungsschicht stellen die Schichten 2 und 3 des OSI-Systems dar.)
(3) Unter dem normalen domäneninternen IS-IS-Routing sollte ein Paket, das seinen Ursprung in einem Teil eines Bereichs hat und eine Adresse trägt, die in einem anderen Teil des gleichen Bereichs liegt, (mittels L1-IS-Routing) zu dem Zielbereich geroutet werden. Im vorliegenden Fall kann es jedoch passieren, dass eine Nachricht, die in dem Ring 10 generiert wird und an ein NE außerhalb des Rings, aber in dem gleichen Bereich (z. B. in dem Ring 20 aus 3) adressiert ist, von dem Ursprungs-NE verworfen wird. Dies ist der Fall, weil der Ring 10 als eine separate Domäne außerhalb des Gültigkeitsbereichs des L1-Routings wirkt.

Wir wenden uns nun einer Lösung für diese Nachteile zu.
Overhead für manuelle Endsystem-Umgebung
Die hier vorgeschlagene Lösung besteht darin, einem Nutzer zu gestatten, an dem Gateway-NE einen statischen Routendatensatz einzugeben, welcher eine manuelle Umgebung definiert, die einen oder mehrere Bereiche fortlaufender Systemkennungen abdeckt. Wenn es also möglich ist, einen statischen Routendatensatz zu definieren, welcher bis zu sagen wir drei Bereiche von bis zu sagen wir 255 Systemkennungen gestattet, könnte der Nutzer mit nur einem einzigen Dateneintrag statische Routen für bis zu 765 NEs eingeben, die über einen gegebenen DCC erreicht werden können. Diese Lösung setzt voraus, dass der Netzadressierungsplan in einer solchen Weise gestaltet ist, dass sukzessive Systemkennungen für die NEs, die zu dem gleichen Ring gehören, vorhanden sind. (Es kann jedoch auch einige Lücken in den Reihen geben). In der Praxis stellt dies keine reale Einschränkung für den Netzadressierungsplan dar, da diese "Sukzessivitäts"-Einschränkung normalerweise sowieso bereits erfüllt ist.
Wiederherstellungsmechanismus für statisches Routing
In der normalen Wegelenkungs-Praxis wird die Entscheidung, ob das GNE A ein eingehendes Paket zu sagen wir dem NE D auf seiner Leitung DCC 1 oder seiner Leitung DCC 2 sendet, von dem Metrikvergleich der beiden Routen abhängen. Die Metrik stellt ein Maß für die Kosten des Einrichtens einer Route über eine bestimmte Leitung entsprechend einem bestimmten gewählten Kriterium dar. Mögliche Kriterien sind: die Kapazität der Leitungen zum Abwickeln von Verkehr (dies ist die normalerweise verwendete "Standard"-Metrik), die Durchgangslaufzeit der Leitung, die in Geld bemessenen Kosten der Nutzung der Leitung oder die Restfehlerwahrscheinlichkeit der Leitung. Welche Metrik auch immer genutzt wird, es wird die billigste Leitung gewählt. Bei der vorgeschlagenen statischen Konfiguration ist die von dem GNE A zwischen dem DCC 1 und 2 getroffene Auswahl eine zufällige, da die beiden DCCs zufällig eine manuelle Umgebung zu dem Ziel mit den gleichen metrischen Kosten haben. Unter der normalen dynamischen Wegelenkung würde, wenn eine von zwei möglichen Leitungen "betriebsunfähig" (nicht funktionsfähig) wäre, dies dem betreffenden NE dynamisch mitgeteilt werden, sodass dieses dann die andere wählen würde, ungeachtet dessen, ob diese die "beste" (metrisch gesprochen) Route wäre. Unter der statischen Wegelenkung ist dies nicht möglich, mit dem Ergebnis, dass das NE in jedem Fall versuchen wird, ein Paket über die "beste" Route zu senden, selbst wenn diese "betriebsunfähig" ist.
Wenn nun die Verbindung zwischen A und B oder zwischen A und C ausfällt, wird das GNE hinsichtlich dieses Ausfalls von der Sicherungsschicht in Kenntnis gesetzt (angenommen, das Schicht-Zwei-Protokoll ist verbindungsorientiert, was notwendig ist, damit die Wiederherstellung funktioniert). In diesem Fall geht die manuelle Umgebung an der ausgefallenen Leitung außer Betrieb, sodass automatisch die andere Leitung gewählt wird. Wenn aber die Leitung zwischen B und D oder zwischen C und D ausfällt, gibt es keine Möglichkeit für das GNE, dies zu wissen (da es kein dynamisches Wissen bezüglich der Ringtopologie mehr gibt). In diesem Fall wird, wenn beispielsweise die Verbindung zwischen B und D ausfällt und A ein Paket an B sendet, das an D adressiert ist, B das Paket zurück an A senden. Tatsächlich ist die einzig mögliche Route für das Paket bei B der Präfix der Länge Null zu A. Wenn A sich dafür entscheidet, das Paket weiterhin an B zu senden, kommt dieses in eine Routing-Schleife hinein, bis seine Lebenszeit abläuft und es verworfen wird.
Die hier vorgeschlagene Lösung besteht in dem nachstehenden Upgrade für die Implementierung des Weiterleitungsprozesses an dem NE. Nehmen wir an, dass die folgenden Bedingungen zutreffen:

1. das NE muss ein Paket unter Nutzung einer manuellen Umgebung weiterleiten;
2. es gibt zwei manuelle Umgebungen, sagen wir ADJ-1 und ADJ-2, welche für die Zieladresse des Pakets passen;
3. ADJ-1 und ADJ-2 haben die gleichen metrischen Kosten; und
4. das Paket wurde auf der Leitung, die ADJ-1 (ADJ-2) zugeordnet ist, empfangen.

In dieser Situation leitet das NE das Paket auf ADJ-2 (ADJ-1) weiter, sodass, wenn es das erste Mal auf dem "falschen" DCC gesendet wird (im vorstehenden Beispiel in Richtung B), es, wenn es zurückkommt, auf dem richtigen gesendet wird (in diesem Fall in Richtung C).
Schutz für bereichsinternes Routing
Wenn ein Paket eine Adresse trägt, die in dem Bereich liegt, in welchem dieses seinen Ursprung hat, aber außerhalb des Rings, ist für das Paket vorgesehen, dass dieses nicht durch das Level-1-Routing verworfen wird, wenn von dem L1 IS, welches das Paket abwickelt, ein "angegliederter" Level-2-Router erreicht werden kann (d. h. ein L2 IS, welches für sich deklariert, Zugang auf andere Bereiche zu haben – in diesem Fall auf eines der NEs, die mit dem GNE verbunden sind).
Diese Verbesserung gilt für das kleine DCN, bei dem der EM und alle NEs in den gleichen Bereich passen, sowie für alle DCNs, bei welchen es notwendig ist, Pakete von einem Ring zu einem weiteren zu routen.
Obgleich die Erfindung weitestgehend mit Bezug auf eine einfache Ringkonfiguration erklärt worden ist, wie sie in 1 dargestellt ist, ist die Erfindung nicht auf nur solche Konfigurationen beschränkt. Tatsächlich ist sie überhaupt nicht auf Ringtopologien beschränkt.
Die 4 bis 9 stellen weitere Ausführungen der Erfindung in einem SDH-DCN-Aufbau dar. In 4a ist eine Anordnung gezeigt, bei der ausschließlich die dynamische IS-IS-Wegelenkung genutzt wird, wobei, wie zuvor, ein Element-Manager 11 mit einem Ethernet-LAN (LAN 1) verbunden ist und von dort über Router 13, 14 und ein DCN 12 mit einem zweiten LAN (LAN 2). In diesem Fall ist jedoch an einem Gateway-NE, dem GNE A, an dessen DCC 1 ein Netz angeschlossen, welches die ISs B, C, D und E umfasst, wobei die Elemente C, D und E einen herkömmlichen Ring bilden, und an dessen DCCs 2 und 3 ist außerdem ein Ring angeschlossen, der die ISs F, G, H und I umfasst, wobei an das Element I seinerseits ein Ring angeschlossen ist, der aus den ISs L und M besteht.
Gemäß der vorliegenden Erfindung wird die gegebene IS-Konfiguration genommen und die ISs an dem DCC 1 werden als eine Gruppe von ESs abgespalten, die auf diesem DCC erreichbar sind, und die ISs auf den DCCs 2 und 3 als weitere Gruppe von ESs. Eine manuelle ES-Umgebung für die Systeme B, C, D und E wird von dem Operator an der dem DCC 1 zugeordneten Leitung eingegeben, für welche außerdem das Attribut "externe Domäne" gesetzt wird. Zwei weitere manuelle ES-Umgebungen für die Systeme F, G, H, I, L und M werden an den Leitungen eingegeben, die den DCCs 2 und 3 zugeordnet sind. Zusätzlich werden die Elemente B, F und G als L2 ISs bestimmt, und diese erhalten an ihren Leitungen, die mit dem GNE verbinden, RAPs der Länge Null, wobei für diese Leitungen ebenfalls das Attribut "externe Domäne" auf GILT gesetzt wird. Die Topologie, die von dem GNE mittels seiner eigenen LSPs für den Rest des DCN angezeigt wird, ist in 4b gezeigt.
In diesem Fall sollte angemerkt werden, dass, soweit der Teil des DCN, der auf dem DCC 1 erreicht wird, betroffen ist, es nur eine Grenze gibt, da nur ein DCC beteiligt ist. Das bedeutet, dass keine "Redundanz" vorhanden ist und daher eine Unterbrechung in irgendeiner Verbindung nicht umgangen werden kann, im Gegensatz zu dem Fall, bei dem ein Ausfall einer Verbindung oder eines Systems auftritt, die über den DCC 2/3 erreichbar sind.
5a zeigt eine Konfiguration, bei der GNEs von dem DCN nicht über Ethernet, sondern mit Hilfe des DCC direkt erreicht werden. Bei dem gezeigten Aufbau umfasst eine ADM-4-Anordnung die NEs B und C, welche für einen STM-4-Ring als Nicht-Gateway-NEs und gleichzeitig für eine Anzahl von STM-1-Teilringen 24, 25 und 26 als GNEs wirken. Es sei angenommen, dass eine dynamische Wegelenkung für den STM-4-Ring aufrechterhalten werden soll, aber nicht für die anderen. Die Erfindung kommt hier derart ins Spiel, dass sich 5b ergibt. In 5b ist jeder der STM-1-Teilringe 24, 25 und 26 wie zuvor beschrieben umgewandelt, indem die Elemente B und C zu "lokalen" GNEs für ihre jeweiligen Ringe geworden sind. Das Attribut "externe Domäne" wird für die DCCs 1 und 2 bei B auf GILT gesetzt (und für die DCCs 3 und 4 bei C), und bei B und C werden von dem Operator ES-Umgebungen für die keine Gateways darstellenden NEs eingegeben. Diese Umgebungen sind zu den NEs I und J in dem Ring 24, D und E in dem Ring 25 sowie F, G und H in dem Ring 26 gerichtet. Wie zuvor werden für alle diese Elemente (außer dem Element G) Präfixe der Länge Null an den Leitungen eingerichtet, welche diese mit ihren jeweiligen GNEs verbinden, für welche der Merker "externe Domäne" ebenfalls auf GILT gesetzt ist, und sie werden alle als L2 ISs konfiguriert, außer G. Das NE G wird nicht umkonfiguriert, sondern wird als ein L1 NE beibehalten.
Eine "bus"-artige Topologie, wie die in 6a dargestellte, wird entsprechend der Erfindung zu der in 6b gezeigten Konfiguration transformiert. Hierbei wird eine manuelle Endsystem-Umgebung für B, C, D und E an dem GNE A für den DCC, welcher dieses mit B verbindet, eingegeben. Außerdem wird das Attribut "externe Domäne" auf der Leitung gesetzt, welche diesem DCC zugeordnet ist. Das NE B wird derart umkonfiguriert, dass es als ein L2 IS wirkt, wobei der Leitung des DCC, welcher B mit A verbindet, ein Präfix der Länge Null zugeordnet wird, für welche Leitung ebenfalls das Attribut "externe Domäne" gesetzt wird. An den anderen NEs wird keine Umkonfiguration benötigt.
Die Erfindung kann auch auf eine Topologie angewandt werden, bei welcher zwei GNEs vorhanden sind, wie sie in 7 dargestellt ist. In 7a bilden die GNEs A und F eine Schnittstelle mit jeweiligen LANs 1 und 2 und bilden einen Ring mit den ISs B, C, D und E. In diesem Fall müssen manuelle Endsystem-Umgebungen, die den Leitungen zugeordnet sind, welche die DCCs 1 der GNEs A und F nutzen, in diesen GNEs für die NEs B und C eingegeben werden. In der gleichen Weise müssen manuelle Endsystem-Umgebungen, die den Leitungen zugeordnet sind, welche die DCCs 2 der GNEs A und F nutzen, in diesen GNEs für die NEs D und E eingegeben werden. Wieder werden die entsprechenden Attribute "externe Domäne" gesetzt, und es werden RAPs der Länge Null bei B, C, D und E bereitgestellt, welche außerdem bestimmt werden, als L2 ISs zu wirken. (Siehe 7b).
Man beachte, dass hierbei manuelle Umgebungen nur zu NEs hin erzeugt werden, die auf einem gegebenen DCC erreichbar sind, ohne ein weiteres GNE zu kreuzen. So werden in 7 keine Umgebungen für die NEs B und C in Verbindung mit dem DCC 2 des GNE A erzeugt, da diese NEs auf diesem DCC nur durch Kreuzen des GNE F erreichbar sind.
Bei dieser speziellen Konfiguration ist der Ring anfällig für Probleme, die sich aus einem Ausfall einer einzigen Verbindung oder einem anderen Ausfall in dem Ring ergeben. Um diesen Nachteil zu kompensieren, ist es möglich, die Prinzipien anzuwenden, die in der gleichzeitig anhängigen GB-Patentanmeldung GB 9805247.5 , mit Prioritätsdatum 21. Juli 1997 und im Namen von GPT Limited eingereicht, verkörpert sind, wobei die Anmeldung den Titel "M A Alternate Routing" trägt.
8a zeigt einen Fall, bei welchem drei GNEs vorhanden sind (A, B, C). Es sei angenommen, dass diese GNEs alle in den gleichen Bereich passen, welcher außerdem die Router 13, 14 und 15 enthält. Die Tatsache, dass die externen Router alle in den gleichen Bereich passen, bedeutet, dass entweder der Bereich verbunden ist (d. h. dass es möglich ist, von einem beliebigen Router zu einem beliebigen anderen zu gelangen, indem ein DCN-Pfad verfolgt wird, der nur über in dem Bereich vorhandene Router läuft) oder dass er unterteilt ist, in welchem Fall die externen Router das Partitionsreparaturmerkmal des IS-IS-Protokolls implementieren müssen. In diesem Fall wird durch die vorliegende Erfindung die Topologie derart umkonfiguriert, dass man zu dem Schema aus 8b gelangt, bei welchem manuelle Umgebungen eingerichtet sind, wie sie jetzt beschrieben werden sollen:

1. GNE A: eine manuelle Umgebung an dem DCC 1 zu den NEs D, E und F hin und eine an dem DCC 2 für die NEs K und L;
2. GNE B: eine manuelle Umgebung an dem DCC 1 zu den NEs K und L hin sowie eine an dem DCC 2 für die NEs G, H, I und J;
3. GNE C: eine manuelle Umgebung an dem DCC 1 zu den NEs G, H, I und J hin sowie eine an dem DCC 2 zu den NEs D, E und F hin.

Bei den DCCs der GNEs und bei den Leitungen der NEs D, F, K, L, G und J, welche mit den GNEs verbunden sind, werden Merker "externe Domäne" gesetzt, und gleichzeitig werden an diesen Leitungen entsprechende RAPs der Länge Null eingerichtet.
Eine Erweiterung des Schemas aus 8 auf eine größere Anzahl von GNEs als drei ist leicht zu implementieren, wenn die folgende Bedingung erfüllt wird, nämlich dass manuelle Umgebungen an allen GNEs nur für diejenigen NEs geschaffen werden, die zwischen diesen und den nächstliegenden GNEs auf dem gleichen Ring eingeschlossen sind.
Die Einschränkung, dass die GNEs in dem gleichen Bereich liegen müssen, kann auf den ersten Blick als restriktiv erscheinen, diese wird in der Praxis aber oft kein Problem darstellen, da die Anzahl von agierenden ISs entsprechend der Erfindung nicht groß sein wird, angesichts der Tatsache, dass die meisten NEs letztlich für den Rest des DCN als ESs erscheinen werden. Es kann also ein recht großer Bereich abgedeckt werden, ohne dass die von dem TS-IS-Protokoll empfohlene maximale Anzahl von ISs überschritten wird.
Entsprechend den vorstehend beschriebenen Ausführungsformen, welche als eine "Lösung mit statischem Routing" betreffend typisiert werden können, ist es notwendig, eine Anzahl von statischen Routen in dem Gateway-Netzelement zu konfigurieren. Dies kann für den Operator zu einem beträchtlichen Verwaltungsaufwand werden, insbesondere, wenn die DCN-Topologie beträchtlichen Änderungen unterliegt. Die "Lösung mit statischem Routing" ist nicht so gut für Topologien geeignet, bei welchen mehrere Gateways vorhanden sind. Für solche Topologien kann ein Ausfall einer Verbindung bewirken, dass ein Teil des DCN unerreichbar wird, selbst wenn weiterhin physikalische Routen existieren. Die "Lösung mit statischem Routing" ist außerdem nicht so gut geeignet für Topologien, bei denen ein Teil des DCN über mehr als zwei Leitungen zugänglich ist, die an dem gleichen Gateway konfiguriert sind. Das Problem ist wiederum eines, das die Fehlertoleranz betrifft.
Den vorstehenden Problemen wird dadurch begegnet, dass entsprechend einer weiteren bevorzugten Ausführungsform der vorliegenden Erfindung eine als geistiges Eigentum geschützte Erweiterung in die von der IS-IS-Protokoll-Empfehlung beschriebene Netzarchitektur eingeführt wird. Eine solche Erweiterung muss an allen Netzelementen implementiert werden, die einem Gateway-Netzelement benachbart sind (d. h. direkt mit diesem verbunden sind). Am Rest der Übertragungsausrüstung (d. h. weder an den Gateway-Netzelementen noch an den keine Gateways darstellenden Netzelementen, die nicht direkt mit einem der Gateways verbunden sind) braucht keine Änderung zu erfolgen.
Die Lösung entsprechend dieser weiter bevorzugten Ausführungsform basiert auf der Definition von "peripheren Domänen". Eine periphere Domäne ist als ein Teil des DCN folgendermaßen definiert:

1. Eine Gruppe von Systemen (d. h. End- und/oder Intermediate Systems) wird innerhalb eines DCN derart angeordnet, dass es kein System (weder End- noch Intermediate System) in dem DCN außerhalb der Gruppe gibt, welches über mindestens ein innerhalb der Gruppe befindliches System gehen muss, um ein anderes außerhalb der Gruppe befindliches System zu erreichen. Anders ausgedrückt erscheint die periphere Domäne für den Rest des DCN als ein Endsystem, nicht als Intermediate System: sie kann Pakete aussenden und empfangen, aber nicht diese routen.
2. Wenn mehr als eine Leitung vorhanden ist, welche die Gruppe von Systemen mit dem Rest des DCN verbindet, bietet jede dieser Leitungen Zugriff von den Systemen der Gruppe auf alle Systeme im Rest des DCN, möglicherweise mit Hilfe von Routen mit unterschiedlichen Kosten. Tatsächlich ist dies im vorstehenden Punkt 1 impliziert.
3. Alle Systeme in der Gruppe passen in einen einzigen IS-IS-Bereich, und alle Systeme außerhalb der Gruppe, die direkt über das DCN mit einem System in der Gruppe verbunden sind, passen ebenfalls in den gleichen IS-IS-Bereich wie die Systeme in der Gruppe. Man beachte, dass dies lediglich eine Verwaltungsanforderung darstellt und dass der Netzadressierungsplan generell derart ausgelegt werden kann, dass er dieser entspricht.

Ein Beispiel für eine periphere Domäne im Zusammenhang mit einem SDH-Ring soll nun mit Bezug auf die 9 und 10 beschrieben werden. In 9 können die Systeme B, C und D als eine periphere Domäne betrachtet werden, und die DCC-Kanäle B1–A2 zwischen dem GNE A und dem NE B sowie A1–C2 zwischen dem GNE A und dem NE C als die Grenzen der peripheren Domäne.
Die IS-IS-Empfehlung bietet die Möglichkeit, die Größe einer gegebenen Domäne durch Definieren von Domänengrenzen zu beschränken. Dies wird erreicht durch Einrichten (über einen Verwaltungsvorgang) des Attributs "externe Domäne" an den Leitungen, die diesen Grenzen zugeordnet sind.
In der gleichen Weise definieren wir hier die nachfolgende Erweiterung an dem Informationsmodell, das von dem Protokoll genutzt wird (mit "Informationsmodell" meinen wir den Satz von Objekten, mit welchen das Protokoll zu tun hat, dessen Attribute und zugelassene Operationen). Eine solche Erweiterung besteht aus einem neuen Attribut, das an einer Leitung eines Intermediate-Systems (IS) des Levels 2 gesetzt werden kann. Dieses Attribut wird nur an den Leitungen gesetzt, welche die periphere Domäne mit dem/den Gateway-Netzelement(en) verbinden. Beispielsweise wird in 9 das Attribut an der Leitung B1 des Systems B und an der Leitung C2 des Systems C gesetzt, aber nicht an den Leitungen A1 und A2 des Systems A. Es brauchen keine Attribute an Leitungen gesetzt zu werden, die keine Grenzen der peripheren Domäne darstellen. Das Attribut "periphere Domäne" einer Leitung ist folgendermaßen definiert.
Wenn für ein IS des Levels 2, S, das Attribut für eine gegebene Leitung S1 gesetzt wird, dann wird S die folgenden Aktionen an eingehenden und ausgehenden Routing-Paketen für S1 ausführen (Datenpakete werden wie gewöhnlich behandelt).
Was die Verarbeitung von Routing-Verkehr betrifft, der von S1 eingeht, so wird das System S die IS-IS-Hallo-Protokolldateneinheit(IIH)-Pakete und die Sequenznummer-Protokolldateneinheit(SNP)-Pakete verwerfen. Es wird nur IS-Hallo-Protokolldateneinheit(ISH)-Pakete verarbeiten. Wenn irgendwelche ISH-Pakete empfangen werden und solange das letzte empfangene ISH noch gültig ist (d. h. die Haltezeit für das letzte ISH-Paket noch nicht abgelaufen ist), wird das System S automatisch einen RAP (Präfix für erreichbare Adressen) der Länge Null für S1 aufrechterhalten und diesen in seinem Level-2-LSP verkünden.
Was die Routing-Pakete betrifft, die auf S1 gesendet werden sollen, werden die folgenden Aktionen ausgeführt:

(1) Immer, wenn an S der Dijkstra-Algorithmus ausgeführt wird (dies ist der Algorithmus, der von den meisten Routing-Protokollen, darunter IS-IS, genutzt wird, um den kürzesten Weg zu irgendeinem erreichbaren Ziel zu berechnen), wird das System so viele Endsystem-Hallo-Protokolldateneinheit(ESH)-Pakete generieren, wie benötigt werden, um die Adressen aller Systeme zu enthalten, die es in der peripheren Domäne zu erkennen vermag (d. h. derer es gewahr ist, aufgrund der IS-IS-Routing-Protokoll-Abwicklungssoftware, wie in der Empfehlung ISO 10589 beschrieben). Man beachte, dass mehrere Endsystem-zu-Intermediate-System-Umgebungen über eine einzige Leitung erzeugt werden können. Wenn dies geschieht, wird das System S für den Rest des DCN außerhalb der peripheren Domäne alle innerhalb der peripheren Domäne befindlichen Systeme derart darstellen, als ob diese Endsysteme wären, die auf der Leitung (S1), welche der Grenze der peripheren Domäne zugeordnet ist, erreichbar sind.

Man beachte, dass die Topologie der peripheren Domäne, wie sie vom Rest des DCN, und auch von den Netzelementen innerhalb der peripheren Domäne, die nicht direkt mit dem Gateway verbunden sind, wahrgenommen wird, die gleiche ist, wie bei der "Lösung mit statischem Routing". Entsprechend dieser bevorzugten Ausführungsform werden ESH-Pakete entsprechend den folgenden Regeln generiert:

1. Solange es keine Änderung in der Topologie der peripheren Domäne gibt, wird der Satz von ESH-Paketen über jede Grenze der peripheren Domäne mit einer mittleren Häufigkeit gesendet, die gleich der mittleren Häufigkeit der Generierung eines neuen LSP (Link State Protokoll-Dateneinheit) innerhalb der peripheren Domäne ist. Da LSPs von einem Intermediate System mit einer mittleren Frequenz von 15 Minuten erzeugt werden, wird der Satz aus ESH-Paketen über jede Domänengrenze mit einer Generierungsfrequenz von N/900 Sekunden gesendet, wobei N die Anzahl der Systeme innerhalb der peripheren Domäne ist.
2. Immer, wenn eine Änderung der Topologie der peripheren Domäne erfolgt, sendet ein System an den Grenzen der peripheren Domäne, sobald es dieser Änderung gewahr wird, einen vollständig aktualisierten Satz von ESH-Paketen über die Grenzen der peripheren Domäne. Sofern Systeme betroffen sind, die nicht länger erreichbar sind, werden ESH-Pakete, die deren NSAPs enthalten, über die Grenze gesendet, mit einer Haltezeit von 1 Sekunde, sodass diese schnell aus der Liste der Umgebungen des Gateways gelöscht werden.

Nehmen wir Bezug auf das in 9 gezeigte Beispiel, so würde sowohl dem Gateway-Netzelement A als auch dem Rest des DCN außerhalb der peripheren Domäne diese in 10 gezeigte Topologie präsentiert werden. Dies ist exakt die gleiche Topologie, die von dem Gateway dem Rest des DCN präsentiert werden würde, wenn die zuvor beschriebene statische Routing-Konfiguration gewählt wäre.
Vorteilhafterweise wird entsprechend dieser weiter bevorzugten Ausführungsform die "virtuelle Topologie" des DCN, wie sie in 10 gezeigt ist, nicht manuell von dem Operator eingegeben, sondern wird dynamisch von dem Netz selbst erfasst. Dies ergibt im Wesentlichen die gleichen Vorteile wie bei der vorstehend beschriebenen "Lösung mit statischem Routing". Tatsächlich wird ein gewisser zusätzlicher Overhead eingetragen, um die ESH-Pakete in den dem Gateway benachbarten Systemen zu generieren und um diese an dem Gateway zu verarbeiten, dies stellt aber insgesamt viel weniger Verkehr dar, wenn man die Reduzierung der IIH- und LSP-Verarbeitung und des Verkehrs-Overhead in Rechnung zieht.
Zudem bringt die Lösung mit peripherer Domäne die folgenden Vorteile mit sich:

1. Es ist nicht notwendig, statische Routen an dem Gateway zu konfigurieren, um die DCN-Topologie hinter diesem zu beschreiben. Dies vereinfacht die DCN-Verwaltung beträchtlich.
2. Da die für das Gateway bereitgestellten Informationen dynamisch erfasst werden, wird jede Änderung in der Topologie der peripheren Domäne automatisch entdeckt. Dies ermöglicht eine Wiederherstellung nach einem etwaigen DCN-Ausfall in der peripheren Domäne, bei dem ein physikalischer Pfad für alle Systeme verfügbar bleibt. Insbesondere ist dies auf Topologien ausgerichtet, bei welchen die periphere Domäne vom Rest des DCN außerhalb der peripheren Domäne über mehr als ein Gateway zugänglich ist.

Dies ist in den 11 bis 13 dargestellt. 11 beschreibt einen Ring mit acht Netzelementen A bis H und zwei Gateways A und E.
12 zeigt, wie die Ringtopologie für die Gateways A und E und für den Rest des DCN außerhalb der peripheren Domäne erscheint, nachdem zwei periphere Domänen geschaffen worden sind, eine, welche die Netzelemente B, C und D umfasst, und die andere, welche die Netzelemente F, G und H umfasst.
13 zeigt, wie sich die Topologie aus 12 ändert, wenn die Verbindung zwischen F und G ausfällt. Diese Änderung der Topologie wird außerhalb der peripheren Domäne durch neue ESH-Pakete angekündigt, welche von F und H bei Erkennen des Verbindungsausfalls in "deren" peripherer Domäne erzeugt werden. Man beachte, dass der Rest des DCN nur davon in Kenntnis gesetzt wird, was er tatsächlich zu wissen braucht, d. h. ihm wird mitgeteilt, welcher DCC genutzt werden kann, um welche Systeme zu erreichen.
Die vorstehende Attributänderung würde vorzugsweise in der Q-Schnittstelle der Übertragungsausrüstung (beispielsweise SDH-Netzelementen) implementiert werden. Eine solche Schnittstelle ist in der ITU-T-Empfehlung Q.811 "Series Q: Switching And Signalling – Specifications of Signalling System No. 7 – Q3 interface" vom Juni 1997 beschrieben. Die vorliegende Erfindung verbessert das Funktionsverhalten des DCN (Datenkommunikationsnetz), d. h. die Infrastruktur für die Übertragungsausrüstung TMN (Telekommunikations-Management-Netzwerk). Die Verbesserung ermöglicht, dass eine Reihe von Netzelementen vom Rest des DCN betrachtet werden, als wären sie Endsysteme, selbst wenn sie immer noch Routing-Funktionalität bereitstellen müssen. Gleichzeitig wird weiterhin eine dynamische Wegelenkung in dem DCN-Kern bereitgestellt.
Entsprechend einer weiteren Ausführungsform umfasst eine Kommunikationsanordnung, die einen Teil eines SDH-DCN-Kommunikationssystems bildet, ein Netzwerk (LAN), ein Gateway-Netzelement (NE A), das mit dem Netzwerk verbunden ist, sowie ein oder mehrere weitere Netzelemente (NE B, C, D), welche zusammen mit dem Gateway-Element zumindest einen Teil eines Routing-Bereichs bilden. Das Gateway-Element wirkt als Schnittstelle zwischen den weiteren Elementen und dem Netzwerk. Obgleich die weiteren Elemente Intermediate Systems darstellen, sind das Gateway-Element und die weiteren Elemente derart konfiguriert, dass bewirkt wird, dass die weiteren Elemente als Endsysteme erscheinen, was den Rest des Kommunikationssystems betrifft.
Obgleich die Erfindung bis hierher mit Bezug auf das SDH-System beschrieben worden ist, ist sie auch auf andere Kommunikationssysteme anwendbar, welche das standardmäßige IS-IS-Routing-Protokoll nutzen.
Obgleich in die Ansprüche Bezugsbezeichnungen eingefügt worden sind, um das Verständnis derselben zu erleichtern, sind diese in keinster Weise als den Schutzumfang der Ansprüche einschränkend zu betrachten.

Claims

Kommunikationsanordnung, umfassend ein oder mehrere lokale Netze (LAN 1), wobei ein oder mehrere Gateway-Netzelemente (GNE A) mit jedem LAN verbunden sind und ein oder mehrere weitere Netzelemente (NE B, C, D) mit einem jeweiligen Gateway-Netzelement verknüpft sind, welche zusammen mit dem einen oder den mehreren Gateway-Netzelement(en) zumindest einen Teil eines Routing-Bereichs bilden, wobei jedes Gateway-Netzelement dazu ausgebildet ist, Zugang auf sein jeweiliges LAN bereitzustellen und als eine Schnittstelle zwischen dem einen oder den mehreren weiteren Netzelement(en) und dem einen oder den mehreren LANs zu fungieren, wobei das eine oder die mehreren weitere(n) Netzelement(e) jeweils ein Intermediate System (IS) entsprechend dem IS-IS-Routing-Protokoll umfassen; dadurch gekennzeichnet, dass das eine oder die mehreren Gateway-Netzelemente und das eine oder die mehreren weitere(n) Netzelement(e) derart konfiguriert sind, dass bewirkt wird, dass das eine oder die mehreren weitere(n) Netzelement(e) als Endsysteme erscheinen, soweit es den Rest der Kommunikationsanordnung betrifft, wogegen jedes weitere Netzelement für jedes andere weitere Netzelement als ein Intermediate System in dem Routing-Bereich erscheint, wobei die Endsysteme dem Rest der Kommunikationsanordnung durch Link-State-Protokoll(LSP)-Pakete bekannt gemacht werden, die von dem einen oder den mehreren Gateway-Netzelement(en) generiert werden.
Kommunikationsanordnung nach Anspruch 1, bei welcher das oder jedes Gateway-Netzelement einen oder mehrere digitale Kommunikationskanäle (DCCs 1, 2) aufweist, die mit jeweiligen der weiteren Elemente verbunden sind, wobei jedem einen oder jedem der mehreren DCCs manuelle Endsystem-Umgebungen für zumindest einige der weiteren Netzelemente bereitgestellt werden und bei jedem einen oder jedem der mehreren DCCs die Attributmarkierung "externe Domäne" auf GILT gesetzt ist.
Kommunikationsanordnung nach Anspruch 2, bei welcher diejenigen weiteren Netzelemente, die durch einen DCC direkt mit dem oder einem der Gateway-Netzelement(e) verbunden sind, als ein Intermediate System des Levels 2 konfiguriert sind und bei diesen die Attributmarkierung "externe Domäne" für die Leitung, welche den DCC nutzt, auf GILT gesetzt ist, und wobei dem DCC ein erreichbares Adress-Präfix der Länge Null bereitgestellt wird.
Kommunikationsanordnung nach Anspruch 3, bei welcher das Gateway-Netzelement zwei DCCs aufweist, die jeweils Zugang auf eines der weiteren Netzelemente auf einem entsprechenden DCC derselben gewähren, wobei die weiteren Netzelemente in einer Kettenkonfiguration derart verbunden sind, dass sie mit dem Gateway-Netzelement einen Ring bilden.
Kommunikationsanordnung nach Anspruch 3, bei welcher das Gateway-Netzelement durch nur einen DCC mit den weiteren Netzelementen verbunden ist.
Kommunikationsanordnung nach Anspruch 5, bei welcher auf dem einen Gateway-DCC eine manuelle Endsystem-Umgebung für alle weiteren Netzelemente eingerichtet ist, die Attributmarkierung "externe Domäne" für den einen DCC und für den entsprechenden DCC des einen der weiteren Netzelemente, welches den DCC an seinem anderen Ende abschließt, auf GILT gesetzt ist, und ein Präfix der Länge Null an dem entsprechenden DCC dieses abschließenden weiteren Netzelements eingerichtet ist, wobei das abschließende weitere Netzelement als ein Intermediate System des Levels 2 konfiguriert ist.
Kommunikationsanordnung nach einem der Ansprüche 2 bis 6, welche ein einziges Gateway-Element umfasst, bei welchem jeder der ein oder zwei Kanäle, die an dem Gateway-Element vorhanden sind, mit manuellen Endsystem-Umgebungen für alle weiteren Netzelemente ausgestattet ist.
Kommunikationsanordnung nach einem der Ansprüche 2 bis 6, bei welcher zwei Gateway-Elemente (GNE A, F) mit jeweils einem des einen oder der mehreren LANs (LAN 1, 2) verbanden sind und eine Mehrzahl des einen oder der mehreren weiteren Netzelemente (B, C, D, E) zwischen die beiden Gateway-Elemente geschaltet ist.
Kommunikationsanordnung nach Anspruch 8, bei welcher jedes der Gateway-Netzelemente und der weiteren Netzelemente zwei DCCs aufweist, wobei ein erster DCC (DCC 1) eines Gateway-Netzelements (GNE F) mit einem DCC (DCC 1) eines ersten der weiteren Netzelemente (C) verbunden ist, ein zweiter DCC (DCC 2) des gleichen Gateway-Netzelements (GNE F) mit einen DCC (DCC 1) eines zweiten der weiteren Netzelemente (E) verbunden ist, ein erster DCC (DCC 1) des anderen Gateway-Netzelements (GNE A) mit einem DCC (DCC 2) eines dritten der weiteren Netzelemente (B) verbunden ist und ein zweiter DCC (DCC 2) des anderen Gateway-Netzelements (GNE A) mit einem DCC (DCC 2) eines vierten der weiteren Netzelemente (D) verbunden ist.
Kommunikationsanordnung nach Anspruch 9, wobei bei jedem DCC derjenigen weiteren Netzelemente, welche direkt mit mindestens einem der Gateway-Elemente verbunden sind, die Attributmarkierung "externe Domäne" für die Leitung, welche diesen DCC nutzt, auf GILT gesetzt ist und einen erreichbaren Adress-Präfix der Länge Null auf der Leitung aufweist, welche diese mit dem Gateway-Element verbindet, und wobei der erste DCC (DCC 1) jedes Gateway-Elements (GNE A, F) mit manuellen Endsystem-Umgebungen für das erste und das zweite der weiteren Netzelemente (B, C) eingestellt ist und der zweite DCC (DCC 2) jedes Gateway-Netzelements (GNE A, F) mit manuellen Endsystem-Umgebungen für das dritte und vierte der weiteren Netzelemente (D, E) eingestellt ist.
Kommunikationsanordnung nach einem der vorhergehenden Ansprüche, bei welcher das oder jedes Gateway-Element einen statischen Routen-Datensatz umfasst, in welchen manuell ein oder mehrere Bereiche von fortlaufenden Systemkennungen eingegeben worden sind, die den manuellen Endsystem-Umgebungen entsprechen.
Kommunikationsanordnung nach einem der vorhergehenden Ansprüche, bei welcher eine Änderung an dem IS-IS-Weiterleitungsprozess derart implementiert wird, dass, falls zwei manuelle Umgebungen mit gleichen Kosten vorhanden sind, welche mit der Bestimmungsadresse eines gegebenen Pakets übereinstimmen, und eine davon der Leitung zugeordnet ist, auf welcher das Paket empfangen wurde, das Paket auf der anderen Leitung weitergeleitet wird.
Kommunikationsanordnung nach einem der vorhergehenden Ansprüche, wobei ein Nachrichtenpaket, welches von einem der weiteren Netzelemente in dem Routing-Teilbereich generiert oder weitergeleitet wird und für ein Netzelement außerhalb dieses Routing-Bereichs, aber in dem gleichen Bereich wie die weiteren Netzelemente bestimmt ist, von einem Intermediate System des Levels 1, welches dieses Paket abwickelt, nicht verworfen wird, wenn dieses Intermediate System Zugang zu einem angegliederten Intermediate System des Levels 2 hat, welches einen Teil des Bereichs oder des Teilbereichs bildet.
Kommunikationsanordnung nach einem der Ansprüche 1 bis 12, wobei ein Nachrichtenpaket, welches in dem Routing-Bereich oder Routing-Teilbereich generiert wird, der durch das Gateway-Element und die weiteren Netzelemente definiert ist, und für ein Netzelement außerhalb dieses Bereichs oder Teilbereichs bestimmt ist, von einem Intermediate System des Levels 1, welches dieses Paket abwickelt, nicht verworfen wird, wenn dieses Intermediate System Zugang zu einem Intermediate System des Levels 2 hat, welches einen Teil des Bereichs oder Teilbereichs bildet.
Kommunikationsanordnung nach Anspruch 1, bei welcher das eine oder die mehreren weitere(n) Netzelement(e) eine periphere Domäne umfassen.
Kommunikationsanordnung nach Anspruch 1, welche mehrere Knoten umfasst, wobei die mehreren Knoten einen ersten Satz umfassen, der aus den weiteren Netzelementen besteht, sowie einen zweiten Satz, welcher die weiteren Netzelemente ausschließt, wobei der zweite Satz Endsysteme (ES) und/oder Intermediate Systeme (IS) umfasst; wobei jeder Knoten in dem zweiten Satz eine Verbindung zu jedem anderem Knoten in dem zweiten Satz aufweist, wobei die Verbindungen nur durch Knoten des zweiten Satzes laufen.
Kommunikationsanordnung nach Anspruch 16, bei welcher alle weiteren Netzelemente in einem einzigen IS-IS-Bereich liegen und alle Knoten des zweiten Satzes, welche direkt mit einem oder mehreren der weiteren Netzelemente verbunden sind, in dem IS-IS-Bereich liegen.
Kommunikationsanordnung nach einem der Ansprüche 16 und 17, bei welcher die weiteren Netzelemente mit den Knoten des zweiten Satzes durch mehr als eine Leitung verbunden sind und wobei jede der Leitungen Zugang von zumindest einigen der weiteren Netzelemente zu allen Knoten des zweiten Satzes bereitstellt.
Kommunikationsanordnung nach einem der Ansprüche 16 bis 18, bei welcher jedes weitere Netzelement, welches direkt mit einem Konten des zweiten Satzes verbunden ist, Mittel umfasst, um Pakete mit IS-IS-Hallo-Protokolldateneinheiten IIH sowie Pakete mit Sequenznummer-Protokolldateneinheiten SNP, die von einem Knoten des zweiten Satzes empfangen werden, zu verwerfen.
Kommunikationsanordnung nach Anspruch 19, bei welcher jedes weitere Netzelement, das direkt mit einem Knoten des zweiten Satz verbunden ist, als IS des Levels 2 konfiguriert ist und Mittel umfasst, um den Empfang von Paketen mit Intermediate-System-Hallo-Protokolldateneinheiten ISH zu überwachen und um einen erreichbaren Adress-Präfix RAP der Länge Null für die Leitung von dem weiteren Netzelement zu dem Knoten des zweiten Satzes aufrechtzuerhalten, während das zuletzt empfangene ISH-Paket noch gültig ist.
Kommunikationsanordnung nach einem der Ansprüche 16 bis 20, bei welcher jedes weitere Netzelement eine Netzadresse umfasst und bei welcher jedes weitere Netzelement, das direkt mit einem Knoten des zweiten Satzes verbunden ist, Mittel umfasst, um Pakete mit Endsystem-Hallo-Protokolldateneinheiten ESH zu generieren, welche die Adressen aller weiteren Netzelemente enthalten, von denen es Kenntnis hat.
Kommunikationsanordnung nach Anspruch 21, bei welcher jedes weitere Netzelement, das direkt mit einem Knoten des zweiten Satzes verbunden ist, Mittel umfasst, um eine Änderung in der Topologie des Teils der Kommunikationsanordnung, die aus den weiteren Netzelementen und den Verbindungen zwischen diesen besteht, zu erkennen, sowie Mittel zum Senden der ESH-Pakete, wenn keine Änderung erkannt wird, an die Knoten des zweiten Satzes, und zwar in der gleichen Frequenz wie die mittlere Generierungsfrequenz von LSPs durch den ersten Satz weiterer Systeme.
Kommunikationsanordnung nach Anspruch 22, bei welcher jedes weitere Netzelement, das direkt mit einem Knoten des zweiten Satzes verbunden ist, Mittel umfasst, um die ESH-Pakete an die Knoten des zweiten Satzes zu senden, sobald eine Änderung erkannt wird.
Kommunikationsanordnung nach einem der Ansprüche 19 bis 23, bei welcher die weiteren Netzelemente, die direkt mit einem Knoten des zweiten Satzes verbunden sind, Übertragungsausrüstung für synchrone digitale Hierarchie SDH umfassen, wobei die SDH-Übertragungsausrüstung eine Q-Schnittstelle umfasst, wobei die Mittel gemäß den Ansprüchen 7 bis 12 in der Q-Schnittstelle implementiert sind.
Kommunikationsanordnung nach einem der Ansprüche 15 bis 24, bei welcher ein Nachrichtenpaket, welches von einem der weiteren Netzelemente generiert oder verarbeitet wird und für einen Knoten des zweiten Satzes bestimmt ist, der zu dem gleichen Routing-Bereich wie das weitere Netzelement gehört, von einem IS des Levels 1, welches dieses Paket abwickelt, nicht verworfen wird, wenn dieses IS Zugang zu einem angegliederten IS des Levels 2 in dem ersten Satz hat.
Kommunikationsanordnung nach einem der Ansprüche 15 bis 25, welche zur Nutzung in einem SDH-Kommunikationssystem angepasst ist.