DE10209048A1 - Verfahren zur Signalisierung von Diensteanforderungen in heterogenen Netzen - Google Patents

Verfahren zur Signalisierung von Diensteanforderungen in heterogenen Netzen

Info

Publication number
DE10209048A1
DE10209048A1 DE10209048A DE10209048A DE10209048A1 DE 10209048 A1 DE10209048 A1 DE 10209048A1 DE 10209048 A DE10209048 A DE 10209048A DE 10209048 A DE10209048 A DE 10209048A DE 10209048 A1 DE10209048 A1 DE 10209048A1
Authority
DE
Germany
Prior art keywords
network
block
die
der
und
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.)
Withdrawn
Application number
DE10209048A
Other languages
English (en)
Inventor
Karl Schrodi
Christian Winkler
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.)
Nokia Solutions and Networks GmbH and Co KG
Original Assignee
Siemens AG
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 Siemens AG filed Critical Siemens AG
Priority to DE10209048A priority Critical patent/DE10209048A1/de
Priority to PCT/DE2003/000609 priority patent/WO2003075518A1/de
Priority to EP03714659A priority patent/EP1481516A1/de
Publication of DE10209048A1 publication Critical patent/DE10209048A1/de
Withdrawn legal-status Critical Current

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00Traffic control in data switching networks
    • H04L47/70Admission control; Resource allocation
    • H04L47/78Architectures of resource allocation
    • H04L47/783Distributed allocation of resources, e.g. bandwidth brokers
    • H04L47/785Distributed allocation of resources, e.g. bandwidth brokers among multiple network domains, e.g. multilateral agreements
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00Traffic control in data switching networks
    • H04L47/10Flow control; Congestion control
    • H04L47/15Flow control; Congestion control in relation to multipoint traffic
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00Traffic control in data switching networks
    • H04L47/10Flow control; Congestion control
    • H04L47/18End to end
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00Traffic control in data switching networks
    • H04L47/70Admission control; Resource allocation
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00Traffic control in data switching networks
    • H04L47/70Admission control; Resource allocation
    • H04L47/72Admission control; Resource allocation using reservation actions during connection setup
    • H04L47/724Admission control; Resource allocation using reservation actions during connection setup at intermediate nodes, e.g. resource reservation protocol [RSVP]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00Traffic control in data switching networks
    • H04L47/70Admission control; Resource allocation
    • H04L47/80Actions related to the user profile or the type of traffic
    • H04L47/801Real time traffic
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00Traffic control in data switching networks
    • H04L47/70Admission control; Resource allocation
    • H04L47/80Actions related to the user profile or the type of traffic
    • H04L47/805QOS or priority aware

Landscapes

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

Abstract

Für ein paketorientiertes, verbindungsloses, heterogenes Netz wird ein Verfahren vorgeschlagen, bei dem zur Anmeldung und Bereitstellung der erforderlichen Netzressourcen zur Sicherstellung der anwendungsspezifischen Anforderungen an die Netzdienste, wie z. B. Quality of Service, eine Anforderungsmeldung von der Quellenseite zur Senkenseite und eine Rückmeldung von der Senkenseite zur Quellenseite geschickt wird. Durch die Anforderungsmeldung, in der die Beiträge der einzelnen Netze aufsummierbar sind, sind die Netzressourcen reservierbar.

