DE69837464T2 - Vermittlungsnetzaufbau für IP-Mehrfachsendung und für integrierte Dienste - Google Patents

Vermittlungsnetzaufbau für IP-Mehrfachsendung und für integrierte Dienste Download PDF

Info

Publication number
DE69837464T2
DE69837464T2 DE69837464T DE69837464T DE69837464T2 DE 69837464 T2 DE69837464 T2 DE 69837464T2 DE 69837464 T DE69837464 T DE 69837464T DE 69837464 T DE69837464 T DE 69837464T DE 69837464 T2 DE69837464 T2 DE 69837464T2
Authority
DE
Germany
Prior art keywords
multicast
atm
data
switches
logical
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
DE69837464T
Other languages
English (en)
Other versions
DE69837464D1 (de
Inventor
Ajay V. c/o NEC USA Princeton Bakre
Takeshi c/o NEC USA Inc. Princeton Nishida
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.)
Juniper Networks Inc
Original Assignee
Juniper Networks Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Juniper Networks Inc filed Critical Juniper Networks Inc
Publication of DE69837464D1 publication Critical patent/DE69837464D1/de
Application granted granted Critical
Publication of DE69837464T2 publication Critical patent/DE69837464T2/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/70—Admission control; Resource allocation
    • H04L47/72—Admission control; Resource allocation using reservation actions during connection setup
    • H04L47/724—Admission control; Resource allocation using reservation actions during connection setup at intermediate nodes, e.g. resource reservation protocol [RSVP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/02—Details
    • H04L12/16—Arrangements for providing special services to substations
    • H04L12/18—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast
    • H04L12/1836—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast with heterogeneous network architecture
    • 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/4608—LAN interconnection over ATM networks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/70—Admission control; Resource allocation
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/70—Admission control; Resource allocation
    • H04L47/78—Architectures of resource allocation
    • H04L47/783—Distributed allocation of resources, e.g. bandwidth brokers
    • H04L47/785—Distributed allocation of resources, e.g. bandwidth brokers among multiple network domains, e.g. multilateral agreements
    • H04L47/786—Mapping reservation between domains
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/70—Admission control; Resource allocation
    • H04L47/80—Actions related to the user profile or the type of traffic
    • H04L47/806—Broadcast or multicast traffic
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/70—Admission control; Resource allocation
    • H04L47/82—Miscellaneous aspects
    • H04L47/827—Aggregation of resource allocation or reservation requests
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04Q—SELECTING
    • H04Q11/00—Selecting arrangements for multiplex systems
    • H04Q11/04—Selecting arrangements for multiplex systems for time-division multiplexing
    • H04Q11/0428—Integrated services digital network, i.e. systems for transmission of different types of digitised signals, e.g. speech, data, telecentral, television signals
    • H04Q11/0478—Provisions for broadband connections
    • 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
    • H04L2012/5619—Network Node Interface, e.g. tandem connections, transit switching
    • H04L2012/5621—Virtual private network [VPN]; Private-network - network-interface (P-NNI)
    • 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
    • H04L2012/5629—Admission control
    • H04L2012/563—Signalling, e.g. protocols, reference model
    • 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
    • H04L2012/5638—Services, e.g. multimedia, GOS, QOS
    • H04L2012/564—Connection-oriented
    • H04L2012/5642—Multicast/broadcast/point-multipoint, e.g. VOD
    • 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
    • H04L2012/5638—Services, e.g. multimedia, GOS, QOS
    • H04L2012/5665—Interaction of ATM with other protocols
    • H04L2012/5667—IP over ATM

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Small-Scale Networks (AREA)

Description

  • Hintergrund der Erfindung:
  • Die vorliegende Erfindung bezieht sich auf ein Verfahren und eine Netzwerkarchitektur für das Mapping von Internetworking-Protokoll (IP)-Multicast und integrierten Services (d.h. unterschiedlichen Niveaus von Quality of Service) über ein Asynchroner-Übertragungsmodus (ATM)-Netzwerk. Das Verfahren und die Architektur, die auf Multicast-Schaltern basieren, erlauben IP/Ressource Reservation Protocol (RSVP)-Anwendungen, die auf ATM-Hosts laufen, um nahtfrei an Internet-weiten Multicast-Sitzungen teilzunehmen. Das Verfahren und die Architektur machen von ATM-Fähigkeiten einen guten Gebrauch, um Merkmale wie die Empfängerheterogenität, das Abkürzungs-Routing und die Skalierbarkeit zu unterstützen.
  • Beschreibung des verwandten Stands der Technik
  • Die gegenwärtigen Internet-Services, einschließlich des IP-Multicasts, basieren auf der Best-Effort-Lieferung von Datagrammen als dem alleinigen zugrunde liegenden Mechanismus. Der Best-Effort-Lieferungsmechanismus ist jedoch nicht für das Transportieren von Medienströmen, wie Audio und Video, über das Internet verwendbar, da Anwendungen, die solche Ströme verwenden, häufig eine Datenanlieferung mit Verzögerung und Bandbreitengarantien für eine erfolgreiche Wiedergabe von Medienströmen an dem empfangenden Ende erfordern. Des Weiteren wächst der Internet-Verkehr weiterhin schneller als die Geschwindigkeit, mit der zusätzliche Kapazitäten der Internet-Infrastruktur hinzugefügt werden. Dies heißt, dass der Datenverkehr, der über das Internet verläuft, unvorhersehbaren Verzögerungen und einem möglichen Paketverlust wegen der erhöhten Last auf Internet-Servern unterliegt.
  • Während herkömmliche Internet-Anwendungen, wie Email, Dateitransfer, Remote Login etc., die auf dem Transmission Control Protocol (TCP) basieren, ihren Netzwerkgebrauch den vorherrschenden Bedingungen anpassen können, sind neu auftauchende Multimedia-Anwendungen, wie Video auf Nachfrage und jene, die auf Streaming Video basieren, weniger tolerant darin, die Verkehrsparameter, wie Ende-zu-Ende-Verzögerung und Jitter, zu ändern. Die einzige Weise, diese Multimedia-Anwendungen zu unterstützen (die von derjenigen, die Internet-Kapazität weiter auszubauen, verschieden ist) besteht darin, mehrer Service-Klassen und eine Fähigkeit des Reservierens von Ressourcen im Internet zur Verfügung zu stellen.
  • Resultierend aus den Bemühungen der Internet Engineering Task Force (IETF) (z.B. Wroclawski, Specification of the Controlled Load Network Element Service, Network Working Group, Request For Comments: 2211, Kategorie: Standards Track, September 1997; und Shenker et al., Specification of Guarenteed Quality of Service, Network Working Group, Request For Comments: 2212, Kategorie: Standards Track, September 1997) wird erwartet, dass eine Unterstützung für auf Quality of Service (QoS) basierende Service-Klassen, bekannt als integrierte Services, im Internet in naher Zukunft verfügbar sein wird. Zusätzlich wird das Ressource Reservation Protocol (RSVP) auch durch das IETF als ein Internetworking-Protokoll für eine Ressourcenreservierung standardisiert, das von Anwendungen im Multiservice-Internet verwendet wird. Siehe R. Braden, et al., „Ressource Reservation Protocol (RSVP)-Version 1 Functional Specification", Internet Engineering Task Force, Network Working Group, Request For Comments: 2205, Kategorie: Standards Track, September, 1997.
  • Der asynchrone Übertragungsmodus (ATM) ist als eine integrierte Verbindungsschicht- und Netzwerkschichtlösung für das Bereitstellen der auf QoS gegründeten Services in den lokalen und Fernbereichsnetzwerken entwickelt worden. Obgleich die ATM-Technologie ihre eigene Version der auf QoS gegründeten Dienstleistungen unterstützt, ist es unwahrscheinlich, dass ATM-Netze vollständig die vorhandene auf IP gegründete Internet-Infrastruktur in der vorhersehbaren Zukunft ersetzen. Folglich werden mindestens in den Ausgangsstadien der ATM-Entwicklung Hosts, die an ATM-Netze angeschlossen sind, damit fortfahren, IP- und RSVP-Anwendungen laufen zu lassen, um mit anderen Hosts, von denen die meisten immer noch an Legacy-Netzwerken wie dem Ethernet angeschlossen sein können, zu kommunizieren.
  • Da die ATM-Technologie einfach die QoS-Unterstützung zur Verfügung stellt, die für IP-integrierte Services benötigt wird, scheint das Problem des Mappings dieser Services über ein ATM-Netzwerk ein einfaches zu sein. Ein solches Mapping ist jedoch aus den folgenden Gründen ziemlich schwierig:
    • (1) Da das IP das Netzwerk-Schicht-Protokoll der Wahl für den Gebrauch mit RSVP ist, werden alle Netztechniken, die von dem Ethernet zu Token Ring bis zu ATM reichen, als Verbindungsschicht-Technologien durch RSVP/IP behandelt. Ein solcher Ansatz verursacht keine Konflikte mit dem Gebrauch von herkömmlichen Netztechniken wie Ethernet, aber mit ATM-Netzen hat dieser Ansatz ein inhärentes Problem dahingehend, dass er die Netzwerkschichtfähigkeiten (Adressieren und Routen) von ATM nicht verwenden kann;
    • (2) IP-Multicasting, das im Kern von integrierten Services und RSVP ist, wird gemeinhin in den vorhandenen IP-Netzen verwendet. Auf der anderen Seite ist die Unterstützung für leistungsfähiges Multicasting in ATM noch unzulänglich. Virtuelle Punkt-zu-Multipunkt-Schaltungen (VCs) leiden, obgleich sie in ATM unterstützt werden, unter Skalierungsproblemen; und
    • (3) Einige der RSVP-Merkmale, nämlich die Empfängerheterogenität und dynamischer QoS, weisen keine äquivalenten Mechanismen in ATM auf.
  • Ein Vorschlag für das Bereitstellen von IP integrierten Services über ATM ist der Cell Switch Router (CSR) von Toshiba. Siehe Katsube, et al., „Toshiba's Router Architecture Extensions for ATM: Overview," Network Working Group, Request For Comments: 2098, Kategorie: Informational, Februar 1997. Ein CSR ist ein traditioneller IP-Router, der an einem ATM-Schalter angebracht wird und zum „Verknüpfen" (Concatenating) ankommender und abgehender VCs in der Lage ist, um Abkürzungswege durch Router in einer ATM-Wolke zur Verfügung zu stellen. Einzelne Intralogisches-IP-Teilnetz (LIS)-VCs (Host zu Router oder Router zu Router) werden unter Verwendung von ATM-Signalisieren aufgebaut. Solche VCs können Punkt-zu-Punkt für Unicast oder Punkt-zu-Multipunkt für Multicast sein. Unterschiedliche VCs können für unterschiedliche „Ströme" zwischen dem gleichen Satz von Endpunkten aufgebaut werden, um einen unterschiedlichen QoS für jeden Strom, z.B. unter Verwendung von RSVP, zu ermöglichen. Das Problem besteht dann, dass CSRs auf IP basierende Protokolle verwenden, um einen Datenverkehr zu routen und somit den Gebrauch von ATM-Protokollen auf Intra-LIS-Routing begrenzen. Einige der Nachteile dieses Ansatzes sind:
    • (1) Ein wirklicher Abkürzungsweg zwischen zwei Endpunkten kann nicht durch einen Router (CSR) verlaufen, der als der nächste Sprung (Hop) durch IP-Routing gegeben ist. Dieses liegt daran, dass IP-Routing benötigt alle Daten, die Teilnetzgrenzen kreuzen, durch einen Router (CSR) senden muss;
    • (2) Fernbereichsadressierungs- und Routing-Fähigkeiten von ATM werden durch diesen Ansatz nicht geeignet verwendet, da ATM nur als Verbindungsschicht benutzt wird; und
    • (3) Zur Zeit gibt es keinen Vorschlag dafür, heterogene QoS-Empfänger in einer Multicast-Sitzung mit CSRs zu handhaben.
  • Zwei andere neue Vorschläge, die sich mit IP-Schaltung beschäftigen, sind IPSILON und IPSOFACTO. Siehe A. Acharya, et al. „IP switching over fast ATM cell transport (IPSOFACTO), Proc. of IEEE Globecom '97, 1997; und P. Newman, et al., „Transmission of Flow Labeled Ipv4 on ATM Data Links Ipsilon Version 1.0", Network Working Group, Request For Comments 1954, Kategorie: Informational, Mai 1996. IP-Schaltung „kennzeichnet" langlebige IP-Ströme, die durch einen Schalter-Server verlaufen (IP-Schalter) und platziert solche Ströme auf einen schnellen geschalteten Pfad, so dass folgende Datenpakete auf diesen Strömen keine Wiederversammlung, Routing- und Segmentationsverzögerung an dem Server verursachen. IPSILON verwendet ein heuristisches basierend auf der Zahl Paketen mit den gleichen Quell- und Zieladressen, um einen langlebigen Strom zu identifizieren. IPSOFACTO beruht auf den Steuerpaketen von Protokollen höherer Schichten, z.B. SYN-Pakete in TCP, um langlebige Ströme zu identifizieren. Wenn einmal ein langlebiger Strom identifiziert worden ist, wird er einem neuen Virtual Circuit Indicator/Virtual Path Indicator (VCI/VPI) durch den IP-Schalter zugewiesen. Gleichzeitig wird eine Verbindung zwischen dem ankommenden VCI/VPI und abgehendem VCI/VPI in dem Schaltungsnetz aufgebaut, so dass folgende Datenpakete ohne irgendeine Intervention durch die Routing-Software weitergeleitet werden. IPSILON beruht auf einem proprietären Protokoll für das Zuweisen von VCI/VPI an IP-Ströme zwischen zwei IP-Schaltern. IPSOFACTO verwendet eine Technik, die auf dem Partitionieren des VCI/VPI-Raumes basiert, und wählt einen unbenutzte VCI/VPI von diesem Raum für das Weiterleiten eines Stroms durch jeden IP-Schalter. Der einzige Unterschied zwischen den zwei IP-Schaltungstechniken und der CSR-Technik, die zuvor beschrieben worden ist, ist die Weise, in der Abkürzungs-VCs durch den Schalter/den Router aufgebaut werden. Abgesehen von diesem Unterschied beruhen die zwei IP-Schaltungstechniken und CSR auf IP-Routing-Software, um Routing-Entschei dungen zu treffen. Als solche treffen alle Schwächen, die zuvor für CSR angeführt worden sind, gleichermaßen auf die zwei IP-Schaltungstechniken zu.
  • Zusätzlich hat die IP Over Non Broadcast Multiple Access (NBMA) Networks (ION)-Arbeitsgruppe des IETF einen Vorschlag für IP-Multicast über ATM entwickelt, das auf Multicast Address Resolution Servers (MARSs) basiert. Siehe G. J. Armitage, Support for Multicast over UNI 3.0/3.1 based ATM Networks, Network Working Group, Kategorie: Standards Track, Request For Comments 2022, November 1996 wie auch „IP-Multicasting over ATM Networks", IEEE Inc. New York, US, Bd. 15, Nr. 3, 1. Apryl 1997, Seiten 445-457. Eine Verbesserung des grundlegenden MARS-Ansatzes ist das Konzept eines Multicast-Servers (MCS). Siehe R. Talpade, et al., Multicast-Server architectures for MARS-based ATM Multicasting, Network Working Group, Kategorie: Informational, Request for Comments 2149, Mai 1997, welches hilft, den Verkehr von mehreren Sendern zu einer gegebenen Multicast-Gruppe zu aggregieren. Wenn ein aktiver MARS pro LIS in einer ATM-Wolke benutzt wird, werden Punkt-zu-Multipunkt-VCs für eine Multicast-Verteilung auf LIS-Grenzen begrenzt, und es wird eine Inter-LIS-Multicast-Vermittlung durch Multicast-Server gebildet. Abkürzungs-Routing des Multicast-Verkehrs ist in einem solchen Fall nicht möglich. Auf der anderen Seite können, wenn ein MARS für die vollständige ATM-Wolke benutzt wird, Punkt-zu-Multipunkt-VCs die vollständige ATM-Wolke überspannen, wodurch Skalierungsprobleme verursacht werden, wenn die Zahl der ATM-Hosts in der ATM-Wolke groß ist. Siehe G. J. Armitage, VENUS-Very Extensive Non-Unicast Service, Internet Engineering Task Force, Network Working Group, Request For Comments: 2191, Kategorie: Informational, September 1997. Im Vergleich dazu ist die erfinderische Netzwerkarchitektur, die ausführlicher unten besprochen wird, skalierbar, da sie unterschiedliche VCs für Intra- und Zwischen-LIS-Multicast-Verkehr verwendet, während sie Abkürzungs-Routing durch Verknüpfen dieser VCs an Multicast-Schaltern (MSWs) ermöglicht. Ein anderes Problem mit dem MARS/MCS-Ansatz ist die Unfähigkeit der Multicast-Sender, QoS-Anforderungen zu dem MCS für den Multicast-Verkehr zu kommunizieren, der von dem Sender stammt. In der vorliegenden Erfindung jedoch erlaubt, da der MSW der Endpunkt für RSVP-Nachrichten innerhalb eines LIS ist, die Verwendung von diesem als ein MCS den Gebrauch von QoS-VCs von dem Sender zu dem MSW/MCS.
  • In noch einem Weiteren Vorschlag behandelt die Integrated Service Over Specific Link Layers (ISSLL)-Arbeitsgruppe des IETF das Mapping der integrierten Services über ATM, wobei es als eine Verbindungsschicht-Technologie behandelt wird. Die gegenwärtigen Vorschläge in der ISSLL-Arbeitsgruppe für das Mapping von RSVP über ATM (siehe Crawley et al., A Framework for Integrated Services and RSVP over ATM, Internet-Engineering-Task Force, Internet-Entwurf, <draft-ietf-issll-atm-framework-00.txt>, 24. Juli 1997; und Berger, RSVP over ATM Implementation Requirements, Internet-Entwurf, <draft-ietf-issll-atm-imp-req-00.txt>, 11. Juli 1997), empfehlen das Unterstützen eines geänderten homogenen Modells als eine Annäherung an eine volle Empfängerheterogenität. In dem vorgeschlagenen Entwurf werden alle QoS-Empfänger durch eine einzelne QoS-VC bedient, und Best-Effort-Empfänger werden durch eine unterschiedliche Best-Effort-VC bedient, wenn sie nicht durch die QoS-VC bedient werden können. Die ISSLL-Vorschläge enthalten keine klare Diskussion über Multicasting über LIS (d.h. Inter-LIS-Multicasting). Obgleich es das Bestehen von einem MARS und auch von irgendeinem Abkürzungs-Routing erlaubt, ist es nicht klar, ob eine einzelne Punkt-zu-Multipunkt-VC pro Sender (oder MCS) die ATM-Wolke, die Sender direkt mit Empfängern verbindet, überspannt, oder ob IP-Server aufgerufen werden, um Multicast-Verkehr zwischen LIS zu routen. Ein Teil der Konfusion stammt von der Tatsache her, dass die ISSLL-Gruppe durch Definition darauf begrenzt wird, ATM als Verbindungsschicht-Technologie zu behandeln, obgleich ATM verwendet werden kann, um ebenso eine Routingfunktionen durchzuführen. Abkürzungsrouten, das es Multicast-Verkehr erlaubt, Multicast-Router zu überbrücken und einen ausgedehnteren Überblick erfordert, fällt offenbar außerhalb des Geltungsbereichs der ISSLL-Arbeitsgruppe.
  • Ein anderer neuer Vorschlag in der ISSLL-Gruppe verwendet ein Next Hop Resolution Protocol (NHRP), um Abkürzungswege mit QoS zwischen zwei Hosts/Servern aufzubauen, die an ein ATM-Netz angeschlossen sind. Siehe Guerin et al., Support of Shortcuts for RSVP Flows Over ATM, Internet Engineering Task Force, Internet-Entwurf <draft-guerin-issll-rsvp-shortcut-00.tx>. Sie auch, Luciani et al., NBMA Next Hop Resolution Protocol (NHRP), Routing Over Large Clouds Working Group, Internet-Entwurf <draft-ietf-rolc-nhrp-12.txt>. Obgleich dieser Vorschlag einen Abkürzungsweg zwischen den zwei Endpunkten unter Verwendung von signalisierendem ATM aufbaut, handhabt er nicht den Multicast-Fall, da NHRP Multicast-IP-Adressen nicht zu ATM-Adressen auflösen kann.
  • Ein anderer Vorschlag diskutiert unterschiedliche Alternativen für das Herstellen der RSVP-Reservierungen für Unicast- und Multicast-Ströme. Verschiedene Methoden werden beschrieben, um sowohl Root-initiierte (Wurzel (Root) des Multicast-Baums) und Blatt-initiierte (ein Blatt könnte ein Multicast-Empfänger oder ein Egress-Router sein) Abkürzungswege durch ein ATM-Netz zu erzielen. Birman, et al. „Provisioning of RSVP based Services over a lange ATM-Network", IBM Forschungsreport (Informatik) #RC 20250, Oktober 1995. Jedoch erfordern alle die Methoden, die für das Herstellen der Abkürzungswege durch das ATM-Netz beschrieben werden, Modifikationen der RSVP-Verarbeitung an den Routern. Des Weiteren skalieren direkte Abkürzungen von Sendern oder Ingress-Routern zu Empfängern oder Egress-Routern nicht, wenn die Zahl der Multicast-Empfänger groß ist. Die vorher erwähnten Methoden werden in einer sehr allgemeinen Form beschrieben, und es werden keine konkreten Implementierungsdetails erwähnt. Zusätzlich gibt es keine Erwähnung dazu, wie heterogene Empfänger unterstützt werden können. Im Gegensatz dazu implementiert die vorliegende Erfindung, die unten mit Bezug auf eine bevorzugte Ausführungsform beschrieben wir, eine skalierbare Netzwerkarchitektur basierend auf Multicast-Schaltern, die Abkürzungswege zur Verfügung stellt, die inkrementierend für Skalierbarkeit aufgebaut und verknüpft werden. Eine Unterstützung ist auch für heterogene Empfänger gegeben. Keine Modifikationen werden bei der RSVP-Verarbeitung benötigt. Die Aspekte, die auf ATM- und Abkürzungs-Routing bezogen sind, werden nur innerhalb des Multicast-Routings gehandhabt.
  • Ein anderer neuer Vorschlag beschreibt das Design und die Implementierung eines Schalter-Routers, der in der Lage ist einen Quality of Service unter Verwendung von RSVP zur Verfügung zu stellen. E. Basturk et al., Design und Implementation of QoS capable Switch Router, Proceedings of the International Conference on Computer Communications and Networks (IC3N), Sept. 1997. Es werden ein Design und eine Implementierung der Hardware in dem Schalter-Router ausführlich dargestellt. Der Schalter-Router, der beschrieben wird, kann als ein VSR von Toshiba gedacht werden (wie zuvor beschrieben), der um QoS-Fähigkeiten unter Verwendung von RSVP bereichert ist. Der vorgeschlagene Schalter-Router verwendet IP-Routingprotokolle und RSVP, um Unicast- und Multicast-geschaltete Wege in einem ATM-Netz zur Verfügung aufzubauen. Das ATM-Netz wird, wie in Toshibas CSR, als ein Schicht 2-Netzwerk behandelt, so dass ein Vermitteln über Teilnetzgrenzen über einen Router (Schalter-Router in diesem Fall) stattfindet. Jedoch wird die Schalter-Router-Architektur isoliert ohne irgendeine Erwähnung davon beschrieben, wie solche Schalter-Router zusammenarbeiten, um ein skalierbares Mapping von IP-Multicast und RSVP über in der Größe ein stellbare ATM-Netze mit Eigenschaften wie einer Empfängerheterogenität zur Verfügung zu stellen. Folglich treffen die meisten Beschränkungen, die aus dem Gebrauch von auf IP basierenden Protokollen in ATM-Netzwerken, wie zuvor in der Diskussion von Toshibas CSR beschrieben worden ist, auch auf diesen Schalter-Router zu. Insbesondere werden die Punkte, die sich auf das VC-Management für ein ATM-Netzwerk beziehen, das aus einer Anzahl von LIS besteht und die Adressier- und Routingfähigkeiten von ATM verwendet, in diesem Beitrag nicht angesprochen. Des Weiteren sind Erweiterungen der RSVP-Nachrichten erforderlich, um VC-Informationen von einem Schalter-Router zu dem anderen zu übertragen.
  • Im Gegensatz dazu beschreibt die vorliegende Erfindung eine skalierbare Netzwerkarchitektur, die auf Multicast-Schaltern basiert, die Merkmale wie Abkürzungswege und Empfängerheterogenität unterstützt. Details werden unten zur Verfügung gestellt, um zu zeigen, wie Multicast-Schalter zusammen arbeiten können, um IP-Multicast und integrierte Services in einem ATM-Netz zur Verfügung zu stellen, wobei das Routing und die Adressierungsmöglichkeiten von ATM so weit wie möglich ausgenutzt werden. Des Weiteren sind in der erfinderischen Architektur keine Modifikationen der RSVP-Nachrichten nötig.
  • Zusammenfassung der Erfindung:
  • Die vorliegende Erfindung stellt eine Lösung für das Problem des Unterstützens von IP-Multicast und von integrierten Services über ATM zur Verfügung. Die Erfindung legt ein Verfahren und eine Netzwerkarchitektur dar, die auf Multicast-Schaltern für das Mapping von IP-Multicast und von integrierten Services über ATM-Netzwerken basieren. Ein Multicast-Schalter (MSW) ist ein ATM-Schalter, der ebenso die Funktionen eines IP-Multicast-Routers, einschließlich der des Beendens der RSVP-Nachrichten, durchführen kann. Das primäre Problem, das durch die vorliegende Erfindung angegangen wird, ist das des Mappings der Protokollmechanismen (IP-Multicasting-Protokolle und RSVP), die IP-Multicast und integrierte Services an geeignete Mechanismen liefern, die von ATM-Netzen bereitgestellt werden.
  • Die vorliegende Erfindung stellt, indem sie eine Lösung für das Mapping von IP-Multicast und von integrierten Services über ATM zur Verfügung stellt, auch ein Mittel für das Angehen der folgenden Zielsetzungen zur Verfügung.
  • Die erste Zielsetzung ist es, eine Empfängerheterogenität zuzulassen. RSVP erlaubt es unterschiedlichen Empfängern in einer Multicast-Sitzung Ressourcen mit unterschiedlichen QoS-Parametern zu reservieren. Es ist auch möglich, dass einige Empfänger keine Ressourcen reservieren, sondern es stattdessen vorziehen, Daten mit einem Best-Effort-Mechanismus zu empfangen. All diese Empfänger müssen durch ein RSVP über ATM-Mapping unterstützt werden. Da eine Punkt-zu-Multipunkt-VC in ATM keine unterschiedlichen QoS-Parameter haben kann, die mit ihren unterschiedlichen Zweigen assoziiert sind, kann das Unterstützen der Empfängerheterogenität mehrere VCs mit unterschiedlichen QoS-Parametern erfordern.
  • Die zweite Zielsetzung ist es, ein Abkürzungs-Routing zur Verfügung zu stellen. Abkürzungs-Routing für Unicast-Verkehr in einer ATM-Wolke hilft dabei, Zwischenroutingschritte zu eliminieren, indem die Routing- und Adressierungsmöglichkeiten von ATM verwendet werden, für den Fall, dass zwei in Verbindung stehende Hosts an das gleiche ATM-Netz angeschlossen werden. Durch Verwendung eines Mechanismus wie NHRP kann ein Sender die ATM-Adresse des empfangenden Hosts herausfinden und eine direkte VC zu ihm herstellen. Das Erweitern von Abkürzungs-Routing auf Multicast-Daten-Verkehr verursacht jedoch eine Vielzahl von Problemen. Als erstes wird das Verwenden einer Abkürzungs-Punkt-zu-Multipunkt-VC für eine Multicast-Sitzung in einer ATM-Wolke den Sender mit dem Verwalten einer VC belasten, die potentiell mehrere LIS überspannen und eine große Anzahl an Empfänger haben kann. Zweitens ermöglicht das Abkürzungs-Routing für Multicast dem Datenverkehr Multicast-Router zu umgehen. Das bedeutet, dass RSVP-Steuer-Nachrichten (PATH und RESV) einem Weg folgen können, der zu dem Datenweg unterschiedlich ist, wodurch Inkonsistenzen zwischen den Wegeigenschaften, die durch RSVP-Steuer-Nachrichten berechnet werden, und denen, die wirklich von den Daten angetroffen werden, verursacht werden. Ein Mapping muss daher die Art der Unterstützung für eine Abkürzungs-Routing für Multicast-Verkehr klar spezifizieren.
  • Die dritte Zielsetzung besteht darin, ein adäquates VC-Management zur Verfügung zu stellen. Ein Mapping sollte spezifizieren, wie VCs für einen Multicast-Daten-Verkehr und einen RSVP-Steuerverkehr aufgebaut werden. Dieses bezieht die Identifizierung der Endpunkte mit ein, in denen eine Daten- oder Steuerungs-VC endet. Dieses schließt auch die Delegation der VC-Managment-Aufgaben zu Sendern und/oder Routern ein, um Änderungen in der Gruppenmitgliedschaft zu handhaben. Wenn ein Mapping direkte Punkt-zu-Multipunkt-VCs zwischen einem Sender und allen Empfängern in einer ATM-Wolke unterstützt, muss der Sender die VC-Endpunkte verwalten. Wenn neue Empfänger der Multicast-Sitzung beitreten, müssen sie als Blattknoten der Punkt-zu-Multipunkt-VC hinzugefügt werden. Auf der anderen Seite müssen, wenn vorhandene Empfänger die Multicast-Sitzung verlassen, diese von der Punkt-zu-Multipunkt-VC entfernt werden.
  • Die vierte Zielsetzung besteht darin, einen dynamischen QoS zu ermöglichen. RSVP ermöglicht es Multicast-Empfängern, ihre Ressourcenreservierungen zu jeder Zeit zu ändern. Zur Zeit erlauben es User Network Interface (UNI)- und Private Network Noder Interface (PNNI)-Standards des ATM-Forums nicht QoS-Parameter für eine bestehende VC zu ändern.
  • Eine fünfte Zielsetzung besteht darin, eine Skalierbarkeit zur Verfügung zu stellen. Ein Mapping sollte zu einer großen Anzahl von Empfängern und zudem möglicherweise zu einer beträchtlichen Anzahl von Sendern skalierbar sein. Wie oben bemerkt skalieren direkte Punkt-zu-Multipunkt-VCs von einem Sender zu allen Multicast-Empfängern innerhalb einer ATM-Wolke nicht.
  • Eine sechste Zielsetzung besteht darin, einen effektiven Gebrauch von den ATM-Fähigkeiten zu machen. Ein Mapping von IP-Multicast und RSVP über ATM sollte von ATM-Fähigkeiten so viel wie möglich Gebrauch machen, auch wenn irgendeine Form der IP-Routing-Unterstützung erforderlich ist. Eine Lösung, die lediglich auf IP-Multicast-Routern basiert, ist folglich offenbar nicht wünschenswert.
  • Eine siebte Zielsetzung ist es, eine Interoperabilität zur Verfügung zu stellen. Ein Mapping sollte Interoperabilität mit Inter Domain Multicast Routing (IDMR)-Protokollen sicherstellen, die außerhalb der ATM-Wolke in Gebrauch sein können. Wenn das Protokoll, das für Multicasting innerhalb der ATM-Wolke verwendet wird, zu dem unterschiedlich ist, das außerhalb der Wolke verwendet wird, sollten Rand-Multicast-Schalter die Zusammenarbeit zwischen den zwei erleichtern. Zudem sollte eine Unterstützung für native ATM-Anwendungen zur Verfügung gestellt werden, da es sehr wahrscheinlich ist, dass die Host-Endsysteme, die an einem ATM-Netz angeschlossen sind, zusätzlich zu einer RSVP/IP-Schnittstelle ebenso einen nativen ATM-Zugang benötigen.
  • Kurze Beschreibung der Zeichnung:
  • 1 zeigt ein Netzwerk, das aus ATM-Schaltern und Hosts besteht, das als eine ATM-Wolke bekannt ist;
  • 2 zeigt eine Netzwerkarchitektur für das Mapping von IP-Multicast und von integrierten Services über ATM in Übereinstimmung mit der vorliegenden Erfindung;
  • 3 zeigt eine funktionelle Architektur eines Multicast-Schalters (MSW) in Übereinstimmung mit der vorliegenden Erfindung;
  • 4 zeigt Intra- und Inter-LIS-Steuerungs-VCs;
  • 5 zeigt Daten-VCs für Multicasting innerhalb eines LIS;
  • 6 zeigt Stufe I eines Beispiels für RSVP über ATM;
  • 7 zeigt Stufe II eines Beispiels für RSVP über ATM;
  • 8 zeigt Stufe III eines Beispiels für RSVP über ATM;
  • 9 ist ein Flussdiagramm für das Beschreiben der grundlegenden Prozeduren des Mapping-Verfahrens entsprechend der vorliegenden Erfindung;
  • 10 ist ein Flussdiagramm für das Beschreiben des Schrittes SA4 in 9;
  • 11 ist ein Flussdiagramm für das Beschreiben des Schrittes SA5 in 9; und
  • 12 ist ein Flussdiagramm für das Beschreiben zusätzlicher Prozeduren von dem Mapping-Verfahren in 9.
  • Ausführliche Beschreibung der bevorzugten Ausführungsformen
  • Um die Prinzipien zu verstehen, die der vorliegenden Erfindungen zugrunde liegen, ist es notwendig, das Problem des Mappings von IP-Multicast und von integrierten Services über ATM klar zu definieren. Es ist nützlich, zuerst ein Netzwerk zu betrachten, das aus ATM-Schaltern und Hosts besteht, das als eine ATM-Wolke bekannt ist, in der ein solches Mapping gewünscht wird. Ein beispielhaftes Netzwerk wird in 1 gezeigt. Alle Hosts und Schalter in der ATM-Wolke 1 brauchen nicht als IP-Hosts oder Router konfiguriert zu sein. Für die Zwecke dieser Diskussion kann es angenommen werden, dass einige Host-Maschinen als IP-Hosts 2 konfiguriert sind und einige Schalter 3 Routing-Services zu diesen IP-Hosts zur Verfügung stellen, so dass sie mit anderen Hosts sowohl innerhalb als auch außerhalb der ATM-Wolke kommunizieren können. Gekennzeichnete ATM-Schalter an dem Rand dieser ATM-Wolke können an Nicht-ATM-Technologien, wie dem Ethernet, angeschlossen sein, und sie sind als Randschalter 4 bekannt. IP-Hosts 2A und IP-Router 3A stellen Bestandteile der externen IP-Netze dar, mit denen die ATM-Wolke unter Verwendung der Randschalter 4 zusammengeschaltet ist. Von Randschalter wird es gefordert, dass sie IP-Routingfähigkeiten haben, um die ATM-Wolke mit anderen Netzen zu verbinden. Innerhalb der ATM-Wolke kann es angenommen werden, dass IP-Hosts in logische IP-Teilnetze (LIS) 5 zu administrativen und adressierenden Zwecken partitioniert sind. Das ATM Address Resolution Protocol (ARP) wird verwendet, um IP-Adressen zu ATM-Adressen innerhalb eines LIS aufzulösen. Siehe Laubach et al., Classical IP and ARP over ATM, Network Working Group, Internet Draft, Obsoletes 1577, 1622, <draftion-ipatm, classic2-03.txt> 6. Oktober 1997. Unicast-Routing zu anderen IP-Teilnetzen kann von einem IP-Router (vielleicht einem IP-Schalter, der eine IP-Routing-Software laufen läßt) zur Verfügung gestellt werden und/oder durch den Gebrauch von einem Next Hop Resolution Protokoll (NHRP). Siehe J.V. Luciani, et al., NBMA Next Hop Resolution Protocol (NHRP), Internet Engineering Task Force, ION Working Goup, Internet Draft, März 1997.
  • Das Problem des Mappings von IP-Multicast und von integrierten Services über ATM besteht darin, adäquat und effizient Services und Anwendungen, die auf IP-Multicast und RSVP basieren, über eine ATM-Wolke zu unterstützen. In der folgenden Diskussion werden zunächst die Mechanismen, die in den ATM-Standards dazu zur Verfügung gestellt werden, IP-Multicasting und integrierte Services zu unterstützen, umrissen. Als nächstes werden einige Punkte, die durch das erfinderische Mapping von IP-Multicast und RSVP über ATM angegangen werden, angeführt.
  • Multicasting in ATM
  • Das ATM-Forum, das die standardisierende Körperschaft für auf ATM bezogene Protokolle ist, hat in seinen neuen Spezifikationen der User Network Interface (UNI) mehr Multicasting-Bestimmungen aufgenommen. Siehe ATM User Network Interface (UNI) signaling specification Version 4.0, The ATM Forum Technical Committe, Juli 1996. In der früheren Version (3.x) von UNI wurde Multicasting durch virtuelle Punkt-zu-Multipunkt-Schaltungen (VCs) gestützt. Jede solche VC ist in einem ATM-Knoten (Multicast-Sender) verwurzelt (rooted), und es kann jede mögliche Zahl von Blattknoten (Multicast-Empfängern) hinzugefügt werden, nachdem die VC aufgebaut worden ist. In UNI 4.0 ist es vorgesehen, dass Blatt-initiierte Verbindungen Punkt-zu-Multipunkt-VCs hinzugefügt wurden, wodurch die Intervention von dem Wurzelknoten nicht mehr notwendig ist, wenn Blattknoten einer vorhandenen Punkt-zu-Multipunkt-VC hinzugefügt werden müssen.
  • Punkt-zu-Multipunkt-VCs werden in den gegenwärtigen Signalisierungsspezifikationen (Version 1.0) für private Private Network Node Interface (PNNI) unterstützt. Siehe Private Network Node Interface Specification Version 1.0 (PNNI 1.0), The ATM Forum Technical Committe, März 1996. Es wird erwartet, dass die folgende Version von PNNI ebenso Blatt-initiierte Verbindungen unterstützt. Weder UNI 4.0 noch PNNI 1.0 unterstützt das Ändern der QoS-Parameter für eine Punkt-zu-Multipunkt-VC, die bereits aufgebaut worden ist. UNI 4.0 unterstützt auch noch nicht unterschiedliche QoS-Parameterwerte für unterschiedliche Zweige in einer einzelnen Punkt-zu-Multipunkt-VC. Diese Beschränkungen machen es schwierig, auf RSVP gegründeter Multicast zu ATM-Punkt-zu-Multipunkt-VCs zu mappen, da es RSVP-Spezifikationen einzelnen Empfänger in der selben Multicast-Sitzung ermöglichen, ihre eigenen QoS-Parameter zu wählen (d.h. eine Empfängerheterogenität zur Verfügung zu stellen) und sie nachher beliebig zu ändern (dynamischer QoS).
  • Netzwerkarchitektur
  • Im Allgemeinen weist die erfinderische Netzwerkarchitektur für das Mapping von IP-Multicast und von integrierten Services über ATM die folgenden Merkmal auf: (1) Sie ist sowohl für Best-Effort als auch QoS-Verkehr geeignet; (2) Sie unterstützt Intra- und Inter-LIS-Multicasting; (3) Sie unterstützt Abkürzungs-Routing und Empfängerhete rogenität; und (4) Sie ist für eine große Zahl an Sendern und Empfängern skalierbar.
  • Die erfinderische Netzwerkarchitektur basiert auf einer Einheit, die ein Multicast-Schalter (MSW) genannt wird und die als ein ATM-Schalter mit IP-Multicast-Routingfähigkeiten gedacht werden kann. Die Idee ist es, ein MSW pro LIS zu haben, was dem doppelten Zweck des Aggregierens von äußeren Sendern für lokale Empfänger und des Aggregierens von äußeren Empfängern für lokale Sender dient. In diesem Sinne ist ein MSW einem Multicast-Router ähnlich, aber er hat zusätzliche Eigenschaften, die ihn zu einer attraktiveren Option für das Unterstützen von Inter-LIS-Multicast machen. Zunächst ist, anders als Multicast-Router, die sich an den LIS-Grenzen (d.h. zwischen LIS) befinden, ein MSW ein Teil von genau einem LIS. Das Strukturieren von MSW und LIS in dieser Weise ist mehr in Übereinstimmung mit der Weise, in der ATM-Netze organisiert werden, in denen ein Bündel von Endsystemen (Hosts) an einen ATM-Schalter mit einem User Network Interface (UNI) angeschlossen sind. Zweitens ist ein MSW zum Herstellen von direkten VCs zu anderen MSWs in der ATM-Wolke unter Verwendung von ATM-Signalisieren in der Lage und stellt so ein Abkürzungs-Routing für einen Inter-LIS-Multicast-Verkehr zur Verfügung. Drittens kann ein MSW eine Empfängerheterogenität innerhalb eines LIS unterstützen, das auf der lokalen Politik und der Verwendbarkeit von Ressourcen basiert. Die folgende Diskussion beschreibt zuerst die gesamte Netzwerkarchitektur und die Funktionalität eines Multicast-Schalters. Danach wird der Protokollbetrieb von IP-Multicast und RSVP in der erfinderischen Netzwerkarchitektur beschrieben.
  • Wie oben angeführt, wird die erfinderische Netzwerkarchitektur durch einen Multicast-Schalter (MSW) pro LIS in einer ATM-Wolke gebildet. Ein MSW ist ein ATM-Schalter, der auch eine Multicast-Routing-Software zusätzlich zu dem Unterstützen von PNNI und von UNI laufen lässt. Jeder MSW aggregiert Multicast-Empfänger in seinem LIS für die Außenwelt. Ein MSW dient auch als Multicast-Server (MCS) für sein LIS. Ein Multicast-Server in einem ATM-Netz erlaubt die Aggregation des Verkehrs von mehreren Sendern, der auf einer einzelnen VC zu den Empfängern ausgesendet werden kann. Ein MSW ist auch zur Verarbeitung von RSVP-Steuernachrichten in der Lage und zu dem Durchführen der Call-Admission-Steuerung (CAC) für RSVP-Ströme. Auf den Rändern der ATM-Wolke helfen Grenz- oder Rand-MSWs dabei, Multicast-Empfänger innerhalb der ATM-Wolke für äußere Sender und umgekehrt zu aggregieren. Eine beispielhafte Netzwerkarchitektur wird in 2 gezeigt. Die Figur zeigt eine ATM-Wolke 1, die aus drei LIS besteht (6, 7, 8). LIS 6 und LIS 8 haben je einen einzelnen ATM-Schalter, der auch als der MSW 9 für sein LIS bezeichnet wird. LIS 7 hat zwei ATM-Schalter, von denen einer als der MSW 9 bezeichnet wird, während der andere ATM-Schalter 3 an dem IP-Multicasting oder dem RSVP-Betrieb nicht teilnimmt.
  • Es wird angenommen, dass jeder Multicast-Schalter (MSW) 9 mit allen anderen MSWs in der ATM-Wolke unter Verwendung von einer Punkt-zu-Multipunkt-VC kommunizieren kann. Solche VCs unter MSWs können unter Verwendung von UNI-Signalisieren aufgebaut werden. Wenn die ATM-Wolke zu groß ist, wodurch Punkt-zu-Multipunkt-VCs unter MSWs unpraktisch werden, kann eine Hierarchie von MSWs ähnlich der PNNI-Hierarchie (Siehe Private network network interface specification version 1.0 (PNNI 1.0), The ATM Forum Technical Committe, März 1996) erforderlich sein, um die gesamte Wolke abzudecken. In einem solchen Fall wird eine Gruppe von MSWs einen Gruppenführer unter sich wählen, um sie in der folgenden Gruppe höheren Niveuas zu repräsentieren. Ein Multicast-Routing-Schema wird, obwohl nur für Best-Effort-Multicast, unter Verwendung einer PNNI-Hierarchie in R. Venkatswaran et al., Hierarchical multicast routing in wide-area ATM networks, Proc. Of the Intl. Communikations Conf. (ICC '96), Juni 1996, beschrieben.
  • Multicast-Schalter (MSW)
  • 3 zeigt die Architektur eines Multicast-Schalters (MSW) 9. Der MSW wird durch eine Schalterhardware und eine Schaltersteuerung 10 gebildet, die VC-Übersetzungstabellen für eine Zellenvermittlung aufbauen können. Verschiedene andere Bestandteile, die in der Figur gezeigt werden, werden wie folgt beschrieben. Der RSVP-Nachrichten-Handler 11 beendet RSVP-Nachrichten von anderem MSWs in der ATM-Wolke, lokalen ATM-Hosts und externen IP-Routern. Der Message-Handler führt auch den RSVP-Protokoll-beibehaltenden Soft State für jeden RSVP-Strom aus, der den Schalter passiert. Wenn Ressourcenreservierungen für einen neuen Strom von dem RSVP-Handler empfangen werden, befragt der RSVP-Nachrichten-Handler die Call Admission Control (CAC)-Funktion 12, um zu entscheiden, ob genügende Ressourcen für den neuen Strom reserviert werden können. Wenn es so ist, fragt der RSVP-Nachrichten-Handler die VC-Managment-Funktion 13 an, eine geeignete Handlung zu unternehmen, um Intra- und Inter-LIS-VCs für den neuen Strom aufzubauen. Die VC-Management-Funktion macht Gebrauch von der UNI-Signalisierungs-Funktion 13a, um Intra- und Inter-LIS-VCs aufzubauen. UNI-Signalisieren wird sogar für Inter-LIS-VCs unter MSWs verwendet, da diese VCs durch die MSWs beendet werden. Die VC-Management-Funktion macht ebenso von einer VC-Verknüpfungsfunktion 13b Gebrauch, die zwei bestehende VCs, die zur Zeit durch den MSW beendet werden, zu einem VC verknüpfen kann. VC-Management wird später im Detail besprochen.
  • Der Multicast-Routingbestandteil 14 des Multicast-Schalters besteht aus drei Teilen. Der erste Teil 14a ist für das Beibehalten der Gruppenmitgliedschaftinformationen für das LIS verantwortlich. Solche Informationen können durch den lokalen Multicast-Adressauflösungs-Server (MARS) geliefert werden. Siehe G. J. Armitage, Support for Multicast over UNI 3.0/3.1 based ATM Networks, Request For Comments 2022, November 1996. Der zweite Teil 14b ist für die Kommunikation mit seinen Peer-Funktionen verantwortlich, die auf anderen MSWs in der ATM-Wolke laufen. Dieser Teil tauscht zusammengefasste lokale Mitgliedschaftinformationen mit anderen MSWs aus. Diese Informationen werden von MSWs verwendet, um auf Best-Effort und QoS gegründete Multicast-Bäume unter MSWs aufzubauen, wie es später erklärt wird. Der dritte Teil 14c des Multicast-Routingbestandteils 14 stellt eine Inter Domain Multicast Routing (IDMR) Protocol-Schnittstelle zu den IP-Routern zur Verfügung, die außerhalb der ATM-Wolke gelegen sind. Diese Schnittstelle besteht aus einem Multicast-Routing-Code für jedes IDMR-Protokoll, das unterstützt wird, und wechselwirkt mit externen Routern, wobei sie ihnen Multicast-Routing- und Mitgliedschaft-Informationen über die ATM-Wolke schickt und von ihnen ähnliche Informationen über externe Netze erhält. Die IDMR-Schnittstelle wird nur auf Rand-MSWs 4 benötigt, die in 2 gezeigt sind, da interne MSWs 9 nicht direkt mit äußeren Routern kommunizieren.
  • Die Schritte, die in dem Netzwerk durchgeführt werden, die das Mapping von IP-Multicast und von integrierten Services über ATM-Netze ermöglichen, werden im Weiteren beschrieben.
  • 1. Steuerungs-VCs für RSVP-Nachrichten
  • Auf 4 Bezug nehmend bilden alle MSWs in einer ATM-Wolke 1 (oder einer PNNI-Domain) zuerst ein Netz von Punkt-zu-Multipunkt-Steuerungs-VCs 15 unter sich selbst aus – wobei eine solche VC an jedem MSW 9 mit allen Weiteren MSWs als ihren Blättern verwurzelt ist. 4 zeigt eine VC, die an MSW2 verwurzelt ist, mit MSW1 und MSW3 als ihren Blättern. Andere VCs (um der Einfachheit willen nicht gezeigt) werden an MSW1 bzw. an MSW3 verwurzelt. Diese Steuerungs-VCs werden durch die MSWs 9 verwendet, um Gruppenmitgliedschaftinformationen über ihr jeweiliges LIS zu anderen MSWs zu übermitteln. Rand-MSWs 4 übermitteln ebenso Gruppenmitgliedschaftinformationen, die sie von äußeren Netzwerken erhalten haben, zu anderen MSWs. Diese Informationen werden von jedem MSW 9 verwendet, um den Satz von MSWs festzustellen, der es benötigt, Multicast-Daten zu empfangen, die von jedem lokalen Sender für jede Multicast-Gruppe stammen. Die Steuerungs-VCs 15 werden auch von MSWs 9 verwendet, um PATH-Nachrichten weiter zu leiten, die von Sendern innerhalb ihrer LIS stammen.
  • RESV-Nachrichten, die von Multicast-Empfängern innerhalb eines LIS stammen und in Richtung zu einem Multicast-Sender verwiesen werden, werden in eine einzelne RESV-Nachricht durch den MSW in dem LIS aggregiert, das die Empfänger enthält, die dann zu dem MSW in dem LIS weitergeleitet wird, das den Sender enthält. Zusätzliche Punkt-zu-Punkt-Steuerungs-VCs können durch die MSWs zu diesem Zweck erzeugt werden, wie es erforderlich ist. Steuerungs-VCs (sowohl Punkt-zu-Punkt als auch Punkt-zu-Multipunkt) werden mit angemessenen QoS-Parametern erzeugt, die den Grad des Verkehrs reflektieren, der auf solchen VCs erwartet wird.
  • Eine Ausbreitung der Steuernachrichten von einem MSW zu den Multicast-Empfängern innerhalb seines LIS wird unter Verwendung einer unterschiedlichen Punkt-zu-Multipunkt-Steuerungs-VC 16 gehandhabt. Diese Intra-LIS-Steuerungs-VC 16 wird an dem MSW 9 verwurzelt, und jeder Multicast-Empfänger in dem LIS 6, 7, 8 wird der Steuerungs-VC 16 als ein Blattknoten hinzugefügt, wenn sie zuerst als ein Empfänger mit dem lokalen MARS für irgendeine Multicast-Gruppe registriert. Die Intra-LIS-Steuerungs-VC wird verwendet, um PATH-Nachrichten von lokalen und äußeren Sendern zu lokalen Empfänger zu verteilen. Für das Senden von RESV-Nachrichten zu dem MSW zurück verwenden Multicast-Empfänger einzelne Punkt-zu-Punkt-Steuerungs-VCs, wie es benötigt wird. 4 zeigt lokale Steuerungs-VCs 16 in jedem LIS 6, 7, 8 und ebenso die Inter-LIS-Steuerungs-VC 15, die an dem MSW2 9 in dem LIS 7 verwurzelt ist. Ähnlich werden Inter-LIS-Steuerungs-VCs, die an anderen MSWs verwurzelt sind, aus Gründen der Einfachheit nicht gezeigt, wobei das Konzept, das gerade beschrieben worden ist, gleichermaßen anwendbar ist.
  • 2. Multicasting innerhalb eines LIS
  • Bei der wie oben beschriebenen gegebenen Netzwerkarchitektur wird, sobald die Steuerungs-VCs aufgebaut worden sind, Multicast-Übermitteln innerhalb jedes LIS wie folgt durchgeführt. Ein Multicast Address Resolution Server (MARS) wird in jedem LIS eingesetzt, um eine IP-Multicast-Adresse zu ATM-Adressen der Empfänger aufzulösen, die der Gruppe beigetreten sind, die durch die Multicast-Adresse dargestellt wird.
  • Auf 5 Bezug nehmend, registrieren in einem einfachen Multicasting-Szenario innerhalb eines LIS 6A Empfänger 17, 18, die ATM-Hosts sind und die wünschen, einer Multicast-Gruppe beizutreten, zunächst mit dem lokalen MARS (nicht gezeigt) und liefern ihre ATM-Adressen und die Adresse der Multicast-Gruppe. Der MSW 9 registriert auch mit dem lokalen MARS als gemischten Empfänger und einen Multicast-Server (MCS) für alle IP-Multicast-Adressen. Ein Multicast-Sender 19 in dem LIS registriert als ein Sender mit dem lokalen MARS, der seine eigene ATM-Adresse und die IP-Multicast-Gruppen-Adresse gibt, zu der er Daten schicken möchte. Der MARS gibt die ATM-Adresse des MSW 9 als den einzigen Empfänger des Multicast zurück, da der MSW 9 auch der Multicast-Server für das LIS 6A ist. Der Sender 19 fährt dann fort, eine Best-Effort-Punkt-zu-Punkt-VC (nicht gezeigt) mit dem MSW 9 aufzubauen und beginnt damit, Multicast-Daten auf dieser VC zu senden. Der MSW 9 wiederum erhält die Liste von ATM-Hosts 17, 18 (Empfänger), die mit dem MARS als Mitgliedern der Multicast-Gruppe registriert haben, zu der der Sender Daten schickt und stellt Best-Effort-Punkt-zu-Multipunkt-Daten-VCs 20 zu jenen Hosts her. Die Multicast-Daten, die von dem Sender 19 empfangen werden, werden auf diese VCs 20 unter Verwendung von Abkürzungs-Routing weitergeleitet. Alle möglichen Änderungen in der Multicast-Gruppenmitgliedschaft werden dem MSW 9 durch den MARS mitgeteilt. Nach Empfangen dieser Änderungen fügt der MSW 9 Blattknoten der der Punkt-zu-Multipunkt-Best-Effort-Daten-VC 20 hinzu oder entfernt Blattknoten von dieser, wie es passend ist.
  • Der MSW leitet auch Datenpakete, die von dem Sender empfangen werden, zu anderen LIS weiter, wie es später erklärt wird. Um auf QoS basierenden Multicast in dem LIS unter Verwendung von RSVP zu ermöglichen, sendet der Sender 19 eine PATH-Nachricht zu dem MSW 9 auf einer separaten Steuerungs-VC (nicht gezeigt), welche durch den MSW 9 zu den lokalen Empfängern 17, 18 auf der Intra-LIS-Punkt-zu-Multipunkt-Steuerungs-VC (nicht gezeigt) weitergeleitet wird. In Reaktion darauf schicken lokale Empfänger 17, die auf QoS gegründetes Multicast wünschen, RESV-Nachrichten zu dem MSW 9 auf individuellen Steuer-VCs (nicht gezeigt), die ihren Ressourcenbedarf anzeigen. Eine aggregierte RESV-Nachricht, welche die RESV-Nachrichten von den lokalen Empfängern zusammenfasst, wird von dem MSW 9 zu dem Sender 19 geschickt. Der Sender baut sodann eine andere VC 21 zu dem MSW 9 mit den QoS-Parametern auf, die von der aggregierten RESV-Nachricht abgeleitet werden, und beginnt damit, Multicast-Daten auf der neuen VC 21 zu senden. Die alte Best-Effort-Daten-VC von dem Sender zu dem MSW 9 wird gelöscht. Der MSW 9 baut auch eine neue auf QoS gegründete Punkt-zu-Multipunkt-VC 22 zu den lokalen Empfängern 17 auf, die den QoS-Service angefordert hatten. Diese Empfänger werden von der Best-Effort-Daten-VC 20 fallengelassen, obgleich die Best-Efffort-VC 20 funktionsfähig belassen wird, um die Best-Effort-Empfänger 18 zu bedienen. Die von dem Sender ankommende QoS-VC 21 wird durch den MSW mit den zwei abgehenden Punkt-zu-Multipunkt-VCs 20, 22 (auf Best-Effort und QoS gegründet) verknüpft, um ein Abkürzungs-Weiterleiten von Daten innerhalb des LIS zu gewährleisten.
  • Das Verwenden des MSW als einen Multicast-Server (MCS) hat zwei Vorteile. Erstens werden Multicast-Sender von der Belastung des Verwaltens der VC-Endpunkte entlastet, welche sich wegen der Empfänger ändern, die zu der Multicast-Gruppe hinzukommen oder aus dieser herausfallen. Zweitens kann der MSW verschiedene Eigenschaften wie eine Empfängerheterogenität, Senderaggregation, Abkürzungs-Routing etc. auf der Grundlage der Verwendbarkeit von Ressourcen und der lokal konfigurierten Politik unterstützen.
  • 3. Multicasting über LIS-Grenzen
  • Genau wie ein IP-Multicast-Server aggregiert ein MSW-Empfänger innerhalb seines LIS für äußere Sender und äußere Empfänger für lokale Sender. Anders als Multicast-Router jedoch ermöglichen MSWs Abkürzungs-Multicast-Versenden innerhalb und zwischen LIS mit minimaler Routing-Unterstützung. Ein Inter-LIS-Multicast-Baum wird zuerst als Best-Effort-Punkt-zu-Multipunkt-VC, die an einem MSW verwurzelt ist, der einen lokalen Sender hat, gebildet, wobei andere MSWs, die lokale Empfänger haben, die Blattknoten bilden. Lokale VCs, die für eine Multicast-Verteilung innerhalb jedes LIS erzeugt werden, werden dann mit diesem Inter-LIS-Baum verknüpft, wodurch somit der komplette Multicast-Baum gebildet wird. Ein solcher Baum kann für jeden Sender gebildet werden, obgleich es ebenso möglich sein kann, Verkehr von mehreren Sendern auf einem einzelnen Baum zu aggregieren.
  • Um auf QoS gründeten Multicast zu initiieren, beginnt ein Sender damit, PATH-Nachrichten zu seinem lokalen MSW zu schicken. Diese PATH-Nachrichten werden über die Intra- und Inter-LIS-Steuerung-VCs durch den MSW des Senders weitergeleitet. Andere MSWs leiten nach dem Empfangen der PATH-Nachrichten von dem MSW des Senders diese auch innerhalb ihres jeweiligen LIS weiter. Nach Empfangen der PATH-Nachrichten können Empfänger ihren Ressourcenbedarf signalisieren, indem sie ihren jeweiligen MSWs RESV-Nachrichten schicken. Die MSWs kombinieren die Ressourcenreservierungsanforderungen von ihren lokalen Empfängern und senden eine aggregierte RESV-Nachricht zu dem MSW des Senders. Der MSW des Senders sammelt RESV-Anorderungen von anderen MSWs und von seinen lokalen Empfängern und leitet eine aggregierte Anforderung an den Sender weiter. Nach Empfangen einer RESV-Anforderung von dem lokalen MSW kann ein Sender seine lokale Daten-VC mit dem MSW zu einer solchen mit einem QoS verbessern (upgraden), die groß genug ist, um die Ressourcenreservierungen aller bekannten Empfänger zu erfüllen. Danach verbessert der MSW zusätzlich zu dem Herstellen eines QoS-Baums innerhalb seines LIS, wie es zuvor erwähnt wurde, die Inter-LIS-Best-Effort-Punkt-zu-Multipunkt-Daten-VC mit anderem MSWs zu einer solchen mit einem QoS, die groß genug ist, um den QoS-Anforderungen aller Empfänger gerecht zu werden. QoS-Parameter für die Inter-LIS-Daten-VC können von den Verkehrsspezifikations (Tspec)-Parametern in der PATH-Nachricht eines Senders erhalten werden. Danach baut jeder MSW, der ein Blattknoten auf der Inter-LIS-Daten-VC ist, auch eine oder mehrere Punkt-zu-Multipunkt-QoS-VCs innerhalb seines LIS für eine Datenverteilung zu den QoS-Empfängern auf. Anders als in dem Intra-LIS-Fall, in dem mehrere lokale Daten-VCs für Best-Effort- und QoS-Empfänger aufgebaut werden können, verwendet das Inter-LIS-Multicast-Versenden gerade eine QoS-VC. So wird irgendein Grad an Empfängerheterogenität, der benötigt wird, nur innerhalb einzelner LIS gestützt. Ein ausführliches Beispiel des RSVP-Betriebs, der Inter-LIS Multicast abdeckt, wird später gegeben.
  • 4. Ressourcenreservierung
  • Reservierungen unter MSWs werden unter Verwendung von ATM-Signalisierungsprotokollen gehandhabt, wodurch es dem ATM-Netz somit ermöglicht wird, den QoS und den Weg für MSW-zu-MSW-Punkt-zu-Multipunkt-VCs gut zu verwalten. Solche Reservierungen werden durch den MSW aufgebaut, der das LIS eines Senders zu der Zeit des Erzeugens der Punkt-zu-Multipunkt-Daten-VC zu anderen MSWs darstellt. Wenn mehr Empfänger dazukommen, können zusätzliche MSWs zu der Punkt-zu-Multipunkt-VC unter Verwendung von Blatt-initiierten Verbindungen hinzugefügt werden. Lokale (Intra-LIS-) Reservierungen werden ebenso durch den MSW und lokale Sender gehandhabt, die ATM-Signalisieren entsprechend der lokalen Politik betreffend des Grads der zu unterstützenden Heterogenität verwenden.
  • 5. RSVP-Soft-State und VC-Teardown
  • RSVP-Soft-State wird durch die RSVP-Handler-Funktion jedes MSW beibehalten, wie es zuvor angegeben wurde. RSVP erfordert, dass Router RSVP-Ströme unter Verwendung von Untätigkeitszeitnehmern überwachen und den Status für Ströme verwerfen, die für eine konfigurierte Zeitdauer keinen Verkehr gesehen haben. MSWs in dem erfinderischen Schema haben mehr als gerade den auf den Strom bezogenen Soft-State beizubehalten, da sie auch Intra- und Inter-LIS-VCs verwalten. Die RSVP-Handler-Funktion bei den MSWs ist für das periodische Überwachen der Aktivität auf RSVP-Strömen verantwortlich. Für aktive Ströme sollten Sender und Empfänger periodisch PATH- bzw. RESV-Nachrichten senden, jedoch kann es das Fehlen von solchen Nachrichten für eine konfigurierte Zeitdauer erfordern, dass die RSVP-Handler die Schalter-Hardware über den Status des Datenverkehrs auf dem Strom befragen. Wenn die Antwort von der Schalter-Hardware bestätigt, dass der in Frage stehende Strom während einer Periode inaktiv gewesen ist, die die konfigurierte Auszeit überschreitet, wird der Status für diesen Strom verworfen, und es wird jede assoziierte VC gelöscht.
  • 6. Mehrere Sender und RSVP-Reservierungsarten
  • Mehr als ein Sender kann einen Datenverkehr zu derselben IP-Multicast-Gruppen-Adresse zu einer gegebenen Zeit schicken. RSVP erlaubt es einzelnen Empfängern, einen Filter mit jeder angeforderten Reservierung zu assoziieren. Dieser Filter zeigt an, ob die Reservierung Daten, die von einem Sender (örtlich festgelegter Filter) gesendet werden, eine Liste von Sendern (geteilter expliziter Filter) oder alle gegenwärtigen und zukünftigen Sender (Wild-Card-Filter) betrifft.
  • Die Netzwerkarchitektur, die hier beschrieben wird, errichtet standardmäßig einen separaten Multicast-Baum (aus Intra- und Inter-LIS-VCs bestehend) für jeden Multicast-Sender. Dieses ist ideal, wenn alle Multicast-Empfänger in der ATM-Wolke die festgelegte Filterart angefordert haben, da jeder MSW Daten empfängt, die von unterschiedlichen Sendern auf unterschiedlichen VCs stammen. Unterstützung für die anderen zwei Arten kann mit einer der folgenden zwei Methoden ebenso zur Verfügung gestellt werden:
    • i) Separate Intra-LIS-VCs können für jeden Sender durch den MSW beibehalten werden, und ein lokaler Empfänger kann einer oder mehreren von solchen VCs abhängig von der Anzahl von Sendern hinzugefügt werden, die zu der Filterart passen, die von dem Empfänger angefordert wird.
    • ii) Jeder MSW kann die Multicast-Empfänger in seinem LIS in unterschiedliche Gruppen abhängig von der Filterart und den QoS-Parametern, die von den Empfängern angeordert werden, partitionieren. Empfänger, die ähnliche QoS-Parameter und um dieselbe Liste der Sender angefordert haben, können in eine Gruppe gesetzt werden. Als nächstes kann jede solche Gruppe auf einer anderen Intra-LIS-Daten-VC hinzugefügt werden. Auf diese Weise werden Empfänger, die einen Wild-Card-Filter (und ähnliche QoS-Parameter) verlangt haben, auf eine Daten-VC gesetzt. Ähnlich werden Empfänger, die ausdrücklich unterschiedliche Sätze von (einem oder mehreren) Sendern angefordert haben, auf unterschiedliche Daten-VCs gesetzt.
  • Ein MSW kann von dem Netzadministrator so konfiguriert werden, dass irgendeines der oben genannten Verfahren verwendet wird.
  • 7. Externe Sender
  • Wie zuvor erwähnt, haben die inneren (Nichtrand-) MSWs in der Netzwerkarchitektur, die hier beschrieben wird, keine IDMR (Inter Domain Multicast Routing)-Schnittstelle. Dieses liegt daran, dass solche MSWs kein Full-Fledged-IP-Multicast-Routing-Protokoll laufen zu lassen brauchen. Die einzigen Informationen, die für das Aufbauen von Inter-LIS-VCs benötigt werden, die solche über das Bestehen der Sender und der Empfänger in LIS eines jeden MSWs sind, werden unter MSWs unter Verwendung von Steuerungs-VCs ausgetauscht. Des Weiteren sind die Informationen, die für das Aufbauen von Intra-LIS-VCs benötigt werden, für jedes MSW von seinem lokalen MARS verfügbar. Wenn diese Informationen gegeben sind, können MSWs einen Multicast-Baum für jeden Sender innerhalb der ATM-Wolke herstellen.
  • Wenn jedoch eine Multicast-Gruppe einen äußeren Sender hat, kann der Verkehr, der an solch einem Sender entsteht, mehr als einen Rand-MSW erreichen. Wenn jeder solche Rand-MSW einen Multicast-Baum innerhalb der ATM-Wolke aufbaut, kann es mehrere aufgebauten Bäume (die durch unterschiedliche Rand-MSWs erzeugt werden) für den gleichen Sender geben. Da die inneren MSWs kein Full-Fledged-IP-Multicast-Routing-Protokoll laufen lassen, können sie nicht einen Randschalter über den anderen als ihre direkte Quelle von Multicast-Daten wählen. Dieses kann mehrfache Kopien der Datenpakete ergeben, die zu den Empfängern in der ATM-Wolke weitergeleitet werden, was offenbar nicht wünschenswert ist. Um einer Verdopplung von Multicast-Daten innerhalb des ATM-Wolke vorzubeugen, kooperieren alle Rand-MSWs in einer ATM-Wolke mit einander, um die äußeren Sender unter sich selbst zu verteilen. Nach einer solchen Partitionierung für einen gegebenen äußeren Sender gibt es genau einen Rand-MSW, der die Daten weiterleitet, die an diesem Sender in der ATM-Wolke entstehen. Dieser Rand-MSW ist der einzige, der die Erzeugung von Inter- und Intra-LIS-VCs in der ATM-Wolke für den äußeren Sender initiiert. In dieser Hinsicht wirken die Rand-MSWs in einer Art, die derjenigen von Multicast-Routern in einem geteilten Netz in dem Distance Vector Multicast Routing Protocol ähnlich ist (siehe D. Waitzman, et al., Distance Vector Multicast Routing Protocol, Network Working Group, Request for Comments 1075, November 1988), in dem genau ein Router zum Weiterleiten von Multicast-Daten in das geteilte Netz für eine gegebene Multicast-Quelle ausgewählt wird. Für die Rand-MSWs bildet die vollständige ATM-Wolke das geteilte Netz.
  • Beispiel des RSVP-Betriebs
  • Ein Beispiel des RSVP-Betriebs in der erfinderischen Netzwerkarchitektur wird jetzt mit Bezug auf eine ATM-Wolke 1 mit 3 LIS, wie in 6 gezeigt, beschrieben. In Stufe I des beispielhaften Betriebs sind, wie es in 6 gezeigt ist, keine Daten-VCs in der ATM-Wolke aufgebaut. Obgleich Intra- und Inter-LIS-Steuerungs-VCs aufgebaut werden müssen, bevor der RSVP-Betrieb stattfinden kann, werden solche VCs in der Figur aus Klarheit ausgelassen. Die beispielhafte Multicast-Sitzung hat einen Sender S 23, der sich in dem LIS2 7 befindet. Eine Gesamtmenge von drei Empfängern 24, 25 und 27 sind dazu gedacht, die Daten zu empfangen, die durch S 23 mit einem bestimmten QoS gesendet werden (es sei der Einfachheit willen angenommen, dass alle drei beabsichtigen, dieselben QoS-Parameter anzufordern). Weiterhin beabsichtigen die Empfänger 26 und 28, die Multicast-Daten ohne irgendwelche QoS-Reservierungen, d.h. mit Best-Effort-Protokollen, zu empfangen. Zusätzlich gibt es RSVP-Empfänger außerhalb der ATM-Wolke 1 (nicht in der Figur gezeigt) die es wünschen, den Multicast-Verkehr zu empfangen, der an dem Sender S 23 über zwei Rand-MSWs (MSW4 und MSW5) 29, 30 entsteht.
  • Mit Bezug nun auf 7 stellt der Sender S 23 zuerst eine Best-Effort-VC 34 zu dem MSW 32 her, der wiederum eine Best-Effort-VC 35 zu dem QoS-Empfänger 24 aufbaut. Wenn Empfänger in anderen LIS innerhalb und außerhalb der ATM-Wolke 1 der Multicast-Gruppe beitreten, zu welcher S 23 Daten schickt, empfängt der MSW 32 Mitgliedschaft-Aktualisierungen von den jeweiligen MSWs (z.B. 29, 30, 31, 33), die das Vorhandensein der lokalen Empfänger in ihren LIS anzeigen. Der MSW 32 fährt fort, eine Punkt-zu-Multipunkt-Best-Effort-VC 36 zu den MSWs (z.B. 29, 30, 31, 33) zu errichten, die lokale Empfänger haben. Diese MSWs (z.B. 29, 30, 31, 33) bauen Best-Effort-VCs 37 in ihren jeweiligen LIS für das Verteilen des Multicast-Verkehrs zu den lokalen Empfängern (z.B. 25-28) auf. Alle diese MSWs 29-33 verknüpfen dann die Intra- und Inter-LIS-Best-Effort-VCs 34-37, um einen Abkürzungweg von dem Sender S 23 zu allen Multicast-Empfängern aufzubauen. 7 zeigt den Multicast-Baum, der in dieser Weise aufgebaut wird, welche die Stufe II in dem Beispiel darstellt.
  • Um den QoS-Betrieb einzuleiten, schickt der Sender S 23 eine PATH-Nachricht zu dem MSW 32, die seine Verkehr-Eigenschaften beschreibt. Diese PATH-Nachricht wird durch den MSW 32 über Intra- und Inter-LIS-Steuerungs-VCs (nicht gezeigt) verteilt. Wenn andere MSWs (z.B. 31, 33) diese PATH-Nachricht empfangen, verteilen diese sie wiederum innerhalb ihrer jeweiligen LIS (z. B. 6, 8). Rand-MSWs (z. B. 29, 30) leiten auch die PATH-Nachricht an externe Netze weiter. Nachdem sie die PATH-Nachricht empfangen haben, zeigen Empfänger 24, 25 und 27 ihren Wunsch an, QoS-Verkehr zu empfangen, indem sie ihren jeweiligen MSWs 32, 31 bzw. 33 RESV-Nachrichten schicken. Man nehme an, dass einige Empfänger außerhalb der ATM-Wolke 1, die über den MSW 29 und den MSW 30 ebenfalls erreichbar sind, ebenso einen QoS-Verkehr unter Verwendung von RESV-Nachrichten anfordern, der schließlich den MSW 29 und den MSW 30 erreicht. Jeder MSW (einschließlich jedes Rand-MSWs), der QoS-Empfänger innerhalb seines LIS (oder stromabwärts von ihm) hat, schickt eine RESV-Nachricht zu dem MSW 32 unter Verwendung einer unterschiedlichen Punkt-zu-Punkt-Steuerungs-VC (nicht gezeigt), die Ressourcenreservierungen zusammenfasst, die von den Empfänger in ihren jeweiligen LIS angefordert werden. Danach schickt der MSW 32 eine aggregierte RESV-Nachricht zu S 23, welche die Reservierung anzeigt, die für die Punkt-zu-Punkt-VC zwischen S 23 und ihm selbst benötigt wird.
  • Um sich 8 zuzuwenden, so baut, nachdem er die RESV-Nachricht von dem MSW 32 empfangen hat, der Sender S 23 eine QoS-VC 38 zu dem MSW 32 auf und fängt damit an, den Multicast-Verkehr über die neue VC 38 zu senden. S 23 löscht ebenso die vorhandene Best-Effort-VC (34 in 7). MSW 32 stellt eine QoS-VC 39 zu dem QoS-Empfänger 24 her und lässt den Empfänger 24 von der vorhandenen Best-Effort-VC fallen (35 in 7). MSW 32 unterzieht ebenso die Best-Effort-VC (36 in 7) für eine Inter-LIS-Datenverteilung zu einer QoS-VC 40 mit QoS-Parametern groß genug, um irgendwelche der angeforderten Reservierungen zu unterstützen, einem Upgrade. Es gibt keine Notwendigkeit, die vorhandene Inter-MSW Best-Effort-VC (36 in 7) als MSWs beizubehalten, sodass nur Best-Effort-Empfänger Daten von dem MSW 32 auf der QoS-VC 40 empfangen können und sie lokal über Best-Effort-VCs 37 verteilen. Die vorhandene Inter-LIS-Best-Effort-VC (36 in 7) wird folglich verworfen, und es wird die QoS-VC 40 danach für ein Inter-LIS-Datenversenden verwendet. Nachdem die Inter-MSW-VC 40 aufgebaut worden ist, stellen der MSW 31 und der MSW 33 QoS-Daten-VCs 41 in ihren jeweiligen LIS 6, 8 zu Empfängern her, die einen QoS-Verkehr 25, 27 angefordert hatten. Die QoS-Empfänger 25, 27 werden auch von den vorhandenen Best-Effort-VCs (37 in 7) fallengelassen, obgleich Best-Effort-VCs für Best-Effort-Empfänger noch erforderlich sein können. MSW 32 verknüpft die ankommende QoS-VC 38 von dem Sender S 23 mit den abgehenden Inter- und Intra-LIS-VCs 39, 40. Andere MSWs verknüpfen die ankommende Inter-LIS-VC 40 mit einer oder mehreren abgehenden Intra-LIS-VCs 37, 41 und stellen so einen Abkürzungsweg von dem Sender zu allen Multicast-Empfängern (sowohl QoS als auch Best-Effort) zur Verfügung. Das abschließende VC-Setup (Stufe III) wird in 8 gezeigt.
  • Unterstützte Merkmale
  • Die gerade beschriebene Netzwerkarchitektur für das Mapping von IP-Multicast und von integrierten Services über ATM unterstützt eine Vielzahl von Merkmalen.
  • Zuerst kann eine Empfängerheterogenität, d.h. das Ermöglichen, dass unterschiedliche Empfänger in derselben Multicast-Sitzung Daten mit unterschiedlichen Reservierungen empfangen, durch einen MSW in vielen Formen einschließlich des modifizierten Homogenitätsansatzes unterstützt werden, der in Crawley et al., A Framework for Integrated Services and RSVP over ATM, Internet Engineering Task Force, Internet Draft, <draft-ietf-issll-atm-framework-00.txt>, 24. Juli 1997, empfohlen wird. Eine Empfängerheterogenität wird nur innerhalb von LIS unterstützt, in denen sie durch eine lokale Politik und Verfügbarkeit von Ressourcen leicht gesteuert werden kann. Es ist, vorausgesetzt, dass genügende Ressourcen vorhanden sind, möglich, eine vollständige Heterogenität, d.h. distinkte QoS-VCs für Empfänger mit unterschiedlichen Reservierungen, zu unterstützen. Die Zahl von distinkten VCs, die für eine gegebene Multicast-Adresse zu unterstützen ist, kann somit an die Menge der vorhandenen Ressourcen, wie dem Pufferplatz und die VC-Anzahl an dem lokalen MSW etc. gebunden sein. Die Unterstützung der Empfängerheterogenität an dem MSW kann unterschiedliche Queues und Algorithmen erfordern, um diese Queues für unterschiedliche abgehende VCs zu verwalten, wenn sie von einer einzelnen ankommenden VC gespeist werden. Es ist wünschenswert, diese Kapazität in der ATM-Schalter-Hardware zu haben, obgleich es immer möglich ist, eine Empfängerheterogenität in der Software zu unterstützen, indem man ein ankommendes Paket reassembled und es über einige abgehende VCs mit unterschiedlichem QoS überträgt. Eine Unterstützung der Empfängerheterogenität nur auf dem LIS-Niveau spart die Mühe des Aufbauens und Beibehaltens der mehreren Multicast-Bäume (einer für jede angeforderte QoS-Kategorie) für dieselbe Sitzung, die möglicherweise die vollständige ATM-Wolke überspannen können. Infolgedessen besteht keine Notwendigkeit, doppelte Kopien von Datenpaketen über mehrere VCs zwischen MSWs zu senden. Stattdessen ist eine Nachrichtenverdopplung, wenn es irgendein gibt, innerhalb der LIS-Grenzen begrenzt. In Wirklichkeit wird, wenn ein LIS aus gerade einem ATM-Schalter besteht (welcher der MSW sein muss), nur eine Kopie von Daten auf jeder möglichen ATM-Verbindung sogar mit voller Empfängerheterogenität weitergeleitet, da die Verbindung zwischen einem ATM-Host und seinem Schalter eine Punkt-zu-Punkt-Verbindung und nicht ein geteiltes Netz ist.
  • Zweitens kann Abkürzungs-Routing von einem Multicast-Sender zu allen Empfängern in der ATM-Wolke erreicht werden, indem man einfach die folgenden separaten VCs-i) die Punkt-zu-Punkt-VC von dem Sender zu seinem lokalen MSW, ii) die Punkt-zu-Multipunkt-Inter-LIS-VC von dem MSW des Senders zu anderem MSWs, die lokale Empfänger haben, und iii) die Punkt-zu-Multipunkt-VCs zwischen dem MSW und lokalen Empfängern in jedem LIS, das Multicast-Empfänger hat – verknüpft. Ein MSW kann die VCs in dieser Weise verknüpfen, nachdem er eine VC-Setup-Anforderung aus der Vorwärtsrichtung (ein anderer MSW oder ein lokaler Sender) empfangen hat und einen VC-Setup in der Rückwärtsrichtung (zu anderen MSWs oder zu lokalen Empfängern) initiiert hat. Alternativ kann die Verknüpfung durchgeführt werden, wenn das erste Datenpaket durch den MSW den gerouteten Weg in einer Weise durchquert, die IP-Schaltungsschemata ähnlich ist. Das Verwenden von einer VC-Verknüpfung für ein Abkürzungs-Routing und von direkten VCs für Inter-MSW-Daten und Steuerverkehr stellt ein Abkürzungs-Routing von einem Sender zu allen Empfängern in der ATM-Wolke sicher. Zur gleichen Zeit gewährleistet diese Anordnung, dass RSVP-Steuernachrichten denselben Weg (obgleich nicht dieselbe VC) wie Daten durchqueren, wodurch es somit RSVP-PATH-Nachrichten ermöglicht wird, Wegeigenschaften von einem Sender zu den Empfängern richtig zu akkumulieren.
  • Drittens stellen Rand-MSWs auf dem Rand der ATM-Wolke eine Zusammenarbeit mit Inter Domain Multicast Routing (IDMR)-Protokollen sicher, die außerhalb der ATM-Wolke in Gebrauch sein können. Ein Rand-MSW benimmt sich wie jeder mögliche andere MSW innerhalb der ATM-Wolke- in der Tat kann er sogar sein eigenes LIS von ATM-Hosts unterstützen. Zusätzlich lässt ein Rand-MSW auch eine passende Multicast-Routing-Software laufen, um korrekt mit dem Routing-Protokoll zusammenzuarbeiten, das auf seiner Nicht-ATM-Seite verwendet wird.
  • Viertens ermöglicht es RSVP Empfängern, ihre QoS-Reservierungen jederzeit zu ändern, selbst nachdem eine Multicast-Sitzung aufgebaut worden ist. Es ist jedoch ein wenig schwierig, einen dynamischen QoS in ATM-Netzen zu unterstützen, da weder UNI 4.0 noch PNNI z. Z. das Ändern von QoS-Parameter, wenn einmal eine VC aufgebaut worden ist, unterstützen. Die einzige mögliche Art, QoS für eine vorhandene Daten-VC in dem ATM-Netz zu ändern besteht dann, eine neue VC mit den geänderten QoS-Parametern aufzubauen und Verkehr von der alten VC zu der neuen hin zu verlagern.
  • Für einen hinreichend großen Multicast-Baum können solche Änderungen ziemlich aufwendig sein, da viele der angeforderten QoS-Änderungen sich über das LIS des Empfängers, der die QoS-Änderung angefordert hat, hinaus fortpflanzen. In dem erfinerischen Schema, das unterschiedliche VCs für Intra- und Inter-LIS-Verkehr aufweist, können die meisten Anfragen für das Ändern von QoS lokal untergebracht werden, d.h. innerhalb des LIS des Hosts, der die Änderung angefordert hat, weil die Inter-LIS-Daten-VC für einen gegebenen Datenstrom mit einem hinreichend großen QoS aufgebaut wird, so dass sie einen vollständigen Bereich von QoS-Anfragen von den einzelnen Empfängern unterbringen kann. Anforderungen für Änderungen in dem QoS durch lokale Empfänger können somit die Einrichtung von zusätzlichen VCs (und vielleicht den Abbau von alten VCs) veranlassen, um den neuen QoS zu unterstützen, aber solche Modifikationen werden auf das LIS begrenzt.
  • Auf 9 Bezug nehmend, erfolgt eine Beschreibung hinsichtlich grundlegender Prozeduren des Mapping-Verfahrens entsprechend der vorliegenden Erfindung.
  • Das Mapping-Verfahren ist für das Mapping von auf Quality of Service gegründetem Internet Working Protocol (IP) Multicast in einer Netzwerkarchitektur. Der IP-Multicast unterstützt mindestens eine Multicast-Gruppe. Die Netzwerkarchitektur umfasst eine Asynchroner-Übertragungsmodus (ATM)-Wolke einschließlich einer Mehrzahl von logischen IP-Teilnetzen, einer Mehrzahl von Multicast-Schaltern und einer Mehrzahl von lokalen ATM-Hosts. Die Multicast-Schalter kommunizieren unter Verwendung von ATM-Protokollen miteinander. Einer der Mehrzahl der Multicast-Schalter befindet sich in jedem der logischen IP-Teilnetze. Mindestens einer der lokalen ATM-Hosts befindet sich in jedem der logischen IP-Teilnetze.
  • An einem Schritt SA1 wird ein Intralogischer-IP-Teilnetz-Steuer-Baum in jedem der logischen IP-Teilnetze für eine Kommunikation zwischen den Multicast-Schaltern und den ATM-Hosts gebildet. An einem Schritt SA2 wird ein Interlogischer-IP-Teilnetz-Steuer-Baum für das Bereitstellen von Abkürzungs-Routing für interlogischen IP-Teilnetz-Multicast-Verkehr und für jede der mindestens einen Multicast-Gruppe gebildet. An Schritt SA3 wird ein Best-Effort-Punkt ein Punkt einer virtuellen Daten-Schaltung zwischen einen der ATM-Hosts, die Multicast-Daten senden, und einem der Multicast-Schalter, die in einem der logischen IP-Teilnetze gelegen sind, in dem der ATM-Hosts, der Multicast-Daten senden, angeordnet ist. An Schritt SA4 wird ein Best- Effort-Intraogischer-IP-Teilnetz-Daten-Baum in jedem der logischen IP-Teilnetze gebildet. An Schritt SA5 wird ein Best-Effort-Interlogischer-IP-Teilnetz-Daten-Baum gebildet, wobei der Best-Effort-Interlogischer-IP-Teilnetz-Daten-Baum mit den Best-Effort-Intralogischer-IP-Teilnetz-Daten-Bäumen verknüpft werden kann, wodurch Abkürzungen durch die Multicast-Schalter für das Routing interlogischen IP-Teilnetz-Multicast Verkehrs gebildet werden. An Schritt SA6 wird mindestens ein Zweig von mindestens einem der Best-Effort-Intralogischen-IP-Teilnetz-Daten-Bäume in den logischen IP-Teilnetzen einem Upgrade unterzogen, so dass er ein Quality-of-Service-Intralogischer-IP-Teilnetz-Daten-Baum für das Übertragen von Multicast-Daten ist. An Schritt SA7 wird der Best-Effort-Interlogischer-IP-Teilnetz-Daten-Baum zu einem Quality-of-Service-Interlogischer-IP-Teilnetz-Daten-Baum für das Übertragen von Multicast-Daten einem Upgrade unterzogen. An Schritt SA8 wird der Quality-of-Service-Intralogischer-IP-Teilnetz-Daten-Baum mit dem Quality-of-Service-Interlogischer-IP-Teilnetz-Daten-Baum und jedem verbleibenden der Best-Effort-Intralogischer-IP-Teilnetz-Daten-Bäume verknüpft, wodurch ein auf Quality-of-Service gegründeter Multicast-Baums gebildet wird.
  • In dem Mapping-Verfahren wird es bevorzugt, dass der Schritt SA1 einen Schritt des Aufbauens von virtuellen Punkt-zu-Multipunkt-Steuerschaltungen innerhalb jedes der logischen IP-Teilnetze, die signalisierendes ATM verwenden, zwischen den Multicast-Schaltern und den lokalen ATM-Hosts umfasst, die in jedem der logischen IP-Teilnetze angeordnet sind, umfasst.
  • Vorzugsweise umfasst der Schritt SA2 weiterhin einen Schritt des Aufbauens von virtuellen Punkt-zu-Multipunkt-Steuerschaltungen zwischen den Multicast-Schaltern, die sich in jedem der logischen IP-Teilnetze, die signalisierendes ATM verwenden, befinden.
  • Auf 10 Bezug nehmend, wird es bevorzugt, dass der Schritt SA4 einen Schritt SA41 der Bestimmung der Sätze der lokalen ATM-Hosts in den logischen IP-Teilnetzen als Mitgliedern von einer der mindestens einen Multicast-Gruppe und einen Schritt SA42 des Herstellens des Best-Effort Punktes zu virtuellen Multipunkt-Daten-Schaltungen innerhalb jedes der logischen IP-Teilnetze für jede der mindestens einen Multicast-Gruppe, die ATM-Signalisieren von einem jeweiligen der Multicast-Schalter in jedem der logischen IP-Teilnetze zu jedem der lokalen ATM-Hosts verwendet, die bestimmt werden, Mitglieder von der mindestens einen Multicast-Gruppe zu sein, umfasst.
  • Auf 11 Bezug nehmend umfasst der Schritt SA5 weiterhin einen Schritt SA51 des Weiterleitens von Gruppenmitgliedschaftinformationen betreffend die mindestens eine Multicast-Gruppe von jedem der Multicast-Schalter bezüglich seines logischen IP-Teilnetzes zu anderen der Multicast-Schalter, einen Schritt SA52 des Bildens jedes der Multicast-Schalter, der durch den Gebrauch von den Gruppenmitgliedschaftinformationen festgelegt wird, und eines spezifischen Satzes von anderen der Multicast-Schalter, die es benötigen, die Multicast-Daten, die von irgendwelchen des lokalen ATM-Host stammen, zu empfangen, und einen Schritt SA53 des Herstellens eines Best-Effort-Punktes zu einer virtuellen Multipunkt-Daten-Schaltung von dem einen der Multicast-Schalter, die in einem des logischen IP-Teilnetze angeordnet sind, die einen der ATM-Hosts enthalten, die Multicast-Daten zu anderen der Multicast-Schalter senden, die in den logischen IP-Teilnetzen angeordnet sind, die einige der ATM-Hosts enthalten, die Multicast-Daten unter Verwendung von ATM-Signalisieren empfangen.
  • Auf 12 Bezug nehmend, umfasst der Mapping-Schritt nach dem Schritt SA5 weiterhin einen Schritt SB1 des Übermittelns einer Quellen-Beschreibungs-Steuernachricht von dem einen der ATM-Hosts, die Multicast-Daten senden, über eine erste virtuelle Punkt-zu-Punkt-Steuerschaltung, die zwischen dem einen der ATM-Hosts aufgebaut wird, die Multicast-Daten senden, und dem einen der Multicast-Schalter, die in demjenigen der logischen IP-Teilnetze gelegen sind, in denen der eine der ATM-Hosts, die Multicast-Daten senden, angeordnet ist, einen Schritt SB2 des Versendens der Quellen-Beschreibungs-Steuernachricht von dem Multicast-Schalter in dem logischen IP-Teilnetz von dem einen der ATM-Hosts, die Multicast-Daten senden, zu anderen der Multicast-Schalter über den Intralogischer-IP-Teilnetz-Steuer-Baum, und einen Schritt SB3 des Veranlassens der anderen der Multicast-Schalter dazu, die Quellen-Beschreibungs-Steuernachricht über den Intralogischer-IP-Teilnetz-Steuer-Baum zu anderen der ATM-Hosts, die Multicast-Daten empfangen, zu übermitteln.
  • Es ist vorzuziehen, dass das Mapping-Verfahren weiterhin nach dem Schritt SB3 einen Schritt SB4 umfasst, der die Multicast-Schalter Quality of-Service-Ressourcenreservierungs-Anforderungs-Steuernachrichten über eine zweite von den virtuellen Punkt-Steuerschaltungen von einigen der ATM-Hosts empfangen lässt, die Multicast-Daten empfangen und auf Quality-of-Service gegründeten Multicast in den logischen IP-Teilnetzen anfordern, worin jede der Nachrichten zum Anzeigen eines unterschiedlichen Quality-of-Service fähig ist, wobei die Multicast-Schalter, welche die Quality-of-Service-Ressourcen-Reservierungsanforderungs-Steuernachrichten aggregieren, wobei aggregierte Quality-of-Service-Ressourcen-Reservierungsanforderungs-Steuernachrichten gebildet werden, wobei die Quality-of-Service-Ressourcenreservierung Anforderungs-Steuernachrichten den Ressourcenbedarf von den einigen der ATM-Hosts anzeigen, die Multicast-Daten empfangen, und einen Schritt SB5 des Veranlassens der Multicast-Schalter, dazu die aggregierten Quality-of-Service-Ressourcen-Reservierungsanforderungs-Steuernachrichten über eine dritte von den virtuellen Punkt-zu-Punkt-Steuerschaltungen an den Multicast-Schalter in dem logischen IP-Teilnetz von dem einen der ATM-Hosts, die Multicast-Daten senden, zu übermitteln, wobei die dritte von den virtuellen Punkt-zu-Punkt-Steuerschaltungen, für das Übermitteln der aggregierten Quality-of-Service-Ressourcen-Reservierungsanforderungs-Steuernachrichten gebildet wird, wobei der eine der Multicast-Schalter die Quality-of-Service-Ressourcen-Reservierungsanforderungs-Steuernachrichten zu dem anderen der ATM-Hosts, die Daten senden, über die erste virtuelle Punkt-zu-Punkt-Steuerschaltung aggregiert und sendet. Die Quality-of-Service-Ressourcen-Reservierungsanforderungs-Steuernachrichten werden in Schritt SA6 verwendet.
  • Das Mapping-Verfahren umfasst weiterhin den Schritt des Upgradens der virtuellen Best-Effort-Punkt zu-Punkt-Datenschaltung zu einer virtuellen Quality-of-Service-Best-Effort-Punkt zu-Punkt-Datenschaltung. Vorzugsweise werden die aggregierten Quality-of-Service-Ressourcen-Reservierungsanforderungs-Steuernachrichten in den Schritten SA7 und SA3 verwendet.
  • Es ist vorzuziehen, dass das Mapping-Verfahren weiterhin einen Schritt SB6 des Übermittelns neuer Quality-of-Service-Ressourcen-Reservierungsanforderungs-Steuernachrichten von einigen der Empfänger zu den jeweiligen der Multicast-Schalter, um den auf Quality-of-Service gegründeten Multicast-Baums zu ändern, einen Schritt SB7 des Änderns mindestens einiger Zweige der Quality-of-Service-Intralogischer-IP-Teilnetz-Daten-Bäume zu neuen Quality-of-Service-Intralogischer-IP-Teilnetz-Daten-Bäumen für das Übertragen von Multicast-Daten unter Verwendung von ATM-Signalisieren, wobei das Upgraden auf den neuen Quality-of-Service-Res sourcen-Reservierungsanforderungs-Steuernachrichten basiert, und einen Schritt SB8 des Verknüpfens der neuen Quality-of-Service-Intralogischer-IP-Teilnetz-Daten-Bäume mit den Quality-of-Service-Intralogischer-IP-Teilnetz-Daten-Bäumen, dem Quality-of-Service-Interlogischer-IP-Teilnetz-Daten-Baum und den verbleibenden der Best-Effort-Intralogischer-IP-Teilnetz-Daten-Bäumen umfasst, wodurch ein neuer auf Quality-of-Service gegründeter Multicast-Baum gebildet wird.
  • Vorzugsweise umfasst das Mapping-Verfahren weiterhin den Schritt des Veranlassens jedes der Multicast-Schalter dazu, unter Verwendung von Gruppenmitgliedschaftinformationen betreffend der mindestens einen Multicast-Gruppe, einen spezifischen Satz von anderen der Multicast-Schalter zu bestimmen, die die Multicast-Daten empfangen müssen, die von irgendwelchen der lokalen ATM-Hosts stammen, die Multicast-Daten für jede der mindestens einen Multicast-Gruppe senden.
  • Es ist vorzuziehen, dass die ATM-Wolke weiterhin eine Mehrzahl von Multicast-Adressauflösungs-Servern umfasst, und dass sich in jedem der logischen IP-Teilnetze mindestens einer der Multicast-Adressauflösungs-Server befindet. An dem Schritt SA4 werden in diesem Fall einige der ATM-Hosts, die Multicast-Daten empfangen, mit den Multicast-Adressauflösungs-Servern registriert, wenn die einige der ATM-Hosts, die Multicast-Daten empfangen, es wünschen, einer der mindestens einen Multicast-Gruppe beizutreten. Die Multicast-Adressauflösungs-Server lösen eine IP-Multicast-Adresse zu einer ATM-Adresse für jeden von den einigen der ATM-Hosts, die Multicast-Daten empfangen, auf. Die Multicast-Schalter werden mit den Multicast-Adressauflösungs-Servern als gemischte Empfänger und als Multicast-Server für alle IP-Multicast-Adressen registriert.
  • Es ist vorzuziehen, dass einer der ATM-Hosts, die Multicast-Daten senden, als ein Sender mit einem der Multicast-Adressauflösungs-Server, die in einem der logischen IP-Teilnetze gelegen sind, die den Sender enthalten, registriert wird, dass der Sender die Adresse des ATM-Senders und eine der IP-Multicast-Adressen liefert, zu denen der Sender die Multicast-Daten schicken möchte, und dass der eine der Multicast-Adressauflösungs-Server eine ATM-Adresse von dem einen der lokalen Multicast-Schalter, die in dem der logischen IP-Teilnetze gelegen sind, die den Sender als alleiniger Empfänger von der einen der mindestens einen Multicast-Gruppe enthalten, zurückgibt.
  • Zusätzlich ist es vorzuziehen, dass Änderungen in der Mitgliedschaft von der einen der mindestens einen Multicast-Gruppe den Multicast-Schaltern durch die Multicast-Adressauflösungs-Server mitgeteilt werden, und dass die Multicast-Schalter virtuelle Schaltungen zu den einigen der ATM-Hosts, die Multicast-Daten empfangen, entsprechend den Modifikationen in der Mitgliedschaft von der einen der mindestens einen Multicast-Gruppe hinzufügen und von dieser entfernen.
  • Vorzugsweise werden von dem mindestens einen Zweig nach dem Schritt SA6 solche entfernt, die ein Upgrade erfahren haben.
  • Quality-of-Service-Parameter der Quality-of-Service-Interlogischer-IP-Teilnetz-Daten-Bäume sind hinreichend groß, um eine der Quality-of-Service-Ressourcen-Reservierungsanforderungs-Steuernachrichten unterzubringen, die die größte Quality-of-Service-Anforderung besitzt.
  • Vorzugsweise umfasst das Mapping-Verfahren weiterhin den Schritt des Ermittelns eines Fehlens der Quellenbeschreibungs-Steuernachricht und der Quality-of-Service-Ressourcen-Reservierungsanforderungs-Steuernachrichten für einen vorbestimmten Zeitabschnitt und des Löschens entsprechender der Quality-of-Service-Intralogischer-IP-Teilnetz-Daten-Bäume, nachdem der vorbestimmte Zeitabschnitt abgelaufen ist.
  • Vorzugsweise enthält das Mapping-Verfahren weiterhin den Schritt des Zusammenarbeitens mit Protokollen außerhalb der ATM-Wolke durch Randschalter. In diesem Fall sind die Randschalter Multicast-Schalter und an den Rändern der ATM-Wolke angeordnet.
  • Vorzugsweise leiten die Rand-Schalter Gruppeninformationen, die sie von den äußeren Netzen erhalten haben, an die Multicast-Schalter in der ATM-Wolke weiter.
  • In dem Mapping-Verfahren wird es möglich, dass zusätzliche der ATM-Hosts, die Multicast-Daten senden, damit anfangen, Multicast-Daten zu einer der mindestens einen Multicast-Gruppe zu schicken, wodurch es dem einen der ATM-Hosts, die Multicast-Daten senden, und den zusätzlichen der ATM-Hosts, die Multicast-Daten senden, ermöglicht wird, die Multicast-Daten zu einer einzelnen IP-Multicast-Gruppenadresse zu einer gegebenen Zeit zu schicken.
  • Die Quality-of-Service-Ressourcen-Reservierungsanforderungs-Steuernachrichten, die durch einige der ATM-Hosts erzeugt werden, die Multicast-Daten empfangen, schließen weiterhin einen Filter ein. Der Filter zeigt an, dass die Quality-of-Service-Ressourcen-Reservierungsanforderungs-Steuernachrichten Daten, die von einem von allen gegenwärtigen und zukünftigen der Sender gesendet werden, eine spezielle Liste der Sender und eines festgelegten der Sender betreffen.
  • Wenn der Filter anzeigt, dass die Quality-of-Service-Ressourcen-Reservierungsanforderungs-Steuernachrichten einen festgelegten der Sender betreffen, wird ein unterschiedlicher auf Quality-of-Service gegründeter Multicast-Baums für den festgelegten der Sender gebildet.
  • Zusätzliche auf Quality-of-Service gegründete Intralogischer-IP-Teilnetz-Multicast-Bäume werden für jeden von den zusätzlichen der ATM-Hosts gebildet, die Multicast-Daten senden. Die Empfänger werden den zusätzlichen auf Quality-of-Service gegründeten Intralogischer-IP-Teilnetz-Multicast-Bäumen auf der Grundlage des Filters hinzugefügt.
  • Die Empfänger werden in Gruppen partitioniert. Die Gruppen gruppieren einige der Empfänger auf der Grundlage von gleichen der Quality-of-Service-Ressourcen-Reservierungsanforderungs-Steuernachrichten und von gleichen der Filter. Jede der Gruppen operiert an einem unterschiedlichen Multicast-Baum.
  • Die Randschalter arbeiten dabei zusammen, einen gegebenen der Randschalter zu bestimmen, der mit einem gegebenen äußeren Sender, der außerhalb der ATM-Wolke angeordnet ist, zu assoziieren ist. Der gegebene der Randschalter initiiert virtuelle Interlogische-IP-Teilnetz-Schaltungen und virtuelle Intralogische-IP-Teilnetz-Schaltungen in der genannten ATM-Wolke für die genannten äußeren Sender.
  • Obgleich die vorliegende Erfindung mit Bezug auf eine spezielle Ausführungsform beschrieben worden ist, sind viele Modifikationen und Variationen den Fachleuten auf diesem technologischen Gebiet klar offensichtlich. Dementsprechend sind all diese Modifi kationen und Variationen innerhalb des Bereichs der vorliegenden Erfindung enthalten, wie er durch die folgenden Ansprüche definiert wird.

