-
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)