Description

  • Der Anmeldungsgegenstand betrifft ein Verfahren zum Einrichten einer verbindungslosen, paketorientierten Verbindung über verschiedene Netze hinweg.
  • In zukünftigen "konvergierten" Kommunikationsnetzen ("Next Generation Networks", NGNs), die sowohl klassische und neue Telekommunikationsanwendungen (angefangen bei Telefonie- und Video(konferenz)kommunikation bis hin zu echten Multimediaanwendungen) als auch traditionelle und zukünftige Datendienste (vom File-Transfer über Email, Web-Surfing, e-Commerce bis hin zu "Electronic Infotainment") unterstützen sollen, müssen geeignete Signalisierverfahren zur Anmeldung und Bereitstellung der erforderlichen Netzressourcen zur Sicherstellung der anwendungsspezifischen Anforderungen an die Netzdienste, z. B. bez. einer Quality of Service (QoS) oder einer entsprechenden Zuverlässigkeit und Verfügbarkeit der Dienste aus der Sicht des Nutzers, eingesetzt werden.
  • Dabei sind (neben einigen anderen) die folgenden wesentlichen Randbedingungen zu berücksichtigen:
    NGNs werden auf der Internet-Protokoll-Technik (IP) aufsetzen, d. h. der Informationstransport erfolgt in Paketform und a priori verbindungslos unter vorteilhafter Ausnutzung des statistischen Verkehrsverhaltens der paketorientierten Informationsübertragung.
  • Die Architektur der Netze trennt ganz klar zwischen der Steuerung der Dienste und Anwendungen ("Service Control") sowie dem Informationstransport ("Network Control"). Auf der Ebene der Service Control werden die (Ende-zu-Ende-)Beziehungen zwischen den Nutzern und die Vereinbarungen über Art, Umfang und Eigenschaften etc. des bzw. der in Anspruch zu nehmenden Services bearbeitet. Auf der Network-Ebene erfolgt der eigentliche Transport der im Rahmen des/der Services auszutauschenden (Nutz-)Information. Die notwendigen (Steuer-)Informationen zur Bestimmung der dazu erforderlichen Ressourcen und Einstellungen des Netzes werden über eine Signalisierung ausgetauscht. Da die vom Netz unabhängige Service Control die Netzstruktur und die möglichen Wege durch das Netz nicht kennt, ist dafür auch eine "horizontale" Signalisierung zwischen Netzknoten und ggf. benachbarten Teilnetzen erforderlich.
  • Im Rahmen der zunehmenden Globalisierung bei gleichzeitiger massiver Deregulierung der nationalen und regionalen Märkte ist mit einer verstärkten Heterogenität der Netze zu rechnen. Neben der soeben angesprochenen Aufteilung der vertikal übereinander liegenden Aufgaben von Netz-, Service- und Anwendungssteuerung wird auch im horizontalen Bereich Wettbewerb und damit verbunden eine Differenzierung zwischen verschiedenen Netzbetreibern stattfinden. Ein einfaches Beispiel für die sich daraus ergebende Architektur zeigt Fig. 1. Bieten zwei Netzbetreiber divergierende Netzdienste (siehe Definition am Ende des Textes) an, so muß für einen Übergang entweder eine geeignete Abbildung zwischen den jeweiligen verschiedenartigen Netzdiensten vereinbart werden oder es muß die ursprüngliche Anforderungsdefinition bereitgestellt werden, um jeweils individuell einen geeigneten Netzdienst auswählen zu können. Ggf. kann dabei auch eine zusätzliche Information über den in den bis dahin durchlaufenen Teilnetzen bereits eingebuchten (und damit verbrauchten) Anteil an verschiedenen Budgets (z. B. packet loss oder delay) hilfreich oder sogar notwendig sein.
    • A) In den klassischen Telefonnetzen gibt es meist nur einen einheitlichen (Basis-)Netzdienst, der sich z. B. im ISDN auf die Bereitstellung eines sog. B-Kanals (64 kbit/s Übertragungskapazität) abbilden läßt. Auch die Eigenschaften darauf aufbauender Varianten (z. B. durch Kanalbündelung) sind netzweit einheitlich standardisiert. Solche standardisierte "well known network services" können über verschiedenen Teilnetze hinweg einheitlich signalisiert und direkt angefordert und genutzt werden. Eine weitere Vereinfachung bei der Nutzung solcher Dienste ergibt sich aus der Einheit von Netz- und Service-Steuerung, die in jedem Netzknoten integriert bereitgestellt und auch genutzt werden. Eine Diensteanforderung wird dann von Knoten zu Knoten weitergegeben, wobei jeder Knoten die erforderlichen Netz-Ressourcen bereitstellt.
    • B) Auch im Bereich der ATM-Technik (Asynchronous Transfer Mode), deren Entwicklung mit dem Ziel einer Erweiterung des ISDN hin zu einem breitbandigen und multimediafähigen B-ISDN vorangetrieben wurde, gilt die integrierte Bereitstellung von Netz- und Service-Steuerung. Ein Satz von "well known network services" (im Wesentlichen sind das CBR, VBR, ABR, UBR und GFR) mit durch die Standardisierung festgelegten Eigenschaften steht zur Auswahl und kann über die Signalisierung direkt angefordert werden. Da über den Netzdienst Eigenschaften, wie z. B. die QoS, bereits bestimmt sind, muß daneben nur noch eine (ebenfalls standardisierte) Beschreibung des angelieferten Verkehrs (z. B. durch Parameter wie Peak Rate und Sustainable Rate im Falle von VBR) mitgegeben werden. (Die Vorgaben bez. der QoS gelten natürlich nur dann, wenn gewisse Randbedingungen, z. B. bez. der maximalen Anzahl durchlaufener Knoten etc., eingehalten werden.)
    • C) Für IP-basierte Netze gibt es aus den Aktivitäten der Internet Engineering Task Force (IETF) eine Reihe von Ansätzen, die auf eine mögliche Bereitstellung von QoS hinzielen.
      • a) Der am weitesten gehende Ansatz (und somit wohl der für diese Erfindungsmeldung nächstliegende Stand der Technik) ist das Konzept der "Integrated Services" (IntServ). Das zugehörige Signalisierverfahren basiert auf dem "Resource Reservation Protocol" (RSVP, RFC 2205 und RFC 2210 ff.)) und arbeitet nach dem folgenden Grundprinzip:
        Am Ausgangspunkt einer Kommunikationsbeziehung (Sender) wird eine "Path Message" losgeschickt, die quasi den Weg durch das Netz erkunden soll. Sie enthält eine Beschreibung des von dem Sender zu generierenden Verkehrs (Sender TSpec) und einen Bereich (RSVP ADSpec), in den die durchlaufenen Teilnetze und Netzknoten Information über ihre Eigenschaften und Fähigkeiten, die für die Behandlung des zu erwartenden Datenstromes von Bedeutung sein könnten, eintragen. Nach der Ankunft der Path Message an der Datensenke (Receiver), erstellt der Receiver mit Hilfe dieser Informationen eine RSVP FlowSpec, die nun in einer "Reservation Message" entlang des erkundeten Pfades durch das Netz zurück zum Sender geschickt wird und dabei entsprechende Ressourcen reserviert und den Pfad für die Nutzung einstellt.
        Dieses Verfahren ist sehr universell, aber auch immens aufwendig, da es versucht, jeder nur denkbaren Eventualität im Netz Rechnung zu tragen und aus einem Gesamtbild eine entsprechende Reservierungsstrategie abzuleiten. Die hohe Komplexität führt zu einer sehr eingeschränkten Skalierbarkeit und damit auch nur einer beschränkten Nutzbarkeit.
      • b) Der "Differentiated Services" Ansatz (DiffServ, s. z. B. RFCs 2474 und 2475) beschränkt sich auf eine einfache Markierung der Datenpakete entsprechend ihrer Zugehörigkeit zu einer Verkehrsklasse. Damit kann die Klassenzugehörigkeit über die Grenzen von Netzdomänen hinweg (d. h. zwischen verschiedenen Teilnetzen) signalisiert werden und eine unterschiedliche ("differenzierte") Behandlung der Datenpakete verschiedener Verkehrsklassen in den einzelnen Netzknoten (dargestellt durch sog. "Per Hop Behaviours" z. B. RFCs 2597, 2598) vorgenommen werden. Aussagen über gewünschte oder tatsächlich erzielbare Ende-zu-Ende-Eigenschaften in komplexen Netzen sind bei diesem Vorgehen in der Regel aber nicht möglich.
      • c) MPLS (s. z. B. RFC3031) wird häufig im Zusammenhang mit QoS und Zuverlässigkeit von Netzen zitiert. Es verwendet fest eingestellte Pfade, die über ein sog. "Label Distribution Protocol" (LDP) avisiert werden. Ein solches Protokoll kann natürlich auch zur Signalisierung weitergehender Anforderungen (z. B. in Bezug auf QoS etc.) verwendet werden. In diesem Zusammenhang wird sehr häufig eine Erweiterung von RSVP mit Einschluß der Label Distribution vorgeschlagen (s. auch RFCs 3209, 3210). Damit erbt ein MPLS-Anwender aber neben dem Verlust der Vorteile des freien Routens (Einschränkung auf feste Pfade) zusätzlich auch noch die Komplexität und die Skalierbarkeitsprobleme des IntServ-Konzeptes.
  • Alle genannten Ansätze adressieren mehr oder weniger nur eine Teilproblematik der komplexen NGN-Signalisierungsaufgabe und zeigen deshalb auch nur Lösungen für die jeweiligen Teilbereiche auf. Der einzige umfassende Ansatz, RSVP, disqualifiziert sich aufgrund seiner hohen Komplexität und der damit verbundenen Probleme im praktischen Einsatz selbst. Eine brauchbare Lösung, die der Gesamtproblematik (auch über das reine Thema der QoS hinaus) gerecht wird und unter den verschiedenartigen möglichen Randbedingungen einer NGN- Implementierung sinnvoll und wirtschaftlich einsetzbar ist, ist derzeit offenbar nicht bekannt.
  • Ein einfacher Lösungsansatz ergäbe sich natürlich unter der Annahme der ausschließlichen Verwendung global standardisierter und verfügbarer "well known network services" (vgl. oben "ATM"). Ein Zustandekommen einer entsprechenden Vereinbarung muß aber mit zunehmendem Wettbewerb zwischen den Betreibern (Deregulierung) und auch verschiedenen Standardisierungsgremien als eher unwahrscheinlich angesehen werden.
  • Dem Anmeldungsgegenstand liegt das Problem zugrunde, für ein paketorientiertes, verbindungsloses Kommunikationsnetz ein Verfahren zur Anmeldung und Bereitstellung der erforderlichen Netzressourcen zur Sicherstellung der anwenderspezifischen Anforderungen an die gewünschten Netzdienste, z. B. bezüglich einer Quality of Service (QoS) oder einer Zuverlässigkeit und Verfügbarkeit der Dienste, zur Verfügung zu stellen.
  • Das Problem durch die Merkmale des kennzeichnenden Teils des Anspruchs 1 gelöst.
  • Mit dem Anmeldungsgenestand verbundene Vorteile:
    • - Die Signalisierung beinhaltet nicht nur eine Verkehrsbeschreibung, sondern explizit und konkret die Anforderungen der Verkehrsquelle z. B. in Bezug auf QoS und/oder Reliability des angeforderten Dienstes.
    • - Die Signalisierung enthält zusätzlich optional eine Network Service-Spezifikation/Anforderung mit entweder globaler (netzweit) oder lokaler (nur am aktuellen Peering Point) Bedeutung.
    • - Optionale Auswertung der konkreten Anforderungen auch dann, wenn eine Network Service-Spezifikation zur Anforderung eines konkret definierten Netzdienstes vorliegt (Möglichkeit eines "Overrun").
    • - Gleichzeitiges Reservieren der Ressourcen und Prüfen der Einhaltung der verschiedenen Netzbudgets (z. B. bez. packet loss, delay oder delay variation) in einem einzigen Netzdurchlauf.
    • - Optionaler modularer Aufbau der Anforderungsmeldung erlaubt freie Auswahl und Zusammenstellung der Inhalte.
    • - Einfache Grundstruktur und modularer Aufbau ermöglichen eine Vielzahl von Varianten bez. des Gesamtablaufes einer Reservierung bzw. Ablehnung.
  • Weitere Vorteile:
    • - Das Verfahren reduziert den Aufwand für die Signalisierung von Anforderungen und die Reservierung geeigneter Netzressourcen auf ein Minimum und erlaubt dabei eine zuverlässige Prüfung des Einhaltens der Anforderungen.
    • - Das Verfahren ist unabhängig von spezifischen Eigenschaften einzelner Teilnetze und ohne besondere Voraussetzungen in beliebigen, heterogen aufgebauten NGNs einsetzbar.
    • - Durch die explizite Signalisierung der Anforderungen kann in jedem Teilnetz der optimale (sowohl bez. Erfüllung der reinen Anforderungen als auch bez. Wirtschaftlichkeit) Netzdienst gewählt werden.
    • - Die Option, einen (global oder lokal) "vereinbarten" Netzdienst zu wählen, erleichtert sowohl die Standardisierung als auch das Peering zwischen Teilnetzen.
    • - Für eine erfolgreiche Reservierung ist in jeder betroffenen Netzinstanz nur ein komplexer Vorgang notwendig (bei RSVP sind es zwei: Erkunden im Vorwärtsdurchlauf und Reservieren im Rückwärtsdurchlauf).
    • - Ein erfolgreicher Wegeaufbau kann schnell abgewickelt werden (ein Durchlauf, eine direkte Quittung). Bei Nichterfolg kann die zusätzliche Verzögerung durch den Wiederabbau als eine Art implizite Überlastabwehr zur Verzögerung einer erneuten Anfrage genutzt werden. (Geringe Effizienz-Einbussen bez. der Auslastung, bedingt durch "Reservierung vor Freigabe", müssen bei allen Reservierungsverfahren in Kauf genommen werden.)
    • - Die zeitliche Koinzidenz von Anfrage und Reservierung garantiert die Verfügbarkeit der "erkundeten" Wegeeigenschaften.
    • - Das "Aufsammeln" der Wegeeigenschaften gibt größtmögliche Freiheit bez. der in den Teilnetzen verwendeten Mechanismen und Technologien und ermöglicht dennoch eine sehr gute Einschätzung des Erreichens oder Nichterreichens der Anforderungen.
  • Der vorgeschlagene Ansatz kann nicht nur für die Signalisierung von QoS-Anforderungen sondern auch für oder in Kombination mit Anforderungen jedweder sonstigen Art, z. B. bez. Zuverlässigkeit und Verfügbarkeit der angeforderten Netzdienstleistung, eingesetzt werden.
  • Der Anmeldungsgegenstand wird im folgenden als Ausführungsbeispiel in einem zum Verständnis erforderlichen Umfang anhand einer Figur näher erläutert.
  • Das Signalisierverfahren weist zwei Schritte auf. Im ersten Schritt wird eine Anforderungsmeldung von der Quellenseite zur Senkenseite geschickt. Im zweiten Schritt wird entweder eine Bestätigung oder eine Ablehnung zur Quellenseite zurückgeschickt. Das Verfahren unterstützt unidirektionale Datenflüsse, da in IP-Netzen davon ausgegangen werden muß, daß hin- und zurücklaufender Verkehr einer bidirektionalen Kommunikationsbeziehung nicht notwendigerweise denselben Weg nimmt. Für bidirektionale Kommunikationsbeziehungen ist das Verfahren für jede Richtung separat anzuwenden.
  • Die Anforderungsmeldung hat ihren Ursprung entweder bei der Quelle selbst oder bei einem für diese tätigen Agenten oder Proxy. In jedem Falle passiert sie das Zugangsnetz, an das die Quelle angeschlossen ist, und marschiert dann durch eines oder mehrere der verschiedene Teilnetze des Gesamtnetzes zum Zugangsnetz der Senke und endet schließlich entweder in der Senke selbst oder einem für diese tätigen Agenten oder Proxy. Im Falle der Verwendung von Agenten oder Proxies ist ein zusätzlicher Informationsaustausch zwischen Quelle bzw. Senke und der jeweils für diese zuständigen Instanz notwendig, der aber nicht Gegenstand dieser Erfindungsmeldung sein soll. Die Anforderungsmeldung beinhaltet in einem ersten Informationsblock (Block 1) eine Beschreibung des von der Quelle zu senden beabsichtigten Verkehrs (z. B. Bandbreiteninformation, Variabilität/Burstiness, etc. (vgl. z. B. RSVP TSpec)) und zusätzlich in einem zweiten Informationsblock (Block 2) eine genaue Beschreibung verschiedener konkreter Anforderungen/Randbedingungen, die auf dem Weg durch das Netz erfüllt/eingehalten werden müssen. Dazu können z. B. gehören:
    • - Grenzwerte für QoS-Parameter wie packet loss, packet delay oder packet delay variation,
    • - Grenzwerte für die Wahrscheinlichkeit, daß der Informationsfluß (für längere Zeit) unterbrochen wird bzw. abbricht und/oder ein Grenzwert für eine maximal zulässige Unterbrechungszeit des Informationsflusses,
    • - die Zulässigkeit oder Nicht-Zulässigkeit einer Reihenfolgevertauschung der Datenpakete (packet reordering) und/oder Grenzwerte für den zulässigen Umfang eines Reorderings,
    • - . . .
  • In einem sehr einfachen Beispiel könnte z. B. im Block 1 nur ein Bandbreitenwert (z. B. ein Mittel- oder Spitzenwert) und im Block 2 nur eine maximal zulässige Paketverzögerung stehen. Selbstverständlich kann der Block 2 auch leer bleiben, wenn keine weiteren Anforderungen gestellt werden oder diese durch den dritten Informationsblock (s. u.) abgedeckt sind. In einem dritten Informationsblock (Block 3) kann von der Quelle bzw. deren Agent oder Proxy ein konkreter, netzweit spezifizierter Netzdienst ("well known network service") angefordert werden, falls ein solcher existiert und gewünscht wird. Ist dies nicht der Fall, so bleibt dieser Block (zunächst) leer. In diesem Falle (also wann immer dieser Block leer ist) kann Block 3 an den Übergängen zwischen verschiedenen Netzdomänen (Teilnetzen, auch Zugangsnetze sind Teilnetze!) zur Anforderung von zwischen diesen Teilnetzen (lokal) vereinbarten Netzdiensten benutzt werden. Die Prozedur läuft dann so ab, daß das in Flußrichtung der Anforderungsmeldung erste Teilnetz einen mit dem zweiten Teilnetz vereinbarten und zu den Anforderungen in den Blöcken 1 und 2 passenden Netzdienst (der nur zwischen diesen beiden Gültigkeit haben muß) auswählt und in die Anforderungsmeldung einträgt und diese an das zweite Teilnetz weitergibt. Das zweite Teilnetz wertet die Information aus, nimmt die erforderlichen Reservierungen und Einstellungen vor, löscht den Block 3 der Anforderungsmeldung und verfährt am Übergang zum dritten Teilnetz wieder entsprechend der beschriebenen Regel. Optional kann aber auch ein direktes Mapping der empfangenen Netzdienst-Anforderung auf einen mit dem nachfolgenden Teilnetz vereinbarten Netzdienst erfolgen. Bei nicht identischen Netzdienst-Spezifikationen besteht dabei jedoch die Gefahr eines "Aufschaukelns", d. h. eines Aufsteigens zu immer höherwertigen Diensten, da der Dienst im nächsten Teilnetz keine schlechteren Eigenschaften haben sollte als der lokal genutzte.
  • Als weitere Option kann in jedem Teilnetz unabhängig vom Vorhandensein einer brauchbaren Block-3-Information eine Auswertung der Block-2-Information (soweit vorhanden) vorgenommen werden. Ist diese aussagekräftig genug, so kann auf dieser Basis der in diesem Teilnetz zu verwendende (lokal oder global spezifizierte) Netzdienst ausgewählt werden. In speziellen Fällen (Option) kann dabei auch von dem ggf. in Block 3 avisierten Netzdienst abgewichen werden ("Overrun"). Die Auswertung der Block-2-Information ist dann verpflichtend, wenn keine gültige oder brauchbare Block-3-Information verfügbar ist. Als Grundannahme wird davon ausgegangen, daß die Block- 1-Information immer ausgewertet wird.
  • Ein vierter Informationsblock (Block 4) dient dem Aufsammeln von Information über den Verbrauch' der im Block 2 vorgegebenen "Anforderungsbudgetst". Als einfaches Beispiel können hier z. B. die erwarteten (maximalen) Delays in den durchlaufenen Teilnetzen aufsummiert und gegen den in Block 2 angegebenen Grenzwert geprüft werden. (Alternativ könnten auch die Einzelwerte jedes Teilnetzes einfach nur eingetragen werden und an einer anderen (zentralen) Stelle zur Überprüfung gegenüber den Anforderungen ausgewertet werden.) Diese "Konformitätsprüfung" ist erforderlich, weil die einzelnen Teilnetze unabhängig voneinander und mit völlig unterschiedlichen Mechanismen und auch unterschiedlich spezifizierten Netzdiensten arbeiten können. Nur bei der durchgehenden Verfügbarkeit und Verwendung eines "well known network service" kann evt. darauf verzichtet werden, wenn dieser entsprechend umfassend und ausreichend genau spezifiziert ist. Zusätzlich kann in diesem Block auch Information über die gewählte Route eingetragen werden, falls diese nicht eindeutig vorbestimmt ist.
  • Die Reihenfolge der Blöcke bzw. die generelle Anordnung der Informationselemente in der Anforderungsmeldung kann natürlich beliebig festgelegt werden. Sind die Blöcke durch entsprechende Kennzeichnung individuell eindeutig identifizierbar, so müssen nur die einzelnen Blöcke standardisiert werden und die Anforderungsmeldung kann daraus praktisch frei und modular aufgebaut bzw. zusammengestellt werden ("Options- Prinzip"). Dabei müssen nur die im Einzelfall wirklich notwendigen Blöcke eingebaut werden. Alternativ könnte natürlich auch die Gesamtstruktur der Meldung fest vereinbart (standardisiert) werden.
  • Erreicht die Anforderungsmeldung die zuständige Instanz auf der Senkenseite (Senke oder deren Agent/Proxy) und liegen die aufgesammelten "Verbrauchswerte" im Block 4 im zulässigen Rahmen gemäß Block 2 so wird eine Bestätigungsmeldung an die anfordernde Instanz auf der Quellenseite zurückgeschickt, woraufhin das Senden des Informationsflusses freigegeben werden kann. Die Bestätigungsmeldung enthält ggf. auch die im Block 4 der Anforderungsmeldung aufgesammelte Routeninformation. Die Bestätigungsmeldung kann einen beliebigen Weg zu ihrem Ziel nehmen.
  • Übersteigen die aufgesammelten Verbrauchswerte den zulässigen Rahmen so wird eine Ablehnungsmeldung zurückgeschickt. Die Ablehnungsmeldung enthält ggf. Teile der oder auch die gesamte im Block 4 der Anforderungsmeldung aufgesammelte Information, Damit ergeben sich die folgenden Hauptvarianten:
    • A) Die Ablehnungsmeldung wird "entlang des Anforderungspfades" zurückgeschickt. Dabei werden die reservierten Ressourcen Schritt für Schritt wieder freigegeben.
    • B) Die Ablehnungsmeldung wird auf einem beliebigen Weg zurückgeschickt. Die anfordernde Instanz kann dann entweder
      • a) das Angebot zu den gegenüber der Anforderung schlechteren Bedingungen annehmen und den Informationsfluß freigeben oder
      • b) die Ablehnung für diesen Versuch akzeptieren. In diesem Falle muß die anfordernde Instanz unverzüglich eine Releaseanforderung entlang dem immer noch reservierten Pfad senden, um die blockierten Ressourcen wieder freizugeben.
  • Auch während des Durchlaufes der Anforderungsmeldung durch das Netz kann ggf. bereits ein Mangel an Ressourcen, die Nichtverfügbarkeit eines passenden Netzdienstes oder das Überschreiten der Anforderungsspezifikation festgestellt werden. In einem solchen Fall kann (optional) von der feststellenden Instanz sofort eine "vorzeitige Ablehnung" entlang des bisher reservierten Pfades zurückgeschickt werden. Mit der "vorzeitigen Ablehnung" werden alle reservierten Ressourcen wieder freigegeben. (Anmerkung: Nicht alle Kombinationen zwischen den möglichen Ablehnungsstrategien und den Optionen der "vorzeitigen Ablehnung" sind sinnvoll.)
  • Selbstverständlich bleibt es im Falle einer Ablehnung (bzw. Akzeptanz einer Ablehnung gem. II. b), s. oben) der anfragenden Instanz freigestellt, einen weiteren Versuch mit denselben oder modifizierten Anforderungen zu starten.
  • Grundsätzlich wird die Anforderungsmeldung einen Meldungskopf beinhalten, der sie eindeutig identifiziert und von anderen Meldungen unterscheidet. In diesem Kopf können auch grundlegende Informationen übertragen werden. Die nachfolgenden "Blöcke" werden zur Unterscheidung und Abgrenzung ebenfalls exakt markiert.
  • Block 1 ist "mandatory", die übrigen sind optional.
  • Die Inhalte und Darstellungen der Blöcke 1, 2 und 4 bedürfen einer Standardisierung Block 3 beinhaltet im einfachsten Fall nur eine Nummer (z. B. codiert in 7 oder 8 Bit). Die Nummer 5 würde dann den mit der Kennnummer 5 vereinbarten Netzdienst spezifizieren. Ein zusätzlicher Informationsträger (Bit oder Byte) könnte anzeigen, ob es sich um einen globalen oder einen nur lokal vereinbarten Netzdienst handelt, falls diese Information nicht schon implizit in der Kennnummer enthalten wäre.
  • Ein Netzdienst legt bestimmte Eigenschaften für den Transport von Paketen durch ein Netz fest. Diese Eigenschaften werden vom Netz (statistisch, mit einer bestimmten Wahrscheinlichkeit) garantiert. Zu den die Eigenschaften beschreibenden Parametern eines Netzdienstes können neben den üblichen QoS Parametern wie Verzögerung oder Verlust auch die Angabe der Zuverlässigkeit oder die Verfügbarkeit (Blockierungswahrscheinlichkeit) des Netzdienstes gehören. Die von einem Netz angebotenen Netzdienste können im Prinzip in den Grenzen der technischen Möglichkeiten des Netzes frei spezifiziert werden. Mögliche Einflussparameter bei einer zweckmäßigen Festlegung reichen von den Anforderungen der zu übertragenden Anwendungsklassen bis hin zu geschäftlichen und tariflichen Überlegungen des Betreibers.
  • Beispiel für einen Satz von Netzdiensten, der die gängigen Anwendungen abdeckt:
    • 1. Emergency Network Control (ENC) - Netz-interner Steuerungsverkehr (z. B. Signalisierung)
    • 2. Interactive Real-Time (IRT) - Interaktive Realzeitkommunikation (z. B. Videokonferenzen)
    • 3. Non-Interactive Real-Time (NIRT) - nicht-interaktive Realzeitkommunikation (z. B. Videoabruf)
    • 4. Transactional and Signalling (TAS) - transaktionsorientierte Anwendungen (z. B. E-Commerce)
    • 5. Best Effort (BE) - Klassischer Datenverkehr ohne besondere Anforderungen (z. B. WWW)