Claims (41)

  1. Ein Verfahren zum Mapping eines auf Quality-of-Service basierenden Internet-Working-Protokoll (IP)-Multicast in einer Netzwerkarchitektur, wobei der genannte IP-Multicast zumindest eine Multicast-Gruppe unterstützt, wobei die genannte Netzwerkarchitektur eine Asynchroner-Übertragungsmodus (ATM)-Wolke (1) umfasst, die eine Mehrzahl an logischen IP-Teilnetzen (6, 7, 8), eine Mehrzahl an Multicast-Schaltern (9) und eine Mehrzahl an lokalen ATM-Hosts (2) einschließt, wobei die genannten Multicast-Schalter (9) unter Verwendung von ATM-Protokollen kommunizieren, wobei sich in jedem der genannten logischen IP-Teilnetze (6, 7, 8) einer der genannten Mehrzahl an Multicast-Schaltern (9) befindet, und sich in jedem der genannten logischen IP-Teilnetze (6, 7, 8) zumindest einer der genannten lokalen ATM-Hosts (2) befindet, wobei das genannte Verfahren die Schritte umfasst: – Bilden eines intralogischen IP-Teilnetz-Steuerungsbaums in jedem der genannten logischen IP-Teilnetze (6, 7, 8) zur Kommunikation zwischen den genannten Multicast-Schaltern (9) und den genannten ATM-Hosts (2); – Bilden eines interlogischen IP-Teilnetz-Steuerungsbaums zum Bereitstellen eines Abkürzungs-Routens für interlogischen IP-Teilnetz-Multicast-Verkehr und für jede der genannten zumindest einen Multicast-Gruppe; – Bilden einer virtuellen Best-Effort-Punkt-zu-Punkt-Daten-Schaltung zwischen einem der genannten ATM-Hosts (2), die Multicast-Daten senden, und einem der genannten Multicast-Schalter (9), der sich in einem der genannten logischen IP-Teilnetze (6, 7, 8) befindet, in dem der genannte eine der genannten ATM-Hosts (2), die Multicast-Daten senden, eingerichtet ist; – Bilden eines Best-Effort-Intralogischer-IP-Teilnetz-Datenbaums in jedem der genannten logischen IP-Teilnetze (6, 7, 8); – Bilden eines Best-Effort-Interlogischer-IP-Teilnetz-Datenbaums, wobei der genannte Best-Effort-Interlogischer-IP-Teilnetz-Datenbaum mit den genannten Best-Effort-Intralogischer-IP-Teilnetz-Datenbäumen verknüpft sein kann, wodurch Abkürzungen durch die genannten Multicast-Schalter (9) zum Routen von interlogischem IP-Teilnetz-Multicast-Verkehr gebildet werden; – Upgraden zumindest eines Zweigs von zumindest einem der genannten Best-Effort-Intralogischer-IP-Teilnetz-Datenbäume in den genannten logischen IP-Teilnetzen (6, 7, 8), so dass er ein Quality-of-Service-Intralogischer-IP-Teilnetz-Datenbaum zum Übermitteln von Multicast-Daten ist; – Upgraden des genannten Best-Effort-Interlogischer-IP-Teilnetz-Datenbaums auf einen Quality-of-Service-Interlogischer-IP-Teilnetz-Datenbaum zum Übermitteln von Multicast-Daten; – Verknüpfen der genannten Quality-of-Service-Intralogischer-IP-Teilnetz-Datenbäume mit dem genannten Quality-of-Service-Interlogischer-IP-Teilnetz-Datenbaum und jedem verbleibenden der genannten Best-Effort-Intralogischer-IP-Teilnetz-Datenbäume, wodurch ein auf Quality-of-Service basierender Multicast-Baum gebildet wird.
  2. Das Verfahren gemäß Anspruch 1, in dem der genannte Schritt des Bildens eines intralogischen IP-Teilnetz-Steuerungsbaums in jedem der genannten logischen IP-Teilnetze (6, 7, 8) umfasst: – Aufbauen von virtuellen Schaltungen zur Punkt-zu-Multipunkt-Steuerung in jedem der genannten logischen IP-Teilnetze (6, 7, 8) unter Verwendung von ATM-Signalisierung zwischen den genannten Multicast-Schaltern (9) und den genannten lokalen ATM-Hosts (2), die in den genannten logischen IP-Teilnetzen (6, 7, 8) eingerichtet sind.
  3. Das Verfahren gemäß Anspruch 1, in dem der genannte Schritt des Bildens eines interlogischen IP-Teilnetz-Steuerungsbaums weiterhin umfasst: – Aufbauen von virtuellen Schaltungen zur Punkt-zu-Multipunkt-Steuerung zwischen den genannten Multicast-Schaltern (9), die sich in jedem der genannten logischen IP-Teilnetze (6, 7, 8) befinden, unter Verwendung von ATM-Signalisierung.
  4. Das Verfahren gemäß Anspruch 1, in dem der genannte Schritt des Bildens eines Best-Effort-Intralogischer-IP-Teilnetz-Datenbaums umfasst: – Bestimmen von Sätzen der genannten lokalen ATM-Hosts (2) in den genannten logischen IP-Teilnetzen (6, 7, 8) als Mitglieder einer der genannten zumindest einen Multicast-Gruppe; – Aufbauen von virtuellen Best-Effort-Punkt-zu-Multipunkt-Daten-Schaltungen in jedem der genannten logischen IP-Teilnetze (6, 7, 8) für jede der genannten zumindest einen Multicast-Gruppe unter Verwendung von ATM-Signalisierung von einem jeweiligen der genannten Multicast-Schalter (9) in jedem der genannten logischen IP-Teilnetze (6, 7, 8) zu jedem der genannten lokalen ATM- Hosts (2), die als Mitglieder der genannten einen der genannten zumindest einen Multicast-Gruppe bestimmt werden.
  5. Das Verfahren gemäß Anspruch 1, in dem der genannte Schritt des Bildens eines Best-Effort-Interlogischer-IP-Teilnetz-Datenbaums umfasst: – Übermitteln von Gruppenmitgliedinformationen bezüglich der genannten zumindest einen Multicast-Gruppe von jedem der genannten Multicast-Schalter (9) bezüglich ihres logischen IP-Teilnetzes (6, 7, 8) zu anderen der genannten Multicast-Schalter (9); – durch jeden der genannten Multicast-Schalter (9) unter Verwendung der genannten Gruppenmitgliedinformationen Bestimmen eines speziellen Satzes von anderen der genannten Multicast-Schalter (9), die es benötigen, Multicast-Daten zu empfangen, die von irgendeinem der genannten lokalen ATM-Hosts (2) stammen, die Multicast-Daten senden; und – Aufbauen einer virtuellen Best-Effort-Punkt-zu-Multipunkt-Daten-Schaltung von dem genannten einen der genannten Multicast-Schalter, die in einem der genannten logischen IP-Teilnetze (6, 7, 8) eingerichtet sind, die einen der genannten ATM-Hosts (2) enthalten, die Multicast-Daten zu anderen der genannten Multicast-Schalter (9) senden, die in den genannten logischen IP-Teilnetzen (6, 7, 8) eingerichtet sind, die einen der genannten ATM-Hosts (2) enthalten, die Multicast-Daten unter Verwendung von ATM-Signalisierung empfangen.
  6. Das Verfahren gemäß Anspruch 1, weiterhin die Schritte umfassend: – nach dem genannten Schritt des Bildens eines Best-Effort-Interlogischer-IP-Teilnetz-Datenbaums Übermitteln einer Quellbeschreibungssteuernachricht von dem genannten einen der genannten ATM-Hosts (2), die Multicast-Daten senden, über eine erste virtuelle Schaltung zur Punkt-zu-Multipunkt-Steuerung, die zwischen dem genannten einen der genannten ATM-Hosts (2), die Multicast-Daten senden, und dem genannten einen der genannten Multicast-Schalter (9), die sich in dem genannten einen der genannten logischen IP-Teilnetze (6, 7, 8) befinden, in denen der genannte eine der genannten ATM-Hosts (2), die Multicast-Daten senden, eingerichtet ist, aufgebaut ist; – Übermitten der genannten Quellbeschreibungssteuernachricht von dem genannten Multicast-Schalter (9) in dem genannten logischen IP-Teilnetz (6, 7, 8) des genannten einen der genannten ATM-Hosts (2), die Multicast-Daten zu anderen der genannten Multicast-Schalter (9) über den genannten interlogischen IP-Teilnetz-Steuerbaum senden; und – durch die genannten anderen der genannten Multicast-Schalter (9) Übermitteln der genannten Quellbeschreibungssteuernachricht über den genannten intralogischen IP-Teilnetz-Steuerbaum an andere der genannten ATM-Hosts (2), die Multicast-Daten empfangen.
  7. Das Verfahren gemäß Anspruch 6, weiterhin die Schritte umfassend: – nach dem genannten Schritt des Übermittelns der genannten Quellbeschreibungssteuernachricht durch die anderen der genannten Multicast-Schalter (9) Empfangen von Quality-of-Service-Ressourcen-Reservierungsanforderungs-Steuernachrichten über zweite der virtuellen Schaltungen zur Punkt-zu-Punkt- Steuerung von einigen der genannten ATM-Host (2), die Multicast-Daten empfangen und auf Quality-of-Service basierendes Multicast in den genannten logischen IP-Teilnetze (6, 7, 8) wünschen, wobei jede der genannten Nachrichten in der Lage ist, einen unterschiedlichen Quality-of-Service anzuzeigen, die genannten Multicast-Schalter (9) die genannten Quality-of-Service-Ressourcen-Reservierungsanforderungs-Steuernachrichten aggregieren, gesammelte Quality-of-Service-Ressourcen-Reservierungsanforderungs-Steuernachrichten bilden, wobei die genannten Quality-of-Service-Ressourcen-Reservierungsanforderungs-Steuernachrichten Ressourcenanforderungen von den genannten einigen der genannten ATM-Host (2), die Multicast-Daten empfangen, anzeigen; und durch die genannten Multicast-Schalter (9) Übermitteln der genannten aggregierten Quality-of-Service-Ressourcen-Reservierungsanforderungs-Steuernachrichten über dritte der virtuellen Schaltungen zur Punkt-zu-Punkt-Steuerung zu dem genannten Multicast-Schalter (9) in dem genannten logischen IP-Teilnetz (6, 7, 8) des genannten einen der genannten ATM-Hosts (2), die Multicast-Daten senden, wobei die genannten dritten der virtuellen Schaltungen zur Punkt-zu-Punkt-Steuerung zum Übermitteln der genannten aggregierten Quality-of-Service-Ressourcen-Reservierungsanforderungs-Steuernachrichten ausgebildet sind, der genannte eine der genannten Multicast-Schalter (9) die genannten Quality-of-Service-Ressourcen-Reservierungsanforderungs-Steuernachrichten aggregiert und zu dem genannten einen der genannten ATM-Hosts (2), die Daten senden, über die genannte erste Schaltung zur Punkt-zu-Punkt-Steuerung übermittelt.
  8. Das Verfahren gemäß Anspruch 7, in dem die genannten Quality-of-Service-Ressourcen-Reservierungsanforderungs-Steuernachrichten in dem genannten Schritt des Upgradens des genannten zumindest einen Zweigs von zumindest einem der genannten Best-Effort-Intralogischer-IP-Teilnetz-Datenbäume verwendet werden.
  9. Das Verfahren gemäß Anspruch 7, weiterhin die Schritte umfassend: – Upgraden der genannten virtuellen Best-Effort-Punkt-zu-Punkt-Daten-Schaltung zu einer virtuellen Quality-of-Service-Best-Effort-Punkt-zu-Punkt-Daten-Schaltung, wobei die genannten aggregierten Quality-of-Service-Ressourcen-Reservierungsanforderungs-Steuernachrichten in dem genannten Schritt des Upgradens des genannten Best-Effort-Interlogischer-IP-Teilnetz-Datenbaums und dem genannten Schritt des Upgradens der genannten virtuellen Best-Effort-Punkt-zu-Punkt-Daten-Schaltung verwendet werden.
  10. Das Verfahren gemäß Anspruch 7, weiterhin die Schritte umfassend: – Übermitteln neuer Quality-of-Service-Ressourcen-Reservierungsanforderungs-Steuernachrichten von einigen der genannten Empfänger zu jeweiligen der genannten Multicast-Schalter (9), um den genannten auf Quality-of-Service basierenden Multicast-Baum zu verändern; – Verändern zumindest einiger Zweige der genannten Quality-of-Service-Intralogischer-IP-Teilnetz-Datenbäume zu neuen Quality-of-Service-Intralogischer-IP-Teilnetz-Datenbäumen zum Übermitteln von Multicast-Daten unter Verwendung von ATM-Signalisierung, wobei das genannte Upgrading auf der genannten neuen Quality-of-Service-Ressourcen-Reservierungsanforderungs-Steuernachricht basiert; und – Verknüpfen der genannten neuen Quality-of-Service-Intralogischer-IP-Teilnetz-Datenbäume mit den genannten Quality-of-Service-Intralogischer-IP-Teilnetz-Datenbäume, dem genannten Quality-of-Service-Interlogischer-IP-Teilnetz-Datenbaum und den genannten verbleibenden der genannten Best-Effort-Intralogischer-IP-Teilnetz-Datenbäume, wodurch ein neuer auf Quality-of-Service basierender Multicast-Baum gebildet wird.
  11. Das Verfahren gemäß Anspruch 3, weiterhin die Schritte umfassend: – durch jeden der genannten Multicast-Schalter (9), unter Verwendung der Gruppenmitgliedinformationen bezüglich der genannten zumindest einen Multicast-Gruppe, Bestimmen eines spezifischen Satzes von anderen der genannten Multicast-Schalter (9), die es benötigen, Multicast-Daten zu empfangen, die von irgendeinem der genannten lokalen ATM-Hosts stammen, die Multicast-Daten für jede der genannten zumindest einen lokalen Multicast-Gruppe senden.
  12. Das Verfahren gemäß Anspruch 4, in dem die genannte ATM-Wolke (1) weiterhin eine Mehrzahl an Multicast-Adressausflösungs-Servern umfasst, wobei sich in jedem der genannten logischen IP-Teilnetze (6, 7, 8) zumindest einer der genannten Multicast-Adressausflösungs-Server befindet, wobei der genannte Schritt des Bestimmens von Sätzen weiterhin die Schritte umfasst: – Registrieren einiger der genannten ATM-Hosts (2), die Multicast-Daten empfangen, mit den genannten Multicast-Adressausflösungs-Servern, wenn die genannten einige der genannten ATM-Hosts (2), die Multicast-Daten empfangen, es wünschen, der einen der genannten zumindest einen Multicast-Gruppe beizutreten, wobei die genannten Multicast-Adressausflösungs-Server eine IP-Multicast-Adresse zu einer ATM-Adresse für jeden der genannten einigen der genannten ATM-Hosts (2), die Multicast-Daten empfangen, auflösen; und – Registrieren der genannten Multicast-Schalter (9) mit den genannten Multicast-Adressausflösungs-Servern als vermischte Empfänger und als Multicast-Server für sämtliche IP-Multicast-Adressen.
  13. Das Verfahren gemäß Anspruch 12, in dem einer der genannten ATM-Hosts (2), der Multicast-Daten sendet, sich als ein Sender mit einem der genannten Multicast-Adressausflösungs-Server registriert, die sich in einem der genannten logischen IP-Teilnetze (6, 7, 8) befinden, die den Sender enthalten, wobei der genannte Sender die genannte ATM-Adresse des Senders und eine der genannten IP-Multicast-Adressen zur Verfügung stellt, an die der genannte Sender die genannten Multicast-Daten zu senden wünscht, wobei der genannte eine der genannten Multicast-Adressausflösungs-Server eine ATM-Adresse von dem genannten einen der genannten lokalen Multicast-Schalter (9), die sich in dem genannten einen der genannten logischen IP-Teilnetze (6, 7, 8) befinden, zurückgibt, die den genannten Sender als einen einzigen Empfänger der genannten einen der genannten zumindest einen Multicast-Gruppe enthält.
  14. Das Verfahren gemäß Anspruch 12, in dem Änderungen in der Mitgliedschaft der genannten einen der genannten zumindest einen Multicast-Gruppe an die genannten Multicast-Schalter (9) durch die genannten Multicast-Adressausflösungs-Server kommuniziert werden, wobei die genannten Multicast-Schalter (9) virtuelle Schaltungen gemäß den genannten Änderungen in der Mitgliedschaft der genannten einen der genannten zumindest einen Multicast-Gruppe hinzufügen zu und entfernen von den genannten einigen der genannten ATM-Hosts (2), die Multicast-Daten empfangen.
  15. Das Verfahren gemäß Anspruch 1, in dem nach dem genannten Schritt des Upgradens von zumindest einem Zweig von zumindest einem der genannten Best-Effort-Intralogischer-IP-Teilnetz-Datenbäume zu Quality-of-Service -Intralogischer-IP-Teilnetz-Datenbäumen, solche von dem zumindest einen Zweig entfernt werden, die ein Upgrade erfahren haben.
  16. Das Verfahren gemäß Anspruch 9, in dem Quality-of-Service-Parameter der genannten Quality-of-Service-Interlogischer-IP-Teilnetz-Datenbäume hinreichend groß sind, eine der genannten Quality-of-Service-Ressourcen-Reservierungsanforderungs-Steuernachrichten aufzunehmen, die die höchste Quality-of-Service-Anforderung stellt.
  17. Das Verfahren gemäß Anspruch 7, weiterhin den Schritt des Ermittelns einer Abwesenheit der genannten Quellbeschreibungssteuernachricht und der genannten Quality-of-Service-Ressourcen-Reservierungsanforderungs-Steuernachrichten über eine vorbestimmte Zeitdauer und Löschen von entsprechenden der genannten Quality-of-Service-Intralogischer-IP-Teilnetz-Datenbäume, nachdem die vorbestimmte Zeitdauer vorübergegangen ist, umfassend.
  18. Das Verfahren gemäß Anspruch 1, weiterhin Zusammenarbeiten mit Protokollen außerhalb der genannten ATM-Wolke durch Randschalter (4) umfassend, wobei die Randschalter (4) Multicast-Schalter sind, die an Rändern der genannten ATM-Wolke (1) eingerichtet sind.
  19. Das Verfahren gemäß Anspruch 18, in dem die genannten Randschalter (4) Gruppeninformationen, die sie von Netzwerken außerhalb erhalten haben, an die genannten Multicast-Schalter (9) in der genannten ATM-Wolke (1) übermitteln.
  20. Das Verfahren gemäß Anspruch 13, in dem zusätzliche von den genannten ATM-Hosts (2), die Multicast-Daten senden, damit beginnen, Multicast-Daten zu einer der genannten zumindest einen Multicast-Grupp zu senden, wodurch es dem genannten einen der genannten ATM-Hosts (2), die Multicast-Daten senden, und den genannten zusätzlichen der genannten ATM-Hosts (2), die Multicast-Daten senden, ermöglicht wird, die genannten Multicast-Daten zu einer gegebenen Zeit an eine einzelne IP-Multicast-Gruppen-Adresse zu senden.
  21. Das Verfahren gemäß Anspruch 7, in dem in dem die genannten Quality-of-Service-Ressourcen-Reservierungsanforderungs-Steuernachrichten, die von den genannten einigen der genannten ATM-Hosts (2), die Multicast-Daten empfangen, erzeugt werden, weiterhin einen Filter einschließen, wobei der genannte Filter anzeigt, dass die genannten Quality-of-Service-Ressourcen-Reservierungsanforderungs-Steuernachrichten Daten, die von einem von sämtlichen gegenwärtigen und zukünftigen der genannten Sender gesendet werden, eine spezielle Liste der genannten Sender und einen bestimmten der genannten Sender betreffen.
  22. Das Verfahren gemäß Anspruch 21, in dem, wenn der genannte Filter anzeigt, dass die genannten Quality-of-Service-Ressourcen-Reservierungsanforderungs-Steuernachrichten einen bestimmten der genannten Sender betreffen, ein separater auf Quality-of-Service basierender Multicast-Baum für den genannten bestimmten der genannten Sender gebildet wird.
  23. Das Verfahren gemäß Anspruch 21, in dem zusätzliche intralogische auf Quality-of-Service basierende IP-Teilnetz-Multicast-Bäume für jeden der genannten zusätzlichen der genannten ATM-Hosts (2), die Multicast-Daten senden, gebildet wird, wobei die genannten Empfänger auf der Grundlage des genannten Fil ters den genannten zusätzlichen intralogischen auf Quality-of-Service basierenden IP-Teilnetz-Multicast-Bäumen hinzugefügt werden.
  24. Das Verfahren gemäß Anspruch 21, in dem die genannten Empfänger in Gruppen partitioniert sind, wobei die genannten Gruppen einige der genannten Empfänger auf der Grundlage gleicher der genannten Quality-of-Service-Ressourcen-Reservierungsanforderungs-Steuernachrichten und gleicher des genannten Filters gruppieren, wobei jede der genannten Gruppen auf einem separaten Multicast-Baum operiert.
  25. Das Verfahren gemäß Anspruch 19, in dem die genannten Randschalter (4) darin kooperieren, einen bestimmten der genannten Randschalter (4) zu bestimmen, der mit einem bestimmten äußeren Sender zu assoziieren ist, der außerhalb der genannten ATM-Wolke angeordnet ist, wobei der bestimmte der genannten Randschalter (4) virtuelle interlogische IP-Teilnetz-Schaltungen und virtuelle intralogische IP-Teilnetz-Schaltungen in der genannten ATM-Wolke (1) für den genannten bestimmten äußeren Sender initiiert.
  26. Eine Netzwerkarchitektur zum Mapping eines auf Quality-of-Service basierenden Internet-Working-Protokoll (IP)-Multicast in einem Netzwerk, wobei der genannte IP-Multicast eingerichtet ist, zumindest eine Multicast-Gruppe zu unterstützen, wobei die genannte Netzarchitektur eine Asynchroner-Übertragungsmodus (ATM)-Wolke (1) umfasst, wobei die genannte ATM-Wolke (1) umfasst: – eine Mehrzahl an logischen IP-Teilnetzen (6, 7, 8); – eine Mehrzahl an ATM-Hosts (2), wobei sih in jedem der genannten logischen IP-Teilnetze (6, 7, 8) zumindest einer der genannten Mehrzahl an ATM-Hosts (2) befindet; und – eine Mehrzahl an Multicast-Schaltern (9), wobei jeder der genannten Mehrzahl an Multicast-Schaltern (9) in einer jeweiligen der genannten logischen IP-Teilnetze (6, 7, 8) eingerichtet ist, zum Aggregieren von Sendern außerhalb von jedem der genannten logischen IP-Teilnetze (6, 7, 8) für lokale Empfänger inner halb von jedem der genannten logischen IP-Teilnetze (6, 7, 8) und zum Aggregieren von Empfängern außerhalb von jedem der genannten logischen IP-Teilnetze (6, 7, 8) für lokale Sender innerhalb von jedem der genannten logischen IP-Teilnetze (6, 7, 8), wobei die genannten Multicast-Schalter (9) eingerichtet sind, miteinander unter Verwendung von ATM-Protokollen zu kommunizieren.
  27. Eine Netzwerkarchitektur gemäß Anspruch 26, in der die genannte ATM-Wolke (1) weiterhin umfasst: eine Mehrzahl an Multicast-Adressausflösungs-Servern, wobei sich in jedem der genannten logischen IP-Teilnetze (6, 7, 8) einer der genannten Mehrzahl an Multicast-Adressausflösungs-Servern zum Auflösen einer IP-Multicast-Adresse zu ATM-Adressen von Empfängern befindet, die eingerichtet sind, einer der genannten zumindest einen Multicast-Gruppe, die durch die Multicast-Adresse dargestellt wird, beizutreten.
  28. Eine Netzwerkarchitektur gemäß Anspruch 27, weiterhin Randschalter (4) zum Aggregieren einiger der genannten ATM-Hosts, die Multicast-Daten innerhalb der genannten ATM-Wolke (1) empfangen, für Sender außerhalb der genannten ATM-Wolke (1) und zum Aggregieren von Empfängern außerhalb der genannten ATM-Wolke (1) für einige der genannten ATM-Hosts, die Multicast-Daten innerhalb der genannten ATM-Wolke (1) senden, wobei die Randschalter (4) einige der genannten Multicast-Schalter sind, die an Rändern der genannten ATM-Wolke (1) eingerichtet sind.
  29. Eine Netzwerkarchitektur gemäß Anspruch 28, in der die genannten Randschalter (4) mit Inter-Domain-Multicast-Routing (IDMR)-Protokollen zusammenarbeiten, die außerhalb der genannten ATM-Wolke (1) zum Senden und Empfangen von Multicast-Routen- und Mitgliedinformationen über die genannte ATM-Wolke (1) verwendet werden.
  30. Eine Netzwerkarchitektur gemäß Anspruch 29, in der für jeden der genannten Sender außerhalb der genannten ATM-Wolke (1) lediglich einer der genannten Randschalter (4) dazu eingerichtet ist, innerhalb der genannten ATM-Wolke (1) einen Multicast-Baum aufzubauen.
  31. Ein Multicast-Schalter zur Verwendung in einer Netzwerkarchitektur zum Mapping eines Internet-Working-Protokoll (IP)-Multicast und integrierten Services über ein Asynchroner-Übertragungsmodus (ATM)-Netzwerk, wobei die genannte Netzwerkarchitektur eine ATM-Wolke (1) umfasst, die eine Mehrzahl an Multicast-Schaltern (9) und lokalen ATM-Hosts (2) einschließt, wobei die genannte ATM-Wolke (1) weiterhin eine Mehrzahl an logischen IP-Teilnetzen (6, 7, 8) einschließt, wobei jedes der logischen IP-Teilnetze (6, 7, 8) einen der genannten Multicast-Schalter (9) und zumindest einen der genannten lokalen ATM-Hosts (2) enthält, wobei die genannten Multicast-Schalter (9) eingerichtet sind, miteinander unter Verwendung von ATM-Protokollen zu kommunizieren, wobei jeder Multicast-Schalter (9) umfasst: – ein Schaltnetz, das es eingehenden virtuellen Schaltungen ermöglicht, mehrere abgehende virtuelle Schaltungen zu speisen; – einen Schalt-Kontroller (10) zum Steuern des genannten Schaltnetzes, um Header-Übersetzungstabellen für die genannten virtuellen Schaltungen aufzubauen; – ein ATM-Signalisierungs-Software-Modul zum Aufbauen der genannten virtuellen Schaltungen unter Verwendung von ATM-Signalisierung, wobei der genannte Schalt-Kontroller (10) in der Lage ist, die genannten virtuellen Schaltungen zu beenden und die genannten virtuellen Schaltungen mit zwei verschiedenen Verbindungen zu verknüpfen, wodurch es Daten auf einer der genannten eingehenden virtuellen Schaltungen ermöglicht wird, durch das genannte Netzwerk auf einer der genannten abgehenden virtuellen Schaltungen ohne Software-Intervention übermittelt zu werden; und – ein Multicast-Routing-Modul (14), das ein Modul zum Beibehalten von Gruppenmitgliedinformationen für die genannten logischen IP-Teilnetze und ein Modul für die Kommunikation mit Peer-Funktionen auf den genannten Multicast- Schaltern (9) in der genannten ATM-Wolke (1) zum Austauschen summierter lokaler Mitgliedinformationen einschließt.
  32. Ein Multicast-Schalter gemäß Anspruch 31, weiterhin umfassend: – ein Ressourcenreservierungs-Protokollnachrichten-Bearbeitungs-Modul (11) zum Beenden von Ressourcen-Reservierungs-Steuernachrichten von den genannten Multicast-Schaltern (9) in der genannten Netzwerkarchitektur und von den genannten lokalen ATM-Hosts (8); – ein Rufzulassungssteuermodul (12), das mit dem genannten Ressourcenreservierungs-Protokollnachrichten-Bearbeitungs-Modul (11) zum Bestimmen davon verbunden ist, ob hinreichende Ressourcen für einen neuen Datenstrom reserviert werden können, wenn das genannte Ressourcenreservierungs-Protokollnachrichten-Bearbeitungs-Modul (11) eine Ressourcenreservierung für den genannten neuen Datenstrom empfängt; und – ein Virtuelle-Schaltung-Management-Modul (13) zum Aufbauen virtueller Schaltungen für den genannten neuen Datenstrom, wenn das genannte Rufzulassungssteuermodul (12) bestimmt, dass hinreichende Ressourcen reserviert werden können.
  33. Ein Multicast-Schalter gemäß Anspruch 32, in dem das genannte Virtuelle-Schaltung-Management-Modul (13) ein erstes Teil (13a) zum Aufbauen virtueller intralogischer IP-Teilnetz-Schaltungen und virtueller interlogischer IP-Teilnetz-Schaltungen und ein zweites Teil (13b) zum Verknüpfen von irgendwelchen zwei der genannten virtuellen intralogischen IP-Teilnetz-Schaltungen und virtuellen interlogischen IP-Teilnetz-Schaltungen zu einer virtuellen Schaltung umfasst, wobei die genannten zwei virtuellen Schaltungen eingerichtet sind, in einem entsprechenden der genannten Multicast-Schalter (9) zu enden, wobei die genannten virtuellen intralogischen IP-Teilnetz-Schaltungen und virtuellen interlogischen IP-Teilnetz-Schaltungen so angeordnet sind, dass sie unter den genannten Multicast-Schaltern (9) einen Multicast-Baum ausbilden.
  34. Ein Multicast-Schalter gemäß Anspruch 33, in dem der genannte Multicast-Baum entweder ein auf Best-Effort basierender Multicast-Baum, ein auf Quality-of-Service basierender Multicast-Baum oder ein gemischt auf Best-Effort und Quality-of-Service basierender Multicast-Baum ist.
  35. Ein Multicast-Schalter gemäß Anspruch 33, in dem das genannte Virtuelle-Schaltung-Management-Modul (13) eingerichtet ist, einige der genannten ATM-Hosts, die Multicast-Daten empfangen, als Blattknoten dem genannten Multicast-Baum hinzuzufügen, wenn die genannten einige der genannten ATM-Hosts, die Multicast-Daten empfangen, sich mit dem genannten Multicast-Baum verbinden.
  36. Ein Multicast-Schalter gemäß Anspruch 35, in dem das genannte Virtuelle-Schaltung-Management-Modul (13) eingerichtet ist, neue der genannten Multicast-Schalter (9) dem genannten Multicast-Baum hinzuzufügen, wenn die genannten ATM-Hosts sich mit dem genannten Multicast-Baum verbinden.
  37. Ein Multicast-Schalter gemäß Anspruch 33, in dem das genannte Virtuelle-Schaltung-Management-Modul (13) eingerichtet ist, einige der genannten ATM-Hosts, die als Blattknoten Multicast-Daten empfangen, von dem genannten Multicast-Baum zu entfernen, wenn die genannten einige der genannten ATM-Hosts, die Multicast-Daten empfangen, einen Datenstrom verlassen.
  38. Ein Multicast-Schalter gemäß Anspruch 37, in dem das genannte Virtuelle-Schaltung-Management-Modul (13) eingerichtet ist, einige der genannten Multicast-Schalter (9) von dem genannten Multicast-Baum zu entfernen, wenn sämtliche der genannten ATM-Hosts, die Multicast-Daten empfangen, die in entsprechenden der genannten logischen IP-Teilnetze eingerichtet sind, die die genannten einige der genannten Multicast-Schalter (9) enthalten, entfernt werden.
  39. Ein Multicast-Schalter gemäß Anspruch 32, in dem zumindest einer der genannten Multicast-Schalter (9) ein Randschalter (4) zum Aggregieren einiger der genannten ATM-Hosts, die Multicast-Daten empfangen, innerhalb der genannten ATM-Wolke (1) für Hosts, die Sender außerhalb der genannten ATM-Wolke (1) sind, und zum Aggregieren von Hosts, die Empfänger außerhalb der genannten ATM-Wolke (1) sind, für einige der genannten ATM-Hosts, die Multicast-Daten senden, die innerhalb der genannten ATM-Wolke (1) sind, ist.
  40. Ein Multicast-Schalter gemäß Anspruch 39, in dem das genannte Multicast-Routing-Modul (14) weiterhin ein Modul zum Bereitstellen einer Inter-Domain-Multicast-Routing (IDMR)-Protokoll-Schnittstelle (14c) an IP-Router, die sich außerhalb der genannten ATM-Wolke (1) befinden, umfasst.
  41. Ein Multicast-Schalter gemäß Anspruch 40, in dem die genannte Inter-Domain- Multicast-Routing (IDMR)-Protokoll-Schnittstelle (14c) Muticast-Routing für unterstützte IDMR-Protokolle für das Wechselwirken mit den genannten IP-Routern außerhalb der genannten ATM-Wolke (1) durch Senden und Empfangen von Multicast-Route-Informationen und Mitgliedinformationen über die genannte ATM-Wolke (1) umfasst.
