DE69534430T2 - System zur kommunikationsfernverwaltung mit intelligenter filterung - Google Patents

System zur kommunikationsfernverwaltung mit intelligenter filterung Download PDF

Info

Publication number
DE69534430T2
DE69534430T2 DE69534430T DE69534430T DE69534430T2 DE 69534430 T2 DE69534430 T2 DE 69534430T2 DE 69534430 T DE69534430 T DE 69534430T DE 69534430 T DE69534430 T DE 69534430T DE 69534430 T2 DE69534430 T2 DE 69534430T2
Authority
DE
Germany
Prior art keywords
network
resources
interface
central
decentralized
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Lifetime
Application number
DE69534430T
Other languages
English (en)
Other versions
DE69534430D1 (de
Inventor
Chandrasekharan Nilakantan
Kiho Yum
Ta-Sheng Lin
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
3Com Corp
Original Assignee
3Com Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 3Com Corp filed Critical 3Com Corp
Application granted granted Critical
Publication of DE69534430D1 publication Critical patent/DE69534430D1/de
Publication of DE69534430T2 publication Critical patent/DE69534430T2/de
Anticipated expiration legal-status Critical
Expired - Lifetime legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/02—Standardisation; Integration
    • H04L41/0213—Standardised network management protocols, e.g. simple network management protocol [SNMP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/06—Management of faults, events, alarms or notifications
    • H04L41/0604—Management of faults, events, alarms or notifications using filtering, e.g. reduction of information by using priority, element types, position or time

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Communication Control (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)

Description

  • HINTERGRUND DER ERFINDUNG
  • Gebiet der Erfindung
  • Die vorliegende Erfindung betrifft die Verbindung von Datennetzwerken und insbesondere das Verwalten bzw. Managen von Verkehr zwischen miteinander verbundenen Netzwerken für eine effiziente Verwendung von Kommunikationsressourcen.
  • Beschreibung des Stands der Technik
  • Die Verbindung von dezentralen Büros mit Hauptsitzen über Fernnetze (wide area networks; WANs) gewinnt mehr und mehr an Popularität. Unter Verwendung von miteinander verbundenen Netzwerken können Personen, die in dezentralen Büros arbeiten, Zugriff auf elektronische Mailsysteme sowie auf Client-Server-Applikationen haben, gemeinsam Dateien verwenden und weitere Firmenressourcen verwenden, die in der Zentrale verwaltet werden.
  • Es sind Technologien entwickelt worden, um die Verbindung von dezentralen Büros zu erleichtern, um diesen Bedarf zu befriedigen. Ein Beispiel ist die Grenz-Routingsysteme-Architektur (boundary routing systems architecture) von der Firma 3Com Corporation (siehe auch "Plug in to Remote Connectivity", NetAge, veröffentlicht von 3Com Corporation, Vol. 3, No. 2, März/April 1994, Seiten 1–5). Gemäß der Grenz-Routingsysteme-Architektur wird ein dezentrales Netzwerk mit einem erweiterten Interface mit Netzwerkverwaltungsressourcen bereitgestellt, wie beispielsweise einem Multiprotokoll-Router, der in der Zentrale vorhanden ist. Die gesamte Verwaltung des Routers wird von einem Administrator in einer Zentrale erledigt, der den dezentralen Standort nicht besuchen muss, um den vollständigen Zugang für Benutzer des dezentralen Netzwerkes sicherzustellen. Das erweiterte Interface wird bereitgestellt, indem transparent eine WAN-Verbindung zwischen der Zentrale und dem dezentralen Netzwerk eingebracht wird.
  • Ein bedeutender Kostenfaktor beim Verbinden von dezentralen Büros mit der Zentrale sind die Kosten der WAN-Dienste. Beispielsweise erzeugen lokale Netzwerke oftmals einen bedeutenden Hintergrundverkehr (background traffic). Beispielsweise verwendet das IPX-Protokoll (Internetwork Packet Exchange Protocol), das von Net-Ware-Routern ausgeführt wird, die von der Firma Novell, Inc. vertrieben werden, das sogenannte RIP-Protokoll (Routing Information Protocol) und das SAP-Protokoll (Service Advertising Protocol). Das RIP-Protokoll umfasst periodische RIP-Broadcast-Pakete, die alle Routing-Informationen enthalten, die dem Router bekannt sind. Die Pakete werden verwendet, um das Internetzwerk zu synchronisieren, und stellen ein Mittel bereit, die Netzwerke zeitlich vorzurücken, auf die nicht mehr zugegriffen werden kann. Gleichermaßen umfasst das SAP-Protokoll das periodische Aussenden von SAP-Broadcast-Paketen, die alle Serverinformationen enthalten, die dem SAP-Agenten bekannt sind. Diese Broadcasts bzw. Rundrufe sorgen dafür, dass alle Router des Internetzwerkes synchronisiert sind, um ein Mittel bereitzustellen, Server in dem Netzwerk zeitlich vorzurücken. Die WAN-Verwendung durch die Broadcasts im Hintergrund kann recht stark sein.
  • Es besteht somit ein Bedarf, die Verwendung von WAN-Diensten zu verwalten, ohne übermäßig die Verwaltung zu erhöhen, die bei dezentralen Standorten notwendig ist, und ohne übermäßig die Verwendung von Ressourcen in der Zentrale durch das dezentrale Netzwerk zu beschränken.
  • US-PS 5,280,470 beschreibt ein Verfahren und eine Vorrichtung zum Kontrollieren einer Überlastung in einem Datennetzwerk. In Reaktion darauf, dass das Netzwerk eine Überlastung detektiert, sendet das Netzwerk Verlangsamungsnachrichten an ausgewählte virtuelle Kanäle, um deren Datenrate zu vermindern.
  • ZUSAMMENFASSUNG DER ERFINDUNG
  • Gemäß der Erfindung wird eine Vorrichtung bzw. ein Apparat zur Steuerung von Netzwerkverkehr von einer zentralen Vorrichtung über eine Kommunikationsverbindung zu einem dezentralen Netzwerk bereitgestellt, das über ein dezentrales Interface mit der Kommunikationsverbindung verbunden ist, wobei zentrale Verkehrsverwaltungsressourcen bzw. Verkehrsmanagementressourcen in der zentralen Vor richtung umfasst werden, die mit der Kommunikationsverbindung verbunden sind, die Datenpakete überwachen, die über die Kommunikationsverbindung empfangen werden, Verkehrsverwaltungsnachrichten erzeugen und die Verkehrsverwaltungsnachrichten an das dezentrale Interface weiterleiten, um den Verkehr auf der Kommunikationsverbindung zu steuern, dadurch gekennzeichnet, dass die zentralen Verkehrsverwaltungsressourcen Datenpakete detektieren, um zu bestimmen, welche Datenpakettypen einer Vielzahl von Datenpakettypen nicht von dem dezentralen Interface weitergeleitet werden müssen, und die Verkehrsverwaltungsnachrichten in Antwort auf das Bestimmen erzeugen, welche Datenpakettypen einer Vielzahl von Datenpakettypen nicht von dem dezentralen Interface weitergeleitet werden müssen.
  • Die Erfindung stellt ferner ein Verfahren zum Verwalten des Verkehrs zwischen einem ersten Knoten und einem zweiten Knoten bereit, die über eine Kommunikationsverbindung verbunden sind, wobei das Verfahren umfasst: Detektieren von Paketen im Verkehr mittels Verarbeitungsressourcen in dem ersten Knoten, wobei die Pakete von dem Netzwerk durch den zweiten Knoten über die Kommunikationsverbindung gesendet werden und von diesem empfangen werden, um zu bestimmen, welche Datenpakettypen einer Vielzahl von Datenpakettypen nicht von dem zweiten Knoten weitergeleitet werden müssen, und in Reaktion darauf das Entwickeln mit Verarbeitungsressourcen in dem ersten Knoten einer Verkehrsverwaltungsrichtlinie in dem ersten Knoten, und das Delegieren von Ressourcen an den zweiten Knoten über die Kommunikationsverbindung, um die Verkehrsverwaltungsrichtlinie auszuführen.
  • Die Erfindung wird durch den Apparat gemäß Anspruch 1 und das Verfahren gemäß Anspruch 18 ausgeführt.
  • Somit wird das dezentrale Interface automatisch durch zentrale Verkehrsverwaltungsressourcen konfiguriert, die in der zentralen Vorrichtung ablaufen, und zwar ohne ein menschliches Eingreifen in dem dezentralen Netzwerk.
  • Die Verkehrsverwaltungsnachrichten verwalten den Verkehr über eine Kommunikationsverbindung von zwei Typen. Verkehrsverwaltungsnachrichten identifizieren (1) Pakettypen, die von dem dezentralen Interface über die Kommunikationsverbindung weitergeleitet werden sollen, und (2) Pakettypen, die von dem dezentralen Interface an Benutzer des dezentralen Netzwerkes gesendet werden sollen. Somit werden Pa kete, die von dem dezentralen Netzwerk stammen, gefiltert, so dass lediglich notwendige Pakete an die Zentrale weitergeleitet werden. Gleichermaßen werden Pakete, die üblicherweise von dem zentralen Standort stammen, an dem dezentralen Standort in Antwort auf Verwaltungsnachrichten "verschleiert" (spooled), die an dem zentralen Standort erzeugt werden.
  • Um den "plug and play"-Aspekt der vorliegenden Erfindung weiter zu betonen, führen die zentralen Verkehrsverwaltungsressourcen ein Transportprotokoll für die Verkehrsverwaltungsnachrichten aus, die unabhängig von einer Netzwerkadresse für das dezentrale Interface sind.
  • Die vorliegende Erfindung kann ebenso als ein System zum Steuern bzw. zur Kontrolle des Verkehrs über eine Kommunikationsverbindung zwischen einem dezentralen Netzwerk und einer zentralen Vorrichtung charakterisiert werden. Das System gemäß diesem Aspekt umfasst ein dezentrales Netzwerk-Interface, das mit dem dezentralen Netzwerk verbunden ist, einschließlich Datenweiterleitungsressourcen, die gemäß Weiterleitungsregeln Datenpakete weiterleiten, die von Benutzern des dezentralen Netzwerkes stammen, und zwar über die Kommunikationsverbindung zu der zentralen Vorrichtung in Antwort auf Eigenschaften der Datenpakete. Ferner sind zentrale Verbindungsverwaltungsressourcen in der zentralen Vorrichtung vorhanden. Diese Ressourcen überwachen Eigenschaften der weitergeleiteten Datenpakete, die von dem dezentralen Netzwerk-Interface über die Kommunikationsverbindung empfangen werden, um Eigenschaften bzw. Charakteristiken von Benutzern des dezentralen Netzwerkes zu lernen. In Reaktion auf die gelernten Charakteristiken erzeugen diese Ressourcen Verbindungsverwaltungsnachrichten und leiten die Verbindungsverwaltungsnachrichten an das dezentrale Interface weiter. Die dezentralen Verbindungsverwaltungsressourcen in dem dezentralen Interface reagieren auf die Verbindungsverwaltungsnachrichten. In Reaktion auf diese Nachrichten werden die Weiterleitungsregeln an die gelernten Charakteristiken der Benutzer des dezentralen Netzwerkes angepasst, um unnötigen Verkehr auf der Kommunikationsverbindung zu reduzieren.
  • Die zentralen Verbindungsverwaltungsressourcen können außerdem Verwaltungsnachrichten des dezentralen Netzwerkes erzeugen, und zwar auf der Basis eines Protokolls, das durch andere Benutzer der zentralen Vorrichtung ausgeführt wird, und diese Verwaltungsnachrichten des dezentralen Netzwerks an das dezentrale Interface weiterleiten. Gemäß diesem Aspekt erzeugen die Verwaltungsressourcen des dezentralen Netzwerkes in dem dezentralen Interface Netzwerkverwaltungspakete in Reaktion auf die Verwaltungsnachrichten des dezentralen Netzwerkes und senden die Netzwerkverwaltungspakete an die Benutzer des dezentralen Netzwerkes, wie dies gemäß dem Protokoll erforderlich ist. Somit werden Netzwerkverwaltungspakete, die üblicherweise von dem zentralen Standort stammen, durch das dezentrale Interface verschleiert, was die Menge des Verkehrs weiter reduziert, der über die WAN-Verbindung laufen muss.
  • Die zentralen Verbindungsverwaltungsressourcen können außerdem Eigenschaften bzw. Charakteristiken von Datenpaketen überwachen, die von den anderen Benutzern der zentralen Vorrichtung empfangen werden, um über Veränderungen zu lernen, die an den Netzwerkverwaltungspaketen vorgenommen werden müssen, die in den Verwaltungsressourcen des dezentralen Netzwerks erzeugt werden. In Reaktion auf diese gelernten Veränderungen werden Netzwerkverwaltungsnachrichten, die diese Veränderungen anzeigen, erzeugt und an das dezentrale Interface weitergeleitet. Ressourcen in dem dezentralen Netzwerk-Interface verändern die Verwaltungspakete des dezentralen Netzwerkes in Reaktion auf die Netzwerkverwaltungsnachrichten, die diese Veränderungen anzeigen.
  • Ein Transportmechanismus ist in dem System enthalten, der die Kommunikation der Verbindungsverwaltungsnachrichten und der Netzwerkverwaltungsnachrichten an das dezentrale Interface unabhängig von der Netzwerkadresse des dezentralen Interface ermöglicht.
  • Gemäß einem noch weiteren Aspekt der vorliegenden Erfindung wird die WAN-Verkehrsverwaltung in der Grenz-Routersysteme-Architektur (boundary router systems architecture) implementiert, in der das dezentrale Interface Unicast-Datenrahmen von Benutzern des zweiten Netzwerkes weiterleitet, die an ein erweitertes Interface des zentralen Standortes adressiert sind, Broadcast-Rahmen über eine Kommunikationsverbindung zu dem zentralen Standort weiterleitet und Rahmen weiterleitet, die von dem zentralen Standort kommend von dem dezentralen Netzwerk empfangen werden, wenn diese nicht an das dezentrale Interface adressiert sind. In dieser Umgebung überwacht der Verbindungsmanager an dem zentralen Standort Pakete, die über die Kommunikationsverbindung empfangen werden, um die Charakteristika bzw. Eigenschaften des dezentralen Netzwerkes zu lernen, und erzeugt Verkehrsverwaltungsnachrichten in Reaktion auf die gelernten Charakteristika. Diese Verkehrsverwaltungsnachrichten werden an das dezentrale Interface weitergeleitet, wo ein Verbindungsmanageragent Broadcast-Rahmen in Reaktion auf die Verkehrsverwaltungsnachrichten filtert. Außerdem können der Verbindungsmanager und der Verbindungsmanageragent eingerichtet werden, um Netzwerkverwaltungsrahmen zu verschleiern, die normalerweise an dem zentralen Standort erzeugt werden, wie dies vorstehend beschrieben worden ist.
  • Somit stellt die vorliegende Erfindung einen "intelligenten Filter"-Mechanismus ("Smart Filtering" mechanism) bereit, mittels dem ein dezentrales Büro mit einem zentralen Standort mit einem geringen administrativen Aufwand (overhead) und mit einem sorgfältig verwalteten WAN-Verkehr verbunden werden kann. Das System ermöglicht das Lernen der Charakteristika bzw. Eigenschaften des dezentralen Netzwerks und ermöglicht ferner, das dezentrale Netzwerk über Veränderungen auf dem Laufenden zu halten, die an dem zentralen Standort stattfinden. Auf der Grundlage dieser Eigenschaften ist ein Filter-/Verschleierungs-Agent an dem dezentralen Standort automatisch dazu in der Lage, WAN-Verkehr auf der Grundlage von Ratschlägen von dem zentralen Standort zu verwalten.
  • Weitere Aspekte und Vorteile der vorliegenden Erfindung ergeben sich aus den beigefügten Zeichnungen, der detaillierten Beschreibung und den anhängenden Ansprüchen.
  • KURZE BESCHREIBUNG DER ZEICHNUNGEN
  • Die Erfindung wird nachstehend beispielhaft unter Bezugnahme auf die beigefügten Zeichnungen beschrieben.
  • 1 zeigt ein schematisches Diagramm von Netzwerken, die gemäß der vorliegenden Erfindung mit einem intelligenten Filtermanager an dem zentralen Knoten und intelligenten Filteragenten an Blattknoten verbunden sind.
  • 2 zeigt eine schematische Darstellung einer Grenz-Routing-Umgebung, in der "Protokoll-Inseln" dargestellt werden.
  • 3 zeigt ein detaillierteres schematisches Diagramm eines intelligenten Filtersystems gemäß der vorliegenden Erfindung.
  • 4 zeigt ein schematisches Diagramm von Ressourcen auf dem zentralen Knoten und dem Blattknoten, die das intelligente Filterprotokoll gemäß der vorliegenden Erfindung ausführen.
  • 5 zeigt ein schematisches Diagramm eines Grenz-Router-Systems bzw. Boundary-Router-Systems gemäß der vorliegenden Erfindung.
  • 6 zeigt ein schematisches Diagramm der Ressourcen des zentralen Knotens und des Blattknotens eines Grenz-Routers bzw. Boundary-Routers gemäß der vorliegenden Erfindung.
  • 7 zeigt ein detaillierteres schematisches Diagramm der Ressourcen, die das intelligente Filtern (Smart Filtering) gemäß einer bevorzugten Ausführungsform der vorliegenden Erfindung ausführen.
  • 8 zeigt ein "Pseudo-Code"-Diagramm der Startroutine für einen intelligenten Filteranschluss (Smart Filtering port) gemäß der vorliegenden Erfindung.
  • 9 zeigt ein "Pseudo-Code"-Diagramm von intelligenten Filterverstellungen während der Laufzeit gemäß der vorliegenden Erfindung.
  • 10 zeigt ein "Pseudo-Code"-Diagramm eines Algorithmus, der verwendet wird, um die intelligente Filterfunktion an einem Anschluss abzustellen.
  • 11 zeigt eine "Pseudo-Code"-Darstellung eines Algorithmus zum Handhaben von Ausnahmen in der intelligenten Filterumgebung.
  • 12 zeigt eine "Pseudo-Code"-Darstellung des intelligenten Filter-Trigger-Algorithmus gemäß der vorliegenden Erfindung.
  • 13 stellt eine Perspektive von "adresslosen" Transportmechanismen bereit, die gemäß einem Aspekt der vorliegenden Erfindung verwendet werden.
  • DETAILLIERTE BESCHREIBUNG
  • 1 zeigt eine Vielzahl von miteinander verbundenen Netzwerken, einschließlich einem zentralen Knoten (central node) 10, einem Blattknoten (leaf node) 11 und einem Blattknoten (leaf node) 12. Der zentrale Knoten 10 kann ein Netzwerkzwischensystem umfassen, wie beispielsweise einen Multiprotokoll-Router. Ein Beispiel für den Multiprotokoll-Router ist unter dem Namen NetBuilder II, der von der Firma 3Com Corporation, Santa Clara, Kalifornien, bereitgestellt wird, bekannt.
  • Dieser zentrale Knoten 10 ist mit einem ersten lokalen Netzwerk (local area network) 13 verbunden, das eine Vielzahl von Netzwerkservern umfasst, die im Allgemeinen mit der Bezugsziffer 14 gekennzeichnet sind, eine Vielzahl von Netzwerk-Clients, die im Allgemeinen mit der Bezugsziffer 15 gekennzeichnet sind, sowie Verbindungen zu anderen lokalen Netzwerken oder Fernnetzen, die schematisch durch die Wolke 16 repräsentiert sind. Darüber hinaus kann der zentrale Knoten 10 mit einem zweiten LAN 17 verbunden sein, das eine Anzahl von Clients und Servern enthält, die nicht gezeigt sind, und dieser kann ferner mit weiteren LANs oder WANs verbunden sein, wie dies durch die Wolke 18 dargestellt ist.
  • Der zentrale Knoten 10 ist über eine Fernnetzstandverbindung (point to point wide area network link) 22 mit dem Blattknoten 11 verbunden. Der Blattknoten 11 ist mit einem lokalen Netzwerk 19 verbunden, das Netzwerkserver, die im Allgemeinen mit der Bezugsziffer 20 gekennzeichnet sind, und Netzwerk-Clients umfasst, die im Allgemeinen mit der Bezugsziffer 21 gekennzeichnet sind.
  • Der zentrale Knoten 10 ist außerdem über eine geschaltete Fernnetzkommunikationsverbindung (switched wide area network communication link) 23 mit dem Blattknoten 12 verbunden. Der Blattknoten 12 ist mit einem lokalen Netzwerk 24 verbunden, das einen Netzwerk-Server 25 und einen Netzwerk-Client 26 umfasst. Außerdem kann das LAN 24 mit einer "Protokoll-Insel" (protocol island) verbunden sein, die im Allgemeinen mit der Bezugsziffer 27 gekennzeichnet ist und die eine Anzahl von Vorrichtungen umfassen kann, die ein Protokoll ausführen, das nicht von Ressourcen auf dem zentralen Knoten 10 verarbeitet wird. Somit werden Pakete von der Protokoll-Insel 27 nicht von dem Multiprotokoll-Router an dem zentralen Knoten 10 geroutet.
  • Gemäß der vorliegenden Erfindung umfasst der zentrale Knoten 10 einen intelligenten Filtermanager (Smart Filtering Manager) 28, der Blattknoten 11 umfasst einen intelligenten Filteragenten (Smart Filtering agent) 29 und der Blattknoten 12 umfasst einen intelligenten Filteragenten 30. Der intelligente Filtermanager 28 überwacht Datenpakete, die über die Kommunikationsverbindungen 22 oder 23 empfangen werden, um Charakteristika bzw. Eigenschaften der dezentralen Netzwerke 19 bzw. 24 zu lernen. Der Manager erzeugt Verkehrsverwaltungsnachrichten in Reaktion auf die gelernten Charakteristika und leitet die Verkehrsverwaltungsnachrichten an die intelligenten Filteragenten 29 und 30 auf den Blattknoten 11 und 12 weiter. Die Blattknoten 11 und 12 reagieren auf die Verkehrsverwaltungsnachrichten, um den Verkehr zu steuern bzw. zu kontrollieren, der über die Fernverbindungen 22 und 23 weitergeleitet werden muss. Beispielsweise kann der intelligente Filtermanager bestimmte Netzwerkverwaltungspakete detektieren, die durch Server 20 auf dem LAN 19 erzeugt werden, die nicht jedes Mal, wenn diese erzeugt werden, zu dem zentralen Knoten weitergeleitet werden müssen. In Reaktion auf diese gelernte Charakteristik des dezentralen Netzwerkes wird eine Verkehrsverwaltungsnachricht an den Blattknoten 11 gesendet, wo der intelligente Filteragent 29 einen Filter implementiert, um das Weiterleiten derartiger Pakete über die Verbindung 22 zu verhindern.
  • Außerdem kann der intelligente Filtermanager 28 bestimmte Pakettypen detektieren, die von dem zentralen Knoten 10 über die Blattknoten 11 bzw. 12 zu den dezentralen Netzwerken 19 und 24 weitergeleitet werden, die den dezentralen Netzwerken keine neuen Informationen liefern. Diese Nachrichten müssen nicht von dem zentralen Knoten über die Verbindungen 22 und 23 weitergeleitet werden, falls Verkehrsverwaltungsnachrichten an die Blattknoten 11 und 12 gesendet werden, wo die intelligenten Filteragenten 29 und 30 Ressourcen einrichten, um diese Verkehrsverwaltungspakete für die dezentralen Netzwerke zu verschleiern.
  • 2 zeigt eine perspektivische Ansicht der Protokoll-Insel-Umgebung. In 2 ist ein zentraler Router 40 über eine WAN-Verbindung 41 mit dem Blatt L1 (42) verbunden. Das Blatt L1 ist mit einem LAN 43 verbunden, an das ein VINES-Netzwerk 44 angebracht ist. Der zentrale Router 40 ist außerdem direkt mit dem Netzwerk N1 (45) verbunden. Das Netzwerk N1 ist mit einer Gruppe 46 von Arbeitsstationen verbunden, auf denen das AppleTalk-Protokoll ausgeführt wird. Der zentrale Router 40 ist außerdem über eine WAN-Verbindung 48 mit einem zweiten Blatt L2 (47), mit einem dritten Blatt L3 (48) über die WAN-Verbindung 49 und mit einem zweiten direkt angebrachten Netzwerk N2 (50) verbunden.
  • Das zweite Blatt L2 ist mit einem Netzwerk 51 verbunden. Das Netzwerk 51 ist mit einer Gruppe 52 von Terminals verbunden, auf der das LAT-Protokoll ausgeführt wird. Wie in der Figur dargestellt, werden das zweite Blatt L2, das dritte Blatt L3 und das zweite angebrachte Netzwerk N2 alle in einer IPX-Routing-Umgebung betrieben, die durch die Wolke 53 repräsentiert ist. Protokoll-Inseln bestehen in der VINES-Gruppe 44, der AppleTalk-Gruppe 46 und der LAT-Gruppe 52. Diese Protokoll-Inseln sind vernetzte Topologien, die immer auf ein Netzwerk mit einem einzelnen Blatt beschränkt sind und keine Verbindungsbedürfnisse mit anderen Blattnetzwerken oder dem zentralen Router 40 aufweisen.
  • Die IPX-Routing-Wolke zeigt, dass die Domäne des IPX-Routings ein gesamtes Blattnetzwerk 48 oder ein teilweises Blattnetzwerk umfassen kann, wie beispielsweise das Netzwerk 51, das mit dem zweiten Blatt L2 verbunden ist. Somit muss der Multicast- und Broadcast-Verkehr, der von den Protokoll-Inseln 44, 46 und 52 erzeugt wird, nicht über die Fernverbindungen 41, 48 und 49 kommuniziert werden, da diese an dem zentralen Router 40 verworfen werden, solange dieser für den bestimmten Anschluss bzw. Port, an dem diese empfangen werden, streng als ein Router betrieben wird. In dem vorstehend erwähnten Blattnetzwerk 51 würden beispielsweise alle LAT-Broadcast-Pakete und LAT-Multicast-Pakete zu dem zentralen Router 40 entweichen und dort verworfen werden, da der zentrale Router lediglich ein IPX-Routing über den mit der Verbindung 48 verbundenen Anschluss bzw. Port durchführen würde. Dieser Verkehrstyp ist die Art von WAN-Overhead, die unter Verwendung der intelligenten Filterung (Smart Filtering) gemäß der vorliegenden Erfindung entfernt werden sollte.
  • 3 zeigt die grundlegende Struktur zum Implementieren des intelligenten Filtermaster und des intelligenten Filteragenten. Das weitläufig angewendete SNMP-Protokoll (Simple Network Management Protocol) wird als ein Beispiel für den grundlegenden Transportmechanismus verwendet. In 3 ist der zentrale Router durch Box 60 dargestellt. Innerhalb des zentralen Routers 60 ist der intelligente Filtermaster-Code 61 implementiert, der ein Interface 62 zu dem SNMP-Transportmechanismus 65 umfasst. Der SNMP-Transportmechanismus 65 ist mit dem Anschluss bzw. Port 63 verbunden. Der Anschluss bzw. Port 63 ist mit einer WAN-Verbindung 64 verbunden. Diese WAN-Verbindung 64 ist in dem Blattknoten 67 mit dem SNMP-Transportmechanismus 66 verbunden. Der SNMP-Transportmechanismus 66 ist durch das Interface 68 mit dem intelligenten Filteragenten-Code 69 verbunden, der eine SNMP-Verwaltungsinformationsbank MIB (management Information base; MIB) umfasst. Der intelligente Filteragent 69 führt in Reaktion auf Information in der MIB eine Paketverschleierung 70 und eine Paketfilterung 71 für das Blatt-LAN 72 aus.
  • Obgleich eine tatsächliche Implementierung nicht eine strenge Schichtung sein kann, können diese Ressourcen ebenso dargestellt werden, wie dies in 4 gezeigt ist. Insbesondere verbindet eine Fernverbindung 90 einen Blattknoten 91 mit einem zentralen Knoten 92. Der zentrale Knoten 92 umfasst geroutete Protokollressourcen 93 zum Routen einer Vielzahl von Protokollen in einem Netzwerk. Intelligente Filter-Trigger-Ressourcen 94 sind mit den gerouteten Protokollressourcen 93 verbunden. Diese Ressourcen können innerhalb der gerouteten Protokollressourcen 93 eingebaut sein oder separat implementiert sein, und zwar in Abhängigkeit der besonderen verwendeten Software-Architektur. Blattknoteneinrichtungsressourcen 95 sind mit den Trigger-Ressourcen 94 verbunden. Diese Ressourcen bestimmen auf der Basis der Trigger-Ressourcen 94, welche Arbeitsschritte für ein Filtern und ein Verschleiern an den Blattknoten 91 delegiert werden sollen.
  • Ein intelligenter Filter-Manager-/Agent-Transportmechanismus 96 ist mit den Einrichtungsressourcen 95 des Blattknotens 91 verbunden. Dieser Mechanismus ermöglicht den Transport über die WAN-Verbindung 90 zu einem intelligenten Filter-Manager-/Agent-Transportmodul 97 in dem Blattknoten 91. Der Transport ermöglicht die Kommunikation von die Verkehrsverwaltung betreffenden Nachrichten zu den Einrichtungsressourcen 98 des Blattknotens 91, die von den Filter- und Verschleierungsressourcen 99 verwendet werden, um den Verkehr über die WAN-Verbindung 90 zu verwalten. Wie vorstehend beschrieben, ist SNMP mit MIB-Objekten ein Mechanismus, der für diesen Transport verwendet werden kann. Alternativen umfassen IP-UDP (IP User Datagram Protocol) mit den UI-Befehls-/Parameterkonventionen, TCP (Transmission Control Protocol) sowie speziell ausgestaltete Protokolle.
  • Bei einer Implementierung der vorliegenden Erfindung handelt es sich bei dem zentralen Knoten 92 um einen Multiprotokoll-Router, der für ausgewählte Anschlüsse bzw. Ports die Grenz-Routingsysteme-Architektur (boundary routing system architecture) umfasst. Bei dem Blattknoten 91 handelt es sich um ein dezentrales Interface für den zentralen Knoten 92, das Pakete, die an das Interface auf dem zentralen Knoten adressiert sind, für das Blattnetzwerk über die WAN-Verbindung 90 zu dem zentralen Knoten für ein Routing weiterleitet und Pakete, die über die WAN-Verbindung 90 empfangen werden, die nicht an den Blattknoten 91 adressiert sind, an das angebrachte Netzwerk weiterleitet. Die Filter- und Verschleierungsressourcen werden verwendet, um den Multicast- und Broadcast-Hintergrundsverkehr zu kontrollieren, der für die Kommunikation über die WAN-Verbindung 90 zu dem zentralen Knoten 92 nicht notwendig ist.
  • Die Grenz-Routersysteme-Architektur ist in 5 dargestellt, die ein erstes Netzwerk 110 mit einem zweiten Netzwerk 111 verbindet. Das erste Netzwerk 110 enthält ein erstes LAN 109, das eine Vielzahl von Endsystemen und einen Server umfasst, und kann unter Verwendung bekannter Zwischensysteme (nicht gezeigt) mit anderen LANs verbunden sein. Ein zentraler Router 112 ist mit dem LAN 109 verbunden. Der zentrale Router 112 ist ein Zwischensystem in dem Netzwerk, der Netzwerkressourcen bereitstellt, die Protokollsuiten einer höheren Schicht dienen, die in einer besonderen Ausführungsform Routing-Ressourcen umfassen. Somit verwaltet der zentrale Router 112 Endsystemverzeichnisse 113 für das lokale LAN 109 und globale Routing-Informationen 114, um den Routing-Funktionen gemäß den Protokollsuiten einer höheren Schicht zu dienen. Somit werden die Endsystemverzeichnisse DEC-Endsystemtabellen, IPX-Endsystemtabellen, IP-Endsystemtabellen und andere umfassen, um anderen Protokollsuiten zu dienen, die in dem Netzwerk 110 betrieben werden. Der zentrale Router 112 kann außerdem mit anderen Abschnitten des Firmendatennetzwerkes verbunden sein, wie dies schematisch bei Pfeil 115 dargestellt ist.
  • Der zentrale Router 112 umfasst ein lokales Interface 116, das dem lokalen LAN 109 dazu dient, Endsystemen auf dem LAN 109 Zugang zu den Netzwerkressourcen innerhalb des zentralen Routers 112 bereitzustellen. Der zentrale Router 112 kann außerdem mit anderen lokalen LANs verbunden sein. Darüber hinaus umfasst der zentrale Router 112 ein dezentrales Routing-Interface 117, das Endsystemen in dem dezentralen Netzwerk 111 ein Interface zu den Netzwerkressourcen bereitstellt. Zur Unterstützung des dezentralen Interface 117 bewahrt der zentrale Router 112 Endsystemverzeichnisse 118 auf, die den Protokollsuiten einer höheren Schicht in dem dezentralen Netzwerk 111 dienen. Ein intelligenter Filtermanager 126 ist in den Ressourcen des zentralen Routers 112 enthalten.
  • Wie dies schematisch durch das gestrichelte Symbol 119 dargestellt ist, erscheint das dezentrale Netzwerk 111 den Endsystemen in dem lokalen LAN 109, als ob dieses ein LAN wäre, das lokal mit dem zentralen Router 112 verbunden ist. Dieser Anschein wird über eine Kommunikationsverbindung 120 beibehalten, die Telefon- oder andere Einwählleitungen, geleaste Leitungen, Satelliten, drahtlose Systeme oder andere Kommunikationsmedien zu einem Routing-Adapter 121 verwenden kann, der mit dem dezentralen Netzwerk 111 verbunden ist. Ein intelligenter Filteragent 125 ist in den Ressourcen des dezentralen Interfaces 121 enthalten. Das dezentrale Netzwerk 111 umfasst ein dezentrales LAN 122, mit dem bekanntermaßen eine Vielzahl von Endsystemen und ein Server verbunden werden können. Darüber hinaus kann das LAN 122 bekanntermaßen über Zwischensysteme (nicht dargestellt) in dem dezentralen Netzwerk 111 mit anderen LANs verbunden werden. Der Routing-Adapter 121 stellt Mittel zum transparenten Ausdehnen des dezentralen Routing-Interfaces 117 über die Kommunikationsverbindung 120 auf das Netzwerk 111 bereit. Aus Sicht des dezentralen Netzwerkes 111 stellt der Routing-Adapter 121 dieselben Funktionen wie ein Router bereit, wobei dieser unabhängig von den Protokollsuiten höherer Schichten betrieben wird.
  • 6 zeigt die funktionelle Ausgestaltung eines Boundary-Routers bzw. Grenz-Routers (der im Allgemeinen mit der Bezugsziffer 200 gekennzeichnet ist) und eines Routing-Adapters (der im Allgemeinen mit der Bezugsziffer 201 gekennzeichnet ist).
  • Wenn ein einzelnes Grenz-LAN 223 an den Routing-Adapter 201 angebracht ist, wie dies in 6 dargestellt ist, dann erscheint die Kombination des Routing-Adapters 201 und des Grenz-Routers 200 den Benutzern des dezentralen LANs als ein Endsystem auf dem dezentralen LAN, ganz wie ein normaler Router.
  • Ein zentraler Router umfasst wenigstens ein lokales LAN-Interface 210 für das Anbringen an ein lokales LAN 211. Es gibt ein lokales LAN-Interface für jedes angebrachte LAN, wie dies in der Figur angezeigt ist. Jedem lokalen LAN-Interface wird eine LAN-Adresse für die Verwendung durch die Routing-Ressourcen auf dem zentralen Router zugewiesen. Eine Auskapselungs-/Einkapselungsfunktion 212 ist mit dem lokalen LAN-Interface verbunden, und zwar auch eine für jedes angebrachte LAN. Die Auskapselungs-/Einkapselungsfunktion 212 ist mit Router-Verwaltungsfunktionen 213 und Multiprotokoll-Relay-Funktionen 214 verbunden, die für jedes geroutete Protokoll implementiert sind. Erweiterungen des zentralen Routers, um dem dezentralen Netzwerk zu dienen, umfassen eine Grenz-Router-Verwaltung 215, eine Grenz-Funktion 216 und ein Grenz-Verbindungs-Interface 217. Das Grenz-Verbindungs-Interface 217 ist mit einer Grenz-Verbindung 218 verbunden, die die Kommunikation mit einem Grenz-Verbindungs-Interface 220 auf dem Routing-Adapter 201 bereitstellt. Das Grenz-Verbindungs-Interface 220 ist mit einer Grenz-Relay-Funktion 221 und über die Relay-Funktion 221 mit einem Grenz-LAN-Interface 222 verbunden. Das Grenz-LAN-Interface 222 ist mit dem Grenz-LAN 223 ver bunden. Ferner ist eine Routing-Adapter-Verwaltungslogik 224 zum Durchführen von Verwaltungsfunktionen mit dem Grenz-Relay 221 verbunden.
  • Somit enthält ein zentraler Router die gesamte Logik eines Multiprotokoll-Routers (wie beispielsweise NetBuilder II, der von der Firma 3Com Corporation, Santa Clara, Kalifornien, vertrieben wird) plus Grenz-Funktionalität für die Grenz-Verbindungen, die den Grenz-Router mit dem Routing-Adapter verbinden. Die zusätzliche Funktionalität besteht aus Grenz-Router-Verwaltung 215, Grenz-Funktion 216, intelligentem Filter-Manager 226 und dem Grenz-Verbindungs-Interface 217.
  • Die Grenz-Router-Verwaltung 215 stellt dem Grenz-LAN bzw. den Grenz-LANs 223 einen äquivalenten Satz von Funktionen bereit, wie dies die Router-Verwaltung 213 für das lokale LAN 211 bereitstellt. Sie ist ferner bei der Verwaltung der Grenz-Verbindung 218 und des Routing-Adapters 201 hilfreich.
  • Die Grenz-Router-Verwaltung 215 ist dafür verantwortlich, die Grenz-LAN-Endsystemverzeichnisse für die verbundenen Grenz-LANs aufzubewahren, genauso wie die Router-Verwaltungsfunktion 213 ein lokales LAN-Endsystemverzeichnis für dessen angebrachte lokale LANs aufbewahrt.
  • Für angebrachte lokale LANs wird das lokale LAN-Endsystemverzeichnis durch Protokollrahmenaustausche zwischen der Router-Verwaltungsfunktion 213 und Endsystemen aufbewahrt, die an das lokale LAN 211 angebracht sind. Diese Protokolle werden "Endsystem zu Zwischensystem"-Protokolle (end system to intermediate system; ES-IS-Protokolle) genannt. Üblicherweise weist jedes Protokoll einer höheren Schicht, das von dem Router unterstützt wird, sein eigenes ES-IS-Protokoll auf.
  • Die Grenz-Router-Verwaltungsfunktion 215 unterstützt dieselben ES-IS-Protokolle wie die Routing-Verwaltungsfunktion 213. Jedes Grenz-LAN-Endsystem-Verzeichnis wird durch Protokollrahmenaustausche zwischen der Grenz-Router-Verwaltungsfunktion 215 und Endsystemen aufbewahrt, die an das dezentrale Grenz-LAN 223 angebracht sind.
  • Der Strom von Rahmen von der Grenz-Router-Verwaltungsfunktion 215 wird eingeleitet, indem die Grenz-Router-Verwaltungsfunktion 215 die ES-IS-Protokollnachrichten direkt zu der Grenzfunktion 216 führt, um diese an die Grenz-LAN-Endsysteme weiterzuleiten. Der entgegengesetzte Strom von ES-IS-Rahmen von den Grenz- LAN-Endsystemen zu der Grenz-Router-Verwaltungsfunktion 215 wird ebenso unterstützt.
  • Die Grenz-Router-Verwaltungsfunktion 215 ist ferner dafür verantwortlich, die Verwaltung von verbundenen Routing-Adaptern 201 zu erleichtern, indem derselbe Grad an Durchsichtigkeit und Steuerung bzw. Kontrolle der verknüpften Grenz-LANs 223 ermöglicht wird, wie dies durch die Router-Verwaltungsfunktion 213 für die angebrachten lokalen LANs 211 möglich gemacht wird. Außerdem kann eine erweiterte Durchsichtigkeit und Kontrolle bzw. Steuerung der Grenzverbindungen 218, der Interfaces 217 usw. bereitgestellt werden.
  • Alle Verwaltungsanfragen, Antworten und dergleichen werden zunächst von der Router-Verwaltungsfunktion 213 empfangen. Router-Verwaltungsrahmen von angebrachten lokalen LANs 211 werden zu der Router-Verwaltungsfunktion 213 in einem Grenz-Router weitergeleitet, und zwar genauso wie dies in einem regulären Router passieren würde. Aus dem Nachstehenden ergibt sich, dass dasselbe für Router-Verwaltungsrahmen von verbundenen Grenz-LANs 223 der Fall ist, da ein Routing-Adapter 201 Verwaltungsrahmen weiterleitet, die auf dem Grenz-LAN 223 empfangen werden, und zwar über die Grenzverbindung 218 zu dem Grenz-Router 200.
  • Die Grenz-Router-Verwaltung 215 verarbeitet die Verwaltungsanfragen, Antworten, Teile von Anfragen und dergleichen, die mit dem Grenz-LAN 223 zu tun haben (z.B. Bestimmen des Typs des Grenz-LAN-ETHERNET, TOKEN RING oder FDDI). Die Grenz-Router-Verwaltung 215 sammelt und verändert dezentrale Grenz-LAN-Information, indem Rahmen zu der Routing-Adapter-Verwaltungsfunktion 224 gesendet werden und Rahmen von der Routing-Adapter-Verwaltungsfunktion 224 empfangen werden. Gleichermaßen können andere Aspekte der Boundary-Router-/Routing-Adapter-Domäne verwaltet werden (z.B. Einstellen, Ändern und Sammeln lokaler/dezentraler Informationen über beide Enden der Grenzverbindung).
  • Die Grenzfunktion 216 ist zwischen den Multiprotokoll-Router-Relay-Funktionen 214 und der Grenzverbindungs-Interface-Funktion 217 positioniert. Ein Paar bestehend aus einer Grenzfunktion 216 und einem Grenzverbindungs-Interface 217 ist jeder Grenzverbindung 218 zugeordnet. Die Multiprotokoll-Router-Relay-Funktion 214 ist mit jedem Grenzfunktions-/Grenzverbindungs-Interface-Paar separat verbunden. Jedes Paar bildet ein eindeutig adressiertes erweitertes dezentrales Inter face für die Routing-Ressourcen in dem Grenz-Router aus, das transparent über die jeweilige Verbindung 218 zu dem Routing-Adapter 201 ausgedehnt ist.
  • Die Grenzfunktion 216 ist dafür verantwortlich, dasselbe Interface bereitzustellen, wie es die Einkapselungs-/Auskapselungs-Funktion 212 für ein angebrachtes lokales LAN 211 bereitstellt. Dies bedeutet, dass die Multiprotokoll-Relay-Funktion 214 nicht zwischen angebrachten lokalen LANs und verbundenen Grenz-LANs unterscheidet.
  • Die Grenz-Funktion 216 ist ferner dafür verantwortlich, Protokoll-Informationen höherer Schichten in das und aus dem Format des dezentralen Grenz-LAN 223 (z.B. ETHERNET, TOKEN RING oder FDDI usw.) einzukapseln/auszukapseln, und zwar genauso wie dies die Einkapselungs-/Auskapselungs-Funktion 212 für sein angebrachtes lokales LAN 211 tut.
  • Für die Einkapselung wird die LAN-spezifische Rahmenformatinformation des Grenz-LANs 223 und der Quelladresswert für das dezentrale Interface zu dem Grenz-Router mittels lokaler Konfigurationsinformation oder mittels eines Protokollaustausches zwischen der Grenz-Router-Verwaltung 215 und der Routing-Adapter-Verwaltung 224 in dem verbundenen Routing-Adapter gelernt. Die LAN-Rahmen-Zieladresswerte werden durch die Multiprotokoll-Relay-Funktion 214 geführt, die diese von einem Grenz-LAN-Endsystemverzeichnis erhält, das von der Grenz-Router-Verwaltungsfunktion 215 unterhalten wird.
  • In der Grenz-Funktion 216 werden eingekapselte Rahmen zu der Grenzverbindungs-Interface-Funktion 217 geführt und von dieser erhalten.
  • Die Grenzverbindungs-Interface-Funktion 217 ist zwischen der Grenzfunktion 216 und der Grenzverbindung 218 angeordnet. Das Grenzverbindungs-Interface 217 arbeitet mit dessen gleichrangiger Grenzverbindungs-Interface-Funktion 220 in dem Routing-Adapter 201 und ist dafür verantwortlich, Rahmen an die Grenzverbindung 218 zu senden und von dieser zu empfangen. Die Funktionalität des Grenzverbindungs-Interface 217 umfasst die Einkapselung/Auskapselung der LAN-Rahmen innerhalb eines Protokolls bzw. aus einem Protokoll, wie beispielsweise das PPP-Protokoll des Internets (point to point protocol), das unter anderem anzeigt, ob die 32 Bit-Rahmenkontrollsumme vorhanden/nicht vorhanden (PRESENT/NOT PRESENT) ist, das LAN-Rahmenformat, ob Bestätigungen notwendig sind, und dergleichen.
  • Eine Kompression/Dekompression von übertragenen/empfangenen Rahmen kann ebenfalls durch die Grenzverbindungs-Interface-Funktion 220 unter Verwendung eines beliebigen Kompressionsprotokolls einer Vielzahl von Kompressionsprotokollen erfolgen.
  • Während einer physikalischen Verbindungsübertragung bzw. einem physikalischen Verbindungsempfang über die Grenzverbindung 218 fügt das Grenzverbindungs-Interface 220 ein beschränkendes Protokoll, wie beispielsweise ISO 3309, hinzu. Während des physikalischen Verbindungsempfangs muss der Rahmen anhand des beschränkenden Protokolls rekonstruiert werden und ungültige Rahmen müssen verworfen werden (z.B. Rahmen mit unrichtigen Rahmenkontrollsummen).
  • Ein Routing-Adapter funktioniert unabhängig von den Protokollsuiten, die in LAN-Rahmen eingekapselt sind, die über das Grenz-LAN 223 und die Verbindung 218, an die dieses angebracht ist, empfangen/gesendet werden. Die Routing-Adapter-Funktionalität besteht aus einem Grenzverbindungs-Interface 220, einem Grenz-LAN-Interface 222, einem Grenz-Relay 221, einem intelligenten Filter-Agenten 225 und einer Routing-Adapter-Verwaltung 224.
  • Die Grenzverbindungs-Interface-Funktion 220 ist zwischen der Grenzverbindung 218 und der Grenz-Relay-Funktion 221 positioniert. Das Grenzverbindungs-Interface 220 in dem Routing-Adapter 201 arbeitet mit dessen gleichrangiger Grenzverbindungs-Interface-Funktion 217 in dem Grenz-Router 200 und ist dafür verantwortlich, Rahmen zu der Grenzverbindung 218 zu senden und Rahmen von dieser zu empfangen. Die Funktionalität des Grenzverbindungs-Interface 220 ist im Wesentlichen identisch zu dem Grenzverbindungs-Interface 217 in dem Boundary-Router bzw. Grenz-Router 200, wie dies vorstehend beschrieben worden ist.
  • Die Grenz-LAN-Interface-Funktion 222 ist zwischen dem Grenz-LAN 223 und dem Grenz-Relay 221 angeordnet. Das Grenz-LAN-Interface 222 ist dafür verantwortlich, Rahmen zu dem Grenz-LAN 223 zu senden und Rahmen von diesem zu empfangen. Die Funktionalität des Grenz-LAN-Interface 222 ist dieselbe wie die Funktionalität der äquivalenten Funktion in einem Router, und umfasst folgendes:
    • 1. Handhaben der physikalischen und der Datenverbindungsprotokolle, usw., wie diese durch das Grenz-LAN 223 definiert sind;
    • 2. Übertragen von Rahmen, die durch die Grenz-Relay-Funktion 221 weitergegeben werden; und
    • 3. Weiterleiten von gültig empfangenen LAN-Datenrahmen zu der Grenz-Relay-Funktion 221, die eine Zieladresse innerhalb eines programmierten Satzes von Adressen aufweisen, einschließlich der Adresse des erweiterten dezentralen Interface zu dem Boundary-Router bzw. Grenz-Router, oder Gruppenadressen, die durch die Routing-Adapter-Verwaltungsfunktion eingestellt ist.
  • Die Grenz-Relay-Funktion 221 umfasst die Rahmen-Relay-Logik des Adapters und operiert unabhängig von Protokollsuiten höheren Schichten. Die Rahmen-Relay-Logik eines Routing-Adapters 201 wird durch die zwei folgenden Regeln definiert.
    • 1. Jeder Rahmen, der von dem Grenz-LAN 223 zu dem Grenz-Relay 221 geführt wird, wird zu dessen Grenzverbindungs-Interface 220 weitergeleitet, es sei denn, dass die Verbindung 218 nicht betriebsbereit ist. In diesem Fall kann es sich um einen Netzwerkverwaltungsrahmen handeln und dieser wird zu der Routing-Adapter-Verwaltungsfunktion 224 geführt. Dies ermöglicht es dem Routing-Adapter, lokal verwaltet zu werden, wenn die Verbindung nicht betriebsbereit ist. Beispielsweise kann die Routing-Adapter-Verwaltung 224 auf Verwaltungsrahmen antworten, die einen Versuch anfragen, eine Verbindung wiederzuöffnen, indem beispielsweise erneute Einwahlen auf Einwählverbindungen versucht werden.
    • 2. Jeder Rahmen, der von dessen Grenzverbindungs-Interface 220 empfangen wird, wird zu dem Grenz-LAN-Interface 222 weitergeleitet, es sei denn, dass sein Ziel der LAN-Adresse des Routing-Adapters entspricht. In diesem Fall handelt es sich um einen Netzwerkverwaltungsrahmen von der Grenz-Router-Verwaltungsfunktion 215 und dieser wird zu der Routing-Adapter-Verwaltungsfunktion 224 geleitet.
  • Die Routing-Adapter-Verwaltung 224 unterhält lokale Konfigurationsinformationen, wie beispielsweise den LAN-Typ des Grenz-LAN 223 und die Multicast-Zieladressen, die empfangen werden sollen.
  • Ferner operiert die Routing-Adapter-Verwaltung 224 als der Agent der Grenz-Router-Verwaltungsfunktion. Somit ist diese für das Verarbeiten und Antworten auf Verwaltungsanfragen, Antworten, usw. verantwortlich, die von diesem empfangen werden.
  • Ferner ist die Routing-Adapter-Verwaltung 224 für das Verarbeiten und das Antworten von Verwaltungsanfragen, Antworten, usw. verantwortlich, die von Endsystemen auf dem Grenz-LAN 223 empfangen werden, wenn die Grenzverbindung 218 nicht betriebsbereit ist.
  • Intelligente Filterung in einer Grenz-Routing-Konfiguration
  • Beim Grenz-Routing bzw. Boundary-Routing werden Pakete ohne neue nützliche Informationen, die durch die WAN-Verbindung durchtreten, als Overhead und damit als überflüssig erachtet. Derartige Pakete werden über die WAN-Verbindung geleitet, werden jedoch letztendlich verworfen, ohne irgendeine Netzwerkfunktion zu beeinflussen. Das Filtern dieser Pakete von der WAN-Verbindung führt zu bedeutenden realisierten Bandbreiteneinsparungen.
  • Um zu filternde Pakete zu identifizieren, wird Verkehr in Betracht gezogen, der auf beiden Seiten der WAN-Verbindung erzeugt wird. Es ist nicht notwendig, jedes Paket zu filtern, das möglicherweise gefiltert werden kann, sondern der Fokus wird vielmehr auf eine Maximierung der WAN-Verbindungsbandbreiten-Einsparung gerichtet. Mit anderen Worten: das System konzentriert sich auf Verkehr, der voluminös ist.
  • Im Wesentlichen gibt es zwei Pakettypen, die reduziert oder eliminiert werden können. Der erste Pakettyp umfasst periodische Broadcast-Pakete, die durch Routing-Protokolle erzeugt werden. Dabei handelt es sich um Router-zu-Router-Pakete und Endsystem-zu-Router-Pakete, die periodisch und/oder Pakete des Broadcast/Multicast-Typs sind.
  • Der intelligente Filtermechanismus (Smart Filtering Mechanism) nutzt die Tatsache, dass überall dort, wo der Inhalt dieser wiederholenden Pakete über einen langen Zeitraum der gleiche bleibt (was üblicherweise für zahlreiche dieser Pakete in einem stabilen Netzwerk der Fall ist), die Wiederholung vermieden werden kann oder gefiltert werden kann und durch andere Mechanismen kompensiert werden kann, bei denen keine Pakete über die WAN-Verbindung gesendet werden.
  • Der zweite Pakettyp, der durch intelligentes Filtern (Smart Filtering) reduziert wird, umfasst Pakete, die durch "Protokoll-Inseln" erzeugt werden. Sogar in einer Grenz-Routing-Umgebung ist es möglich, dass "Protokoll-Inseln" bestehen. Dabei handelt es sich um Netzwerk-Topologien, die immer auf ein Netzwerk mit einem einzigen Blatt beschränkt sind und die keinen Verbindungsbedarf mit anderen Blattnetzwerken oder dem zentralen Router aufweisen.
  • Im Allgemeinen können die Techniken, die dazu verwendet werden, um WAN-Overhead zu reduzieren, folgendermaßen kategorisiert werden:
    • – Einrichten von Paketfiltern. Dies kann auf jedweden Pakettyp angewendet werden, und zwar unabhängig davon, ob diese geroutet werden oder nicht.
    • – Einrichten von Router-/Serice-Regeln auf beiden Seiten der WAN-Verbindung. Diese Technik erfordert die Kenntnis von Routing-Protokollen auf beiden Seiten der WAN-Verbindung.
    • – Verwenden eines Routing-Protokolls, das stufenweise Aktualisierungen (incremental updates) anstatt von periodischen Aktualisierungen durchführt. Unglücklicherweise führen die meisten Routing-Protokolle keine schrittweisen Aktualisierungen durch.
    • – Einrichten statischer Routen/Dienste, um die periodischen Broadcast-Pakete zu eliminieren. Dies kann bei sich stetig veränderten Netzwerken nicht gut funktionieren, da statische Einträge eine Netzwerksynchronisation erschweren. Wenn ein menschliches Eingreifen erforderlich ist, um diese statischen Einträge beizubehalten, dann wird dies mühsam sein und einen hohen Verwaltungsaufwand erzeugen.
    • – "Verschleierungspakete" ("spoofing" packets) anstatt periodischer Protokollpakete. Dies kann erforderlich sein, wenn ein Netzwerkprotokoll (z.B. IPX) von diesen periodischen Paketen abhängt, um die Netzwerksichtbarkeit beizubehalten. Wenn eine IPX-Vorrichtung diese periodischen Pakete nicht empfängt, dann wird diese nicht die Existenz des Netzwerks erkennen. Somit ist ein Verschleiern notwendig, um das Netzwerk für diese Vorrichtungen sichtbar zu halten.
    • – Eine Lösung für den "Protokoll-Insel"-Overhead, wenn kein Überbrücken (Bridging) im Grenz-Routing-Anschluss erfolgt: Verwerfen aller Pakete von diesen "Protokoll-Inseln" durch den Blattknoten. In der Tat achten die Blattknoten darauf, welche Protokolle auf dem zentralen Router geroutet werden und leiten nur Pakete von diesen gerouteten Protokollen zu der WAN-Verbindung weiter.
  • Eine Kombination der vorstehend erwähnten Techniken kann eingesetzt werden, um die gewünschte Wirkung zu erreichen.
  • Bei der intelligenten Filterung (Smart Filtering) ist es unerlässlich, den richtigen Moment für das Aktivieren oder das Deaktivieren der Filterlogik zu bestimmen. Der zentrale Router ist für diese Intelligenz verantwortlich. Die Kriterien für das Aktivieren der intelligenten Filterung auf einem Anschluss bzw. Port sind:
    • – Der Anschluss bzw. Port ist als ein Grenz-Routing-Anschluss definiert worden.
    • – Die intelligente Filterung ist freigegeben.
    • – Die dazugehörige WAN-Verbindung ist hochgefahren und voll betriebsfähig.
  • Im voll betriebsfähigen Zustand wird die intelligente Filterung "Trigger" erfassen und entsprechende Aktionen vornehmen. Bei einem "Trigger" handelt es sich um ein Ereignis, das spezifisch für ein Protokoll ist, oder um einen Umstand, bei dem eine intelligente Filteraktion veranlasst ist. Detaillierte Beispiele können in den nachstehenden Abschnitten dieser Druckschrift gefunden werden.
  • Eine Deaktivierung oder manchmal eine erneute Aktivierung der intelligenten Filterung tritt auf, wenn:
    • – die dazugehörige WAN-Verbindung heruntergefahren ist und nicht mehr betriebsbereit ist.
    • – die intelligente Filterung auf dem Anschluss bzw. Port nicht mehr freigegeben ist.
    • – der Anschluss bzw. der Port nicht mehr als ein Grenz-Routing-Anschluss definiert ist.
  • Im voll betriebsfähigen Zustand kann die Anschlusskonfiguration verändert werden, so dass ein spezifisches Protokoll an dem zentralen Standort nicht länger geroutet wird. Hierbei handelt es sich um eines der Trigger-Ereignisse, die veranlassen, dass eine intelligente Filteraktion ausgeführt werden muss. In diesem Fall sollte die intelligente Filterung für dieses spezifische Protokoll dementsprechend deaktiviert werden.
  • Die Filterintelligenz ist in den Router am zentralen Standort eingebaut und der Blattknoten folgt lediglich den Anweisungen bzw. Richtlinien, die von dem zentralen Router ausgegeben werden. Wenn die intelligente Filterung betriebsfähig ist, dann detektiert der zentrale Router ein Trigger-Ereignis, formuliert die erforderlichen Aktionen, die vorgenommen werden müssen, und "delegiert" Teile der Aktion an den Blattknoten. Diese "Delegierung" wird durch einen nachstehend beschriebenen Transportmechanismus durchgeführt.
  • Der intelligente Filtermechanismus umfasst einen intelligenten Prozess am zentralen Router. Der Prozess verwendet SNMP, um Anfragen über die WAN-Verbindung an den Blattknoten zu senden. Die Instrumentierung der intelligenten Filterungs-MIB auf dem Blattknoten würde die Anfragen von dem zentralen Router ausführen, um somit die erwünschte Filterwirkung zu erreichen. Der größte Teil der erforderlichen Information wird in Echtzeit während des Ablaufs gelernt und notwendige Verstellungen werden gemäß dieser Information dynamisch durchgeführt. Die einzige statische Information ist eine Option zum Freischalten bzw. zum Sperren eines Benutzer-Interface für intelligente Filterung an dem zentralen Router.
  • 7 zeigt ein Diagramm des zentralen Knotens und des Blattknotens, in dem der intelligente Filtermanager und der intelligente Filteragent gemäß einer bevorzugten Ausführungsform hervorgehoben sind, die ausgestaltet ist, um Verkehr zu kontrollieren bzw. steuern, der von dem IPX-Protokoll erzeugt wird. Nach der Beschreibung von 7, um eine heuristische Perspektive zu liefern, werden Implementierungsdetails einer besonderen Ausführungsform beschrieben.
  • Der zentrale Knoten 300 umfasst einen IPX-Treiber 301 und andere Protokoll-Treiber, die im Allgemeinen mit der Bezugsziffer 302 gekennzeichnet sind. Der IPX-Treiber 301 umfasst eine RIP-Tabelle 303 und eine SAP-Tabelle 304. Bei dem Blattverkehr-Managerkern 305 handelt es sich um Software, die in dem IPX-Treiber 301 eingebaut ist, um Trigger-Ereignisse für den intelligenten Filtermanager zu detektie ren. Der intelligente Filtermanager umfasst einen globalen Steuerblock 306, Blattinformations-MIB-Objekte 307, einen intelligenten Filter pro Anschluss-Steuerblock 308 und einen intelligenten Filter pro Anschluss-Client-Nachrichtenblock 309.
  • Diese Komponenten verwenden einen Transportmechanismus, der auf SNMP über das Internetprotokoll (IP) basiert, wie dies bei Block 310 angezeigt ist. Der SNMP-Block 310 ist ein Client eines PPP-Blocks (point to point protocol block) 311, der die Fernverbindung 312 verwaltet. In dem zentralen Knoten 300 sind ferner Grenz-Routing-Ressourcen 313 vorhanden, wie beispielsweise solche, die vorstehend unter Bezugnahme auf 6 beschrieben worden sind.
  • Der zentrale Knoten 300 ist außerdem mit anderen Anschlüssen bzw. Ports (die im Allgemeinen mit der Bezugsziffer 325 gekennzeichnet sind) verbunden und umfasst ähnliche Ressourcen, um derartige Anschlüsse bzw. Ports zu unterstützen, wie dies erforderlich ist.
  • Der Blattknoten, der im Allgemeinen mit der Bezugsziffer 314 gekennzeichnet ist, umfasst einen PPP-Treiber 315, der mit der WAN-Verbindung 312 verbunden ist. Der Transportmechanismus 316 SNMP über IP komplementiert eine vergleichbare Komponente (310) auf dem zentralen Knoten 300. Der SNMP-Transport unterstützt Paket-Tabellen-MIB-Objekte 317 und Blattkontroll-MIB-Objekte 318. Mit den MIB-Objekten 318 ist ein Blattverkehr-Agentkern 319 verbunden, der die Filterung und das Verschleiern auf der Basis der Information in den MIB-Objekten 318 verwaltet, eine Blattglobal-Datenstruktur 320, die dazu verwendet wird, den Blattverkehr-Agentkern 319 zu konfigurieren, sowie ein Blattnetzwerk-Interface 321. Das Blattnetzwerk-Interface 321 ist außerdem mit Grenz-Routing-Ressourcen 322 verbunden, wie beispielsweise denen, die vorstehend unter Bezugnahme auf 6 beschrieben worden sind.
  • Die Implementierung des intelligenten Filtermerkmals (Smart Filtering feature) auf dem zentralen Router wird Smart Filtering Manager (SFM) genannt. Diese Komponente wird einen Prozess starten, um die folgenden Aufgaben zu erledigen:
    • – Die Verwaltung der intelligenten Filterkontrolltabellen pro Anschluss.
    • – Das Erkennen intelligenter Filter-Trigger-Ereignisse und das Reagieren darauf.
    • – Das Zusammenwirken mit dem SNMP-Prozess für jeden intelligenten Filteranschluss.
  • Indem eng mit der intelligenten Filterimplementierung der Blattknoten, dem SNMP-Prozess und den Protokollmodulen, wie beispielsweise den IPX-Modulen, zusammengearbeitet wird, wird die SFM-Komponente die erwünschte Wirkung bei der Einsparung der WAN-Verbindungsbandbreite erreichen.
  • Eine wichtige Datenstruktur, die von der SFM-Komponente verwendet wird, ist ein Steuerblock pro Anschluss (7, Element 308), der SmartFilterManager Control Block (SFMCB) genannt wird.
  • Zusätzlich zu den SFMCBs pro Anschluss wird ein globaler Steuerblock (7, Element 306) verwendet, um allgemeine Steuerinformationen hinsichtlich der intelligenten Filtervorgänge als ganze zu speichern.
  • Der intelligente Filterprozess wird durch Nachrichten aufgerufen, die in dessen Postfächern bzw. Mailboxen empfangen werden. Dieser wird diese Nachrichten in der Reihenfolge abarbeiten, in der diese empfangen worden sind. Jede Nachricht zeigt ein Ereignis an, das Aufmerksamkeit erfordert. Der Prozess wird jede Nachricht auf der Basis des in diesem Abschnitt beschriebenen Algorithmus an die geeignete Verarbeitungsroutine absenden.
  • Der Algorithmus, der verwendet wird, um einen intelligenten Filteranschluss einzurichten, kann, wie in 8 dargestellt, folgendermaßen zusammengefasst werden.
  • Der Algorithmus beginnt, indem bestimmt wird, ob der Anschluss bzw. Port für Grenz-Routing oder intelligentes Filtern eingerichtet ist und ob die Verbindung betriebsbereit ist (Zeile 1). Wenn alle drei Bedingungen erfüllt sind, dann wird für den Anschluss der intelligente Filtermanager-Steuerblock initiiert (Zeile 2). Anschließend wird der intelligente Filtermanager als ein SNL-Client registriert, um den Verbindungsstatus zu empfangen (Zeile 3). Sodann sendet der Manager eine SNMP-Anfrage "set a3SfControl to enabled" an den Blattknoten (Zeile 4).
  • Wenn es bei der empfangenen SNMP-Antwort keinen Fehler gibt (Zeile 5), dann wird ein Zeitgeber gestartet, um zu ermöglichen, dass die anfängliche Routing-Informa tion bestimmt wird (Zeile 6). Ferner werden die intelligenten Filteroperationen in Echtzeit initiiert (Zeile 7).
  • Wenn jedoch ein Fehler empfangen worden ist oder eine Auszeit auftritt, bevor eine Antwort empfangen wird, dann wird der intelligente Filtermanager-Steuerblock freigesetzt und der Algorithmus wird verlassen (Zeilen 8 und 9).
  • Wenn der Anschluss nicht für ein Grenz-Routing und ein intelligentes Filtern eingerichtet ist und die Verbindung betriebsbereit ist, dann wird der intelligente Filter-Manager-Steuerblock freigesetzt und der Algorithmus wird beendet (Zeilen 10 und 11).
  • Die intelligenten Ablauffilteroperationen können mit dem in 9 dargestellten Algorithmus beschrieben werden.
  • Der Algorithmus beginnt, indem bestimmt wird, ob die Operationen hochgefahren werden oder ein Anschluss oder eine Protokollkonfiguration verändert worden ist. Wenn irgendeines dieser Ereignisse eingetreten ist, dann wird eine SNMP-Nachricht "set a3SfProtocolCtrl to (protocols enabled)" an den Blattknoten gesendet (Zeilen 1 und 2). Wenn der Algorithmus hochgefahren wird oder sich Routing-Information geändert hat, dann sendet der Manager eine SNMP-Anfrage, um notwendige Filter bereitzustellen und eine SNMP-Anfrage, um Pakete zu bestimmen, die auf dem Blattnetzwerk verschleiert werden sollen. Ferner werden die Einträge toter Stationen nach einer Benachrichtigung durch den Blattknoten entfernt (Linien 3 bis 6).
  • Die letzten drei Aktionsteile (Zeilen 4 bis 6) hängen zum großen Teil von den Protokollen bzw. dem Protokoll ab, die zu dem Zeitpunkt geroutet werden bzw. das zu dem Zeitpunkt geroutet wird, wenn Entscheidungen getroffen werden.
  • Der in 10 dargestellte Algorithmus wird verwendet, um die intelligente Filterfunktion auf einem Anschluss herunterzufahren.
  • Der Algorithmus beginnt, indem bestimmt wird, ob der Algorithmus für kein Boundary-Routing oder kein intelligentes Filtern eingestellt ist (Zeile 1). Wenn der Algorithmus auf einen dieser beiden Zustände eingestellt worden ist, dann wird eine SNMP-Anfrage "set a3SfResetCtrl" an den Blattknoten gesendet, der Manager wird vom SNL de-registriert und dieser setzt den intelligenten Filtermanager-Steuerblock frei und der Algorithmus wird beendet bzw. verlassen (Zeilen 2 bis 4).
  • Wenn detektiert wird, dass die Verbindung nicht betriebsbereit ist, dann wird ein Zeitgeber gestartet, und zwar für den Fall, dass die Verbindung wieder aktiv wird (Zeilen 5 und 6). Wenn der Zeitgeber ausläuft, dann wird der intelligente Filtermanager-Steuerblock (SF Smart Filter manager control block) gesperrt (Zeilen 7 und 8).
  • Der Algorithmus zum Bearbeiten von Ausnahmen ist in 11 dargestellt.
  • Der Algorithmus beginnt, wenn eine SNMP-Anfrage abgelaufen ist (Zeile 1). Wenn diese abgelaufen ist, dann wird die Anfrage erneut gesendet, bis eine vorherbestimmte Grenze von erneuten Versuchen erreicht worden ist (Zeile 2). Wenn diese Grenze erneuter Sendungen erreicht worden ist, dann wird der intelligente Filter-Manager-Steuerblock freigesetzt und der Algorithmus wird beendet (Zeilen 3 und 4).
  • Wenn der Algorithmus keine Ressourcen aufweist oder ein schwieriges Problem sich diesem stellt, dann sendet der Manager eine SNMP-Anfrage "set a3SfResetCtrl" zu dem Blattknoten, falls dies möglich ist, setzt sodann den intelligenten Filtermanager-Steuerblock frei und bricht ab (Zeilen 5 bis 7).
  • 12 liefert einen Abriss eines erweiterten Pseudo-Codes der intelligenten Ablauf-Filter-Manageroperationen für IPX. Der Algorithmus läuft ab, wenn ein RIP- oder ein SAP-Paket von dem zentralen Knoten empfangen wird.
  • Zunächst bestimmt der Algorithmus, ob das RIP-/SAP-Paket von einem Server auf einem lokalen Netzwerk stammt (Zeile 1). Wenn dies der Fall ist, dann bestimmt der Algorithmus, ob das RIP-/SAP-Paket bei der Durchsicht der RIP-/SAP-Tabelle in dem zentralen Knoten verändert worden ist. Wenn dieses verändert worden ist, dann wird eine veränderte RIP-/SAP-Nachricht unter Verwendung der SNMP-MIB-Struktur erzeugt (Zeile 3). Diese Nachricht wird an die Grenz-Routing-Anschlüsse und die intelligenten Filter-Anschlüsse auf dem zentralen Knoten weitergeleitet (Zeile 4). Die geänderte RIP-/SAP-Nachricht wird zu den Blattknoten gesendet (Zeile 5). Das empfangene RIP-/SAP-Paket wird zu den Anschlüssen gesendet, die nicht für ein Boundary-Routing oder ein intelligentes Filtern konfiguriert sind, und zwar, falls dies geeignet ist, gemäß dem Protokoll (Zeilen 6 und 7).
  • Beim Blattknoten wird das RIP-/SAP-Paket, das für das Verschleiern verwendet wird, mit den Veränderungen aktualisiert (Zeile 8).
  • Wenn es keine Veränderungen des RIP- oder SAP-Pakets gegeben hat, das von dem Server auf einem lokalen Netzwerk empfangen worden ist, dann wird das RIP- oder SAP-Paket lediglich an die Anschlüsse gesendet, die nicht für ein Boundary-Routing und ein intelligentes Filtern konfiguriert sind (Zeilen 9 bis 11).
  • Wenn das RIP-/SAP-Paket, das von dem zentralen Knoten empfangen wird, von einem Server auf dem Blattnetzwerk stammt (Zeile 12), dann werden die RIP- und SAP-Tabellen auf dem zentralen Knoten aktualisiert (Zeile 13). Anschließend wird die MAC-Adresse des Servers bestimmt, von dem das RIP-/SAP-Paket stammt (Zeile 14). Sodann wird eine Filternachricht an den Blattknoten gesendet, von dem das Paket empfangen worden ist, und zwar mit der MAC-Adresse des Servers, von dem das Paket stammt (Zeile 15). An dem Blattknoten werden in Reaktion auf die Filternachricht Broadcast-Pakete gefiltert, die eine Quelladresse aufweisen, die der MAC-Adresse des Servers entspricht (Zeilen 16 und 17).
  • Die SFM-Komponente arbeitet mit dem SNMP-Prozess für die folgenden Aufgaben zusammen:
    • – Das Erzeugen von SNMP-Anfragen zum Senden an die Blattknoten.
    • – Das Empfangen von SNMP-Antworten und das Reagieren darauf.
  • Die SFM-Komponente verwendet ein Nachrichten-Interface für die Kommunikation mit dem SNMP-Prozess. Die Nachrichten enthalten notwendige Parameter, um entweder das Erzeugen einer SNMP-Anfrage zu unterstützen oder um das Ergebnis einer SNMP-Antwort zu übertragen.
  • Nachdem eine Anfrage von der SFM-Komponente empfangen worden ist, erzeugt der SNMP-Prozess ein SNMP-Anfrage-Paket und bringt einen Prozess hervor, um auf die Antwort zu warten. Der SNMP-Prozess sendet eine Nachricht (mit dem Ergebnis oder einer Fehlermeldung) zurück an das SFM-Modul, wenn eine Antwort empfangen wird.
  • Die SFM-Komponente arbeitet mit deren Clients für ein Erfassen und ein Reagieren auf die Trigger-Ereignisse zusammen. Ein Client-Nachrichten-Interface (7, Element 309) unterstützt Operationen, einschließlich das Freischalten bzw. Sperren von Anschlüssen, Protokoll-Routing-Entscheidungsänderungen, das Entleeren eines spezifischen Pakettyps, ein neues Verschleierungspaket, das Ende einer Verschleierungsbatch, sowie eine Host-Adresse, die auf dem Blattnetzwerk gefiltert werden soll.
  • Die intelligenten Filter-Trigger-Ereignisse können in den folgenden Kategorien zusammengefasst werden:
  • 1. Ereignisse, die das gesamte intelligente Filtermerkmal auf dem Anschluss aktivieren oder deaktivieren.
  • Diese Ereignisse umfassen Änderungen der Anschluss-Steuerparameter und Änderungen der WAN-Verbindung selbst. Beide Veränderungstypen könnten zum Freischalten oder Sperren des intelligenten Filtermerkmals auf dem Anschluss führen.
  • 2. Ereignisse, die die intelligenten Filteroperationen hinsichtlich der Protokollaktivierung beeinflussen.
  • Diese Ereignisse sind Veränderungen, die an der Protokollaktivierung auf dem Boundary-Routing-Anschluss vorgenommen werden. Wenn beispielsweise das IPX-Routing von freigeschaltet zu gesperrt verändert wird, dann würde dementsprechend das ganze IPX-Verschleiern und IPX-Filtern, das auf dem Blattknoten durchgeführt wird, gestoppt werden.
  • 3. Protokoll-spezifsche Ereignisse, die Veränderungsaktionen des Filterns oder des Verschleierns veranlassen.
  • Diese Trigger-Ereignisse sind protokoll-spezifische Situationen, die Reaktionen von dem intelligenten Filter-Code induzieren. Beim IPX-Routing würden beispielsweise Veränderungen der RIP- oder SAP-Tabellen aufgrund von neuen empfangenen RIP- oder SAP-Paketen anzeigen, dass irgendetwas für die intelligenten Filteroperationen unternommen werden muss. Ein weiteres Beispiel ist das Entleeren der IPX-Tabellen.
  • Da die IPX-Protokoll-Module über diese Trigger-Ereignisse Bescheid wissen, ist es natürlich und sehr effizient, dass die IPX-Komponenten dieses Wissen an das SFM- Modul weitergeben. Wenn beispielsweise die RIP- oder SAP-Pakete erstellt werden, dann haben die IPX-Module die Information, ob gegenüber der letzten Verarbeitung eine Veränderung stattgefunden hat. Diese Information sollte zu dem SFM-Modul kommuniziert werden, und zwar als ein Trigger-Ereignis, so dass das SFM darauf reagieren wird.
  • Die vorstehend aufgeführten Trigger-Ereignisse werden über das vorstehend beschriebene Client-Interface an die SFM-Komponente kommuniziert.
  • Die MIB-Objektgruppe (management information Base object group), die von dem SNMP-Transport unterstützt wird, enthält die folgenden Objekte:
    • – Das Objekt zum Freischalten bzw. zum Sperren des intelligenten Filters. Dieses Objekt kann außerdem dazu verwendet werden, um zu bestimmen, ob der Blattknoten überhaupt eine intelligente Filterung unterstützt.
    • – Die Netzwerkprotokolle, die an dem zentralen Router geroutet werden.
    • – Ob eine Überbrückung (Bridging) auf dieser Verbindung freigeschaltet ist oder nicht.
    • – Die Pakete, die durch die Blattknoten "verschleiert" werden sollen, sowie Intervalle zwischen diesen Paketen – hierbei sollte es sich um ein zusammengesetztes Objekt handeln, und eine Tabelle sollte mit mehreren Paketeinträgen definiert sein.
    • – Weitere Informationen, z.B. zusätzliche Informationen, die dazu benötigt werden, Filter, Regeln und Masken auf dem Blattknoten einzurichten – Information, die nicht über bestehende MIB-Objektgruppen erhältlich ist.
  • Die Kommunikationen zwischen dem zentralen Router und seinen Blattknoten werden als SNMP-Operationen durchgeführt. Die Art und Weise, in der SNMP abläuft, verstärkt wiederum die vorstehend erwähnte Master-Slave-Beziehung. Innerhalb des SNMP-Modells ist der zentrale Router die SNMP-Verwaltungsstation und die Blattknoten sind SNMP-Agenten.
  • Filteroperationen werden durch das intelligente Filtersystem automatisch eingerichtet. Alle notwendigen Informationen hinsichtlich der Trigger-Ereignisse und des Routings wird während des Ablaufs ohne menschliche Einwirkung gelernt. Die einzige Sache, die ein menschliches Eingreifen erforderlich machen kann, ist, ob das intelligente Filtermerkmal auf dem Grenz-Routing-Anschluss aktiviert werden soll.
  • Die Verwendung von SNMP geht davon aus, dass eine IP-Konfiguration auf beiden Seiten der WAN-Verbindung zur Verfügung steht. Ein Protokoll ohne Adressen wird jedoch für Benutzer bereitgestellt, die nicht IP benutzen, wie dies nachstehend unter Bezugnahme auf 13 beschrieben wird.
  • Der Anhang führt die MIB-Definitionen auf, die in dem intelligenten Filtermerkmal verwendet werden.
  • Die intelligente Filter-MIB (Smart Filtering MIB) enthält insgesamt drei Objektgruppen. Zwei dieser Objektgruppen werden verwendet, um zu ermöglichen, dass der zentrale Router seine Befehle über diese Objekte durchführt, um die erwünschten Wirkungen hervorzurufen. Eine dritte Gruppe wird verwendet, um zu ermöglichen, dass der Blattknoten den zentralen Router über Informationen benachrichtigt, die der Blattknoten aufweist. Die ersten zwei Gruppen sind auf dem Blattknoten implementiert, während die dritte Gruppe auf dem zentralen Router implementiert ist. Nachstehend findet sich ein Überblick über diese Objekte.
  • Steuerung (7, Element 318)
  • Diese Objektgruppe wird durch den zentralen Router verwendet, um die folgenden Operationen zu steuern:
    • 1. Aktivierung der intelligenten Filteroperation.
    • 2. Registrierung zu dem Blattknoten der Protokolle, die auf dem Grenz-Routing-Anschluss an dem zentralen Standort freigeschaltet sind, so dass der Blattknoten Filter anwenden würde, um Verkehr korrekt zu verwerfen, der von "Protokoll-Inseln" erzeugt wird.
    • 3. Entleeren aller Paketeinträge.
  • Es gibt außerdem eine Untergruppe von Objekten, die Information aufweisen, die wichtig für die intelligente Filteroperationen sind, die durch den Blattknoten aufgezeichnet worden sind. Die Informationen umfassen Statusdaten, Daten über die Gründe für ein Versagen und Buchhaltungsdaten.
  • Pakettabelle (7, Element 317)
  • Diese Objektgruppe wird von dem zentralen Router verwendet, um Verschleierungspakete für den Blattknoten zu erzeugen, so dass der Blattknoten diese Pakete periodisch zu dem Blattnetzwerk übertragen kann. Es gibt ferner eine Untergruppe, die verwendet wird, um Filter auf dem Blattknoten bereitzustellen, so dass der Blattknoten spezifische Broadcast-Pakete von Stationen auf dem Blattnetzwerk verwerfen wird.
  • Es gibt drei Tabellen in dieser Gruppe:
    • 1. Pakettyp-Tabelle – Diese Tabelle enthält alle Steuerparameter und Informationen, die für einen bestimmten Pakettypen, z.B. IPX-SAP, zur Verfügung stehen. Jede Reihe in dieser Tabelle stellt einen bestimmten Pakettyp und dessen dazugehörige Datenelemente dar. Der zentrale Standort kann eine Minimumanzahl von Befehlen ausgeben, um alle Pakete desselben Typs über diese Tabelle zu steuern.
    • 2. Pakettabelle – Diese Tabelle enthält die tatsächlichen Pakete, die periodisch von dem Blattknoten übertragen werden sollen. Jede Reihe in dieser Tabelle stellt ein zu übertragendes Paket dar.
    • 3. Adresstabelle – Diese Tabelle enthält eine Liste der Stationen auf dem Blattnetzwerk.
  • Blattinformation (7, Element 307)
  • Diese Objektgruppe wird von einem Blattknoten verwendet, um den dazugehörigen zentralen Router über wichtige Informationen zu informieren, die der Blattknoten gesammelt hat. Lediglich wichtige Informationen, wie beispielsweise Fehlermeldungen oder tote Server, werden übermittelt. Andere Informationen, wie beispielsweise Buchhaltung oder Statistiken, können ebenfalls umfasst werden.
  • Die Ausgestaltung der intelligenten Filter-MIB erlaubt eine Flexibilität beim Erzeugen eines Paketeintrags. Üblicherweise wird ein MIB-Tabelleneintrag erzeugt, indem ein Index für den Tabelleneintrag ausgewählt wird und sodann das Feld "entry.status" des Eintrags gesetzt wird, der durch den Index spezifiziert ist. Wenn ein Agent der Anfrage nicht entsprechen kann, den spezifizierten Eintrag zu erzeugen, z.B. Erzeugen eines bestehenden Eintrags oder wenn keine Ressourcen vorhanden sind, dann wird eine Antwort mit einer Fehlermeldung zurückgegeben. Dann ist es Aufgabe des Managers, einen anderen Index zu versuchen.
  • Hinsichtlich der intelligenten Filter-Implementierung folgt aus dem vorstehend beschriebenen Eintragserzeugungsschema, dass der zentrale Router die Tabellenverwendung überwacht, sich den nächsten erhältlichen Index für die Eintragserzeugung verschafft und die Pakettabelle mittels dieser Indices verwaltet. Dieses Verfahren der Eintragserzeugung erzeugt zusätzlichen SNMP-Verkehr, insofern als der zentrale Router sich einen brauchbaren Index vor der Eintragserzeugung verschaffen muss oder riskieren muss, aufgrund eines ungültigen Indexes oder aufgrund von zu wenig Speicher bei der Eintragserzeugung abgewiesen zu werden. Die zentrale Router-Implementierung kann außerdem schwierig werden, wenn dieser die Tabellenverwendung überwachen muss, wobei ein detailliertes Wissen über die Pakettabelle auf dem Blattknoten aufbewahrt wird. Offensichtlich skaliert dieses Verfahren nicht gut mit einer großen Anzahl von Blattknoten.
  • In der Realität jedoch kann das vorstehend erwähnte Eintragserzeugungsschema bei einigen intelligenten Filteroperationen nicht benötigt werden. Beispielsweise beim Verschleiern von IPX-SAP-Paketen zu dem Blattnetzwerk befiehlt der zentrale Router dem Blattknoten, alle SAP-Pakete zu verschleiern, die von dem zentralen Router erzeugt worden wären, wenn die intelligente Filterung nicht im Einsatz wäre. Beim Freischalten oder Sperren des intelligenten Filtermerkmals ist der zentrale Router daran interessiert, das Verschleiern aller SAP-Pakete freizuschalten oder zu sperren und nicht nur daran, einen bestimmten Paketeintrag zu verschleiern.
  • Dasselbe gilt für das Aktualisieren von Verschleierungspaketen, wenn neue Information zur Verfügung steht. Da der Blattknoten nicht den Inhalt in diesen Verschleierungspaketen versteht (kein IPX-Protokoll-Stapel steht auf dem Blatt zur Verfügung), kann dieser nicht einfach den betroffenen Paketeintrag aktualisieren. Stattdessen werden alle SAP-Verschleierungspakete als eine "Charge" ("batch") aktualisiert. In diesem Sinne erfolgt der Tabellenzugang tatsächlich auf einer "Char gen"-Basis, d.h. alle SAP-Verschleierungspakete sind in einer Charge gruppiert. Indem dieses Modell verwendet wird, wird die intelligente Filterimplementierung vereinfacht und der SNMP-Verkehr auf der WAN-Verbindung reduziert.
  • Die intelligente Filter-MIB ist ausgestaltet, um das vorstehend beschriebene "Chargen"-Modell ("batch" model) zu vereinfachen. Wenn Verschleierungspaketeinträge auf dem Blattknoten erzeugt werden, dann startet der zentrale Router damit, einen Verschleierungspaketeintrag mittels des aller ersten Indexes, d.h. Eins, zu erzeugen. Wenn es weitere Pakete zum Verschleiern gibt, dann wird der zentrale Router den nächsthöheren Index usw. verwenden.
  • Ein Vorteil der Verwendung dieses Modells besteht darin, dass der zentrale Router von der Notwendigkeit entlastet wird, die detaillierte Verwendung der Pakettabelle zu verfolgen bzw. zu überwachen. Indem des Weiteren Operationen in einem "Chargen"-Modus durchgeführt werden, wird der SNMP-Verkehr auf ein Mindestmaß beschränkt. Wenn beispielsweise alle SAP-Pakete in der Verschleierungstabelle entleert werden, dann kann der zentrale Router eine SNMP-Anfrage verwenden, um alle SAP-Verschleierungspakete zu entfernen, ohne irgendeinen Index zu spezifizieren. Wenn dieses Verfahren nicht verwendet wird, können mehrere SAP-Anfragen/Antworten erforderlich sein.
  • IPX-Unterstützung
  • Um IPX-Broadcast-Verkehr zu filtern, wird die SFM-Komponente für jeden Typ von Broadcast-Verkehr geeignete Schritte vornehmen.
  • Der Benutzer kann dazu in der Lage sein, den Operationsmodus für RIP- und SAP-Broadcast zu konfigurieren, indem spezifiziert wird, ob die Routing-/Service-Aktualisierung mittels periodischer Aktualisierungen oder mittels nicht-periodischer, stufenweiser bzw. inkrementaler Aktualisierungen erfolgen soll.
  • Wenn die Einstellung der RIP-/SAP-Steuerung nicht-periodisch ist, dann wird kein Verschleiern (und kein intelligentes Filtern) benötigt, da RIP-/SAP-Broadcast nun inkremental aktualisiert wird. Keine weitere Einsparung von Bandbreite kann mittels des intelligenten Filtermerkmals in diesem Falle realisiert werden. Wenn die Einstellung periodisch ist, dann wird das intelligente Filtermerkmal die nachstehend beschriebenen Operationen durchführen.
  • Die SFM-Komponente richtet die Verschleierungspakettabelle auf dem Blattknoten ein, um das Verschleiern zu starten. Sobald das Verschleiern gestartet worden ist, werden die RIP- und SAP-Aktualisierungs-Pakete für den Grenz-Routing-Anschluss auf dem zentralen Router nicht zum Blattnetzwerk übergehen. Dies kann erreicht werden, indem verlangt wird, dass IPX-Komponenten sich mit SFM konsultieren, bevor diese Pakete erstellt werden.
  • Wenn ein RIP- oder ein SAP-Aktualisierungspaket erzeugt wird, dann haben die IPX-Protokollmodule das Wissen darüber, ob es gegenüber der vorherigen Verarbeitung irgendeine Veränderung gegeben hat. Wenn es Veränderungen gegeben hat, dann benachrichtigen die IPX-Module das SFM-Modul, die bestehenden Verschleierungspakete auf dem Blattknoten zu entleeren und sodann die Verschleierungstabelle mit neuen Verschleierungspaketen zu starten.
  • Wenn das intelligente Filtern gestoppt wird, z.B. indem die RIP-/SAP-Steuerung auf nicht-periodisch gestellt wird, wenn das Verschleiern bereits vorgenommen wird, dann könnte das SFM-Modul lediglich eine SNMP-Anfrage verwenden, um die Verschleierungsoperation zu säubern. Indem das a3SfFlushCtl-Objekt auf den entsprechenden zu entleerenden Pakettyp gesetzt wird, benachrichtigt das SFM-Modul den Blattknoten, die Verschleierungsoperation für den identifizierten Pakettypen zu stoppen und die Verschleierungstabelle dementsprechend zu entleeren. Es ist anzumerken, dass die RIP- und die SAP-Verschleierung separat gesteuert und entleert werden können.
  • Die SFM-Komponente richtet Filter auf dem Blattknoten ein, um RIP- und SAP-Broadcasts von allen IPX-Servern auf dem Blatt-LAN zu filtern. Die a3SfAddrTable-Objektgruppe in der intelligenten Filter-MIB wird verwendet, um diese Aufgabe zu erleichtern. Der intelligente Filter-Agent-Code auf dem Blattknoten weist eingebaute Filter auf, um alle RIP- oder SAP-Broadcasts zu verwerfen, die von den IPX-Servern erzeugt werden, die durch die a3SfAddr-Tabelle identifiziert werden. Die SFM-Komponente würde die Adresstabelle mit Serveradressen füllen, die in dem Blattnetzwerk gelernt worden sind.
  • Wenn ein neuer Server auf dem Blatt-LAN hochgefahren wird, dann werden seine Route-/Service-Broadcasts ungefiltert durch die WAN-Verbindung durchgehen. Die IPX-Module erfahren von dem neuen Server mittels des empfangenen Broadcast-Pakets. Nachdem die Route-/Service-Tabellen aktualisiert worden sind und die Emp fangsregeln überprüft worden sind, fügt der zentrale Router den neuen Server zu der a3SfAddr-Tabelle auf dem Blattknoten hinzu. Folglich werden nachfolgende Broadcasts von dem neuen Server auch gefiltert.
  • Der intelligente Filteragent-Code auf dem Blattknoten weist einen Zeitgeber auf, um alle Server in der a3SfAddr-Tabelle zu überwachen. Wenn der Blattknoten während der üblichen Auszeitperiode nichts von einem Server gehört hat, dann wird angenommen, dass der Server "tot" ist, und die SFM-Komponente muss hinsichtlich dieser Information benachrichtigt werden. Die a3SfLeaflnfo-Objektgruppe in der intelligenten Filter-MIB wird dazu verwendet, dass der Blattknoten die SFM-Komponente benachrichtigt.
  • Wenn die intelligente Filterung gestoppt wird, indem beispielsweise das Merkmal von dem Anschlusssteuerparameter gesperrt wird, dann werden die RIP- und SAP-Einträge, die mittels des Blattnetzwerkes gelernt worden sind, dementsprechend entfernt. Die SFM-Komponente wird außerdem den Blattknoten benachrichtigen, das Filtern von RIP- und SAP-Broadcasts von IPX-Servern auf dem Blattnetzwerk zu stoppen.
  • Ein Benutzer kann die Routing-Steuerung freischalten oder sperren oder die RIP-Tabelle und die SAP-Tabelle mittels des IPX-Service im Benutzer-Interface entleeren. Wenn dies passiert, dann muss die SFM benachrichtigt werden, so dass diese die Verschleierungsoperationen auf dem Blattknoten beenden kann. Die Filteroperation auf dem Blattknoten muss ebenfalls gestoppt werden, so dass Broadcast-Verkehr von IPX-Servern auf dem Blattnetzwerk von dem zentralen Router empfangen werden kann.
  • Blattknoten-Implementierung
  • Die Implementierung des intelligenten Filtermerkmals auf dem Blattknoten wird intelligenter Filter-Agent genannt (smart filtering agent; SFA). Diese Komponente ist eine Instrumentierung der meisten Objektgruppen in der intelligenten Filter-MIB auf dem Blattknoten. Durch das Bedienen der SNMP-Anfragen wird die SFA-Komponente die Direktiven von dem zentralen Router ausführen und somit den erwünschten Verschleierungs- und Filter-Effekt erreichen.
  • Die SFA-Komponente wird als ein Prozess implementiert. Die meisten Funktionalitäten werden durch direkte Funktionsaufrufe im Kontext des SNMP-Prozesses aufgerufen. Üblicherweise würde der SNMP-Prozess Anfragepakete von der WAN-Verbindung empfangen und sodann die Anfragen an Funktionen weitergeben, die in der MIB-Tabelle registriert sind. Wenn die SFA-Komponente mit dieser Anfrage fertig ist, gibt diese die Steuerung an den SNMP-Prozess zurück. Der SNMP-Prozess erzeugt sodann das Antwortpaket mit dem Ergebnis von der SFA-Komponente.
  • Der SFA-Prozess ist außerdem für das Ausführen von Ankündigungszeitgebern für Verschleierungspakete und für das Übertragen der Pakete an den LAN-Anschluss verantwortlich, wenn diese Zeitgeber ablaufen.
  • Die internen Datentabellen ähneln der a3SfPkType-Tabelle, der a3SfPacket-Tabelle und der a3SfAddr-Tabelle, die in der intelligenten Filter-MIB definiert sind. Zusätzlich zu diesen Tabellen wird eine globale Datenstruktur (7, Element 320) für eine allgemeine Organisation der SFA-Komponente verwendet.
  • Adressenloser Transport
  • Es gibt eine spezielle Bedingung für den SNMP-Verwaltungsprozess, die von der intelligenten Filter-Komponente benötigt wird. Hierbei handelt es sich um die Fähigkeit des SNMP-Manager-Prozesses SNMP-Anfragen zu dem Blattknoten zu bekommen, ohne irgendwelche IP-Adressen zu haben, die entweder auf dem Blattknoten oder dem zentralen Knoten konfiguriert sind. Um das Interface zwischen dem SNMP-Managerprozess und dessen Client sowie UDP zu machen, wird eine spezielle IP-Adresse verwendet, um der IP-Schicht anzuzeigen, dass ein bestimmtes Paket von der intelligenten Filter-Komponente stammt. Wenn IP diese IP-Adresse in dem Zielfeld erkennt, dann wird der Interface-Parameter in der Nachricht von UDP verwendet, um zu bestimmen, über welchen Anschluss das Paket gesendet werden soll. Zusätzlich wird eine spezielle IP-Adresse in dem Quell-IP-Feld platziert und eine IP-Broadcast-Adresse (alle eins) wird in dem Ziel-IP-Feld platziert. Schließlich wird die IP-Komponente eine spezielle MAC-Adresse in dem Ziel-MAC-Adressenfeld platzieren. Währenddessen wird der Blattknoten diese MAC-Adresse als eine besondere Adresse erkennen und das Paket akzeptieren. Da es sich bei der Ziel-IP-Adresse um ein Broadcast handelt, wird das Paket sich entlang des Protokollstapels hocharbeiten und zu SNMP geliefert. Nachdem die SNMP-Komponente das Verarbeiten der Anfrage beendet, wird diese das Paket einfach normal behandeln und die Anfrage zu dem zentralen Knoten zurücksenden (in diesem Fall entspricht die Ziel-IP-Adresse der speziellen IP-Adresse). Die IP-Komponente in dem Blattknoten (unter Verwendung desselben Codes wie der zentrale Knoten) wird sodann die spezielle IP-Zieladresse erkennen und den Interface-Nachrichtenparameter anstatt der IP-Adresse verwenden, und zwar bei der Bestimmung auf welchem Anschluss das Paket ausgesendet werden soll.
  • Wenn der SNMP-Agent eine intelligente Filter-Anfrage erhält (der Agent bestimmt dies, indem die Ziel-IP-Adresse der Anfrage überprüft wird; wenn diese 127.0.0.1 ist, dann handelt es um eine intelligente Filter-Anfrage), werden überall Einsen in dem Quell-IP-Adressfeld platziert und der Interface-Parameter wird auf den ersten HSS-Anschluss an der Box gestellt. Da es sich hierbei um einen Blattknoten handeln wird, muss dieser Anschluss der Anschluss sein, über den die Anfrage empfangen worden ist.
  • Weder der zentrale Knoten noch der Blattknoten müssen die IP- oder die MAC-Adresse des anderen bei diesem Transportmechanismus kennen. Der Mechanismus, der verwendet wird, um den unteren Protokollschichten anzuzeigen, dass es sich bei einem Paket um ein intelligentes Filterpaket handelt, funktioniert durch die Verwendung der Ziel-IP-Adresse: Wenn diese 127.0.0.1 ist, dann handelt es sich bei dem Paket um ein intelligentes Filterpaket.
  • 13 zeigt die Aktionen, die von den unteren Schichten vorgenommen werden. Die sendende Seite ist in Box 200 für ein IP-Schicht-Interface dargestellt.
  • Wie in 13 dargestellt, erzeugt einer der zwei Prozesse (snmp_to_udp() oder snmp_mgr_proc()) eine SNMP-Nachricht für eine Lieferung durch das UDP-Interface zu dem Internetprotokolltreiber. In diesem Prozess wird das IP-Ziel auf 127.0.0.1 gesetzt, die IP-Quelle wird überall auf Eins gesetzt (Oxfffffff) und die intelligente Filter-MAC-Adresse wird auf 0x080002001507 gesetzt. Der Interface-Wert wird auf den Anschluss gesetzt, der von dem intelligenten Filtermanager designiert ist. Das IP-Protokoll (Block 200) nimmt die Nachricht in dem Prozess ip_transmit() auf. Wenn das IP-Ziel 127.0.0.1 entspricht, dann wird der von dem intelligenten Filter-Manager designierte Interface-Wert in der Nachricht verwendet. Andernfalls wird der Interface-Wert durch die IP-Ziel-Adresse bestimmt. Anschließend füllt dieser Prozess die Routen-Informationsstruktur auf, was das Einsetzen der Zahl 127.0.0.1 in dem IP-Quellfeld und das Einsetzen von Einsen überall in dem IP-Ziel feld umfasst. Der nächste Prozess ip_tosubnet() nimmt das Paket auf und dann, wenn die IP-Quelladresse 127.0.0.1 entspricht, wird eine spezielle intelligente Filter-MAC-Adresse in dem Ziel-MAC-Feld eingesetzt. Der Prozess wird sodann über die Verbindung zu dem Transportmechanismus heruntergereicht.
  • Auf der empfangenden Seite ist der IP-Prozess in Block 201 dargestellt. Das eingehende Paket wird die intelligente Filter-MAC-Adresse aufweisen. Sie wird als die MAC-Adresse des Anschlusses erkannt und zu der IP-Schicht hochgeleitet. Die IP-Schicht wird das überall aus Einsen bestehende Broadcast-Ziel erkennen und das Paket zu dem UDP-Client hochleiten. UDP wird den Zielanschluss erkennen, der das Paket zu dem SNMP-Prozess hochleitet, snmp_proc_req().
  • Zusammenfassung
  • Wie vorstehend beschrieben, besteht eine der Aufgaben, die in der WAN-Umgebung bestehen, in der optimalen Verwendung der WAN-Verbindung-Bandbreite. Wenn mehr und mehr lokale Netzwerke mittels WAN-Verbindungen miteinander verbunden werden, dann wird ein größerer Teil der Bandbreite der WAN-Verbindung für periodische Broadcast-Pakete verwendet. Typischerweise enthalten diese Pakete eine Momentaufnahme der Netzwerk-Routing-Information. Sie werden in einem bestimmten Intervall mittels eines Broadcast zu dem Netzwerk gesendet, um die Routing-Information auszutauschen und zu aktualisieren, und ermöglichen implizit, dass Routing-Vorrichtungen miteinander synchronisiert werden oder bleiben. In einem stabilen Netzwerk würde der Inhalt dieser Pakete, die von derselben Vorrichtung mittels Broadcast gesendet werden, gleich bleiben.
  • Da die ausgetauschte Routing-Information sehr groß sein kann und die Information proportional zu der Anzahl von Routing-Vorrichtungen sein kann, kann der Bedarf für die WAN-Verbindungsbandbreite für diese periodischen Pakete bedeutend sein. Im Vergleich zu einer Router-zu-Router-Einrichtung reizt das Grenz-Routing-Modell diesen Bedarf weiter aus, indem weiterer, LAN-orientierter Broadcast-Verkehr über die WAN-Verbindung ermöglicht wird.
  • Intelligente Filterung (Smart Filtering) ist eine Lösung, die vorgeschlagen wird, um diese periodischen Pakete zu reduzieren. Indem diese periodischen Pakete auf ein Mindestmaß beschränkt werden, kann die WAN-Verbindungsbandbreite besser für anderen Netzwerkverkehr verwendet werden. Zusätzlich zu diesen periodischen Pa keten wird der intelligente Filterprozess außerdem nach anderen Pakettypen Ausschau halten, die nicht die WAN-Verbindung durchqueren müssen.
  • Die Vorteile der intelligenten Filterungsoperation (smart filtering operation) umfassen:
    • – Die WAN-Verbindungsverwendung wird verbessert, indem unnötiger Verkehr von der Verbindung entfernt wird.
    • – Die Intelligenz wird bei dem zentralen Router gehalten, während der Blattknoten lediglich als ein Agent zum Ausführen von Richtlinien von dem zentralen Router agiert. In dieser Rolle verbleibt der Blattknoten so weit wie möglich protokollunabhängig.
    • – Auf dem zentralen Router ist das intelligente Filtern skalierbar, um zahlreiche Blattnetzwerke unterzubringen.
    • – Die Implementierung ist einfach.
  • ANHANG Copyright 3Com Corporation 1994
    Figure 00400001
  • Dieser Datentyp, der dieselbe Semantik wie die RowStatus-Textkonvention aufweist, die in dem SNMPv2 verwendet wird, wird verwendet, um Einträge in eine Tabelle einzufügen und Einträge in einer Tabelle zu löschen. Die Tabelle in dieser MIB erlaubt einen Teil der Funktionalität, die von dem RowStatus-Text bereitgestellt wird.
  • Die Tabelle in dieser MIB erlaubt einen Teil der Funktionalität, die von der RowStatus-Textkonvention bereitgestellt wird. Insbesondere wird eine Reihenerzeugung unter Verwendung lediglich des createAndGo-Verfahrens ermöglicht. Das heißt, wenn Einträge zu dieser Tabelle hinzugefügt werden, muss dieses Objekt auf createAndGo(4) gesetzt werden. Der Instanz-Identifizierer für dieses Objekt definiert die Werte der Spalten, die diesen Index ausmachen.
  • In derselben PDU müssen die geeigneten verbleibenden Spalten dieser Reihe ebenfalls gesetzt werden. Der Agent wird unmittelbar den Wert des Objekts auf active (1) setzen, wenn die Reihe korrekt ist. Wenn nicht, dann wird der Agent die SET-Abfrage abweisen und eine Fehlermeldung zurücksenden.
  • Um einen Eintrag zu entfernen, wird der Wert dieses Objekts auf destroy (6) gesetzt. Um einen bestehenden Eintrag zu modifizieren, muss dieser entfernt werden und ein weiterer Eintrag mit den erwünschten Veränderungen hinzugefügt werden.
  • Die Objekte in der intelligenten Filter-MIB sind nachstehend aufgelistet.
  • Figure 00410001
  • Figure 00420001
  • Diese Objektgruppe wird verwendet, um Information über intelligente Filter-Operationen auf dem Agenten anzuzeigen.
  • Figure 00420002
  • Figure 00430001
  • Figure 00440001
  • Diese Objektgruppe wird verwendet, um die a3SfPkType-Tabelle und deren Einträge zu beschreiben. Jeder Eintrag enthält die Steuerparameter und verwandte Informationen für Pakete eines bestimmten Typs.
  • Figure 00440002
  • Figure 00450001
  • Figure 00460001
  • Figure 00470001
  • Diese Objektgruppe wird verwendet, um die a3SfPacket-Tabelle und deren Einträge zu beschreiben.
  • Figure 00470002
  • Figure 00480001
  • Figure 00490001
  • Diese Objektgruppe wird verwendet, um Serverstationen auf dem Blattnetzwerk zu identifizieren. Der Filter würde auf dem Blattknoten eingerichtet werden, um Broadcast-Pakete von diesen Serverstationen zu filtern.
  • Figure 00490002
  • Figure 00500001
  • Figure 00510001
  • Diese Objektgruppe ermöglicht einem Blattknoten, dessen zentralen Router über wichtige Informationen zu informieren, die dieser aufgenommen hat. Anders als der Rest der intelligenten Filter-MIB ist diese Objektgruppe an dem zentralen Router implementiert.
  • Figure 00510002
  • Figure 00520001
  • Figure 00530001

Claims (22)

  1. Apparat zur Steuerung von Netzwerkverkehr von einer zentralen Vorrichtung (10) über eine Kommunikationsverbindung (22, 23) zu einem dezentralen Netzwerk (19, 24), das über ein dezentrales Interface (29, 30) mit der Kommunikationsverbindung verbunden ist, wobei zentrale Verkehrsverwaltungsressourcen (28) in der zentralen Vorrichtung umfasst werden, die mit der Kommunikationsverbindung verbunden sind, die Datenpakete überwachen, die über die Kommunikationsverbindung empfangen werden, Verkehrsverwaltungsnachrichten erzeugen und die Verkehrsverwaltungsnachrichten an das dezentrale Interface weiterleiten, um den Verkehr auf der Kommunikationsverbindung zu steuern, dadurch gekennzeichnet, dass die zentralen Verkehrsverwaltungsressourcen Netzwerkverwaltungspakete detektieren und/oder Broadcast- oder Multicast-Pakete detektieren, die durch Routing-Protokolle erzeugt werden, um zu bestimmen, ob derartige Pakettypen nicht von dem dezentralen Interface weitergeleitet werden müssen, und die Verkehrsverwaltungsnachrichten in Antwort auf das Bestimmen erzeugen, ob solche Pakettypen nicht von dem dezentralen Interface weitergeleitet werden müssen.
  2. Apparat nach Anspruch 1, wobei die Verkehrsverwaltungsnachrichten Pakettypen identifizieren, die von dem dezentralen Interface über die Kommunikationsverbindung weitergeleitet werden sollen.
  3. Apparat nach Anspruch 1, wobei die Verkehrsverwaltungsnachrichten Pakettypen identifizieren, die durch das dezentrale Interface für eine Kommunikation mit Anwendern des dezentralen Netzwerkes erzeugt werden sollen.
  4. Apparat nach Anspruch 1, wobei die zentralen Verkehrsverwaltungsressourcen ein Transportprotokoll für die Verkehrsverwaltungsnachrichten unabhängig von einer Netzwerkadresse für das dezentrale Interface ausführen.
  5. Apparat nach einem der vorstehenden Ansprüche, wobei das dezentrale Interface Datenweiterleitungsressourcen enthält, die gemäß Weiterleitungsregeln Datenpakete, die von Anwendern des dezentralen Netzwerkes stammen, über die Kommunikationsverbindung zu der zentralen Vorrichtung in Antwort auf Eigenschaften der Datenpakete weiterleiten, wobei die zentralen Verkehrsverwaltungsressourcen in Antwort auf die Bestimmung, welche Typen einer Vielzahl von Datenpakettypen nicht von dem dezentralen Interface weitergeleitet werden müssen, Verbindungsverwaltungsnachrichten erzeugen und an das dezentrale Interface weiterleiten, und wobei dezentrale Verbindungsverwaltungsressourcen in dem dezentralen Interface in Reaktion auf die Verbindungsverwaltungsnachrichten, die von den zentralen Verbindungsverwaltungsressourcen erhalten werden, die Weiterleitungsregeln anpassen, um ein Weiterleiten der Datenpakete zu verhindern, die nicht an das dezentrale Interface weitergeleitet werden müssen, um unnötigen Verkehr auf der Kommunikationsverbindung zu reduzieren.
  6. Apparat nach Anspruch 5, wobei die zentralen Verkehrsverwaltungsressourcen außerdem Verwaltungsnachrichten des dezentralen Netzwerks auf der Basis eines Protokolls erzeugen, das von anderen Anwendern der zentralen Vorrichtung ausgeführt wird, und die Verwaltungsnachrichten des dezentralen Netzwerkes zu dem dezentralen Interface weiterleiten, wobei der Apparat ferner Verwaltungsressourcen des dezentralen Netzwerkes in dem dezentralen Interface enthält, die Netzwerkverwaltungspakete in Antwort auf die Verwaltungsnachrichten des dezentralen Netzwerkes erzeugen und die Netzwerkverwaltungspakete zu den Anwendern des dezentralen Netzwerkes kommunizieren, wie dies gemäß dem Protokoll erforderlich ist.
  7. Apparat nach Anspruch 6, wobei die zentralen Verbindungsverwaltungsressourcen Eigenschaften von Datenpaketen überwachen, die von anderen Anwendern der zentralen Vorrichtung empfangen werden, um Veränderungen zu lernen, die an den Netzwerkverwaltungspaketen vorgenommen werden müssen, die in den Verwaltungsressourcen des dezentralen Netzwerkes erzeugt werden, Netzwerkverwaltungsnachrichten erzeugen, die die Veränderungen anzeigen, und die Netzwerkverwaltungsnachrichten zu dem dezentralen Interface weiterleiten, wobei der Apparat ferner Ressourcen in dem dezentralen Netzwerkinterface enthält, die die Netzwerkverwaltungspakete in Antwort auf die Netzwerkverwaltungsnachrichten ändern, die die Veränderungen anzeigen.
  8. Apparat nach Anspruch 5, wobei das dezentrale Interface eine Netzwerkadresse aufweist und ferner ein Transportmechanismus umfasst wird, der die Kommunikation der Verbindungsverwaltungsnachrichten zu dem dezentralen Interface bereitstellt, wobei der Transportmechanismus unabhängig von der Netzwerkadresse des dezentralen Interface ist.
  9. Apparat nach Anspruch 5, wobei das dezentrale Interface eine Netzwerkadresse aufweist und ferner ein Transportmechanismus umfasst wird, der die Kommunikation der Verbindungsverwaltungsnachrichten und der Netzwerkverwaltungsnachrichten zu dem dezentralen Interface unabhängig von der Netzwerkadresse des dezentralen Interface bereitstellt.
  10. Apparat nach Anspruch 5, wobei die Weiterleitungsregeln einen Filter enthalten, der auf Quellenadressen in den Datenpaketen basiert.
  11. Apparat nach Anspruch 5, wobei die Weiterleitungsregeln eine Tabelle von Quellenadressen enthalten und die Weiterleitungsressourcen keine Broadcast-Datenpakete zu der zentralen Vorrichtung weiterleiten, die Quellenadressen in der Tabelle aufweisen.
  12. Apparat nach Anspruch 11, wobei die dezentralen Verbindungsverwaltungsressourcen die Tabelle von Quellenadressen in Antwort auf die Verbindungsverwaltungsnachrichten aktualisieren, die von den zentralen Verbindungsverwaltungsressourcen empfangen werden.
  13. Apparat nach Anspruch 12, wobei die zentrale Vorrichtung Multiprotokoll-Routerressourcen enthält und wobei Anwender des dezentralen Netzwerkes auf die Multiprotokoll-Routerressourcen über das dezentrale Interface zugreifen.
  14. Apparat nach Anspruch 5, wobei die zentrale Vorrichtung Multiprotokoll-Routerressourcen enthält, das dezentrale Interface eine Netzwerkadresse aufweist und Anwender des dezentralen Netzwerkes auf die Multiprotokoll-Routerressourcen zugreifen, indem Pakete über das dezentrale Interface ge sendet werden, wo die Weiterleitungsressourcen derartige Pakete an die zentrale Vorrichtung weiterleiten.
  15. Apparat nach Anspruch 6, wobei die Verwaltungsressourcen des dezentralen Netzwerkes eine Tabelle von Netzwerkverwaltungspaketen enthalten, die an Anwender des dezentralen Netzwerkes gemäß dem Protokoll kommuniziert werden sollen, sowie Ressourcen, um die Tabelle in Antwort auf die Netzwerkverwaltungsnachrichten zu aktualisieren.
  16. Apparat nach Anspruch 7, wobei die Verwaltungsressourcen des dezentralen Netzwerkes eine Tabelle von Netzwerkverwaltungspaketen enthalten, die zu Anwendern des dezentralen Netzwerkes gemäß dem Protokoll kommuniziert werden sollen, sowie Ressourcen, um die Tabelle in Antwort auf die Netzwerkverwaltungsnachrichten zu aktualisieren.
  17. Apparat nach Anspruch 7, wobei die zentrale Vorrichtung Ressourcen enthält, die Datenpakete, die Zieladressen aufweisen, die Adressen von Anwendern des dezentralen Netzwerks entsprechen, über die Kommunikationsverbindung zu dem dezentralen Interface weiterleiten, das die Pakete zu den Anwendern des Netzwerkes weiterleitet.
  18. Verfahren zum Verwalten von Verkehr zwischen einem ersten Knoten (10) und einem zweiten Knoten (19), die durch eine Kommunikationsverbindung (22) verbunden sind, gekennzeichnet durch das Detektieren mittels Verarbeitungsressourcen in dem ersten Knoten von Netzwerkverwaltungspaketen und/oder Broadcast- oder Multicast-Paketen, die durch Routing-Protokolle erzeugt werden, und zwar im Verkehr, der zu einem Netzwerk durch den zweiten Knoten über die Kommunikationsverbindung übertragen wird und von einem Netzwerk durch den zweiten Knoten über die Kommunikationsverbindung empfangen wird, um zu bestimmen, ob derartige Pakettypen nicht von dem zweiten Knoten weitergeleitet werden müssen, und in Antwort darauf das Entwickeln mit Verarbeitungsressourcen (28) in dem ersten Knoten einer Verkehrsverwaltungsregeln in dem ersten Knoten und Delegieren von Ressourcen an den zweiten Knoten über die Kommunikationsverbindung, um die Verkehrsverwaltungsregeln auszuführen.
  19. Verfahren nach Anspruch 18, wobei das Überwachen mit Verarbeitungsressourcen von den Paketen des ersten Knotens, die im Verkehr zu dem Netzwerk übertragen werden und von diesem empfangen werden, das Bestimmen einschließt, ob ein Paket, das über die Kommunikationsverbindung in dem ersten Knoten empfangen wird, ein Broadcast-Paket ist und von welcher Quelle das Paket stammt, und wobei das Delegieren von Ressourcen an den zweiten Knoten über die Kommunikationsverbindung, um die Verkehrsverwaltungsregeln auszuführen, das Senden einer Quellenadresse einer Quelle enthält, von der Broadcast-Pakete stammen, die die delegierte Quellenadresse aufweisen.
  20. Verfahren nach Anspruch 18, wobei das Überwachen mit Verarbeitungsressourcen von den Paketen des ersten Knotens, die im Verkehr von dem Netzwerk gesendet werden und von diesem empfangen werden, das Bestimmen einschließt, ob ein über die Kommunikationsverbindung an den zweiten Knoten gesendetes Paket ein periodisches Paket ist und ob der zweite Knoten das periodische Paket bereits empfangen hat, und wobei das Delegieren von Ressourcen an den zweiten Knoten über die Kommunikationsverbindung, um die Verkehrsverwaltungsregeln auszuführen, das Senden eines Hinweises auf den Inhalt des periodischen Pakets enthält, wenn dieses nicht bereits zum zweiten Knoten gesendet worden ist, sodass der zweite Knoten das delegierte periodische Paket verschleiern kann.
  21. Verfahren nach Anspruch 18, wobei der Schritt des Delegierens das Bereitstellen eines Transportmechanismus einschließt, mittels dem der erste Knoten und der zweite Knoten über die Kommunikationsverbindung unabhängig von irgendwelchen konfigurierten Netzwerkadressen kommunizieren.
  22. Verfahren nach Anspruch 18, wobei das Verfahren das Bereitstellen von Multiprotokoll-Routingressourcen in dem ersten Knoten einschließt.
DE69534430T 1994-10-12 1995-10-12 System zur kommunikationsfernverwaltung mit intelligenter filterung Expired - Lifetime DE69534430T2 (de)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US321748 1994-10-12
US08/321,748 US5541911A (en) 1994-10-12 1994-10-12 Remote smart filtering communication management system
PCT/US1995/012793 WO1996012363A1 (en) 1994-10-12 1995-10-12 Remote smart filtering communication management system

Publications (2)

Publication Number Publication Date
DE69534430D1 DE69534430D1 (de) 2005-10-13
DE69534430T2 true DE69534430T2 (de) 2006-06-22

Family

ID=23251867

Family Applications (1)

Application Number Title Priority Date Filing Date
DE69534430T Expired - Lifetime DE69534430T2 (de) 1994-10-12 1995-10-12 System zur kommunikationsfernverwaltung mit intelligenter filterung

Country Status (8)

Country Link
US (1) US5541911A (de)
EP (1) EP0786179B1 (de)
JP (1) JP3522284B2 (de)
AT (1) ATE304255T1 (de)
AU (1) AU696657B2 (de)
CA (1) CA2202388C (de)
DE (1) DE69534430T2 (de)
WO (1) WO1996012363A1 (de)

Families Citing this family (133)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5193180A (en) * 1991-06-21 1993-03-09 Pure Software Inc. System for modifying relocatable object code files to monitor accesses to dynamically allocated memory
US7327688B2 (en) * 1994-01-21 2008-02-05 Alcatel Canada Inc. Digital communications system
GB9401092D0 (en) * 1994-01-21 1994-03-16 Newbridge Networks Corp A network management system
US5675741A (en) * 1994-10-25 1997-10-07 Cabletron Systems, Inc. Method and apparatus for determining a communications path between two nodes in an Internet Protocol (IP) network
US6460036B1 (en) 1994-11-29 2002-10-01 Pinpoint Incorporated System and method for providing customized electronic newspapers and target advertisements
US5758257A (en) 1994-11-29 1998-05-26 Herz; Frederick System and method for scheduling broadcast of and access to video programs and other data using customer profiles
DE69531410T2 (de) * 1994-12-09 2004-05-06 British Telecommunications P.L.C. Mehrrechnerumgebungen
CA2224689C (en) * 1995-06-02 2002-10-29 Rational Software Corporation Remote monitoring of computer programs
US6883034B1 (en) 1995-06-23 2005-04-19 Cisco Technology, Inc. Method of resolving conflicts in access control lists in router by comparing elements in the lists based on subsumption relations
US6393486B1 (en) 1995-06-23 2002-05-21 Cisco Technology, Inc. System and method using level three protocol information for network centric problem analysis and topology construction of actual or planned routed network
US6147996A (en) 1995-08-04 2000-11-14 Cisco Technology, Inc. Pipelined multiple issue packet switch
US6339794B2 (en) * 1995-12-08 2002-01-15 Microsoft Corporation Wire protocol for a media server system
US6865610B2 (en) 1995-12-08 2005-03-08 Microsoft Corporation Wire protocol for a media server system
US6058429A (en) * 1995-12-08 2000-05-02 Nortel Networks Corporation Method and apparatus for forwarding traffic between locality attached networks using level 3 addressing information
US5761424A (en) * 1995-12-29 1998-06-02 Symbios, Inc. Method and apparatus for programmable filtration and generation of information in packetized communication systems
US6091725A (en) 1995-12-29 2000-07-18 Cisco Systems, Inc. Method for traffic management, traffic prioritization, access control, and packet forwarding in a datagram computer network
US6035105A (en) 1996-01-02 2000-03-07 Cisco Technology, Inc. Multiple VLAN architecture system
US5781726A (en) * 1996-01-31 1998-07-14 3Com Corporation Management of polling traffic in connection oriented protocol sessions
US5826022A (en) * 1996-04-05 1998-10-20 Sun Microsystems, Inc. Method and apparatus for receiving electronic mail
US5884033A (en) * 1996-05-15 1999-03-16 Spyglass, Inc. Internet filtering system for filtering data transferred over the internet utilizing immediate and deferred filtering actions
US5828468A (en) * 1996-05-17 1998-10-27 Nko, Inc. Point of presence (POP) for digital facsimile network with spoofing capability to maintain fax session
US6243667B1 (en) 1996-05-28 2001-06-05 Cisco Systems, Inc. Network flow switching and flow data export
US6308148B1 (en) * 1996-05-28 2001-10-23 Cisco Technology, Inc. Network flow data export
US6212182B1 (en) 1996-06-27 2001-04-03 Cisco Technology, Inc. Combined unicast and multicast scheduling
US6434120B1 (en) 1998-08-25 2002-08-13 Cisco Technology, Inc. Autosensing LMI protocols in frame relay networks
US5857203A (en) * 1996-07-29 1999-01-05 International Business Machines Corporation Method and apparatus for dividing, mapping and storing large digital objects in a client/server library system
US5828833A (en) * 1996-08-15 1998-10-27 Electronic Data Systems Corporation Method and system for allowing remote procedure calls through a network firewall
US6230193B1 (en) 1996-10-31 2001-05-08 3Com Corporation Method and apparatus supporting network communications
US5835727A (en) * 1996-12-09 1998-11-10 Sun Microsystems, Inc. Method and apparatus for controlling access to services within a computer network
US5968125A (en) * 1997-01-21 1999-10-19 Net. Roi Process for optimizing the effectiveness of a hypertext element
US6732154B1 (en) * 1997-03-18 2004-05-04 Paratran Corporation Distribution limiter for network messaging
US6532491B1 (en) 1997-03-24 2003-03-11 Novell, Inc. Processes and apparatuses for managing network devices
US6237031B1 (en) * 1997-03-25 2001-05-22 Intel Corporation System for dynamically controlling a network proxy
US6094672A (en) * 1997-05-19 2000-07-25 Novell, Inc. Method and system for time synchronization management
US6122272A (en) 1997-05-23 2000-09-19 Cisco Technology, Inc. Call size feedback on PNNI operation
US6356530B1 (en) 1997-05-23 2002-03-12 Cisco Technology, Inc. Next hop selection in ATM networks
US6862284B1 (en) 1997-06-17 2005-03-01 Cisco Technology, Inc. Format for automatic generation of unique ATM addresses used for PNNI
US6078590A (en) 1997-07-14 2000-06-20 Cisco Technology, Inc. Hierarchical routing knowledge for multicast packet routing
US6205473B1 (en) 1997-10-03 2001-03-20 Helius Development Corporation Method and system for asymmetric satellite communications for local area networks
US6055364A (en) 1997-07-31 2000-04-25 Cisco Technology, Inc. Content-based filtering of multicast information
US6212183B1 (en) 1997-08-22 2001-04-03 Cisco Technology, Inc. Multiple parallel packet routing lookup
US6512766B2 (en) 1997-08-22 2003-01-28 Cisco Systems, Inc. Enhanced internet packet routing lookup
US6157641A (en) 1997-08-22 2000-12-05 Cisco Technology, Inc. Multiprotocol packet recognition and switching
US6052724A (en) * 1997-09-02 2000-04-18 Novell Inc Method and system for managing a directory service
US6021419A (en) * 1997-09-16 2000-02-01 International Business Machines Corporation System for filtering broadcast digital information in accordance with channel identifiers stored in preference list which can be dynamically updated via command through network
US6343072B1 (en) 1997-10-01 2002-01-29 Cisco Technology, Inc. Single-chip architecture for shared-memory router
US6111877A (en) 1997-12-31 2000-08-29 Cisco Technology, Inc. Load sharing across flows
CA2226063C (en) * 1997-12-31 2003-10-07 Northern Telecom Limited A method of provisioning nodes within a communications network
US6108350A (en) * 1998-03-09 2000-08-22 3Com Corporation Method and apparatus for detecting the protocol used by an end station and negotiating a protocol used by the endpoint
US6073167A (en) * 1998-03-18 2000-06-06 Paratran Corporation Distribution limiter for network messaging
US6338086B1 (en) * 1998-06-11 2002-01-08 Placeware, Inc. Collaborative object architecture
US6370121B1 (en) 1998-06-29 2002-04-09 Cisco Technology, Inc. Method and system for shortcut trunking of LAN bridges
US6377577B1 (en) 1998-06-30 2002-04-23 Cisco Technology, Inc. Access control list processing in hardware
US6470008B1 (en) * 1998-07-09 2002-10-22 Sprint Communications Company L.P. Internet routing system
US6182147B1 (en) 1998-07-31 2001-01-30 Cisco Technology, Inc. Multicast group routing using unidirectional links
US6308219B1 (en) 1998-07-31 2001-10-23 Cisco Technology, Inc. Routing table lookup implemented using M-trie having nodes duplicated in multiple memory banks
US6389506B1 (en) 1998-08-07 2002-05-14 Cisco Technology, Inc. Block mask ternary cam
US6771642B1 (en) 1999-01-08 2004-08-03 Cisco Technology, Inc. Method and apparatus for scheduling packets in a packet switch
US6574658B1 (en) * 1999-01-29 2003-06-03 Lucent Technologies Inc. System and method for secure classification of electronic mail
US6381570B2 (en) 1999-02-12 2002-04-30 Telogy Networks, Inc. Adaptive two-threshold method for discriminating noise from speech in a communication signal
US6757791B1 (en) 1999-03-30 2004-06-29 Cisco Technology, Inc. Method and apparatus for reordering packet data units in storage queues for reading and writing memory
US6760331B1 (en) 1999-03-31 2004-07-06 Cisco Technology, Inc. Multicast routing with nearest queue first allocation and dynamic and static vector quantization
US6603772B1 (en) 1999-03-31 2003-08-05 Cisco Technology, Inc. Multicast routing with multicast virtual output queues and shortest queue first allocation
US6298340B1 (en) 1999-05-14 2001-10-02 International Business Machines Corporation System and method and computer program for filtering using tree structure
US6654369B1 (en) 1999-05-28 2003-11-25 Intel Corporation Method for directing the route of a cell transmitting a network
US6496503B1 (en) * 1999-06-01 2002-12-17 Intel Corporation Device initialization and operation using directed routing
US6604146B1 (en) 1999-06-15 2003-08-05 Viasat, Inc. Efficient internet service implementation for mesh satellite networks using centralized router server for distribution of destination tables
FR2795580A1 (fr) * 1999-06-28 2000-12-29 Bull Sa Procede d'interrogation a distance d'agents snmp
US6751191B1 (en) 1999-06-29 2004-06-15 Cisco Technology, Inc. Load sharing and redundancy scheme
SE521516C2 (sv) * 1999-09-14 2003-11-11 Ericsson Telefon Ab L M Anordning och förfarande relaterande till routing ett nätverk
US6674743B1 (en) 1999-12-30 2004-01-06 3Com Corporation Method and apparatus for providing policy-based services for internal applications
US7058007B1 (en) 2000-01-18 2006-06-06 Cisco Technology, Inc. Method for a cable modem to rapidly switch to a backup CMTS
US6839829B1 (en) 2000-01-18 2005-01-04 Cisco Technology, Inc. Routing protocol based redundancy design for shared-access networks
US6606659B1 (en) 2000-01-28 2003-08-12 Websense, Inc. System and method for controlling access to internet sites
US7082467B2 (en) * 2000-02-10 2006-07-25 Hughes Network Systems Method and device for selective transport level spoofing based on information in transport level packet
US6973497B1 (en) * 2000-02-10 2005-12-06 Hughes Electronics Corporation Selective spoofer and method of performing selective spoofing
US7313608B1 (en) * 2000-06-21 2007-12-25 Nortel Networks Limited Method and apparatus for using documents written in a markup language to access and configure network elements
US7072979B1 (en) * 2000-06-28 2006-07-04 Cisco Technology, Inc. Wide area load balancing of web traffic
US6981056B1 (en) 2000-06-28 2005-12-27 Cisco Technology, Inc. Wide area load balancing of web traffic
EP1323014A2 (de) 2000-09-28 2003-07-02 Vigilos, Inc. Verfahren und prozess zum konfigurieren eines standorts für die überwachung
US8392552B2 (en) 2000-09-28 2013-03-05 Vig Acquisitions Ltd., L.L.C. System and method for providing configurable security monitoring utilizing an integrated information system
US7627665B2 (en) * 2000-09-28 2009-12-01 Barker Geoffrey T System and method for providing configurable security monitoring utilizing an integrated information system
EP1330812A1 (de) * 2000-09-28 2003-07-30 Vigilos, Inc. System und verfahren zur dynamischen wechselwirkung mit abgesetzten einrichtungen
US8185615B1 (en) * 2000-11-28 2012-05-22 Verizon Business Global Llc Message, control and reporting interface for a distributed network access system
US7657628B1 (en) * 2000-11-28 2010-02-02 Verizon Business Global Llc External processor for a distributed network access system
US8180870B1 (en) * 2000-11-28 2012-05-15 Verizon Business Global Llc Programmable access device for a distributed network access system
US7046680B1 (en) 2000-11-28 2006-05-16 Mci, Inc. Network access system including a programmable access device having distributed service control
US6910148B1 (en) 2000-12-07 2005-06-21 Nokia, Inc. Router and routing protocol redundancy
US7881208B1 (en) 2001-06-18 2011-02-01 Cisco Technology, Inc. Gateway load balancing protocol
EP1443409B1 (de) * 2001-10-30 2010-08-18 Sony Corporation Überwachungsverfahren für elektronische einrichtungen, elektronische einrichtung, computer und programm dafür
US7308001B2 (en) * 2001-11-16 2007-12-11 Computer Network Technology Corporation Fibre channel frame batching for IP transmission
US6947985B2 (en) * 2001-12-05 2005-09-20 Websense, Inc. Filtering techniques for managing access to internet sites or other software applications
US7194464B2 (en) 2001-12-07 2007-03-20 Websense, Inc. System and method for adapting an internet filter
US7240123B2 (en) * 2001-12-10 2007-07-03 Nortel Networks Limited Distributed routing core
US20030135556A1 (en) * 2001-12-14 2003-07-17 International Business Machines Corporation Selection of communication strategies for message brokers or publish/subscribe communications
US7480715B1 (en) 2002-01-25 2009-01-20 Vig Acquisitions Ltd., L.L.C. System and method for performing a predictive threat assessment based on risk factors
US7027450B2 (en) * 2002-02-19 2006-04-11 Computer Network Technology Corporation Frame batching and compression for IP transmission
US8811429B2 (en) * 2002-02-19 2014-08-19 Brocade Communications Systems, Inc. Batching and compression for IP transmission
US20030163343A1 (en) * 2002-02-27 2003-08-28 International Business Machines Corporation Method and system for dynamically modifying an electronic campaign based on network activity
US20030167335A1 (en) * 2002-03-04 2003-09-04 Vigilos, Inc. System and method for network-based communication
US20030206172A1 (en) * 2002-03-05 2003-11-06 Vigilos, Inc. System and method for the asynchronous collection and management of video data
TW550903B (en) * 2002-04-23 2003-09-01 Via Tech Inc Method for filtering packets and the associated devices
US7171467B2 (en) * 2002-06-13 2007-01-30 Engedi Technologies, Inc. Out-of-band remote management station
US7325140B2 (en) * 2003-06-13 2008-01-29 Engedi Technologies, Inc. Secure management access control for computers, embedded and card embodiment
US6823383B2 (en) * 2002-09-10 2004-11-23 Capital One Financial Corporation Stealth network
US7185015B2 (en) * 2003-03-14 2007-02-27 Websense, Inc. System and method of monitoring and controlling application files
US7529754B2 (en) 2003-03-14 2009-05-05 Websense, Inc. System and method of monitoring and controlling application files
US7450574B1 (en) * 2003-04-25 2008-11-11 Shoretel, Inc. IP telephony network using a configuration map for organizing sites in a tree-like hierarchy
US6881900B2 (en) * 2003-07-03 2005-04-19 Alan P. Halbert Ceiling box safety mounting bracket
US7593346B2 (en) 2003-07-31 2009-09-22 Cisco Technology, Inc. Distributing and balancing traffic flow in a virtual gateway
US20050108331A1 (en) * 2003-10-31 2005-05-19 Osterman Lawrence W. Presence tracking for datagram based protocols with search
US7516212B2 (en) * 2004-01-21 2009-04-07 Hewlett-Packard Development Company, L.P. Device status identification
GB2416879B (en) 2004-08-07 2007-04-04 Surfcontrol Plc Device resource access filtering system and method
GB2418037B (en) 2004-09-09 2007-02-28 Surfcontrol Plc System, method and apparatus for use in monitoring or controlling internet access
GB2418108B (en) * 2004-09-09 2007-06-27 Surfcontrol Plc System, method and apparatus for use in monitoring or controlling internet access
US7944469B2 (en) * 2005-02-14 2011-05-17 Vigilos, Llc System and method for using self-learning rules to enable adaptive security monitoring
US20060190960A1 (en) * 2005-02-14 2006-08-24 Barker Geoffrey T System and method for incorporating video analytics in a monitoring network
US20070211701A1 (en) * 2006-03-07 2007-09-13 Fujitsu Limited Communicating configuration information for an end system
US8615800B2 (en) 2006-07-10 2013-12-24 Websense, Inc. System and method for analyzing web content
US8020206B2 (en) 2006-07-10 2011-09-13 Websense, Inc. System and method of analyzing web content
US9654495B2 (en) 2006-12-01 2017-05-16 Websense, Llc System and method of analyzing web addresses
GB2445764A (en) 2007-01-22 2008-07-23 Surfcontrol Plc Resource access filtering system and database structure for use therewith
US8015174B2 (en) 2007-02-28 2011-09-06 Websense, Inc. System and method of controlling access to the internet
GB0709527D0 (en) 2007-05-18 2007-06-27 Surfcontrol Plc Electronic messaging system, message processing apparatus and message processing method
US8307114B2 (en) * 2007-05-22 2012-11-06 International Business Machines Corporation High availability message transmission
US7752300B2 (en) * 2007-11-19 2010-07-06 International Business Machines Corporation Automatically determining management information base modules for a device
AU2009267107A1 (en) 2008-06-30 2010-01-07 Websense, Inc. System and method for dynamic and real-time categorization of webpages
EP2443580A1 (de) 2009-05-26 2012-04-25 Websense, Inc. Systeme und verfahren für den effizienten nachweis von fingerabdruckdaten und -informationen
KR101669287B1 (ko) * 2009-09-01 2016-11-09 삼성전자주식회사 제 3의 원격 유저 인터페이스 장치를 통한 원격 유저 인터페이스 장치의 제어 방법 및 장치
US20110145837A1 (en) * 2009-12-14 2011-06-16 Bower Kenneth S Filtering Broadcast Recipients In A Multiprocessing Environment
CN102823194A (zh) * 2010-03-31 2012-12-12 瑞典爱立信有限公司 操作、监管和管理代理和用于处理操作、监管和管理消息的方法
US9117054B2 (en) 2012-12-21 2015-08-25 Websense, Inc. Method and aparatus for presence based resource management
CN104468854B (zh) 2013-09-13 2017-10-27 新华三技术有限公司 一种纵向融合架构vcf的构建方法及设备

Family Cites Families (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE69130853T2 (de) * 1990-11-21 1999-07-22 At & T Corp Bandbreitenverwaltung und Überlastabwehr für den Zugang zu Breitband-ISDN-Netzen
US5434863A (en) * 1991-08-30 1995-07-18 Hitachi, Ltd. Internetworking apparatus for connecting plural network systems and communication network system composed of plural network systems mutually connected
US5321694A (en) * 1991-09-20 1994-06-14 Extension Technology Corporation Method and apparatus for reducing the transmission of repetitive braodcast datagrams over communication links
US5280481A (en) * 1991-09-20 1994-01-18 Extension Technology Corp. Local area network transmission emulator
DE69330981T2 (de) * 1992-04-20 2002-06-27 3Com Corp Vorrichtung zur Netzmittelerweiterung auf entfernte Netzwerke
US5313465A (en) * 1992-05-13 1994-05-17 Digital Equipment Corporation Method of merging networks across a common backbone network

Also Published As

Publication number Publication date
AU3947895A (en) 1996-05-06
JP2002509658A (ja) 2002-03-26
US5541911A (en) 1996-07-30
EP0786179B1 (de) 2005-09-07
AU696657B2 (en) 1998-09-17
CA2202388C (en) 2001-05-01
ATE304255T1 (de) 2005-09-15
DE69534430D1 (de) 2005-10-13
EP0786179A4 (de) 2001-01-24
JP3522284B2 (ja) 2004-04-26
CA2202388A1 (en) 1996-04-25
WO1996012363A1 (en) 1996-04-25
EP0786179A1 (de) 1997-07-30

Similar Documents

Publication Publication Date Title
DE69534430T2 (de) System zur kommunikationsfernverwaltung mit intelligenter filterung
DE69836271T2 (de) Mehrstufiges firewall-system
DE60009819T2 (de) Netzwerkgerätskonfigurationsverfahren und Vorrichtung
DE60109709T2 (de) Datenverwaltungsrahmenwerk für Verfahrensverwaltung
DE69829476T2 (de) Netzwerkverwaltungsarchitektur
DE60031274T2 (de) Mehrfachanschlussverfahren und -gerät für vituelle ports
DE60216221T2 (de) Verfahren und Vorrichtung zur automatischen Erkennung von logischen Verbindungen zwischen Netzvorrichtungen
DE69433860T2 (de) System zur umgekehrten adressenauflösung für entfernte netzwerkvorrichtung
DE60108927T2 (de) Komputersysteme, insbesondere virtuelle private Netzwerken
DE60035830T2 (de) Netzwerkgeräteverwaltungsvorrichtung und - verfahren
DE60308700T2 (de) Dynamische fernkonfiguration eines webservers zur bereitstellung von kapazität auf anfrage
DE69832946T2 (de) Verteiltes System und Verfahren zur Steuerung des Zugriffs auf Netzmittel und Ereignismeldungen
DE69927929T2 (de) Verfahren und System zur Netzwerkverwaltung
DE69938160T2 (de) Verfahren und Vorrichtung zur Verwaltung von Netzwerken und Anlagen
DE69628718T2 (de) Netzwerk - Topologie-Verwaltungssystem
DE60103163T2 (de) Gateway zum zugriff auf netzressourcen
DE60207368T2 (de) Verfahren und Vorrichtung zur automatischen Erkennung von Netzelementen mit Datenübertragungsfähigkeiten
DE602005004334T2 (de) Nms zur Verarbeitung von Multi-Server Ereignissen
DE69737150T2 (de) System zur parameteranalyse und verkehrsüberwachung in atm-netzen
DE112012003778T5 (de) Computernetzwerk-Management-Tools
DE60038356T2 (de) Steuerungs- und Verteilungsprotokoll für einen beweglichen Routerrahmen
EP1668822B1 (de) Verfahren zur synchronisierung von alarmen in einem managementsystem eines kommunikationsnetzes
DE60217520T2 (de) Router discovery protokoll auf einem mobilen internetprotokoll basierendem netz
EP1655974A1 (de) Verfahren und Vorrichtungen zum Informationsabgleich zwischen Manager und Agent in eiem Managementnetz
DE60304307T2 (de) Methode und Apparat zur Bereitstellung von Routing Protokoll Redundanz in einem Netzelement

Legal Events

Date Code Title Description
8364 No opposition during term of opposition
R082 Change of representative

Ref document number: 786179

Country of ref document: EP

Representative=s name: BOEHMERT & BOEHMERT, 80336 MUENCHEN, DE