Claims (7)

1. Verfahren zum Einrichten einer verbindungslosen, paketorientierten Verbindung über verschiedene Netze hinweg, wobei eine Anforderungsmeldung, in der mehrere Blöcke aufnehmbar sind, von der Quellenseite zur Senkenseite geschickt wird, in dem ersten Block der Anforderungsmeldung eine Beschreibung des von der Quelle zu senden beabsichtigten Verkehrs aufnehmbar ist und eine Rückmeldung von der Senkenseite zur Quellenseite geschickt wird.
2. Verfahren nach Anspruch 1 dadurch gekennzeichnet, dass ein zweiter Block der Anforderungsmeldung eine Beschreibung der auf dem Weg einzuhaltenden Anforderungen aufweist.
3. Verfahren nach Anspruch 2 dadurch gekennzeichnet, dass in einem dritten Block ein spezifischer Netzdienst anforderbar ist.
4. Verfahren nach Anspruch 2 oder 3 dadurch gekennzeichnet, dass in einem vierten Block die im zweiten Block vorgegebenen Anforderungen akkumulierbar sind.
5. Verfahren nach einem der Ansprüche 2 bis 4 dadurch gekennzeichnet, dass in einem fünften Block Informationen über die gewählte Route ablegbar sind.
6. Verfahren nach einem der vorstehenden Ansprüche dadurch gekennzeichnet, dass in einem Block die Vergebührungs-/charging-Informationen der einzelnen Netze akkumulierbar sind.
7. Verfahren nach einem der vorstehenden Ansprüche dadurch gekennzeichnet, dass die Anforderungsmeldung vor Erreichen der Senkeseite an die Quellenseite zurückgesandt wird, wenn eine in der Anforderungsmeldung vorgegebene Anforderung nicht erfüllt ist.
DE10209048A 2002-03-01 2002-03-01 Verfahren zur Signalisierung von Diensteanforderungen in heterogenen Netzen Withdrawn DE10209048A1 (de)