DE69837464T 1997-11-18 1998-11-18 Vermittlungsnetzaufbau für IP-Mehrfachsendung und für integrierte Dienste Expired - Lifetime DE69837464T2 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US972748 1997-11-18
US08/972,748 US6671276B1 (en) 1997-11-18 1997-11-18 Switch based network architecture for IP multicast and integrated services

Publications (2)

Publication Number Publication Date
DE69837464D1 DE69837464D1 (de) 2007-05-16
DE69837464T2 true DE69837464T2 (de) 2007-07-19

Family

ID=25520068

Family Applications (1)

Application Number Title Priority Date Filing Date
DE69837464T Expired - Lifetime DE69837464T2 (de) 1997-11-18 1998-11-18 Vermittlungsnetzaufbau für IP-Mehrfachsendung und für integrierte Dienste

Country Status (4)

Country Link
US (1) US6671276B1 (de)
EP (1) EP0917390B1 (de)
JP (1) JP3147164B2 (de)
DE (1) DE69837464T2 (de)

Families Citing this family (45)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6539000B1 (en) * 1998-07-21 2003-03-25 Kabushiki Kaisha Toshiba Multicast communication method and apparatus
US6850987B1 (en) * 1999-06-01 2005-02-01 Fastforward Networks, Inc. System for multipoint infrastructure transport in a computer network
JP3549774B2 (ja) * 1999-06-01 2004-08-04 富士通株式会社 ネットワーク相互接続装置及びネットワーク相互接続方法
JP4999244B2 (ja) * 1999-06-08 2012-08-15 ザ トラスティーズ オブ コロンビア ユニヴァーシティ イン ザ シティ オブ ニューヨーク インターネット電話用のネットワーク電話器具およびシステム
AU5879800A (en) * 1999-06-18 2001-01-09 Trustees Of Columbia University In The City Of New York, The System and method for receiving over a network a broadcast from a broadcast source
US6606315B1 (en) * 1999-07-02 2003-08-12 Cisco Technology, Inc. Synchronizing service instructions among forwarding agents using a service manager
US20010027490A1 (en) * 2000-01-25 2001-10-04 Gabor Fodor RSVP handling in 3G networks
GB0005363D0 (en) * 2000-03-06 2000-04-26 Nokia Networks Oy Interworking in a communication system
US7065079B1 (en) * 2000-05-04 2006-06-20 Cisco Technology, Inc. VC sharing for multicast in a computer network
US7184440B1 (en) 2000-07-26 2007-02-27 Alcatel Canada Inc. Multi-protocol switch and method therefore
RU2003106394A (ru) 2000-08-11 2004-08-20 Дзе Трастиз Оф Коламбия Юниверсити Ин Дзе Сити (Us) Система и способ унифицированного обмена сообщениями в интер/интранет-телефонии
ATE326097T1 (de) * 2000-08-25 2006-06-15 Cit Alcatel Verfahren zur bereitstellung einer bidirektionellen verbindung in einem netz für die mehrfachübertragung von datenströmen mit verwendung vom internetprotokoll und netz für die anwendung des verfahrens
US7197555B1 (en) * 2000-09-13 2007-03-27 Canon Kabushiki Kaisha Directory server tracking tool
US7180855B1 (en) * 2001-04-19 2007-02-20 At&T Corp. Service interface for QoS-driven HPNA networks
US7142563B1 (en) 2001-02-20 2006-11-28 At&T Corp. Service interface for QoS-driven HPNA networks
US7293103B1 (en) 2001-02-20 2007-11-06 At&T Corporation Enhanced channel access mechanisms for a HPNA network
US7213050B1 (en) * 2001-07-11 2007-05-01 Cisco Technology, Inc. System and method for reserving conference resources for a multipoint conference using a priority scheme
AR039363A1 (es) 2001-11-02 2005-02-16 Interdigital Tech Corp Un metodo para establecer una sesion inalambrica en base a paquetes entre al menos dos usuarios, donde al menos uno de los usuarios es un usuario inalambrico y un equipo de usuario inalambrico utilizado por dicho metodo
US20030144895A1 (en) * 2002-01-30 2003-07-31 Comverse, Inc. Prepaid personal advisory service for cellular networks
US7065577B1 (en) * 2002-03-27 2006-06-20 Alcatel Facilitating IP-based multicasting control connections
CN100426733C (zh) 2003-01-16 2008-10-15 华为技术有限公司 网络通信中实现资源分配的系统及其方法
DE602004027379D1 (de) * 2003-06-26 2010-07-08 Thomson Licensing Kindersicherung für digitalen inhalt
CN1327664C (zh) * 2003-08-19 2007-07-18 华为技术有限公司 异步传输模式数据流的转发装置及方法
US20050094653A1 (en) * 2003-11-03 2005-05-05 Marconi Communications, Inc. Permanent virtual channel/path connection modify
EP1687995B1 (de) * 2003-11-28 2010-04-07 Telefonaktiebolaget LM Ericsson (PUBL) Verfahren und anordnung zur transportschicht-steuer-zeichengabe in utran bei unterstützung sowohl von atm- als auch von ip-transporttechnologie
US8009668B2 (en) * 2004-08-17 2011-08-30 Hewlett-Packard Development Company, L.P. Method and apparatus for router aggregation
US20060285497A1 (en) * 2005-06-20 2006-12-21 Nokia Corporation Method, apparatus and computer program product providing interoperable QoS parameters and signaling thereof in a 3GPP2-3GPP and 3GPP2-3GPP2 conversational multimedia exchange
US8599685B2 (en) * 2006-09-26 2013-12-03 Cisco Technology, Inc. Snooping of on-path IP reservation protocols for layer 2 nodes
US8064446B2 (en) 2007-08-24 2011-11-22 At&T Intellectual Property I, L.P. Multicast with adaptive dual-state
WO2009092705A2 (fr) 2008-01-22 2009-07-30 Thomson Licensing Procédé d'aide à la réservation de ressources pour un réseau à commutation de paquets, et dispositif de gestion et dispositif d'aide associés
US7856024B1 (en) * 2008-12-12 2010-12-21 Tellabs San Jose, Inc. Method and apparatus for integrating routing and bridging functions
US9049617B2 (en) * 2009-09-23 2015-06-02 At&T Intellectual Property I, L.P. Signaling-less dynamic call setup and teardown by utilizing observed session state information
US8774076B2 (en) * 2011-02-04 2014-07-08 Cisco Technology, Inc. Optimizing OTV multicast traffic flow for site local receivers
US9098344B2 (en) 2011-12-27 2015-08-04 Microsoft Technology Licensing, Llc Cloud-edge topologies
US10361971B2 (en) * 2016-08-31 2019-07-23 International Business Machines Corporation Resource reservation mechanism for overlay networking
EP3491805B1 (de) * 2016-09-07 2020-10-14 Cloud of Things, Ltd System und verfahren zur konfiguration der verbindung einer angeschlossenen vorrichtung
US10862694B2 (en) 2017-03-24 2020-12-08 Oracle International Corporation System and method to provide default multicast proxy for scalable forwarding of announcements and information request intercepting in a high performance computing environment
US11968132B2 (en) 2017-03-24 2024-04-23 Oracle International Corporation System and method to use queue pair 1 for receiving multicast based announcements in multiple partitions in a high performance computing environment
US10461947B2 (en) * 2017-03-24 2019-10-29 Oracle International Corporation System and method to provide default multicast lid values per partition as additional SMA attributes in a high performance computing environment
US10560277B2 (en) 2017-03-24 2020-02-11 Oracle International Corporation System and method to provide multicast group MLID dynamic discovery on received multicast messages for relevant MGID in a high performance computing environment
US10693815B2 (en) 2017-03-24 2020-06-23 Oracle International Corporation System and method to use all incoming multicast packets as a basis for GUID to LID cache contents in a high performance computing environment
US10841199B2 (en) 2017-03-24 2020-11-17 Oracle International Corporation System and method for optimized path record handling in homogenous fabrics without host stack cooperation in a high performance computing environment
US10868686B2 (en) 2017-03-24 2020-12-15 Oracle International Corporation System and method to provide default multicast group (MCG) for announcements and discovery as extended port information in a high performance computing environment
US10868685B2 (en) 2017-03-24 2020-12-15 Oracle International Corporation System and method to provide explicit multicast local identifier assignment for per-partition default multicast local identifiers defined as subnet manager policy input in a high performance computing environment
US10601765B2 (en) 2017-03-24 2020-03-24 Oracle International Corporation System and method to provide combined IB and IP address and name resolution schemes via default IB multicast groups in a high performance computing environment

