DE60034320T2 - Verfahren zur vermeidung von nichtsequentiellen rahmen in einer netzwerkvermittlungsstelle - Google Patents

Verfahren zur vermeidung von nichtsequentiellen rahmen in einer netzwerkvermittlungsstelle Download PDF

Info

Publication number
DE60034320T2
DE60034320T2 DE60034320T DE60034320T DE60034320T2 DE 60034320 T2 DE60034320 T2 DE 60034320T2 DE 60034320 T DE60034320 T DE 60034320T DE 60034320 T DE60034320 T DE 60034320T DE 60034320 T2 DE60034320 T2 DE 60034320T2
Authority
DE
Germany
Prior art keywords
bit
port
packet
address
bits
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
DE60034320T
Other languages
English (en)
Other versions
DE60034320D1 (de
Inventor
Shiri Los Altos Kadambi
Shekhar San Jose Ambe
Mohan Sunnyvale Kalkunte
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.)
Broadcom Corp
Original Assignee
Broadcom 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
Priority claimed from US09/343,409 external-priority patent/US6335932B2/en
Application filed by Broadcom Corp filed Critical Broadcom Corp
Publication of DE60034320D1 publication Critical patent/DE60034320D1/de
Application granted granted Critical
Publication of DE60034320T2 publication Critical patent/DE60034320T2/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
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/24—Traffic characterised by specific attributes, e.g. priority or QoS
    • H04L47/2408—Traffic characterised by specific attributes, e.g. priority or QoS for supporting different services, e.g. a differentiated services [DiffServ] type of service
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/46—Interconnection of networks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/46—Interconnection of networks
    • H04L12/4604—LAN interconnection over a backbone network, e.g. Internet, Frame Relay
    • H04L12/462—LAN interconnection over a bridge based backbone
    • H04L12/4625—Single bridge functionality, e.g. connection of two networks over a single bridge
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/54—Store-and-forward switching systems 
    • H04L12/56—Packet switching systems
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/54—Store-and-forward switching systems 
    • H04L12/56—Packet switching systems
    • H04L12/5601—Transfer mode dependent, e.g. ATM
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/54—Store-and-forward switching systems 
    • H04L12/56—Packet switching systems
    • H04L12/5601—Transfer mode dependent, e.g. ATM
    • H04L12/5602—Bandwidth control in ATM Networks, e.g. leaky bucket
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/24—Multipath
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/24—Multipath
    • H04L45/245—Link aggregation, e.g. trunking
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/54—Organization of routing tables
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/74—Address processing for routing
    • H04L45/742—Route cache; Operation thereof
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/12—Avoiding congestion; Recovering from congestion
    • H04L47/125—Avoiding congestion; Recovering from congestion by balancing the load, e.g. traffic engineering
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/24—Traffic characterised by specific attributes, e.g. priority or QoS
    • H04L47/2441—Traffic characterised by specific attributes, e.g. priority or QoS relying on flow classification, e.g. using integrated services [IntServ]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/24—Traffic characterised by specific attributes, e.g. priority or QoS
    • H04L47/2458—Modification of priorities while in transit
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/50—Queue scheduling
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/50—Queue scheduling
    • H04L47/62—Queue scheduling characterised by scheduling criteria
    • H04L47/6215—Individual queue per QOS, rate or priority
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/50—Queue scheduling
    • H04L47/62—Queue scheduling characterised by scheduling criteria
    • H04L47/622—Queue service order
    • H04L47/6225—Fixed service order, e.g. Round Robin
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/50—Queue scheduling
    • H04L47/62—Queue scheduling characterised by scheduling criteria
    • H04L47/625—Queue scheduling characterised by scheduling criteria for service slots or service orders
    • H04L47/627—Queue scheduling characterised by scheduling criteria for service slots or service orders policing
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L49/00—Packet switching elements
    • H04L49/30—Peripheral units, e.g. input or output ports
    • H04L49/3081—ATM peripheral units, e.g. policing, insertion or extraction
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L49/00—Packet switching elements
    • H04L49/35—Switches specially adapted for specific applications
    • H04L49/351—Switches specially adapted for specific applications for local area network [LAN], e.g. Ethernet switches
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L49/00—Packet switching elements
    • H04L49/90—Buffering arrangements
    • H04L49/901—Buffering arrangements using storage descriptor, e.g. read or write pointers
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L49/00—Packet switching elements
    • H04L49/90—Buffering arrangements
    • H04L49/9047—Buffering arrangements including multiple buffers, e.g. buffer pools
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L49/00—Packet switching elements
    • H04L49/90—Buffering arrangements
    • H04L49/9063—Intermediate storage in different physical parts of a node or terminal
    • H04L49/9068—Intermediate storage in different physical parts of a node or terminal in the network interface card
    • H04L49/9073—Early interruption upon arrival of a fraction of a packet
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
    • H04L69/161—Implementation details of TCP/IP or UDP/IP stack architecture; Specification of modified or new header fields
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/42—Loop networks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L49/00—Packet switching elements
    • H04L49/20—Support for services
    • H04L49/201—Multicast operation; Broadcast operation
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L49/00—Packet switching elements
    • H04L49/20—Support for services
    • H04L49/205—Quality of Service based
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L49/00—Packet switching elements
    • H04L49/25—Routing or path finding in a switch fabric
    • H04L49/253—Routing or path finding in a switch fabric using establishment or release of connections between ports
    • H04L49/254—Centralised controller, i.e. arbitration or scheduling
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L49/00—Packet switching elements
    • H04L49/30—Peripheral units, e.g. input or output ports
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L49/00—Packet switching elements
    • H04L49/35—Switches specially adapted for specific applications
    • H04L49/354—Switches specially adapted for specific applications for supporting virtual local area networks [VLAN]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L49/00—Packet switching elements
    • H04L49/60—Software-defined switches
    • H04L49/602—Multilayer or multiprotocol switching, e.g. IP switching
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/14—Multichannel or multilink protocols
    • Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
    • Y02D—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
    • Y02D30/00—Reducing energy consumption in communication networks
    • Y02D30/50—Reducing energy consumption in communication networks in wire-line communication networks, e.g. low power modes or reduced link rate

Description

  • HINTERGRUND DER ERFINDUNG:
  • Gebiet der Erfindung:
  • Die vorliegende Erfindung betrifft Verfahren zum Verhindern, dass Rahmen (Frames) in einem Netzwerk-Switch aus der Ordnung geraten.
  • Beschreibung des Standes der Technik:
  • Die vorliegende Erfindung treibt die Netzwerkvermittlungstechnologie in einem Switch (Vermittlungsstelle) voran, der zur Verwendung in Umgebungen wie Ethernet, Fast Ethernet, Gigabit Ethernet und anderen Arten von Netzwerkumgebungen geeignet ist, die eine Hochleistungsvermittlung von Datenpaketen oder Datenzellen erfordern. Ein Switch, der die offenbarten Elemente nutzt, und ein System, das die offenbarten Schritte durchführt, stellen Kosten- und Betriebsvorteile gegenüber dem Stand der Technik bereit.
  • Die EP A 0 859 492 beschreibt ein Fair Queuing System mit adaptiver Bandbreitenumverteilung, wobei das System eine Vielzahl von Warteschlangen pro Verbindung, einen gewichteten Fair Queuing Scheduler, eine Erfassungsvorrichtung zum Erfassen eines Vorhandenseins oder eines Nichtvorhandenseins von Paketen in Warteschlangen, das die Verfügbarkeit von überschüssiger Bandbreite anzeigt, und einen zustandsabhängigen Scheduler für die Umverteilung überschüssiger Bandbreite beim Erfassen von Warteschlangen, in denen keine Pakete vorhanden sind, umfasst.
  • Die WO A 98 25381 betrifft einen Netzwerkadapter-Treiber mit einem zielbasierten Anordnungsschema, bei dem mehrere Pakete von Daten geordnet werden, bevor sie übertragen werden, um eine bessere Ausnutzung von verteilten Netzwerkressourcen zu erzielen.
  • Gemäß der Erfindung sind Verfahren zum Verhindern, dass Rahmen in einem Netzwerk-Switch aus der Ordnung geraten, bereitgestellt, wie sie durch den Gegenstand der unabhängigen Ansprüche 1 und 3 dargelegt sind.
  • Weitere vorteilhafte Merkmale sind in den Unteransprüchen definiert.
  • KURZE BESCHREIBUNG DER ZEICHNUNGEN:
  • Die Aufgaben und Merkmale der Erfindung werden unter Bezugnahme auf die nachfolgende Beschreibung und die angehängten Zeichnungen besser verständlich, wobei:
  • 1 ein allgemeines Blockdiagramm von Elementen eines Netzwerk-Switch ist, wie er hier besprochen wird;
  • 2 ein ausführlicheres Blockdiagramm des Netzwerk-Switch ist;
  • 3 den Datenfluss in dem CPS-Kanal des Netzwerk-Switch veranschaulicht;
  • 4A eine Demand-Priority-Round-Robin-Arbitrierung für den Zugriff auf den C-Kanal des Netzwerk-Switch veranschaulicht;
  • 4B den Zugriff auf den C-Kanal auf der Grundlage der Round-Robin-Arbitrierung veranschaulicht, die in 4A veranschaulicht worden ist;
  • 5 P-Kanal-Nachrichtentypen veranschaulicht;
  • 6 ein Nachrichtenformat für S-Kanal-Nachrichtentypen veranschaulicht;
  • 7 eine Veranschaulichung des OSI-7-Schichten-Referenzmodells ist;
  • 8 einen Funktionsplan eines EPIC-Moduls veranschaulicht;
  • 9 das Schneiden eines Datenpakets bei dem Eintritt (Ingress) zu einem EPIC-Modul veranschaulicht;
  • 10 eine Detailansicht von Elementen der MMU ist;
  • 11 das CBM-Zellenformat veranschaulicht;
  • 12 ein internes/externes Speicherzugangs-Flussdiagramm veranschaulicht;
  • 13 ein Blockdiagramm eines Austrittsmanagers (Egress Manager) 76 veranschaulicht, wie er in 10 veranschaulicht ist;
  • 14 mehr Einzelheiten eines EPIC-Moduls veranschaulicht;
  • 15 ein Blockdiagramm eines Schnellfilterungsprozessors (FFP; fast filtering processor) ist;
  • 16 ein Blockdiagramm der Elemente des CMIC 40 ist;
  • 17 eine Reihe von Schritten veranschaulicht, die verwendet werden, um einen FFP zu programmieren;
  • 18 ein Flussdiagramm ist, das den Alterungsprozess für ARL-(L2)- und L3-Tabellen veranschaulicht;
  • 19 die Kommunikation unter Verwendung eines Leitungsbündels (Trunk Group) gemäß der vorliegenden Erfindung veranschaulicht;
  • 20 eine Tabelle ist, die zahlreiche Felder für verschiedene Pakettypen auflistet;
  • die 21A und 21B jeweils ein Filtermaskenformat und ein Feldmaskenformat veranschaulichen;
  • 22 ein Flussdiagramm ist, das die Bildung und Anwendung einer Filtermaske veranschaulicht;
  • 23 ein Beispiel eines Format für eine Regeltabelle (rules table) veranschaulicht;
  • 24 ein Format für eine IP-Multicast-Tabelle veranschaulicht;
  • 25 ein Flussdiagramm ist, das die Handhabung eines IP-Multicast-Pakets veranschaulicht;
  • 26 ein Ausführungsbeispiel von gestapelten SOC Switches 10 veranschaulicht;
  • die 27A und 27B alternative Ausführungsbeispiele von gestapelten SOC-10-Konfigurationen veranschaulichen;
  • 28 eine ausführliche Ansicht der Funktionsmodule des IPIC 90 ist;
  • 29 die Pakethandhabung für Pakete veranschaulicht, die bei der Hochleistungsschnittstelle des IPIC 90 hereinkommen;
  • 30 eine Diffserv-zu-COS-Abbildungstabelle ist;
  • 31 die Konfiguration der Offsets veranschaulicht;
  • 32 ein primäres Flussdiagramm für die Filterungs-/Zähllogik ist;
  • 33 ein Flussdiagramm der Logik der teilweisen Übereinstimmung ist;
  • 34 ein Flussdiagramm der In-Profil-Aktions-Logik ist;
  • 35 ein Flussdiagramm der Aktionslogik für die teilweise Übereinstimmung für die Bits 3-6 ist;
  • 36 ein Flussdiagramm der Aktionslogik für die teilweise Übereinstimmung für die Bits 1, 0 und 10 ist;
  • 37 ein Flussdiagramm der In-Profil-Aktions-Logik für die Bits 2, 8 und 9 ist;
  • 38 eine erste Konfiguration einer Adresstabelle und einer Suchmaschine veranschaulicht;
  • 39 eine zweite Konfiguration von zwei Adresstabellen und zwei Suchmaschinen veranschaulicht;
  • 40a ein erstes Beispiel von Adresseinträgen veranschaulicht, die in einer einzigen Adresstabelle gespeichert sind;
  • 40b ein zweites Beispiel von Adresseinträgen veranschaulicht, die in zwei separaten sortierten Adresstabellen gespeichert sind;
  • 41a ein drittes Beispiel von Adresseinträgen veranschaulicht, die in einer einzigen Adresstabelle gespeichert sind;
  • 41b ein viertes Beispiel von Adresseinträgen veranschaulicht, die in zwei separaten sortierten Adresstabellen gespeichert sind;
  • 42 ein Flussdiagramm der In-Profil-Aktions-Logik für die Bits 11-13 ist;
  • 43 ein Flussdiagramm der gespiegelten Port-/End-FFP-Aktionen ist;
  • 44 ein Flussdiagramm der Außer-Profil-Aktions-Logik ist;
  • 45 ein Flussdiagramm des Datenflusses eines ankommenden Pakets ist;
  • 46 ein Flussdiagramm der Logik der differenzierten Dienste ist;
  • 47 ein Flussdiagramm ist, das den Schritt 46-4 erweitert;
  • 48 ein Verfahren zum Verhindern, dass Rahmen aus der Ordnung geraten, veranschaulicht;
  • 49 eine Fortsetzung des Verfahrens zum Verhindern, dass Rahmen aus der Ordnung geraten, veranschaulicht;
  • 50 eine Gigabit-/Client-/Server-Konfiguration veranschaulicht;
  • 51 Trunk Warteschlangen in einer Trunk Group veranschaulicht;
  • 52 ein Flussdiagramm der differentiellen Flusshandhabungslogik ist;
  • 53 die Austrittsportlogik veranschaulicht;
  • 54 ein Blockdiagramm einer Stapelkonfiguration ist;
  • 55 ein Flussdiagramm der Logik ist, die das Bedienen von COS-Warteschlangen als eine Funktion des Austritts-Warteschlangenstatus unterstützt; und
  • 56 ein veranschaulichendes Beispiel eines Verfahrens zum Verhindern, dass Rahmen aus der Ordnung geraten, ist.
  • AUSFÜHRLICHE BESCHREIBUNG DER BEVORZUGTEN AUSFÜHRUNGSBEISPIELE:
  • Da sich die Computerleistung in den letzten Jahren immer mehr gesteigert hat und weiter steigert, sind auch die Anforderungen an Computernetzwerke beträchtlich gestiegen; schnellere Computerprozessoren und höhere Speicherfähigkeiten erfordern Netzwerke mit hohen Bandbreitenfähigkeiten, um einen Hochgeschwindigkeitstransfer von beträchtlichen Mengen an Daten zu ermöglichen. Die allgemein bekannte Ethernet-Technologie, die auf zahlreichen IEEE Ethernet Standards beruht, ist ein Beispiel für eine Computervernetzangstechnologie, die modifiziert und verbessert werden konnte und kann, um eine lebensfähige Datenverarbeitungstechnologie zu bleiben. Eine vollständigere Diskussion von Vernetzungssystemen kann zum Beispiel in dem Dokument SWITCHED AND FAST Ethernet von Breyer und Riley (Ziff-Davis, 1996) und in zahlreichen IEEE-Veröffentlichungen gefunden werden, die sich auf die IEEE 802 Standards beziehen. Auf der Grundlage des Open Systems Interconnect (OSI) 7-Schichten-Referenzmodells sind die Netzwerkfähigkeiten durch die Entwicklung von Zwischenverstärkern (repeaters), Brücken (bridges) und Routern und neuerdings auch "Switches" ("Vermittlungsstellen") gewachsen, die mit verschiedenen Arten von Kommunikationsmedien arbeiten. Grobdraht (thickwire), Dünndraht (thinwire), verdrilltes Leitungspaar und Glasfasern sind Beispiele für die Medien, die für Computernetzwerke verwendet worden sind und werden. Switches bzw. Vermittlungsstellen sind, wenn sie die Computervernetzung und das Ethernet betreffen, Vorrichtungen auf Hardwarebasis, die den Fluss von Datenpaketen oder Zellen auf der Grundlage von Zieladressinformationen steuern, die in jedem Paket zur Verfügung stehen. Eine richtig ausgelegte und implementierte Vermittlungsstelle sollte in der Lage sein, ein Paket zu empfangen und das Paket an einen geeigneten Ausgangsport mit einer Geschwindigkeit zu vermitteln, die als Leitungsgeschwindigkeit bezeichnet wird, welches die maximale Geschwindigkeit ist, zu der das spezielle Netzwerk in der Lage ist. Die Basis-Ethernet-Leitungsgeschwindigkeit beträgt bis zu 10 Megabit pro Sekunde, und beim Fast Ethernet beträgt diese bis zu 100 Megabit pro Sekunde. Ein Gigabit-Ethernet ist in der Lage, Daten über ein Netzwerk mit einer Geschwindigkeit von bis zu 1.000 Megabit pro Sekunde zu übertragen. Da sich die Geschwindigkeiten erhöht haben, sind die Konstruktionsbeschränkungen und Konstruktionsanforderungen im Hinblick auf die nachfolgenden zugehörigen Konstruktions- und Protokoll-Vorschriften und im Hinblick darauf, eine kostengünstige, kommerziell lebensfähige Lösung bereitzustellen, immer komplexer geworden. So benötigt eine Hochgeschwindigkeitsvermittlung zum Beispiel einen Hochgeschwindigkeitsspeicher, um eine geeignete Pufferung der Paketdaten bereitstellen zu kön nen; ein herkömmliches Dynamic Random Access Memory (DRAM) ist relativ langsam und benötigt einen hardwaregesteuerten Refresh. Die Geschwindigkeit von DRAMs als Pufferspeicher in der Netzwerkvermittlung führt daher dazu, dass wertvolle Zeit verloren geht, und es wird beinahe unmöglich, den Switch oder das Netzwerk bei Leitungsgeschwindigkeit zu betreiben. Außerdem sollte die Einbeziehung einer externen CPU vermieden werden, da die Einbeziehung einer CPU es auch beinahe unmöglich macht, den Switch bei Leitungsgeschwindigkeit zu betreiben. Des Weiteren ist, da Netzwerk-Switches im Hinblick darauf, dass Regeltabellen und eine Speichersteuerung benötigt werden, immer komplizierter geworden sind, eine komplexe Mehr-Chip-Lösung notwendig, die Logikschaltungen benötigt, die manchmal als Verbindungsschaltkreisschaltungen (glue logic circuitry) bezeichnet werden, um zu ermöglichen, dass die verschiedenen Chips miteinander kommunizieren können. Des Weiteren sind Kosten-/Nutzen-Kompromisse im Hinblick auf teuere, aber schnelle SRAMs gegenüber kostengünstigen, aber langsamen DRAMs notwendig. Des Weiteren benötigen DRAMs aufgrund ihrer dynamischen Natur das Auffrischen der Speicherinhalte, um Verluste daraus zu vermeiden. SRAMs leiden nicht an der Refresh-Anforderung und weisen im Vergleich zu DRAMs einen reduzierten Betriebs-Overhead auf, wie etwa die Eliminierung von Seiten-Fehltreffern, etc.. Obwohl DRAMs eine ausreichende Geschwindigkeit aufweisen, wenn sie auf Stellen auf der gleichen Seite zugreifen, wird die Geschwindigkeit herabgesetzt, wenn auf andere Seiten zugegriffen werden muss.
  • Unter Bezugnahme auf das vorher diskutierte OSI-7-Schichten-Referenzmodell, das in 7 veranschaulicht ist, weisen die höheren Schichten typischerweise mehr Informationen auf. Verschiedene Arten von Produkten stehen zur Durchführung von vermittlungsbezogenen Funktionen auf verschiedenen Schichten des OSI-Modells zur Verfügung. Verteiler (Hubs) oder Repeaters arbeiten bei Schicht 1 und kopieren und "rundsenden" im Wesentlichen ankommende Daten zu einer Vielzahl von Speichen des Verteilers. Vermittlungsbezogene Vorrichtungen der Schicht 2 werden typischerweise als Multiport-Bridges bezeichnet und sind in der Lage, zwei separate Netzwerke zu überbrücken. Brücken können eine Tabelle von Abwicklungsregeln auf der Grundlage dessen errichten, welche MAC-(Medienzugangskontrolleinrichtungs-)Adressen an welchen Ports der Brücke existieren, und können Pakete, die für eine Adresse bestimmt sind, die sich auf einer gegenüberliegenden Seite der Brücke befindet, übermitteln. Brücken verwenden typischerweise das, was als der "Spannbaum"-Algorithmus bekannt ist, um potentielle Datenschleifen zu eliminie ren; eine Datenschleife ist eine Situation, in der ein Paket in einem Netzwerk auf der Suche nach einer bestimmten Adresse endlos Runden dreht. Der Spannbaum-Algorithmus definiert ein Protokoll zur Verhinderung von Datenschleifen. Schicht-3-Switches, die manchmal auch als Router bezeichnet werden, können Pakete auf der Basis der Zielnetzwerkadresse weiterleiten. Schicht-3-Switches sind in der Lage, Adressen zu lernen und Tabellen davon zu verwalten, die den Port-Mappings entsprechen. Die Verarbeitungsgeschwindigkeit für Schicht-3-Switches kann verbessert werden, indem eine spezialisierte Hochleistungs-Hardware verwendet wird und die Host-CPU ausgeschaltet bzw. gesperrt (offloading) wird, so dass Befehlsentscheidungen nicht das Weiterleiten von Paketen verzögern.
  • 1 veranschaulicht eine Konfiguration, bei der ein Switch-on-Chip (SOC) 10 gemäß der vorliegenden Erfindung funktionell mit externen Vorrichtungen 11, einem externen Speicher 12, Fast Ethernet Ports 13 und Gigabit Ethernet Ports 15 verbunden ist. Für die Zwecke dieses Ausführungsbeispiels werden Fast Ethernet Ports 13 als Ethernet Ports mit niedriger Geschwindigkeit betrachtet, da sie in der Lage sind, mit Geschwindigkeiten in dem Bereich von 10 Mbps bis 100 Mbps zu arbeiten, während die Gigabit Ethernet Ports 15, die Ethernet Ports hoher Geschwindigkeit sind, in der Lage sind, bei 1000 Mbps zu arbeiten. Die externen Vorrichtungen 11 können andere Vermittlungsvorrichtungen zur Erweiterung von Vermittlungsfähigkeiten umfassen oder andere Vorrichtungen umfassen, die eventuell von einer speziellen Anwendung benötigt werden. Der externe Speicher 12 ist ein zusätzlicher Off-Chip-Speicher, der zusätzlich zu dem internen Speicher vorgesehen ist, der sich auf dem SOC 10 befindet, wie unten noch besprochen werden wird. Die CPU 52 kann je nach Notwendigkeit verwendet werden, um den SOC 10 mit Regeln zu programmieren, die dafür geeignet sind, die Paketverarbeitung zu steuern. Aber wenn der SOC 10 einmal in geeigneter Weise programmiert oder konfiguriert worden ist, arbeitet der SOC 10 so weit wie möglich in einer freilaufenden Art und Weise, ohne mit der CPU 52 zu kommunizieren. Da die CPU 52 nicht jeden Aspekt des Betriebs des SOC 10 steuert, sind die Leistungsanforderungen bezüglich der CPU 52, zumindest im Hinblick auf den SOC 10, ziemlich gering. Deshalb kann im Vergleich zu bekannten Netzwerk-Switches eine weniger leistungsstarke und daher kostengünstigere CPU 52 verwendet werden. Wie ebenfalls unten diskutiert werden wird, verwendet der SOC 10 einen externen Speicher 12 in einer effizienten Art und Weise, so dass die Kosten- und Leistungsanforderungen des Speichers 12 reduziert werden können. Der interne Speicher auf dem SOC 10 ist, wie unten besprochen werden wird, ebenfalls so konfiguriert, dass der Vermittlungsdurchsatz maximiert und die Kosten minimiert werden.
  • Es sollte angemerkt werden, dass jede Anzahl von Fast Ethernet Ports 13 und Gigabit Ethernet Ports 15 bereitgestellt werden kann. In einem Ausführungsbeispiel kann ein Maximum von 24 Fast Ethernet Ports 13 und 2 Gigabit Ethernet Ports 15 bereitgestellt werden. In ähnlicher Weise können zusätzliche Verbindungen zu weiteren externen Vorrichtungen 11, einem externen Speicher 12 und CPUs 52 in dem Maße bereitgestellt werden, wie dies notwendig ist.
  • 1 veranschaulicht auch, dass der SOC 10 verschiedene interne modulare Komponenten umfasst, wie etwa wenigstens einen Ethernet Port Schnittstellen-Controller (EPIC) 20, wobei eine Vielzahl davon als 20a, 20b, ... 20x bezeichnet wird, eine Vielzahl von Gigabit Port Schnittstellen-Controllern (GPIC) 30, die hier als 30a, 30b, ... 30x bezeichnet werden, einen Internet Port Schnittstellen-Controller (IPIC) 90, einen gemeinsamen Pufferspeicherpool (CBP; common buffer pool) 50, eine Speicherverwaltungseinheit (MMU) 70, und einen CPU-Verwaltungs-Schnittstellen-Controller (CMIC) 40. Der CPS-Kanal 80 läuft durch den SOC 10 und ermöglicht die Kommunikation zwischen den modularen Elementen des SOC 10.
  • 2 veranschaulicht ein ausführlicheres Blockdiagramm der Funktionselemente des SOC 10. Wie aus 2 ersichtlich wird und wie oben angemerkt worden ist, umfasst der SOC 10 eine Vielzahl von modularen Systemen auf dem Chip, wobei jedes modulare System, obwohl es sich auf dem gleichen Chip befindet, funktionell von den anderen modularen Systemen getrennt ist. Deshalb kann jedes Modul effizient parallel mit anderen Modulen arbeiten, und diese Konfiguration ermöglicht einen beträchtlichen Betrag an Freiheit bei der Aktualisierung und beim Reengineering des SOC 10.
  • Der SOC 10 umfasst eine Vielzahl von Ethernet Port Schnittstellen-Controllern 20a, 20b, 20c, etc., eine Vielzahl von Gigabit Port Schnittstellen-Controllern 30a, 30b, etc., einen CPU-Verwaltungs-Schnittstellen-Controller 40, einen gemeinsamen Pufferspeicherpool 50, eine Speicherverwaltungseinheit 70, die einen gemeinsamen Pufferspeichermanager (CBM) 71 umfasst, und eine systemweite Busstruktur, die als CPS-Kanal 80 bezeichnet wird. Die MMU 70 kommuniziert mit dem externen Speicher 12, der einen externen globalen Pufferspeicherpool (GBP; global buffer memory pool) 60 umfasst. Der CPS-Kanal 80 umfasst einen C-Kanal 81, einen P-Kanal 82 und einen S-Kanal 83. Der CPS-Kanal wird auch als der Zellprotokoll-Seitenband-Kanal (cell protocol sideband channel) bezeichnet und ist ein 17 Gbps Kanal, der die verschiedenen Module miteinander 'verklebt' bzw. verbindet. Wie ebenfalls in 2 veranschaulicht ist, ist auch ein Internet Port Schnittstellen-Controller (IPIC) 90, der eine Vielzahl von Tabellen 91 aufweist, und ein Netzwerk-Pufferspeicher-Pool (NBP; network buffer pool) 92 darauf enthalten. Ebenfalls in dem IPIC 90 enthalten und an späterer Stelle diskutiert sind eine Vielzahl von Komponenten, die assoziiert sind, um den IPIC 90 in die Lage zu versetzen, mit anderen Switches oder mit anderen Komponenten durch eine Hochleistungsschnittstelle zu kommunizieren. Der IPIC 90 ermöglich es, dass hocheffiziente Stapelkonfigurationen erschaffen werden können.
  • Wie unten erläutert werden wird, steht jeder EPIC 20a, 20b und 20c, die allgemein als EPIC 20 bezeichnet werden, und jeder GPIC 30a und 30b, die allgemein als GPIC 30 bezeichnet werden, eng mit geeigneten Adressauflösungslogiktabellen und Schicht-3-Vermittlungstabellen 21a, 21b, 21c, 31a, 31b, Regeltabellen 22a, 22b, 22c, 31a, 31b und VLAN-Tabellen 23a, 23b, 23c, 31a, 31b in Wechselbeziehung. Diese Tabellen werden jeweils allgemein als 21, 31, 22, 32, 23, 33 bezeichnet. Diese Tabellen werden wie andere Tabellen auf dem SOC 10 in Silizium als x mal y zweidimensionale Arrays implementiert, wobei jede Array (x·y) Speicherstellen darin aufweist.
  • In einem Ausführungsbeispiel der vorliegenden Erfindung unterstützt jeder EPIC 20 acht Fast Ethernet Ports 13 und vermittelt Pakete zu und/oder von diesen Ports, je nachdem, wie dies zweckdienlich ist. Die Ports sind deshalb mit dem Netzwerkmedium (Koaxialkabel, verdrilltes Leitungspaar, Glasfaser, etc.) unter Verwendung der bekannten Medienverbindungstechnologie verbunden und kommunizieren mit dem CPS-Kanal 80 auf der anderen Seite davon. Die Schnittstelle jedes EPIC 20 mit dem Netzwerkmedium kann durch eine RMII-Schnittstelle (Reduced Media Internal Interface) bereitgestellt werden, die die direkte Mediumsverbindung mit dem SOC 10 ermöglicht. Wie in dem Fachgebiet bekannt ist, ist die Autonegotiation ein Aspekt des Fast Ethernet, bei dem das Netzwerk in der Lage ist, eine höchste Kommunikationsgeschwindigkeit zwischen einer Quelle und einem Ziel auf der Grundlage der Fähigkeiten der jeweiligen Geräte aushandeln zu können. Die Kommunikationsgeschwindigkeit kann variieren, wie dies vorher angemerkt worden ist, und zwar zwischen 10 Mbps und 100 Mbps; deshalb ist die Autonegotiations-Fähigkeit direkt in jedes EPIC-Modul eingebaut. Die Adressauflösungslogik-(ARL; address resolution logic)- und Schicht-3-Tabellen (ARL/L3) 21a, 21b, 21c, die Regeltabelle 22a, 22b, 22c und die VLAN-Tabellen 23a, 23b und 23c sind so konfiguriert, dass sie ein Teil des assoziierten EPIC sind oder damit verbunden sind, und zwar in einer effizienten und zweckmäßigen Art und Weise, um auch den Leitungsgeschwindigkeits-Paketfluss zu unterstützen.
  • Jeder EPIC 20 weist separate Eintritts- und Austrittsfunktionen (ingress and egress functions) auf. Auf der Eintrittsseite (ingress side) kann das selbstinitiierte und CPU-initiierte Lernen von Schicht-2-Adressinformationen stattfinden. Die Adressauflösungslogik (ARL) wird verwendet, um diese Aufgabe zu unterstützen. Die Adressalterung ist als ein Leistungsmerkmal eingebaut, um die Speicherung von Adressinformationen zu eliminieren, die nicht mehr länger gültig oder nützlich sind. Der EPIC 20 führt auch die Schicht-2-Spiegelung durch. Ein Schnellfilterungsprozessor (FFP) 141 (siehe 14) ist in jedem EPIC und GPIC eingebaut, um das Paketweiterleiten zu beschleunigen und den Paketfluss zu verbessern. Die Eintrittsseite jedes EPIC und GPIC, die in 8 als ein Eintrittssubmodul 14 veranschaulicht ist, weist einen beträchtlichen Betrag an Komplexität auf, um in der Lage zu sein, eine beträchtliche Anzahl von unterschiedlichen Pakettypen, die bei dem Port hereinkommen können, für die Leitungsgeschwindigkeitspufferung und dann den geeigneten Transfer zu dem Austritt (egress) richtig zu verarbeiten. Funktionell weist jeder Port an jedem Modul des SOC 10 ein separates Eintrittssubmodul 14 auf, das damit assoziiert ist. Aus einer Implementierungsperspektive werden aber, um den Betrag an Hardware zu minimieren, der auf dem Ein-Chip-SOC 10 implementiert wird, gemeinsame Hardware-Elemente in dem Silizium verwendet, um eine Vielzahl von Eintrittssubmodulen in jedem speziellen Modul zu implementieren. Die Konfiguration des SOC 10, die hier diskutiert wird, ermöglicht gleichzeitig Nachschlagevorgänge (Lookups) und die Filterung, und erlaubt deshalb eine Verarbeitung von bis zu 6,6 Millionen Paketen pro Sekunde. Schicht-2-Nachschlagevorgänge, Schicht-3-Nachschlagevorgänge und die Filterung erfolgen gleichzeitig, um dieses Leistungsniveau zu erzielen. Auf der Austrittsseite (egress side) ist der EPIC in der Lage, das Paket-Polling auf der Grundlage entweder als eine Austrittsverwaltungs-Funktion oder als eine Serviceklassen-Funktion (COS-(class-of-service)-Funktion) zu unterstützen. Das Rerouting/Scheduling von Paketen, die übertragen werden sollen, kann erfolgen, sowie auch die Head-of-line-(HOL-)-Blockierungsmitteilung, die Paketalterung, die Reassemblierung der Zellen und andere Funktionen, die mit einer Ethernet Port Schnittstelle assoziiert sind.
  • Jeder GPIC 30 ist jedem EPIC 20 ähnlich, unterstützt aber nur einen Gigabit Ethernet Port und verwendet eher eine portspezifische ARL-Tabelle, als dass er eine ARL-Tabelle verwendet, die mit irgendwelchen anderen Ports gemeinsam genutzt wird. Außerdem ist jeder GPIC-Port mit dem Netzwerkmedium unter Verwendung einer medienunabhängigen Gigabit Schnittstelle (GMII-Schnittstelle) anstatt einer RMII-Schnittstelle verbunden.
  • Der CMIC 40 agiert als ein Gateway zwischen dem SOC 10 und der Host-CPU. Die Kommunikation kann zum Beispiel entlang einem PCI-Bus oder einem anderen akzeptablen Kommunikationsbus erfolgen. Der CMIC 40 kann sequentielle direktabgebildete (direct mapped) Zugriffe zwischen der Host-CPU 52 und dem SOC 10 bereitstellen. Die CPU 52 wird durch den CMIC 40 in der Lage sein, auf zahlreiche Ressourcen auf dem SOC 10 zuzugreifen, die MIB-Zähler, programmierbare Register, Status- und Steuerregister, Konfigurationsregister, ARL-Tabellen, portbasierte VLAN-Tabellen, IEEE 802.1q VLAN-Tabellen, Schicht-3-Tabellen, Regeltabellen, CBP-Adress- und -Datenspeicher sowie auch GBP-Adress- und -Datenspeicher umfassen können. Optional kann der CMIC 40 einen DMA-Support, eine DMA-Verkettungs- und Streuungs-Erfassung sowie auch einen Master- und Ziel-PCI 64 umfassen.
  • Der gemeinsame Pufferspeicherpool oder CBP 50 kann als der Datenspeicher auf dem Chip betrachtet werden. In einem Ausführungsbeispiel ist der CBP 50 ein Primär-Speicher des Hochgeschwindigkeits-SRAM-Typs, um die Leistung zu maximieren und die Hardware-Overhead-Anforderungen zu minimieren. Der CBP 50 kann zum Beispiel eine Größe von 720 Kilobyte aufweisen und bei 132 MHZ laufen. Pakete, die in dem CBP 50 gespeichert sind, werden typischerweise eher als eine Reihe von verknüpften Zellen anstatt als Pakete gespeichert. Die Pakete werden in dem SOC 10 als Zellen gespeichert und bewegt und als Pakete wiederzusammengebaut, bevor sie auf geeigneten Austrittsports hinausgeschickt werden. Wie in der Figur veranschaulicht ist, enthält die MMU 70 auch den gemeinsamen Pufferspeichermanager (CBM) 71. Der CBM 71 handhabt die Warteschlangenverwaltung und ist verantwortlich dafür, den ankommenden Zellen Zellenzeiger zuzuweisen, sowie auch zentrale Paket-INFORMATIONSOFFENLEGUNGSANWEISUNGEN (CPIDs; common packet INFORMATION DISCLOSURE STATEMENT) zuzuweisen, wenn das Paket einmal vollständig in den CBP geschrieben ist. Der CBM 71 kann auch die Verwaltung des Pools der freien Adressenzeiger auf dem Chip handhaben, den tatsächlichen Datenverkehr zu und von dem Datenpool steuern und eine Speicherbudgetverwaltung bereitstellen.
  • Der globale Speicherpufferpool oder GBP 60 agiert als ein Sekundär-Speicher und kann auf dem Chip (on-chip) oder extern von dem Chip (off-chip) angeordnet sein. In einem Ausführungsbeispiel ist der GBP 60 extern von dem Chip im Hinblick auf den SOC 10 angeordnet. Wenn er sich extern von dem Chip befindet, wird der GBP 60 als ein Teil des externen Speichers 12 oder als der gesamte externe Speicher 12 betrachtet. Als ein Sekundär-Speicher muss der GBP kein teurer Hochgeschwindigkeits-SRAM sein und kann ein langsamerer, kostengünstigerer Speicher wie etwa ein DRAM sein. Der GBP ist eng mit der MMU 70 gekoppelt und arbeitet wie der CBP, da Pakete als Zellen gespeichert werden. Für Broadcast- und Multicast-Nachrichten wird nur eine Kopie des Pakets in dem GBP 60 gespeichert.
  • Wie in den Figuren gezeigt ist, befindet sich die MMU 70 zwischen dem GBP 60 und dem CPS-Kanal 80 und agiert als eine externe Speicherschnittstelle. Um die Speicherausnutzung zu optimieren, umfasst die MMU 70 mehrere Lese- und Schreibpufferspeicher und unterstützt zahlreiche Funktionen, die die globale Warteschlangenverwaltung umfassen, die allgemein die Zuweisung von Zellenzeigern für umgeleitete ankommende Pakete, die Aufrechterhaltung des globalen FAP, die zeitoptimierte Zellenverwaltung, die globale Speicherbudgetverwaltung, die GPID-Zuweisungs- und Austrittsmanager-Benachrichtigung, die Schreibpufferspeicherverwaltung, die Lese-Prefetches auf der Grundlage von Austrittsmanager-/Serviceklassenanforderungen und eine intelligente Speichersteuerung umfasst.
  • Wie in 2 gezeigt ist, besteht der CPS-Kanal 80 eigentlich aus drei separaten Kanälen, die als der C-Kanal, der P-Kanal und der S-Kanal bezeichnet werden. Der C-Kanal weist eine Breite von 128 Bits auf und läuft bei 132 MHZ. Paketübertragungen zwischen Ports finden in dem C-Kanal statt. Da dieser Kanal lediglich zum Datentransfer verwendet wird, ist mit seiner Benutzung kein Overhead verbunden. Der P-Kanal oder Protokoll-Kanal ist mit dem C-Kanal synchron oder mit diesem phasenverriegelt. Während der Zellübertragungen wird der Nachrichten-Header von der MMU über den P-Kanal gesendet. Der P-Kanal weist eine Breite von 64 Bits auf und läuft bei 132 MHZ.
  • Der S- oder Seitenband-Kanal läuft bei 132 MHZ und weist eine Breite von 32 Bits auf. Der S-Kanal wird für Funktionen wie etwa das Übertragen des Port-Verbindungsstatus, die Empfangsport-Voll-Funktionen, Portstatistiken, ARL-Tabellen-Synchronisierungsfunktionen, Speicher- und Registerzugriffsfunktionen auf die CPU und andere CPU-Verwaltungsfunktionen sowie die Globaler-Speicher-Voll- und Gemeinsamer-Speicher-Voll-Benachrichtigung verwendet.
  • Ein richtiges Verstehen des Betriebs des SOC 10 erfordert ein korrektes Verstehen des Betriebs des CPS-Kanals 80. Unter Bezugnahme auf 3 ist zu sehen, dass in dem SOC 10 an dem Eintritt Pakete, die zu einem EPIC oder GPIC hereinkommen, von dem EPIC 20 oder dem GPIC 30 in Zellen von 64 Byte geschnitten werden. Die Verwendung von Zellen auf dem Chip anstatt von Paketen macht es leichter, den SOC so anzupassen, dass er mit zellbasierten Protokollen wie etwa zum Beispiel dem asynchronen Transfermodus (ATM) arbeiten kann. Gegenwärtig verwendet der ATM aber Zellen mit einer Länge von 53 Bytes, wobei 48 Bytes für die Nutzlast und 5 Bytes für den Header vorgesehen sind. In dem SOC werden ankommende Pakete in Zellen zerteilt, die 64 Byte lang sind, wie dies oben diskutiert worden ist, und die Zellen werden noch weiter in vier separate Zellenblöcke Cn0 ... Cn3 mit 16 Bytes geteilt. Phasenverriegelt mit dem C-Kanal ist der P-Kanal, der den Opcode in Synchronisation mit Cn0 festgelegt. Eine Port-Bitmap wird in den P-Kanal während der Phase Cn1 eingeführt. Die Bitmap ohne Tags wird in den P-Kanal während der Phase Cn2 eingeführt, und ein Zeitstempel wird in dem P-Kanal in Cn3 platziert. Unabhängig von den Ereignissen in dem C-Kanal und dem P-Kanal wird der S-Kanal als ein Seitenband verwendet und ist deshalb von den Aktivitäten in dem C-Kanal und dem P-Kanal abgetrennt.
  • Der IPIC 90 kommuniziert mit dem CPS-Kanal 80 und funktioniert im Wesentlichen wie ein Port. Pakete, die in den IPIC von außerhalb des SOC 10 hineinkommen, würden entweder von einem anderen IPIC-Modul auf einem anderen SOC 10 oder von anderen Verbindungen durch eine Hochleistungsschnittstelle kommen. Der IPIC ist deshalb von einem EPIC-Modul 20 unterscheidbar, da jeder EPIC typischerweise eine Vielzahl von Ports aufweisen wird, während der IPIC nur einen einzigen Port aufweist. Wie noch ausführlicher beschrieben werden wird, umfasst der IPIC einen internen Speicherpuffer, der als der Netzwerk-Pufferspeicherpool oder NBP bezeichnet wird, und der in den 1 und 2 als NBP 92 veranschaulicht ist. Der IPIC 90 umfasst auch eine Vielzahl von Tabellen 91 für die Pakethandhabung, wie etwa eine VLAN-Tabelle 802.1q, Gruppierungstabellen, etc.. Der IPIC 90 weist keine ARL-Tabellen auf, da die Zielportnummer in dem Modul-Header zur Verfügung stehen wird. Pakete, die in den SOC 10 entweder durch einen EPIC 20 oder einen GPIC 30 hereinkommen und die für den IPIC 90 bestimmt sind, werden nicht in dem CBP oder GBP gespeichert, sondern werden zu dem NBP 92 im Innern des IPIC 90 selber geroutet und dort gespeichert.
  • Zellen- oder C-Kanal
  • Die Arbitrierung für den CPS-Kanal tritt außerhalb des Bandes auf. Jedes Modul (EPIC, GPIC, IPIC, etc.) überwacht den Kanal, und passende Zielports antworten auf die entsprechenden Transaktionen. Die C-Kanal-Arbitrierung ist ein Demand-Priority-Round-Robin-Arbitrierungsmechanismus. Wenn keine Anforderungen aktiv sind, kann aber der Standardmodus, der während der Konfiguration des SOC 10 ausgewählt werden kann, in dem Kanal parken und kompletten Zugriff darauf haben. Wenn alle Anforderungen aktiv sind, ist die Konfiguration des SOC 10 derart, dass der MMU bei jedem zweiten Zellenzyklus Zugriff gewährt wird und sich die EPICs 20, die GPICs 30 und der IPIC 90 den gleichen Zugriff auf den C-Kanal auf einer Round-Robin-Basis teilen. Die 4A und 4B veranschaulichen einen C-Kanal-Arbitrierungsmechanismus, bei dem der Abschnitt A die MMU ist und der Abschnitt B aus zwei GPICs, drei EPICs und einem IPIC besteht. Die Abschnitte haben abwechselnd Zugriff, und da die MMU das einzige Modul im Abschnitt A ist, bekommt sie bei jedem zweiten Zyklus Zugriff. Die Module im Abschnitt B erhalten den Zugriff auf einer Round-Robin-Basis, wie dies vorher bereits erwähnt worden ist.
  • Das Arbitrierungsverfahren des C-Kanals 81 ist, wie dies vorher erläutert worden ist und in den 4A und 4B veranschaulicht ist, ein Demand-Priority-Round-Robin-Verfahren. Jedes E/A-Modul, der EPIC 20, der GPIC 30, der CMIC 40 und der IPIC 90 zusammen mit der MMU 70 kann eine Anforderung für einen Zugriff auf den C-Kanal initiieren. Wenn keine Anfrage zu irgendeiner gegebenen Zeit besteht, bekommt das Standardmodul, das mit einer hohen Priorität eingerichtet ist, den vollständigen Zugriff auf den C-Kanal 81. Wenn irgendein einzelnes E/A- Modul oder die MMU 70 Zugriff auf den C-Kanal 81 anfordert, erhält dieses einzelne Modul auf Abruf (on demand) Zugriff auf den C-Kanal 81.
  • Wenn die EPIC-Module 20a, 20b, 20c und die GPIC-Module 30a und 30b, der IPIC 90 und der CMIC 40 gleichzeitig Zugriff auf den C-Kanal anfordern, dann wird der Zugriff in einer Round-Robin-Weise gewährt. Für einen gegebenen Arbitrierungszeitraum würde jedem der E/A-Module ein Zugriff auf den C-Kanal 81 bereitgestellt. Zum Beispiel würde jedem GPIC-Modul 30a und 30b der Zugriff gewährt, gefolgt von den EPIC-Modulen und schließlich dem CMIC 40. Nach jedem Arbitrierungszeitraum würde das nächste E/A-Modul mit einer gültigen Anforderung den Zugriff auf den C-Kanal 81 gewährt bekommen. Dieses Muster würde fortgesetzt, solange jedes der E/A-Module eine aktive Zugriffsanforderung für den C-Kanal 81 bereitstellen würde.
  • Protokoll- oder P-Kanal
  • Unter erneuter Bezugnahme auf den Protokoll- oder P-Kanal kann eine Vielzahl von Nachrichten in dem P-Kanal platziert werden, um den Fluss an Daten, der in dem C-Kanal fließt, richtig zu lenken. Da der P-Kanal 84 eine Breite von 64 Bits aufweist und eine Nachricht typischerweise 128 Bits benötigt, werden zwei kleinere 64-Bit-Nachrichten zusammengefasst, um eine komplette P-Kanal-Nachricht zu bilden. Die nachfolgende Liste identifiziert die Felder und die Funktion sowie die verschiedenen Bitzählungen der 128-Bit-Nachricht in dem P-Kanal.
    • IP/IPX Bits – 2 Bits lang – IP/IPX Bits – Enthält Informationen bezüglich des Pakettyps. Wert 0 – Ist ein L2-vermitteltes Paket. Wert 1 – Das Paket ist ein IP-vermitteltes Paket. Wert 2 – Das Paket ist ein IPX-vermitteltes Paket. Wert 3 – Das Paket ist ein IP-Multicast-Paket.
    • Next Cell – 2 Bits lang – Die Next Cell (nächste Zelle) weist die einzigartige Anforderung auf, den Zell-Header zufrieden zu stellen: Wert 01 – Wenn die gültigen Bytes (valid bytes) in dieser Zelle zwischen 1 und 16 liegen. Wert 02 – Wenn die gültiges Bytes in dieser Zelle zwischen 17 und 32 liegen. Wert 03 – Wenn die gültigen Bytes in dieser Zelle zwischen 33 und 48 liegen. Wert 00 – Wenn die gültigen Bytes in dieser Zelle zwischen 49 und 64 liegen. Für die erste Zelle sind alle vier Zyklen gültig.
    • Src Dest Port – 6 Bits lang – Die Nummer des Ports, der die Nachricht sendet oder die Nachricht empfängt. Die Interpretation der Quelle oder des Ziels hängt von dem Opcode ab.
    • Cos – 3 Bits lang – COS – Die Class of Service (Serviceklasse) für dieses Paket.
    • J Bit – 1 Bit lang – Das J Bit in der Nachricht identifiziert, dass das Paket ein Jumbo-Paket ist.
    • S Bit – 1 Bit lang – Das S Bit wird verwendet, um zu identifizieren, dass dies die erste Zelle des Pakets ist. Wenn das S Bit gesetzt ist, sind alle vier Zyklen gültig.
    • E Bit – 1 Bit lang – Das E Bit wird dazu verwendet, zu identifizieren, dass dies die letzte Zelle des Pakets ist. Wenn das E Bit gesetzt ist, dann enthält das Längenfeld die Anzahl an gültigen Bytes in dem Transfer.
    • CRC Bits – 2 Bits lang – Wert 0×01 – ist das Append CRC Bit. Wenn dieses Bit gesetzt ist, dass sollte der Austrittsport die CRC an das Paket anhängen. Wert 0×02 – ist das Regenerate CRC Bit. Wenn dieses Bit gesetzt ist, dann sollte der Austrittsport CRC regenerieren. Wert 0×00 – keine Änderung bei CRC. Wert 0×03 – nicht benutzt.
    • P Bit – 1 Bit lang – Wenn dieses Bit gesetzt ist, dann soll die MMU das gesamte Paket löschen.
    • Len – 7 Bits lang – Die Len Bits werden dazu verwendet, die gültige Anzahl der Bytes in diesem Transfer zu identifizieren. Dieses Feld ist für jede Zelle gültig.
    • O Bits – 2 Bits lang – Optimization Bits (Optimierungs-Bits) werden für die CPU bereitgestellt, so dass diese das Paket effizienter verarbeiten kann. Wert 0 – Nicht verwendet. Wert 1 – ist gesetzt, wenn das Paket der CPU als ein Ergebnis des gesetzten C-Bits in der Standard-Router-Tabelle geschickt wird. Wert 2 – Rahmentyp-Fehlübereinstimmung – Wenn dieses Bit gesetzt ist, dann passt der IPX-Rahmenpakettyp nicht zu dem Pakettyp in der IPX-L3-Tabelle. Wert 3 – Reserviert.
    • Bc/Mc Bitmap – 31 Bits lang – Broadcast- und Multicast-Bitmap. Dieses Feld identifiziert alle Austrittsports, zu denen das Paket geschickt werden soll.
    • UnTagged Bits/Source Port (Bit 0 .. 5) – 31/5 Bits lang – Wenn der Opcode 0×02 ist, das heißt, das Paket wird von dem Port zu der MMU transferiert, dann wird dieses Feld als Bitmap ohne Tags (Untagged Bitmap) interpretiert. Aber wenn der Opcode 0×01 ist, das heißt, das Paket wird von der MMU zu dem Austrittsport transferiert, dann werden die letzten 6 Bits dieses Feldes als das Source Port Feld (Quellportfeld) interpretiert. Untagged Bits – diese Bits identifizieren alle Austrittsports, die den Tag-Header abstreifen sollen. Source Port (Bit 0 .. 5) – Die Source Port Number (Quellportnummer), d.h., die Nummer des Ports, bei dem dieses Paket den Switch betreten hat.
    • U Bit – 1 Bit lang – U Bit – Dieses Feld ist nur von Bedeutung, wenn der Opcode 0×01 ist, das heißt, das Paket von der MMU zu dem Austritt transferiert wird. Wenn dieses Bit gesetzt ist, dann sollte das Paket aus dem Port als Tagfrei (untagged) herausgehen, das heißt, die MAC muß das Tag-Abstreifen durchführen.
    • Time Stamp – 14 Bits lang – Der Time Stamp bzw. Zeitstempel ist ein laufender 14 Bit Zähler, den das System in dieses Feld stellt, wenn das Paket ankommt. Der Zeitstempel wird mit der Granularität von 1 μsec implementiert.
    • Vlan Id – 12 Bits lang – Vlan-Identifizierer. Merke: In Orion-SA werden alle Pakete in dem CP-Kanal als ein mit Tags versehenes Paket übertragen, d.h., die VLAN Id wird zusammen mit dem Paket gesendet, wobei es wie bei der Orion-SM VLAN Id auf dem P-Kanal weitergeleitet wird. Das heißt, jedes Paket (ob ohne Tag oder mit Tag) wird so, wie es ist, in einem Zellen-Kanal weggehen.
    • Matched Filter – 4 Bits lang – Matched Filter Rules – Dieses Feld identifiziert das passende Filter, wenn das Paket als ein Ergebnis des Filterabgleichs zu der CPU gehen muß. Dieses Feld ist nur gültig, wenn das Bit 0 der CPU-Opcodes gesetzt ist. Wenn das MSB (Bit 4) 0 ist, dann wird es von dem Filter auf 1 gesetzt, aber wenn das MSB (Bit 4) 1 ist, dann wird es von dem Filter auf 2 gesetzt.
    • CPU Opcodes – 18 Bits lang – CPU-Opcodes: Wir haben diese Bits für eine effiziente Verarbeitung des Pakets durch die CPU bereitgestellt. Diese Bits werden gesetzt, wenn das Paket aus verschiedenen Gründen zu der CPU gesendet wird. Die nachfolgenden Opcodes sind folgendermaßen definiert: Bit 0 – Filter Match Bit (Filterabgleichbit) – Dieses Bit wird als ein Ergebnis eines Filterabgleichs gesetzt, und eine der Aktionen des Filters ist, das Paket zu der CPU zu senden. Bit 1 – Dieses Bit wird gesetzt, wenn 1) das CPU-Lernbit in der portbasierten VLAN-Tabelle gesetzt ist und die Quell-MAC-Adresse in der ARL-Tabelle gelernt wird, oder 2) ein CM Bit in der PVLAN-Tabelle gesetzt ist und es ein SLF ist, oder 3) die ankommende VLAN-Id nicht in der 802.1Q VLAN-Tabelle gefunden wird. Bit 2 – Dieses Bit ist gesetzt, wenn das Source Routing Bit (Quell-Routing-Bit) das Bit 40 der Quell-MAC-Adresse ist. Bit 3 – Dieses Bit ist gesetzt, wenn es sich 1) um einen Zielnachschlagevorgang-Fehlschlag handelt oder 2) eine L3-Stationsbewegung vorliegt. Bit 4 – Control Frame Bit (Steuerrahmenbit) – Dieses Bit ist gesetzt, wenn das Paket ein BPDU, GVRP, GMRP oder eine der reservierten Adressen ist. Bit 5 – IP Packet Bit – Dieses Bit ist gesetzt, wenn das Paket IP-vermittelt werden muss. Bit 6 – IPX Packet Bit – Dieses Bit ist gesetzt, wenn das Paket IPX-vermittelt werden muss. Bit 7 – IP Options Presence Bit – Dieses Bit ist gesetzt, wenn IP-Optionen vorhanden sind. Bit 8 – Dieses Bit ist gesetzt, wenn das Paket ein Klasse D-IP-Multicast-Paket ist. Bit 9 – Dieses Bit ist gesetzt, wenn TTL nach der Dekrementierung Null oder weniger ist. Bit 10 – Broadcast Bit – Wenn dieses Bit gesetzt ist, dann ist das Paket ein Broadcast-Paket. Bit 11 – Multicast Packet-Dieses Bit ist gesetzt, wenn das Paket ein Multicast-Paket ist.
    • New IP Checksum – 16 Bits lang – Neue IP-Prüfsumme – Dieses Feld wird nur für die Schicht-3-vermittelten IP-Multicast Pakete verwendet. Dieses Feld enthält die neue IP-Prüfsumme, die von dem Eintritt nach dem Dekrementieren des TTL-Feldes berechnet wird.
    • L3 Port Bitmap – 31 Bits lang – L3 Port Bitmap – identifiziert alle L3-vermittelten Ports für ein IP-Multicast-Paket.
  • MODULSPEZIFISCHE FELDER:
    • C Bit – 1 Bit lang – Control Bit – Das Steuerbit identifiziert, ob dies ein Steuerrahmen oder ein Datenrahmen ist. Dieses Bit wird für den Steuerrahmen auf 1 gesetzt und wird für den Datenrahmen auf 0 gesetzt.
    • Mod Opcodes – 3 Bits lang – Mod Opcodes – werden dazu verwendet, den Pakettyp zu identifizieren. Wert 00 – identifiziert, dass das Paket ein Unicast-Paket ist und der Austrittsport eindeutig von der Modul-Id-Bitmap (nur ein Bit wird in diesem Feld gesetzt) und der Austrittsportnummer identifiziert wird. Wert 01 – identifiziert, dass das Paket ein Broadcast- oder Zielnachschlagevorgang-Fehlschlag (DLF) ist und für mehrere Ports auf dem gleichen Modul oder für mehrere Ports auf unterschiedlichen Modulen bestimmt ist. Der Austrittsport ist in diesem Szenario kein gültiges Feld. Wert 02 – identifiziert, dass das Paket ein Multicast-Paket ist und an mehrere Ports adressiert ist. Wert 03 – identifiziert, dass das Paket ein IP-Multicast-Paket ist und an mehrere Ports adressiert ist.
    • TGID – 3 Bits lang – TGID Bits – TGID identifiziert den Trunk Group (Leitungsbündel-)-Identifizierer des Quellports. Dieses Feld ist nur gültig, wenn das T-Bit gesetzt ist.
    • T – 1 Bit lang – T Bit – Wenn dieses Bit gesetzt ist, dann ist TGID ein gültiges Feld.
    • MT Module Id – 5 Bits lang – die MT-Modul-Id ist eine Modul-Id, "zu der gespiegelt wird" ("mirrored-to" module Id). Dieses Feld wird dazu verwendet, das Paket zu einem Port, "zu dem gespiegelt wird" ("mirrored-to" port), zu senden, der sich auf einem fernen Modul befindet. Dieses Feld ist nur gültig, wenn das M-Bit gesetzt ist.
    • M Bit – 1 Bit lang – M Bit – Wenn dieses Bit gesetzt ist, dann ist die MT-Modul-Id ein gültiges Feld.
    • Remote Port – 6 Bits lang – Remote Port ist die Nummer des Ports auf dem fernen Modul, der das Paket empfangen soll.
    • Src Port – 6 Bits lang – Source Port ist der Quellport des Pakets.
    • PFM Bits – 2 Bits lang – PFM Bits ist der Portfilterungsmodus des Quellports. Diese Bits sind nur für ein Multicast-Paket gültig.
    • Mod Id Bitmap – 32 Bits lang – Die Bitmap aller Module, die dieses Paket bekommen sollen.
  • Das Opcode Feld der P-Kanal-Nachricht definiert den Typ der Nachricht, die im Augenblick gesendet wird. Obwohl der Opcode gegenwärtig so gezeigt ist, dass er eine Breite von 2 Bits aufweist, kann das Opcode Feld je nach Wunsch erweitert werden, um an neue Typen von Nachrichten angepasst zu werden, die in der Zukunft definiert werden können. Graphisch ist der P-Kanal-Nachrichtentyp, der oben definiert ist, aber in 5 gezeigt.
  • Eine Frühbeendigungsnachricht wird verwendet, um dem CBM 71 anzuzeigen, dass das aktuelle Paket beendet werden soll. Während des Betriebs wird, wie dies unten noch ausführlicher erörtert werden wird, das Status Bit (S) Feld in der Nachricht so gesetzt, dass es den Wunsch anzeigt, das aktuelle Paket aus dem Speicher zu löschen. Im Ansprechen auf das Status Bit würden auch alle betroffenen Austrittsports das aktuelle Paket vor der Übertragung löschen.
  • Das Src Dest Port Feld der P-Kanal-Nachricht definiert, wie dies oben angegeben worden ist, jeweils die Ziel- und die Quellportadressen. Jedes Feld weist eine Breite von 6 Bits auf und erlaubt daher die Adressierung von 64 Ports.
  • Das CRC Feld der Nachricht ist 2 Bits breit und definiert CRC-Aktionen. Das Bit 0 des Feldes stellt eine Angabe bereit, ob der assoziierte Austrittsport eine CRC an das aktuelle Paket anhängen soll. Ein Austrittsport würde eine CRC an das aktuelle Paket anhängen, wenn das Bit 0 des CRC Feldes auf eine logische Eins gesetzt ist. Das Bit 1 des CRC Feldes stellt eine Angabe bereit, ob der assoziierte Austrittsport eine CRC für das aktuelle Paket regenerieren soll. Ein Austrittsport würde eine CRC regenerieren, wenn das Bit 1 des CRC Feldes auf eine logische Eins gesetzt ist. Das CRC Feld ist nur für die letzte Zelle gültig, die übertragen wird, wie dies von dem E-Bit-Feld der P-Kanal-Nachricht definiert wird, das auf eine logische Eins gesetzt ist.
  • Wie bei dem CRC Feld sind das Status Bit Feld (st), das Len Feld und das Cell Count Feld der Nachricht nur für die letzte Zelle eines Pakets gültig, das übertragen wird, wie dies von dem E-Bit Feld der Nachricht definiert ist.
  • Da der SOC 10 für effiziente Stapelkonfigurationen konfiguriert ist, werden 32 Bits in Protokoll-Kanal-Nachrichten für eine Modul-ID-Bitmap bereitgestellt, die eine Bitmap aller Module eines Stapels ist, die das Paket bekommen sollen. Aufgrund der Wichtigkeit der Modul-ID in dem SOC 10 sind die Modul-ID und die Portnummer (bestimmbar aus dem Remote Port Feld) wichtig für einen korrekten Paketfluss in einem Stapel.
  • Das Time Stamp Feld der Nachricht weist eine Auflösung von 1 μs auf und ist nur für die erste Zelle des Pakets gültig, wie von dem S Bit Feld der Nachricht definiert ist. Eine Zelle ist als die erste Zelle eines empfangenen Pakets definiert, wenn das S-Bit Feld der Nachricht auf einen logischen Wert von Eins gesetzt ist.
  • Wie dies unten noch ausführlicher beschrieben werden wird, sind der C-Kanal 81 und der P-Kanal 82 synchron miteinander derart verbunden, dass die Daten in dem C-Kanal 81 über den CPS-Kanal 80 übertragen werden, während gleichzeitig eine entsprechende P-Kanal-Nachricht übertragen wird.
  • S-Kanal oder Seitenband-Kanal
  • Der S-Kanal 83 ist ein 32 Bit breiter Kanal, der einen separaten Kommunikationsweg innerhalb des SOC 10 bereitstellt. Der S-Kanal 83 wird für die Verwaltung durch die CPU 52, die interne Flusskontrolle des SOC 10 und die Intermodulbenachrichtigung in dem SOC 10 verwendet. Der S-Kanal 83 ist ein Seitenband-Kanal des CPS-Kanals 80 und ist elektrisch und physikalisch von dem C-Kanal 81 und dem P-Kanal 82 isoliert. Es ist wichtig anzumerken, dass, da der S-Kanal separat und getrennt von dem C-Kanal 81 und dem P-Kanal 82 ist, der Betrieb des S-Kanals 83 in bezug auf den Betrieb des C-Kanals 81 und des P-Kanals 82 fortgesetzt werden kann, ohne dass es zu einer Leistungsverschlechterung kommt. Im umgekehrten Fall gibt es, da der C-Kanal nicht für die Übertragung von Systemnachrichten verwendet wird, sondern nur für die Übertragung von Daten, keinen Overhead, der mit dem C-Kanal 81 assoziiert ist, und somit ist der C-Kanal 81 in der Lage, je nach Bedarf frei zu laufen, um ankommende und abgehende Paketinformationen zu handhaben.
  • Der S-Kanal 83 des CPS-Kanals 80 stellt einen systemweiten Kommunikationspfad für die Übertragung von Systemnachrichten bereit, der zum Beispiel die CPU 52 mit einem Zugriff auf die Steuerstruktur des SOC 10 versorgt. Systemnachrichten umfassen Portstatusinformationen, die den Portverbindungsstatus, Empfangsport-Voll-Informationen und Portstatistiken umfassen, die ARL-Tabellensynchronisierung, den CPU-52-Zugriff auf die Speicherpuffer GBP 60 und CBP 50 und auf die SOC-10-Steuerregister, und eine Speicher-Voll-Mitteilung, die dem GBP 60 und/oder dem CBP 50 entspricht.
  • 6 veranschaulicht ein Nachrichtenformat für eine S-Kanal-Nachricht in dem S-Kanal 83. Die Nachricht ist aus vier 32-Bit-Worten gebildet; die Bits der Felder der Worte sind wie folgt definiert:
    • Opcode – 6 Bits lang – Identifiziert den Typ an Nachricht, der in dem S-Kanal vorhanden ist;
    • Dest Port – 6 Bits lang – Definiert die Nummer des Ports, zu dem die aktuelle S-Kanal-Nachricht geschickt werden soll;
    • Src Port – 6 Bits lang – Definiert die Nummer des Ports, von dem die aktuelle S-Kanal-Nachricht stammt;
    • COS – 3 Bits lang – Definiert die Serviceklasse, die mit der aktuellen S-Kanal-Nachricht assoziiert ist; und
    • C bit – 1 Bit lang – Definiert logisch, ob die aktuelle S-Kanal-Nachricht für die CPU 52 bestimmt ist.
    • Error Code – 2 Bits lang – Definiert einen gültigen Fehler, wenn das E Bit gesetzt ist;
    • DataLen – 7 Bits lang – Definiert die gesamte Anzahl an Datenbytes in dem Data-Feld;
    • E bit – 1 Bit lang – Gibt logisch an, ob ein Fehler bei der Ausführung des aktuellen Befehls aufgetreten ist, wie dieser von dem Opcode definiert ist;
    • Address – 32 Bits lang – Definiert die Speicheradresse, die mit dem aktuellen Befehl assoziiert ist, wie dieser in dem Opcode definiert ist;
    • Data – 0-127 Bits lang – Enthält die Daten, die mit dem aktuellen Opcode assoziiert sind.
  • Mit der Konfiguration des CPS-Kanals 80, wie sie oben definiert worden ist, ist das Entkoppeln des S-Kanals von dem C-Kanal und dem P-Kanal derart, dass die Bandbreite in dem C-Kanal für den Zellentransfer aufbewahrt werden kann, und dass die Überlastung des C-Kanals nicht die Kommunikationen in dem Seitenband-Kanal beeinträchtigt.
  • SOC-Betrieb
  • Die Konfiguration des SOC 10 unterstützt Fast Ethernet Ports, Gigabit Ports und erweiterbare Verbindungen davon, wie oben diskutiert worden ist. Die SOC-Konfiguration kann auch gestapelt werden, wie vorher angemerkt worden ist, wodurch eine beträchtliche Porterweiterungsfähigkeit ermöglicht wird. Wenn die Datenpakete von dem SOC 10 empfangen, in Zellen geschnitten und in dem CPS-Kanal 80 platziert worden sind, können sich gestapelte SOC-Module mit dem CPS-Kanal verbinden, den Kanal überwachen und geeignete Informationen je nach Notwendigkeit extrahieren. Wie unten erläutert werden wird, tritt ein beträchtlicher Betrag an zeitgleich ablaufenden Nachschlagevorgängen und Filterung auf, wenn das Paket in das Eintrittssubmodul 14 eines EPIC 20 oder GPIC 30 eintritt, und zwar im Hinblick auf Schicht-2- und Schicht-3-Nachschlagevorgänge und eine schnelle Filterung.
  • Nun wird unter Bezugnahme auf die 8 und 9 die Handhabung eines Datenpakets beschrieben. Für Erläuterungszwecke wird davon ausgegangen, dass Ethernet-Daten, die empfangen werden sollen, an einem der Ports 24a des EPIC 20a ankommen. Es wird angenommen, dass das Paket zu einem Benutzer übertragen werden soll, und zwar auf einem der Ports 24c des EPIC 20c. Alle EPICs 20 (20a, 20b, 20c, etc.) weisen ähnliche Merkmale und Funktionen auf, und jeder arbeitet individuell auf der Grundlage des Paketflusses.
  • Ein Eingabedatenpaket 112 wird an dem Port 24a wie gezeigt angelegt. Das Datenpaket 112 ist in diesem Beispiel durch die aktuellen Standards für eine 10/100 Mbps Ethernet-Übertragung definiert und kann jede Länge oder Struktur aufweisen, wie diese von diesem Standard definiert sind. Die vorliegende Diskussion wird annehmen, dass die Länge des Datenpakets 112 1024 Bits oder 128 Bytes sei.
  • Es sollte angemerkt werden, dass jeder EPIC 20 und jeder GPIC 30 ein Eintrittssubmodul 14 und ein Austrittssubmodul 16 aufweist, die portspezifische Eintritts- und Austrittsfunktionen bereitstellen. Die gesamte Verarbeitung eines ankommenden Pakets findet in dem Eintrittssubmodul 14 statt, und Funktionsmerkmale wie zum Beispiel der Schnellfilterungsprozessor, Schicht-2-(L2)- und Schicht-3-(L3)-Nachschlagevorgänge, Schicht-2-Lernvorgänge, sowohl selbstinitiiert als auch CPU-52-initiiert, Schicht-2-Tabellenverwaltung, Schicht-2-Vermittlung, Paketschneiden, Offset-Anlegung und Kanalzuteilung erfolgen in dem Eintrittssubmodul 14. Nach den Nachschlagevorgängen, der Schnellfilterungsverarbeitung und dem Schneiden in Zellen, wie dies oben angemerkt worden ist und unten noch diskutiert werden wird, wird das Paket aus dem Eintrittssubmodul 14 in eine Zuteilungseinheit 18 platziert und dann in den CPS-Kanal 80 platziert, und die Speicherverwaltung wird von der MMU 70 gehandhabt. Eine Anzahl von Eintrittspufferspeichern sind in der Zuteilungseinheit 18 bereitgestellt, um eine korrekte Handhabung der Pakete/Zellen zu gewährleisten. Wenn die Zellen oder in Zellen aufgeteilten Pakete in den CPS-Kanal 80 platziert werden, ist das Eintrittssubmodul mit dem Paket fertig. Der Eintritt ist nicht mit der dynamischen Speicherzuweisung oder dem speziellen Weg involviert, den die Zellen zu dem Ziel nehmen werden. Das Austrittssubmodul 16, das in 8 als Submodul 16a des EPIC 20a veranschaulicht ist, überwacht den CPS-Kanal 80 und hält kontinuierlich nach Zellen Ausschau, die für einen Port dieses bestimmten EPIC 20 bestimmt sind. Wenn die MMU 70 ein Signal empfängt, dass ein Austritt, der mit einem Ziel eines Pakets in dem Speicher assoziiert ist, bereit ist, Zellen zu empfangen, zieht die MMU 70 die Zellen, die mit dem Paket assoziiert sind, aus dem Speicher heraus, was unten noch erläutert werden wird, und platziert die Zellen in dem CPS-Kanal 80, abgezielt auf das entsprechende Austrittssubmodul. Ein FIFO in dem Austrittssubmodul 16 sendet kontinuierlich ein Signal auf den CPS-Kanal 80, dass er bereit ist, Pakete zu empfangen, wenn es in dem FIFO Platz zur Aufnahme von Paketen oder Zellen gibt. Wie vorher angemerkt worden ist, ist der CPS-Kanal 80 so konfiguriert, dass er Zellen handhaben kann, aber Zellen eines bestimmten Pakets werden immer zusammen gehandhabt, um ein Verfälschen bzw. eine Verstümmelung oder ein Durcheinanderbringen von Paketen zu verhindern.
  • In einem Ausführungsbeispiel der vorliegenden Erfindung bestimmt das Eintrittssubmodul 14a in dem EPIC 20a dann, wenn ein Datenpaket 112 von dem EPIC-Modul 20a empfangen wird, als eine Eintrittsfunktion das Ziel des Pakets 112. Insbesondere werden die ersten 64 Bytes des Datenpakets 112, die die Header-Information bilden, von dem Eintrittssubmodul 14a gepuffert und mit Daten verglichen, die in den ARL/L3-Tabellen 21a gespeichert sind, um den Zielport 24c des Datenpakets 112 zu bestimmen. Ebenfalls als eine Eintrittsfunktion schneidet das Eintrittssubmodul 14a das Datenpaket 112 in eine geeignete Anzahl von 64-Byte-Zellen. In diesem Fall wird das beispielhafte 128-Byte-Paket in zwei 64-Byte-Zellen 112a und 112b geschnitten. Obwohl das beispielhafte Datenpaket 112, das in diesem Beispiel gezeigt ist, exakt zwei 64-Byte-Zellen 112a und 112b ist, kann ein tatsächliches ankommendes Datenpaket eine beliebige Anzahl von Zellen sein und umfasst oftmals eine beliebige Anzahl von Zellen, wobei wenigstens eine dieser Zellen eine Länge von weniger als 64 Bytes aufweist. In solchen Situationen werden Stopf-Bytes zu der unvollständigen Zelle hinzugefügt, um die gesamten 64 Bytes der Zelle zu füllen. In solchen Fällen ignoriert das Eintrittssubmodul 14a die Stopf-Bytes innerhalb der Zelle und verarbeitet das Paket wie jedes andere. Weitere Erörterungen der Pakethandhabung werden sich auf das Paket 112 und/oder die Zellen 112a und 112b beziehen. Ein typisches Zellenformat ist in 11 gezeigt.
  • Um Datenfluss-Leistungsrückgangs-Probleme zu überwinden, die mit einer Overhead-Verwendung des C-Kanals 81 assoziiert sind, werden die gesamten L2-Lernvorgänge und die L2-Tabellenverwaltung durch die Verwendung des S-Kanals 83 erreicht. Das selbstinitiierte L2-Lernen wird erreicht, indem die Quelladresse eines Benutzers an einem gegebenen Eintrittsport 24 unter Verwendung der mit dem Paket assoziierten Adresse entschlüsselt wird. Sobald die Identität des Benutzers an dem Eintrittsport 24 ermittelt ist, werden die ARL-/L3-Tabellen 21a aktualisiert, um die Benutzeridentifikation zu reflektieren. Die ARL-/L3-Tabellen 21 jedes anderen EPIC 20 und GPIC 30 werden, um die neu erworbene Benutzeridentifikation zu re flektieren, in einem Synchronisierungsschritt aktualisiert, wie dies unten beschrieben werden wird. Als eine Folge davon kann, obwohl der Eintritt des EPIC 20a feststellen kann, dass ein gegebener Benutzer an einem gegebenen Port 24a ist, der Austritt des EPIC 20b, dessen Tabelle 21b mit der Benutzeridentifikation am Port 24a aktualisiert worden ist, dann Informationen dem Benutzer an dem Port 24a bereitstellen, ohne erneut zu lernen, mit welchem Port der Benutzer verbunden war, was die ARL-Nachschlageeffizienz des SOC 10 steigert.
  • Die Tabellenverwaltung kann auch durch die Verwendung der CPU 52 erzielt werden. Die CPU 52 kann über den CMIC 40 dem SOC 10 Softwarefunktionen bereitstellen, die zu der Benennung der Identifikation eines Benutzers an einem gegebenen Port 24 führen. Aber wie oben diskutiert worden ist, ist es nicht erwünscht, dass die CPU 52 kontinuierlich auf die Paketinformation in ihrer Gesamtheit zugreift, da dies zu einer Leistungsverschlechterung führen würde. Statt dessen wird der SOC 10 im Allgemeinen von der CPU 52 mit Identifikationsinformationen, die den Benutzer betreffen, programmiert. Danach kann der SOC 10 einen Echtzeitdatenfluss aufrechterhalten, da die Tabellendatenkommunikation zwischen der CPU 52 und dem SOC 10 ausschließlich in dem S-Kanal 83 auftritt. Obwohl der SOC 10 der CPU 52 direkte Paketinformationen über den C-Kanal 81 bereitstellen kann, ist ein solcher System-Setup aus den Gründen unerwünscht, die oben erläutert worden sind. Wie oben angegeben worden ist, wird als eine Eintrittsfunktion ein Adressauflösungs-Nachschlagevorgang durchgeführt, indem die ARL-Tabelle 21a überprüft wird. Wenn das Paket für eine der Schicht-3-(L3-)Switches des SOC 10 bestimmt ist, dann führt das Eintrittssubmodul 14a die L3- und Standardtabellen-Nachschlagevorgänge durch. Wenn der Zielport ermittelt worden ist, setzt der EPIC 20a ein Bereit-Flag in der Zuteilungseinheit 18a, die dann eine Arbitrierung für den C-Kanal 81 durchführt.
  • Wenn alle E/A-Module, einschließlich der MMU 70, den Zugriff auf den C-Kanal 81 anfordern, wird der MMU 70 der Zugriff gewährt, wie dies in 4B gezeigt ist, da die MMU einen kritischen Datenpfad für alle Module auf dem Switch bereitstellt. Beim Erhalt des Zugriffs zu dem Kanal 81 fährt die Zuteilungseinheit 18a (9) damit fort, das empfangene Paket 112 zu dem C-Kanal 81 weiterzuleiten, und zwar jeweils eine Zelle zur gleichen Zeit.
  • Unter erneuter Bezugnahme auf 3 sind die einzelnen C-, P- und S-Kanäle des CPS-Kanals 80 gezeigt. Wenn die Zuteilungseinheit 18a die Erlaubnis erhalten hat, auf den CPS-Kanal 80 zuzugreifen, platziert die Zuteilungseinheit 18a während des ersten Zeitraums Cn0 die ersten 16 Bytes der ersten Zelle 112a des empfangenen Pakets 112 in dem C-Kanal 81. Gleichzeitig platziert die Zuteilungseinheit 18a die erste P-Kanal-Nachricht, die der augenblicklich übertragenen Zelle entspricht. Wie oben angemerkt worden ist, definiert die erste P-Kanal-Nachricht – neben anderen Dingen – den Nachrichtentyp. Deshalb ist dieses Beispiel derart, dass die erste P-Kanal-Nachricht die aktuelle Zelle so definieren würde, dass sie ein Unicast-Nachrichtentyp ist, der zu dem Ziel-Austrittsport 21c geleitet werden soll.
  • Während des zweiten Taktzyklus Cn1 werden die zweiten 16 Bytes (16:31) der augenblicklich übertragenen Datenzelle 112a in dem C-Kanal 81 platziert. In ähnlicher Weise wird während des zweiten Taktzyklus Cn1 die Bc/Mc Port-Bitmap in dem P-Kanal 82 platziert.
  • Wie von der Veranschaulichung der S-Kanal-83-Daten während der Zeiträume Cn0 bis Cn3 in 3 angegeben wird, ist die Operation des S-Kanals 83 von der Operation des C-Kanals 81 und des P-Kanals 82 abgekoppelt. Zum Beispiel kann die CPU 52 über den CMIC 40 Systemebenennachrichten zu nichtaktiven Modulen weiterleiten, während ein aktives Modul Zellen in dem C-Kanal 81 weiterleitet. Wie vorher angegeben worden ist, ist dies ein wichtiger Aspekt des SOC 10, da die S-Kanal-Operation eine parallele Aufgabenverarbeitung erlaubt, wodurch die Übertragung von Zellendaten in dem C-Kanal 81 in Echtzeit erlaubt wird. Wenn die erste Zelle 112a des ankommenden Pakets 112 in dem CPS-Kanal 80 platziert ist, ermittelt die MMU 70, ob die Zelle zu einem Austrittsport 21 übertragen werden soll, der sich lokal auf dem SOC 10 befindet.
  • Wenn die MMU 70 feststellt, dass die aktuelle Zelle 112a in dem C-Kanal 81 für einen Austrittsport des SOC 10 bestimmt ist, übernimmt die MMU 70 die Kontrolle des Zelldatenflusses.
  • 10 veranschaulicht in einer ausführlicheren Art und Weise die funktionellen Austrittsaspekte der MMU 70. Die MMU 70 umfasst den CBM 71 und ist zwischen dem GBP 60, dem CBP 50 und einer Vielzahl von Austrittsmanagern (EgM) 76 des Austrittssubmoduls 18 angeschlossen, wobei ein Austrittsmanager 76 für jeden Austrittsport bereitgestellt ist. Der CBM 71 ist mit jedem Austrittsmanager 76 in einer parallelen Konfiguration über den R-Kanal-Datenbus 77 verbunden. Der R-Kanal-Datenbus 77 ist ein 32 Bit breiter Bus, der von dem CBM 71 und den Austrittsmanagern 76 bei der Übertragung von Speicherzeigern und Systemnachrichten verwendet wird. Jeder Austrittsmanager 76 ist auch mit dem CPS-Kanal 80 für den Transfer von Datenzellen 112a und 112 verbunden.
  • Der CBM 71 führt zusammengefasst die Funktionen einer On-Chip-FAP-Verwaltung (Verwaltung des Pools freier Adressen auf dem Chip), den Transfer von Zellen zu dem CBP 50, die Paketassemblierung und die Meldung an die jeweiligen Austrittsmanager, das Umleiten von Paketen zu dem GBP 60 über einen globalen Pufferspeichermanager sowie auch die Handhabung des Paketflusses von dem GBP 60 zu dem CBP 50 durch. Der Speicher-Clean-Up, die Speicherbudgetverwaltung, die Kanalschnittstelle und die Zellenzeigerzuweisung sind ebenfalls Funktionen des CBM 71. Im Hinblick auf den Pool freier Adressen verwaltet der CBM 71 den Pool freier Adressen und weist den ankommenden Zellen freie Zellenzeiger zu. Der Pool freier Adressen wird von dem CBM 71 auch zurückgeschrieben, so dass die freigegebenen Zellenzeiger von verschiedenen Austrittsmanagern 76 in geeigneter Weise gelöscht werden. Unter der Annahme, dass es genug Platz gibt, der in dem CBP 50 zur Verfügung steht, und dass genügend freie Adresszeiger zur Verfügung stehen, verwaltet der CBM 71 wenigstens zwei Zellenzeiger pro Austrittsmanager 76, der gemanagt wird. Die erste Zelle eines Pakets kommt bei einem Austrittsmanager 76 an, und der CBM 71 schreibt diese Zelle in die CBM-Speicherzuweisung bei der Adresse, auf die von dem ersten Zeiger gezeigt wird. In dem nächsten Zell-Header-Feld ist der zweite Zeiger geschrieben. Das Format der Zelle, wie sie im CBP 50 gespeichert ist, ist in 11 gezeigt; jede Zeile weist eine Breite von 18 Bytes auf. Die Zeile 0 enthält geeignete Informationen bezüglich der Informationen der ersten Zelle und der letzten Zelle, Broadcast/Multicast, der Anzahl an Austrittsports für Broadcast oder Multicast, der Zellenlänge in bezug auf die Anzahl an gültigen Bytes in der Zelle, des nächsten Zellenzeigers, der Gesamtzellenzählung in dem Paket und eines Zeitstempels. Die restlichen Zeilen enthalten Zellendaten als 64-Byte-Zellen. Der Pool freier Adressen in der MMU 70 speichert alle freien Zeiger für den CBP 50. Jeder Zeiger in dem Pool freier Adressen zeigt zu einer 64-Byte-Zelle in dem CBP 50; die aktuelle Zelle, die in dem CBP gespeichert ist, beträgt insgesamt 72 Bytes, wobei 64 Bytes Byte-Daten und 8 Bytes Steuerinformationen sind. Funktionen wie hohe und niedrige HOL-Blockierungs-Pegel, Ausgabe-Warteschlangen-Budgetregister, die CPID-Zuweisung und andere Funktionen werden in dem CBM 71 gehandhabt, wie dies hier erläutert wird.
  • Wenn die MMU 70 feststellt, dass die Zelle 112a für einen entsprechenden Austrittsport in dem SOC 10 bestimmt ist, steuert die MMU 70 den Zellenfluss von dem CPS-Kanal 80 zu dem CBP 50. Wenn das Datenpaket 112 bei der MMU 70 von dem CPS 80 empfangen wird, ermittelt der CBM 71, ob ausreichend Speicher in dem CBP 50 für das Datenpaket 112 vorhanden ist oder nicht. Ein Pool freier Adressen (nicht gezeigt) kann eine Speicherung für wenigstens zwei Zellenzeiger pro Austrittsmanager 76 pro Serviceklasse bereitstellen. Wenn ausreichend Speicher in dem CBP 50 für die Speicherung und Identifikation des ankommenden Datenpakets zur Verfügung steht, platziert der CBM 71 die Datenzelleninformationen in dem CPS-Kanal 80. Die Datenzelleninformationen werden dem CBP 50 von dem CBM 71 an der zugewiesenen Adresse bereitgestellt. Wenn neue Zellen bei der MMU 70 empfangen werden, weist der CBM 71 Zellenzeiger zu. Der anfängliche Zeiger für die erste Zelle 112a zeigt zu dem Austrittsmanager 76, der dem Austrittsport entspricht, zu dem das Datenpaket 112 gesendet werden wird, nachdem es in dem Speicher platziert worden ist. In dem Beispiel von 8 kommen Pakete bei dem Port 24a des EPIC 20a herein und sind für den Port 24c des EPIC 20c bestimmt. Für jede weitere Zelle 112b weist der CBM 71 einen entsprechenden Zeiger zu. Dieser entsprechende Zellenzeiger wird als ein NC_Header mit einem Wert von zwei Bytes oder 16 Bits an einer geeigneten Stelle in einer Steuernachricht mit dem ersten Zeiger für den entsprechenden Austrittsmanager 76 und nachfolgenden Zellenzeigern als ein Teil jedes Zell-Headers gespeichert, eine Verbundliste von Speicherzeigern wird gebildet, die das Paket 112 definiert, wenn das Paket über den entsprechenden Austrittsport, der in diesem Fall 24c ist, übertragen wird. Wenn das Paket vollständig in den CBP 50 geschrieben ist, wird dem entsprechenden Austrittsmanager 76 ein entsprechender CBP-Paketidentifizierer (CPID) bereitgestellt; dieser CPID zeigt zu der Speicherstelle der ersten Zelle 112a. Der CPID für das Datenpaket wird dann verwendet, wenn das Datenpaket 112 zu dem Zielaustrittsport 24c geschickt wird. Tatsächlich verwaltet der CBM 71 zwei Pufferspeicher, die einen CBP-Zellenzeiger enthalten, wobei der Zugang zu dem CBP auf einer Anzahl von Faktoren basiert. Ein Beispiel einer Zugangs- bzw. Zulassungslogik für den CBP 50 wird unten unter Bezugnahme auf 12 erörtert werden.
  • Da der CBM 71 den Datenfluss innerhalb des SOC 10 steuert, kann der Datenfluss, der mit jeglichem Eintrittsport assoziiert ist, in ähnlicher Weise gesteuert werden. Wenn das Paket 112 empfangen und in dem CBP 50 gespeichert worden ist, wird dem assoziierten Austrittsmanager 76 ein CPID bereitgestellt. Die gesamte Anzahl an Datenzellen, die mit dem Datenpaket assoziiert ist, wird in einem Budgetregister (nicht gezeigt) gespeichert. Wenn mehr Datenpakete 112 empfangen werden und dafür bestimmt sind, zu dem gleichen Austrittsmanager 76 gesendet zu werden, wird der Wert des Budgetregisters, das dem assoziierten Austrittsmanager 76 entspricht, mit der Anzahl an Datenzellen 112a, 112b der empfangenen neuen Datenzellen inkrementiert. Das Budgetregister stellt deshalb dynamisch die gesamte Anzahl an Zellen dar, die durch einen speziellen Austrittsport in einem EPIC 20 gesendet werden sollen. Der CBM 71 steuert das Hereinströmen von zusätzlichen Datenpaketen durch das Vergleichen des Budgetregisters mit einem Registerwert eines hohen Pegels (high watermark) oder einem Registerwert eines niedrigen Pegels (low watermark) für den gleichen Austritt.
  • Wenn der Wert des Budgetregisters den hohen Pegelwert überschreitet, wird der assoziierte Eintrittsport deaktiviert. In ähnlicher Weise wird dann, wenn die Datenzellen eines Austrittsmanagers 76 über den Austrittsport gesendet werden und das entsprechende Budgetregister auf einen Wert unterhalb des unteren Pegelwerts sinkt, der Eintrittsport wieder aktiviert. Wenn der Austrittsmanager 76 die Übertragung des Pakets 112 initiiert, meldet der Austrittsmanager 76 dies dem CBM 71, der dann den Budgetregisterwert um die Anzahl an Datenzellen, die übertragen werden, dekrementiert. Die speziellen hohen Pegelwerte und niedrigen Pegelwerte können von dem Benutzer über die CPU 52 programmiert werden. Dies gibt dem Benutzer die Kontrolle über den Datenfluss jedes Ports in jedem EPIC 20 oder GPIC 30 und des IPIC 90.
  • Der Austrittsmanager 76 ist auch in der Lage, den Datenfluss zu steuern. Jeder Austrittsmanager 76 ist mit der Fähigkeit versehen, Paketidentifikationsinformationen in einem Paketzeiger-Budgetregister zu verfolgen; wenn ein neuer Zeiger von dem Austrittsmanager 76 empfangen wird, wird das assoziierte Paketzeiger-Budgetregister inkrementiert. Wenn der Austrittsmanager 76 ein Datenpaket 112 hinaussendet, wird das Paketzeiger-Budgetregister dekrementiert. Wenn ein Speicherungs-Limit erreicht wird, das dem Register zugewiesen ist, was einem vollen Paketidentifikationspool entspricht, wird eine Benachrichtigungsnachricht zu allen Eintrittsports des SOC 10 gesendet, die anzeigt, dass der Zielaustrittsport, der von diesem Austrittsmanager 76 gesteuert wird, nicht zur Verfügung steht. Wenn das Paketzeiger-Budgetregister unter den hohen Paketpool-Pegelwert dekrementiert wird, wird eine Benachrichtigungsnachricht gesendet, dass der Zielaustrittsport nun zur Verfügung steht. Die Benachrichtigungsnachrichten werden von dem CBM 71 auf dem S-Kanal 83 gesendet.
  • Wie vorher angemerkt worden ist, kann die Flusskontrolle von dem CBM 71 und auch von dem Eintrittssubmodul 14 entweder des EPIC 20, des GPIC 30 oder von dem IPIC 90 bereitgestellt werden. Das Eintrittssubmodul 14 überwacht die Zellenübertragung in den Port 24. Wenn ein Datenpaket 112 an einem Port 24 empfangen wird, inkrementiert das Eintrittssubmodul 14 ein Empfangs-Budgetregister um die Zellenzählung des ankommenden Datenpakets. Wenn ein Datenpaket 112 gesendet wird, dekrementiert der entsprechende Eintritt 14 das Empfangs-Budgetregister um die Zellenzählung des abgehenden Datenpakets 112. Das Budgetregister 72 wird im Ansprechen auf eine Dekrementier-Zellenzählungs-Nachricht, die von dem CBM 71 initiiert wird, wenn ein Datenpaket 112 aus dem CBP 50 erfolgreich übertragen wird, von dem Eintritt 14 dekrementiert.
  • Die effiziente Handhabung des CBP 50 und des GBP 60 ist notwendig, um den Durchsatz zu maximieren, das Portverhungern zu verhindern und einen Port-Underrun zu verhindern. Für jeden Eintritt gibt es einen niedrigen Pegel und einen hohen Pegel; wenn die Zellenzählung unterhalb des niedrigen Pegels liegt, wird das Paket zu dem CBP zugelassen, wodurch das Portverhungern verhindert wird, indem der Port einen geeigneten Anteil von dem CBP-Platz erhält.
  • 12 veranschaulicht allgemein die Handhabung eines Datenpakets 112, wenn es an einem zugehörigen Eintrittsport empfangen wird. Diese Figur veranschaulicht die dynamische Speicherzuweisung an einem einzigen Port und ist auf jeden Eintrittsport des SOC 10 anwendbar. In dem Schritt 12-1 wird die Länge des ankommenden Pakets durch das Schätzen der Zellenzählung auf der Grundlage der Austrittsmanagerzählung plus der Zählung der ankommenden Zellen geschätzt. Nachdem diese Zellenzählung geschätzt ist, wird die aktuelle Zellenzählung des GBP 60 bei Schritt 12-2 überprüft, um festzustellen, ob der GBP 60 leer ist oder nicht. Wenn die Zellenzählung des GBP 0 ist, wodurch angezeigt wird, dass der GBP 60 leer ist, schreitet das Verfahren zu Schritt 12-3 fort, bei dem festgestellt wird, ob die geschätzte Zellenzählung von Schritt 12-1 kleiner als der niedrige Zulassungspegel des CBP 50 ist oder nicht. Der niedrige Zulassungspegelwert ermöglicht den Empfang neuer Datenpakete 112 in dem CBP 50, wenn die gesamte Anzahl an Zellen in dem assoziierten Austritt unterhalb des niedrigen Zulassungspegelwerts liegt. Wenn die Zellenzählung kleiner als der niedrige Zulassungspegel des CBP 50 ist, dann wird das Paket bei Schritt 12-5 in den CBP 50 zugelassen. Wenn die geschätzte Zellenzählung nicht unterhalb des niedrigen Zulassungspegels liegt, dann muss der CBM 71 eine Arbitrierung für die CBP-Speicherzuordnung mit anderen Eintrittsports anderer EPICs und GPICs im Schritt 12-4 durchführen. Wenn der Arbitrierungsprozess nicht erfolgreich ist, dann wird das ankommende Paket zu einem Umleitprozess gesendet, der in 12 als A bezeichnet wird, der das Paket zu dem GBP 60 umsteuert. Alternativ dazu wird, wenn die Arbitrierung erfolgreich ist, das Paket bei Schritt 12-5 zu dem CBP 50 zugelassen. Die Zulassung des Pakets 112 zu dem CBP 50 wird bevorzugt, um die Leitungsgeschwindigkeitskommunikation zu ermöglichen.
  • Die obige Diskussion ist auf die Situation gerichtet, in der die GBP-Zellenzählung als 0 festgestellt wird, was einen leeren externen Speicher repräsentiert. Wenn in dem Schritt 12-2 die GBP-Zellenzählung so bestimmt wird, dass sie nicht 0 ist, dann schreitet das Verfahren zu Schritt 12-6 fort, bei dem die geschätzte Zellenzählung, die in Schritt 12-1 ermittelt worden ist, mit dem hohen Zulassungspegel des CBP 50 verglichen wird. Wenn die geschätzte Zellenzählung größer als der hohe Zulassungspegel des CBP 50 ist, dann wird das Paket bei Schritt 12-7 zu dem GBP 60 umgeleitet. Wenn die geschätzte Zellenzählung kleiner als der hohe Zulassungspegel ist, dann wird die geschätzte Zellenzählung im Schritt 12-8 mit dem niedrigen Zulassungspegel des CBP 50 verglichen. Wenn festgestellt wird, dass die geschätzte Zellenzählung größer als der niedrige Zulassungspegel ist, was bedeutet, dass die geschätzte Zellenzählung zwischen dem hohen Pegel und dem niedrigen Pegel liegt, wird das Paket bei Schritt 12-7 zu dem GBP 60 umgesteuert. Wenn die geschätzte Zellenzählung unterhalb des niedrigen Zulassungspegels liegt, dann wird die aktuelle GBP-Zählung bei Schritt 12-9 mit einem Umsteuerungs-Zellen-Limit-Wert verglichen. Dieser Umsteuerungs-Zellen-Limit-Wert kann von dem Benutzer durch die CPU 52 programmiert werden. Wenn die GBP-Zählung bei Schritt 12-9 kleiner oder gleich dem Umsteuerungs-Zellen-Limit-Wert ist, dann wird die geschätzte Zellenzählung und die GBP-Zählung mit einem geschätzten niedrigen Zellenzählungs-Pegel verglichen. Wenn die Kombination aus geschätzter Zellenzählung und GBP-Zählung kleiner als der geschätzte niedrige Zellenzählungs-Pegel ist, dann wird das Paket bei Schritt 12-5 zu dem CBP 50 zugelassen. Wenn die Summe größer als der geschätzte niedrige Zellenzählungs-Pegel ist, dann wird das Paket bei dem Schritt 12-7 zu dem GBP 60 umgeleitet. Nach dem Umsteuern zu dem GBP 60 wird die GBP-Zellenzählung aktualisiert und die Paketverarbeitung wird beendet. Es sollte angemerkt werden, dass dann, wenn sowohl der CBP 50 als auch der GBP 60 voll sind, das Paket fallengelassen wird. Fallengelassene Pakete werden in Übereinstimmung mit den bekannten Ethernet-Vorgängen oder Netzwerkkommunikationsvorgängen behandelt und bewirken eine Verzögerung der Kommunikation. Aber diese Konfiguration legt durch das Setzen der Pegel durch die CPU 52 auf geeignete Pufferspeicherwerte auf einer pro Port Basis zur Maximierung der Speicherausnutzung und zur Minimierung des Fallenlassens von Paketen einen geeigneten Gegendruck an. Diese CBP-/GBP-Zulassungslogik führt zu einer verteilten, hierarchischen, gemeinsam genutzten Speicherkonfiguration mit einer Hierarchie zwischen dem CBP 50 und dem GBP 60 und Hierarchien innerhalb des CBP 50.
  • Wenn das Paket 112, das oben im Hinblick auf 12 erörtert worden ist, für den IPIC bestimmt ist und deshalb aus der Hochleistungsverbindung hinaus gesendet werden soll, dann wird das Paket sofort zu dem IPIC-Modul geschaltet und muß nicht entweder zu dem CBP 50 oder zu dem GBP 60 zugelassen werden. Nachdem festgestellt worden ist, dass die Zieladresse mit dem IPIC assoziiert ist, wird das Paket in den C-Kanal 81 platziert, wie dies in 8 veranschaulicht ist, und wird von dem IPIC 90 "aufgepickt", bei dem es in den NBP 92 platziert wird. Nachdem die Zieladresse für Zielorte gelernt worden ist, die sich in dem IPIC 90 befinden, wird ein Paket, das bei dem Port 24 hereinkommt und für einen Port in dem IPIC 90 bestimmt ist, in Zellen geschnitten und in dem CPS-Kanal 80 platziert und ist direkt für den NBP 92 des IPIC 90 bestimmt. Die Zellen, die mit diesem Paket assoziiert sind, werden nicht von der MMU 70 abgewickelt und unterliegen deshalb nicht der oben erläuterten CBP-/GBP-Zulassungslogik. Wenn die Zieladresse aber nicht gelernt bzw. erfahren worden ist, dann wird das Paket zu allen Ports durch die CBP-/GBP-Zulassungslogik und auch durch den NBP 92 gesendet. Eine ausführlichere Erörterung des NBP 92 und des IPIC 90 wird an späterer Stelle zu finden sein.
  • Adressauflösung (L2) + (L3)
  • 14 veranschaulicht einige der im gleichen Zeitintervall ablaufenden Filterungs- und Nachschlagevorgangseinzelheiten eines Pakets, das bei dem Eintritt eines EPIC 20 hereinkommt. 12 veranschaulicht, wie dies vorher erörtert worden ist, die Handhabung eines Datenpakets im Hinblick auf die Zulassung zu dem verteilten, hierarchischen, gemeinsam genutzten Speicher. 14 betrifft die An wendung der Filterung, die Flussüberwachung, die Adressauflösung und die Regelanwendungssegmente des SOC 10. Diese Funktionen werden im Hinblick auf die Zulassung zu dem CBP 50 und zu dem GBP 60, die oben erörtert worden ist, gleichzeitig durchgeführt. Wie in der Figur gezeigt ist, wird das Paket 112 an einem Eintrittsport 24 des EPIC 20 empfangen und wird dann zu einem Eintritts-FIFO 142 geleitet. Sobald die ersten sechzehn Bytes des Datenpakets in dem Eintritts-FIFO 142 ankommen, wird eine Adressauflösungsanforderung zu der ARL-Maschine 143 gesendet, die einen Adressnachschlagevorgang in den ARL-/L3-Tabellen 21 initiiert.
  • Eine Beschreibung der Felder in den ARL-/L3-Tabellen 21 lautet folgendermaßen:
    • Mac Address – 48 Bits lang – MAC-Adresse;
    • VLAN tag – 12 Bits lang – VLAN-Tag-Identifzierer, wie er in dem IEEE 802.1q Standard für mit Tags versehene Pakete beschrieben ist. Für Pakete ohne Tags wird dieser Wert aus der portbasierten VLAN-Tabelle abgerufen.
    • CosDst – 3 Bits lang – Serviceklasse auf der Grundlage der Zieladresse. COS (Class of Service) identifiziert die Priorität dieses Pakets. 8 Prioritätsebenen, wie sie in dem IEEE 802.1p Standard beschrieben sind.
    • Port Number – 6 Bits lang – Die Port Number (Portnummer) ist der Port, an dem diese MAC-Adresse gelernt wird.
    • SD_Disc Bits – 2 Bits lang – Diese Bits identifizieren, ob das Paket auf der Grundlage der Quelladresse oder der Zieladresse verworfen werden soll. Der Wert 1 bedeutet, Verwerfen auf der Grundlage der Quelle. Der Wert 2 bedeutet, Verwerfen auf der Grundlage des Ziels.
    • C bit – 1 Bit lang – Das C Bit identifiziert, dass das Paket zu dem CPU-Port gegeben werden soll.
    • St Bit – 1 Bit lang – Das St Bit identifiziert, dass dieses ein statischer Eintrag ist (er wird nicht dynamisch gelernt), und dies bedeutet, dass er nicht herausgealtert werden soll. Nur die CPU 52 kann diesen Eintrag löschen.
    • Ht Bit – 1 Bit lang – Das Hit Bit (Treffer-Bit) – Dieses Bit wird gesetzt, wenn eine Übereinstimmung mit der Quelladresse vorliegt. Es wird in dem Alterungsmechanismus verwendet.
    • CosSrc – 3 Bits lang – Serviceklasse auf der Grundlage der Quelladresse. Die COS identifiziert die Priorität dieses Pakets.
    • L3 Bit – 1 Bit lang – L3 Bit – dieses Bit identifiziert, dass dieser Eintrag als ein Ergebnis der L3-Schnittstellenkonfiguration geschaffen worden ist, die MAC-Adresse in diesem Eintrag eine L3-Schnittstellen-MAC-Adresse ist, und dass jedes Paket, das für diese MAC-Adresse bestimmt ist, geroutet werden muß.
    • T Bit – 1 Bit lang – Das T Bit identifiziert, dass diese MAC-Adresse von einem der Trunk Ports gelernt wird. Wenn es eine Übereinstimmung bei der Zieladresse gibt, dann wird der Austrittsport nicht aus der Portnummer in diesem Eintrag bestimmt, sondern wird durch den Trunk-Identifikationsprozess auf der Grundlage von Regeln entschieden, die von den RTAG Bits und der Trunk Group, die von dem TGID identifiziert wird, identifiziert werden.
    • TGID – 3 Bits lang – TGID identifiziert das Leitungsbündel bzw. die Trunk Group, wenn das T Bit gesetzt ist. Der SOC 10 unterstützt 6 Trunk Groups pro Switch.
    • RTAG – 3 Bits lang – RTAG identifiziert das Trunk-Auswahlkriterium, wenn die Zieladresse mit diesem Eintrag übereinstimmt und das T Bit in diesem Eintrag gesetzt ist. Wert 1 – basierend auf der Quell-MAC-Adresse. Wert 2 – basierend auf der Ziel-MAC-Adresse. Wert 3 – basierend auf der Quell- & Zieladresse. Wert 4 – basierend auf der Quell-IP-Adresse. Wert 5 – basierend auf der Ziel-IP-Adresse. Wert 6 – basierend auf der Quell- und Ziel-IP-Adresse.
    • S C P – 1 Bit lang – Source CoS Priority Bit (Quell-CoS-Prioritäts-Bit) – Wenn dieses Bit gesetzt ist (in dem übereinstimmenden Quell-MAC-Eintrag), dann hat die Quell-CoS Priorität vor der Ziel-CoS.
    • Module ID – 5 Bits lang – Die Modul-ID identifiziert das Modul, in dem diese MAC-Adresse gelernt wird.
  • Der SOC 10 umfasst auch eine Multicast-Tabelle für die geeignete Handhabung von Multicast-Paketen. Eine Konfiguration der Multicast-Tabelle würde 256 Bits tief und 128 Bits breit sein. Die Suchfelder der Multicast-Tabelle könnten in einem Ausführungsbeispiel folgendermaßen lauten:
    • Mac Address – 48 Bits lang – die MAC-Adresse.
    • VLAN Tag – 12 Bits lang – der VLAN-Tag-Identifizierer, wie er in dem IEEE 802.1q Standard beschrieben ist.
    • CosDst – 3 Bits lang – Serviceklasse auf der Grundlage der Zieladresse. Die COS identifiziert die Priorität dieses Pakets. Wir unterstützen 8 Prioritätsebenen, wie diese in dem IEEE 802.1p Standard beschrieben sind.
    • Mc Port Bitmap – 31 Bits lang – Die Port-Bitmap identifiziert alle Austrittsports, auf denen das Paket hinausgehen soll.
    • Untagged Bitmap – 31 Bits lang – Diese Bitmap identifiziert die nicht mit einem Tag versehenen Elemente (untagged elements) des VLAN, d.h., wenn der Rahmen, der zum Heraussenden aus diesen Elementeports bestimmt ist, ohne einen Tag-Header übertragen werden soll.
    • Module Id Bitmap – 32 Bits lang – Die Modul-Id-Bitmap identifiziert alle Module, zu denen die Pakete gehen sollen.
  • Es sollte auch angemerkt werden, dass die VLAN-Tabellen 23 eine Anzahl von Tabellenformaten umfassen; alle diese Tabellen und Tabellenformate werden hier nicht erörtert werden. Aber als ein Beispiel werden die portbasierten VLAN-Tabellenfelder wie folgt beschrieben:
    • Port VLAND Id – 12 Bits lang – Der Port-VLAN-Identifizierert ist die VLAN-Id, die von dem portbasierten VLAN benutzt wird.
    • Sp State – 2 Bits lang – Dieses Feld identifiziert den aktuellen Spannbaumzustand. Wert 0×00 – Der Port befindet sich in einem inaktiven Zustand. In diesem Zustand werden keine Pakete akzeptiert, nicht einmal BPDUs. Wert 0×01 – Der Port befindet sich in einem Blockierungs- oder Mithörzustand. In diesem Zustand werden von dem Port keine Pakete akzeptiert, außer BPDUs. Wert 0×02 – Der Port befindet sich in einem Lernzustand. In diesem Zustand werden die Paket nicht zu einem anderen Port weitergeleitet, werden aber zum Lernen akzeptiert. Wert 0×03 – Der Port befindet sich in einem Weiterleitzustand. In diesem Zustand werden die Pakete sowohl zum Lernen als auch zum Weiterleiten akzeptiert.
    • Port Discard Bits – 6 Bits lang – Es gibt 6 Bits in diesem Feld, und jedes Bit identifiziert das Kriterium zum Verwerfen der Pakete, die bei diesem Port hereinkommen. Merke: Die Bits 0 bis 3 werden nicht benutzt. Bit 4 – Wenn dieses Bit gesetzt ist, dann werden alle Rahmen, die bei diesem Port hereinkommen, verworfen. Bit 5 – Wenn dieses Bit gesetzt ist, dann wird jeder 802.1 q Rahmen mit Prioritäts-Tag (vid = 0) und ohne Tag, der bei diesem Port ankommt, verworfen.
    • J Bit – 1 Bit lang – Das J Bit bedeutet Jumbo-Bit. Wenn dieses Bit gesetzt ist, dann sollte dieser Port Jumbo-Frames akzeptieren.
    • RTAG – 3 Bits lang – Das RTAG identifiziert das Trunk-Auswahlkriterium, wenn die Zieladresse mit diesem Eintrag übereinstimmt und das T Bit in diesem Eintrag gesetzt ist. Wert 1 – basierend auf der Quell-MAC-Adresse. Wert 2 – basierend auf der Ziel-MAC-Adresse. Wert 3 – basierend auf der Quell- und Zieladresse. Wert 4 – basierend auf der Quell-IP-Adresse. Wert 5 – basierend auf der Ziel-IP-Adresse. Wert 6 – basierend auf der Quell- und Ziel-IP-Adresse.
    • T Bit – 1 Bit lang – Dieses Bit identifiziert, dass der Port ein Element der Trunk Group ist.
    • C Learn Bit – 1 Bit lang – Das CPU-Lern-Bit – Wenn dieses Bit gesetzt ist, dann wird das Paket zu der CPU gesendet, wann immer die Quelladresse gelernt wird.
    • PT – 2 Bits lang – Der Port Type identifiziert den Typ des Ports. Wert 0 – 10 Mbit-Port. Wert 1 – 100 Mbit-Port. Wert 2 – 1 Gbit-Port. Wert 3 – CPU-Port.
    • VLAN Port Bitmap – 28 Bits lang – Die VLAN-Port-Bitmap identifiziert alle Austrittsports, auf denen das Paket hinausgehen soll.
    • B Bit – 1 Bit lang – Das B-Bit ist das BPDU-Bit. Wenn dieses Bit gesetzt ist, dann weist der Port die BPDUs zurück. Dieses Bit wird für die Trunk Ports gesetzt, von denen nicht erwartet wird, dass sie die BPDUs akzeptieren.
    • TGID – 3 Bits lang – TGID – Dieses Feld identifiziert die Trunk Group, zu der dieser Port gehört.
    • Untagged Bitmap – 28 Bits lang – Diese Bitmap identifiziert die Elemente des VLAN ohne Tags, d.h. wenn der Rahmen, der dafür bestimmt ist, aus diesen Elementeports hinaus zu gehen, ohne einen Tag-Header übertragen werden soll.
    • M Bits – 1 Bit lang – das M Bit wird für die Spiegelungsfunktionalität verwendet. Wenn dieses Bit gesetzt ist, dann ist das Spiegeln an dem Eintritt aktiviert.
  • Der SOC 10 kann auch eine Vielzahl von 802.1Q VLAN-Tabellen mit Tags umfassen, die dazu verwendet werden können, alle Elementeports der explizit mit einem Tag versehenen VLANs zu bekommen. Die Tabelle kann zum Beispiel 64 Einträge tief und 68 Bits breit sein. Die Felder könnten folgendermaßen lauten:
    • VLAN Tag – 12 Bits lang – Der VLAN-Tag-Identifizierer, wie er in dem IEEE 802.1q Standard beschrieben ist.
    • VLAN Port Bitmap – 28 Bits lang – Die VLAN-Port-Bitmap identifiziert alle Austrittsports, auf denen das Paket hinausgesendet werden soll.
    • Untagged Bitmap – 28 Bits lang – Diese Bitmap identifiziert die Elemente des VLAN ohne Tags. Deshalb identifiziert diese Bitmap, ob der Rahmen von diesen Elementeports mit oder ohne einen Tag-Header übertragen werden soll.
  • Unter Bezugnahme auf die Erörterung der Adressauflösung und auch unter Bezugnahme auf 14 liest die ARL-Maschine 143 das Paket; wenn das Paket ein VLAN-Tag gemäß dem IEEE Standard 802.1q aufweist, dann führt die ARL-Maschine 143 einen Nachschlagevorgang auf der Grundlage der mit Tags versehenen VLAN-Tabelle 231 durch, die Teil der VLAN-Tabelle 23 ist. Wenn das Paket dieses Tag nicht enthält, dann führt die ARL-Maschine den VLAN-Nachschlagevorgang auf der Grundlage der portbasierten VLAN-Tabelle 232 durch. Wenn das VLAN für das ankommende Paket identifiziert ist, führt die ARL-Maschine 143 eine ARL-Tabellendurchsuchung auf der Grundlage der Quell-MAC-Adresse und der Ziel-MAC-Adresse durch. Wenn das Ergebnis der Zieldurchsuchung eine L3-Schnittstellen-MAC-Adresse ist, dann wird eine L3-Durchsuchung einer L3-Tabelle innerhalb der ARL-/L3-Tabelle 21 durchgeführt. Wenn die L3-Durchsuchung erfolgreich ist, dann wird das Paket gemäß den Paket-Routing-Regeln modifiziert.
  • Zum besseren Verständnis der Nachschlagevorgänge, des Lernens und des Vermittelns kann es ratsam sein, noch einmal die Handhabung des Pakets 112 im Hinblick auf 8 zu erörtern. Wenn das Datenpaket 112 von einer Quellstation A in den Port 24a des EPIC 20a gesendet wird und für eine Zielstation B in dem Port 24c des EPIC 20c bestimmt ist, schneidet das Eintrittssubmodul 14a das Datenpaket 112 in Zellen 112a und 112b. Das Eintrittssubmodul liest dann das Paket, um die Quell-MAC-Adresse und die Ziel-MAC-Adresse zu ermitteln. Wie vorher erörtert worden ist, führt das Eintrittssubmodul 14a, vor allem die ARL-Maschine 143, den Nachschlagevorgang bei geeigneten Tabellen in den ARL-/L3-Tabellen 21a und der VLAN-Tabelle 23a durch, um zu sehen, ob die Ziel-MAC-Adresse in den ARL-/L3-Tabellen 21a existiert; wenn die Adresse nicht gefunden wird, aber die VLAN- INFORMATIONSOFFENLEGUNGSANWEISUNGEN für die Quelle und das Ziel gleich sind, dann wird das Eintrittssubmodul 14a das Paket so einstellen, dass es zu allen Ports in dem VLAN gesendet wird. Das Paket wird dann zu der zugehörigen Zieladresse fortschreiten. Eine "Quellen-Durchsuchung" und eine "Ziel-Durchsuchung" laufen parallel ab. Wenn die Quelladresse bei einem Quellennachschlagevorgang nicht gefunden wird, tritt ein Quellennachschlagevorgang-Fehlschlag (SLF, source lookup failure) auf. Bei dem Auftreten eines SLF wird die Quell-MAC-Adresse des ankommenden Pakets "gelernt" und deshalb zu einer ARL-Tabelle innerhalb der ARL-/L3-Tabellen 21a hinzugefügt. Nachdem das Paket von dem Ziel empfangen worden ist, wird von der Zielstation B eine Bestätigung zu der Quellstation A gesendet. Da die Quell-MAC-Adresse des ankommenden Pakets von der geeigneten Tabelle von B gelernt wird, wird die Bestätigung in geeigneter Weise zu dem Port gesendet, in dem sich A befindet. Die Zieladresse für das Bestätigungspaket oder die Bestätigungspakete ist bekannt, da sie vorher die Quelladresse war, die als ein Ergebnis des anfänglichen SLF gelernt worden ist. Wenn die Bestätigung bei dem Port 24a empfangen wird, lernt die ARL-Tabelle deshalb die Quell-MAC-Adresse von B aus dem Bestätigungspaket. Es sollte vermerkt werden, dass, solange die VLAN INFORMATIONSOFFENLEGUNGSANWEISUNGEN (für Pakete mit Tags) der Quell-MAC-Adressen und Ziel-MAC-Adressen gleich sind, eine Schicht-2-Vermittlung, wie sie oben erörtert worden ist, durchgeführt wird. Deshalb basiert die L2-Vermittlung und das L2-Nachschlagen auf den ersten 16 Bytes eines ankommenden Pakets. Für Pakete ohne Tags wird das Portnummernfeld in dem Paket für die portbasierte VLAN-Tabelle innerhalb der VLAN-Tabelle 23a indiziert, und die VLAN-ID kann dann ermittelt werden. Wenn die VLAN-INFORMATIONSOFFENLEGUNGSANWEISUNGEN aber unterschiedlich sind, wird das L3-Vermitteln notwendig, bei dem die Pakete zu einem anderen VLAN gesendet werden. Aber das L3-Vermitteln basiert auf dem IP-Header-Feld des Pakets. Der IP-Header umfasst die Quell-IP-Adresse, die Ziel-IP-Adresse und die TTL (time-to-live).
  • Wenn das Datenpaket 112 von einer Quellstation A in den Port 24a des EPIC 20a gesendet worden wäre und für den IPIC 90 bestimmt gewesen wäre, würde der gleiche Lernprozess beim Auftreten eines SLF und das gleiche Senden des Pakets zu allen Ports beim Auftreten eines DLF auftreten. Der IPIC 90 wird im Wesentlichen wie jeder andere Port auf dem SOC 10 behandelt, mit bemerkenswerten Ausnahmen im Hinblick auf die Existenz des NBP 92, wie oben erörtert worden ist und unten erörtert werden wird.
  • Um das Schicht-3-Switching auf dem SOC 10 noch besser zu verstehen, wird das Datenpaket 112 von der Quellstation A auf einen Port 24a des EPIC 20a gesendet und ist auf die Zielstation B gerichtet; es wird aber angenommen, dass sich die Station B auf einem anderen VLAN befindet, wie dies durch die Quell-MAC-Adresse und die Ziel-MAC-Adresse deutlich wird, die unterschiedliche VLAN INFORMATIONSOFFENLEGUNGSANWEISUNGEN aufweisen. Der Suchvorgang für B würde ohne Erfolg sein, da sich B auf einem anderen VLAN befindet, und das Senden des Pakets lediglich zu allen Ports in dem gleichen VLAN würde dazu führen, dass B das Paket niemals empfängt. Das Schicht-3-Switching ermöglicht daher das Überbrücken von VLAN-Grenzen, erfordert aber das Lesen von mehr Paketinformationen als nur die MAC-Adressen des L2-Switching. Zusätzlich zu dem Lesen der Quell- und Ziel-MAC-Adressen liest der Eintritt 14a deshalb auch die IP-Adresse der Quelle und des Ziels. Wie vorher angemerkt worden ist, werden die Pakettypen von dem IEEE-Standard und anderen Standards definiert und sind auf dem Fachgebiet bekannt. Durch das Lesen der IP-Adresse des Ziels ist der SOC 10 in der Lage, das Paket auf eine geeignete Routert-Schnittstelle abzuzielen, die konsistent mit der Ziel-IP-Adresse ist. Das Paket 112 wird deshalb durch die Zuteilungseinheit 18a in den CPS-Kanal 80 gesendet und ist für einen Port bestimmt, der mit einer geeigneten Routert-Schnittstelle (nicht gezeigt und kein Teil des SOC 10) verbunden ist und auf dem sich das Ziel B befindet. Steuerrahmen, die als solche durch ihre Zieladresse identifiziert werden, werden zu der CPU 52 über den CMIC 40 gesendet. Die Ziel-MAC-Adresse ist deshalb die Routert-MAC-Adresse für B. Die Routert-MAC-Adresse wird durch die Mithilfe der CPU 52 gelernt, die eine ARP-(Adressauflösungsprotokoll-)-Anforderung verwendet, um die Ziel-MAC-Adresse für den Routert für B anzufordern, und zwar auf der Grundlage der IP-Adresse von B. Durch die Verwendung der IP-Adresse kann der SOC 10 deshalb die MAC-Adresse lernen. Durch den Bestätigungs- und Lernprozess ist es aber nur das erste Paket, das dieser "langsamen" Behandlung aufgrund der Einbeziehung der CPU 52 unterworfen ist. Nachdem die geeigneten MAC-Adressen gelernt sind, kann ein Leitungsgeschwindigkeits-Switching durch die Verwendung von gleichzeitigen Tabellen-Nachschlagevorgängen auftreten, da die notwendigen Informationen von den Tabellen gelernt werden. Die Implementierung der Tabellen in Silizium als zweidimensionale Arrays ermöglicht solche schnellen, im gleichen Zeitintervall ablaufenden Nachschlagevorgänge. Wenn die MAC-Adresse für B gelernt worden ist, ändert der Eintritt 14a deshalb dann, wenn Pakete mit der IP-Adresse für B ankommen, die IP-Adresse auf die Ziel-MAC-Adresse, um das Leitungsgeschwindigkeits-Switching zu ermöglichen. Auch wird die Quelladresse des ankommenden Pakets auf die Routert-MAC-Adresse für A statt auf die IP-Adresse für A geändert, so das die Bestätigung von B zu A in einer schnellen Art und Weise abgewickelt werden kann, ohne dass eine CPU an dem Zielende benutzt werden muß, um die Quell-MAC-Adresse als das Ziel für die Bestätigung zu identifizieren. Außerdem wird ein TTL-(time-to-live)-Feld in dem Paket in geeigneter Weise gemäß dem IETF-(Internet Engineering Task Force)-Standard manipuliert. Ein einzigartiger Aspekt des SOC 10 ist, dass die Gesamtheit der Vermittlung, der Paketverarbeitung und der Tabellen-Nachschlagevorgänge in Hardware durchgeführt wird, anstatt dass man die CPU 52 oder eine andere CPU benötigt und Zeit für die Verarbeitung von Instruktionen vergeudet. Es sollte angemerkt werden, dass die Schicht-Drei-Tabellen für den EPIC 20 variierende Größen aufweisen können; in einem bevorzugten Ausführungsbeispiel sind diese Tabellen in der Lage, bis zu 2.000 Adressen zu verwalten und sind dem Löschen und Streichen von veralteten Adressen unterworfen, wie dies hier erläutert wird.
  • Wie vorher erwähnt worden ist, wird dann, wenn ein Datenpaket 112 den SOC 10 durch einen Port 24 betritt und zu dem Eintrittssubmodul 14 gesendet wird, ein Adress-Nachschlagevorgang in der ARL-/L3-Tabelle 21 durchgeführt, um festzustellen, ob diese Adresse bereits gelernt worden ist. Das Nachschlagen wird von einer Suchmaschine 210, wie sie in 38 gezeigt ist, in einer geeigneten Tabelle 21 logisch durchgeführt. Nachschlagevorgänge werden typischerweise durch die Tatsache ermöglicht, dass die Tabellen in einer sortierten Reihenfolge gespeichert sind, und Adressen werden unter Verwendung einer binären oder Gleichschritt-Typ-Durchsuchungsmethode (lockstep-type search method) gesucht.
  • Die vorliegende Erfindung umfasst ein Verfahren und eine Struktur zur Beschleunigung der Durchsuchungen in einer Adresstabelle 21 wie etwa einer Schicht-2-Tabelle. Unter Bezugnahme auf 39 ist eine ausführlichere An sicht einer beschleunigten Nachschlagekonfiguration im Hinblick auf die Ad resstabelle 21 und die Suchmaschine 210 offenbart. In einem Beispiel kann die Adresstabelle 21 eine einzelne sortierte 8K Tabelle sein, die von einer einzigen Suchmaschine 210 durchsucht wird. In dem beschleunigten Beispiel, das in 38 gezeigt ist, ist diese einzelne Adresstabelle 21 in zwei halbgroße Tabellen 211 und 212 aufgeteilt, wobei jede halbgroße Tabelle 4K Einträge aufweist. Die Tabelle kann aufgeteilt werden, indem die Adresstabelle 211 so ausgelegt wird, dass sie alle Einträge mit geradzahligen Adressen von der ursprünglichen Adresstabelle 21 enthält, und indem die Tabelle 212 alle ungeradzahligen Adresseinträge aus der ursprünglichen Adresstabelle 21 enthält. Durch das Aufteilen der ursprünglichen Adresstabelle 21 in zwei separate Tabellen auf der Grundlage des letzten Bits der Tabellenadresse bleibt jede der Tabellen 211 und 212 in einer sortierten Reihenfolge und enthält Einträge aus dem gesamten Adressbereich der ursprünglichen Tabelle 21. Die Suchmaschine 210 kann dann in zwei separate Suchmaschinen aufgeteilt werden, nämlich die erste Suchmaschine 213 und die zweite Suchmaschine 214, wie dies in 38 gezeigt ist, die so konfiguriert sind, dass sie gleichzeitige Adressnachschlagevorgänge für zwei Datenpakete durchführen können. In dem SOC 10 werden die Pakete für die Nachschlagevorgänge in Warteschlangen gestellt, da jedes EPIC-Modul 20 und/oder GPIC-Modul 30 eine Vielzahl von Ports aufweist. Zeitgleich ablaufende und/oder simultane Nachschlagevorgänge sind möglich, da der Durchsuchungsalgorithmus, der in dem SOC 10 implementiert ist, bis zu dem allerletzten Durchsuchungszyklus nicht zwischen geradzahlfgen und ungeradzahligen adressierten Einträgen unterscheidet. Diese Optimierung ermöglicht es deshalb, dass ein beträchtlicher Betrag an Durchsuchung für zwei separate Paketadressen gleichzeitig und parallel durchgeführt werden kann, wodurch der Durchsatz beinahe verdoppelt wird, selbst wenn sich die tatsächliche Zeit, die benötigt wird, um jeden einzelnen Suchvorgang vollständig durchzuführen, nicht ändert.
  • Deshalb werden die Quell- und Ziel-Adressnachschlagevorgänge dann, wenn zwei Pakete in ein EPIC-Modul 20 für den Adressnachschlagevorgan kommen, miteinander verwoben, wodurch die Ressourcen des SOC 10 für eine maximale Effizienz einem Zeitmultiplexing unterzogen werden. Die Verwendung von zwei Suchmaschinen 213 und 214 ermöglicht es den Suchmaschinen, in einer simultanen Art und Weise zu arbeiten, während sie die Tabellen 211 und 212 unter Verwendung von unterschiedlichen Suchschlüsseln durchsuchen. Nur der letzte Vergleich in der binären Suche wird zwischen geradzahligen und ungeradzahligen Adressen unterscheiden. Deshalb werden für eine 8K tiefe Adresstabelle 21, die in zwei 4K tiefe Tabellen 211 und 212 aufgeteilt worden ist, die ersten zwölf Suchzyklen für die ankommenden Paketadressen parallel durchgeführt, während der dreizehnte und letzte Suchzyklus, der nur durchgeführt wird, wenn die jeweilige Suchmaschine noch keine Übereinstimmung für eine gewünschte Adresse in der Adresstabelle gefunden hat, einen Zugriff auf die anderen Adresstabellen benötigt, um die gewünschte Adresse zu lokalisieren. Unter Bezugnahme auf 40a ist eine ursprüngliche ungeteilte Tabelle als 21 gezeigt. 40b veranschaulicht, wie in diesem Ausführungsbeispiel der Erfindung die Tabelle 21 in zwei Tabellen 211 und 212 geteilt wird, wobei die Tabelle 211 die geradzahligen Adressstellen enthält und die Tabelle 212 die ungeradzahligen Adressstellen enthält, wobei beide aber in einer sortierten Reihenfolge bleiben.
  • Als ein erstes Beispiel der Operation dieses Ausführungsbeispiels wird angenommen, dass ein erstes Datenpaket und ein zweites Datenpaket in einen einzelnen GPIC 20 auf dem SOC 10 hereinkommen und für Adressnachschlagevorgänge übermittelt werden. Es soll angenommen werden, dass das erste Paket von der MAC-Adresse D kommt und für eine MAC-Adresse AE bestimmt ist. Das zweite Paket kommt von der MAC-Adresse Z und ist für die MAC-Adresse AH bestimmt. In einem Switch, der einen Overhead von vier Zyklen benötigt, beginnen die Adressnachschlagevorgänge im Wesentlichen gleichzeitig bei Taktzyklus 4, wobei das erste Paket von der ersten Suchmaschine 213 gehandhabt wird und das zweite Paket von der zweiten Suchmaschine 214 gehandhabt wird. Die erste Suchmaschine 213 durchsucht zu anfangs die geradzahligen Adressspeicherplätze in der Tabelle 211, während die zweite Suchmaschine 214 die ungeradzahligen Adressspeicherplätze in der Tabelle 212 durchsucht, wie dies in 40b veranschaulicht ist. Da die Tabellen in geeigneter Weise sortiert sind, sind die Suchmaschinen so konfiguriert, dass sie binäre Durchsuchungen initiieren, die in einer Gleichschrittweise oder in einer parallelen Weise beginnend bei dem mittleren Eintrag der jeweiligen Tabellen fortschreiten. Deshalb initiiert die erste Suchmaschine 213 die Durchsuchung der Tabelle 211 bei der Speicheradressstelle 16 und vergleicht die Quell-Adresse D des ersten Datenpakets als den Quellsuchschlüssel mit dem Eintrag Q, der bei der Speicheradressstelle 16 gespeichert ist, wie dies in 40b gezeigt ist. Das Ergebnis dieses Vergleichs ist die Feststellung, dass die erste Suchmaschine 213 die Suche nach der gewünschten Adresse bei niedrigeren Speicheradressstellen fortsetzen sollte, da der Adresseintrag Q numerisch größer als die gewünschte Adresse D ist, was anzeigt, dass die gewünschte Adresse, falls sie in der Tabelle vorhanden ist, an einer niedrigeren Speicheradressstelle gespeichert sein muß. Wie vorher diskutiert worden ist, muß sowohl ein Quelladress-Nachschlagevorgang als auch ein Zieladress-Nachschlagevorgang für jedes Datenpaket durchgeführt werden. Deshalb vergleicht die erste Suchmaschine 213 bei dem Taktzyklus 5 die Zieladresse AE des ersten Datenpakets als den Suchschlüssel mit dem Eintrag Q, der in der mittleren Speicheradressstelle 16 gespeichert ist, und ermittelt, dass die Suche bei höheren Speicheradressstellen fortgesetzt werden sollte, da der Eintrag Q numerisch hexadezimal gesehen niedriger als die gewünschte Adresse AE ist. Dies zeigt an, dass die gewünschte Zieladresse, falls sie in der Tabelle vorhanden ist, bei einer höheren Speicheradressstelle gespeichert sein muß. Bei dem Taktzyklus 6 schaut die erste Suchmaschine 213 in der Speicheradressstelle 8 nach, vergleicht den Suchschlüssel D mit dem Eintrag I und stellt fest, dass die Suche bei den niedrigeren Speicheradressstellen fortgesetzt werden sollte, und zwar in ähnlicher Weise dazu, wie dies oben erörtert worden ist. Bei dem Taktzyklus 7 schaut die erste Suchmaschine 213 in der Speicheradressstelle 24 nach, vergleicht den Ziel-Suchschlüssel AE mit dem Eintrag Y und stellt fest, dass die Suche bei höheren Speicheradressstellen fortgesetzt werden sollte. Bei dem Taktzyklus 8 schaut die erste Suchmaschine 213 in der Speicheradressstelle 4 nach und vergleicht den Quell-Suchschlüssel D mit dem Eintrag E, der an dieser Stelle gespeichert ist. Als ein Ergebnis dieses Vergleichs wird festgestellt, dass die Suche bei niedrigeren Speicheradressstellen fortgesetzt werden sollte. Bei dem Taktzyklus 9 schaut die erste Suchmaschine 213 in der Speicheradressstelle 28 nach, vergleicht den Ziel-Suchschlüssel AE mit dem Adresseintrag AC und stellt fest, dass die Suche bei höheren Speicheradressstellen fortgesetzt werden sollte. Bei dem Taktzyklus 10 schaut die erste Suchmaschine 213 in der Speicheradressstelle 2 nach und vergleicht den Quell-Suchschlüssel D mit dem Eintrag C und stellt fest, dass die Suche in der Tabelle 212 mit den ungeradzahligen Adressen bei der Speicherplatzstelle 3 fortgesetzt werden sollte. Diese Feststellung ist ein Ergebnis der ersten Suchmaschine 213, die feststellt, dass die gewünschte Adresse D weder an der Speicheradressstelle 2, noch an der Spei cheradressstelle 4 gefunden worden ist, welches sequentielle Einträge sind, die numerisch die gewünschte Adresse umgeben. Deshalb ist es angesichts dieser Situation bekannt, dass sich die gewünschte Adresse nicht in der ersten Tabelle 211 befindet, und somit muß die erste Suchmaschine 213 versuchen, in der zweiten Adresstabelle 212 bei der Speicheradressstelle 3 nachzuschauen, da diese Speicheradressstelle interstitiell zwischen den vorher durchsuchten Speicheradressstellen 2 und 4 positioniert ist. Bei dem Taktzyklus 11 schaut die erste Suchmaschine 213 in der Speicheradressstelle 30 nach, welches die letzte Speicheradressstelle in der Tabelle 211 mit den geradzahligen Adressen ist, vergleicht den Ziel-Suchschlüssel AE mit dem Eintrag AE und stellt bei Takt 12 fest, dass das Ergebnis ein Treffer ist. Da ein Treffer festgestellt wurde, setzt die erste Suchmaschine 213 die Suche nach AE in der Tabelle 212 mit den ungeradzahligen Adressen nicht fort, da der Zieladressen-Nachschlagevorgang für das erste Paket vollendet ist. Aber die Quelladresse ist immer noch nicht gefunden, und deshalb schaut die erste Suchmaschine 213 bei dem Taktzyklus 12 in der ungeradzahligen Adresstabelle 212 bei der Speicheradressstelle 3 nach, vergleicht den Quell-Suchschlüssel D mit dem Eintrag D und stellt bei dem Taktzyklus 13 fest, dass das Ergebnis ein Treffer ist. Somit ist der Adressnachschlagevorgang für das erste Paket komplett, da sowohl die Quelladresse als auch die Zieladresse in den jeweiligen Adressnachschlagetabellen gefunden worden sind.
  • Während die Suchmaschine 213 die oben erwähnten Nachschlagevorgänge durchführt, die mit den Quell- und Zieladressen des ersten Datenpakets assoziiert sind, führt die zweite Suchmaschine 214 gleichzeitig die Nachschlagevorgänge für die Quell- und Zieladressen des zweiten Datenpakets durch. Bei dem Taktzyklus 4 und gleichzeitig zu dem Vergleich der geradzahligen Speicheradressstelle 16 durch die erste Suchmaschine 213 schaut die zweite Suchmaschine 214 in der ungeradzahligen Speicheradressstelle 17 nach, die die Mitte der Tabelle 212 der ungeradzahligen Adressen repräsentiert. Die zweite Suchmaschine 214 vergleicht den Quell-Suchschlüssel Z mit dem Adresseintrag R und stellt fest, dass die Suche bei höheren Speicheradressstellen fortgesetzt werden sollte, da R numerisch kleiner als die gewünschte Adresse ist. Bei dem Taktzyklus 5 schaut die zweite Suchmaschine 214 in die Speicheradresse 17, vergleicht den Zieladressen-Suchschlüssel AH mit dem Eintrag R und stellt fest, dass die Suche bei höheren Speicheradressstellen fortgesetzt werden sollte, da die gewünschte Adresse numerisch kleiner als der Eintrag ist, der in der Speicheradressstelle 17 gespeichert ist. Bei dem Taktzyklus 6 schaut die zweite Suchmaschine 214 in die Speicheradressstelle 25, vergleicht den Quell-Suchschlüssel Z mit dem Eintrag Z und stellt bei Takt 7 fest, dass das Ergebnis ein Treffer ist. Der Quelladress-Nachschlagevorgang für das zweite Datenpaket ist deshalb vollendet. Bei dem Taktzyklus 7 setzt die zweite Suchmaschine 214 das Suchen nach der Zieladresse fort, indem sie in die Speicheradressstelle 25 schaut und den Ziel-Suchschlüssel AH mit dem Eintrag Z vergleicht. Dieser Vergleich ermittelt, dass die Suche bei höheren Speicheradressstellen fortgesetzt werden sollte. Bei dem Taktzyklus 9 wertet die zweite Suchmaschine 214 die Inhalte der Speicheradressstelle 29 aus, vergleicht den Ziel-Suchschlüssel AH mit dem Eintrag AD und stellt fest, dass die Suche bei höheren Speicheradressstellen fortgesetzt werden sollte. Bei dem Taktzyklus 11 schaut die zweite Suchmaschine 214 in die Speicheradressstelle 31, vergleicht den Ziel-Suchschlüssel AH mit dem Eintrag AF und stellt bei Takt 12 fest, dass das Ergebnis ein Fehltreffer ist. Deshalb ist der Zieladress-Nachschlagevorgang für das zweite Paket vollendet. Der Zieladress-Nachschlagevorgang für das zweite Paket benötigt keinen letzten Lesevorgang aus der Tabelle 213 mit den geradzahligen Adressen; die Suchmaschine 214 stellt einen Fehltreffer fest, wenn die Ergebnisse der endgültigen Suche keinen Zeiger zu einer Tabelle 211 aus der Tabelle 212 bereitstellt.
  • Als ein zweites Beispiel wird angenommen, dass ein erstes Datenpaket bei einem Port in dem EPIC 20 auf dem SOC 10 von der MAC-Adresse A hereinkommt, das für eine MAC-Adresse JJ bestimmt ist, während ein zweites Datenpaket zeitgleich bei einem anderen Port in dem EPIC 20 des SOC 10 von einer MAC-Adresse G hereinkommt und für die MAC-Adresse CC bestimmt ist. In einem Switch, der wiederum einen Overhead von vier Taktzyklen benötigt, beginnen die Adresssuchvorgänge bei Taktzyklus 4, wobei das erste Paket von der ersten Suchmaschine 213 gehandhabt wird und das zweite Paket von der zweiten Suchmaschine 214 gehandhabt wird. Die erste Suchmaschine 213 durchsucht zuerst die Tabelle 211 der geradzahligen Adressstellen, und die zweite Suchmaschine 214 durchsucht die Tabelle 212 mit den ungeradzahligen Adressstellen. Da die Tabellen 211 und 212 ausgehend von der primären Adresstabelle in geeigneter Weise aufgeteilt und sortiert worden sind, wie dies in den 41a und 41b gezeigt ist, sind die Suchmaschinen wiederum so konfiguriert, dass sie eine binäre Suchoperation oder eine Suchoperation des Gleichschritttyps an der mittleren Adressstelle der jeweiligen Tabellen initiieren können. Deshalb vergleicht die erste Suchmaschine 213 bei dem Taktzyklus 4 den Quelladress-Suchschlüssel A mit dem Eintrag Y, der an der Speicheradressstelle 16 gespeichert ist, und stellt fest, dass die Suche bei niedrigeren Speicheradressstellen fortgesetzt werden sollte, da der hexadezimale numerische Wert der gewünschten Adresse größer als der Eintrag ist. Bei dem Taktzyklus 5 vergleicht die erste Suchmaschine 213 den Zieladressen-Suchschlüssel JJ mit dem Eintrag Y und stellt fest, dass die Suche bei höheren Speicheradressstellen fortgesetzt werden sollte, da der hexadezimale numerische Wert der gewünschten Adresse kleiner als der Eintrag ist. Bei dem Taktzyklus 6 vergleicht die erste Suchmaschine 213 den Quelladressen-Suchschlüssel mit dem Eintrag M, der an der Speicheradressstelle 8 gespeichert ist und stellt fest, dass die Suche bei niedrigeren Speicheradressstellen fortgesetzt werden sollte. Bei dem Taktzyklus 9 vergleicht die erste Suchmaschine 213 den Zieladressen-Suchschlüssel mit dem Eintrag KK, der an der Speicheradressstelle 28 gespeichert ist, und stellt fest, dass die Suche bei niedrigeren Speicheradressstellen fortgesetzt werden sollte. Bei dem Taktzyklus 10 vergleicht die erste Suchmaschine 213 den Quelladress-Suchschlüssel mit dem Eintrag D, der an der Speicheradressstelle 2 gespeichert ist, und stellt fest, dass die Suche bei niedrigeren Speicheradressstellen fortgesetzt werden sollte. Bei dem Taktzyklus 11 vergleicht die erste Suchmaschine 213 den Zieladressen-Suchschlüssel mit dem Eintrag GH, der an der Speicheradressstelle 26 gespeichert ist, und stellt fest, dass die Suche in der Tabelle 212 mit den ungeradzahligen Adressen an der Speicheradressstelle 27 fortgesetzt werden sollte. Diese Feststellung beruht auf der Tatsache, dass die Suchmaschine 213 die Einträge in den angrenzenden Speicheradressstellen 26 und 28 für den Ziel-Suchschlüssel verglichen hat und festgestellt hat, dass die gewünschte Adresse, falls sie in der Tabelle vorhanden ist, in einer Speicheradressstelle zwischen diesen beiden Speicheradressstellen gespeichert sein würde. Daher ist die einzige verbleibende Speicheradressstelle, die für die Durchsuchung in der Operation des Gleichschritttyps zur Verfügung steht, die Speicheradressstelle 27 in der Tabelle 212 mit den ungeradzahligen Adressen. Bei dem Taktzyklus 12 vergleicht die erste Suchmaschine 213 den Quelladressen-Suchschlüssel mit dem Eintrag B, der an der Speicherstelle 0 gespeichert ist, und stellt fest, dass die Suche einen Fehltreffer ergeben hat. Da der Eintrag B die niedrigste nume rische Adresse in den Tabellen ist, wird ein Fehltreffer festgestellt, und danach muß die Quell-MAC-Adresse A gelernt werden und in die Tabelle an die geeignete Stelle eingefügt werden, um die sortierte Reihenfolge der Tabelle aufrecht zu erhalten, was hier erörtert werden wird. Bei dem Taktzyklus 13 vergleicht die erste Suchmaschine 213 den Zieladressen-Suchschlüssel JJ mit dem Eintrag JJ, der an der Speicheradressstelle 27 der ungeradzahligen Adresstabelle 212 gespeichert ist und stellt fest, dass ein Treffer aufgetreten ist.
  • Deshalb ist die Quelladresse des ersten Datenpakets bei der Vollendung der oben erwähnten Schritte nicht lokalisiert worden, und somit muß sie gelernt und in der Adresstabelle gespeichert werden. Aber die Zieladresse des ersten Datenpakets wurde an der Speicherstelle 27 in der Tabelle 212 mit den ungeradzahligen Adressen gefunden, und deshalb wurde für diese Adresse ein Treffer erklärt. Somit ist die Suchoperation für die Quell- und Zieladressen für das erste Datenpaket abgeschlossen. Aber wie bei dem vorhergehenden Beispiel müssen auch die Quell- und Zieladressen des zweiten Datenpakets in den Adresstabellen gesucht werden.
  • Deshalb unternimmt die zweite Suchmaschine 214 gleichzeitig zu den oben genannten Schritten, die mit der ersten Suchmaschine 213 assoziiert sind, die die Tabelle 211 mit den geradzahligen Adressen durchsucht, eine Durchsuchung der Tabelle 212 mit den ungeradzahligen Adressen für die Quell- und Zieladressen des zweiten Datenpakets. Die zweite Suchmaschine 214 beginnt bei dem Taktzyklus 4, indem sie den Quelladressen-Suchschlüssel G mit dem Adresseintrag AA vergleicht, der an der Speicheradressstelle 17 in der Tabelle 212 der ungeradzahligen Adressen gespeichert ist. Dieser Vergleich ergibt die Feststellung, dass die Suche bei niedrigeren Speicheradressstellen fortgesetzt werden sollte, da der Eintrag G numerisch kleiner als der Adresseintrag AA ist. Bei dem Taktzyklus 5 vergleicht die zweite Suchmaschine 214 den Zieladress-Suchschlüssel CC mit dem Eintrag AA, der an der Speicheradressstelle 17 gespeichert ist. Dieser Vergleich ergibt die Feststellung, dass die Suche bei höheren Speicheradressstellen fortgesetzt werden sollte. Beim Taktzyklus 6 vergleicht die zweite Suchmaschine 214 den Quelladress-Suchschlüssel G mit dem Eintrag N, der an der Speicheradressstelle 9 gespeichert ist. Die zweite Suchmaschine 214 stellt fest, dass der Eintrag N numerisch größer als die gewünschte Adresse ist, und deshalb sollte die Suche bei niedrigeren Speicherad ressstellen fortgesetzt werden. Bei dem Taktzyklus 7 vergleicht die zweite Suchmaschine 214 den Zieladressen-Suchschlüssel CC mit dem Eintrag CF, der an der Speicheradressstelle 25 gespeichert ist, und stellt fest, dass die Suche bei niedrigeren Speicheradressstellen fortgesetzt werden sollte. Bei dem Taktzyklus 8 vergleicht die zweite Suchmaschine 214 den ursprünglichen Adress-Suchschlüssel G mit dem Eintrag J, der in der Speicheradressstelle 5 gespeichert ist, und stellt fest, dass die Suche bei niedrigeren Speicheradressstellen fortgesetzt werden sollte. Bei dem Taktzyklus 9 vergleicht die Suchmaschine 214 den Zielsuchadress-Suchschlüssel mit dem Eintrag BC, der bei der Speicheradressstelle 21 gespeichert ist, und stellt fest, dass die Suche bei höheren Speicheradressstellen fortgesetzt werden sollte. Bei dem Taktzyklus 10 vergleicht die Suchmaschine 214 den Quelladress-Suchschlüssel G mit dem Eintrag E, der an der Speicheradressstelle 3 gespeichert ist, und stellt fest, dass die gewünschte Adresse numerisch größer als der Eintrag E ist. Somit stellt die zweite Suchmaschine 214, da vorher im Taktzyklus 10 festgestellt worden ist, dass die gesuchte Adresse größer als der Eintrag der ungeradzahligen Speicheradressstelle 3 ist, und vorher im Taktzyklus 8 festgestellt worden ist, dass die gesuchte Adresse kleiner als der Eintrag an der ungeradzahligen Speicheradressstelle 5 ist, fest, dass der nächste Vergleich in der Tabelle 211 der geradzahligen Adressen an der Speicheradressstelle 4 stattfinden wird. Bei dem Taktzyklus 11 vergleicht die zweite Suchmaschine 214 den Zieladress-Suchschlüssel CC mit dem Eintrag BE und stellt fest, dass die Suche bei höheren Speicheradressstellen fortgesetzt werden sollte. Aber die zweite Suchmaschine 214 hat im Taktzyklus 7 bereits die angrenzende höhere Speicheradressstelle durchsucht, die die Speicheradressstelle 25 war. Deshalb bestimmt die Suchmaschine 214, dass der nächste Vergleich für die Zieladresse in der Tabelle 211 der geradzahligen Adressen an der Speicheradressstelle 24 stattfinden wird. Bei dem Taktzyklus 12 versucht die zweite Suchmaschine 214, die geradzahlige Adressentabelle 211 nach dem Quelladressen-Suchschlüssel G zu durchsuchen; aber, wie oben erörtert worden ist, führt die erste Suchmaschine 213 gerade einen Nachschlagevorgang für den Quelladressen-Schlüssel A an der Speicheradressstelle 0 in der geradzahligen Adresstabelle 211 während dieses bestimmten Taktzyklus durch, und daher bleibt die zweite Suchmaschine 214 während dieses Taktzyklus stehen und ist nicht in der Lage, den Vergleich durchzuführen. Bei dem Taktzyklus 13 hat die erste Suchmaschine 213 ihren Nachschlagevorgang in der geradzahligen Adresstabelle 211 been det, und dann wird es der zweiten Suchmaschine 214 erlaubt, mit dem vorher stehen gebliebenen Suchvorgang in der Tabelle 211 der geradzahligen Adressen weiterzumachen. Deshalb vergleicht die zweite Suchmaschine 214 in dem Taktzyklus 13 den Eintrag G, der in der Speicherstelle 4 der Tabelle der geradzahligen Adressen gespeichert ist, mit dem Quelladressen-Suchschlüssel G. Bei dem Taktzyklus 14 wird ein Treffer für die Quelladresse festgestellt, und die zweite Suchmaschine 214 führt die Suche nach der Zieladresse des zweiten Datenpakets fort, indem sie den Zieladressen-Suchschlüssel CC mit dem Eintrag CC vergleicht, der in der Tabelle 211 der geradzahligen Adressen an der Speicheradressstelle 24 gespeichert ist. Bei dem Taktzyklus 15 wird ein Treffer für die Zieladresse festgestellt.
  • Bei Beendigung des Taktzyklus 15 ist sowohl der Quelladressen-Suchvorgang als auch der Zieladressen-Suchvorgang für das erste Datenpaket und das zweite Datenpaket beendet. Die Quelladresse des ersten Datenpakets ist in den Tabellen nicht gefunden worden und musste daher gelernt und in geeigneter Weise in die Tabellen eingefügt werden. Die restlichen Adressen, die die Zieladresse des ersten Datenpakets und die Quell- und Zieladressen des zweiten Datenpakets umfassen, wurden in den Adresstabellen gefunden.
  • Bei Fällen, in denen eine Adresse gelernt werden muß, wie dies oben angemerkt worden ist, wird einer speziellen Betriebsprozedur gefolgt. Als ein Beispiel wird die primäre Adresstabelle, wie sie in 42 gezeigt ist, wieder in die ersten und zweiten Adresstabellen 211 und 212 aufgeteilt, wie dies in 42a gezeigt ist. Es wird angenommen, dass die Adresse F als ein Ergebnis einer Suchoperation, die diese Adresse in den Tabellen nicht gefunden hat, gelernt werden muß. Da die Adresseinträge, die in den Tabellen gespeichert sind, in einer sortierten Reihenfolge vorliegen, würde die Adresse F logischerweise in die Speicheradressstelle 4 gehören, wenn die sortierte Reihenfolge bei dem Einfügen aufrechterhalten werden soll. Aber die Speicheradressstelle 4 ist im Augenblick von dem Eintrag G besetzt. Deshalb muß, um Platz für die Adresse F zu schaffen, die gelernt und an der Speicheradressstelle 4 korrekt gespeichert werden soll, jeder der Einträge in den Speicheradressstellen 4 bis 26 bewegt oder nach oben zu den benachbarten Speicheradressstellen verschoben werden, wodurch die Speicheradressstelle 4 geöffnet wird. Um das Verschieben dieser Adresseinträge zu erzielen, liest eine Lernzustandsmaschine den Adresseintrag GH aus der Speicheradressstelle 26 und den Adresseintrag CF aus der Speicheradressstelle 25 in einem einzigen Taktzyklus aus. Dann wird der Adresseintrag GH in die Speicheradressstelle 27 geschrieben, während der Adresseintrag CF in die Speicheradressstelle 26 geschrieben wird, und zwar wieder in dem gleichen Taktzyklus. Diese gleichzeitige Lese-/Schreib-Operation des paarweisen Typs setzt sich nach unten durch die Speicheradressstellen innerhalb der Tabellen fort, bis die Einträge K und J aus den Speicheradressstellen 6 und 5 ausgelesen werden und jeweils in die Speicheradressstellen 7 und 6 geschrieben werden. Zu diesem Zeitpunkt wird der Eintrag G aus der Speicheradressstelle 4 gelesen und in die Speicheradressstelle 5 geschrieben, die von der Adresse J in der vorhergehenden Verschiebung freigegeben worden ist. Dies führt zu der gewünschten freien Stelle in der Speicheradressstelle 4, wodurch Platz für die gelernte Speicheradresse F bereitgestellt wird, damit sie in die Speicheradressstelle 4 geschrieben werden kann. Als ein Ergebnis dieser speziellen Tabellenkonfiguration verdoppelt die Lernrate beinahe die des Einzel-Tabellen-Schemas.
  • In der Situation, in der ein einzelnes Datenpaket von einem Eintritt ankommt und eine Adressauflösung benötigt und es keine anderen in der Warteschlange befindlichen Datenpakete gibt, die auf einen Adressnachschlagevorgang warten, wickelt die Suchmaschine den Adressnachschlagevorgang für das Datenpaket einzeln ab. Wenn sofort, nachdem die Suche für das einzelne Datenpaket gestartet ist, eine Flut von Datenpaketen von den anderen Eintritten ankommt, dann müssen die neu angekommenen Datenpakete im schlimmsten Fall 30 Taktzyklen lang warten, während die Quelladresse und die Zieladresse des einzelnen Datenpakets in den Tabellen nachgeschlagen worden sind, bevor die Suchmaschinen mit dem Nachschlagen für die neu angekommenen Datenpakete beginnen können. Wenn irgendeines der neu angekommenen Datenpakete von den Gigabit Ports stammt, dann muß ein Arbitrierungsschema so konfiguriert sein, dass es diesen Datenpaketen eine höhere Priorität zuweist, da ihre Adressnachschlagevorgänge alle innerhalb von 90 Taktzyklen vollständig durchgeführt sein müssen, nachdem die Adressnachschlagevorgänge des einzelnen Datenpakets vollendet sind.
  • Die vorliegende Erfindung stellt einen klaren Vorteil gegenüber Einzel-Adresstabellen-Nachschlagekonfigurationen bereit, da die große Mehrheit der zeitgleichen Durchsuchungen parallel zueinander durchgeführt werden. Deshalb wird in dem Fall, bei dem beide Durchsuchungen nur log2(Tabellngröße)-Vergleiche benötigen, die Leistung verdoppelt, und zwar ungeachtet der Adresseinfügungen und Adresslöschungen, da diese Operationen von niedrigerer Priorität sind und keine Auswirkung auf die Leistung haben. Als ein spezielles Beispiel wird die Leistung für die parallele Operation dadurch berechnet, dass die Anzahl von Zyklen pro Suche mit der Anzahl der Taktzyklen pro Suchzyklus multipliziert wird und dann der Takt-Overhead addiert wird. Diese Berechnung wird durch die folgende Gleichung dargestellt: Leistung = (#Zyklen parallel)·(2Takte/Suchzyklus) + Overhead (1)
  • Deshalb wird die Leistung für eine 8k Tabelle, die die vorliegende Erfindung verwendet, durch das Folgende dargestellt: P8k = (13)·(2) + 4 = 30 Taktzyklen für 2 Pakete oder 15 Taktzyklen für ein einzelnes Datenpaket (2)
  • Die Leistung für eine 16k Tabelle, die die vorliegende Erfindung verwendet, wird durch das Folgende dargestellt: P16k = (14)·(2) + 4 = 32 Taktzyklen für 2 Pakete oder 16 Taktzyklen für ein einzelnes Paket (3)
  • Wenn nur ein einzelnes Datenpaket einen Adressnachschlagevorgang benötigt, repräsentiert das Folgende die Suchzeit zur Erzielung des Nachschlagens mit der vorliegenden Erfindung: P8k = (13)·(2) + 4 = 30 Taktzyklen pro Paket (4) P16k = (14)·(2) + 4 = 32 Taktzyklen pro Paket (5)
  • Deshalb stellt die vorliegende Erfindung einen wesentlichen Anstieg der Leistung der Adressnachschlagezeit gegenüber einer Einzel-Tabellen-ARL bereit, obwohl sie nicht die Verwendung eines zusätzlichen Speichers erfordert. Des Weiteren wird die Nachschlage- und Lern-Latenzzeit der vorliegenden Erfindung gegenüber der der Einzel-Tabellen-ARL fast auf die Hälfte gekürzt, da die Mehrzahl der Lese- und Schreibvorgänge, die damit assoziiert sind, parallel erzielt werden können, wodurch sich die Anzahl an Taktzyklen, die notwendig sind, um die Verschiebung von Speicheradressen und das Einfügen einer gelernten Adresse fertig zu stellen, reduziert. Außerdem verringert sich die Leis tung schlechtestenfalls um nur zwei Taktzyklen, wenn die Tabellengröße von 8k auf 16k vergrößert wird.
  • Darüber hinaus können die Ausführungsbeispiele der vorliegenden Erfindung, die oben erörtert worden sind, physikalisch auf eine Vielzahl von Arten implementiert werden. Zum Beispiel können die Adresstabellen und Suchmaschinen der vorliegenden Erfindung in Hardware implementiert werden, wie etwa auf einem einzigen Halbleitersubstrat in Verbindung mit den verschiedenen Komponenten des SOC 10. Alternativ dazu können die Adresstabellen und Suchmaschinen als separate diskrete Hardware-Komponenten implementiert werden, die elektrisch mit den Komponenten des SOC 10 verbunden sind. Des Weiteren können die Tabellen und Suchmaschinen, die mit dem SOC 10 assoziiert sind, sowohl ausschließlich, als auch teilweise durch Software implementiert und durchsucht werden. Zusätzlich wird, obwohl die vorliegende Vorrichtung und das vorliegende Verfahren in Verbindung mit der Adressauflösung in einem Netzwerk-Switch offenbart ist, in Betracht gezogen, dass die Vorrichtung und das Verfahren zur Durchsuchung einer sortierten Tabelle, wie dies hier zitiert wird, auf verschiedene alternative Anwendungen angewendet werden können. Deshalb ist die Zitierung der Implementierung der Vorrichtung und des Verfahrens in Verbindung mit der Adressauflösung in keinster Weise dazu gedacht, den Schutzbereich der vorliegenden Erfindung zu begrenzen, da die vorliegende Erfindung effektiv bei jeglicher Durchsuchung einer sortierten Tabelle verwendet werden könnte.
  • Filterung:
  • Nun wird wieder auf die Erörterung der 14 Bezug genommen. Sobald die ersten 64 (vierundsechzig) Bytes des Pakets in dem Eingangs-FIFO 142 ankommen, wird an den FFP 141 eine Filterungsanforderung gesendet. Der FFP 141 umfasst einen extensiven Filterungsmechanismus, der es dem SOC 10 ermöglicht, Paketfilter auf jedes Feld eines Pakets von der Schicht 2 bis zu der Schicht 7 des OSI-Sieben-Schichten-Modells zu setzen. Filter werden für die Paketklassifizierung auf der Grundlage verschiedener Protokollfelder innerhalb der Pakete selber verwendet. Verschiedene Aktionen werden auf der Grundlage der Paketklassifikation unternommen, einschließlich zum Beispiel das Paketverwerfen, das Senden des Pakets zu der CPU, das Senden des Pakets zu anderen Ports, das Senden des Pakets in bestimmte COS-Prioritäts-Warteschlangen und das Ändern des Diensttyp-(TOS; type of service)-Vorrangs. Filter werden allgemein auch dazu verwendet, Sicherheitsmerkmale zu implementieren, da sie so konfiguriert sein können, dass sie es einem Paket erlauben, nur dann weiterzugehen, wenn eine Filterübereinstimmung vorliegt. Wenn keine Übereinstimmung vorliegt, dann können die Aktionen, die mit exklusiven Filtern assoziiert sind, ergriffen werden. Eine weitere Erörterung von Filtern, sowohl inklusiv als auch exklusiv, wird später dargestellt.
  • Es sollte angemerkt werden, dass der SOC 10 die Fähigkeit aufweist, sowohl Pakete mit Tags als auch Pakete ohne Tags zu handhaben, die in den Switch hereinkommen. Pakete mit Tags sind in Übereinstimmung mit den IEEE-Standards mit Tags versehen und umfassen ein spezielles IEEE 802.1p Prioritätsfeld für das Paket. Tag-lose Pakete weisen kein Tag auf und umfassen daher kein 802.1p-Prioritätsfeld. Der SOC 10 kann für das Paket auf der Grundlage entweder des Ankunftsports oder der Zieladresse einen geeigneten Prioritätswert zuweisen. Wie in dem ARL-Tabellenformat angemerkt ist, das hier erörtert wird, ist ein SCP-(Source COS Priority; Quellenserviceklassenprioritäts-)Bit als eines der Felder der Tabelle enthalten. Wenn dieses SCP-Bit gesetzt ist, wird der SOC 10 eine Gewichtung auf der Grundlage eines Quell-COS-Werts in der ARL-Tabelle zuweisen. Wenn das SCP-Bit nicht gesetzt ist, dann wird der SOC 10 eine COS für das Paket auf der Grundlage des Ziel-COS-Feldes in der ARL-Tabelle zuweisen. Diese COS-Werte sind drei Bit-Felder in der ARL-Tabelle, wie vorher in der ARL-Tabellenfeld-Beschreibung angemerkt worden ist.
  • Der FFP 141 ist im Wesentlichen eine programmierbare Regelmaschine, die von einer Zustandsmaschine angesteuert wird. Die Filter, die von dem FFP in einem ersten Ausführungsbeispiel verwendet werden, sind 64 (vierundsechzig) Bytes breit und werden an ein ankommendes Paket angelegt. In einigen Ausführungsbeispielen kann eine 64 Byte Filtermaske verwendet werden und an alle ausgewählten 64 Bytes oder 512 Bits eines Pakets angelegt werden. In einem anderen Ausführungsbeispiel kann aber ein Filter geschaffen werden, indem ausgewählte Felder eines ankommenden Pakets derart analysiert werden, dass eine 64 Byte Filtermaske geschaffen wird, die selektiv an Felder von Interesse eines ankommenden Pakets angelegt wird. In noch einem anderen Ausführungsbeispiel kann ein Filter geschaffen werden, indem eine vorbe stimmte Anzahl an Offsets an das ankommende Datenpaket 112 angelegt wird, wobei eine vorbestimmte Anzahl an Bytes, die sofort jedem einzelnen Offset folgen, von dem Paket analysiert bzw. geparst und danach miteinander verkettet werden, um einen Filterwert zu bilden, der bei dem Filterungsprozess verwendet wird.
  • Filter werden, wie vorher angemerkt worden ist, hauptsächlich für die Paketklassifizierung auf der Grundlage bestimmter ausgewählter Protokollfelder in dem Paket verwendet. Auf der Grundlage der Paketklassifikation kann eine Vielzahl von Aktionen ergriffen werden. Die Aktionen können das Verwerfen der Pakete, das Senden der Pakete zu der CPU, das Senden der Pakete zu einem gespiegelten Port, das Prioritäts-Mapping, die TOS-Tag-Modifikation, etc. umfassen. In einem Ausführungsbeispiel umfasst der FFP 141 eine Filterungslogik 1411, die in 15 veranschaulicht ist, die selektiv vorbestimmte Felder aus den ankommenden Datenpaketen analysiert, wodurch effektiv die Werte der gewünschten Felder aus den MAC-, IP-, TCP- und UDP-Headern erhalten werden. 20 ist eine Tabelle, die die verschiedenen wichtigen Felder und ihre jeweiligen Offsets für verschiedene Pakettypen veranschaulicht. Andere Felder, die zu IPX und/oder anderen Feldern in Bezug stehen können, können ebenfalls bei diesem Filtrationsverfahren verwendet werden, indem diese speziellen Felder, die geparst werden sollen, bei der Filterung aus dem Paket ausgewählt werden.
  • Der SOC 10 umfasst eine Filter-Datenbank, die eine Vielzahl von Filtersätzen umfasst. In einem Beispiel können zwei Sätze von Filtern bereitgestellt sein, von denen jeder acht Filter und eine assoziierte Regeltabelle enthält, die 512 Einträge tief ist. 21A veranschaulicht das Format für eine Filtermaske, wobei sie die verschiedenen Felder davon, die das Field Mask-Feld einschließen, zeigt. Die speziellen Felder der Filtermaske sind wie folgt:
    • Field Mask – 512 Bits lang – Die Feldmaske besteht aus mehreren Protokollmasken (Protocol Masks). Für die Felder, die von Interesse sind, wird die Maske überall auf 1en gesetzt, und für andere Felder wird die Maske auf Null gesetzt.
    • Egress Port Mask – 6 Bits lang – Die Austrittsportmaske – Diese Austrittsportmaske wird nur dann überall auf 1en gesetzt, wenn der Austrittsport Teil des Filters ist.
    • Egress ModId Mask – 5 Bits lang – Die Egress Module Id Mask (Austrittsmodul-Id-Maske) – Diese Modul-Id-Maske wird nur dann insgesamt auf 1en gesetzt, wenn die Austrittsmodul-Id Teil des Filters ist.
    • Ingress Port Mask – 6 Bits lang – Die Eintrittsportmaske wird nur dann insgesamt auf 1en gesetzt, wenn der Eintrittsport Teil des Filters ist.
    • Data Offset 1 – 7 Bits lang – Der Daten-Offset 1 – Der 7-Bit-Daten-Offset wird dazu verwendet, die Datenmaske für 8 Bytes von Daten 1 irgendwo in den ersten 128 Bytes des Pakets zu setzen.
    • Data Offset 2 – 7 Bits lang – Der Daten-Offset 2 – Der 7-Bit-Daten-Offset wird dazu verwendet, die Datenmaske für 8 Bytes von Daten 2 irgendwo in den ersten 128 Bytes des Pakets zu setzen.
    • Data Offset 3 – 7 Bits lang – Der Daten-Offset 3 – Der 7-Bit-Daten-Offset wird dazu verwendet, die Datenmaske für 8 Bytes von Daten 3 irgendwo in den ersten 128 Bytes des Pakets zu setzen.
    • Data Offset 4 – 7 Bits lang – Der Daten-Offset 4 – Der 7-Bit-Daten-Offset wird dazu verwendet, die Datenmaske für 8 Bytes von Daten 4 irgendwo in den ersten 128 Bytes des Pakets zu setzen.
    • No Match Action – 13 Bits lang – Keine-Übereinstimmungs-Aktion – Dieses Feld ist nur gültig, wenn das Aktivierungsbit für die Keine-Übereinstimmungs-Aktion auf 1 gesetzt ist. Die Keine-Übereinstimmungs-Aktion wird nur dann angelegt, wenn das Filter nicht mit irgendeinem der Einträge in der Regeltabelle übereinstimmt. Die nachfolgenden Aktionen sind folgendermaßen definiert: Bit 0 – Wenn dieses Bit gesetzt ist, dann ändere die 802.1p Priorität in dem Paket. Die Priorität wird aus dem 802.1p Priority Feld ausgelesen. Bit 1 – Wenn dieses Bit gesetzt ist, dann kategorisiere dieses Paket, um es in eine Prioritäts-COS-Warteschlange zu schicken, aber modifiziere nicht das 802.1p Priority Feld in dem Paket-Tag-Header. Wiederum wird die Priorität aus dem 802.1p Priority Feld abgerufen. Bit 2 – Wenn dieses Bit gesetzt ist, dann ändere den IP-TOS-Vorrang in dem IP-Header. Der neue TOS-Vorrangswert wird aus dem TOS_P-Feld gelesen. Bit 3 – Wenn dieses Bit gesetzt ist, dann sende das Paket zur CPU. Bit 4 – Wenn dieses Bit gesetzt ist, dann verwerfe das Paket. Bit 5 – Wenn dieses Bit gesetzt ist, dann wähle den Ausgangsport aus dem Portfeld aus. Wenn das Paket ein Broadcast, Multicast oder ein DLF ist, dann wird diese Aktion nicht angelegt. Bit 6 – Wenn dieses Bit gesetzt ist, dann wird das Paket zu dem Port, "zu dem gespiegelt wird" ("mirrored-to" port), gesendet. Bit 7 – ist ein reserviertes Bit. Bit 8 – Wenn dieses Bit gesetzt ist, dann wird der Wert des 802.1p Priority Feldes aus dem TOS Precedence Feld in dem IP-Header genommen. (TOS_P->COS). Bit 9 – Wenn dieses Bit gesetzt ist, dann wird der Wert des TOS Precedence Feldes in dem IP-Header aus dem 802.1p Priority Feld genommen. (TOS_P->COS). Bit 10 – wenn dieses Bit gesetzt ist, dann wird der Wert der differenzierten Dienste (DS; differentiated services) aus dem Differentiated Services Feld genommen. Bit 11 – wenn dieses Bit gesetzt ist, dann wähle den Ausgangsport und die Ausgangs-Modul-ID aus der Filtermaske unabhängig vom Pakettyp aus. Bit 12 – reserviert.
    • NMA Enable – 1 Bit lang – No Match Action Enable (Keine-Übereinstimmungs-Aktions-Aktivierung) – Wenn diese Bit gesetzt ist, dann ist das No Match Action-Feld ein gültiges Feld. Auch die Art und Weise, in der die Durchsuchung in der Regeltabelle durchgeführt wird, ist etwas anders.
    • 802.1p Priority Bits – 3 Bits lang – 802.1p Prioritätsbits – Der Wert in diesem Feld wird dazu verwendet, dem Paket die Priorität zuzuweisen. Der 802.1p Standard definiert 8 Ebenen von Priorität von 0 bis 7. Das Feld wird nur verwendet, wenn das Bit 0 oder das Bit 1 des Action Feldes gesetzt ist.
    • TOS_P Field – 3 Bits lang – Das TOS_P-Feld – Der Wert in diesem Feld wird dazu verwendet, dem TOS Precedence Feld in dem IP-Header den neuen Wert zuzuweisen. Dieses Feld wird nur verwendet, wenn das Bit 2 des Action Feldes gesetzt ist.
    • Differentiated Services – 6 Bits lang – Differenzierte Dienste – Der Wert in diesem Feld wird dazu verwendet, dem Differentiated Services Feld in dem IP-Header den neuen Wert zuzuweisen.
    • Output Port – 6 Bits lang – Dieses Feld identifiziert die Ausgangsportnummer. Dieser Port setzt sich über den Austrittsport hinweg, der von der ARL ausgewählt worden ist.
    • Output Module Id – 5 Bits lang – Dieses Feld identifiziert die Ausgangsmodulnummer. Die Kombination aus Ausgangsmodul und Ausgangsport setzt den Austrittsport und die Modul-Id außer Kraft, die von der ARL ausgewählt worden sind. Dieses Feld ist nur gültig, wenn das Remote Port Bit gesetzt ist.
    • Remote Port Bit – 1 Bit lang – Wenn dieses Bit gesetzt ist, dann befindet sich der Austrittsport auf dem fernen Modul, und der Port wird durch die Kombination aus Ausgangsmodul-Id und Ausgangsport identifiziert.
    • Filter Enable Bit – 1 Bit lang – Wenn dieses Bit gesetzt ist, wird der Filter aktiviert.
    • Counter – 5 Bits lang – Der Zählerindex – Dies ist der Zähler (Counter), der inkrementiert werden muß.
  • 22 ist ein Flussdiagramm, das die Filterung in dem SOC 10 in einem ersten Ausführungsbeispiel veranschaulicht, bei dem der FFP 141 und die oben diskutierte Filterungskonfiguration verwendet werden. Ein ankommendes Paket, das bei einem Eintritt eines EPIC 20 oder GPIC 30 hereinkommt, wird durch die Adressauflösungslogik der Adressauflösung unterworfen, die bei Schritt 22-1 gezeigt ist. Nachdem die Adressauflösung vollendet ist, analysiert bzw. parst der FFP 141 selektiv das Paket des Schrittes 22-2 und erhält die Werte von vorher ausgewählten Feldern, die mit dem Paket assoziiert sind. In Abhängigkeit von dem Typ des Pakets, also ob es ein Paket des Ethernet Typ II, 802.3, IP, IPX, TCP, UDP, etc. ist, können die oben aufgelisteten Felder auch in dem Parsing-Prozess extrahiert werden. Ein Feldwert wird bei Schritt 22-3 konstruiert, indem die extrahierten Felder in der gleichen Reihenfolge verkettet werden, wie sie in der Feldmaske aufgelistet sind, einschließlich des Eintrittsports und des Austrittsports. Wenn der Austrittsport nicht festgelegt oder bekannt ist, dann wird der Portwert auf einen ungültigen Wert gesetzt, der zum Beispiel 0×3f sein kann. Beim Schritt 22-4 geht die Logik 1411 durch alle Filter, bei denen das Filteraktivierungsbit (Filter enable bit) gesetzt ist, und legt den Maskenabschnitt des Filters an das Feld an. Das Ergebnis dieser Operation wird bei Schritt 22-5 mit der Filternummer verkettet, um einen Suchschlüssel zu erzeugen. Der Suchschlüssel wird dazu verwendet, nach einer Übereinstimmung mit dem Schlüssel in der Regeltabelle 22 bei Schritt 22-6 zu suchen. Wenn das Keine-Übereinstimmungs-Aktions-(NMA; no match action)-Bit auf Null gesetzt ist, dann wird das Filter als ein inklusives Filter betrachtet. Bei inklusiven Filtern sollte, wie dies unten noch besprochen wird, eine exakte Übereinstimmung vorliegen, um die Aktionen auszuführen, die in dem Regeltabelleneintrag definiert sind. Wenn keine exakte Übereinstimmung vorliegt, dann wird für dieses spezielle Filter keine Aktion ergriffen. Wenn das NMA-Bit auf Eins gesetzt ist, dann ist das Filter ein exklusives Filter. Dieser Prozess wird für jedes einzelne Filter wiederholt, bis alle ausgewählten Filter an das Paket angelegt worden sind.
  • Wenn eine binäre Suche in der Regeltabelle 22 durchgeführt wird, wird ein zusätzlicher Vergleich unter Verwendung der Filterauswahl-, Quellport- und Zielportfelder durchgeführt, um festzustellen, ob eine teilweise Übereinstimmung vorliegt. Wenn eine volle Übereinstimmung vorliegt, dann werden die Aktionen aus dem übereinstimmenden Regeltabelleneintrag angelegt. Wenn keine vollständige Übereinstimmung vorliegt, aber eine teilweise Übereinstimmung vorliegt, dann werden die Aktionen aus dem "No match action"-Feld in der Filtermaske bei Schritt 22-7 angelegt. Wenn keine vollständige Übereinstimmung und keine teilweise Übereinstimmung vorliegen, dann wird keine Filteraktion unternommen.
  • Die Regeltabelle 22 ist von der CPU 52 durch den CMIC 40 komplett programmierbar. Die Regeltabelle kann als ein Beispiel eine Tiefe von 256 Einträgen aufweisen. Die Einträge in den Regeltabellen werden, wiederum beispielshalber, in aufsteigender Reihenfolge mit dem Filterwert + Austrittsport + Austrittsmodul-Id + Eintrittsport + Filterauswahl als dem Schlüssel gespeichert. Der Eintrittsport oder Austrittsport wird nur gesetzt, wenn eine Intention besteht, die Filterung auf einer pro Port Basis durchzuführen, und in diesem Fall sollte die assoziierte Eintritts- und/oder Austrittsmaske auf den oben genannten ungültigen Wert von 0×3f gesetzt sein.
  • Die FFP-Konfiguration verbessert die Handhabung des Echtzeitverkehrs, da im Fluge Pakete gefiltert und die Aktionen unternommen werden können. Ohne den FFP 141 müsste das Paket für eine entsprechende Aktion, die interpretiert und unternommen werden soll, zu der CPU transferiert werden. Bei inklusiven Filtern wird, wenn eine Filterübereinstimmung vorliegt, eine Aktion ergriffen, und wenn keine Filterübereinstimmung vorliegt, wird keine Aktion ergriffen; aber die Pakete werden auf der Grundlage einer Übereinstimmungs- oder Nicht-Übereinstimmungs-Situation für inklusive Filter nicht fallengelassen.
  • 23 veranschaulicht ein Beispiel eines Formats für Regeltabellen 22. Die Felder dieser Regeltabelle lauten wie folgt:
    • Filter Value – 512 Bits lang – Für jedes ankommende Paket wird die Filtermaske angelegt, und das Ergebnis wird mit dem Filterwert (Filter Value) verglichen. Da das ankommende Paket selber typischerweise im Big Endian Format vorliegt, sollte der Filterwert in einem Bit Endian Format erstellt werden.
    • Ingress Port – 6 Bits lang – Eintrittsportnummer: Dieses Feld wird nur gesetzt, wenn dieses Filter auf einen speziellen Eintrittsport gesetzt wird. Wenn dieses Feld gesetzt ist, dann sollte die Eintrittsportmaske in dem Filterregister gesetzt sein.
    • Egress Port – 6 Bits lang – Austrittsportnummer: Dieses Feld wird nur gesetzt, wenn das Filter auf einen speziellen Austrittsport gesetzt wird. Wenn dieses Feld gesetzt ist, dann sollte die Austrittsportmaske in dem Filterregister gesetzt sein. Im Falle von Broadcast, Multicast oder DLF sollte der Filterungsmechanismus eine ungültige Portnummer (0×3f) verwenden, so dass in dem Eintrag keine Übereinstimmung vorliegt. Egress Module Id – 5 Bits lang – Austrittsmodul-Id – Dieses Feld wird nur gesetzt, wenn das Filter auf eine spezielle Austrittsport + Modul-Id gesetzt wird. Wenn dieses Feld gesetzt ist, dann sollte die Austrittsportmaske + die Austrittsmodul-Id in dem Filterregister gesetzt sein. Im Falle von Broadcast, Multicast oder DLF sollte der Filterungsmechanismus eine ungültige Portnummer (0×3f) verwenden, so dass keine Übereinstimmung mit dem Eintrag vorliegt. Merke: Der ferne Austrittsport (Remote Egress Port) ist eine Kombination aus Austrittsport + Modul-Id. Der einzige Weg, um den fernen Port ungültig zu machen, liegt darin, eine ungültige Portnummer zu verwenden.
    • Filter Select – 3 Bits lang – Filterauswahl – Diese Bits werden dazu verwendet, die Filternummer zu identifizieren, die verwendet wird, um diese Einträge abzugleichen.
    • Action Bits – 14 Bits lang – Die Aktions-Bits definieren die Aktionen, die im Falle des übereinstimmenden Eintrags zu ergreifen sind. Bit 0 – Wenn dieses Bit gesetzt ist, dann ändere die 802.1p-Priorität in dem Paket. Die Priorität wird aus dem 802.1p Priority Feld abgerufen. Bit 1 – Wenn dieses Bit gesetzt ist, dann kategorisiere dieses Paket, um es zu einer Prioritäts-COS-Warteschlage zu schicken, aber modifiziere nicht das 802.1p Priority Feld in dem Paket-Tag-Header. Wiederum wird die Priorität aus dem 802.1p Priority Feld erfasst. Bit 2 – wenn dieses Bit gesetzt ist, dann ändere den IP TOS Vorrang in dem IP-Header. Der neue TOS-Vorrangswert wird aus dem TOS_P Feld erfasst. Bit 3 – wenn dieses Bit gesetzt ist, dann sende das Paket zu der CPU. Bit 4 – wenn dieses Bit gesetzt ist, dann verwerfe das Paket. Bit 5 – wenn dieses Bit gesetzt ist, dann wähle den Ausgangsport und die Ausgangsmodul-Id aus dem Regeleintrag aus. Wenn das Paket ein Broadcast, Multicast oder ein DLF ist, dann wird diese Aktion nicht angelegt. Bit 6 – Wenn dieses Bit gesetzt ist, dann wird das Paket zu dem Port, "zu dem gespiegelt wird", gesendet. Bit 7 – Wenn dieses Bit gesetzt ist, dann inkrementiere den Zähler (Counter), der in dem Zählerwert angegeben ist. Der Zählerindex wird aus dem Counter Feld herausgepickt. Bis zu 32 Zähler werden unterstützt. Bit 8 – Wenn dieses Bit gesetzt ist, dann wird der Wert des 802.1p Priority Feldes aus dem TOS Precedence Feld (TOS-Vorrangs-Feld) in dem IP-Header gelesen. (TOS_P->COS). Bit 9 – Wenn dieses Bit gesetzt ist, dann wird der Wert des TOS Precedence Feldes in dem IP-Header aus dem 802.1p Priority Feld erfasst. (COS->TOS_P). Bit 10 – Wenn dieses Bit gesetzt ist, dann wird der Wert der differenzierten Dienste (DS) aus dem Differentiated Services Feld erfasst. Bit 11 – Wenn dieses Bit gesetzt ist, dann wähle den Ausgangsport und die Ausgangsmodul-Id aus der Regeltabelle aus. Bit 12 – Reserviert. Bit 13 – Wenn dieses Bit gesetzt ist, dann wird das Paket nicht fallengelassen. Wenn sowohl das Bit 4 als auch das Bit 13 gesetzt sind, dann wird das Paket nicht fallengelassen.
    • 802.1p Priority Bits – 3 Bits lang – Der Wert in diesem Feld wird dazu verwendet, dem Paket die Priorität zuzuweisen. Der 802.1p Standard definiert 8 Ebenen von Prioritäten von 0 bis 7. Dieses Feld wird nur benutzt, wenn das Bit 0 oder das Bit 1 des Action Feldes gesetzt ist. Differentiated Services – 6 Bits lang – Differenzierte Dienste – Der Wert in diesem Feld wird dazu verwendet, dem Differentiated Services Feld in dem IP-Header den neuen Wert zuzuweisen.
    • TOS_P field – 4 Bits lang – Der Wert in diesem Feld wird dazu verwendet, dem TOS Precedence Feld in dem IP Header den neuen Wert zuzuweisen. Dieses Feld wird nur benutzt, wenn Bit 2 des Action Feldes gesetzt ist.
    • Output Port – 6 Bits lang – Ausgangsport – Dieses Feld identifiziert die Ausgangsportnummer. Dieser Port setzt den Austrittsport außer Kraft, der von der ARL ausgewählt ist.
    • Output Module Id – 5 Bits lang – Ausgangsmodul-Id – Dieses Feld identifiziert die Ausgangsmodulnummer. Die Kombination aus Ausgangsmodul und Ausgangsport setzt den Austrittsport und die Modul-Id außer Kraft, die von der ARL ausgewählt worden sind. Dieses Feld ist nur gültig, wenn das Remote Port Bit gesetzt ist.
    • Counter – 5 Bits lang – Der Counter Index (Zählerindex) ist der Zähler (Counter), der inkrementiert werden muß.
  • Mit anderen Worten, eine logische UND-Operation wird mit der Filtermaske, bei der die ausgewählten Felder aktiviert sind, und dem Paket durchgeführt. Wenn eine Übereinstimmung vorliegt, werden die übereinstimmenden Einträge an die Regeltabellen 22 angelegt, um festzustellen, welche speziellen Aktionen ergriffen werden. Da es eine begrenzte Anzahl von Feldern in der Regeltabelle gibt, und da spezielle Regeln für verschiedene Typen von Paketen angelegt werden müssen, werden die Regeltabellenanforderungen minimiert, indem alle ankommenden Pakete als "mit Tags versehene" Pakete eingestellt werden; alle Pakete ohne Tags unterliegen daher der 802.1 Q Tag-Einfügung, um die Anzahl an Einträgen zu reduzieren, die in der Regeltabelle notwendig sind. Diese Aktion eliminiert die Notwendigkeit von Einträgen, die die Handhabung von Paketen ohne Tags betreffen. Es sollte angemerkt werden, dass spezielle Pakettypen von verschiedenen IEEE Standards und anderen Netzvermittlungsstandards definiert sind und hier nicht definiert werden.
  • Wie vorher angemerkt worden ist, werden exklusive Filter als Filter definiert, die Pakete ausschließen, für die keine Übereinstimmung vorliegt; für ausgeschlossene Pakete werden Aktionen ergriffen, die mit exklusiven Filtern assoziiert sind. Bei inklusiven Filtern werden aber inklusive Aktionen ergriffen. Wenn eine Übereinstimmung vorliegt, wird die Aktion ergriffen, wie dies oben erörtert worden ist; wenn keine Übereinstimmung vorliegt, wird keine Aktion ergriffen, und das Paket wandert durch den Weiterleitprozess voran. Unter Bezugnahme auf 15 ist der FFP 141 so gezeigt, dass er eine Filterdatenbank 1410 umfasst, die Filtermasken darin enthält und die mit logischen Schaltungen 1411 zur Bestimmung der Pakettypen und Anlegung entsprechender Fil termasken kommuniziert. Nachdem die Filtermaske angelegt worden ist, wie dies oben angemerkt worden ist, wird das Ergebnis dieses Anlegens für einen geeigneten Nachschlagevorgang und eine geeignete Aktion an die Regeltabelle 22 angelegt. Es sollte vermerkt werden, dass die Filtermasken, die Regeltabellen und die Logik, obwohl sie durch die CPU 52 programmierbar sind, nicht auf der CPU 52 für die Verarbeitung und die Berechnung davon beruhen. Nach der Programmierung ist eine Hardware-Konfiguration bereitgestellt, die eine/einen Leitungsgeschwindigkeits-Filteranlegung und -Nachschlagevorgang ermöglicht.
  • Unter erneuter Bezugnahme auf 14 bestimmt die Logik 1411 im FFP 141, nachdem der FFP 141 geeignete konfigurierte Filter anlegt und Ergebnisse aus den zugehörigen Regeltabellen 22 erhalten werden, die geeignete Aktion und ergreift diese. Die Filterungslogik kann das Paket verwerfen, das Paket zu der CPU 52 senden, den Paket-Header oder IP-Header modifizieren und jegliches IP-Prüfsummen-Feld (IP checksum field) neu berechnen oder jede andere geeignete Aktion im Hinblick auf die Headers ergreifen. Die Modifikation tritt bei dem Pufferspeicher-Slicer 144 auf, und das Paket wird in den C-Kanal 81 platziert. Die Steuernachricht und die Nachrichten-Header-Information werden von dem FFP 141 und der ARL-Maschine 143 angelegt, und der Nachrichten-Header wird in dem P-Kanal 82 platziert. Die Zuteilungseinheit 18, die auch allgemein im Hinblick auf 8 erörtert worden ist, koordiniert alle Zuteilungen zu dem C-Kanal, dem P-Kanal und dem S-Kanal. Wie vorher angemerkt worden ist, sind jedes EPIC-Modul 20, GPIC-Modul 30, die MMU 70, der IPIC 90, etc. einzeln konfiguriert, um über den CPS-Kanal zu kommunizieren. Jedes Modul kann unabhängig modifiziert werden, und solange die CPS-Kanal-Schnittstellen aufrechterhalten werden, sollten interne Modifikationen an irgendeinem der Module wie etwa dem EPIC 20a die anderen Module wie etwa EPIC 20b, GPICs 30 oder IPIC 90 nicht beeinträchtigen.
  • Wie vorher erwähnt worden ist, wird der FFP 141 von dem Benutzer durch die CPU 52 auf der Grundlage der speziellen Funktionen, die von dem FFP gehandhabt werden sollen, programmiert. Unter Bezugnahme auf 17 ist zu sehen, dass bei Schritt 17-1 von dem Benutzer ein FFP-Programmierungsschritt initiiert wird. Wenn die Programmierung initiiert ist, identifiziert der Benutzer im Schritt 17-2 die Protokollfelder des Pakets, die für das Filter von Interesse sein sollen. Im Schritt 17-3 werden der Pakettyp und die Filterbedingungen festgelegt, und im Schritt 17-4 wird eine Filtermaske auf der Grundlage des identifizierten Pakettyps und der gewünschten Filterbedingungen konstruiert. Die Filtermaske ist im Wesentlichen eine Bitmap, die an ausgewählte Felder des Pakets angelegt wird oder mit den ausgewählten Feldern des Pakets einem UND unterzogen wird. Nachdem die Filtermaske konstruiert ist, wird dann bestimmt, ob das Filter ein inklusives oder ein exklusives Filter sein wird, und zwar in Abhängigkeit von den Problemen, die gelöst werden sollen, von den Paketen, die weitergeleitet werden sollen, den Aktionen, die ergriffen werden sollen, etc.. Im Schritt 17-6 wird bestimmt, ob das Filter an dem Eintrittsport ist oder nicht, und im Schritt 17-7 wird bestimmt, ob das Filter an dem Austrittsport ist oder nicht. Wenn das Filter an dem Eintrittsport ist, dann wird in dem Schritt 17-8 eine Eintrittsportmaske verwendet. Wenn festgestellt wird, dass das Filter an dem Austrittsport sein wird, dann wird bei Schritt 17-9 eine Austrittsmaske verwendet. Auf der Grundlage dieser Schritte wird dann ein Regeltabelleneintrag für die Regeltabellen 22 konstruiert, und der Eintrag oder die Einträge werden in die geeignete Regeltabelle platziert (Schritte 17-10 und 17-11). Diese Schritte werden von dem Benutzer ergriffen, indem er durch eine geeignete Eingabevorrichtung spezielle Sätze von Regeln und Informationen in die CPU 52 eingibt, und indem die CPU 52 im Hinblick auf die Erschaffung der Filter durch den CMIC 40 und die geeigneten Eintritts- oder Austrittssubmodule in einem entsprechenden EPIC-Modul 20 oder GPIC-Modul 30 die geeignete Aktion ergreift.
  • In einem anderen Ausführungsbeispiel der Erfindung ist die Filterungslogik gegenüber dem vorhergehenden Ausführungsbeispiel modifiziert. In diesem Ausführungsbeispiel, das in einer Implementierung mit dem, was vorher erörtert worden ist, rückwärts kompatibel ist, sind vier 16-Byte-Felder in dem Paket-Header speziell definiert, wobei jedes dieser Felder seinen eigenen konfigurierbaren Offset aufweist. Diese vier 16-Byte-Felder sind kombiniert, um die vorher erwähnte 64 Byte/512 Bit-Feldmaske zu bilden. Aber in diesem Ausführungsbeispiel sind die Offsets so konfiguriert, dass die Filtermaske in den Paket-Header effektiv bis zu 120 Bytes tief schauen kann. Obwohl 20 veranschaulicht, dass ein beträchtlicher Teil der relevanten Filterungsinformationen in den ersten 64 Bytes des Paket-Header enthalten ist, wird die vorliegende Erfindung dann, wenn die Produkt- und Technologieneuerungen dazu führen, dass die Bytes 64 bis 120 des Paket-Header von beträchtlicher Relevanz für die Filterung sind, so konfiguriert werden, dass sie die Filterung unter Verwendung dieses Header-Formats durchführt.
  • Wie oben angemerkt ist, wird der 64-Byte-Paketschlüssel in eine vorbestimmte Anzahl von Subfeldern aufgeteilt. Zum Beispiel kann der 64-Byte-Paketschlüssel in 4 16-Byte-Subfelder aufgeteilt werden. Jedes Subfeld weist eine 3-Bit-Maske auf, die damit assoziiert ist, und die ein Vielfaches von 8 Bytes anzeigt, um einen Offset für jedes Subfeld zu bilden, wie dies in 31 gezeigt ist. Deshalb würde zum Beispiel dann, wenn die ersten 64 Bytes des Pakets von Interesse sind, ein Offset-Feld von 000 für alle vier der 16-Byte-Subfelder verwendet. Dies würde bewirken, dass der erste Offset die 16 Bytes beginnend mit Byte 0 und fortlaufend bis zum Byte 15 erfassen/überprüfen würde. Der zweite Offset würde die 16 Bytes beginnend mit Byte 16 und fortlaufend bis zum Byte 31 erfassen, und in ähnlicher Weise würde der dritte Offset die Bytes 32 bis 47 erfassen, und der vierte Offset würde die Bytes 48 bis 63 erfassen, wodurch die gesamten ersten 64 Bytes eingeschlossen wären. Als ein zweites Beispiel würden die Subfelder dann, wenn die Offsets als erster Offset 001, zweiter Offset 011, dritter Offset 100 und vierter Offset 110 gesetzt wären, folgendermaßen definiert sein. Der erste Offset von 001 würde das erste Subfeld als beginnend mit der Bytenummer 8 in dem Paket-Header und 16 Bytes lang fortlaufend bis zu dem Byte 23 definieren. Der zweite Offset von 011 würde das zweite Subfeld als beginnend bei Byte 40 und 16 Bytes lang fortlaufend bis zum Byte 55 definieren. Der dritte Offset von 100 würde das dritte Subfeld als beginnend bei Byte 64 und fortlaufend bis zu Byte 79 definieren. Schließlich würde der vierte Offset von 110 das vierte Subfeld als beginnend bei Byte 96 und fortlaufend bis zum Byte 111 definieren. Danach werden die vier einzelnen 16-Byte-Subfelder, die durch die Anlegung der vier Offsets geschaffen wurden, zu einem einzigen 64-Byte-Feldwert verkettet. Wieder muß die Verkettung des Feldwerts die Eintrittsport-, Austrittsport- und Austrittsmodul-Id-Felder enthalten. Wenn die Austrittsmodul-ID- oder Austrittsport-Felder nicht festgelegt sind, dann werden diese Felder wieder auf einen ungültigen Wert wie etwa 0×3f gesetzt. Die Filterlogik geht dann durch alle Filter, die gesetzt sind, und legt den Maskenabschnitt des Filters an den Feldwert und die Filtermaske an. Das Ergebnis dieser Operation wird wiederum mit der Filternummer verkettet, um den Suchschlüssel zu erzeugen, der dann dazu verwen det wird, nach einer Übereinstimmung in den Regeltabellen 22 zu suchen. Wenn alle der No Match Action Bits auf 0 gesetzt sind, dann wird das Filter als ein inklusives Filter betrachtet, das anzeigt, dass es eine exakte Übereinstimmung geben muß, damit die Aktionen ausgeführt werden, die in dem Regeltabelleneintrag angegeben sind. Wenn nichts weniger als eine vollständige Übereinstimmung vorliegt, dann wird unter einem inklusiven Filter keine Aktion ergriffen. Aber wenn wenigstens eines der Action Bits auf 1 gesetzt ist, dann wird das Filter als ein exklusives Filter betrachtet.
  • Bei der Ausführung der Aktionen aus den Regeltabelleneinträgen und der Nicht-Übereinstimmungs-Aktionen aus dem Filter werden spezielle Regeln befolgt, um eine korrekte Filterung und Aktionsausführung zu gewährleisten. Die relevanten Regeln zur Ausführung der Aktionen aus den Regeltabelleneinträgen und der Nicht-Übereinstimmungs-Aktionen aus den Filtern sind wie folgt:
    • • Wenn eine binäre Suche in der Regeltabelle durchgeführt wird, wird ein zusätzlicher Vergleich durchgeführt unter Verwendung der {filter select + egress module id + ingress port + egress port}-Felder ({Filterauswahl + Austrittsmodul-Id + Eintrittsport + Austrittsport}-Felder), um eine teilweise Übereinstimmung festzustellen
    • • Eine volle Übereinstimmung tritt auf, wenn der filter select + egress module id + ingress port + egress port + packet format + filter value (Filterauswahl + Austrittsmodul-Id + Eintrittsport + Austrittsport + Paketformat + Filterwert) mit einem Eintrag in der Regeltabelle übereinstimmt. Deshalb werden dann, wenn eine vollständige Übereinstimmung vorliegt, die assoziierten Aktionen aus dem übereinstimmenden Regeltabelleneintrag angelegt.
    • • Wenn keine vollständige Übereinstimmung und keine teilweise Übereinstimmung vorliegt, dann wird keine Aktion ergriffen.
    • • Wenn keine vollständige Übereinstimmung, aber eine teilweise Übereinstimmung vorliegt, dann werden die Aktionen aus dem No Match Action Feld angelegt. Diese No Match Action (Keine-Übereinstimmungs-Aktion) wird von dem Filtermaskenfeld abgeleitet.
    • • Wenn eine teilweise Übereinstimmung mit einem Filter vorliegt, werden Aktionen, die mit der Filtermaske assoziiert sind, ergriffen. Wenn eine vollständige Übereinstimmung mit einem höheren Filterwert vorliegt, dann werden die Aktionen, die mit dem Regeleintrag assoziiert sind, ergriffen. Wenn ein bestimmtes Aktions-Bit von dem No Match Action Feld gesetzt ist und die vollständige Übereinstimmung in einer anderen Filtermaske nicht das gleiche Aktions-Bit setzt, dann wird die Aktion ergriffen, da die teilweise Übereinstimmung und die vollständige Übereinstimmung auf unterschiedlichen Filtern vorliegen.
    • • Wenn eine teilweise Übereinstimmung und eine vollständige Übereinstimmung vorliegen, werden die Zähler nur für die vollständige Übereinstimmung gemäß der Regeltabelle aktualisiert. Wenn nur eine teilweise Übereinstimmung vorliegt, dann werden die Zähler gemäß der Aktion in der Filtermaske aktualisiert. Wenn alle der Filter eine vollständige Übereinstimmung in der Regeltabelle aufweisen und die Aktion darin liegt, den gleichen Zähler zu inkrementieren, dann wird der Zähler nur einmal inkrementiert. Wenn alle der Filter eine teilweise Übereinstimmung aufweisen und die Aktion darin liegt, den gleichen Zähler zu inkrementieren, dann wird der Zähler nur einmal inkrementiert.
  • Paketflusskontrolle:
  • In Verbindung mit den Filterungsfunktionen ermöglicht die Konfiguration des SOC 10 eine Verkehrskonditionierungsfunktion, die je nach Notwendigkeit Datenpakete messen, formen, überwachen, fallen lassen und/remarkieren kann, um zu gewährleisten, dass die Pakete oder der Datenverkehr, die/der die Bereiche der differenzierten Dienste (diffserv) betreten/betritt, konform zu den vorher bestimmten Anforderungen für die spezielle Implementierung sind/ist. Messfunktionen messen im Allgemeinen die zeitlichen Eigenschaften, im Allgemeinen die Rate oder den Fluss des Stroms der Pakete, die von einem Klassifizierer ausgewählt worden sind. In der vorliegenden Erfindung wird ein Rate Counter Feld (Ratenzähler-Feld) für einen Codepunkt in einer Diffserv-zu-COS-Abbildungstabelle jedes mal dann inkrementiert, wenn ein Paket mit diesem speziellen Codepunkt den Switch betritt, wo durch erlaubt wird, dass eine Verkehrsrate bestimmt wird. Eine Formgebungsfunktion dient dazu, einige oder alle der Pakete in einem Verkehrsstrom zu verzögern, um den Verkehrsstrom in Übereinstimmung mit einem vorbestimmten Verkehrsprofil zu bringen. Die vorliegende Erfindung implementiert eine Formgebungsfunktionalität für jede COS-Warteschlange, die von dem COS-Manager an jedem einzelnen Austritt gehandhabt wird. Die Fallenlassenfunktion der Messlogik ist verantwortlich für das Fallenlassen einiger oder aller Pakete in einem Datenstrom, um den Datenstrom in Übereinstimmung mit einem vorbestimmten Verkehrsprofil zu bringen. Einfach gesagt, wenn der oben erwähnte Rate Counter für einen speziellen Codepunktwert den Rate Counter-Schwellwert überschreitet, der in der Diffserv-zu-COS-Tabelle gespeichert ist, dann ist die Option bereitgestellt, unter Verwendung der New Codepoint Action Bits (neue Codepunkt-Aktions-Bits) das Paket aus dem Datenstrom fallen zu lassen. Die Remarkierungs-Funktion erlaubt es, dass der Codepunkt eines Pakets in Abhängigkeit von den Charakteristiken des Verkehrsprofils zurückgesetzt werden kann. Der Remarker kann so konfiguriert sein, dass er alle Pakete auf einen einzigen Codepunkt remarkiert, oder er kann so konfiguriert sein, dass er ein Paket auf einen eines Satzes von Codepunkten markiert. Insbesondere dann, wenn der oben erwähnte Rate Counter für einen Codepunkt den Rate Counter-Schwellwert in der Diffserv-zu-COS-Tabelle überschreitet, ist zusätzlich zu dem Ändern der 802.1p Priorität des Pakets die Option bereitgestellt, den Codepunkt unter Verwendung der New Codepoint Action Bits zu remarkieren und eine neue COS-Warteschlange für das Paket auszuwählen, wobei beides einen direkten Einfluss auf den Flussschwellwert des Pakets haben wird.
  • Obwohl die vorliegende Erfindung mehrere Paketflusskontrollalternativen bereitstellt, wird das Messen im Allgemeinen von dem Counter Feld der Regeltabelle 22 bereitgestellt. Durch die Verwendung des Zählers und der COS-Warteschlangen können Pakete in einem bestimmten Verkehrsstrom je nach Notwendigkeit verzögert werden, um den Verkehrsstrom in Übereinstimmung mit dem gewünschten Verkehrsprofil zu bringen. Dies kann durch die Verwendung eines COS-Managers 113 und eines Transaktions-FIFO 132 gesteuert werden, wie in 13 veranschaulicht ist. Paketzeiger, die von dem differenzierten Dienste-Codepunkt (DSCP; differentiated services code point) abhängen, werden in eine der COS-Warteschlangen in dem Transaktions-FIFO 132 platziert, und ein Scheduler 134 ruft das nächste Paket in Abhängigkeit von der Prioritätsbestimmung des COS-Managers 133 ab. Warteschlangen-Scheduling-Algorithmen können in den COS-Manager 133 je nach Zweckdienlichkeit für eine bestimmte Anwendung einprogrammiert werden. Ein Scheduling auf der Basis einer strengen Priorität kann implementiert werden, wobei Pakete in der COS-Warteschlange der höheren Priorität zuerst für die Übertragung aufgenommen werden. Aber dies kann zum Verhungern der COS-Warteschlangen niedriger Priorität führen. Eine Option zur Lösung dieser Schwierigkeit ist deshalb die Implementierung einer Scheduling-Konfiguration auf der Basis einer gewichteten Priorität, wobei allen COS-Warteschlangen eine Minimum-Bandbreite bereitgestellt wird, so dass keine Warteschlange als eine Folge der Prioritätszuweisung verhungert. Die Bandbreite ist ein programmierbarer Parameter in dem COS-Manager 133 und kann auf der Grundlage der Switch-Anwendung programmiert werden. Echtzeitanwendungen können durch einen Parameter der maximal zulässigen Latenzzeit implementiert werden, der den COS-Manager 133 in die Lage versetzt, die Paketübertragung derart zu planen, dass die Pakete in einer bestimmten COS-Warteschlange nicht für länger als eine maximal zulässige Latenzzeit verzögert werden.
  • MESSEN UNTER VERWENDUNG VON DSCP
  • Der allgemeine Fluss eines ankommenden Pakets, wie es durch die verschiedenen Funktionen des SOC 10 relativ zu den differenzierten Diensten geht, ist in 45 gezeigt. In einem Ausführungsbeispiel der vorliegenden Erfindung wird eine Verbesserung der differenzierten Dienste für das Internet-Protokoll verwendet, um eine skalierbare Dienstdiskriminierung zu ermöglichen, ohne dass Zustands- und Signalisierungsoperationen pro Fluss bei jedem Sprung benötigt werden. Deshalb kann eine Vielzahl von Diensten aus einem kleinen, wohldefinierten Satz von Systembausteinen gebildet werden, die bereits innerhalb der Netzwerk-Switch-Konfiguration eingesetzt werden. Die differenzierten Dienste können durch eine Kombination aus Folgendem konstruiert werden: erstens, Setzen von Bits in dem IP-Header-Feld an Netzwerk-Grenzen; zweitens, Verwenden dieser Bits, um festzulegen, wie Pakete durch die Knoten in dem Netzwerk weitergeleitet werden; und drittens, durch die Konditionierung der markierten Pakete an Netzwerk-Grenzen in Übereinstim mung mit vorher festgelegten Anforderungen oder Regeln des Dienstes. Die vorliegende Erfindung verwendet den differenzierten Dienste-Codepunkt zur Klassifizierung und Weiterleitung des Verkehrs, der in den Switch eintritt, auf der Grundlage vorbestimmter Richtlinien, die direkt zu dem DSCP in Bezug stehen, und die unten erörtert werden.
  • In diesem Ausführungsbeispiel wählt die Paketklassifizierung die Pakete in einem Verkehrsstrom auf der Basis der Inhalte spezieller Felder in dem Paket-Protokoll-Header aus. In der differenzierten Dienste-Architektur gibt es zwei Typen von Paketklassifizierern: erstens, Mehrfeld-Klassifizierer (multi-field classifier); und zweitens Verhaltensaggregat-Klassifizierer (behaviour aggregate classifier). Mehrfeld-Klassifizierer klassifizieren die Pakete, die den Switch betreten, auf der Grundlage des Inhalts spezieller Felder in dem Protokoll-Header. Die speziellen Felder von Interesse sind wie folgt:
    1) Source IP Address (Quell-IP-Adresse)
    2) Destination IP Address (Ziel-IP-Adresse)
    3) DS Field (DS-Feld)
    4) Protocol ID (Protokoll-ID)
    5) Source TCP Port (Quell-TCP-Port)
    6) Destination TCP Port (Ziel-TCP-Port)
    7) Source UDP Port (Quell-UDP-Port)
    8) Destination UDP Port (Ziel-UDP-Port)
    9) Incoming Interface Number (Nr. der Ankunfts-Schnittstelle)
    10) Application Type, e.g. Telnet, HTTP, FTP, RTP, RTCP, etc. (Anwendungstyp, z.B. Telnet, HTTP, FTP, RTP, RTCP, etc.)
  • Bei der Verwendung von Mehrfeld-Klassifizierern verwendet der SOC 10 den FFP-Mechanismus 141, um die Mehrfeld-(MF)-Klassifikationen zu implementieren, die an den Netzwerk-Grenzen erzielt werden. Die MF-Klassifizierer-Fähigkeit wird unter Verwendung der FFP-141-Maschine implementiert, wobei die Filtermaske und die entsprechende Regeltabelle laut den entsprechenden, auf die differenzierten Dienste bezogenen Richtlinien programmiert werden, um einen neuen Codepunkt zuzuweisen oder den Codepunkt des Pakets zu ändern. Der gleiche Regeleintrag kann verwendet werden, um die 802.1p Priorität des Pakets in Abhängigkeit von der speziellen Richtlinie zu ändern.
  • Alternativ dazu werden dann, wenn ein Verhaltensaggregat-(BA; behavior aggregate)-Klassifizierer verwendet wird, die Pakete nur unter Verwendung des DSCP klassifiziert, und die BA-Klassifizierer befinden sich in Switches, die nicht nur an den DS-Bereichsgrenzen, sondern auch in dem DS-Bereich selber verwendet werden. Der BA-Klassifizierer wird in der Eintrittslogik implementiert. Obwohl zahlreiche komplexere Paketklassifizierer und Richtlinien entsprechend der Vereinbarung zwischen einem Kunden und einem Dienstanbieter definiert werden können, ist die nachfolgende Tabelle ein Beispiel einer Paketklassifizierung.
  • Figure 00700001
  • Insbesondere dann, wenn das DS-Feld in dem ankommenden Paket nicht Null ist, bekommt die Eintrittslogik den COS-Warteschlangenwert aus dem DS-Feld unter Verwendung der Diffserv-zu-COS-Abbildungstabelle, die in 30 gezeigt ist. Die nachfolgenden Felder sind in 30 gezeigt und werden unten ausführlich beschrieben.
    • COS Queue Value – 3 Bits lang – Der COS-Warteschlangenwert wird verwendet, wenn das Paket zu dem Austrittsport gesendet wird.
    • Change Priority Field (CPF) Bit – 1 Bit lang – Wenn das CPF Bit gesetzt ist, dann wird das 802.1p Priority Feld in dem Paket auf eine neue Priorität geändert. Das neue Priority Feld wird aus dem '802.1p Priority' Feld abgerufen.
    • New Codepoint Action (NCA) Bits – 2 Bits lang – Neue Codepunktaktionen werden nur ergriffen, wenn der Rate Counter den Rate Counter-Schwellwert überschreitet. Wert 00 – Keine Aktion. Wert 01 – Weise einen neuen Codepunkt zu. Der neue Codepunktwert wird aus dem "New Codepoint" Feld erfasst. Wert 02 – Weise einen neuen Codepunkt zu und ändere auch die 802.1p Priorität des Pakets. Das neue 802.1p Priority Feld wird aus dem "New 802.1p Priority" Feld abgerufen. Wert 03 – Lasse das ankommende Paket fallen.
    • 802.p Priority – 3 Bits lang – Dieses Prioritäts-Feld wird nur verwendet, wenn das CPF Bit gesetzt ist.
    • Rate Counter – 12 Bits lang – Dieser Zähler wird jedes mal dann inkrementiert, wenn ein Paket mit diesem Codepunkt ankommt. Dieser Zähler wird alle 1 ms zurückgesetzt.
    • Rate Counter Threshold – 12 Bits lang – Wird als Anzahl der Pakete pro 1 ms ausgedrückt. Wenn der Rate Counter diesen Schwellwert überschreitet, dann ist das Paket ein Kandidat für einen neuen Codepunkt.
    • Rate Discard Threshold – 12 Bits lang – Der Rate Discard Threshold (Ratenverwerfungsschwellwert) wird als Anzahl von Paketen pro 1 ms ausgedrückt. Wenn der Ratenverwerfungsschwellwert überschritten wird, dann werden die Pakete verworfen, wenn der NCA Bitwert auf 03 gesetzt ist.
    • New Codepoint – 6 Bits lang – Wenn der Rate Counter den Rate Counter-Schwellwert überschreitet und der NCA Bitwert 01 ist, dann wird der neue Codepunktwert aus diesem Feld abgelesen.
    • New COS Queue – 3 Bits lang – Wenn der Rate Counter den Rate Counter-Schwellwert überschreitet und der NCA Bitwert 01 ist, dann wird der neue COS-Warteschlangenwert aus diesem Feld erfasst.
    • New 802.1p Priority – 3 Bits lang – Wenn der Rate Counter den Rate Counter-Schwellwert überschreitet und der NCA Bitwert 02 ist, dann wird der neue 802.1p Prioritätswert des Pakets aus diesem Feld erfasst.
  • Die Abbildungstabelle, die oben gezeigt ist, bietet auch die Option der Modifizierung des 802.1p Priority Feldes des ankommenden Pakets an. Für jedes Paket, sogar mit Tags versehene oder mit Prioritäts-Tags versehene Pakete mit einem 802.1p Priority Feld, nimmt der COS-Warteschlangenwert, der als ein Ergebnis der differenzierten Dienste-Abbildungstabellen ausgewählt worden ist, Vorrang gegenüber der Priorität ein, die von den 802.1p-Richtlinien ausgewählt worden ist.
  • Ein Flussdiagramm der Logik der differenzierten Dienste, die die vorbestimmten Richtlinien darstellt, die mit dem DSCP assoziiert sind, ist in 46 gezeigt. Das Flussdiagramm der Logik der differenzierten Dienste beginnt bei Schritt 46-1, bei dem die Logik nachschaut, um zu sehen, ob das Paket ein IP-Paket ist und ob der Pakettyp 4 ist. Falls nicht, dann geht die Logik weiter zu Schritt 46-4, der hier noch ausführlicher beschrieben wird; falls ja, dann schreitet die Logik weiter zu Schritt 46-2, bei dem dann, wenn FFP_DSCP gesetzt ist, der Wert des DSCP aus dem FFP verwendet wird. Wenn FFP_DSCP nicht gesetzt ist, und wenn das DSCP-Flag auf 1 gesetzt ist, dann wird der zugewiesene DSCP-Wert dazu verwendet, in die DiffServ-Tabelle zu indizieren, ansonsten wird der DSCP-Wert aus dem IP-Header verwendet. Nach dem Ausführen der geeigneten Aktion bei Schritt 46-2 geht die Logik weiter zu Schritt 46-3, bei dem festgestellt wird, ob der Rate Counter kleiner als der oder gleich dem DSCP-Schwellwert ist. Wenn der Rate Counter nicht größer als der oder gleich dem DSCP-Verwerfungsschwellwert ist, dann geht die Flusslogik weiter zu Schritt 46-9. Wenn der Rate Counter größer als der oder gleich dem DSCP-Verwerfungsschwellwert ist, dann geht die Logik weiter zu Schritt 46-5, bei dem festgestellt wird, ob der DF-Wert 1 ist. Wenn der DF-Wert 1 ist, dann wird die Port-Bitmap auf 0 gesetzt, und wenn der C-Zustand oder eine Kopie des Pakets zu der CPU gehen soll, dann wird die Port-Bitmap auf 1 gesetzt, und die Logik schaltet zu Schritt 46-4. Wenn der DF-Wert nicht gleich 1 ist, dann geht die Logik weiter zu Schritt 46-7, bei dem festgestellt wird, ob der DF-Wert gleich 2 ist. Wenn herausgefunden wird, dass der DF-Wert gleich 2 ist, dann wird das CNG Bit in dem P-Kanal gesetzt, und die Logik geht weiter zu Schritt 46-9. Wenn der DF-Wert nicht gleich 2 ist, dann geht die Logik ohne Modifikation des CNG Bits direkt weiter zu Schritt 42-9. Bei dem Schritt 46-9 stellt die Logik fest, ob der DSCP Rate Counter kleiner als der oder gleich dem DSCP-Remarkierungs-Schwellwert ist. Falls ja, dann geht die Logik weiter zu Schritt 46-10, falls nicht, dann geht sie weiter zu Schritt 46-11. Bei dem Schritt 46-10 stellt die Logik fest, ob der RMF-Wert gleich 0 oder 3 ist. Falls ja, dann geht die Logik weiter zu Schritt 46-11, falls nicht, dann führt die Logik bei Schritt 46-12 eine Überprüfung durch, um zu sehen, ob der RMF-Wert gleich 2 ist. Wenn der RMF-Wert gleich 2 ist, dann erhält die Logik die 802.1p Priorität aus dem dem neuen DSCP-zugewiesenen 802.1p Priority Feld. Wenn der RMF-Wert nicht gleich 2 ist, dann geht die Logik ohne eine Modifikation der Priorität direkt weiter zu Schritt 46-17. Bei dem Schritt 46-17 wird das DSCP-Feld in das neue DSCP-Feld (New DSCP Field) geändert, die IP-Prüfsumme wird neu berechnet, die CRC wird regeneriert. Bei Vollendung all dieser Aktionen geht die Logik weiter zu Schritt 46-4.
  • Nun kehren wir zurück zu Schritt 46-10. Wenn hier der RMF-Wert nicht gleich 0 oder 3 ist, dann geht die Logik weiter zu Schritt 46-11, bei dem die Logik eine Überprüfung durchführt, um zu sehen, ob der NP-Wert gleich 1× ist. Falls ja, dann bekommt die Logik die 802.1p Paketpriorität aus dem 802.1p Priority Feld, bevor sie zu dem Schritt 46-18 weitergeht. Falls in dem Schritt 46-11 herausgefunden wird, dass der NP-Wert nicht gleich 1× ist, dann führt die Logik beim Schritt 46-15 eine Überprüfung durch, um zu sehen, ob der NP-Wert gleich 1 ist. Wenn der NP-Wert gleich 1 ist, dann ruft die Logik den COS-Warteschlangenwert aus der DSCP-Prioritätswarteschlange ab, bevor sie zu dem Schritt 46-18 weitergeht. Wenn der NP-Wert bei dem Schritt 46-15 nicht gleich 1 ist, dann geht die Logik ohne Modifikation der COS-Warteschlange direkt weiter zu Schritt 46-18. Bei Schritt 46-18 wird, wenn der FFP-DSCP gleich 1 ist oder das DSCP_Flag gleich 1 ist, das DSCP Feld geändert, die IP-Prüfsumme wird neu berechnet, und die CRC wird regeneriert. In diesem Schritt wird das DSCP Feld von der FFP-Logik kommen, wenn FFP_DSCP gleich 1 ist; falls nicht, dann wird der Wert von der DSCP-Logik kommen. Bei Vollendung dieser Aktionen geht die DSCP-Logik weiter zu Schritt 46-4.
  • 47 zeigt ein ausführliches Flussdiagramm der Logik, die in dem Schritt 42-4 der 42 enthalten ist. Bei dem Schritt 47-1 erhält die Logik die Port-Bitmap und führt eine logische "UND"-Operation mit diesem Wert und dem weiterleitenden Portregister durch, während sie diesen Wert nach dem Durchgang durch das COS-Mapping unter Verwendung des COS-Auswahlregisters auch mit dem aktiven Portregister, das der ausgewählten COS-Warteschlange entspricht, einem "UND" unterzieht. Dieser Wert wird auch einem "UND" mit dem HOL-Registerwert unterzogen, der dem aktiven Portregister 8 entspricht, um bei diesem Schritt die Port-Bitmap zu erhalten. Die Logik schaut sich in diesem Schritt auch die M-Bits des Ports des portbasierten VLAN an. Bei Beendigung der Aktionen von Schritt 47-1 geht die Logik weiter zu Schritt 47-2, bei dem die Logik eine Überprüfung durchführt, um zu sehen, ob der Eintrittsport gespiegelt ist, das heißt, ob das M-Bit 0 ist, oder ob die Stapelverbindung (stack link) und das M-Bit gesetzt sind. Falls ja, dann wird das Paket bei Schritt 47-3 zu dem entsprechenden gespiegelten Port geschickt, während die Logik, falls dies nicht der Fall ist, zu Schritt 47-4 weitergeht, ohne irgendeine Spiegelportaktion durchzuführen. Bei Schritt 47-4 führt die Logik eine Überprüfung durch, um zu sehen, ob das Spiegeln auf Filterlogik beruht. Falls ja, dann wird das Paket beim Schritt 47-5 zu dem geeigneten gespiegelten Port gesendet, falls nein, dann geht die Logik weiter zu Schritt 47-6, ohne irgendeine Aktion bezüglich eines gespiegelten Ports zu unternehmen. Beim Schritt 47-6 führt die Logik eine Überprüfung durch, um zu sehen, ob der Austrittsport gespiegelt ist, indem sie in das Austrittsspiegelungsregister schaut. Wenn der Austrittsport gespiegelt ist, dann wird das Paket zu dem gespiegelten Port gesendet, bevor die Logik zu Schritt 47-8 geht. Wenn das Paket nicht gespiegelt wird, dann geht die Logik einfach direkt zu Schritt 47-8 weiter, ohne irgendeine Spiegelportaktion zu unternehmen. Der Schritt 47-8 fährt mit der Spiegelportlogik fort, und deshalb wird er hier nicht ausführlich erörtert. Nichtsdestoweniger ist der DSCP bei dieser Stufe der Logik dementsprechend modifiziert worden, so dass der Paketfluss beim Austritt in geeigneter Weise geformt und/oder gemessen werden kann.
  • MESSEN UNTER VERWENDUNG DER MESS-ID
  • In einem anderen Ausführungsbeispiel wird die Paketflusskontrolllogik in die Filterungslogik gefaltet, und deshalb arbeitet die Paketflusskontrolllogik in Verbindung mit der Filterung. In diesem Ausführungsbeispiel arbeitet die Filterungs-/Flusslogik in drei Stufen: erstens, die Logik unternimmt Aktionen, die unabhängig von dem Paketprofil sind, das heißt, die Aktionen hängen nicht von der Klassifizierung des Pakets als im Profil befindlich (In-Profil) oder außerhalb des Profils befindlich (Außer-Profil) ab; zweitens, die Filterungs-/Flusslogik pickt die Mess-ID heraus, die eine 6-Bit-Zahl ist, die mit dem Paket assoziiert ist, und die in der Regeltabelle gespeichert ist, und unternimmt alle geeigneten In-Profil-Aktionen, die eingestellt sind; und drittens, die Filterungs-/Flusslogik unternimmt alle geeigneten Außer-Profil-Aktionen. Beginnend mit den profilunabhängigen Aktionen wird beim Anlegen jeder einzelnen Filtermaske, was im Allgemeinen in einer aufsteigenden numerischen Reihenfolge unternommen wird, eine Entscheidung von der Filterungs-/ Flusslogik getroffen, und zwar dahingehend, ob eine Übereinstimmungsregel vorliegt, wie dies in 32 gezeigt ist. Diese Bestimmung stellt im Wesentlichen fest, ob eine vollständige Übereinstimmung vorliegt oder nicht, wie dies vorher definiert worden ist und was in 32 als Schritt 32-1 gezeigt worden ist. Falls bei Schritt 32-1 festgestellt wird, dass für die bestimmte Maske eine vollständige Übereinstimmung vorliegt, dann wird das erste Aktions-Bit bei Schritt 32-2 überprüft. Wenn beim Schritt 32-1 keine vollständige Übereinstimmung festgestellt wird, dann stellt die Logik bei Schritt 32-3 fest, ob eine teilweise Übereinstimmung für die Maske vorliegt oder nicht. Wenn bei Schritt 32-3 eine teilweise Übereinstimmung herausgefunden wird, dann geht die Logik weiter durch das teilweise Übereinstimmungs-Verfahren, das in 33 veranschaulicht ist und das weiter unten weiter erörtert werden wird. Nun kehren wir zu Schritt 32-2 zurück. Falls bei diesem Schritt festgestellt wird, dass das Bit 1 der Aktions-Bits gesetzt ist, dann wird die Serviceklasse aus diesem Regeleintrag bei Schritt 32-4 ausgewählt. Wenn das Bit 1 der Aktions-Bits nicht gesetzt ist, dann geht die Logik weiter zu Schritt 32-5 und führt eine Überprüfung durch, um zu sehen, ob das Bit 0 der Aktions-Felder gesetzt ist. Wenn das Bit 0 gesetzt ist, dann wird bei Schritt 32-5 die Serviceklasse für diesen Eintrag aus dem Regeleintrag erhalten, das Paket wird für das mit einem Prioritäts-Tag versehene Feld modifiziert, und das Regenerate CRC-Bit wird gesetzt. Wenn das Bit 0 nicht gesetzt ist, dann geht die Logik weiter zu Schritt 32-6, der allgemein den Beginn der Flusskontrolllogik und das Ende der profilunabhängigen Aktionen darstellt, da das Aktions-Bit 0 und das Aktions-Bit 1 Aktionen sind, die unabhängig von der Flusskontrolle sind. Einfach gesagt werden die profilunabhängigen Aktionen bei den Schritten 32-1 bis 32-5 unternommen, und beginnend bei Schritt 32-6 beginnen die profilabhängigen Aktionen.
  • Bei Schritt 32-6 wird die Mess-ID für die spezielle Maske aus der Regeltabelle erhalten. Bei Schritt 32-7 stellt die Logik fest, ob die Mess-ID, die aus der Regeltabelle erhalten worden ist, 0 ist. Wenn die Mess-ID 0 ist, dann wird das Paket automatisch als innerhalb des Profils befindlich (In-Profil) beurteilt, und die entsprechenden In-Profil-Aktionen werden bei Schritt 32-8 sofort ergriffen. Wenn die Mess-ID nicht 0 ist, dann indexiert die Logik bei Schritt 32-9 mit der Mess-ID in die Messtabelle, um den Profilstatus des Pakets zu bestimmen. Bei dem Schritt 32-10 stellt die Logik beim Indexieren in die Messtabelle fest, ob das Paket tatsächlich in dem Profil ist, und falls ja, dann werden die In-Profil-Aktionen von Schritt 32-8 unternommen. Wenn das Paket nicht als in dem Profil befindlich bestimmt wird, dann wird das Paket bei Schritt 32-11 standardmäßig als außerhalb des Profils befindlich ermittelt. Deshalb werden bei der Feststellung, dass das Paket außerhalb des Profils ist, bei Schritt 32-12 die geeigneten Außer-Profil-Aktionen ergriffen.
  • Die Aktionen für die teilweise Übereinstimmung, die bei Schritt 32-3 erörtert wurden, und die ein Teil der profilunabhängigen Aktionen sind, werden in 33 noch ausführlicher beschrieben. Wenn bei Schritt 32-3 keine teilweise Übereinstimmung herausgefunden wird, dann ermittelt die Logik, ob es irgendwelche anderen Masken für den Vergleich gibt. Wenn es andere Masken für den Vergleich gibt, dann geht die Logik zurück zu Schritt 32-1 in 32. Wenn es keine anderen Masken zum Vergleichen gibt, dann fährt die Logik fort, eine Überprüfung bezüglich eines gespiegelten Ports und endgültigen FFP-Aktionen durchzuführen, wie dies in 34 gezeigt ist. Wenn aber bei Schritt 32-3 eine teilweise Übereinstimmung herausgefunden wird, dann geht die Logik in 33 bei Schritt 33-1 weiter. Bei Schritt 33-1 stellt die Logik fest, ob das Bit 8 der Keine-Übereinstimmungs-Aktion gesetzt ist. Wenn das Bit 8 der Keine-Übereinstimmungs-Aktion gesetzt ist, dann ruft die Logik die IEEE 802.1P Prioritätswerte aus dem TOS Precedence Feld in dem Paket-Header bei Schritt 33-2 ab und geht zu Schritt 33-3 weiter. Wenn das Bit 8 der Keine-Übereinstimmungs-Aktion nicht gesetzt ist, dann geht die Logik ohne eine Aktion direkt zu Schritt 33-3 weiter. Bei Schritt 33-3 wird das Bit 9 der Keine-Übereinstimmungs-Aktions-Bits überprüft. Wenn das Bit 9 der Keine-Übereinstimmungs-Aktions-Bits gesetzt ist, dann wird der TOS-Vorrangswert aus dem IEEE 802.1p Priority Feld erfasst, die IP-Prüfsumme wird neu berechnet und die Regenerate CRC wird in der Nachricht gesetzt. Danach geht die Logik weiter zu Schritt 33-5. Wenn das Keine-Übereinstimmungs-Aktions-Bit 9 nicht gesetzt ist, dann geht die Logik einfach weiter zu Schritt 33-5, ohne irgendeine Aktion zu ergreifen. Bei Schritt 33-5 führt die Logik eine Überprüfung durch, um zu sehen, ob das Bit 2 der Keine-Übereinstimmungs-Aktions-Bits gesetzt ist. Wenn das Bit 2 gesetzt ist, dann ersetzt die Logik das TOS Precedence Feld in dem IP-Header mit dem TOS_P-Feld aus der Filtermaske, die IP-Prüfsumme wird neu berechnet, und die Regenerate CRC wird in der Nachricht gesetzt. Nach dem Ergreifen dieser Aktionen geht die Logik weiter zu Schritt 35-1 in 35. Wenn das Keine-Übereinstimmung-Aktions-Bit nicht gesetzt ist, dann geht die Logik einfach weiter zu Schritt 35-1, ohne irgendeine Aktion zu ergreifen.
  • 35 veranschaulicht die Fortsetzung der Aktionslogik für eine teilweise Übereinstimmung, die wiederum Teil der profilunabhängigen Aktionen ist und mit Schritt 35-1 beginnt. Bei dem Schritt 35-1 führt die Logik eine Überprüfung durch, um zu sehen, ob das Keine-Übereinstimmung-Aktions-Bit 3 gesetzt ist. Wenn das Bit gesetzt ist, dann wird eine Kopie des Pakets zu der CPU gesendet, und das Bit 0 der CPU-Opcodes wird gesetzt, bevor zu Schritt 35-3 weitergegangen wird. Wenn das Keine-Übereinstimmung-Aktions-Bit 3 nicht gesetzt ist, dann geht die Logik einfach weiter zu Schritt 35-3, ohne irgendeine Aktion zu ergreifen. Beim Schritt 35-3 führt die Logik eine Überprüfung durch, um zu sehen, ob das Keine-Übereinstimmung-Aktions-Bit 6 gesetzt ist. Wenn das Keine-Übereinstimmung-Aktions-Bit 6 gesetzt ist, dann wird bei dem Schritt 35-4 eine Kopie des Pakets zu dem gespiegelten Port gesendet, und die Logik geht weiter zu Schritt 35-5. Wenn das Keine-Übereinstimmung-Aktions-Bit 6 bei Schritt 35-3 nicht gesetzt ist, dann geht die Logik einfach weiter zu Schritt 35-5, ohne irgendeine Aktion zu ergreifen. Bei Schritt 35-5 führt die Logik eine Überprüfung durch, um zu sehen, ob das Keine-Übereinstimmung-Aktions-Bit 4 gesetzt ist. Wenn das Keine-Übereinstimmung- Aktions-Bit 4 gesetzt ist, dann lässt die Logik das Paket bei Schritt 35-6 fallen und geht weiter zu Schritt 35-7. Wenn das Keine-Übereinstimmung-Aktions-Bit 4 bei Schritt 35-5 nicht gesetzt ist, dann geht die Logik einfach weiter zu Schritt 35-7, ohne irgendeine Aktion zu ergreifen. Bei Schritt 35-7 führt die Logik eine Überprüfung durch, um zu sehen, ob das Bit 5 der Keine-Übereinstimmung-Aktions-Bit gesetzt ist. Wenn das Keine-Übereinstimmung-Aktions-Bit 5 gesetzt ist, dann werden bei Schritt 35-8 der Ausgangsport und die Ausgangsmodul-Id aus dem Feld in der Filtermaske als der Austrittsport und das Austrittsmodul zusammen mit dem entsprechenden Setzen der Port-Bitmap festgelegt. Danach geht die Logik weiter zu Schritt 36-1, wie in 36 gezeigt ist. Wenn das Keine-Übereinstimmung-Aktions-Bit 5 nicht gesetzt ist, dann geht die Logik einfach weiter zu Schritt 36-1, ohne dass sie eine Aktion durchführt, die mit dem Keine-Übereinstimmung-Aktions-Bit 5 assoziiert ist.
  • 36 zeigt die Fortsetzung der Logik für die teilweise Übereinstimmung, die wiederum Teil der profilunabhängigen Aktionen ist und mit Schritt 36-1 beginnt. Bei Schritt 36-1 führt die Logik eine Überprüfung durch, um zu sehen, ob das Bit 1 der Keine-Übereinstimmungs-Aktions-Bits gesetzt ist. Wenn das Keine-Übereinstimmung-Aktions-Bit 1 gesetzt ist, dann wählt die Logik die COS aus dem Feld in der Filtermaske bei Schritt 36-2 aus und geht weiter zu Schritt 36-3. Wenn das Bit 1 der Keine-Übereinstimmungs-Aktions-Bits nicht gesetzt ist, dann geht die Logik einfach weiter zu Schritt 36-3, ohne dass sie irgendeine Aktion durchführt. Bei Schritt 36-3 führt die Logik eine Überprüfung durch, um zu sehen, ob das Bit 0 der Keine-Übereinstimmungs-Aktions-Bits gesetzt ist. Wenn das Bit 0 gesetzt ist, dann bekommt die Logik die COS aus dem Feld in der Filtermaske, modifiziert das Paket für das mit einem Prioritäts-Tag versehene Feld, setzt das Regenerate CRC-Bit und geht dann weiter zu Schritt 36-5. Wenn das Bit 0 nicht gesetzt ist, dann geht die Logik einfach weiter zu Schritt 36-5, ohne irgendeine Aktion durchzuführen, die mit dem Keine-Übereinstimmung-Aktions-Bit 0 assoziiert ist. Bei Schritt 36-5 führt die Logik eine Überprüfung durch, um zu sehen, ob das Keine-Übereinstimmung-Aktions-Bit 10 gesetzt ist. Wenn das Bit 10 gesetzt ist und wenn die TOS nicht von einer höheren Filtermaske modifiziert worden ist, dann wird bei Schritt 36-6 der DSCP aus dem in-DSCP Feld der Filtermaske ausgelesen, die IP-Prüfsumme wird neu berechnet und das Regenerate CRC-Bit wird in der Nachricht gesetzt. Nach dem Durchführen dieser Aktionen, und wenn man bei Schritt 36-5 herausfindet, dass das Bit 10 der Keine-Übereinstimmungs-Aktions-Bits nicht gesetzt ist, dann geht die Logik weiter zu Schritt 36-7. Bei Schritt 36-7 führt die Logik eine Überprüfung durch, um zu sehen, ob das Bit 11 der Keine-Übereinstimmungs-Aktions-Bits gesetzt ist. Wenn das Bit 11 gesetzt ist, dann wählt die Logik bei Schritt 36-8 den Ausgangsport und das Ausgangsportmodul aus der Filtermaske als den Austrittsport und das Austrittsmodul aus. Des Weiteren wird die Port-Bitmap bei Schritt 36-8 entsprechend gesetzt. Wenn bei Schritt 35-7 herausgefunden wird, dass das Bit 11 nicht gesetzt ist, oder wenn die Keine-Übereinstimmungs-Aktionen für das Bit 11 durchgeführt werden, dann fährt die Logik fort, indem sie prüft, ob es irgendwelche weiteren Masken zum Vergleichen gibt, und falls dies so ist, indem sie mit dem Schritt 33-1 für die nächste Maske beginnt und jeden der oben erwähnten Schritte wiederholt. Wenn es keine weiteren Masken zum Vergleichen gibt, dann geht die Logik weiter zu Schritt 43-1, wie in 43 gezeigt ist.
  • Bei Schritt 43-1 wird die Port-Bitmap auf 0 gesetzt, wenn das Paket auf der Grundlage der Aktionen, die durchgeführt werden sollen, fallengelassen werden soll, wie dies von dem Filterungsprozess bestimmt worden ist. Bei dem Schritt 43-2 erhält die Logik die Port-Bitmap und unterzieht diesen Wert einem "UND" mit dem Weiterleitportregister und unterzieht diesen einem "UND" mit dem aktiven Portregister, das der COS-Warteschlange entspricht, die nach dem COS-Mapping unter Verwendung des COS-Auswahlregisters ausgewählt worden ist und mit dem HOL-Register einem "UND" unterzogen worden ist, um die Austrittsport-Bitmap zu erhalten. Außerdem betrachtet die Logik bei Schritt 43-2 die M Bits der portbasierten VLAN-Tabelle, bevor sie zu Schritt 43-3 weitergeht. Bei Schritt 43-3 stellt die Logik fest, ob der Eintrittsport gespiegelt wird, was dem M-Bit 0 entspricht, oder ob die Stapelverbindung und die M-Bits gesetzt sind. Falls ja, dann wird das Paket bei Schritt 43-4 zu dem gespiegelten Port gesendet, bevor mit der Logik bei Schritt 43-5 fortgefahren wird. Wenn die Bits bei Schritt 43-3 nicht gesetzt sind, dann geht die Logik direkt zu Schritt 43-5, ohne das Paket zu dem gespiegelten Port weiterzuleiten. Bei dem Schritt 43-5 stellt die Logik fest, ob das Spiegeln auf der Filterungslogik basiert. Falls nicht, dann geht die Logik direkt weiter zu Schritt 43-7. Falls ja, dann sendet die Logik das Paket wieder zu dem gespiegelten Port, bevor sie zu Schritt 43-7 weitergeht. Bei dem Schritt 43-7 stellt die Logik aus der Überprüfung des Austrittsspiegelungsregisters fest, ob der Austrittsport gespiegelt ist. Wenn das Aus trittsspiegelungsportregister dies befiehlt, dann wird das Paket zu dem gespiegelten Port gesendet. Falls nicht, dann geht die Logik weiter durch die Spiegelungsprozesse, die mit Block M bezeichnet sind, was hier nicht ausführlich erörtert werden wird.
  • Wenn einmal alle profilunabhängigen Aktionen durchgeführt worden sind, dann geht die Logik weiter durch die profilabhängigen Aktionen, die mit 32-8 in 32 beginnen. Bei Schritt 32-8 ist bereits festgestellt worden, dass das auszugebende Paket als in dem Profil liegend klassifiziert worden ist, und deshalb bildet der Schritt 32-8 paketabhängige Aktionen. Die speziellen In-Profil-Aktionen, die im Schritt 32-8 angemerkt sind, werden ausführlicher beginnend in 36 gezeigt. Bei Schritt 34-1 in 34 überprüft die Filterungs-/Flusskontrolllogik das In-Profil-Aktions-Bit 8, um zu sehen, ob dieses Bit gesetzt ist. Wenn dieses Bit nicht gesetzt ist, dann geht die Logik einfach weiter zu Schritt 34-3, ohne irgendeine Aktion bei dem Paket durchzuführen. Aber wenn das Bit gesetzt ist, dann führt die Logik die In-Profil-Aktionen durch, die mit diesem Bit assoziiert sind. Insbesondere dann, wenn das Bit 8 gesetzt ist, liest die Logik bei Schritt 34-2 den 802.1p Prioritätswert aus dem TOS Precedence Feld in dem IP-Header heraus und das Regenerate CRC-Bit in der Nachricht wird gesetzt. Nach dem Durchführen dieser Aktionen geht die Logik weiter zu Schritt 34-3, bei dem die Logik eine Überprüfung durchführt, um zu sehen, ob das In-Profil-Aktions-Bit 9 gesetzt ist. Wenn das Bit nicht gesetzt ist, dann geht die Logik weiter zu Schritt 34-5, ohne irgendeine Aktion bei dem Paket durchzuführen. Wenn das Bit 9 gesetzt ist, dann führt die Logik bei Schritt 34-4 die geeigneten In-Profil-Aktionen durch, die mit dem In-Profil-Aktions-Bit 9 assoziiert sind. Insbesondere wird bei Schritt 34-6 der TOS-Vorrangswert aus dem 802.1p Priority Feld erfasst, die IP-Prüfsumme wird neu berechnet und das Regenerate CRC-Bit in der Nachricht wird gesetzt. Danach geht die Logik weiter zu Schritt 34-5, bei dem das In-Profil-Aktions-Bit 2 überprüft wird. Wenn das Bit 2 nicht gesetzt ist, dann geht die Logik weiter, wie dies in 37 bei Schritt 37-1 gezeigt ist.
  • Der Schritt 37-1 zeigt die Überprüfung durch die Filterungs-/Flusskontrolllogik, um zu sehen, ob das In-Profil-Bit 3 gesetzt ist. Falls nein, dann geht die Logik weiter zu Schritt 37-3; falls ja, dann sendet die Logik eine Kopie des Pakets zu der CPU und setzt das Bit 0 der CPU-Opcodes bei Schritt 37-2, bevor sie zu Schritt 37-3 weitergeht. Bei Schritt 37-3 überprüft die Filterungs-/Flusskontrolllogik das In-Profil-Aktions-Bit 6. Wenn dieses Bit nicht gesetzt ist, dann geht die Logik weiter zu Schritt 37-5, ohne eine Aktion durchzuführen, aber wenn dieses Bit gesetzt ist, dann wird bei Schritt 37-4 eine Kopie des Pakets zu dem gespiegelten Port gesendet, bevor die Logik weiter zu Schritt 37-5 geht. Beim Schritt 37-5 führt die Filter-/Flusskontrolllogik eine Überprüfung durch, um zu sehen, ob das Aktions-Bit 4 gesetzt ist. Wenn das Bit 4 gesetzt ist, dann wird das Paket bei Schritt 37-6 fallen gelassen, aber die Logik fährt damit fort, die restlichen Aktions-Bits zu überprüfen. Wenn das Bit 4 nicht gesetzt ist, dann geht die Logik weiter zu Schritt 37-7, bei dem das Aktions-Bit 5 zusammen mit dem Zielport überprüft wird. Wenn das Aktions-Bit 5 gesetzt ist und der Zielport auf 0×3f gesetzt ist, den ungültigen Standardwert, der von dem SOC 10 gesetzt worden ist, dann wird der Ausgangsport und die Ausgangsmodul-Id aus dem Regeleintrag als Austrittsport und Austrittsmodul ausgewählt und die Port-Bitmap entsprechend gesetzt. Wenn das Aktions-Bit 5 und der Zielport nicht auf die gewünschten Werte gesetzt sind, dann geht die Logik weiter zu Schritt 37-9, bei dem das Aktions-Bit 7 überprüft wird. Wenn das Aktions-Bit 7 gesetzt ist, dann wird der Zähler, der in dem Counter Feld der Regel angegeben ist, bei Schritt 37-10 inkrementiert, außer der Zähler ist für dieses Paket bereits durch ein vorhergehendes Aktions-Bit oder eine vorhergehende Regel inkrementiert worden. Danach geht die Logik weiter zu Schritt 37-11, bei dem das Aktions-Bit 10 überprüft wird. Wenn das In-Profil-Aktions-Bit 10 gesetzt ist und TOS nicht von einer höheren Filtermaske modifiziert worden ist, dann wird bei Schritt 37-12 der DSCP aus dem in-DSCP Feld der Regeltabelle erfasst, die IP-Prüfsumme wird neu berechnet und das Regenerate CRC wird in dem Paket gesetzt. Danach geht die Logik durch die In-Profil-Aktions-Bits weiter, wie dies in 42 veranschaulicht ist.
  • Bei Schritt 42-1 überprüft die Filterungs-/Flusskontrolllogik das In-Profil-Aktions-Bit 11 und die Zielportadresse. Wenn das Aktions-Bit 11 gesetzt ist und die Zielportadresse gleich 0×3f ist, dann werden der Ausgangsport und das Ausgangsmodul aus dem Regeleintrag als der Austrittsport und das Austrittsmodul ausgewählt, und die Port-Bitmap wird entsprechend aktualisiert, und zwar alles im Schritt 42-2. Bei Vollendung der Aktionen, die mit dem Aktions-Bit 11 assoziiert sind, oder wenn das Aktions-Bit nicht gesetzt ist, geht die Filterungs-/Flusskontrolllogik weiter zu Schritt 42-3. Bei Schritt 42-3 überprüft die Logik das In-Profil-Aktions-Bit 12. Wenn das Bit gesetzt ist, dann wird das Fallenlassen-Vorrangsbit (drop precedence bit) auf 1 gesetzt, und das CNG Bit wird in dem P-Kanal gesetzt. Nach dem Durchführen dieser Aktion, oder wenn das Aktions-Bit 12 zu anfangs nicht gesetzt ist, geht die Logik weiter zu Schritt 42-5. Bei diesem Schritt überprüft die Filterungs-/Flusskontrolllogik das In-Profil-Aktions-Bit 13. Wenn dieses Bit gesetzt ist, dann wird das Paket bei Schritt 42-6 fallen gelassen. Nach dem Fallenlassen des Pakets, oder wenn das Bit 13 zu anfangs nicht gesetzt ist, fährt die Logik damit fort, irgendwelche ungeprüften Masken zu überprüfen, indem sie die Logikschritte für die ungeprüften Masken beginnend bei Schritt 33-1 wiederholt.
  • Nun wird Rückbezug auf die 32 bei Schritt 32-12 genommen. Wenn das Paket als außerhalb des Profils liegend (Außer-Profil) beurteilt wird, dann werden die Außer-Profil-Aktionen in Übereinstimmung mit 44 durchgeführt. Die Außer-Profil-Aktionen beginnen bei Schritt 44-1, bei dem die Filterungs-/Flusskontrolllogik eine Überprüfung durchführt, um zu sehen, ob das Außer-Profil-Aktions-Bit 0 gesetzt ist. Wenn dieses Bit gesetzt ist, dann wird das Paket zu der CPU gesendet und das Bit 0 der CPU-Opcodes wird gesetzt, bevor die Logik weiter zu Schritt 44-3 geht. Wenn das Außer-Profil-Aktions-Bit 0 nicht gesetzt ist, dann geht die Logik weiter zu Schritt 44-3, ohne dass sie irgendeine Aktion bei dem Paket durchführt. Beim Schritt 44-3 führt die Filterungs-/Flusskontrolllogik eine Überprüfung durch, um zu sehen, ob das Bit 1 der Außer-Profil-Aktions-Bits gesetzt ist. Wenn dieses Bit gesetzt ist, dann wird das Paket fallen gelassen, bevor die Logik durch die restlichen Aktions-Bits weitergeht. Aber wenn das Bit 1 nicht gesetzt ist, dann geht die Logik einfach weiter zu Schritt 44-5, ohne irgendeine Aktion durchzuführen. Beim Schritt 44-5 überprüft die Logik das Aktions-Bit 2, und wenn dieses Bit gesetzt ist, dann ruft die Logik bei Schritt 44-6 den DSCP aus dem out-DSCP Feld der Regel ab, wenn die TOS unmodifiziert ist. Die IP-Prüfsumme wird ebenfalls bei Schritt 44-6 neu berechnet, zusammen mit dem Setzen des CRC-Regenerate-Bits. Nach der Vollendung der Aktionen, die mit dem Aktions-Bit 2 assoziiert sind, oder wenn das Bit 2 nicht gesetzt ist, geht die Logik weiter zu Schritt 44-7, bei dem das Aktions-Bit 3 des Aktionsfeldes überprüft wird. Wenn das Bit gesetzt ist, dann wird bei Schritt 44-8 das Fallenlassen-Vorrangsbit gesetzt, und das CNG-Bit wird in dem P-Kanal gesetzt. Nach dem Durchführen dieser Aktionen, oder wenn das Aktions-Bit 3 nicht zu anfangs gesetzt ist, geht die Logik weiter zu Schritt 44-9, bei dem das Bit 4 überprüft wird. Wenn das Bit 4 gesetzt ist, dann wird das Paket bei dem Schritt 44-10 trotz der vorhergehenden Aktions-Bits nicht fallen gelassen. Wenn das Bit 4 nicht gesetzt ist, dann werden alle vorher ausgeführten Aktions-Bits, die das Paket fallen lassen würden, nicht modifiziert, und das Paket darf fallen gelassen werden. Bei Schritt 44-11 sind die Außer-Profil-Aktionen für eine Maske fertiggestellt und die Logik stellt fest, ob es irgendwelche anderen Masken zum Vergleichen gibt. Wenn es weitere Masken gibt, dann fährt die Logik bei Schritt 32-1 in 32 mit der nächsten Maske fort. Wenn es keine Masken mehr zur Durchsicht gibt, dann fährt die Logik mit dem Schritt 43-1 in 43 fort.
  • Allgemein gesprochen sollte es angemerkt werden, dass das Blockdiagramm des SOC 10 in 2 jeden GPIC 30 so veranschaulicht, dass dieser seine eigenen ARL-/L3-Tabellen 31, Regeltabelle 32 und VLAN-Tabellen 33 aufweist, und auch dass jeder EPIC 20 ebenfalls seine eigenen ARL-/L3-Tabellen 21, Regeltabelle 22 und VLAN-Tabellen 23 aufweist. Aber es wird innerhalb der vorliegenden Erfindung auch in Betracht gezogen, dass zwei separate Module eine gemeinsame ARL-/L3-Tabelle und eine gemeinsame VLAN-Tabelle gemeinsam nutzen können. Aber jedes Modul besitzt im Allgemeinen seine eigene Regeltabelle 22. Deshalb kann zum Beispiel der GPIC 30 die ARL-/L3-Tabelle 21a und die VLAN-Tabelle 23a mit dem EPIC 20a gemeinsam nutzen. In ähnlicher Weise kann der GPIC 30b die ARL-Tabelle 21b und die VLAN-Tabelle 23b mit dem EPIC 20b gemeinsam nutzen. Dieses gemeinsame Nutzen von Tabellen reduziert die Anzahl an Gatter, die benötigt werden, um die Erfindung zu implementieren, und schafft dadurch ein vereinfachtes Nachschlagen und eine vereinfachte Synchronisierung, was unten erörtert werden wird.
  • Tabellensynchronisierung und -alterung
  • Der SOC 10 verwendet ein einzigartiges Verfahren zur Tabellensynchronisierung und -alterung, um zu gewährleisten, dass nur aktuelle und aktive Adressinformationen in den Tabellen verwaltet werden. Wenn die ARL-/L3-Tabellen aktualisiert werden, um eine neue Quelladresse aufzunehmen, wird ein "Treffer-Bit" innerhalb der Tabelle des "Eigentümers" oder des erhaltenden Moduls gesetzt, um anzuzeigen, dass auf die Adresse zugegriffen worden ist. Wenn eine neue Adresse gelernt wird und in die ARL-Tabelle plaziert wird, wird auch eine S-Kanal-Nachricht in den S-Kanal 83 als eine ARL-Einfügenachricht platziert, die alle ARL-/L3-Tabellen auf dem SOC 10 anweist, diese neue Adresse zu lernen. Der Eintrag in den ARL-/L3-Tabellen umfasst eine Identifikation des Ports, der ursprünglich das Paket empfangen hat und die Adresse gelernt hat. Deshalb wird der EPIC 20a dann, wenn der EPIC 20a den Port enthält, der ursprünglich das Paket erhalten hat und der deshalb ursprünglich die Adresse gelernt hat, der "Eigentümer" der Adresse. Deshalb kann nur der EPIC 20a diese Adresse aus der Tabelle löschen. Die ARL-Einfügenachricht wird von allen Modulen empfangen und die Adresse wird allen ARL-/L3-Tabellen auf dem SOC 10 hinzugefügt. Der CMIC 40 wird die Adressinformationen auch zu der CPU 52 senden. Wenn jedes Modul die Adressinformation empfängt und lernt, wird eine Bestätigungs- oder ACK-Nachricht zurück zu dem EPIC 20a gesendet; als der Eigentümer können weitere ARL-Einfügenachrichten von dem EPIC 20a nicht gesendet werden, bis alle ACK-Nachrichten von allen Modulen empfangen worden sind. In einem bevorzugten Ausführungsbeispiel der Erfindung sendet der CMIC 40 keine ACK-Nachricht, da der CMIC 40 auf sich keine Eintritts-/Austrittsmodule umfasst, sondern nur mit der CPU 52 kommuniziert. Wenn mehrere SOC-10-Switches in einer gestapelten Konfiguration bereitgestellt sind, würden aufgrund der Tatsache, dass der CPS-Kanal 80 von allen gestapelten Modulen gemeinsam genutzt werden würde, alle ARL-/L3-Tabellen synchronisiert.
  • Unter Bezugnahme auf 18 wird der ARL-Alterungsprozess diskutiert. Ein Alters-Timer ist in jedem EPIC-Modul 20 und GPIC-Modul 30 bereitgestellt; bei Schritt 18-1 wird festgestellt, ob der Alters-Timer abgelaufen ist. Wenn der Timer abgelaufen ist, beginnt der Alterungsprozess, indem der erste Eintrag in der ARL-Tabelle 21 untersucht wird. Bei Schritt 18-2 wird festgestellt, ob der Port, auf den in dem ARL-Eintrag Bezug genommen wird, zu dem speziellen Modul gehört oder nicht. Wenn die Antwort Nein ist, dann geht der Prozess weiter zu Schritt 18-3, bei dem festgestellt wird, ob dieser Eintrag der letzte Eintrag in der Tabelle ist oder nicht. Wenn die Antwort bei Schritt 18-3 Ja ist, dann wird der Alters-Timer neu gestartet und der Prozess wird bei Schritt 18-4 vollendet. Wenn dies nicht der letzte Eintrag in der Tabelle ist, dann geht der Prozess bei Schritt 18-5 zurück zu dem nächsten ARL-Eintrag. Wenn aber bei Schritt 18-2 festgestellt wird, dass der Port zu diesem speziellen Modul ge hört, dann wird bei Schritt 18-6 festgestellt, ob das Treffer-Bit dort gesetzt ist oder nicht, oder ob dies ein statischer Eintrag ist. Wenn das Treffer-Bit gesetzt ist, wird das Treffer-Bit bei Schritt 18-7 zurückgesetzt, und das Verfahren geht dann weiter zu Schritt 18-3. Wenn das Treffer-Bit nicht gesetzt ist, dann wird der ARL-Eintrag bei Schritt 18-8 gelöscht, und eine ARL-Eintrags-Löschungsnachricht wird auf dem CPS-Kanal zu den anderen Modulen, einschließlich dem CMIC 40, geschickt, so dass die Tabelle entsprechend synchronisiert werden kann, wie dies oben angemerkt worden ist. Dieser Alterungsprozess kann bei den ARL-(Schicht 2)-Einträgen sowie auch bei den Schicht-3-Einträgen durchgeführt werden, um zu gewährleisten, dass veraltete Pakete in geeigneter Weise von den Eigentümern der Einträge aus den Tabellen gelöscht werden. Wie vorher angemerkt worden ist, wird der Alterungsprozess nur bei Einträgen durchgeführt, bei denen der Port, auf den Bezug genommen wird, zu dem bestimmten Modul gehört, das den Alterungsprozess durchführt. Zu diesem Zweck wird das Treffer-Bit deshalb nur in dem Eigentümermodul gesetzt. Das Treffer-Bit wird nicht für Einträge in den Tabellen anderer Module gesetzt, die die ARL-Einfügenachricht erhalten. Das Treffer-Bit wird deshalb in den synchronisierten Nicht-Eigentümer-Tabellen immer auf Null gesetzt.
  • Der Zweck der Quell- und Zielsuchen und der gesamten Nachschlagevorgänge liegt darin, die Portnummer innerhalb des SOC 10 zu identifizieren, zu dem das Paket geleitet werden soll, nachdem es entweder in dem CBP 50 oder dem GBP 50 platziert worden ist. Natürlich führt ein Quell-Nachschlagevorgang-Fehlschlag dazu, dass die Quelle aus der Quellen-MAC-Adressinformation in dem Paket gelernt wird; ein Ziel-Nachschlagevorgang-Fehlschlag führt aber, da kein Port identifiziert werden würde, dazu, dass das Paket zu allen Ports auf dem SOC 10 gesendet wird. Solange die Ziel-VLAN-ID die gleiche ist wie die Quell-VLAN-ID, wird das Paket durch das VLAN voranschreiten und das ultimative Ziel erreichen, wobei an diesem Punkt ein Bestätigungspaket empfangen wird, wodurch die ARL-Tabelle in die Lage versetzt wird, den Zielport zur Verwendung bei nachfolgenden Paketen zu lernen. Wenn die VLAN-INFORMATIONSOFFENLEGUNGSANWEISUNGEN unterschiedlich sind, wird ein L3-Nachschlagevorgang und ein Lernprozess durchgeführt, wie dies vorher erörtert worden ist. Es sollte vermerkt werden, dass jeder EPIC und jeder GPIC eine FIFO-Warteschlange enthält, um ARL-Einfügenachrichten zu speichern, da, obwohl jedes Modul nur eine Nachricht pro Zeitpunkt schicken kann, dann, wenn jedes Modul eine Einfügenachricht schickt, eine Warteschlange für die geeignete Handhabung der Nachrichten bereitgestellt sein muß.
  • Portbewegung
  • Nachdem die ARL-/L3-Tabellen Einträge in sich aufweisen, tritt manchmal die Situation auf, bei der ein bestimmter Benutzer oder eine bestimmte Station die Position von einem Port zu einem anderen Port ändern kann. Um Übertragungsfehler zu vermeiden, umfasst der SOC 10 deshalb Fähigkeiten zur Identifizierung einer solchen Bewegung und zur geeigneten Aktualisierung der Tabelleneinträge. Wenn zum Beispiel die Station A, die sich zum Beispiel am Port 1 befindet, versucht, mit Station B zu kommunizieren, deren Einträge anzeigen, dass sich der Benutzer B am Port 26 befindet, und wenn dann die Station B zu einem anderen Port bewegt wird, zum Beispiel zu dem Port 15, dann wird ein Ziel-Nachschlagevorgang-Fehlschlag auftreten und das Paket wird zu allen Ports gesendet werden. Wenn das Paket von der Station B bei Port 15 empfangen wird, wird die Station B eine Bestätigungsnachricht (ACK-Nachricht) senden, die von dem Eintritt des EPIC-/GPIC-Moduls empfangen werden wird, das darauf den Port 1 enthält. Ein Quell-Nachschlagevorgang (der Bestätigungsnachricht) wird zwar eine Übereinstimmung bei der Quelladresse ergeben, aber die Portinformation wird nicht übereinstimmen. Der EPIC/GPIC, der das Paket von B empfängt, muß deshalb den alten Eintrag aus der ARL-/L3-Tabelle löschen und auch eine ARL-/L3-Löschnachricht auf den S-Kanal senden, so dass alle Tabellen synchronisiert werden. Dann wird die neue Quelleninformation mit dem korrekten Port in die ARL-/L3-Tabelle eingefügt, und eine ARL-/L3-Einfügenachricht wird in den S-Kanal platziert, wodurch die ARL-/L3-Tabellen mit der neuen Information synchronisiert werden. Die aktualisierte ARL-Einfügenachricht kann nicht gesendet werden, bis alle Bestätigungsnachrichten, die die ARL-Löschnachricht betreffen, gesendet sind, um eine korrekte Tabellensynchronisierung zu gewährleisten. Wie vorher angemerkt worden ist, können typische ARL-Einfüge- und -Löschbefehle nur von dem Eigentümermodul initiiert werden. In dem Falle der Portbewegung aber können die auf die Portbewegung bezogenen Lösch- und Einfügenachrichten von jedem Modul initiiert werden, da die Portbewegung von irgendeinem Modul identifiziert werden kann, das ein Paket zu einem bewegten Port sendet.
  • Trunking
  • Während des Konfigurationsprozesses, bei dem ein lokales Netzwerk von einem Administrator mit einer Vielzahl von Switches, etc., konfiguriert wird, können zahlreiche Ports "gebündelt" werden, um die Bandbreite zu erhöhen. Wenn zum Beispiel der Verkehr zwischen einem ersten Switch SW1 und einem zweiten Switch SW2 als hoch zu erwarten ist, dann kann das LAN so konfiguriert werden, dass eine Vielzahl von Ports, zum Beispiel die Ports 1 und 2, miteinander verbunden werden können. In einer Umgebung von 100 Megabit pro Sekunde stellt das Bündeln (Trunking) von zwei Ports effektiv eine erhöhte Bandbreite von 200 Megabit pro Sekunde zwischen den beiden Ports bereit. Die beiden Ports 1 und 2 werden deshalb als eine "Trunk Group" (Leitungsbündel) identifiziert, und die CPU 52 wird verwendet, um die Handhabung der Trunk Group korrekt zu konfigurieren. Wenn eine Trunk Group identifiziert ist, wird sie als eine Vielzahl von Ports behandelt, die als ein logischer Port arbeiten. 19 veranschaulicht eine Konfiguration, bei der der SW1, der eine Vielzahl von Ports darauf enthält, eine Trunk Group mit Port 1 und Port 2 von SW2 aufweist, wobei die Trunk Group zwei Kommunikationsleitungen sind, die jeweils die Ports 1 und 2 jedes SW1 und SW2 verbinden. Dadurch wird die Trunk Group T gebildet. In diesem Beispiel versucht die Station A, die mit dem Port 3 des SW1 verbunden ist, mit der Station B, die sich bei dem Port 26 des Switch SW2 befindet, zu kommunizieren oder dieser ein Paket zu senden. Das Paket muß deshalb durch die Trunk Group T von dem Port 3 des SW1 zu dem Port 26 des SW2 wandern. Es sollte angemerkt werden, dass die Trunk Group jede Anzahl von Ports zwischen den Switches umfassen kann. Wenn der Verkehrsfluss zwischen SW1 und SW2 ansteigt, könnte die Trunk Group T von dem Administrator derart neu konfiguriert werden, dass sie mehr Ports umfasst, wodurch die Bandbreite effektiv gesteigert wird. Zusätzlich zu der Bereitstellung einer erhöhten Bandbreite stellt das Trunking eine Redundanz in dem Fall eines Versagens einer der Verbindungen zwischen den Switches bereit. Wenn die Trunk Group erzeugt ist, programmiert ein Benutzer den SOC 10 durch die CPU 52 mit der Trunk Group Identifikations-(TGID)-Information, damit die entsprechende Trunk Group bzw. die entsprechenden Trunk Groups erkannt werden können. Eine Trunk Group Port-Bitmap wird für jede TGID vorbereitet; und eine Trunk Group Tabelle, die für jedes Modul auf dem SOC 10 bereitgestellt ist, wird verwendet, um die Trunk Group zu implementieren, die auch ein Port-Bündel genannt werden kann. Eine Trunk Group Bitmap-Tabelle ist ebenfalls bereitgestellt. Diese beiden Tabellen werden auf einer pro Modul Basis bereitgestellt und werden wie die Tabellen 21, 22 und 23 in Silizium als zweidimensionale Arrays implementiert. In einem Ausführungsbeispiel des SOC 10 können sechs Trunk Groups unterstützt werden, wobei jede Trunk Group bis zu acht Trunk Ports darauf aufweist. Aber zur Kommunikation muß der gleiche Port für den Paketfluss verwendet werden, um ein Durcheinanderbringen der Ordnung der Pakete oder Rahmen zu verhindern. Die Identifikation, welcher Port zur Kommunikation verwendet werden wird, basiert auf einer Adresse aus den Folgenden: Quell-MAC-Adresse, Ziel-MAC-Adresse, Quell-IP-Adresse, Ziel-IP-Adresse, oder aus Kombinationen aus Quell- und Zieladressen. Wenn als ein Beispiel die Quell-MAC verwendet wird, dann werden dann, wenn die Station A auf dem Port 3 des SW1 ein Paket zu der Station B auf dem Port 26 des SW2 senden will, die letzten drei Bits der Quell-MAC-Adresse von Station A, die sich in dem Source Address Feld des Pakets befinden, dazu verwendet, einen Trunk Port Index zu erzeugen. Der Trunk Port Index wird dann von dem Eintritts-Submodul 14 auf dem bestimmten Port auf dem Switch in der Trunk Group Tabelle nachgeschlagen, um festzustellen, welcher Port der Trunk Group für die Kommunikation verwendet werden wird. Mit anderen Worten, wenn ein Paket von der Station A zu der Station B gesendet werden soll, dann wird die Adressauflösung durchgeführt, wie dies oben erläutert worden ist. Wenn das Paket durch eine Trunk Group gehandhabt werden soll, dann wird ein T-Bit in dem ARL-Eintrag gesetzt, der mit der Zieladresse abgeglichen wird. Wenn das T-Bit oder das Trunk Bit gesetzt ist, dann wird die Zieladresse aus einem der Trunk Ports gelernt. Der Austrittsport wird daher nicht von der Portnummer gelernt, die in dem ARL-Eintrag enthalten ist, sondern wird stattdessen aus der Trunk Group ID und dem Regel-Tag (RTAG) gelernt, das aus dem ARL-Eintrag erfasst wird, und das dazu verwendet werden kann, den Trunk Port auf der Grundlage des Trunk Port Index zu identifizieren, der in der Trunk Group Tabelle enthalten ist. Das RTAG und die TGID, die in dem ARL-Eintrag enthalten sind, definieren deshalb, welcher Teil des Pakets dazu verwendet werden soll, den Trunk Port Index zu erzeugen. Wenn zum Beispiel der RTAG-Wert 1 ist, dann werden die letzten drei Bits der Quell-MAC-Adresse dazu verwendet, den Trunk Port Index zu identifizieren; unter Verwendung der Trunk Group Tabelle kann der Trunk Port Index dann dazu verwendet werden, den geeigneten Trunk Port für die Kommunikation zu identifizieren. Wenn der RTAG-Wert 2 ist, dann sind es die letzten drei Bits der Ziel-MAC-Adresse, die zur Erzeugung des Trunk Port Index verwendet werden. Wenn der RTAG-Wert 3 ist, dann werden die letzten drei Bits der Quell-MAC-Adresse einem exklusiven ODER mit den letzten drei Bits der Ziel-MAC-Adresse unterzogen. Das Ergebnis dieser Operation wird dazu verwendet, den Trunk Port Index zu erzeugen. Für IP-Pakete werden zusätzliche RTAG-Werte verwendet, so dass anstatt der MAC-Adressen die Quell-IP- und die Ziel-IP-Adressen für den Trunk Port Index verwendet werden.
  • Der SOC 10 ist so konfiguriert, dass dann, wenn ein Trunk Port nachlässt oder aus irgendwelchen Gründen versagt, eine Benachrichtigung durch den CMIC 40 zu der CPU 52 gesendet wird. Die CPU 52 ist dann so konfiguriert, dass sie automatisch die Trunk Group Tabelle und die VLAN-Tabellen überprüft, um sicherzugehen, dass die zugehörigen Port-Bitmaps geändert werden, um die Tatsache zu reflektieren, dass ein Port nachlässt und deshalb entfernt wird. In ähnlicher Weise muß dann, wenn der Trunk Port oder die Verbindung erneut eingerichtet wird, der Prozess umgedreht werden, und eine Nachricht muß zu der CPU 52 gesendet werden, so dass die VLAN-Tabellen, die Trunk Group Tabellen etc. aktualisiert werden können, um das Vorhandensein des Trunk Ports zu reflektieren.
  • Des Weiteren sollte es angemerkt werden, dass, da die Trunk Group als eine einzelne logische Verbindung behandelt wird, die Trunk Group so konfiguriert ist, dass sie Steuerrahmen oder Steuerpakete, die auch als BPDUs bekannt sind, nur an einem der Trunk Ports akzeptiert. Die portbasierte VLAN-Tabelle muß deshalb so konfiguriert sein, dass sie ankommende BPDUs von nicht spezifizierten Trunk Ports zurückweist. Diese Zurückweisung kann ohne weiteres durch das Setzen eines B-Bits in der VLAN-Tabelle eingestellt werden. Der IEEE Standard 802.1d definiert einen Algorithmus, der als der Spannbaum-Algorithmus bekannt ist und der zur Vermeidung von Datenschleifen in Switches dient, in denen Trunk Groups existieren. Unter Bezugnahme auf 19 könnte eine logische Schleife zwischen den Ports 1 und 2 und den Switches SW1 und SW2 bestehen. Der Spannbaum-Algorithmus definiert vier separate Zustände, wobei diese Zustände das Deaktivieren, Blockieren, Belauschen, Lernen und Weiterleiten umfassen. Die portbasierte VLAN-Tabelle ist so konfi guriert, dass sie die CPU 52 in die Lage versetzt, die Ports für einen spezifischen ARL-Zustand zu programmieren, so dass die ARL-Logik bei den ankommenden Paketen die geeignete Aktion unternimmt. Wie vorher angemerkt worden ist, stellt das B-Bit in der VLAN-Tabelle die Fähigkeit bereit, BPDUs zurückzuweisen. Das St-Bit in der ARL-Tabelle ermöglicht es der CPU, die statischen Einträge zu lernen; wie in 18 angemerkt ist, werden statische Einträge von dem Alterungsprozess nicht gealtert. Das Treffer-Bit in der ARL-Tabelle ermöglicht es der ARL-Maschine 143 zu erfassen, ob bei diesem Eintrag ein Treffer existiert hat oder nicht, wie dies vorher erwähnt worden ist. Mit anderen Worten, der SOC 10 verwendet eine einzigartige Konfiguration von ARL-Tabellen, VLAN-Tabellen, Modulen, etc., um eine effiziente siliziumbasierte Implementierung der Spannbaum-Zustände bereitzustellen.
  • In bestimmten Situationen, wie etwa einem Ziel-Nachschlagevorgang-Fehlschlag (DLF), bei dem ein Paket zu allen Ports in einem VLAN gesendet wird, oder einem Multicast-Paket, ist die Trunk Group Bitmap-Tabelle so konfiguriert, dass sie die geeigneten Portinformationen abruft, so dass das Paket nicht zurück zu den Mitgliedern der gleichen Quell-Trunk Group gesendet wird. Dies verhindert einen unnötigen Verkehr in dem LAN und hält die Effizienz an der Trunk Group aufrecht.
  • IP/IPX
  • Unter erneuter Bezugnahme auf 14 kann jeder EPIC 20, GPIC 30 oder IPIC 90 so konfiguriert sein, dass er eine Unterstützung von sowohl IP- als auch IPX-Protokollen bei Leitungsgeschwindigkeit ermöglicht. Diese Flexibilität wird bereitgestellt, ohne dass dies irgendeine negative Auswirkung auf die Systemperformanz hat, und sie verwendet eine in Silizium implementierte Tabelle, die für das IP-Protokoll, das IPX-Protokoll oder eine Kombination aus IP-Protokoll und IPX-Protokoll ausgewählt werden kann. Diese Fähigkeit ist innerhalb einer Logikschaltung 1411 bereitgestellt und verwendet ein "IP Longest Prefix Cache"-Nachschlagen (IP_LPC) und ein "IPX Longest Prefix Cache"-Nachschlagen (IPX_LPC). Während des Schicht-3-Nachschlagevorgangs wird eine Reihe von im gleichen Zeitintervall ablaufenden Durchsuchungen durchgeführt; ein schneller L3-Nachschlagevorgang und der IP Longest Prefix Cache-Nachschlagevorgang werden gleichzeitig durchgeführt, wenn das Paket von dem Paket-Header als ein IP-Paket identifiziert worden ist. Wenn der Paket-Header das Paket als ein IPX-Paket identifiziert, werden der schnelle L3-Nachschlagevorgang und der IPX Longest Prefix Cache-Nachschlagevorgang gleichzeitig durchgeführt. Es sollte angemerkt werden, dass die ARL-/L3-Tabellen 21/31 der EPICs 20 und der GPICs 30 eine IP-Standard-Routertabelle umfassen, die für einen IP Longest Prefix Cache-Nachschlagevorgang verwendet wird, wenn das Paket als ein IP-Paket identifiziert wird, und auch eine IPX-Standard-Routertabelle umfasst, die verwendet wird, wenn der Paket-Header das Paket als ein IPX-Paket identifiziert. Geeignete Hexadezimalcodes werden verwendet, um die Pakettypen zu bestimmen. Wenn das Paket weder als ein IP-Paket, noch als ein IPX-Paket identifiziert wird, wird das Paket über den CPS-Kanal 80 und den CMIC 40 zu der CPU 52 geleitet. Es sollte angemerkt werden, dass dann, wenn das Paket als ein IPX-Paket identifiziert wird, es irgendeines von vier Typen von IPX-Paketen sein kann. Diese vier Typen sind, wie vorher angemerkt worden ist, Ethernet 802.3, Ethernet 802.2, Ethernet SNAP und Ethernet II.
  • Die gleichzeitigen Nachschlagevorgänge von L3 und entweder IP oder IPX sind wichtig für die Performanz des SOC 10. In einem Ausführungsbeispiel des SOC 10 würde die L3-Tabelle als die Standard-Routertabellen einen Abschnitt umfassen, der IP-Adressinformationen aufweist, und einen anderen Abschnitt aufweisen, der IPX-Informationen aufweist. Diese Standard-Routertabellen werden, wie vorher angemerkt worden ist, in Abhängigkeit davon durchsucht, ob das Paket ein IP-Paket oder ein IPX-Paket ist. Um die Tabellen deutlicher zu veranschaulichen, ist das L3-Tabellen-Format für eine L3-Tabelle innerhalb der ARL-/L3-Tabellen 21 wie folgt:
    • IP or IPX Address – 32 Bits lang – IP- oder IPX-Adresse – ist eine 32 Bit IP- oder IPX-Adresse. Die Ziel-IP- oder -IPX-Adresse in einem Paket wird als ein Schlüssel bei der Durchsuchung dieser Tabelle verwendet.
    • Mac Address – 48 Bits lang – Die MAC-Adresse ist eigentlich die Folgesprung-MAC-Adresse (next Hop MAC Address). Diese MAC-Adresse wird als die Ziel-MAC-Adresse in dem weitergeleiteten IP-Paket verwendet.
    • Port Number – 6 Bits lang – Portnummer – Ist die Portnummer, bei der das Paket hinausgehen soll, wenn die Ziel-IP-Adresse mit der IP-Adresse dieses Eintrags übereinstimmt.
    • L3 Interface Num – 5 Bits lang – L3 Schnittstellennummer – Diese L3-Schnittstellennummer wird verwendet, um die Router-MAC-Adresse aus der L3-Schnittstellentabelle zu bekommen.
    • L3 Hit Bit – 1 Bit lang – L3 Treffer-Bit – Wird verwendet, um zu überprüfen, ob bei diesem Eintrag ein Treffer vorliegt. Das Treffer-Bit ist gesetzt, wenn die Quell-IP-Adress-Suche mit diesem Eintrag übereinstimmt. Der L3-Alterungsprozess altert den Eintrag, wenn dieses Bit nicht gesetzt ist.
    • Frame Type – 2 Bits lang – Der Rahmentyp gibt den Typ des IPX-Rahmens (802.2, Ethernet II, SNAP und 802.3) an, der von diesem IPX-Knoten akzeptiert wird. Wert 00 – Ethernet II Rahmen. Wert 01 – SNAP Rahmen. Wert 02 – 802.2 Rahmen. Wert 03 – 802.3 Rahmen.
    • Reserved – 4 Bits lang – Reserviert für zukünftige Verwendung.
  • Die Felder der Standard-IP-Routertabelle sind wie folgt:
    • IP Subnet Address-32 Bits lang – IP-Subnetzadresse – Ist eine 32 Bit IP-Adresse des Subnetzes.
    • Mac Address – 48 Bits lang – Die MAC-Adresse ist eigentlich die Folgesprung-MAC-Adresse (next Hop MAC Address), und in diesem Fall ist sie die MAC-Adresse des Standard-Routers.
    • Port Number – 6 Bits lang – Die Port Number ist die Nummer des Ports, bei dem das weitergeleitete Paket hinausgehen soll.
    • Module ID – 5 Bits lang – Identifiziert das Modul in einem Stapel, durch das das Paket nach einer Longest-Prefix-Übereinstimmung hinausgehen muß.
    • L3 Interface Num – 5 Bits lang – L3 Interface Num ist die L3-Schnittstellennummer.
    • IP Subnet Bits – 5 Bits lang – Die IP-Subnetz-Bits ist die gesamte Anzahl von Subnetz-Bits in der Subnetz-Maske. Diese Bits werden mit der Ziel-IP-Adresse vor dem Vergleich mit der Subnetz-Adresse einem UND unterzogen.
    • C Bit – 1 Bit lang – C-Bit – Wenn dieses Bit gesetzt ist, dann wird das Paket auch zu der CPU gesendet.
  • Die Felder der Standard-IPX-Routertabelle innerhalb der ARL-/L3-Tabellen 21 sind wie folgt:
    • IPX Subnet Address – 32 Bits lang – Die IPX-Subnetz-Adresse ist eine 32 Bit IPX-Adresse des Subnetzes.
    • Mac Address – 48 Bits lang – Die MAC-Adresse ist eigentlich die Folgesprung-MAC-Adresse, und in diesem Fall ist sie die MAC-Adresse des Standard-Routers.
    • Port Number – 6 Bits lang – Die Port Number ist die Nummer des Ports, bei dem das weitergeleitete Paket hinausgehen soll.
    • Module ID – 5 Bits lang – identifiziert das Modul in dem Stapel, bei dem das Paket nach einer Longest-Prefix-Übereinstimmung hinausgehen soll.
    • L3 Interface Num – 5 Bits lang – L3 Interface Num ist die L3-Schnittstellennummer.
    • IPX Subnet Bits – 5 Bits lang – Die IPX-Subnetz-Bits sind die gesamte Anzahl an Subnetz-Bits in der Subnetz-Maske. Diese Bits werden mit der Ziel-IPX-Adresse vor dem Vergleich mit der Subnetz-Adresse einem UND unterzogen.
    • C Bit – 1 Bit lang – C-Bit – Wenn dieses Bit gesetzt ist, dann wird das Paket auch zu der CPU gesendet.
  • Wenn in der L3-Tabelle für die Ziel-IP-Adresse keine Übereinstimmung gefunden wird, schlägt die Longest Prefix Übereinstimmung in dem Standard-IP-Router fehl; dann wird das Paket zu der CPU gegeben. In ähnlicher Weise wird, wenn in der L3-Tabelle für eine Ziel-IPX-Adresse keine Übereinstimmung gefunden wird und die Longest-Prefix-Übereinstimmung in dem Standard-IPX-Router fehlschlägt, das Paket zu der CPU gegeben. Die Nachschlagevorgänge werden parallel durchgeführt, aber wenn die Ziel-IP- oder – IPX-Adresse in der L3-Tabelle gefunden wird, dann werden die Ergebnisse des Standard-Routertabellen-Nachschlagevorgangs aufgegeben.
  • Der Longest Prefix Cache-Nachschlagevorgang, egal ob für IP oder IPX, umfasst wiederholte Abgleichversuche von Bits der IP-Subnetz-Adresse. Der Longest-Prefix-Abgleich besteht darin, die Ziel-IP-Adresse mit der Anzahl an IP- oder IPX-Subnetz-Bits einem UND zu unterziehen und das Ergebnis mit der IP-Subnetz-Adresse zu vergleichen. Wenn eine Longest-Prefix-Übereinstimmung gefunden wird, dann werden, solange die TTL nicht gleich eins ist, die geeigneten IP-Prüfsummen neu berechnet, die Ziel-MAC-Adresse wird durch die Folgesprung-MAC-Adresse ersetzt, und die Quell-MAC-Adresse wird durch die Router-MAC-Adresse der Schnittstelle ersetzt. Die VLAN-ID wird aus der L3-Schnittstellentabelle erhalten, und das Paket wird dann je nach Zweckdienlichkeit entweder mit Tag oder ohne Tag versehen gesendet. Wenn das C-Bit gesetzt ist, wird eine Kopie des Pakets zu der CPU gesendet, was für Lernfunktionen oder andere CPU-bezogene Funktionen eventuell notwendig sein kann.
  • Es sollte deshalb angemerkt werden, dass dann, wenn ein Paket ankommt, das für eine MAC-Adresse bestimmt ist, die mit einer Schicht-3-Schnittstelle für ein ausgewähltes VLAN assoziiert ist, der Eintritt nach einer Übereinstimmung bei einer IP-/IPX-Ziel-Subnetz-Schicht sucht. Wenn keine IP-/IPX-Ziel-Subnetz-Übereinstimmung vorliegt, wird das Paket für ein geeignetes Routing zu der CPU 52 weitergeleitet. Aber wenn eine IP-/IPX-Übereinstimmung erfolgt, dann wird die MAC-Adresse des Folgesprungs und die Austritts-Portnummer identifiziert und das Paket wird in geeigneter Weise weitergeleitet.
  • Mit anderen Worten, der Eintritt des EPIC 20 oder GPIC 30 ist im Hinblick auf die ARL-/L3-Tabellen 21 so konfiguriert, dass dann, wenn ein Paket in das Eintritts-Submodul 14 eintritt, der Eintritt identifizieren kann, ob das Paket ein IP-Paket oder ein IPX-Paket ist oder nicht. Die IP-Pakete werden zu einem IP-/ARL-Nachschlagevorgang geleitet, und die IPX-konfigurierten Pakete werden zu einem IPX-/ARL-Nachschlagevorgang geleitet. Wenn während des L3-Nachschlagevorgangs eine L3-Übereinstimmung gefunden wird, dann werden die Nachschlagevorgänge der Longest-Prefix-Übereinstimmung aufgegeben.
  • IP Multicast
  • Der SOC 10 ist so konfiguriert, dass er IP-Multicast-Anwendungen, wie etwa die Multimedia-Konferenz, Echtzeit-Video, Echtzeit-Audio, etc., unterstützen kann. Diese Anwendungen sind in hohem Maße von der Punkt-zu-Mehrpunkt-Übermittlung von Diensten abhängig. Einige IP-Protokolle, die entwickelt worden sind, um IP Multicast zu unterstützen, umfassen das DVMRP (Distance Vector Multicast Routing Protocol), den Protocol-Independent Multicast Dense Mode, den Protocol Independent Multicast-Sparse Mode, Multicast-Erweiterungen zu SOSPF, etc.. Um solche Konfigurationen zu implementieren, ist jeder EPIC, GPIC und mögliche andere Module auf dem SOC 10 mit einer IP-Multicast-Tabelle versehen. Die Eintrittslogik 14 und die Austrittslogik 16 sind so konfiguriert, dass sie IP-Multicast-Pakete handhaben können.
  • Jede Multicast-Tabelle kann zum Beispiel 256 Einträge tief und 128 Bits breit sein. Die Tabelle ist sortiert, und der Suchschlüssel ist die Quell-IP-Adresse plus die Multicast-IP-Adresse. 24 veranschaulicht das Format für eine IP-Multicast-Tabelle. Die Felder für eine solche Tabelle können folgendermaßen sein:
    • Source IP Address – 32 Bits lang – Die Quell-IP-Adresse ist eine 32 Bit IP-Adresse der Quellstation.
    • Multicast IP Address – 32 Bits lang – Multicast-IP-Adresse – Ist eine 32 Bit IP Multicast Adresse. Merke: Die IP-Multicast-Adresse ist eine Klasse-D-Adresse; die ersten drei MSBs sind alle 1en.
    • L3 Port Bitmap – 31 Bits lang – Die L3-Port-Bitmap identifiziert alle Ports, auf denen das Paket hinausgehen soll.
    • L3 Module Bitmap – 32 Bits lang – Die L3-Modul-Bitmap identifiziert alle Module, auf denen das Paket hinausgehen soll.
    • Source Port – 6 Bits lang – Der Quellport ist der Port, der der Quellstation am nächsten liegt. Mit anderen Worten, die Quellstation, die von der Quell-IP-Adresse identifiziert ist, sendet Multicast-Verkehr durch diesen Port.
    • TTL Threshold – 5 Bits lang – Wenn das ankommende Multicast-Paket einen TTL unterhalb des TTL-Schwellwerts aufweist, dann wird das Paket fallengelassen.
  • 25 veranschaulicht ein Flussdiagramm, das zeigt, wie ein Eintritt 14 eines SOC 20 ein IP-Multicast-Paket handhaben würde, das bei einem Port darauf eintritt. Im Schritt 25-1 wird das Paket untersucht, um festzustellen, ob es ein IP-Multicast-Paket ohne jegliche Optionsfelder ist oder nicht. Wenn Optionsfelder vorhanden sind, wird das Paket für die weitere Handhabung zu der CPU 52 gesendet. Im Schritt 52-2 wird die IP-Prüfsumme validiert. Im Schritt 25-3 wird die Ziel-IP-Adresse untersucht, um zu sehen, ob sie eine Klasse-D-Adresse ist. Eine Klasse-D-Adresse ist eine Adresse, bei der die drei höchstwertigen Bits alle auf 1 gesetzt sind. Wenn die Ziel-IP-Adresse keine Klasse-D-Adresse ist, dann wird das Paket fallengelassen. Falls es eine Klasse-D-Adresse ist, wird die IP-Multicast-Tabelle bei Schritt 25-4 mit dem Schlüssel aus der Quell-IP-Adresse + der Ziel-IP-Adresse durchsucht. Wenn der Eintrag nicht gefunden wird, dann wird das Paket zu der CPU 52 gesendet. Wenn bei Schritt 25-5 eine Übereinstimmung gefunden wird, wird bei Schritt 25-6 die TTL (time-to-live) gegenüber dem TTL-Schwellwert-Wert in dem IP-Multicast-Eintrag überprüft. Wenn der TTL-Wert kleiner als der Schwellwert ist, dann wird das Paket fallengelassen. Wenn der TTL-Wert nicht unterhalb des Schwellwerts liegt, dann wird der Quellport bei Schritt 25-7 mit dem Quellport in dem Eintrag verglichen. Wenn keine Übereinstimmung vorliegt, wird das Paket fallengelassen. Wenn eine Übereinstimmung vorliegt, wird das Paket bei Schritt 25-8 in geeigneter Weise über den C-Kanal 81 des CPS-Kanals 80 gesendet, wobei geeignete P-Kanal-Nachrichten damit festgelegt sind. Das Paket wird mit der L2-Port-Bitmap und der L2-Bitmap ohne Tags, die als ein Ergebnis der L2-Suche erhalten wurden, und der L3-Port-Bitmap als ein Ergebnis der IP-Multicast-Suche gesendet. Außerdem wird das IP-Multicast-Bit in der P-Kanal-Nachricht gesetzt, das anzeigt, dass das Paket ein IP-Multicast-Paket ist und dass der Austritt beim Empfang des Pakets den IP-Header in geeigneter Weise modifizieren muß. Aus dem CPS-Kanal 80 wird das Paket daher zu dem geeigneten Pufferspeicherpool gesendet, bis es von dem geeigneten Austrittsport erhalten wird.
  • Wenn der geeignete Austrittsport das Paket von dem Speicher erhält, dann muß das Paket modifiziert werden, falls der Austrittsport Teil der L3-Port-Bitmap ist. Der TTL-Wert muß dekrementiert werden, und die IP-Header-Prüfsumme wird neu berechnet. Die Quell-MAC-Adresse in dem Paket muß so geändert werden, dass sie die L3-Schnittstellen-MAC-Adresse ist. Wenn die L3-Schnittstelle, die mit dem Port assoziiert ist, mit Tags versehen ist, dann muß der VLAN-Tag-Header durch die VLAN-ID ersetzt werden, die für die Schnittstelle konfiguriert ist.
  • Es sollte angemerkt werden, dass dann, wenn es mehrere L3-Schnittstellen gibt, die mit einem Port assoziiert sind, mehrere Pakete zu diesem Port gesendet werden müssen. Das CPU-Bit in dem IP-Multicast-Eintrag kann in dieser Situation gesetzt sein, so dass das Paket zusammen mit der Port-Bitmap, auf der das Paket bereits gesendet worden ist, zu der CPU gegeben wird. Die CPU kann dann mehrere Kopien des Pakets auf den Port mit den mehreren L3-Schnittstellen senden. Diese Konfiguration minimiert deshalb die Komplexität und maximiert die Geschwindigkeit auf dem SOC 10, stellt aber auch die hinzugefügte Flexibilität der CPU-Einbeziehung bereit, wenn dies notwendig sein sollte.
  • Ein weiteres wichtiges Feld des Filtermaskenformats ist der Zählerindex (counter index) oder das Zählerfeld (counter field). Dieses Feld aus fünf Bits wird jedes mal dann inkrementiert, wenn eine Übereinstimmung mit der speziellen Filtermaske vorliegt. Die Zählerdaten werden für eine Reihe von unterschiedlichen Zwecken verwendet, die das Finden von Paketzählungen für bestimmte Typen von Paketen, Paketstatistiken, etc. einschließen. Wenn ein Netzwerk-Administrator zum Beispiel versucht, eine bestimmte Rate eines bestimmten Pakettyps oder eine Paketfrequenz oder Pakete von einer speziellen IP-Adresse zu überwachen, kann der Zähler so konfiguriert sein, dass er entsprechend inkrementiert wird. Schwellwerte können von dem Netzwerk-Administrator so festgelegt werden, dass eine vorbestimmte Aktion durchgeführt werden kann, nachdem ein ausgewählter Schwellwert überschritten wird. Eine solche Aktion kann das Ändern der Priorität der Pakete, das Fallenlassen weiterer Pakete und andere Aktionen umfassen.
  • Bemerkenswerte Aspekte des Regeltabellenformats für den SOC 10 sind Felder von Aktions-Bits, die es ermöglichen, dass die Priorität oder der Vorrang von TOS zu COS und umgekehrt geändert werden kann. Unter Bezugnahme auf die Regeltabelle, die in 23 veranschaulicht ist, und das Filtermaskenformat ermöglichen die Bits 8 und 9 des Action Bit Feldes diese Umwandlung. Wenn das Bit 8 gesetzt ist, dann wird das 802.1p Priority Feld aus dem TOS Precedence Feld in dem IP-Header erfasst. Wenn das Bit 9 gesetzt ist, dann wird der Wert des TOS Precedence Feldes aus dem 802.1p Priority Feld erfasst. Dies stellt den signifikanten Vorteil bereit, dass wertvolle Informationen bereitgestellt werden, die sowohl von Routern als auch von Switches gelesen werden können. Switches, die in der Schicht 2 arbeiten, werden das 802.1p Priority Feld prüfen, während Router, die bei Schicht 3 arbeiten, das TOS Precedence Feld prüfen werden. Wenn ein Paket den Switch-Bereich aus dem Router-Bereich in einem LAN betritt, dann kann der Vorrang durch den SOC 10 in geeigneter Weise von dem 802.1p Priority Feld zu dem TOS Precedence Feld bewegt werden und umgekehrt.
  • HOL-Blockierung
  • Der SOC 10 enthält einige einzigartige Datenflusscharakteristiken, um die Effizienz und die Vermittlungsgeschwindigkeit zu maximieren. In Netzwerk-Kommunikationen tritt ein Konzept, das als Head-of-Line- oder HOL-Blockierung bekannt ist, dann auf, wenn ein Port versucht, ein Paket zu einem überlasteten Port zu senden und wenn sich sofort nach diesem Paket ein weiteres Paket befindet, das zu einem nicht überlasteten Port gesendet werden soll. Die Überlastung an dem Zielport des ersten Pakets würde zu einer Verzögerung des Transfers des zweiten Pakets zu dem nicht überlasteten Port führen. Jeder EPIC 20, GPIC 30 und IPIC 90 innerhalb des SOC 10 umfasst einen einzigartigen HOL-Blockierungs-Mechanismus, um den Durchsatz zu maximieren und die negativen Auswirkungen zu minimieren, die ein einzelner überlasteter Port auf den Verkehr ausüben würde, der zu den nicht überlasteten Ports geht. Wenn zum Beispiel ein Port auf einem GPIC 30 mit einer Datenrate von zum Beispiel 1000 Megabit pro Sekunde versucht, Daten zu einem anderen Port 24a auf dem EPIC 20a zu senden, wäre der Port 24a sofort überlastet. Jeder Port auf jedem IPIC 90, GPIC 30 und EPIC 20 ist von der CPU 52 so programmiert, dass er einen hohen Pegel und einen niedrigen Pegel pro Port pro Serviceklasse (COS) im Hinblick auf den Pufferspeicherraum innerhalb des CBP 50 aufweist. Die Tatsache, dass der Head-of-Line-Blockierungs-Mechanismus eine Head-of-Line-Blockierungs-Verhinderung pro Port pro COS ermöglicht, ermöglicht einen effizienteren Datenfluss als denjenigen, der im Stand der Technik bekannt ist. Wenn die Ausgabewarteschlange für einen bestimmten Port den vorprogrammierten hohen Pegel innerhalb des zugeordneten Puffers in dem CBP 50 erreicht, sendet die MMU 70 in dem S-Kanal 83 eine COS-Warteschlagen-Status-Mitteilung zu dem entsprechenden Eintrittsmodul des entsprechenden GPIC 30 oder EPIC 20. Wenn die Nachricht empfangen wird, wird das aktive Portregister, das der COS entspricht, die in der Nachricht angegeben ist, aktualisiert. Wenn das Port-Bit für diesen speziellen Port auf Null gesetzt ist, dann ist der Eintritt so konfiguriert, dass er alle Pakete fallen lässt, die zu diesem Port gehen. Obwohl die fallen gelassenen Pakete eine negative Auswirkung auf die Kommunikation zu dem überlasteten Port haben werden, ermöglicht das Fallenlassen der Pakete, die für überlastete Ports bestimmt sind, dass Pakete, die zu nicht überlasteten Ports gehen, direkt dorthin weitergeleitet werden. Wenn die Ausgabewarteschlange unter den vorprogrammierten niedrigen Pegel geht, sendet die MMU 70 eine COS-Warteschlangen-Status-Mitteilungsnachricht auf dem Seitenbandkanal, wobei das Bit für den Port gesetzt ist. Wenn der Eintritt diese Nachricht erhält, wird das Bit, das dem Port in dem aktiven Portregister für das Modul entspricht, so gesetzt, dass das Paket zu der geeigneten Ausgabewarteschlange gesendet werden kann. Durch das Warten, bis die Ausgabewarteschlange unter den niedrigen Pegel fällt, bevor der Port reaktiviert wird, ist eine Hysterese in das System eingebaut, um eine konstante Aktivierung und Deaktivierung des Ports auf der Grundlage der Weiterleitung nur eines Pakets oder einer kleinen Anzahl von Paketen zu verhindern. Es sollte angemerkt werden, dass jedes Modul ein aktives Portregister aufweist. Als ein Beispiel kann jede COS pro Port vier Register für das Speichern des hohen Pegels und des niedrigen Pegels aufweisen; diese Register können Daten in bezug auf die Anzahl von Zellen in der Ausgabewarteschlange oder in bezug auf die Anzahl von Paketen in der Ausgabewarteschlange speichern. In dem Falle einer Unicast-Nachricht wird das Paket lediglich fallen gelassen; in dem Falle von Multicast- oder Broadcast-Nachrichten wird die Nachricht zwar im Hinblick auf überlastete Ports fallen gelassen, aber zu nicht überlasteten Ports weitergeleitet. Die MMU 70 umfasst die gesamte Logik, die benötigt wird, um diesen Mechanismus zur Verhinderung der HOL-Blockierung im Hinblick auf die Budgetierung von Zellen und Paketen zu implementieren. Die MMU 70 umfasst ein HOL-Blockierungs-Markierungsregister (HOL blocking marker register), um den Mechanismus zu implementieren, der auf Zellen basiert. Wenn die lokale Zellenzählung plus die globale Zellenzählung für einen speziellen Austrittsport den HOL-Blockierungs-Markierungsregister-Wert überschreitet, dann sendet die MMU 70 die HOL-Status-Mitteilungsnachricht. Die MMU 70 kann durch die Verwendung eines Bits in dem MMU-Konfigurationsregister, das als ein Use Advanced Warning Bit bezeichnet wird, auch eine frühe HOL-Mitteilung implementieren. Wenn dieses Bit gesetzt ist, dann sendet die MMU 70 die HOL-Mitteilungsnachricht, wenn die lokale Zellenzählung plus die globale Zellenzählung plus einhunderteinundzwanzig (121) größer als der Wert in dem HOL-Blockierungs-Markierungsregister ist. 121 ist die Anzahl der Zellen in einem Jumbo-Frame.
  • Im Hinblick auf die oben erörterte Hysterese sollte angemerkt werden, dass die MMU 70 sowohl eine räumliche als auch eine zeitliche Hysterese implementiert. Wenn der Wert der lokalen Zellenzählung plus die globale Zellenzählung unter den Wert in dem HOL-Blockierungs-Markierungsregister fällt, dann wird ein Poaching-Timer-Wert aus einem MMU-Konfigurationsregister verwendet, um diesen in einen Zähler zu laden. Der Zähler wird alle 32 Taktzyklen dekrementiert. Wenn der Zähler 0 erreicht, sendet die MMU 70 die HOL-Statusnachricht mit der neuen Port-Bitmap. Das Bit, das dem Austrittsport entspricht, wird auf 0 zurückgesetzt, um anzuzeigen, dass an dem Austrittsport keine HOL-Blockierung mehr vorliegt. Um die HOL-Blockierungs-Verhinderung auf der Grundlage von Paketen durchzuführen, wird ein Skid-Mark-Wert in dem MMU-Konfigurationsregister definiert. Wenn die Anzahl an Transaktionswarteschlangeneinträgen plus dem Skid-Mark-Wert größer als die maximale Transaktionswarteschlangengröße pro COS ist, dann sendet die MMU 70 die COS-Warteschlangen-Statusnachricht in dem S-Kanal. Wenn der Eintrittsport diese Nachricht empfängt, wird der Eintrittsport das Senden von Paketen für diese spezielle Port- und COS-Kombination einstellen. In Abhängigkeit von der Konfiguration und der Paketlänge, die für den Austrittsport empfangen wird, kann entweder die Head-of-Line-Blockierung für den hohen Pegel der Zellen oder die Head-of-Line-Blockierung für den hohen Pegel der Pakete zuerst erreicht werden. Diese Konfiguration arbeitet deshalb daran, entweder eine kleine Serie von sehr großen Paketen oder eine große Serie von sehr kleinen Paketen daran zu hindern, HOL-Blockierungs-Probleme zu erzeugen.
  • Der vorher diskutierte niedrige Pegel im Hinblick auf die CBP-Zulassungslogik hat den Zweck zu gewährleisten, dass unabhängig von den Verkehrsbedingungen jeder Port einen geeigneten Pufferspeicherraum haben wird, der ihm in dem CBP zugewiesen ist, um eine Portverhungerung zu verhindern, und um zu gewährleisten, dass jeder Port in der Lage sein wird, mit jedem anderen Port in dem Ausmaß zu kommunizieren, dass das Netzwerk eine solche Kommunikation unterstützen kann.
  • Unter erneuter Bezugnahme auf die MMU 70 ist der CBM 71 so konfiguriert, dass er die Verfügbarkeit von Adresszeigern, die mit ankommenden Paketen assoziiert sind, aus einem Pool freier Adressen maximiert. Der CBM 71 speichert, wie vorher angemerkt worden ist, den ersten Zellenzeiger, bis das ankommende Paket 112 entweder in dem CBP 50 oder dem GBP 60 empfan gen und assembliert wird. Wenn das Lösch-Flag (purge flag) der entsprechenden P-Kanal-Nachricht gesetzt ist, löscht der CBM 71 das ankommende Datenpaket 112 und sorgt deshalb dafür, dass die Adresszeiger GPID/CPID, die mit dem ankommenden Paket assoziiert sind, verfügbar werden. Wenn das Lösch-Flag gesetzt ist, entleert oder löscht der CBM 71 daher das Paket im Wesentlichen aus der Verarbeitung des SOC 10, wodurch eine nachfolgende Kommunikation mit dem assoziierten Austrittsmanager 76 verhindert wird, der mit dem gelöschten Paket assoziiert ist. Der CBM 71 ist auch so konfiguriert, dass er mit den Austrittsmanagern 76 kommuniziert, um veraltete und gestaute Pakete zu löschen. Veraltete und gestaute Pakete werden zu dem CBM 71 auf der Grundlage des assoziierten Startadresszeigers geleitet, und die Rückgewinnungseinheit innerhalb des CBM 71 befreit die Zeiger, die mit den zu löschenden Paketen assoziiert sind; dies wird im Wesentlichen dadurch erreicht, dass der Pool der freien Adressen so modifiziert wird, dass er diese Änderung reflektiert. Der Speicherbudgetwert wird aktualisiert, indem der aktuelle Wert des assoziierten Speichers um die Anzahl an Datenzellen dekrementiert wird, die gelöscht werden.
  • Zusammenfassend werden die aufgelösten Pakete von dem Eintritts-Submodul 14 in dem C-Kanal 81 platziert, wie dies im Hinblick auf 8 diskutiert worden ist. Der CBM 71 ist mit dem CPS Kanal verbunden, und jedes Mal dann, wenn es eine Zelle/ein Paket gibt, die/das für einen Austrittsport bestimmt ist, weist der CBM 71 Zellenzeiger zu und verwaltet die Verbundliste. Eine Vielzahl von im gleichen Zeitintervall ablaufenden Reassemblierungsmaschinen ist bereitgestellt, und zwar jeweils eine Reassemblierungsmaschine für jeden Austrittsmanager 76, und verfolgt den Rahmenstatus. Wenn eine Vielzahl von Zellen, die ein Paket repräsentieren, vollständig in den CBP 50 geschrieben ist, sendet der CBM 71 CPIDs zu den jeweiligen Austrittsmanagern hinaus, wie oben erörtert worden ist. Die CPIDs zeigen auf die erste Zelle des Pakets in dem CBP; der Paketfluss wird dann von den Austrittsmanagern 76 zu Transaktions-MACs 140 gesteuert, wenn die CPID-/GPID-Zuweisung durch den CBM 71 beendet ist. Das Budgetregister (nicht gezeigt) des jeweiligen Austrittsmanagers 76 wird in geeigneter Weise um die Anzahl an Zellen dekrementiert, die mit dem Austritt verbunden sind, nachdem das komplette Paket in den CBP 50 geschrieben ist. Der EGM 76 schreibt die zugehörigen PIDs in sein Transaktions-FIFO. Da es mehrere Serviceklassen (COSs) gibt, schreibt der Aus trittsmanager 76 dann die PIDs in den ausgewählten Transaktions-FIFO, der der ausgewählten COS entspricht. Wie unten unter Bezugnahme auf 13 erörtert werden wird, besitzt jeder Austrittsmanager 76 seinen eigenen Scheduler, der mit dem Transaktionspool oder dem Transaktions-FIFO auf einer Seite und mit dem Paketpool oder dem Paket-FIFO auf der anderen Seite verbunden ist. Der Transaktions-FIFO umfasst alle PIDs, und der Paketpool oder der Paket-FIFO umfasst nur CPIDs. Der Paket-FIFO ist mit dem Transaktions-FIFO verbunden und initiiert eine Übertragung auf der Grundlage von Anforderungen von der Übertragungs-MAC. Wenn die Übertragung gestartet ist, werden die Daten jeweils eine Zelle pro Zeitpunkt auf der Grundlage von Transaktions-FIFO-Anforderungen aus dem CBP 50 ausgelesen.
  • Wie vorher angemerkt worden ist, gibt es einen Austrittsmanager für jeden Port jedes EPIC 20 und GPIC 30, und dieser ist mit dem Austrittssubmodul 18 assoziiert. Es sollte angemerkt werden, dass der IPIC 90 den Austritt auf eine andere Art und Weise managt wie die EPICs 20 und die GPICs 30, da der IPIC 90 Pakete aus dem NBP 92 abruft.
  • 13 veranschaulicht ein Blockdiagramm eines Austrittsmanagers 76, der mit dem R-Kanal 77 kommuniziert. Für jedes Datenpaket 112, das von einem Eintrittssubmodul 14 eines EPIC 20 des SOC 10 empfangen wird, weist der CBM 71 eine Zeigeridentifikation (PID; pointer identification) zu; wenn das Paket 112 zu dem CBP 50 zugelassen wird, weist der CBM 71 eine CPID zu, und wenn das Paket 112 zu dem GBP 60 zugelassen wird, weist der CMB 71 eine GPID-Nummer zu. Zu diesem Zeitpunkt benachrichtigt der CBM 71 den entsprechenden Austrittsmanager 76, der das Paket 112 handhaben wird, und leitet die PID durch den R-Kanal 77 zu dem entsprechenden Austrittsmanager 76 weiter. In dem Fall eines Unicast-Pakets würde nur ein Austrittsmanager 76 die PID erhalten. Aber wenn das ankommende Paket ein Multicast- oder Broadcast-Paket wäre, dann würde jeder Austrittsmanager 76, zu dem das Paket geleitet wird, die PID empfangen. Aus diesem Grund muß ein Multicast- oder Broadcast-Paket nur einmal in dem entsprechenden Speicher gespeichert werden, der entweder der CBP 50 oder der GBP 60 ist.
  • Jeder Austrittsmanager 76 umfasst eine R-Kanal-Schnittstelleneinheit (RCIF) 131, einen Transaktions-FIFO 132, einen COS-Manager 133, einen Scheduler 134, eine beschleunigte Paketentleerungseinheit (APF; accelerated packet flush unit) 135; eine Speicherleseeinheit (MRU) 136, eine Zeitstempelüberprüfungseinheit (TCU) 137, und eine Ent-Tag-Einheit (untag unit) 138. Die MRU 136 kommuniziert mit einem CBP-Speichercontroller (CMC) 79, der mit dem CBP 50 verbunden ist. Der Scheduler 134 ist mit einem Paket-FIFO 139 verbunden. Die RCIF 131 handhabt alle Nachrichten zwischen dem CBM 71 und dem Austrittsmanager 76. Wenn ein Paket 112 in dem SOC 10 empfangen und gespeichert wird, leitet der CBM 71 die Paketinformationen zu der RCIF 131 des assoziierten Austrittsmanagers 76 weiter. Die Paketinformationen werden eine Angabe enthalten, ob das Paket in dem CBP 50 oder in dem GBP 70 gespeichert ist oder nicht, werden die Größe des Pakets und die PID enthalten. Die RCIF 131 leitet die empfangenen Paketinformationen dann zu dem Transaktions-FIFO 132 weiter. Der Transaktions-FIFO 132 ist ein FIFO mit einer festgelegten Tiefe mit acht COS-Prioritäts-Warteschlangen und ist als eine Matrix mit einer Anzahl von Zeilen und Spalten angeordnet. Jede Spalte des Transaktions-FIFO 132 stellt eine Serviceklasse (COS) dar, und die gesamte Anzahl an Zeilen ist gleich der Anzahl an Transaktionen, die für jede Serviceklasse erlaubt sind. Der COS-Manager 133 arbeitet zusammen mit dem Scheduler 134, um eine richtlinienbasierte Dienstgüte (QOS; quality of service) auf der Grundlage der Ethernet Standards bereitzustellen. Wenn Datenpakete in einer oder mehreren der COS-Prioritäts-Warteschlangen des Transaktions-FIFO 132 ankommen, leitet der Scheduler 134 einen ausgewählten Paketzeiger von einer der Prioritätswarteschlangen zu dem Paket-FIFO 139. Die Auswahl des Paketzeigers basiert auf einem Warteschlangen-Scheduling-Algorithmus, der von einem Benutzer durch die CPU 52 innerhalb des COS-Managers 133 programmiert wird. Ein Beispiel für eine COS-Angelegenheit ist das Video, das eine größere Bandbreite als Textdokumente benötigt. Ein Datenpaket 112 von Videoinformationen kann deshalb zu dem Paket-FIFO 139 vor einem assoziierten Paket mit einem Textdokument geleitet werden. Der COS-Manager 133 würde deshalb den Scheduler 134 so anleiten, dass dieser den Paketzeiger auswählt, der mit dem Paket der Videodaten assoziiert ist.
  • Der COS-Manager 133 kann auch programmiert werden, indem ein Scheduling-Verfahren, das auf einer strikten Priorität beruht, oder ein Scheduling-Verfahren, das auf einer gewichteten Priorität beruht, dazu verwendet wird, den nächsten Paketzeiger in dem Transaktions-FIFO 132 auszuwählen. Wenn ein Scheduling-Verfahren auf der Basis einer strikten Priorität verwendet wird, wird jede der acht COS-Prioritäts-Warteschlangen im Hinblick auf alle anderen COS-Warteschlangen mit einer Priorität versehen. Alle Pakete, die sich in der COS-Warteschlange mit der höchsten Priorität befinden, werden aus dem Transaktions-FIFO 132 zur Übertragung extrahiert. Wenn andererseits ein Scheduling-Verfahren auf der Basis einer gewichteten Priorität verwendet wird, dann ist jede COS-Prioritäts-Warteschlange mit einer programmierbaren Bandbreite versehen. Nach der Zuweisung der Warteschlangenpriorität jeder COS-Warteschlange wird jede COS-Prioritäts-Warteschlange mit einer minimalen und einer maximalen Bandbreite versehen. Die minimalen und maximalen Bandbreitenwerte sind durch den Benutzer programmierbar. Wenn die Warteschlangen mit einer höheren Priorität ihre minimale Bandbreite erreichen, ordnet der COS-Manager 133 die restliche Bandbreite auf der Grundlage irgendeines Auftretens des Überschreitens der maximalen Bandbreite für irgendeine Prioritätswarteschlange zu. Diese Konfiguration garantiert, dass von den Warteschlangen der hohen Priorität eine maximale Bandbreite erreicht wird, während die Warteschlangen mit der niedrigeren Priorität mit einer niedrigeren Bandbreite versehen werden.
  • Die programmierbare Beschaffenheit des COS-Managers ermöglicht es, dass der Scheduling-Algorithmus auf der Grundlage der speziellen Bedürfnisse eines Benutzers modifiziert werden kann. Zum Beispiel kann der COS-Manager 133 einen maximalen Paketverzögerungswert in Betracht ziehen, der von einer Transaktions-FIFO-Warteschlange erfüllt werden muss. Mit anderen Worten, der COS-Manager 133 kann es erfordern, dass ein Paket 112 bei der Übertragung nicht um den maximalen Paketverzögerungswert verzögert wird; dies gewährleistet, dass der Datenfluss von Hochgeschwindigkeitsdaten, wie etwa Audio, Video und andere Echtzeitdaten, kontinuierlich und gleichmäßig übertragen wird.
  • Wenn sich das angeforderte Paket in dem CBP 50 befindet, wird die CPID aus dem Transaktions-FIFO 132 zu dem Paket-FIFO 139 weitergeleitet. Wenn sich das angeforderte Paket in dem GBP 60 befindet, initiiert der Scheduler ein Abrufen des Pakets aus dem GBP 60 zu dem CBP 50; der Paket-FIFO 139 verwendet nur gültige CPID-Informationen und verwendet keine GPID-Informationen. Der Paket-FIFO 139 kommuniziert nur mit dem CBP und nicht mit dem GBP. Wenn der Austritt versucht, ein Paket abzurufen, dann kann das Paket nur aus dem CBP abgerufen werden; aus diesem Grund ruft der Scheduler dann, wenn sich das angeforderte Paket in dem GBP 50 befindet, das Paket so ab, dass der Austritt das Paket korrekt aus dem CBP abholen kann.
  • Die APF 135 überwacht den Status des Paket-FIFO 139. Nachdem der Paket-FIFO 139 für eine bestimmte Zeitspanne voll ist, entleert die APF 135 den Paket-FIFO. Die CBM-Rückgewinnungseinheit wird von der APF 135 mit den Paketzeigern versehen, die in dem Paket-FIFO 139 gespeichert sind, und die Rückgewinnungseinheit wird von der APF 135 instruiert, um die Paketzeiger als Teil des Pools freier Adressen freizugeben. Die APF 135 deaktiviert auch den Eintrittsport 21, der mit dem Austrittsmanager 76 assoziiert ist.
  • Während der Paket-FIFO 139 die Paketzeiger von dem Scheduler 134 empfängt, extrahiert die MRU 136 die Paketzeiger für die Zuteilung zu dem richtigen Austrittsport. Nachdem die MRU 136 den Paketzeiger empfängt, leitet sie die Paketzeigerinformation zu dem CMC 79 weiter, der jede Datenzelle aus dem CBP 50 abruft. Die MRU 136 leitet die erste Datenzelle 112a, die die Zell-Header-Informationen enthält, an die TCU 137 und die Ent-Tag-Einheit 138 weiter. Die TCU 137 stellt fest, ob das Paket gealtert ist, indem sie die Zeitstempel, die in der Datenzelle 112a gespeichert sind, mit der aktuellen Zeit vergleicht. Wenn die Speicherungszeit größer als eine programmierbare Verwerfungszeit ist, dann wird das Paket 112 als ein veraltetes Paket verworfen. Außerdem wird die Ent-Tag-Einheit 138 dann, wenn eine wartende Anforderung danach besteht, Tags aus der Datenzelle 112a zu entfernen, den Tag-Header vor dem Absenden des Pakets entfernen. Die Tag-Headers sind in dem IEEE Standard 802.1q definiert.
  • Der Austrittsmanager 76 ist durch die MRU 136 mit dem Übertragungs-FIFO 140 verbunden, der ein Übertragungs-FIFO für eine geeignete Medienzugangskontrolleinrichtung (MAC) ist; Medienzugangskontrolleinrichtungen sind in dem Ethernet-Fachgebiet bekannt. Die MRU 136 holt das Datenpaket 112 vorher aus dem entsprechenden Speicher ab und sendet das Paket zu dem Übertragungs-FIFO 140 und kennzeichnet den Beginn und das Ende des Pakets mit einem Flag. Falls notwendig, wird der Übertragungs-FIFO 140 das Paket auffüllen, so dass das Paket eine Länge von 64 Bytes aufweist.
  • Wie in 9 gezeigt ist, wird das Paket 112 zur Handhabung in dem SOC 10 in eine Vielzahl von 64 Byte Datenzellen geschnitten oder aufgeteilt. Die Aufteilung der Pakete in Zellen vereinfacht deren Handhabung und verbessert die Granularität, und sie macht es auch leichter, den SOC 10 an zellbasierte Protokolle wie etwa ATM anzupassen. Aber bevor die Zellen aus dem SOC 10 herausgesendet werden, müssen sie wieder in ein Paketformat assembliert werden, damit eine korrekte Kommunikation in Übereinstimmung mit dem zugehörigen Kommunikationsprotokoll möglich ist. Eine Zellen-Reassemblierungsmaschine (nicht gezeigt) ist in jedem Eintritt des SOC 10 eingebaut, um die geschnittenen Zellen 112a und 112b für die weitere Kommunikation in ein in geeigneter Weise verarbeitetes und konvertiertes Paket zu reassemblieren.
  • 16 ist ein Blockdiagramm, das einige der Elemente der CPU-Schnittstelle bzw. des CMIC 40 zeigt. In einem bevorzugten Ausführungsbeispiel stellt der CMIC 40 eine 32 Bit 66 MHz PCI Schnittstelle sowie auch eine 12C Schnittstelle zwischen dem SOC 10 und der externen CPU 52 bereit. Durch den CMIC-Bus 167 wird die PCI-Kommunikation von dem PCI-Kern 41 gesteuert und die 12C-Kommunikation von dem 12C-Kern 42 durchgeführt. Wie in der Figur gezeigt ist, kommunizieren viele CMIC 40-Elemente miteinander durch den CMIC-Bus 167. Die PCI-Schnittstelle wird typischerweise für die Konfiguration und die Programmierung von Elementen des SOC 10 wie etwa Regeltabellen, Filtermasken, Pakethandhabung, etc., sowie auch für das Bewegen von Daten zu und von der CPU oder einem anderen PCI-Uplink verwendet. Die PCI-Schnittstelle ist für High-End-Systeme geeignet, bei denen die CPU 52 eine leistungsstarke CPU ist und einen ausreichenden Protokoll-Stack betreibt, wie er zur Unterstützung von Schicht-2- und Schicht-3-Switching-Funktionen benötigt wird. Die 12C-Schnittstelle ist für Low-End-Systeme geeignet, bei denen die CPU 52 hauptsächlich für die Initialisierung verwendet wird. Low-End-Systeme würden selten die Konfiguration des SOC 10 ändern, nachdem der Switch eingeschaltet ist und läuft.
  • Die CPU 52 wird von dem SOC 10 wie jeder andere Port behandelt. Deshalb muß der CMIC 40 die notwendigen Portfunktionen bereitstellen, die den anderen Portfunktionen sehr ähnlich sind, die oben definiert worden sind. Der CMIC 40 unterstützt alle S-Kanal-Befehle und -Nachrichten, wodurch die CPU 52 in die Lage versetzt wird, auf den gesamten Paketspeicher- und Registersatz zugreifen zu können; dies ermöglicht es der CPU 52 auch, Einfüge- und Löscheinträge in die ARL-/L3-Tabellen auszugeben, CFAP-/SFAP-Initialisierungsbefehle auszugeben, Lese-/Schreib-Speicherbefehle und -ACKs, Lese-/Schreib-Registerbefehle und -ACKs, etc., auszugeben. Im Innern des SOC 10 ist der CMIC 40 mit dem C-Kanal 81, dem P-Kanal 82 und dem S-Kanal 83 verbunden und ist in der Lage, als ein S-Kanal-Master sowie auch als ein S-Kanal-Slave zu arbeiten. Zu diesem Zweck muß die CPU 52 32 Bit D-Worte lesen oder schreiben. Zur ARL-Tabellen-Einfügung und -Löschung unterstützt der CMIC 40 die Pufferspeicherung von vier Einfüge-/Lösch-Nachrichten, die zyklisch abgefragt (gepollt) oder unterbrechungsgesteuert sein können. ARL-Nachrichten können durch einen DMA-Zugriff unter Verwendung eines ARL DMA Controllers 161 auch direkt in den CPU-Speicher platziert werden. Der DMA Controller 161 kann die CPU 52 nach dem Transfer irgendeiner ARL-Nachricht oder wenn alle angeforderten ARL-Pakete in den CPU-Speicher platziert worden sind, unterbrechen.
  • Die Kommunikation zwischen dem CMIC 40 und dem C-Kanal 81/P-Kanal 82 wird durch die Verwendung von CP-Kanal-Pufferspeicher 162 für die Pufferung von C- und P-Kanal-Nachrichten und die CP-Bus-Schnittstelle 163 durchgeführt. S-Kanal-ARL-Nachrichtenpufferspeicher 164 und die S-Kanal-Busschnittstelle 165 ermöglichen die Kommunikation mit dem S-Kanal 83. Wie vorher angemerkt worden ist, werden PIO-(programmierte Ein-/Ausgabe)Register verwendet, wie durch die SCH PIO Register 166 und die PIO Register 168 veranschaulicht ist, um auf den S-Kanal zuzugreifen, sowie auch um andere Steuer-, Status-, Adress- und Datenregister zu programmieren. Die PIO Register 168 kommunizieren mit dem CMIC Bus 167 durch die 12C-Slave-Schnittstelle 42a und 12C-Master-Schnittstelle 42b. Der DMA Controller 161 ermöglicht die Verkettung in dem Speicher, wodurch es der CPU 52 erlaubt wird, mehrere Pakete von Daten ohne eine kontinuierliche CPU-Intervention zu übertragen. Jeder DMA-Kanal kann deshalb so programmiert werden, dass er eine Lese- oder Schreib-DMA-Operation durchführen kann. Spezielle Deskriptorenformate können als geeignet ausgewählt werden, um eine gewünschte DMA-Funktion gemäß den Anwendungsregeln auszuführen. Zum Empfangen von Zellen von der MMU 70 für den Transfer zu einem Speicher agiert der CMIC 40, falls dies zweckmäßig ist, als ein Austrittsport und folgt dem Austrittsprotokoll, wie dies vorher erörtert worden ist. Für die Transferierung von Zellen zu der MMU 70 agiert der CMIC 40 als ein Eintrittsport und befolgt das Eintrittsprotokoll, wie dies vorher erörtert worden ist. Der CMIC 40 führt eine Überprüfung bezüglich aktiver Ports, COS-Warteschlangenverfügbarkeit und anderer Eintrittsfunktionen durch und unterstützt einen HOL-Blockierungs-Mechanismus, der oben erörtert worden ist. Der CMIC 40 unterstützt Einzel- und Burst-PIO-Operationen; aber ein Burst sollte auf die S-Kanal-Pufferspeicher und die ARL-Einfüge-/Lösch-Nachrichtenpufferspeicher begrenzt sein. Unter erneuter Bezugnahme auf die 12C-Slave-Schnittstelle 42a ist der CMIC 40 so konfiguriert, dass er eine 12C-Slave-Adresse aufweist, so dass ein externer 12C-Master auf die Register von CMIC 40 zugreifen kann. Der CMIC 40 kann umgekehrt als ein 12C-Master arbeiten und deshalb auf andere 12C-Slaves zugreifen. Es sollte angemerkt werden, dass der CMIC 40 auch MIIM durch die MIIM-Schnittstelle 169 unterstützen kann. Die MIIM-Unterstützung ist von dem IEEE Standard 802.3u definiert und wird hier nicht weiter erläutert. In ähnlicher Weise liegen andere Betriebsaspekte des CMIC 40 außerhalb des Schutzumfangs der vorliegenden Erfindung.
  • Ein einzigartiger und vorteilhafter Aspekt des SOC 10 ist die Fähigkeit, im gleichen Zeitintervall ablaufende Nachschlagevorgänge im Hinblick auf Schicht Zwei (ARL), Schicht Drei und die Filterung durchführen zu können. Wenn ein ankommendes Paket in ein Eintrittssubmodul 14 entweder eines EPIC 20 oder eines GPIC 30 kommt, wie dies vorher diskutiert worden ist, dann ist das Modul in der Lage, gleichzeitig einen Adressen-Nachschlagevorgang durchzuführen, um festzustellen, ob die Zieladresse innerhalb eines gleichen VLAN wie eine Quelladresse liegt; wenn die VLAN-INFORMATIONSOFFENLEGUNGSANWEISUNGEN gleich sind, sollte ein Schicht-2- oder ARL-Nachschlagevorgang ausreichend sein, um das Paket korrekt in einer Speicher- und Weiterleitkonfiguration zu vermitteln. Wenn die VLAN-INFORMATIONSOFFENLEGUNGSANWEISUNGEN unterschiedlich sind, dann muß das Schicht-3-Switching auf der Grundlage der geeigneten Identifikation der Zieladresse und das Vermitteln zu einem geeigneten Port erfolgen, um die VLAN der Zieladresse zu erhalten. Deshalb muß das Schicht-3-Switching durchgeführt werden, um die VLAN-Grenzen zu überschreiten. Wenn ein SOC 10 feststellt, dass das L3-Switching notwendig ist, identifiziert der SOC 10 die MAC-Adresse eines Zielrouters auf der Grundlage des L3-Nachschlagevorgangs. Der L3-Nachschlagevorgang wird auf der Grundlage eines Lesevorgangs in dem Anfangsabschnitt des Pakets dahingehend bestimmt, ob das L3-Bit gesetzt ist oder nicht. Wenn das L3-Bit gesetzt ist, dann wird ein L3-Nachschlagevorgang notwendig, um geeignete Routing-Instruktionen zu identifizieren. Wenn das Nachschlagen nicht von Erfolg gekrönt ist, wird eine Anfrage an die CPU 52 gesendet, und die CPU 52 unternimmt die zweckmäßigen Schritte, um das geeignete Routing für das Paket zu identifizieren. Wenn die CPU die geeigneten Routing-Informationen erhalten hat, werden die Informationen in der L3-Nachschlage-Tabelle gespeichert, und für das nächste Paket wird der Nachschlagevorgang erfolgreich sein und das Paket wird in der Speicher- und Weiterleitkonfiguration vermittelt.
  • Verbindbarkeit
  • Der IPIC 90 des SOC 10 stellt eine signifikante Funktionalität im Hinblick auf die Verbindbarkeit bereit. Insbesondere ermöglicht der IPIC 90 einen beträchtlichen Betrag an Flexibilität und Leistung im Hinblick auf das Stapeln einer Vielzahl von SOC-10-Chips. Wenn man die Hochleistungs-Schnittstelle verwendet, die vorher erörtert worden ist, können zwei SOC-10-Chips oder Switch-Module miteinander durch ihre jeweiligen IPIC-90-Module verbunden werden. Eine solche Konfiguration würde es ermöglichen, dass die SOC-Switch-Module auch gemeinsam ihre CMIC-40-Module mit einer gemeinsamen CPU 52 verbinden können. In einer solchen Konfiguration, bei der jeder SOC 10 drei EPIC-20-Module, die jeweils acht Fast Ethernet Ports aufweisen, und zwei GPIC-Module umfasst, die jeweils einen Gigabit Ethernet Port aufweisen, würde die sich ergebende Konfiguration 48 Fast Ethernet Ports (24 Ports pro SOC 10) und vier Gigabit Ethernet Ports aufweisen. 26 veranschaulicht eine solche Konfiguration, bei der die CPU 52 allgemein mit dem CMIC 40(1) und dem CMIC 40(2) jeweils des SOC 10(1) und des SOC 10(2) verbunden ist. Der IPIC 90(1) und der IPIC 90(2) sind durch die Hochleistungs-Schnittstelle 261 miteinander verbunden. Die Fast Ethernet Ports und Gigabit Ports werden kollektiv jeweils als die Ports 24(1) und 24(2) gezeigt.
  • Andere Stapelungskonfigurationen umfassen das, was als eine Ringkonfiguration bezeichnet wird, bei der eine Vielzahl von SOC-10-Chips durch eine ICM-(Verbindungs-Modul)-Schnittstelle zu einem Ring verbunden sind. Noch eine dritte Stapelungsverbindung ist eine Vielzahl von SOC-10-Chips oder – Switches, die durch ein ICM zu einem Kreuzschienenschalter (crossbar switch) verbunden sind, so dass der Kreuzschienenschalter die Vielzahl von SOC-10-Switches miteinander verbindet. Diese zusätzlichen zwei Stapelungskonfigurationen sind jeweils in den 27A und 27B veranschaulicht. 27A veranschaulicht einen SOC 10(1), der durch das ICM 271(1) zu einem Ring R verbunden ist, sowie auch einen SOC 10(2), der durch das ICM 271(2) zu einem Ring R verbunden ist. Diese Konfiguration ermöglicht es, dass eine Vielzahl von SOC-10-Switches gestapelt werden kann. In einem Ausführungsbeispiel können bis zu 32 SOC 10 Switches an dem Ring R angebracht werden. 27B veranschaulicht eine Kreuzschienenkonfiguration, bei der der SOC 10(1) und der SOC 10(2) jeweils durch das ICM 271(1) und 271(2) zu einer Kreuzschiene C verbunden sind. Diese Konfiguration ermöglicht es ähnlich wie die Konfiguration von 27A, dass eine beträchtliche Anzahl von SOC-Switches gestapelt werden kann. Die Kreuzschiene C ist eine bekannte Vorrichtung, die als eine Matrix oder ein Gitter arbeitet, die/das in der Lage ist, eine Vielzahl von Ports durch die Aktivierung einer geeigneten Matrixverbindung miteinander zu verbinden.
  • Wie in den 1 und 2 veranschaulicht worden ist, ist der IPIC 90 jedes SOC 10 auf einer Seite mit dem CPS-Kanal 80 und auf der anderen Seite mit der Hochleistungs-Verbindung 261 verbunden. Pakete, die in den IPIC 90 hereinkommen und die für andere Ports auf dem SOC 10 bestimmt sind, werden im Wesentlichen wie Pakete gehandhabt, die zu jedem anderen Port auf dem SOC 10 hereinkommen. Aber aufgrund der Existent des Modul-Header für sequentielle Kommunikationen umfasst der IPIC 90 ein flachen Speicher, um das ankommende Paket zu speichern. Der Modul-Header wird bei dem Eintritt abgestreift; der Modul-Header wird, wie vorher angemerkt worden ist, durch das Quell-Modul an das Paket angehängt. Der IPIC 90 führt dann die Adressauflösung durch. Die Adressauflösung ist für Pakete, die in den IPIC 90 hereinkommen, anders als für Pakete, die in die EPICs 20 oder GPICs 30 hereinkommen, und wird unten erörtert werden. Nach der Adressauflösung werden die Ziel- oder Austrittsports bestimmt, und die Port-Bitmap wird konstruiert. Das Paket wird dann in Zellen geschnitten, und die Zellen werden zu der MMU 70 über den CPS-Kanal 80 gesendet. Die Zellendaten werden über den C-Kanal 81 gesendet, und die zugehörigen Nachrichten, die den Modul-Header umfassen, werden über den P-Kanal 82 gesendet.
  • Für den Fall, bei dem die Zellen bei anderen Ports auf dem SOC 10 hereinkommen und für die Hochleistungs-Schnittstelle 261 bestimmt sind, werden die Zellen ausgehend von dem zugehörigen Eintrittsport in den CPS-Kanal 80 platziert, wo sie dann von dem IPIC 90 empfangen werden. Die Zellen werden in dem NBP 92 miteinander zurück in Pakete verschachtelt und werden deshalb nicht von der MMU 70 gehandhabt. Der NBP ist, wie vorher angemerkt worden ist, ein Speicher auf dem Chip (on-chip memory), der nur für die Verwendung durch den IPIC 90 dediziert ist. Der NBP kann ein separater getrennter Speicher oder ein reservierter Speicherplatz in dem CBP 50 sein. Die Modul-Header-Information, die von der Quelle an dem Paket angehängt worden ist, wird von dem IPIC 90 ausgehend von dem P-Kanal empfangen. Der Modul-Header umfasst die Modul-ID-Bitmap, die COS, die "gespiegelt-zu"-Port-/Switch-Informationen, die Trunk Group ID, etc.. Das konstruierte Paket wird dann auf die Hochleistungs-Schnittstelle 261 gesendet. Es sollte angemerkt werden, dass auf die Schnittstelle 261 typischerweise von zwei Vorrichtungen zugegriffen werden soll. Zum Beispiel veranschaulicht die 26 eine Konfiguration, bei der der IPIC 90(1) und der IPIC 90(2) für den Zugriff auf die Schnittstelle 261 eine Arbitrierung durchführen müssen. In den Konfigurationen der 27A und 27B muß der zugehörige IPIC 90 für einen Zugriff auf die Schnittstelle 261 mit dem zugehörigen ICM 271 eine Arbitrierung durchführen. Der Arbiter ist zum Beispiel in 28 als Arbiter 93 veranschaulicht.
  • 28 ist ein Überblick über die funktionellen Elemente eines IPIC 90. Zusätzlich zu den Tabellen 91, dem NBP 92 und dem Arbiter 93 umfasst der IPIC 90 eine Flusskontrolllogik 94, die mit dem ICM 271 verbunden ist, um es dem IPIC 90 zu ermöglichen, mit dem Verkehr Schritt zu halten, der von dem ICM kommt. Unter Verwendung eines Pausen-/Fortsetzungs-Signals tauschen das ICM und die Flusskontrolllogik 94 Pausen- und Fortsetzungs-Signale aus, um den Fluss in geeigneter Weise zu kontrollieren. In Situationen, in denen der ICM-Speicher voll ist, aktiviert das ICM das Pausen-/Fortsetzungs-Signal als eine Pause, um dem IPIC 90 mitzuteilen, keine weiteren Pakete mehr zu dem ICM 271 zu schicken. In Situationen, in denen der IPIC 90 Pakete von dem ICM 271 empfängt, der IPIC aber nicht mehr länger Pakete empfangen kann, zum Beispiel wenn der CBP 50 und der GBP 60 voll sind, dann wird der IPIC das Pausen-/Fortsetzungs-Signal für das ICM als ein Pausensignal aktivieren. Sobald es zweckdienlich ist, den Fluss in irgendeiner Richtung wieder fortzusetzen, wird das Signal deaktiviert, um den Verkehrsfluss wieder fortzusetzen. Es sollte angemerkt werden, dass dann, wenn das ICM voll ist, aber immer noch weiterhin Pakete an dem IPIC 90 von dem CPS-Kanal 80 ankommen, der HOL-Blockierungs-Verhinderungs-Mechanismus aktiviert wird, der oben erörtert worden ist.
  • Nun wird erneut Bezug auf die Funktion des Arbiters 93 genommen. Der Arbiter 93 steuert die Bandbreite an der Hochleistungs-Schnittstelle 261. Unter Verwendung eines Konfigurationsregisters kann die Priorität für die Pakethandhabung nach vorbestimmten Zeiträumen von dem IPIC 90 zu dem ICM 271 geschaltet werden und umgekehrt. In Situationen, in denen es kein ICM gibt und in denen der IPIC 90(1) mit dem IPIC 90(2) kommuniziert, würde dann eine Master-CPU, die die Funktionen in einer gestapelten Konfiguration steuert, den Arbiter 93 und die Flusskontrolllogik 94 steuern. Die Master-CPU würde eine CPU 52 einer Vielzahl von CPUs 52 sein, die mit einer Vielzahl von SOC Switches 10 assoziiert sind.
  • Es sollte auch angemerkt werden, dass der NBP-Manager 95 die Speicherverwaltung für den NBP 92 steuert. Der NBP-Manager 95 führt deshalb viele Funktionen durch, die spezifisch für den IPIC 90 sind, die aber der Funktion der MMU 70 im Hinblick auf den SOC 10 ähnlich sind. Es existieren aber einige bemerkenswerte Unterschiede dahingehend, dass es keine CBP-/GBP-Zulassungslogik gibt, da der NBP 92 als ein einziges Speicherpufferpool behandelt wird.
  • Pakete, die an dem IPIC 90 von der Hochleistungs-Schnittstelle 261 ankommen, werden immer einen Modul-Header darauf aufweisen. Der Modul-Header wird von dem Quell-SOC eingefügt, wenn das Paket gesendet wird, was als der Quell-Switch bezeichnet wird. Die Felder des Modul-Header sind wie folgt.
    • C Bit – 1 Bit lang – Control Bit – Das Steuerbit identifiziert, ob dies ein Steuerrahmen oder ein Datenrahmen ist. Dieses Bit wird für den Steuerrahmen auf 1 gesetzt und für den Datenrahmen auf 0 gesetzt.
    • Opcodes – 3 Bits lang – Opcodes werden dazu verwendet, den Pakettyp zu identifizieren. Wert 00 – identifiziert, dass das Paket ein Unicast-Paket ist, und der Austrittsports wird auf eindeutige Weise von der Modul-ID-Bitmap (nur ein Bit wird in diesem Feld gesetzt werden) und der Austrittsportnummer identifiziert. Wert 01 – identifiziert, dass das Paket ein Broadcast- oder Zielsuchvorgang-Fehlschlag (DLF) ist und für mehrere Ports auf dem gleichen Modul oder mehrere Ports auf verschiedenen Modulen bestimmt ist. Der Austrittsport ist in diesem Szenario kein gültiges Feld. Wert 02 – identifiziert, dass das Paket ein Multicast-Paket ist und für viele Ports adressiert ist. Wert 03 – identifiziert, dass das Paket ein IP-Multicast-Paket ist und für viele Ports adressiert ist.
    • TGID – 3 Bits lang – TGID Bits – TGID identifiziert den Trunk Group Identifizierer des Quellports. Dieses Feld ist nur gültig, wenn das T-Bit gesetzt ist.
    • T – 1 Bit lang – T-Bit – Wenn dieses Bit gesetzt ist, dann ist TGID ein gültiges Feld.
    • MT Module Id Bitmap – 5 Bits lang – die MT-Modul-ID ist eine "gespiegelt-zu"-Modul-ID ("mirrored-to" Module ID). Dieses Feld wird verwendet, um das Paket zu einem Port, "zu dem gespiegelt wird", zu senden, der sich auf einem fernen Modul befindet. Dieses Feld ist nur gültig, wenn das M-Bit gesetzt ist.
    • M Bit – 1 Bit lang – M-Bit – Wenn dieses Bit gesetzt ist, dann ist MT Module Id ein gültiges Feld.
    • Data Len – 14 Bits lang – Datenlänge – Identifiziert die Datenlänge des Pakets.
    • CoS – 3 Bits lang – CoS Bits – Identifiziert die CoS-Priorität für diesen Rahmen.
    • CRM – 1 Bit lang – CoS Re-Map Bit – Dieses Bit wird verwendet, um die CoS auf der Grundlage der Quell-Modul-ID + Quell-Portnummer zu remappen. Dieses Merkmal ist für die Module nützlich, die keine CoS-Mapping-Fähigkeit aufweisen.
    • Module Id Bitmap – 32 Bits lang – Modul-Id-Bitmap – Bitmap aller Module, die das Paket empfangen sollen.
    • Egress Port – 6 Bits lang – Austrittsport – Ist die Nummer des Ports auf dem fernen Modul, der das Paket empfangen soll.
    • New IP checksum – 16 Bits lang – Neue IP-Prüfsumme – Diese wird hauptsächlich für den IP-Multicast-vermittelten Verkehr verwendet.
    • PFM – 2 Bits lang – Port Filtering Mode Bits (Portfilterungsmodus-Bits) – Diese sind der Port-Filterungsmodus für den Quellport.
    • Source Port – 6 Bits lang – Source Port ist die Quellportnummer des Pakets.
    • CRC Bits – 2 Bits lang – CRC-Bits – Dies sind die gleichen CRC-Bits aus der P-Kanal-Nachricht, die hier kopiert werden. Wert 0×01 – ist das Append CRC Bit. Wenn dieses Bit gesetzt ist, dann soll der Austrittsport die CRC an das Paket anhängen. Wert 0×02 – ist das Regenerate CRC Bit. Wenn dieses Bit gesetzt ist, dann soll der Austrittsport CRC regenerieren. Wert 0×00 – keine Änderung in CRC. Wert 0×03 – nicht benutzt.
    • Source Mod Id – 5 Bits lang – Quellmodul-ID – ist die Quellmodul-ID des Pakets.
    • Data – N Bits lang – Data Bytes – Die Datenbytes können die CRC enthalten. Man muß die CRC-Bits überprüfen, um herauszufinden, ob die Daten CRC enthalten. Wenn die CRC-Bits so gesetzt sind, dass die CRC angehängt werden soll, dann enthalten die Daten keine CRC-Bytes. Wenn die CRC-Bits so gesetzt sind, dass die CRC regeneriert werden soll, dann enthalten die Daten CRC-Bytes, aber es ist kein gültiges CRC. Wenn der CRC-Wert 00 ist, dann enthalten die Daten CRC und es ist ein gültiges CRC.
    • CRC Of (Module Header + Data) – 4 Bits lang – CRC-Wert, der die Daten und den Modul-Header umfasst.
  • Damit der IPIC 90 die Adressauflösung korrekt durchführt, müssen zahlreiche Tabellen innerhalb der Tabellen 91 enthalten sein. Diese Tabellen umfassen eine 802.1q VLAN Tabelle, eine Multicast-Tabelle, eine IP-Multicast-Tabelle, eine Trunk Group Bitmap-Tabelle, eine Abbildungstabelle für die Priorität der Serviceklassenwarteschlangen und eine Abbildungstabelle für die Ports für die Serviceklassen. Die ARL-Logik für den IPIC 90 unterscheidet sich von der vorher erörterten EPIC/GPIC-Adressauflösungslogik aus zahlreichen Gründen. Zuerst einmal startet das Paket nach den 16 Bytes des Modul-Headers; der Modul-Header enthält Informationen in bezug darauf, ob das Paket ein Steuerrahmen oder ein Datenrahmen ist. Steuerrahmen werden immer zu der CPU gesendet, nachdem der Modul-Header abgestreift ist. Der Modul-Header ent hält die Trunk Group Identifizierer-Informationen, die gespiegelt-zu-Port-Informationen, Austrittsportinformationen, etc.. Jedes Mal dann, wenn das C-Bit in dem Modul-Header gesetzt ist, wird das Paket zu der CPU gesendet. Das T-Bit und die TGID-Bits sind in dem Modul-Header bereitgestellt, um das Trunking quer durch die Module zu unterstützen. Das Spiegeln wird von der MT-Modul-ID-Bitmap und dem M-Bit gesteuert. Das CRM- oder COS-Re-Map-Bit ermöglicht das Remapping der COS auf der Grundlage der Quellmodul-ID und der Quellportnummer. Dieses Remapping kann in Situationen notwendig werden, in denen Switches von verschiedenen Anbietern geliefert werden.
  • Unter Bezugnahme auf 29 ist eine Adressauflösung für ein Paket, das von einer Hochleistungs-Schnittstelle 271 in den IPIC 90 hereinkommt, wie folgt:
    Das Paket, das von der Schnittstelle 261 in den IPIC 90 hereinkommt, wird bei Schritt 29-1 in einem flachen Speicher 96 gespeichert, in dem die IPIC-ARL-Logik 97 entscheidet, ob der GBP 60 voll ist. Falls ja, dann wird das Paket bei Schritt 29-2 fallen gelassen. Falls nein, dann stellt die Logik 97 bei Schritt 29-3 fest, ob das M-Bit in dem Modul-Header gesetzt ist, und führt auch eine Überprüfung durch um zu sehen, ob die Modul-ID für das "gespiegelt-zu"-Modul gleich der vorliegenden Modul-ID ist. Falls ja, dann wird der Port, zu dem gespiegelt wird, aus dem Portspiegelungsregister für den SOC 10 erhalten, und ein Bit wird in der Port-Bitmap gesetzt, das dem Port, zu dem gespiegelt wird, entspricht, und das Paket wird bei dem Schritt 29-4 zu dem Port, zu dem gespiegelt wird, gesendet. Wenn die Antwort im Hinblick auf das M-Bit NEIN ist, und nachdem das Paket zu dem Port, zu dem gespiegelt wird, gesendet worden ist, führt die ARL-Logik 97 bei dem Schritt 29-5 eine Überprüfung durch, um zu sehen, ob das C-Bit gesetzt ist. Falls ja, dann wird das Paket bei Schritt 29-6 zu der CPU gesendet. Das CPU-Bit in der Port-Bitmap wird so gesetzt, dass gewährleistet wird, dass das Paket zu der CPU gesendet wird. Falls das C-Bit nicht gesetzt ist, oder nachdem das Paket in geeigneter Weise zu der CPU gesendet worden ist, stellt die ARL-Logik 97 bei Schritt 29-7 fest, ob das Paket ein Unicast-Paket ist oder nicht. Falls ja, dann wird das Paket in geeigneter Weise in den CPS-Kanal 80 platziert, wobei das Bit, das dem Austrittsport entspricht, in geeigneter Weise in der Port-Bitmap gesetzt wird. Wenn das T-Bit gesetzt ist, dann wird die endgültige Bitmap auf der Grundlage der Trunk Group Bitmap und der TGID gesetzt. Wenn das CRM-Bit gesetzt ist, dann wird die Abbildungstabelle für die Ports für die Serviceklassen durchsucht, um die geeignete COS-Warteschlange zu bekommen. Anderenfalls wird die COS aus dem Modul-Header ausgelesen. Dieser Sendeschritt tritt bei Schritt 29-8 auf. Wenn festgestellt wird, dass das Paket kein Unicast-Paket ist, dann stellt die IPIC ARL-Logik 97 bei Schritt 29-9 fest, ob das Paket ein Multicast-Paket ist. Diese Bestimmung wird, wie oben erwähnt worden ist, durchgeführt, indem die Zieladresse überprüft wird, um zu sehen, ob sie eine Klasse-D-Adresse ist. Die Klasse-D-Klassifikation ist eine Klassifikation, bei der die ersten drei MSBs der Multicast-IP-Adresse auf Eins gesetzt sind. Wenn festgestellt wird, dass es tatsächlich ein IP-Multicast-Paket ist, dann werden zwei separate und gleichzeitige Prozesse durchgeführt. Bei Schritt 29-10 wird eine Durchsuchung der IP-Multicast-Tabelle durchgeführt, und zwar mit der Quell-IP-Adresse und der Ziel-IP-Adresse als dem Suchschlüssel. Wenn eine Übereinstimmung oder ein Treffer vorliegt, dann wird bei Schritt 29-11 die TTL in dem IP-Header mit dem TTL-Schwellwert verglichen. Wenn die TTL unterhalb des Schwellwerts liegt, dann wird das Paket zu der CPU gesendet. Wenn die TTL nicht unterhalb des TTL-Schwellwerts liegt, dann wird die L3-Port-Bitmap erhalten, und es wird festgestellt, ob die L3-Port-Bitmap ein Element des aktiven Portregisters ist, das der COS für das Paket entspricht, oder nicht. Die neue IP-Prüfsumme aus dem Modul-Header wird auf dem P-Kanal gesendet, und das Paket wird auf dem C-Kanal gesendet. Dieser Prozess ist als der L3-Vermittlungsschritt 29-13 veranschaulicht. Wenn die Suche von Schritt 29-10 nicht zu einem Treffer führt, dann wird das Paket bei Schritt 29-12 zu der CPU gesendet, und die Bits 8 der CPU-Opcodes werden gesetzt.
  • Der zweite Prozess, der durchgeführt wird, wenn ermittelt wird, ob das Paket ein Multicast-Paket ist oder nicht, umfasst eine Schicht-2-Vermittlung. Daher ermöglicht der SOC 10 eine Hybrid-Multicast-Behandlung. Das heißt, deshalb kann das gleiche Paket bei Schicht 2 und bei Schicht 3 vermittelt werden. Deshalb untersucht die ARL-Logik 97 bei Schritt 29-14, nachdem der Schritt 29-9 feststellt, dass das Paket ein Multicast-Paket ist, die PFM-(Portfilterungsmodus-)Bits des Modul-Headers. Wenn der PFM auf Null gesetzt ist, dann wird das Paket zu allen Ports weitergeleitet. Die Port-Bitmap wird aus der Port-VLAN-Tabelle erhalten, ein geeigneter Ausschluss des IPIC-Ports wird durchgeführt, der Trunk Port wird in geeigneter Weise bestimmt, die COS wird erfasst, und das Paket wird bei Schritt 29-15 in geeigneter Weise weitergeleitet. Wenn der PFM nicht auf Null gesetzt ist, dann wird die Multicast-Tabelle bei Schritt 29-16 unter Verwendung des Zielschlüssels durchsucht, der aus der Zieladresse und der VLAN ID gebildet worden ist. Wenn kein Treffer vorhanden ist, dann untersucht die Logik 97 bei Schritt 29-17 noch einmal den Eintrittsport. Wenn der PFM auf 2 gesetzt ist, wird das Paket fallen gelassen. Wenn der PFM nicht auf 2 gesetzt ist, wird die Port-Bitmap bei Schritt 29-19 aus der VLAN-Tabelle erhalten und das Paket wird bei Schritt 29-20 weitergeleitet. Wenn die Zieldurchsuchung des Schrittes 29-16 ein Treffer ist, wird die Port Bitmap bei Schritt 29-18 aus der Multicast-Tabelle erhalten, und das Paket wird bei Schritt 29-20 weitergeleitet. Bei dem Schritt 29-20 werden zugehörige Portregister auf der Grundlage des T-Bits, der COS, der Spiegelung, etc. gesetzt und das Paket wird zu den zugehörigen Zielen weitergeleitet. Diese Konfiguration ermöglicht, wie vorher erwähnt worden ist, eine einzigartige Hybrid-Multicast-Handhabung, so dass ein Multicast-Paket in geeigneter Weise bei Schicht 2 und/oder Schicht 3 vermittelt werden kann.
  • Unter erneuter Bezugnahme auf 28 wird der Zugriff auf den NBP 92 von dem NBP-Manager 95 gesteuert. Wiederum werden Pakete, die in den IPIC 90 auf einer Hochleistungs-Schnittstelle 261 eintreten, zuerst in einem flachen Speicher 96 gespeichert, der zum Beispiel 3 Zellen tief sein kann. Der Modul-Header, der 16 Bytes lang ist, und eine vorbestimmte Anzahl von paketierten Zellen (wie etwa 14 Bytes) kommen herein und die Adressauflösung, die oben erörtert worden ist, wird von der ARL-Logik 97 durchgeführt. Die VLAN-Tabelle, die Multicast-Tabelle und die IP-Multicast-Tabellen, die die Tabellen 91 bilden, werden für die verschiedenen Nachschlagevorgänge verwendet. Es sind keine ARL-Tabellen bereitgestellt, da der Modul-Header Informationen bezüglich Unicast, Multicast, etc. bis zu der fernen Portnummer bereitstellt. Die ferne Portnummer ist die Modul-ID plus die Zielportnummer. Da die Zielportnummer zur Verfügung steht, ist eine ARL-Tabelle, wie sie in den EPICs 20 und den GPICs 30 verwendet wird, nicht nötig. Die PFM-Bits des Modul-Headers sind gemäß dem 802.1 q Standard definiert und ermöglichen die Adressauflösung für Multicast, wie dies oben erörtert worden ist. Deshalb werden Pakete, die an einer Schnittstelle 261 hereinkommen, für die Adressauflösung in den flachen Speicher platziert. Nach der Adressauflösung wird das Paket in dem CPS-Kanal 80 platziert, in dem es für eine geeignete Speicherarbitrierung und Speicherung zu der MMU 70 gesendet wird, bevor es von dem geeigneten Austritt erfasst wird. Ankommende Pakete, die aus den EPICs 20 und GPICs 30 für den IPIC 90 bestimmt sind, werden direkt auf dem CPS-Kanal 80 in den NBP 92 gesendet. Durch die Verwendung des NBP-Managers 95 sendet der IPIC 90 allgemein geeignete S-Kanal-Nachrichten in bezug auf den Betrieb des NBP 92 und des IPIC 90. Solche S-Kanal-Nachrichten können NBP-Voll-Nachrichten, GBP-Voll-Nachrichten, eine HOL-Mitteilung, eine COS-Mitteilung, etc. umfassen. Deshalb verwaltet der NBP-Manager 95 den FAP (Pool freier Adressenzeiger) für den NBP, handhabt den Zellentransfer für den NBP, weist den ankommenden Zellen Zellenzeiger zu, assembliert Zellen zu Paketen, schreibt Paketzeiger in den Paket-FIFO 98 und überwacht die Aktivitäten des Schedulers 99. Der Scheduler 99 arbeitet zusammen mit dem NBP 92, dem Paket-FIFO 98 und dem Arbiter 93, um das nächste Paket für die Übertragung auf der Hochleistungs-Schnittstelle 261 zeitlich zu planen. Der Scheduler 99 wertet die COS-Warteschlangen in dem Paket-FIFO 98 aus, und wenn Pakete in dem Paket-FIFO vorhanden sind, dann wird das Paket für die Übertragung auf der Hochleistungs-Schnittstelle 261 abgerufen. Die Übertragung wird von dem Status des Gewährungssignals im Hinblick auf das ICM gesteuert, wie dies von dem Arbiter 93 gesteuert wird. Wie in 28 gezeigt ist, muß der Scheduler 93 acht COS-Warteschlangen in dem Paket-FIFO 98 in geeigneter Weise handhaben. Ein geeignetes COS-Management bestimmt, welches das nächste Paket sein wird, das aus den Prioritätswarteschlangen abgerufen werden soll. Das COS-Management wird von einem COS-Manager durchgeführt (nicht gezeigt), der ein Teil des Schedulers 99 ist. Der Scheduler 99 kann deshalb so programmiert werden, dass er je nach Notwendigkeit unterschiedliche Typen von Warteschlangen-Scheduling-Algorithmen erlaubt. Zwei Beispiele für Scheduling-Algorithmen, die verwendet werden können, sind 1) das Scheduling auf der Basis einer strikten Priorität, und 2) das Scheduling auf der Basis einer gewichteten Priorität. Beide dieser Algorithmen und die assoziierten Register können in geeigneter Weise programmiert werden.
  • Wenn der Scheduler 99 ein Paket zur Übertragung abruft, wird der Paketzeiger aus dem Paket-FIFO 98 erhalten, und der Paketzeiger zeigt auf die erste Zelle des Pakets. Der Zell-Header enthält alle benötigten Informationen, und der Modul-Header ist hier ein gültiges Feld. Die Daten, die übertragen werden sollen, sind aus dem 16ten Byte erhältlich, und das Modul-Header-Feld wird nicht als ein gültiges Feld betrachtet. Eine geeignete Verknüpfung der Zellen wird gewährleistet, um sicher zu stellen, dass komplette Pakete reassembliert und auf einer Hochleistungs-Schnittstelle 261 gesendet werden.
  • Eine Verbindungsgruppierung, die mit der vorstehend besprochenen Trunking-Konfiguration und -Operation gleichzusetzen ist, ist durch den IEEE 802.3ad Standard definiert und stellt ein Verfahren zum logischen Behandeln mehrerer Verbindungen zwischen zwei Vorrichtungen als eine einzelne Verbindung dar. Die Verbindungsgruppierung ist besonders nützlich, wenn eine Vorrichtung Daten an eine andere Vorrichtung oder eine andere Datenendeinrichtung (DTE; Data Terminal Equipment) senden muss, wobei die Daten die auf einer einzelnen Verbindung zur Verfügung stehende Bandbreite übersteigen, da es die Gruppierung einer oder mehrerer Verbindungen dem Benutzer erlaubt, die verfügbare Bandbreite allmählich, jedoch beträchtlich zu erhöhen, um die Daten zu übertragen, und zwar ohne zusätzliche Erhöhung der Hardware-Kosten und ohne zusätzliche Installationen. Eine spezifische, durch den IEEE 802.3ad Standard definierte Funktion ist das Flush-Protokoll, das dazu verwendet wird, eine falsche Anordnung von Rahmen zu vermeiden, wenn große Flüsse von einer Verbindung zu einer anderen vermittelt werden, um einen größeren Teil der verfügbaren Bandbreite zu nutzen. Ein falsches Anordnen oder aus der Ordnung Geraten (Out-of-Ordering) von Rahmen kann auftreten, wenn die Übertragung von Rahmen auf einer ersten Verbindung an eine zweite Verbindung vermittelt wird, da die über die zweite Verbindung gesendeten ersten Rahmen möglicherweise vor den über die erste Verbindung gesendeten letzten Rahmen am Ziel ankommen könnten. Diese Situation tritt im Allgemeinen dann auf, wenn die gesendeten Rahmen unterschiedliche Größen aufweisen, was inhärent zu ungleichmäßigen Übertragungszeiten quer durch die jeweiligen Verbindungen führt.
  • Als ein Beispiel für eine Situation, in der ein aus der Ordnung Geraten von Rahmen für gewöhnlich auftreten würde, betrachten wir die Situation, in der ein 1500 Byte Rahmen zur Übertragung über eine Verbindung A in die Warteschlange gestellt wird, gefolgt von einem 64 Byte Rahmen, der zur Übertragung über eine Verbindung B in die Warteschlange gestellt wird. Sogar wenn die Übertragung des 1500 Byte Rahmens über die Verbindung A zuerst initiiert wird, ist die Übertragung des 64 Byte Rahmens vor dem Abschluss des 1500 Byte Rahmens abgeschlossen. Daher werden die Rahmen am Ziel nicht richtig geordnet sein, da der 64 Byte Rahmen nun vor dem 1500 Byte Rahmen steht. Diese Situation tritt bei jeder beliebigen Kombination von Rahmengrößen auf, wobei der erste Rahmen im Vergleich zum zweiten Rahmen relativ groß ist und der zweite Rahmen kurz nach der Initialisierung der Übertragung des ersten und größeren Rahmens gesendet wird, was dazu führt, dass der zweite und kleinere Rahmen vollständig vom Ziel empfangen wird, bevor die Übertragung des ersten und größeren Rahmens abgeschlossen ist.
  • Unter nochmaliger Bezugnahme auf die Flush-Protokollfunktion sendet die lokale DTE dann, wenn ein Fluss unter Verwendung des Flush-Protokolls von einer Verbindung zu einer anderen vermittelt werden soll, eine Indikator-Markierungs-Paketdateneinheit (PDU; Packet Data Unit) an die Verbindungspartner-DTE. Die Verbindungspartner-DTE sendet bei Empfang der Markierungs-PDU von der lokalen DTE eine Markierungs-Antwort-PDU an die lokale DTE, die angibt, dass alle Rahmen, die vor der Markierungs-PDU gesendet wurden, in der richtigen Reihenfolge empfangen worden sind. Die lokale DTE sendet keine neuen Datenrahmen an die Verbindungspartner-DTE, bis die Markierungs-Antwort-PDU empfangen worden ist. Bei Empfang der Markierungs-Antwort-PDU nimmt die lokale DTE das Senden von Datenrahmen auf einer anderen Verbindung wieder auf, welche durch eine vorbestimmte Logik ausgewählt wird. Die Verzögerung bei der Vermittlung (Switching) an die zweite Verbindung und die Wiederaufnahme des Sendens von Rahmen verhindert effizient jegliches aus der Ordnung Geraten von Rahmen, die von der Verbindungsparter-DTE empfangenen werden, da es dem ersten Rahmen erlaubt wird, am Ziel anzukommen, bevor der zweite Rahmen von der Quelle versendet wird. Somit würde unter erneuter Bezugnahme auf das unmittelbar oben erwähnte Beispiel der 64 Byte Rahmen, der sich in der Warteschlange für die Verbindung B befindet, nicht an das Ziel gesendet werden, bis eine Markierungs-Antwort-PDU vom Ziel erhalten wurde, wodurch angezeigt wird, dass der über die Verbindung A gesendete 1500 Byte Rahmen am Ziel angekommen ist. Daher kann dann, wenn der größere Rahmen über die Verbindung A vollständig gesendet worden ist, die Übertragung des kleineren Rahmens über die Verbindung B initiiert werden, ohne Bedenken haben zu müssen, dass dieser Rahmen am Ziel ankommt, bevor die Übertragung des größeren Rahmens über die Verbindung A abgeschlossen ist.
  • Der Flush-Protokollprozess ist theoretisch bei der Verhinderung eines Durcheinandergeratens von Rahmen in einer Verbindungsgruppierungsumgebung wirksam; die theoretische Wirksamkeit des Prozesses hängt jedoch in kritischer Weise von der Zeitsteuerung der Markierungs-Antwort-PDU-Übertragung ab. Die Verhinderung eines aus der Ordnung Geratens von Rahmen ist in einem Switch, der das Flush-Protokoll verwendet, nicht garantiert, wenn die Verbindung A aus dem vorherigen Beispiel die Markierungs-Antwort-PDU sendet, sobald die Markierungs-PDU empfangen wurde, da die Warteschlangentiefe der Eintrittsports für den Switch unterschiedlich sein kann. Nehmen wir als Beispiel die Situation an, in der die Warteschlangentiefe des Eintrittsports 1 größer als die Warteschlangentiefe des Eintrittsports 2 ist. Deshalb ist es dann, wenn ein Fluss von der Verbindung 1 zu der Verbindung 2 vermittelt wird, wenn der Eintrittsport 1 beim Empfang der Markierungs-PDU eine Markierungs-Antwort-PDU sendet, daher möglich, dass der über die Verbindung 2 gesandte Rahmen noch immer vor dem über die Verbindung 1 gesendeten Rahmen an dem Austrittsport ankommt.
  • Um zu vermeiden, dass Rahmen infolge der unterschiedlichen Warteschlangentiefen aus der Ordnung geraten, wenn das Flush-Protokoll verwendet wird, verwendet die vorliegende Erfindung ein neuartiges Verfahren zum Senden der Markierungs-PDU und der Markierungs-Antwort-PDU. 56 ist als ein veranschaulichendes Beispiel des Verfahrens dargestellt, das in der vorliegenden Erfindung verwendet wird, um ein aus der Ordnung Geraten von Rahmen infolge eines Unterschieds der Warteschlangentiefe bei Verwendung des Flush-Protokolls zu verhindern. Wie in 56 gezeigt ist, nehmen wir an, das alle Rahmen im Fluss am Port 1 für den Port 5 bestimmt sind. Daher sendet der Eintrittsport 1 dann, wenn er die Markierungs-PDU empfängt, die Markierungs-PDU an den Austrittsport 5. Diese Funktion könnte auch durch das Senden eines systemgebundenen Rahmens innerhalb des Switch an den Port 5 ausgeführt werden, der die Markierungs-PDU und die Eintrittsportnummer darin einkapseln würde. Diese Art von Rahmen würde hinsichtlich der Übermittlung (Forwarding) zu dem Austrittsport derselben Behandlung unterzogen werden wie die restlichen Datenrahmen. Der Austrittsport würde dann bei Empfang des Rahmens und bei Abschluss der Übertragung der Daten in der Austritts-Warteschlange einen Hinweis an den Eintrittsport 1 senden. Bei Empfang die ses Hinweises sendet der Eintrittsport 1 nun über die Verbindung 1 eine Markierungs-Antwort-PDU an den Verbindungspartner. Indem mit dem Senden des Hinweises vom Austrittsport zum Eintrittsport 1 gewartet wird, stellt das Verfahren sicher, dass der Rahmen nicht in der falschen Reihenfolge gesendet wird, da ein Vermitteln (Switching) zwischen den Verbindungen nicht stattfindet, bis der Austrittsport freigegeben worden ist. Somit hat durch das Ermöglichen einer Freigabe des Austrittsports ein Unterschied in der Warteschlangentiefe nun keine Wirkung mehr auf die Rahmen-Ordnung. Bei Empfang einer Benachrichtigung vom Austrittsport, dass die Übertragung der Rahmen abgeschlossen ist, die sich zuvor in der Warteschlange befunden haben, übermittelt der Eintrittsport die Markierungs-Antwort-PDU an den Verbindungspartner, der die Übertragung der nachfolgenden Rahmen über die zweite Verbindung initiiert, ohne ein aus der Ordnung Geraten von Paketen zu verursachen.
  • Darüber hinaus hat das Flush-Protokoll, wie in den vorherigen Beispielen angemerkt ist, eine inhärente Wirkung auf die Leistung des Switch, da die Übertragung von in Warteschlangen stehenden Rahmen einfach bis zur Ankunft der Markierungs-Antwort-PDU verzögert wird. Ein anderes Ausführungsbeispiel der vorliegenden Erfindung widmet sich dieser unerwünschten Verzögerung bei der Übertragung von in Warteschlangen stehenden Rahmen bis zur Ankunft der Markierungs-Antwort-PDU beim Flush-Protokoll, indem eine Logik zum Verbindungsgruppierungslastausgleich ohne Implementierung der Flush-Protokoll-Funktion vorgesehen wird. Die Logik gemäß diesem Ausführungsbeispiel sieht im Allgemeinen ein Verfahren und eine Struktur zum Entscheiden vor, wann der Rahmen-Fluss von einer Verbindung zu einer anderen vermittelt werden kann, indem eine Überprüfung durchgeführt wird, um zu sehen, ob der Rahmen zu einer anderen Verbindung vermittelt werden kann, ohne dass die Möglichkeit besteht, dass am Ziel eine falsche Anordnung von Rahmen erzeugt wird. Daher kann in vielen Fällen, obgleich dies nicht immer möglich ist, die Rahmen-Übertragung zu einer anderen Verbindung vermittelt bzw. umgeschaltet werden, ohne die Übertragungsverzögerung infolge des Wartens auf die beim Flush-Protokoll verwendete Markierungs-Antwort-PDU zu verursachen. Die Entscheidung, einen Rahmen zur Übertragung an eine andere Verbindung zu vermitteln, basiert im Allgemeinen auf Kriterien, wie etwa die Anzahl an pro Zeiteinheit gesendeten Paketen oder die Anzahl an pro Zeiteinheit gesendeten Bytes. Darüber hinaus wird auch die Sequenz und Größe der Pakete, die in einer Warteschlange auf Übertragung warten, bei der Entscheidung, die Übertragung an eine andere Verbindung zu vermitteln, verglichen. Insbesondere ist dann, wenn ein Paket in einer Sequenz von Paketen größer als das vorherige Paket in der Sequenz ist, der Rahmen ein Kandidat zur Verbindungsvermittlung, da das vorstehend beschriebene Szenario, bei dem auf den großen Rahmen ein kleiner Rahmen folgt, vermieden wird. Des Weiteren umfasst die Entscheidung, eine Vermittlung durchzuführen, außerdem eine Überprüfung der Warteschlangenlängen an den Austrittsport, um sicherzustellen, dass aufgrund der verzögerten Übertragung infolge eines Warteschlangenrückstaus kein aus der Ordnung Geraten stattfindet.
  • 48, die ein detailliertes Flussdiagramm der Verbindungsgruppierungs-Falschanordnungsverhinderungslogik ist, veranschaulicht eindeutig den Betrieb der vorliegenden Erfindung. Die folgenden Variablen sind in 48 dargestellt:
    • Lp = Anzahl an Bits im vorherigen Paket
    • Lc = Anzahl an Bits im aktuellen Paket
    • Lj = Warteschlangenlänge an Verbindung j (Sendeseite)
    • Li = Warteschlangenlänge an Verbindung l (Sendeseite)
    • N = Anzahl an Bits in der Präambel + IPG
    • F = Anzahl an Bits zur Berücksichtigung der unterschiedlichen Verbindungslänge
  • Im Schritt 48-1 von 48 wird die Logik initialisiert, wenn Lp und Lc auf 0 gesetzt sind, bevor zu Schritt 48-2 weitergegangen wird, welcher der Paketankunft entspricht. Im Schritt 48-3 wird die Länge des Pakets durch die Verwendung eines Zählers ermittelt, der indirekt die Länge des Pakets aus der Zeit bestimmt, die notwendig ist, um das Paket bei einer vorbestimmten Rate zu empfangen, die auch der Paketflussrate des ankommenden Pakets entspricht. Schritt 48-4 stellt die erste logische Entscheidung in 48 dar, da die in Schritt 48-3 ermittelte Länge des Pakets mit einem vorbestimmten Schwellwert verglichen wird. Wenn die Länge des Pakets größer oder gleich dem Schwellwert ist, dann fährt die Logik mit Schritt 48-5 fort, in dem das Switch-Bit gesetzt wird, und danach geht die Logik zu Schritt 48-6 weiter. Wenn die Länge des Pakets so bestimmt wird, dass sie kleiner als der Schwell wert ist, dann geht die Logik weiter zu Schritt 48-6. Im Schritt 48-6 ermittelt die Logik die Anzahl an Bits im Paket, welche durch die Variable Lc dargestellt ist, bevor sie zu Schritt 48-7 übergeht. Beim Schritt 48-7 ermittelt die Logik, ob das Switch-Bit gesetzt ist, und fährt, wenn ja, mit Schritt 48-9 fort, und wenn nicht, geht die Logik zu Schritt 48-8 über. Die Schritte 48-3 bis 48-8 dienen im Allgemeinen dazu, die Rate oder Häufigkeit zu überwachen, mit der die Verbindung vermittelt wird. Wenn die Verbindung zu oft vermittelt wird, wie durch den voreingestellten Schwellwert bestimmt, dann kehrt die Verbindung einfach zu Schritt 48-2 zurück, ohne die Verbindung zu vermitteln. Diese Logik dient effektiv dazu, den Betrag an Vermittlung (Switching) zwischen Verbindungen zu begrenzen, da ein übermäßiges Vermitteln auch zu einer Leistungsverschlechterung führen kann.
  • Bezug nehmend nochmals auf Schritt 48-8, der den eingeschlagenen Weg darstellt, wenn das Switch-Bit in Schritt 48-7 nicht gesetzt ist, wählt die Logik den Austritts-Trunk Port i gemäß der Regellogik aus. Danach fährt die Logik fort, indem sie zu Schritt 48-2 zurückkehrt, welcher den vorstehend erwähnten Zustand darstellt, in dem die Verbindung zu oft vermittelt worden ist. In Schritt 48-9, der den eingeschlagenen Weg darstellt, wenn das Switch-Bit gesetzt ist und die Verbindung somit nicht zu oft vermittelt worden ist, ermittelt die Logik, ob die Anzahl an Bits im aktuellen Paket (Lc) addiert mit der Anzahl an Bits in der Präambel und IPG größer oder gleich der Anzahl an Bits im vorherigen Paket ist. Diese Ermittlung ist für die Lastausgleichslogik kritisch, da es dieser Schritt ist, der bestimmt, ob das erste Paket, das zur Übertragung über die Verbindung bereit ist, größer als das zweite Paket ist, das zur Übertragung über die Verbindung bereit ist. Wenn das erste Paket größer als das zweite ist, das heißt, wenn Lc + N ≥ Lp ist, dann wird in Schritt 48-10 bestimmt, dass das Paket kein Kandidat zur Vermittlung ist. Daher gehen Pakete, die keine Kandidaten zur Vermittlung sind, zu Schritt 48-11 weiter, in dem der Austrittsport als i gemäß der Regellogik ausgewählt wird. Wenn sich die Paketprofile in Schritt 48-9 zur Vermittlung qualifizieren, dann geht die Logik weiter zu Schritt 48-12, welcher in 49 beginnend mit Schritt 49-1 ausführlich dargestellt ist.
  • 49 stellt die Logik zum Lastausgleich in der Verbindungsgruppierungsumgebung dar, wenn der Rahmen als ein Kandidat zur Verbindungsvermittlung klassifiziert worden ist. Die Logik beginnt mit Schritt 49-1, in dem das Flussdiagramm die Klassifizierung des Rahmens veranschaulicht. In Schritt 49-2 wählt die Logik den nächsten Port j zur Verwendung im Verbindungsvermittlungsschema gemäß der Regellogik aus. In Schritt 49-3 ermittelt die Logik, ob die Warteschlangenlänge an der Verbindung j (Lj) addiert mit der Anzahl an Bits im aktuellen Paket (Lc) kleiner als die Warteschlangenlänge an l (Li) ist. Dieser Schritt bestimmt im Wesentlichen, ob die Warteschlange an der sendeseitigen Verbindung j über ausreichend Raum verfügt, um die Verbindungsvermittlung für den spezifischen, zu vermittelnden Rahmen durchzuführen. Einfach ausgedrückt, wenn die verfügbare Warteschlangentiefe der Sendeverbindung nicht ausreicht, um den über die alternative Verbindung zu sendenden Rahmen zu halten, dann ist die alternative Verbindung kein zur Wahl für die Vermittlung erwünschter Kandidat, da die Wahl dieser Verbindung wahrscheinlich die Übertragungsrate hemmen würde. Wenn in Schritt 49-3 ermittelt wird, dass Lj + Lc > Li ist, dann wird der Rahmen im Schritt 49-4 in die Warteschlange von Verbindung j gestellt, was die tatsächliche Vermittlung an die Verbindung j darstellt. Danach aktualisiert die Logik in Schritt 49-5 die Regeltabelle, um die neue Abbildung (Mapping) des Rahmens auf die Verbindung j zu reflektieren. Darüber hinaus wird nach dem Vermitteln des Rahmens an die Verbindung j das Reset Switch Bit gesetzt und die Zählung wird zurückgesetzt, wobei beide Operationen in Schritt 49-6 stattfinden. An diesem Punkt geht die Logik weiter zu Schritt 49-10, in dem die Vermittlungsoperation abgeschlossen ist.
  • Unter nochmaliger Bezugnahme auf Schritt 49-3, wenn die Logik ermittelt, dass Lj + Lc nicht größer als Li ist, dann geht die Logik weiter zu Schritt 49-7. Im Schritt 49-7 ermittelt die Logik, ob es noch weitere Ports gibt, die zur Vermittlung zur Verfügung stehen. Falls ja, dann kehrt die Logik zu Schritt 49-2 zurück, um den nächsten Port auszuwählen. Falls keine weiteren Ports mehr zur Vermittlung zur Verfügung stehen, dann geht die Logik zu Schritt 49-8 weiter, bei dem das Flussdiagramm zeigt, dass keine weiteren Austritts-Trunk Ports mehr vorhanden sind, die die Vermittlungskriterien erfüllen. Im nächsten Schritt, Schritt 49-9, wird der Rahmen in die Warteschlange von Verbindung i gestellt und die Logik geht zu Schritt 48-10 weiter, der den Abschluss der Verbindungsvermittlungsoperation darstellt.
  • Eine andere Situation, bei der ein aus der Ordnung Geraten von Rahmen potentiell auftreten kann, besteht, wenn ein Server mit einem Gigabit Port verbunden ist und ein Client über einen Trunk Port mit dem Server verbunden ist, wie in 50 gezeigt ist. Wenn der Client in 50 Daten vom Server anfordert, ist es denkbar, dass der gesamte Fluss in die Warteschlange einer einzelnen Verbindung der Trunk Group gestellt wird, wenn eine standardmäßige statische Mapping-Funktion (Abbildungsfunktion) verwendet wird, um den Fluss zu der Verbindung abzubilden. Diese Art von Mapping-Schema berücksichtigt nicht den Zustand des gesamten Systems und führt daher wahrscheinlich zu einer nicht ordnungsgemäßen Nutzung der Verbindungen sowie zu einer Leistungsverschlechterung und einer falschen Anordnung von Rahmen am Ziel. Unterschiedliche Netzwerke, womit diejenigen gemeint sind, an denen verschiedene Ports angebracht sind, wobei unterschiedliche Übertragungsgeschwindigkeiten zwischen den jeweiligen Ports vorhanden sind, stellen ein Beispiel dar, in dem diese Arten von Situationen auftreten können.
  • Zur Vermeidung dieser Probleme stellt die vorliegende Erfindung an jedem Austritts-Trunk Port in der Trunk Group zwei Warteschlangen oder Pufferspeicher bereit. Die erste Warteschlange wird zum Speichern von Rahmen verwendet, die von einem Hochgeschwindigkeitsport kommen, wie etwa dem in 50 gezeigten Gigabit Port. Die zweite Warteschlange wird zum Speichern von Rahmen verwendet, die von den restlichen Ports des Switch kommen, welche im Allgemeinen dieselbe Geschwindigkeit haben. 51 veranschaulicht die erste und zweite Warteschlange jedes Trunk Ports in der Trunk Group. Beim Implementieren der Verwendung der ersten und zweiten Warteschlangen wird ein Gigabit Port zunächst auf einem Trunk Port abgebildet, was durch Informationen dargestellt ist, die im Allgemeinen in einer Tabelle im Switch gespeichert sind. Im Trunk Port werden vom Gigabit Port ankommende Rahmen automatisch an die erste Warteschlange gesendet, während die von den anderen "Normalgeschwindigkeits"-Ports ankommenden Rahmen an die zweite Warteschlange gesendet werden. Jede erste Warteschlange hat einen hohen Pegel (HWM; High Watermark), der mit einem vorbestimmten Pegel in der Warteschlange in Verbindung gebracht wird, der im Allgemeinen den Pegel darstellt, bei dem die Warteschlange nahezu voll mit Rahmen ist. Somit stellt der HWM, der durch den Benutzer programmierbar ist, die Anzahl an Rahmen in der Warteschlange dar, bevor der Switch entscheidet, die Rahmen in eine Warteschlange eines anderen Ports, und zwar dessen zugeordnete erste Warteschlange, zu stellen. Daher erreicht, wenn sich die erste Warteschlange infolge des Eintreffens von Rahmen von einem Gigabit Port füllt, der Pegel in der Warteschlange schließlich den HWM, wobei der Switch zu diesem Zeitpunkt eine Markierungs-PDU in die Warteschlange einfügt und den Rahmen-Fluss zu einem anderen Trunk Port vermittelt bzw. umgeschaltet. Nachfolgende, vom Gigabit Port ankommende Rahmen werden dann an den alternativen Trunk Port gesendet, und die Mapping-Tabellen werden aktualisiert, um die Vermittlung zu reflektieren. Bei Ankunft von Daten am alternativen Port wird der Prozess des Füllens der ersten Warteschlange wiederholt, bis die Warteschlange wiederum den HWM erreicht, zu welchem Zeitpunkt ein anderer alternativer Port gesucht wird. 52 ist ein Flussdiagramm der differentiellen Flusshandhabungslogik. Bei Ankunft eines Rahmens im Switch wird der Rahmen in Schritt 52-1 auf dem geeigneten Trunk Port abgebildet. In Schritt 52-2 ermittelt die Logik, ob der ankommende Rahmen von einem Gigabit Port kommt. Wenn der Quellport kein Gigabit Port ist, dann fährt die Logik mit Schritt 52-3 fort, in dem der Rahmen in die zweite Warteschlange eingefügt wird, wobei der Prozess in Schritt 52-4 abgeschlossen ist. Wenn der Rahmen in Schritt 52-2 von einem Gigabit Port kam, dann geht die Logik zu Schritt 52-5 weiter, in dem die Logik ermittelt, ob die Anzahl an Rahmen in der ersten Warteschlange größer oder gleich dem HWM der Warteschlange ist. Wenn die Anzahl an Rahmen in der Warteschlange kleiner als der HWM ist, dann wird der Rahmen in Schritt 52-6 in die erste Warteschlange eingefügt, und der Prozess wird in Schritt 52-5 abgeschlossen. Wenn die Anzahl an Rahmen im Pufferspeicher größer oder gleich dem HWM ist, dann fährt die Logik mit Schritt 52-8 fort, in dem die Logik eine Markierungs-PDU in den Pufferspeicher der ersten Warteschlange einfügt und den Port als zum Erhalt weiterer Rahmen vom Gigabit Port nicht zur Verfügung stehend festlegt. Dieser Schritt bestimmt im Wesentlichen, ob der aktuelle Rahmen in den in der ersten Warteschlange verfügbaren Raum hineinpasst. Wenn Platz vorhanden ist, dann wird der Rahmen in die Warteschlange eingefügt, wenn nicht, dann muss der Rahmen und alle nachfolgenden Rahmen zu einem anderen Port und einer anderen Warteschlange umgeleitet werden. Die Markierungs-PDU, die in die aktuelle erste Warteschlange eingefügt wird, welche nach Art eines FIFO arbeitet, stellt schließlich die einzigen Daten dar, die infolge einer Warteschlangenentleerung aufgrund einer Rahmen-Übertragung am Austritt in der Warteschlange verblei ben. Zu diesem Zeitpunkt wird die Markierungs-PDU gelesen und die Logik weiß, dass sie Ports vermitteln muss, um die restlichen Rahmen abzurufen, die an den alternativen Trunk Port vermittelt wurden, wie in Schritt 59-9 gezeigt, in dem der nächste verfügbare Trunk Port durch die Logik ausgewählt wird. Diese Wahl wird im Wesentlichen mittels einer Operation des Round-Robin-Typs durchgeführt, in der die Logik einfach den nächsten Port überprüft, um festzustellen, ob er verfügbar ist, wobei, wenn nicht, die Logik zu anderen Ports weitergeht, bis ein verfügbarer Port gefunden wird. Wenn in Schritt 52-9 ein verfügbarer Port gefunden wird, dann wird der Rahmen-Fluss in Schritt 52-10 an diesen Port vermittelt, und der Rahmen-Fluss wird nun beginnen, die erste Warteschlange des neu ausgewählten Ports zu füllen. Die Mapping-Tabelle, die die Portvermittlung widerspiegelt, wird in Schritt 52-11 aktualisiert, und der Prozess ist in Schritt 52-12 abgeschlossen.
  • Bei Abschluss der Portvermittlung wird auf der Austrittsseite des Switch eine zusätzliche Logik implementiert, um die Portvermittlungslogik zu vervollständigen. 53 veranschaulicht die Logik auf der Austrittsseite des Switch beginnend mit Schritt 53-1. In Schritt 53-1 wird ein Rahmen am Austrittsport versandt, wodurch ein Rahmen aus einer der ersten oder zweiten Warteschlangen entfernt wird. Sobald ein Rahmen am Austritt versandt worden ist, geht die Logik zu Schritt 53-2 weiter, in dem ermittelt wird, ob der Rahmen aus einer ersten Warteschlange stammte. Wenn der Rahmen nicht aus einer ersten Warteschlange stammte, dann fährt die Logik mit Schritt 53-3 fort, in dem eine Bestimmung durchgeführt wird, ob sich ein weiterer Rahmen in einer ersten oder zweiten Warteschlange befindet. Wenn ein weiterer Rahmen in einer der Warteschlangen auf den Austritt wartet, dann kehrt die Logik zu Schritt 53-1 zurück, um den wartenden Rahmen am Austritt zu versenden. Wenn keine weiteren Rahmen zum Austritt in der Warteschlange stehen, dann geht die Logik zu Schritt 53-7 weiter, in dem die Logik darauf wartet, dass in einer der Warteschlangen ein Rahmen ankommt. Danach bestimmt die Logik in Schritt 53-8, ob sich in der ersten Warteschlange irgendwelche Rahmen befinden. Falls ja, dann bestimmt die Logik, ob es o.k. ist, den Rahmen am Austritt zu versenden, und falls nicht, dann kehrt die Logik in den Anfangszustand gemäß Schritt 53-1 zurück.
  • Bezug nehmend nochmals auf Schritt 53-2 bestimmt die Logik dann, wenn der am Austritt versandte Rahmen von der ersten Warteschlange kam, ob der Warteschlangenpegel dieser spezifischen Warteschlange kleiner oder gleich dem niedrigen Pegel (LWM; Low Watermark) ist, der dieser Warteschlange zugeordnet ist. Wenn der Pegel des verfügbaren Raums in der Warteschlange kleiner oder gleich dem LWM ist, dann fährt die Logik mit Schritt 53-5 fort, in dem der Port als verfügbar festgelegt wird, um Rahmen vom Gigabit Port zu empfangen. Dieser Schritt stellt das Zurücksetzen des Ports als verfügbar dar, und zwar in der Situation, in der die Portwarteschlange infolge des Füllens der Warteschlange durch einen Gigabit Port deaktiviert worden ist. Danach geht die Logik weiter zu Schritt 53-6, in dem ermittelt wird, ob ein weiterer Rahmen in der ersten oder zweiten Warteschlange auf den Austritt wartet. Falls ja, dann kehrt die Logik zu Schritt 53-1 zurück und wiederholt die zuvor genannte Schrittfolge, und wenn nicht, dann geht die Logik zu Schritt 53-7 weiter, in dem der nächste Rahmen erwartet wird. Daher kann der Switch aufgrund der Implementierung der zwei Warteschlangen, die mit spezifischen Rahmenflussraten assoziiert sind, eine lange Kette (String) von Rahmen von einem Gigabit Port empfangen und diese Rahmen effizient und exakt an ihre jeweiligen Ziele senden, ohne irgendein aus der Ordnung Geraten von Rahmen zu verursachen.
  • Bezug nehmend nochmals auf die Besprechung der Stapelkonfiguration wird beim allgemeinen Betrieb des SOC 10 in einer Stapelkonfiguration ein an einem Eintrittsport ankommendes Paket direkt an den IPIC 90 gesendet, nachdem ermittelt worden ist, dass die Zieladresse des Pakets ein anderer SOC 10 im Stapel ist. Der IPIC 90 empfängt Zellen von den Eintrittsports des SOC 10, und diese Zellen werden zur Übertragung im NBP 92 zusammengesetzt, welcher der lokale Speicher für den IPIC 90 ist. Die verknüpften Zellen werden zu Rahmen zusammengesetzt, wobei jedem der Rahmen ein Modul-Header angehängt wird, bevor er über die HiGig-Schnittstelle 261 an einen anderen SOC 10 versandt wird. Bei einer Umkehrung dieses Prozesses empfängt der IPIC 90 auch Rahmen von anderen Switches über die HiGig-Schnittstelle 261. Die von der HiGig-Schnittstelle 261 in den IPIC 90 eingehenden Rahmen werden beim Eintreten in den SOC 10 ebenfalls im NBP 92 gespeichert. Der IPIC 90 streift den Modul-Header ab, der dem Rahmen vom Ursprungs-Switch angehängt worden ist, und führt die IPIC-Adressauflösungslogik durch. Danach wird das Paket in Zellen zerteilt und an die MMU 70 gesendet. Der NBP-Manager schreibt einen Paketzeiger in die COS-Warteschlangen, nachdem die Zellen zu einem Rahmen zusammengesetzt worden sind. Der NBP-Manager verwendet die vom P-Kanal 82 erhaltenen COS-Parameter dazu, die COS-Warteschlange in den NBP 92 zu schreiben. Daher wird, wenn es mehrere COS-Warteschlangen gibt, die COS-Warteschlange höchster Priorität im Allgemeinen zuerst bedient, gefolgt von den COS-Warteschlangen geringerer Priorität. Dieses Verfahren zur Bedienung (Servicing) von COS-Warteschlangen wird häufig gemäß einem gewichteten Round-Robin-, gewichteten Fair-Queuing- oder einem anderen ähnlichen Algorithmus durchgeführt. Die vorliegende Erfindung sieht jedoch ein weiteres Verfahren zum Bedienen der COS-Warteschlangen vor, wobei der Warteschlangenzustand an der Austritts-COS-Warteschlange im Stapel zum Einlass in die COS-Warteschlangen berechtigt. Allgemein ausgedrückt umfasst dieses zusätzliche durch die vorliegende Erfindung bereitgestellte Verfahren die Überwachung der ausgewählten Austritts-COS-Warteschlange, das Senden von Nachrichtenbenachrichtigungsnachrichten quer durch den Stapel und das Pre-Scheduling der Pakete der überwachten COS-Warteschlange an dem Quell-IPIC, welche Tätigkeiten nachfolgend ausführlich beschrieben werden.
  • Bei einer Stapelkonfiguration unterstützt der hierin beschriebene SOC 10 im Allgemeinen bis zu 32 Module, obgleich er nicht auf eine spezifische Anzahl beschränkt ist. Jedes Chipmodul kann aus 26 Ports bestehen und jeder Port kann 8 COS-Warteschlangen unterstützen. Daher würde der vorstehend erwähnte Überwachungsschritt bei diesem Beispiel einer Konfiguration des SOC 10 an jedem Quell-IPIC 90 in einem SOC 10 6656 COS-Warteschlangen (32 × 26 × 8) überwachen müssen. Der Status dieser 6656 Warteschlangen kann beispielsweise als FULL (voll) (100%), ALMOST FULL (nahezu voll) (90%), ALMOST EMPTY (nahezu leer) (10%) und EMPTY (leer) (10%) beschrieben werden. Diese Statusdarstellung wird immer dann als eine S-Kanalnachricht an alle gestapelten SOCs versandt, wenn eine der 6656 COS-Warteschlangen infolge des Datenflusses ihren Status ändert. Daher ist es allein von einem Standpunkt der Implementierung aus offensichtlich, dass der Überwachungsschritt der vorliegenden Erfindung nicht die Überwachung einer jeden der 6656 Port-Warteschlangen umfassen kann, da eine solche Überwachung infolge der häufigen Nachrichtenaktualisierungen, die sich durch das Switch-Fabric oder den Switch-Ring bewegen, ressourcenintensiv wäre. Daher geht die vorliegende Erfindung, wenn auch nur zu Zwecken der Beschreibung, davon aus, dass zwei Ports an zwei beliebigen Modulen im Chip überwacht werden. Dies ergibt 16 Warteschlangen (2 × 2 × 4), die an dem Quell-IPIC zu überwachen sind. Die vorliegende Erfindung umfasst jedoch die Überwachung einer beliebigen Anzahl an Ports und Warteschlangen.
  • 54 zeigt ein Blockdiagramm des vorstehend beschriebenen Ausführungsbeispiels. In jedem IPIC 90 ist ein Pre-Scheduler 101 vorhanden, dessen Funktion es ist, immer nur eine der sechzehn Warteschlangen auf einmal auszuwählen, um sie in eine der vier COS-Warteschlangen zu senden. 54 zeigt außerdem die sechzehn Warteschlangen, deren Status an jedem Quell-IPIC 90 verwaltet wird. Allgemein ausgedrückt wird im Betrieb, wenn der Status einer Austritts-COS-Warteschlange EMPTY oder ALMOST EMPTY ist, sofort ein Zeigereintrag in die normalen COS-Warteschlangen geschrieben, was durch einen der vorstehend erwähnten allgemeinen Queuing-Algorithmen bedient wird. Wenn jedoch ein Paket an dem Quell-IPIC 90 ankommt und der Ziel-COS-Warteschlangenstatus für diesen Port FULL oder ALMOST FULL ist, dann wird der Paketzeigereintrag nicht sofort in die normale COS-Warteschlange geschrieben, auch wenn sie eine höhere Priorität hat, vorausgesetzt, dass andere COS-Warteschlangen vorhanden sind, die darauf warten, bedient zu werden. Die Logik der vorliegenden Erfindung verzögert vielmehr das Schreiben des Paketzeigereintrags in die COS-Warteschlange, bis der Warteschlangenstatus einen vorbestimmten Pegel erreicht. Die COS-Warteschlange höherer Priorität, eine der 16, als solche wird abhängig vom Austritts-Warteschlangenstatus bedient.
  • 55 zeigt ein detailliertes Flussdiagramm der Logik, die die Bedienung der COS-Warteschlangen als eine Funktion des Austritts-Warteschlangenstatus unterstützt. In Schritt 55-1 kommt ein Paket an und in Schritt 55-2 wird sofort die Adressauflösung initiiert, wobei der Zielchip, der Zielport und die Ziel-COS bestimmt werden. Danach bestimmt die Logik in Schritt 55-3, ob der Zielport des Pakets, der durch die ARL in Schritt 55-2 bestimmt worden ist, ein überwachter Port ist. Wenn die Bestimmung in Schritt 55-3 ergibt, dass der Zielport des Pakets nicht überwacht wird, dann springt die Logik zu Schritt 55-7. Wenn der Zielport des Pakets jedoch überwacht wird, dann fährt die Logik mit Schritt 55-4 fort, in dem der Pre-Scheduling-Algorithmus betrieben wird, bevor zu Schritt 55-5 übergegangen wird. In Schritt 55-5 überprüft die Logik den Status der Austritts-COS-Warteschlange. In Schritt 55-6 ermittelt die Logik, ob der in Schritt 55-5 geprüfte Austritts-COS-Status Empty (E) oder Almost Empty (AE) ist. Wenn ermittelt wird, dass der Austritts-Warteschlangenstatus E oder AE ist, dann weiß die Logik, dass die Warteschlange das Paket annehmen kann, weshalb die Logik mit Schritt 55-7 fortfährt, in dem der Zeigereintrag für das Paket in die Austritts-COS-Warteschlange geschrieben wird. Danach betreibt die Logik in Schritt 55-8 den Scheduler.
  • Wenn in Schritt 55-6 ermittelt wird, dass der Austritts-COS-Warteschlangenstatus nicht E oder AE ist, dann geht die Logik zu Schritt 55-9 weiter, in dem die Logik bestimmt, ob der Austritts-COS-Warteschlangenstatus Almost Full (AF) ist. Wenn ermittelt wird, dass der Status der Austritts-COS-Warteschlange AF ist, dann geht die Logik weiter zu Schritt 55-10, bei dem die Logik die nächste COS-Warteschlange gemäß einem vorbestimmten Auswahlalgorithmus auswählt. Wenn in Schritt 55-9 ermittelt wird, dass der Austritts-COS-Warteschlangenstatus nicht AF ist, dann fährt die Logik mit Schritt 55-11 fort, in dem die Logik bestimmt, ob der Austritts-Warteschlangenstatus Full (F) ist. Da die vorhergehenden Ermittlungsschritte alle restlichen Statusindikatoren eliminiert haben, weiß die Logik im Wesentlichen, dass der Status der Austritts-COS in Schritt 55-11 F ist, und deshalb geht die Logik zu Schritt 55-12 weiter, in dem das Paket an dem IPIC 90 fallen gelassen wird. Nach dem Fallenlassen des Pakets im Schritt 55-12 ist die Logik im Schritt 55-13 abgeschlossen.
  • Zusammenfassend sieht die vorliegende Erfindung ein Verfahren zum Bedienen der COS-Warteschlangen an einem Quell-IPIC 90 basierend auf dem Austrittsport-Warteschlangenstatus innerhalb des Stapels vor, im Gegensatz zur Bedienung der Warteschlangen basierend auf der COS-Priorität. Durch die Bedienung der Warteschlangen basierend auf dem Austritts-Warteschlangenstatus berücksichtigt das Verfahren effektiv die COS-Priorität in Verbindung mit dem Austritts-Warteschlangenstatus, was wiederum die Portüberlastung und Übertragungsverzögerung quer durch den Stapel minimiert.
  • Die oben erörterte Konfiguration der Erfindung ist in einem bevorzugten Ausführungsbeispiel der Erfindung auf einem Halbleitersubstrat wie etwa Silizium mit geeigneten Halbleiterherstellungsverfahren und auf der Grundlage eines Schaltungs-Layouts verkörpert, das auf der Grundlage der oben diskutierten Ausführungsbeispiele den Fachleuten auf diesem Gebiet klar wäre. Ein Fachmann auf dem Gebiet des Halbleiterdesigns und der Halbleiterherstellung wäre in der Lage, die verschiedenen Module, Schnittstellen und Tabellen, Pufferspeicher, etc. der vorliegenden Erfindung auf einem einzigen Halbleitersubstrat auf der Grundlage der oben erörterten architektonischen Beschreibung zu implementieren. Es würde auch innerhalb des Schutzumfangs der Erfindung liegen, die offenbarten Elemente der Erfindung in diskreten elektronischen Bauteilen zu implementieren, wobei man den Nutzen aus den funktionellen Aspekten der Erfindung ergreifen würde, ohne die Vorteile durch die Verwendung eines einzigen Halbleitersubstrats zu maximieren.

Claims (4)

  1. Verfahren zum Verhindern, dass Rahmen in einem Netzwerk-Switch (10) aus der Ordnung geraten, wobei das Verfahren die folgenden Schritte umfasst: Empfangen eines ersten Abschnitts eines Strings von Paketen von einem Quellport an einem ersten Port (13, 15); Übertragen des ersten Abschnitts des Strings von Paketen zu einem zweiten Port (13, 15) zur Übertragung zu einem Ziel; dadurch gekennzeichnet, dass das Verfahren des Weiteren folgende Schritte umfasst: Senden eines Indikators von dem ersten Port (13, 15) zu dem zweiten Port (13, 15); Empfangen des Indikators an dem zweiten Port (13, 15); Senden eines Antwortindikators von dem zweiten Port (13, 15) zu dem ersten Port (13, 15); und Empfangen eines zweiten Abschnitts des Strings von Paketen von dem Quellport an einem dritten Port (13, 15).
  2. Verfahren nach Anspruch 1, wobei der Schritt des Sendens des Antwortindikators des Weiteren den Schritt des Bestimmens umfasst, ob der erste Abschnitt des Strings von Paketen, der zu dem zweiten Port (13, 15) übertragen worden ist, zu dem Ziel übertragen worden ist, bevor der Antwortindikator gesendet worden ist.
  3. Verfahren zum Verhindern, dass Rahmen in einem Netzwerk-Switch (10) aus der Ordnung geraten, wobei das Verfahren die folgenden Schritte umfasst: Empfangen von Paketen an einem ersten Eintrittsport (13, 15) von einem Quellport; Übertragen der Pakete von dem ersten Eintrittsport (13, 15) zu einem Austrittsport (13, 15) zur Übertragung zu einem Ziel; Bestimmen, dass das Empfangen der Pakete zu einem zweiten Eintrittsport (13, 15) umgeschaltet werden soll; dadurch gekennzeichnet, dass das Verfahren des Weiteren folgende Schritte umfasst: Senden eines Umschaltindikators von dem ersten Eintrittsport (13, 15) zu dem Austrittsport (13, 15); Bestimmen, wann ein Antwort-Umschaltindikator von dem Austrittsport (13, 15) zu dem ersten Eintrittsport (13, 15) gesendet werden soll; Senden des Antwort-Umschaltindikators von dem Austrittsport (13, 15) zu dem ersten Eintrittsport (13, 15); Weiterleiten des Antwort-Umschaltindikators zu dem Quellport; und Umschalten des Empfangens der Pakete auf den zweiten Eintrittsport (13, 15).
  4. Verfahren nach Anspruch 3, wobei der Schritt des Bestimmens, wann ein Antwort-Umschaltindikator gesendet werden soll, des Weiteren den Schritt des Wartens mit dem Senden des Antwort-Umschaltindikators umfasst, bis eine Anzahl an Paketen in dem Austrittsport (13, 15) von dem Austrittsport (13, 15) zu dem Ziel übertragen werden.
DE60034320T 1999-03-17 2000-03-17 Verfahren zur vermeidung von nichtsequentiellen rahmen in einer netzwerkvermittlungsstelle Expired - Lifetime DE60034320T2 (de)

Applications Claiming Priority (11)

Application Number Priority Date Filing Date Title
US12487899P 1999-03-17 1999-03-17
US124878P 1999-03-17
US12758799P 1999-04-02 1999-04-02
US127587P 1999-04-02
US13560799P 1999-05-24 1999-05-24
US135607P 1999-05-24
US343409 1999-06-30
US09/343,409 US6335932B2 (en) 1998-07-08 1999-06-30 High performance self balancing low cost network switching architecture based on distributed hierarchical shared memory
US14970699P 1999-08-20 1999-08-20
US149706P 1999-08-20
PCT/US2000/007015 WO2000056013A2 (en) 1999-03-17 2000-03-17 Method for avoiding out-of-ordering of frames in a network switch

Publications (2)

Publication Number Publication Date
DE60034320D1 DE60034320D1 (de) 2007-05-24
DE60034320T2 true DE60034320T2 (de) 2007-12-20

Family

ID=27537704

Family Applications (1)

Application Number Title Priority Date Filing Date
DE60034320T Expired - Lifetime DE60034320T2 (de) 1999-03-17 2000-03-17 Verfahren zur vermeidung von nichtsequentiellen rahmen in einer netzwerkvermittlungsstelle

Country Status (5)

Country Link
EP (1) EP1159805B1 (de)
AT (1) ATE359640T1 (de)
AU (1) AU4325800A (de)
DE (1) DE60034320T2 (de)
WO (1) WO2000056013A2 (de)

Families Citing this family (18)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6876653B2 (en) * 1998-07-08 2005-04-05 Broadcom Corporation Fast flexible filter processor based architecture for a network device
US7009933B2 (en) * 2001-01-30 2006-03-07 Broadcom Corporation Traffic policing of packet transfer in a dual speed hub
US7239636B2 (en) 2001-07-23 2007-07-03 Broadcom Corporation Multiple virtual channels for use in network devices
CN100338922C (zh) * 2001-09-11 2007-09-19 友讯科技股份有限公司 网络交换器的地址表格中地址数目的控制方法
US7295555B2 (en) 2002-03-08 2007-11-13 Broadcom Corporation System and method for identifying upper layer protocol message boundaries
US7333498B2 (en) * 2002-05-15 2008-02-19 Hewlett-Packard Development Company, L.P. Method and apparatus for separating data packets in a memory buffer
CN100336363C (zh) * 2002-09-18 2007-09-05 中兴通讯股份有限公司 一种实现聚合链路流量均衡的方法
CN100372292C (zh) * 2003-08-11 2008-02-27 华为技术有限公司 三层交换机上实现组播精确到端口转发的方法
US7697540B2 (en) 2004-09-08 2010-04-13 Telefonaktiebolaget L M Ericsson (Publ) Quality of service (QoS) class reordering with token retention
US7724663B2 (en) 2004-09-08 2010-05-25 Telefonaktiebolaget L M Ericsson (Publ) Counter based quality of service (QoS) class upgrade
US7512132B2 (en) * 2004-09-08 2009-03-31 Telefonaktiebolaget L M Ericsson (Publ) Quality of service (QoS) class reordering
US7649846B2 (en) 2005-04-12 2010-01-19 Fujitsu Limited Purge mechanism in link aggregation group management
US7639614B2 (en) 2005-04-12 2009-12-29 Fujitsu Limited Distribution-tuning mechanism for link aggregation group management
US8451713B2 (en) * 2005-04-12 2013-05-28 Fujitsu Limited Special marker message for link aggregation marker protocol
US20070002770A1 (en) * 2005-06-30 2007-01-04 Lucent Technologies Inc. Mechanism to load balance traffic in an ethernet network
WO2019232694A1 (zh) * 2018-06-05 2019-12-12 华为技术有限公司 队列控制方法、装置及存储介质
WO2021240215A1 (en) * 2020-05-26 2021-12-02 Telefonaktiebolaget Lm Ericsson (Publ) Reordering and reframing packets
US11411891B2 (en) * 2020-10-30 2022-08-09 Ge Aviation Systems Llc System and method for a time-sensitive network

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4899334A (en) * 1987-10-19 1990-02-06 Oki Electric Industry Co., Ltd. Self-routing multistage switching network for fast packet switching system
US5253248A (en) * 1990-07-03 1993-10-12 At&T Bell Laboratories Congestion control for connectionless traffic in data networks via alternate routing
US5875176A (en) * 1996-12-05 1999-02-23 3Com Corporation Network adaptor driver with destination based ordering
US6452933B1 (en) * 1997-02-07 2002-09-17 Lucent Technologies Inc. Fair queuing system with adaptive bandwidth redistribution

Also Published As

Publication number Publication date
DE60034320D1 (de) 2007-05-24
WO2000056013A2 (en) 2000-09-21
EP1159805A2 (de) 2001-12-05
WO2000056013A3 (en) 2001-03-01
ATE359640T1 (de) 2007-05-15
AU4325800A (en) 2000-10-04
EP1159805B1 (de) 2007-04-11

Similar Documents

Publication Publication Date Title
DE60031515T2 (de) Netzwerkvermittlung
DE60005993T2 (de) Verfahren und netzwerkvermittlungsstelle mit datenserialisierung durch gefahrlose mehrstufige störungsfreie multiplexierung
DE60126222T2 (de) Verbundene Netzvermittlungskonfiguration
DE60127794T2 (de) Gebundene Netzschalterkonfiguration
DE60133352T2 (de) Gebundene Netzvermittlungskonfiguration
US6952401B1 (en) Method for load balancing in a network switch
DE60126223T2 (de) Anordnung zur Verbindung von Netzvermittlungsstellen
DE60034320T2 (de) Verfahren zur vermeidung von nichtsequentiellen rahmen in einer netzwerkvermittlungsstelle
DE60010328T2 (de) Spiegelung in einer netzwerkvermittlungsstapelanordnung
US7643481B2 (en) Network switch having a programmable counter
US6996099B1 (en) Network switch having a programmable counter
US6810037B1 (en) Apparatus and method for sorted table binary search acceleration
US7366171B2 (en) Network switch
US7295552B1 (en) Cluster switching architecture
DE60217988T2 (de) System und Verfahren zum zeitschlitzbasierten Erlernen und Durchsuchen von ARL Tabellen mit Blockierung der Einfügung
DE60022870T2 (de) Verfahren zur überlastungsverwaltung in einer netzwerkvermittlung
DE60217572T2 (de) System und Verfahren zum zeitschlitzbasierten Erlernen und Durchsuchen von ARL Tabellen unter Verwendung von Schreib-snoop
DE60036292T2 (de) Architektur zur gruppenbasierten vermittlung
DE60037424T2 (de) Vereinigte Tabelle zur L2-, L3-, L4-Vermittlung und Filterung
DE60037512T2 (de) Speicherverwaltungseinheit in einer netzvermittlungsstelle

Legal Events

Date Code Title Description
8364 No opposition during term of opposition
8328 Change in the person/name/address of the agent

Representative=s name: BOSCH JEHLE PATENTANWALTSGESELLSCHAFT MBH, 80639 M