Priority Applications (3)

Application Number Priority Date Filing Date Title
DE10209048A DE10209048A1 (de) 2002-03-01 2002-03-01 Verfahren zur Signalisierung von Diensteanforderungen in heterogenen Netzen
PCT/DE2003/000609 WO2003075518A1 (de) 2002-03-01 2003-02-26 Verfahren zur signalisierung von diensteanforderungen in heterogenen netzen
EP03714659A EP1481516A1 (de) 2002-03-01 2003-02-26 Verfahren zur signalisierung von diensteanforderungen in heterogenen netzen

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
DE10209048A DE10209048A1 (de) 2002-03-01 2002-03-01 Verfahren zur Signalisierung von Diensteanforderungen in heterogenen Netzen

Publications (1)

Publication Number Publication Date
DE10209048A1 true DE10209048A1 (de) 2003-09-18

Family

ID=27762573

Family Applications (1)

Application Number Title Priority Date Filing Date
DE10209048A Withdrawn DE10209048A1 (de) 2002-03-01 2002-03-01 Verfahren zur Signalisierung von Diensteanforderungen in heterogenen Netzen

Country Status (3)

Country Link
EP (1) EP1481516A1 (de)
DE (1) DE10209048A1 (de)
WO (1) WO2003075518A1 (de)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102016119080A1 (de) 2016-10-07 2018-04-12 Condias Gmbh Vorrichtung zum elektrochemischen Behandeln von Abwasser

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR100703770B1 (ko) 2005-03-25 2007-04-06 삼성전자주식회사 가중 예측을 이용한 비디오 코딩 및 디코딩 방법, 이를위한 장치

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO1999023799A1 (en) * 1997-11-03 1999-05-14 British Telecommunications Public Limited Company Packet network
DE10038878C1 (de) * 2000-08-09 2002-01-10 Siemens Ag Verfahren zum Aufbau einer Verbindung mit vorgegebener Dienstgüte zwischen Kommunikationsnetzen mit Resourcenmanagern

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102016119080A1 (de) 2016-10-07 2018-04-12 Condias Gmbh Vorrichtung zum elektrochemischen Behandeln von Abwasser