Family Cites Families (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5331637A (en) * 1993-07-30 1994-07-19 Bell Communications Research, Inc. Multicast routing using core based trees
US5541927A (en) * 1994-08-24 1996-07-30 At&T Corp. Method of multicasting
US5583862A (en) * 1995-03-28 1996-12-10 Bay Networks, Inc. Method and apparatus for routing for virtual networks
US5608726A (en) * 1995-04-25 1997-03-04 Cabletron Systems, Inc. Network bridge with multicast forwarding table
US5802056A (en) * 1995-07-12 1998-09-01 Bay Networks, Inc. Configuration of virtual rings in a token ring local area network
US5930259A (en) * 1995-08-25 1999-07-27 Kabushiki Kaisha Toshiba Packet transmission node device realizing packet transfer scheme and control information transfer scheme using multiple virtual connections
JP3471137B2 (ja) 1995-08-25 2003-11-25 株式会社東芝 パケット送信ノード装置及びパケット転送方法
US5748736A (en) * 1996-06-14 1998-05-05 Mittra; Suvo System and method for secure group communications via multicast or broadcast
US6049546A (en) * 1996-10-15 2000-04-11 At&T Corporation System and method for performing switching in multipoint-to-multipoint multicasting
US5903559A (en) * 1996-12-20 1999-05-11 Nec Usa, Inc. Method for internet protocol switching over fast ATM cell transport
US5946316A (en) * 1997-01-17 1999-08-31 Lucent Technologies, Inc. Dynamic distributed multicast routing protocol
US5996021A (en) * 1997-05-20 1999-11-30 At&T Corp Internet protocol relay network for directly routing datagram from ingress router to egress router

Also Published As

Publication number Publication date
EP0917390A3 (de) 2001-01-17
DE69837464D1 (de) 2007-05-16
JPH11154959A (ja) 1999-06-08
JP3147164B2 (ja) 2001-03-19
US6671276B1 (en) 2003-12-30
EP0917390B1 (de) 2007-04-04
EP0917390A2 (de) 1999-05-19

Similar Documents

Publication Publication Date Title
DE69837464T2 (de) Vermittlungsnetzaufbau für IP-Mehrfachsendung und für integrierte Dienste
DE69816845T9 (de) Mehrere zusammenarbeitende gebiete innerhalb einer netz durchgangseinheit
DE69938570T2 (de) Verfahren und Vorrichtung für eine reservierte und dynamische Dienstqualität in einem Kommunikationsnetz
DE69828112T2 (de) Rahmenrelaisgeschalteter Datendienst
DE69735691T2 (de) Verwaltung von virtuellen ATM-Verbindungen mit Protokoll zur Reservierung von Ressourcen
DE69737342T2 (de) Internet-NCP(Netzwerksteuerungspunkt) über ATM
DE69838126T2 (de) Verkehrsverwaltung für geschalteten Frame Relay Datendienst
DE60109809T2 (de) Verfahren und system für betriebsmittelreservierungen in einem multicast-netzwerk
DE69734258T2 (de) Anordnung und Verfahren zur hierarchischen Mehrfachsende-Leitweglenkung in einem ATM-Netz
DE60035969T2 (de) Verfahren und Anordnung zur Behandlung der Informationpakete durch vom Nutzer auswählbare Relaisknoten
DE69727930T2 (de) Zusammenfassung von verbindungen in vermittlungskommunikationsnetzen
Katsube et al. Toshiba's router architecture extensions for ATM: Overview
DE69919569T2 (de) Verwaltung von verbindungsorientierten diensten über das internet-protokoll
DE60017622T2 (de) Auf RSVP-basiertes Tunnelprotokoll zum Bereitstellen von integrierten Diensten
EP1128605B1 (de) Vorrichtung zur Mehrfachübertragung von Paketen
DE60119461T2 (de) Verfahren zur Bereitstellung einer bidirektionellen Verbindung in einem Netz für die Mehrfachübertragung von Datenströmen mit Verwendung vom Internetprotokoll und Netz für die Anwendung des Verfahrens
DE69727692T2 (de) Atm verteilnetz
DE60122831T2 (de) Verteilter Virtueller Router mit Redundanz für Netzwerken mit ändernder Topologie
DE60315496T2 (de) Parallelzugriff auf Daten über ein Paketnetzwerk
DE60035836T2 (de) Dynamische Burst-Zusammenstellung basiert auf voll/teilweis gemeinsame Mehrfachübertragungsentitäten
DE60319724T2 (de) Verfahren und vorrichtung zur bereitstellung von multicast-fähigkeit in einem atm-netzwerk
WO2001054448A1 (de) Verfahren und vorrichtung zur zugangssteuerung eines kommunikationsnetzes
DE69838965T2 (de) Paketvermittlungsnetzwerk, Paketvermittlungseinrichtung und Netzwerkmanagementeinrichtung
Salgarelli et al. Supporting IP multicast integrated services in ATM networks
Bagwell et al. A comparison of native ATM-multicast to IP-multicast with emphasis on mapping between the two

Legal Events

Date Code Title Description
8364 No opposition during term of opposition