DE60203539T2 - Mehrfach-domain-zugriffsregelung von datenflüssen in assoziation mit dienstqualitätskriterien - Google Patents

Mehrfach-domain-zugriffsregelung von datenflüssen in assoziation mit dienstqualitätskriterien Download PDF

Info

Publication number
DE60203539T2
DE60203539T2 DE60203539T DE60203539T DE60203539T2 DE 60203539 T2 DE60203539 T2 DE 60203539T2 DE 60203539 T DE60203539 T DE 60203539T DE 60203539 T DE60203539 T DE 60203539T DE 60203539 T2 DE60203539 T2 DE 60203539T2
Authority
DE
Germany
Prior art keywords
quality
domain
service
access controller
exit
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 - Fee Related
Application number
DE60203539T
Other languages
English (en)
Other versions
DE60203539D1 (de
Inventor
Alban Couturier
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.)
Alcatel Lucent SAS
Original Assignee
Alcatel SA
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 Alcatel SA filed Critical Alcatel SA
Publication of DE60203539D1 publication Critical patent/DE60203539D1/de
Application granted granted Critical
Publication of DE60203539T2 publication Critical patent/DE60203539T2/de
Anticipated expiration legal-status Critical
Expired - Fee Related legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/24—Traffic characterised by specific attributes, e.g. priority or QoS
    • H04L47/2408—Traffic characterised by specific attributes, e.g. priority or QoS for supporting different services, e.g. a differentiated services [DiffServ] type of service
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/24—Traffic characterised by specific attributes, e.g. priority or QoS
    • H04L47/2491—Mapping quality of service [QoS] requirements between different 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/76—Admission control; Resource allocation using dynamic resource allocation, e.g. in-call renegotiation requested by the user or requested by the network in response to changing network conditions
    • H04L47/762—Admission control; Resource allocation using dynamic resource allocation, e.g. in-call renegotiation requested by the user or requested by the network in response to changing network conditions triggered by the network
    • 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/781—Centralised allocation of resources
    • 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
    • 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/805—QOS or priority aware
    • 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/822—Collecting or measuring resource availability data
    • 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/825—Involving tunnels, e.g. MPLS

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Quality & Reliability (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Radio Relay Systems (AREA)

Description

  • Die vorliegende Erfindung betrifft das Management der Dienstgüte in einem Datennetz. Sie findet insbesondere auf Datennetze Anwendung, die aus mehreren Domains gebildet werden und dadurch die Bereitstellung unterschiedlicher Dienste wie die Übertragung von Sprache, Daten, Video usw. ermöglichen. Ein solches Netz kann zum Beispiel ein auf den Protokollen der Familie TCP/IP ("Transport Control Protocol/Internet Protocol") basierendes Netz sein, das heißt es entspricht dem Typ, der allgemein als Internet bezeichnet wird.
  • Bestimmte Dienste erfordern eine ausdrückliche Reservierung von Ressourcen innerhalb des Netzes.
  • Tatsächlich waren bestimmte Netze wie das Internet dafür vorgesehen, Daten zu transportieren, jedoch keine Sprache und auch nicht Videosignale. Im Internet erfolgen Übertragungen in Form von Paketen, wobei jedes Paket unabhängig von den anderen befördert wird. Nun erfordert aber zum Beispiel die Übertragung von Sprache und Videosignalen, die Paketverlustrate sowie die Übertragungsverzögerung zu minimieren, um einen ausreichenden Hör- oder Sehkomfort für die Empfänger der Übertragung zu gewährleisten.
  • Diese Minimierung von Jitter und Verzögerung erfolgt klassischerweise durch die Reservierung von Ressourcen in den Netzknoten (oder Routern).
  • Klassischerweise überträgt das Endgerät, das eine bestimmte Dienstgüte für einen bestimmten Datenfluss wünscht, eine Dienstgüte-Anforderung, bevor die diesem Datenfluss entsprechenden Pakete gesendet werden.
  • Im weiteren Verlauf ist unter Datenfluss ein Mikrofluss ("Microflow") zu verstehen, das heißt eine Gruppe von Paketen, die klassischerweise durch ein 5-Tupel charakterisiert sind: das verwendete Protokoll, die Adresse und den Port des Senders sowie die Adresse und den Port des Empfängers.
  • Im Allgemeinen ist diese Dienstgüte-Anforderung eine Anforderung zur Ressourcenreservierung, zum Beispiel in Übereinstimmung mit dem RSVP-Protokoll (für "ReSerVation Protocol"), wie es im RFC ("Request For Comments") 2205 der IETF ("Internet Engineering Task Force") definiert ist.
  • Nach diesem RSVP-Protokoll muss jeder Router, der eine Anforderung zur Ressourcenreservierung erhält, zunächst überprüfen, ob er über die geforderten Ressourcen verfügt, und die Anforderung nach den klassischen Leitweglenkungsalgorithmen weiterleiten. Die Anforderung zur Ressourcenreservierung legt auf diese Weise den Weg zurück, dem normalerweise die Pakete des Datenflusses bis zum Empfänger folgen würden. Dieser überträgt daraufhin eine Antwort an den ursprünglichen Sender, die den Weg zum Ursprung zurück nimmt. Bei diesem zweiten Durchlauf muss jeder Router tatsächlich die geforderten Ressourcen reservieren.
  • Dieses Protokoll weist einen bedeutenden Nachteil insofern auf, als für jede an ein Netz gerichtete Dienstgüte-Anforderung die Reservierung von Ressourcen auf einer großen Router-Gruppe erforderlich ist und in der Praxis die Aufrechterhaltung eines Verarbeitungskontextes innerhalb des Routers.
  • Dieser Nachteil wird durch die DiffServ- ("Differentiated Services model") Architektur aufgehoben, wie sie im RFC 2475 der IETF ("Internet Engineering Task Force") definiert ist.
  • Nach dieser Architektur werden Dienstgüte-Anforderungen dadurch realisiert, dass Prioritäten, die in diesem Zusammenhang als "Farben" bezeichnet werden, jedem Paket des Datenflusses zugewiesen werden. Die Router, welche auf diese Weise "gefärbte" Pakete (das heißt, denen eine Priorität zugewiesen wurde) empfangen, müssen diese vorrangig behandeln.
  • Allerdings ergänzen sich diese beiden Lösungen, sodass die Lösungen nach dem bisherigen Stand der Technik beide Protokolle gleichzeitig anwenden können, um von ihren jeweiligen Vorteilen zu profitieren.
  • Ein Anwendungsbeispiel einer solchen Lösung nach dem bisherigen Stand der Technik ist in 1 dargestellt. Ein solcher Stand der Technik wird zum Beispiel im RFC 2998 unter dem Titel "A Framework for Integrated Services Operation over Diffserv Networks" beschrieben und wurde im November 2000 von der IETF verabschiedet.
  • Ein Endgerät T1 ist mit einer Domain N1 verbunden, welche die Router R1, R2 und R3 enthält. Ein Endgerät T2 ist mit einer Domain N2 verbunden, welche die Router R4, R5 und R6 enthält.
  • Wenn das Endgerät T1 einen Datenfluss, der eine bestimmte Dienstgüte erfordert, an das Endgerät T2 übertragen will (zum Beispiel eine Multimedia-Sitzung, die eine Mindestübertragungsrate benötigt), sendet es eine Anforderung zur Ressourcenreservierung gemäß dem RSVP-Protokoll.
  • Diese Anforderung zur Ressourcenreservierung wird empfangen und danach vom Router R1 verarbeitet. Er überprüft, ob er tatsächlich über ausreichende interne Ressourcen verfügt (das heißt einen Wert der abgehenden Übertragungsrate, der größer ist als ein von der Anforderung zur Ressourcenreservierung spezifizierter Schwellenwert).
  • Gegebenenfalls wird die Anforderung zur Ressourcenreservierung an den nächsten Router weitergeleitet, der sie verarbeiten kann, und zwar bis zur Grenze des DiffServ-Netzes. Die Antwort kommt klassischerweise an den Router R1 zurück, der sie an das Endgerät T1 weiterleiten kann und diesem dadurch mitteilt, dass die Ressourcenreservierung tatsächlich durchgeführt wurde.
  • Das Endgerät T1 überträgt daraufhin die Pakete des Datenflusses zum Empfänger-Endgerät T2.
  • Bei ihrem Empfang weist der Router R1 ihnen eine Priorität in Abhängigkeit von der zuvor erhaltenen Anforderung zur Ressourcenreservierung zu.
  • Wie zuvor gesagt, entspricht diese Prioritätszuweisung klassischerweise der DiffServ-Architektur.
  • Die Pakete, welche Priorität haben, werden daraufhin innerhalb der Domain N1 und danach der Domain N2 weitergeleitet, wobei sie die Router R1, R3, R4 und R6 durchlaufen. Jeder dieser Router verarbeitet die Pakete in Abhängigkeit von den ihnen zugewiesenen Prioritäten.
  • Diese Lösung nach dem bisherigen Stand der Technik weist ein größeres Problem auf, da die Überprüfung der verfügbaren Ressourcen nur vom ersten Router R1 durchgeführt wird. Daher kann, wenn zwei Dienstgüte-Anforderungen auf zwei verschiedenen Grenz-Routern initiiert werden, zum Beispiel den Routern R1 und R2 oder R1 und R5, dazu führen, dass der Umstand, dass ein anderer Router diese Dienstgüte nicht erfüllen kann, möglicherweise nicht erkannt wird. Den beiden Dienstgüte-Anforderungen wird dann stattgegeben, obwohl eine von beiden oder sogar beide nicht erfüllt werden können.
  • Ein anderes Beispiel ist in dem Dokument XP001075719 beschrieben.
  • Ziel der Erfindung ist es, dieses Problem zu lösen, insbesondere für den Fall, dass mehrere Domains betroffen sind.
  • Hierzu schlägt die Erfindung vor, die Funktion zur Überprüfung der verfügbaren Ressourcen auf eine einzige Vorrichtung zu verlagern, die als Zugangs-Controller bezeichnet wird.
  • Genauer gesagt, ist der Gegenstand der Erfindung ein Zugangs-Controller zu einer Domain eines Datennetzes, wobei diese Domain eine Gruppe von Routern besitzt. Der Zugangs-Controller ist dadurch gekennzeichnet, dass er besitzt:
    • • Empfangsvorrichtungen, um eine Dienstgüte-Anforderung zu empfangen, enthaltend Informationen über den Eintrittspunkt des mit dieser Dienstgüte-Anforderungen verbundenen Paketflusses in die Domain;
    • • Vorrichtungen zur Bestimmung eines Austrittspunktes, welcher der Dienstgüte-Anforderung entspricht;
    • • Vorrichtungen zur Übertragung einer modifizierten Dienstgüte-Anforderung an den Zugangs-Controller, welcher der zum Austrittspunkt gehörenden Austritts-Domain zugeordnet ist, indem darin Informationen über den Eintrittspunkt des Paketflusses in die Austritts-Domain eingefügt werden.
  • Nach einer Anwendung der Erfindung umfasst der Zugangs-Controller außerdem Überprüfungsvorrichtungen, um festzustellen, ob die Dienstgüte-Anforderung von der Domain erfüllt werden kann.
  • Diese Feststellung kann zum Beispiel in Abhängigkeit von Kenntnissen der in der Domain verwendeten Ressourcen oder nach einer makroskopischen Heuristik durchgeführt werden.
  • Indem alle Dienstgüte-Anforderungen, die an eine Domain gerichtet sind, bei einem einzigen Zugangs-Controller zentral zusammengefasst werden, ist dieser in der Lage, die Nutzung zu kennen, denen die Ressourcen der Domain unterliegen, und somit den Dienstgüte-Anforderungen stattzugeben oder nicht, ohne die weiter oben angesprochenen Probleme nach dem bisherigen Stand der Technik zu verursachen.
  • Die Zugangs-Controller der verschiedenen Domains können untereinander Informationen über die Dienstgüte-Anforderungen austauschen. Insbesondere übertragen sie untereinander Informationen über den Eintrittspunkt der mit den Dienstgüte-Anforderungen verbundenen Paketflüsse, um die Leitwegwahl dieser Datenflüsse bestimmen zu können.
  • Die Erfindung und ihre Vorteile werden in der nachfolgenden Beschreibung in Verbindung mit den beigefügten Abbildungen klarer ersichtlich werden.
  • 1, die bereits kommentiert wurde, stellt den Stand der Technik auf dem Gebiet der Zugangskontrolle in einem aus mehreren Domains gebildeten Netz dar.
  • 2 veranschaulicht eine Ausführungsform der Erfindung unter Einsatz zentraler Zugangs-Controller.
  • Auf dem Beispiel von 2 möchte das Endgerät T1 eine Multimedia-Sitzung mit dem Endgerät T2 initiieren. Das Endgerät T1 ist mit einer Domain N1 und das Endgerät T2 mit einer Domain N2 verbunden.
  • Die Multimedia-Sitzung benötigt eine bestimmte Dienstgüte. Das Endgerät T1 überträgt daher eine Dienstgüte-Anforderung m1 an den Router R1, mit dem es verbunden ist.
  • Diese Dienstgüte-Anforderung m1 stimmt typischerweise mit dem RSVP-Protokoll überein.
  • Es ist jedoch wichtig, darauf hinzuweisen, dass die Erfindung auch im Rahmen eines reinen "DiffServ"-Netzes implementiert werden kann.
  • Gemäß dieser Erfindung fängt dieser Router (oder jede andere Einrichtung) R1 diese Dienstgüte-Anforderung ab und überträgt sie an den Zugangs-Controller AC1 in Form einer Meldung m2. Diese Dienstgüte-Anforderung m2 kann zum Beispiel mit dem COPS-Protokoll übereinstimmen, wie es vom RFC 2748 unter dem Titel "The COPS (Common Open Policy Service)" definiert ist, der von der IETF im Januar 2000 verabschiedet wurde.
  • Der Router R1 kann darin Informationen zu ihrer Charakterisierung einfügen, das heißt zum Beispiel ihre IP- ("Internet Protocol") Adresse, doch im allgemeinen Fall verfügt der Zugangs-Controller AC1 über ausreichende Kenntnisse, um diese Informationen selbst der Dienstgüte-Anforderung zuzuweisen.
  • Der Zugangs-Controller AC1 ist der Domain N1 zugeordnet.
  • Er verfügt über Empfangsvorrichtungen, um diese Dienstgüte-Anforderung m2 zu empfangen und um Informationen über den Eintrittspunkt des Paketflusses zur Kenntnis zu nehmen, der mit der Dienstgüte-Anforderung in der Domain N1 verbunden ist. Er kann auf diese Weise wissen, dass dieser Datenfluss am Router R1 angekommen ist.
  • Der Zugangs-Controller AC1 verfügt über Vorrichtungen zur Bestimmung eines Austrittspunkts des Paketflusses, welcher dieser Dienstgüte-Anforderung entspricht. Diese Bestimmungsvorrichtungen können die Kenntnis der internen Ressourcen der Domain N1 umfassen und insbesondere der Topologie der Router, aus denen sie sich zusammensetzt.
  • Anhand der Kenntnis dieser Topologie sowie der Eintrittspunkte der Dienstgüte-Anforderung kann der Zugangs-Controller AC1 den entsprechenden Austrittspunkt bestimmen. Hierzu kann er einfach eine Leitwegbestimmung anwenden, indem er Router für Router den jeweils nächsten Router sucht. Dies kann so durchgeführt werden, dass die Ziel-IP- ("Internet Protocol") Adresse des Paketflusses anhand der Routing-Tabellen der Router aufgelöst wird, die sich der Controller mit der Netztopologie beschafft hat. Er kann den Austritt auch bestimmen, indem er alle Routing-Informationen des BGP ("Border Gateway Protocol") kennt, die zwischen den Grenz-Routern ("Border Routers") der Domain im Umlauf sind.
  • Im Fall eines Netzes, welches so konfiguriert ist, dass es von einem Rand zum anderen reichende Vermittlungspfade darstellt, beispielsweise vom Typ des Multi-Protocol Label Switching (MLPS), wird nur die Kenntnis des Vermittlungspfades (oder des "Label Switch Path" nach der korrekten Terminologie des MPLS-Mechanismus) benötigt, um den Austritt zur bestimmen. Hierzu muss der Zugangs-Controller die Routing-Tabelle und die Regeln zur Bestimmung des Label Switch Paths im Router kennen.
  • Anhand der Kenntnis dieses Austrittspunktes kann er einerseits die Austritts-Domain bestimmen und andererseits den Eintrittspunkt in diese Austritts-Domain. In dem Beispiel von 2 ist die Austritts-Domain die Domain N2, und der Eintrittspunkt gehört zum Router R4.
  • Der Eintrittspunkt in die Austritts-Domain ist durch die Kennung des Eintritts-Routers, R3, gekennzeichnet (zum Beispiel seine IP-Adresse). Gemäß der verwendeten Dienstgüte- (QoS-) Architektur kann er zusätzlich durch die Kennung des Routers gekennzeichnet sein, durch eine Information über die Ebene 1 oder 2 im Sinne des OSI-Modells ("Open Systems Interconnection"), zum Beispiel eine Kennung der physischen Karte, der virtuellen ATM-Schaltung, ein MPLS- ("Multi-Protocol Label Switching") Label usw.
  • Diese Informationen über den Eintrittspunkt in die Austritts-Domain werden in eine modifizierte Dienstgüte-Anforderung m3 eingefügt, die an den Zugangs-Controller AC1 übertragen wird, welcher der Austritts-Domain N2 zugeordnet ist.
  • Der Zugangs-Controller AC2 empfängt folglich eine Dienstgüte-Anforderung m3, die den Eintrittspunkt in diese Domain enthält. Er kann somit ihren Austrittspunkt bestimmen.
  • Für den Fall, dass der Datenfluss, der die Multimedia-Sitzung transportiert, eine größere Zahl von Domains durchqueren sollte, würde die Dienstgüte-Anforderung auf diese Weise von Zugangs-Controller zu Zugangs-Controller übertragen.
  • Nach einer Anwendung der Erfindung können die Zugangs-Controller (oder ein Teil von ihnen) außerdem Überprüfungsvorrichtungen umfassen, um festzustellen, ob die Dienstgüte-Anforderung von der ihr zugeordneten Domain erfüllt werden kann.
  • Nach einer ersten Ausführungsform kann diese Feststellung in Abhängigkeit von den Kenntnissen über die in der Domain verwendeten Ressourcen erfolgen. Diese internen Ressourcen können von einem Netzmanagementsystem geliefert werden. Sie können insbesondere die Bandbreiten der Verbindungen (oder einen Teil der Verbindungen) zwischen den Routern umfassen, aus denen die Domain aufgebaut ist.
  • Nach einer zweiten Ausführungsform kann diese Feststellung nach einer makroskopischen Heuristik erfolgen. Diese Heuristik kann einfach darin bestehen, zu überlegen, ob die Domain eine vordefinierte Anzahl von Dienstgüte-Anforderungen erfüllen kann. Die Feststellung besteht in diesem Fall darin, einfach die Anzahl der empfangenen (und noch gültigen) Dienstgüte-Anforderungen zu zählen und zu überprüfen, ob diese Anzahl innerhalb der zuvor definierten Anzahl bleibt.
  • Wenn ein Zugangs-Controller feststellt, dass die Dienstgüte-Anforderung nicht erfüllt werden kann, kann er ihre Weiterleitung zum nächsten Zugangs-Controller stoppen. Damit nämlich die gewünschte Dienstgüte erreicht wird, müssen alle durchquerten Domains die Dienstgüte-Anforderung erfüllen können.
  • Er kann daraufhin eine Antwortmeldung an den Zugangs-Controller senden, der ihm die Dienstgüte-Anforderung übermittelt hat, um ihm die Nichterfüllung der Dienstgüte-Anforderung mitzuteilen.
  • Letzterer kann daraufhin eine andere Domain wählen, um den Paketfluss erfolgreich bis zum Empfänger zu leiten.
  • Für den Fall, dass alle Zugangs-Controller der Kette entscheiden, dass die ihnen entsprechende Domain die Dienstgüte-Anforderung erfüllen kann, übermittelt der letzte in der Kette an den vorhergehenden Zugangs-Controller eine Antwortmeldung, in der die Erfüllung dieser Dienstgüte-Anforderung mitgeteilt wird.
  • Diese Antwortmeldung wird in entgegengesetzter Richtung zur Dienstgüte-Anforderung bis zum ersten Zugangs-Controller weiterverbreitet und danach bis zu dem Router, an dem diese Dienstgüte-Anforderung angekommen ist.
  • Dieser Router hat dann die Versicherung, dass die vom Endgerät geforderte Dienstgüte bis zum Ziel-Endgerät (oder den Ziel-Endgeräten) erfüllt werden kann. Er kann daraufhin die Übertragung des Datenflusses genehmigen, welcher der Multimedia-Sitzung entspricht.

Claims (4)

  1. Zugangs-Controller (AC1, AC2) zu einer Domain (N1, N2) eines Datennetzes, wobei diese Domain eine Gruppe von Routern (R1, R2, ... R5) besitzt, dadurch gekennzeichnet, dass er besitzt: – Empfangsvorrichtungen, um alle für diese Domain bestimmten Dienstgüte-Anforderungen (m2) zu empfangen, wobei jede Dienstgüte-Anforderung Informationen über den Eintrittspunkt des mit dieser Dienstgüte-Anforderung verbundenen Paketflusses in die Domain enthält; – Vorrichtungen zur Bestimmung eines Austrittspunkts, welcher dieser Dienstgüte-Anforderung entspricht; – Vorrichtungen zur Übertragung einer modifizierten Dienstgüte-Anforderung (m3) an den Zugangs-Controller, welcher der zum Austrittspunkt gehörenden Austritts-Domain zugeordnet ist, indem darin Informationen über den Eintrittspunkt des Paketflusses in die Austritts-Domain eingefügt werden.
  2. Zugangs-Controller nach Anspruch 1, außerdem umfassend Überprüfungsvorrichtungen, um festzustellen, ob die Dienstgüte-Anforderung von der Domain erfüllt werden kann.
  3. Zugangs-Controller nach dem vorhergehenden Anspruch, bei dem diese Feststellung in Abhängigkeit von Kenntnissen der in der Domain verwendeten Ressourcen durchgeführt wird.
  4. Zugangs-Controller nach dem Anspruch 2, bei dem diese Feststellung nach einer makroskopischen Heuristik durchgeführt wird.
DE60203539T 2001-11-29 2002-11-25 Mehrfach-domain-zugriffsregelung von datenflüssen in assoziation mit dienstqualitätskriterien Expired - Fee Related DE60203539T2 (de)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
FR0115430 2001-11-29
FR0115430A FR2832890B1 (fr) 2001-11-29 2001-11-29 Controle multi-domaine d'admission de flux de donnees associes a des criteres de qualite de service
PCT/FR2002/004028 WO2003047185A1 (fr) 2001-11-29 2002-11-25 Controle multi-domaine d'admission de flux de donnees associes a des criteres de qualite de service

Publications (2)

Publication Number Publication Date
DE60203539D1 DE60203539D1 (de) 2005-05-04
DE60203539T2 true DE60203539T2 (de) 2006-02-02

Family

ID=8869908

Family Applications (1)

Application Number Title Priority Date Filing Date
DE60203539T Expired - Fee Related DE60203539T2 (de) 2001-11-29 2002-11-25 Mehrfach-domain-zugriffsregelung von datenflüssen in assoziation mit dienstqualitätskriterien

Country Status (8)

Country Link
US (1) US20050044218A1 (de)
EP (1) EP1451987B1 (de)
CN (1) CN100341300C (de)
AT (1) ATE292350T1 (de)
DE (1) DE60203539T2 (de)
ES (1) ES2238639T3 (de)
FR (1) FR2832890B1 (de)
WO (1) WO2003047185A1 (de)

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7684322B2 (en) 2004-07-01 2010-03-23 Nortel Networks Limited Flow admission control in an IP network
US9419893B2 (en) * 2013-11-11 2016-08-16 Futurewei Technologies, Inc. Traffic engineering resource collection and coordination
CN113015210B (zh) * 2019-12-19 2022-11-29 中国电信股份有限公司 服务质量管控方法和系统

Family Cites Families (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6119235A (en) * 1997-05-27 2000-09-12 Ukiah Software, Inc. Method and apparatus for quality of service management
US6134589A (en) * 1997-06-16 2000-10-17 Telefonaktiebolaget Lm Ericsson Dynamic quality control network routing
US20010012271A1 (en) * 1997-08-04 2001-08-09 Arthur W. Berger Improved acknowledgement of bandwidth requests for the block transfer of data
FI107505B (fi) * 1999-02-16 2001-08-15 Nokia Networks Oy Pääsynvalvontamenetelmä
US6678264B1 (en) * 1999-06-30 2004-01-13 Nortel Networks Limited Establishing connections with a pre-specified quality of service across a communication network
US7054938B2 (en) * 2000-02-10 2006-05-30 Telefonaktiebolaget Lm Ericsson (Publ) Method and apparatus for network service reservations over wireless access networks
JP3617406B2 (ja) * 2000-03-30 2005-02-02 日本電気株式会社 マルチドメインに対応した品質保証型通信サービス提供方式およびサービス提供方法並びにサービス仲介装置
ATE262244T1 (de) * 2000-04-13 2004-04-15 Operax Ab Netzoptimierungsmethode
US20020087699A1 (en) * 2000-07-31 2002-07-04 Telefonaktiebolaget Lm Ericsson (Publ) Dynamic QoS management in differentiated services using bandwidth brokers, RSVP aggregation and load control protocols
US20040136379A1 (en) * 2001-03-13 2004-07-15 Liao Raymond R Method and apparatus for allocation of resources

Also Published As

Publication number Publication date
DE60203539D1 (de) 2005-05-04
EP1451987A1 (de) 2004-09-01
ATE292350T1 (de) 2005-04-15
CN100341300C (zh) 2007-10-03
US20050044218A1 (en) 2005-02-24
FR2832890A1 (fr) 2003-05-30
WO2003047185A1 (fr) 2003-06-05
CN1600004A (zh) 2005-03-23
WO2003047185A8 (fr) 2005-04-07
FR2832890B1 (fr) 2004-02-27
ES2238639T3 (es) 2005-09-01
EP1451987B1 (de) 2005-03-30

Similar Documents

Publication Publication Date Title
DE69938570T2 (de) Verfahren und Vorrichtung für eine reservierte und dynamische Dienstqualität in einem Kommunikationsnetz
DE69916747T2 (de) Verfahren zur Bereitstellung von Dienstgüte in IP-Netzwerken für verzögerungsempfindliche Verkehr
DE60100478T2 (de) IP Plattform für verbesserte Mehrpunkt-Zugriffsysteme
DE19983404B4 (de) Verfahren und Vorrichtung zur Verwendung bei der Einstellung eines TCP Gleitfensters
DE60037368T2 (de) Verfahren und Architektur zur Unterstüzung von mehreren Diensten in einem Etikettvermittlungsnetzwerk
DE60034654T2 (de) System und Verfahren zur Adaption und Verwaltung von IP Dienstqualität
DE69811622T2 (de) Verfahren und Vorrichtung zur Bandbreitenverwaltung in einem Datenübertragungsnetz
EP1428408A2 (de) Verteilte übermittlung von informationen in einem verbindungslosen, paketorientierten kommunikationsnetz
EP1428361B1 (de) Verkehrsbegrenzung mittels zulässigkeitsprüfung für ein paketorientiertes verbindungsloses netz mit qos niveau übertragung
EP2638672A1 (de) Verfahren zum erhöhen der qualität der datenübertragung in einem paketbasierten kommunikationsnetz
EP1629642B1 (de) Verfahren für eine Verkehrsverteilung mittels Hash-Codes entsprechend einer Soll-Verkehrsverteilung in einem paketorientierten Netz mit Mehrwege-Routing
DE60209096T2 (de) Schnelles Pfadwiederherstellungsverfahren in Label-Vermittlungsnetzwerken und Netzwerkanordnung zur Ausführung des Verfahrens
EP1133112A2 (de) Verfahren zum Verteilen einer Datenverkehrslast eines Kommunikationsnetzes und Kommunikationsnetz zur Realisierung des Verfahrens
EP1249154B1 (de) Verfahren und vorrichtung zur zugangssteuerung eines kommunikationsnetzes
WO2004032428A2 (de) Verfahren zur teilweisen erhaltung der paketreihenfolge bei verbindungsloser paketvermittlung mit alternativem routing
DE60203539T2 (de) Mehrfach-domain-zugriffsregelung von datenflüssen in assoziation mit dienstqualitätskriterien
DE10045205A1 (de) Verfahren zum Aufbau von Verbindungen mit vorgegebener Dienstgüte für ein paketorientiertes Kommunikationsnetz mit einem Resourcenmanager
DE60302865T2 (de) Bandbreitenmakler für ein Telekommunikationssystem
DE602006000136T2 (de) Vorreservierung von Ressourcen für Verbindungswege in einem Kommunikationsnetz an Kommunikation von Anschriften von Päckchen oder von Etiketten
EP1757049A1 (de) Verfahren zur ressourcen-reservierung für ein inter-domain-routing mit dienstgütemerkmalen
EP1319287B1 (de) Verfahren zum aufbau von verbindungen mit garantierter dienstgüte für ein kommunikationsnetz mit einem resourcenmanager
EP1374627A1 (de) Verfahren und system zum effizienten verwalten von ressourcen in mpls netzwerken
WO2004107675A2 (de) Verfahren zur weitergabe von ip-paketen an eine externe steuerkomponente eines netzknotens in einem mehrere netzknoten aufweisenden ip-pakete vermittelnden kommunikationsnetz
WO2004002061A1 (de) KOMMUNIKATIONSNETZWERK UND BETRIEBSVERFAHREN FüR DIESES
DE10237336A1 (de) Verfahren zur Übertragung von einem oder mehreren Datenströmen in einem Datennetz

Legal Events

Date Code Title Description
8364 No opposition during term of opposition
8327 Change in the person/name/address of the patent owner

Owner name: ALCATEL LUCENT, PARIS, FR

8339 Ceased/non-payment of the annual fee