Also Published As

Publication number Publication date
WO2003075518A1 (de) 2003-09-12
EP1481516A1 (de) 2004-12-01

Similar Documents

Publication Publication Date Title
DE60109809T2 (de) Verfahren und system für betriebsmittelreservierungen in einem multicast-netzwerk
DE69916747T2 (de) Verfahren zur Bereitstellung von Dienstgüte in IP-Netzwerken für verzögerungsempfindliche Verkehr
DE60102367T2 (de) Netzoptimierungsmethode
DE60117476T2 (de) Bidirektionales Reservierungsprotokoll
DE60017622T2 (de) Auf RSVP-basiertes Tunnelprotokoll zum Bereitstellen von integrierten Diensten
DE69919569T2 (de) Verwaltung von verbindungsorientierten diensten über das internet-protokoll
DE60032669T2 (de) Vorrichtung und Verfahren zur Bandbreitenüberwachung
DE60221261T2 (de) Verfahren und anordnung in einem ip-netzwerk
DE60112089T2 (de) Verfahren und system zur verwaltung der dienstqualität durch einspeisen von informationen in das paketnetz
DE60031435T2 (de) Dienstgütebezogene Herstellung einer Kommunikationssitzung in einem Kommunikationssystem
EP1451980B1 (de) Verfahren zur uebertragung von daten von applikationen mit unterschiedlicher qualität
DE60130114T2 (de) Anwendungsbeeinflusste richtlinie
DE60120354T2 (de) Rsvp-verarbeitung in 3g-netzwerken
DE102004008376B4 (de) Verfahren und System zum Schaffen einer garantierten Qualität des Dienstes in einem IP-Netz
DE102006022046B4 (de) Verfahren zum Ermöglichen einer Steuerung der Dienstqualität und/oder der Dienstvergebührung bei Telekommunikationsdiensten
EP1428361B1 (de) Verkehrsbegrenzung mittels zulässigkeitsprüfung für ein paketorientiertes verbindungsloses netz mit qos niveau übertragung
DE102006012655B4 (de) Verfahren zum Bereitstellen einer Dienstqualität in einem WiMAX-Kommunikationsnetzwerk und Verfahren zum Auswählen einer Zugangs-Transportressourcenkontrollfunktion durch eine Richtlinienentscheidungsfunktion in einem Kommunikationsnetzwerk
EP1398907B1 (de) Verfahren zur Kontrolle von Übertragungsressourcen eines paketorientierten Kommunikationsnetzes bei Topologieänderungen
DE60217728T2 (de) Planung von einem verteilten betriebsmittel zwischen synchronen und asynchronen paketflüssen
EP1249154B1 (de) Verfahren und vorrichtung zur zugangssteuerung eines kommunikationsnetzes
DE10100609A1 (de) Verfahren zum Vergebühren bei der Datenübertragung, zugehörige Einheiten, Zugehöriges Programm und elektronischer Gutschein
EP1665676B1 (de) Verfahren zur laststeuerung in einem paketdatennetz
DE10209048A1 (de) Verfahren zur Signalisierung von Diensteanforderungen in heterogenen Netzen
EP1266496B1 (de) Verfahren und anordnung zur zulässigkeitsprüfung einer dienstnutzung
EP1374627B1 (de) Verfahren und system zum effizienten verwalten von ressourcen in mpls netzwerken

Legal Events

Date Code Title Description
8127 New person/name/address of the applicant

Owner name: NOKIA SIEMENS NETWORKS GMBH & CO.KG, 81541 MUE, DE

8141 Disposal/no request for examination