DE69925505T2

DE69925505T2 - Kommunikationsnetz

Info

Publication number: DE69925505T2
Application number: DE69925505T
Authority: DE
Inventors: Ian Brighton JONES; Neuv Ngo
Original assignee: British Telecommunications PLC
Current assignee: British Telecommunications PLC
Priority date: 1998-12-09
Filing date: 1999-11-17
Publication date: 2006-01-26
Anticipated expiration: 2019-11-18
Also published as: EP1135964B1; US7805508B1; DE69925505D1; WO2000035238A1; EP1135964A1

Description

HINTERGRUND DER ERFINDUNG
Die vorliegende Erfindung bezieht sich auf ein Kommunikationsnetz, und insbesondere auf ein leitungsvermitteltes Netz, wie etwa ein ATM(Asynchroner Übertragungsmodus, Asynchronous Transfer Mode)-Netz.
Herkömmlich haben paketbasierte Protokolle, wie etwa das Internet-protokoll (IP, Internet Protocol), auf Basis des besten Bemühens gearbeitet. Als Ergebnis hat die Dienstqualität, die durch solche Parameter wie etwa Paketverlust und Latenzzeit gemessen wurde, in Abhängigkeit der Last der Netzwerkressourcen, wie etwa der Router, beträchtlich variiert. Während solche Variationen für manche Anwendungen, wie etwa E-Mail, akzeptabel sind, sind sie potenziell eine Barriere für die Verwendung des Internet-Protokolls für kritische Anwendungen, wie etwa Sprachtelefonie oder Multimediakonferenzen. Dementsprechend wurden beträchtliche Anstrengungen auf die Bereitstellung verbesserter Dienstqualität (QoS, Quality of Service) gerichtet. Ein Ansatz war, IP mit QoS-bezogenen Protokollen, wie etwa Resource reserVation Protocol (RSVP) zu ergänzen. Ein anderer Ansatz war, leitungsvermittelte Netze zu verwenden, und insbesondere ATM-Netze, um IP-Verkehr zu übertragen. Wenn ein Kundenendgerät und eine Datenquelle beide mit einem ATM-Netz verbunden sind, dann kann eine vermittelte virtuelle Leitung (SVC, Switched Virtual Circuit) verwendet werden, um von dem Endgerät zu der Quelle unter Umgehung jeglicher Zwischenrouter „durchzustoßen", und stellt ein gleichförmiges und vorhersagbares Niveau der Dienstqualität zur Verfügung. Das Aufbauen einer vermittelten virtuellen Leitung ist jedoch ein komplexer Vorgang, der das Einstellen einer Anzahl von Dienstparametern erfordert, und dies stellt trotz ihrer Vorteile eine Barriere für den weitverbreiteten Einsatz dieser Methode dar.
Die Veröffentlichung von W. Almesberger et al, „Guaranteeing Quality of Service for the Web using ATM", Data Highway, 1. Januar 1995, Seiten A21/1–A21/16 beschreibt einen Versuch, den Prozess des Aufbaus von Verbindungen über ein ATM-Netz zu automatisieren. Die Informationen, die erforderlich sind, um die Verbindung aufzubauen, sind auf das Benutzeragentenfeld, das in dem HTTP (Hypertext Transport Protocol) definiert ist, und Metadaten aufgeteilt, die mit dem HTTP-Dokument kodiert sind. Dieser komplexe Ansatz erfordert, dass zwei ATM-Verbindungen aufgebaut werden, und verschiedene Signalisierungsnachrichten ausgetauscht werden müssen. Ein solcher Verwaltungsaufwand durch Signalisierung ist nicht wünschenswert, da er die Zeit verlängert, die erforderlich ist, um das ATM-Netz zu vermitteln, und verringert folglich die Transparenz des Wechsels zwischen Netzwerken für den Benutzer. Er stellt auch zusätzliche Anforderungen an die Netzwerkressourcen.
ZUSAMMENFASSUNG DER ERFINDUNG
Nach einem ersten Aspekt der vorliegenden Erfindung wird ein für einen einheitliches Ressourcenortsbezeichnerschema mit einem einheitlichen Ressourcenortsbezeichner (URL, Uniform Resource Locator) geschaffen, wobei der einheitliche Ressourcenortsbezeichner einen Identifiziererteil für die Leitungsvermittlung, der eine Ressource als über ein leitungsvermitteltes Netz zugänglich identifiziert, einen Adressteil, der die Adresse der Ressource enthält, und einen Dienstparameterteil umfasst.
URLs stellen, wie ihr Name vermuten lässt, ein Standardsystem zur Identifizierung des Standorts von Ressourcen in einem Netzwerk, wie etwa dem Internet, zur Verfügung. Sie haben gewöhnlicherweise die Form <Schema>:<schemenabhängige Information>, wobei Schema den Typ der Ressourcen identifiziert und z. B. http oder ftp sein kein, und die schemenabhängige Information ist gewöhnlich eine Netzwerkadresse und ein Dateipfad. Indem ein URL-Schema bereitgestellt wird, das für Ressourcen auf einem leitungsvermittelten Netzwerk spezifisch ist, und indem in den URL nicht nur Adressinformationen, sondern auch Dienstparameter eingeschlossen werden, macht die vorliegende Erfindung es möglich, Leitungen in einem leitungsvermittelten Netzwerk mit viel einfacher aufzubauen, als es bisher möglich war. Die Erfindung ist besonders vorteilhaft im Kontext eines ATM-Netzes, kann aber auch auf andere Typen von Netzen, wie etwa zum Beispiel ein Frame-Relay-Netz, angewendet werden.
Nach einem zweiten Aspekt der vorliegenden Erfindung wird ein Verfahren zum Betreiben eines Endgerätes geschaffen, das direkt oder indirekt mit einem leitungsvermittelten Netz verbunden ist, wobei das Verfahren folgendes umfasst:

a) Lesen eines einheitlichen Ressourcenortsbezeichners (URL), der einen Identifiziererteil für die Leitungsvermittlung umfasst, der eine Ressource als zugänglich über ein leitungsvermitteltes Netz identifiziert, einen Adressteil, der die Adresse der Ressource umfasst, und einen Dienstparameterteil umfasst;
b) nachfolgendes Aufbauen einer Verbindung zwischen dem Endgerät des Kunden und der Ressource, wobei die Verbindung Eigenschaften hat, die wenigstens teilweise von einem oder mehreren Parametern bestimmt werden, die in dem Dienstparameterteil enthalten sind.

Vorzugsweise enthält das Verfahren das Lesen des URL von einem Server, der von dem Endgerät entfernt angeordnet ist. Obwohl der URL aus einer lokalen Quelle gelesen werden kann, wie etwa einer Lesezeichendatei eines Browsers, ist die vorliegende Erfindung besonders vorteilhaft, wenn Sie mit URLs verwendet wird, die von einem entfernt angeordneten Server an das Endgerät geliefert werden. Der Server hat im Unterschied zu dem Endgerät im allgemeinen Details über die Art der betreffenden Ressource und kann deshalb die Dienstparameter entsprechend einstellen. Wenn die Ressource zum Beispiel ein Videodatenstrom mit hoher Qualität ist, der eine Verbindung mit hoher Bandbreite erfordert, kann der Server entsprechend hohe Dienstparameter in dem URL einstellen.
Vorzugsweise wird Schritt (b) von dem Endgerät eingeleitet.
Die Erfindung umfasst auch einen Signalträger, der ein Schema eines einheitlichen Ressourcenortsbezeichners entsprechend dem ersten Aspekt der Erfindung verwendet, und Kundenendgeräte und Netzwerkserver, die dazu eingerichtet sind, die URLs nach der Erfindung zu verwenden.
BESCHREIBUNG DER ZEICHNUNGEN
Systeme, die die Erfindung ausführen, werden nun, nur als Beispiel, in weiteren Details mit Bezug auf die Zeichnung im Anhang beschrieben, in denen:
1 ein Netz zeigt, das die Erfindung ausführt;
2 ein Flussdiagramm ist;
3 eine grafische Benutzerschnittstelle (GUI, Graphic User Interface) zeigt; und
4 eine Zustandsmaschine für eine Kundenanwendung zeigt, die die Erfindung implementiert.
BESCHREIBUNG DER BEISPIELE
Wie in 1 gezeigt ist, enthält ein Kommunikationssystem ein ATM-Netz 1. Ein Kundenendgerät 2 ist über das ATM-Netz mit einem Internetdiensteanbieter (ISP, Internet Service Provider) 3 und dem öffentlichen Internet verbunden. Über das Internet kann sich das Kundenendgerät mit anderen Kundenendgeräten von Benutzern 4 und 5 und mit Datenservern 6 und 7 von Inhalteanbietern verbinden. Einer der Datenserver 6 und 7 ist auch mit dem ATM-Netz 1 verbunden.
Bei der Verwendung läuft auf dem Kundenendgerät 1 eine Anwendung, die in diesem Beispiel ein Web-Browser ist. Der Web-Browser ist modifiziert, um die Funktionalität des Windows-Sockets v2 (Win-Sock2) zu unterstützen, was ermöglicht, dass ATM-SVCs eingerichtet werden und zusätzlich zu TCP/IP oder UDP/IP-Flüssen freigegeben werden. Auf herkömmliche Weise liest der Web-Browser eine Webseite, die zum Beispiel von dem Datenserver 7 geliefert wird. Diese Webseite enthält Links zu Ressourcen, die auf dem Datenserver gespeichert sind. Diese Links können zum Beispiel URLs für mehrere MPEG-kodierte Videodateien enthalten. Diese URLs verwenden eine Implementierung des ATM-URL-Schemas nach der vorliegenden Erfindung. Das Format des ATM-URL wird unten detaillierter beschrieben. Der URL enthält die ATM-Netzwerkadresse des Servers und den Pfad auf diesem Server für die entsprechende Datei zusammen mit ATM-Dienstparametern. Wenn der Benutzer des Kundenendgeräts 1 auf einen dieser Links klickt, wird der URL von dem Server an den Web-Browser auf dem Kundenendgerät zurückgegeben. Das Kunden endgerät liest die ATM-Adresse und die Dienstparameter von dem URL, und gibt dann Signale in das ATM-Netz aus, um eine vermittelte virtuelle Leitung zu der angegebenen Adresse aufzubauen. Manche der Dienstparameter können in dem URL als benutzerdefiniert markiert sein. In diesem Fall zeigt der Web-Browser ein Fenster an (das auch das „ ATM-GUI" genannt wird), das dem Benutzer Optionen für benutzerdefinierte Einstellungen anzeigt. Der Benutzer gibt Werte in Kästen in dem Fenster ein, oder akzeptiert Standardeinstellungen, und diese Werte werden zu den Dienstparametern hinzugefügt, die schon in der URL definiert sind.
Es sei angemerkt, dass sich der HTTP-Server und der ATM-Server auf dem gleichen oder auf physikalisch separaten Rechnern befinden können.
Das allgemeine Format eines URL ist in der IETF(Internet Engineering Task Force)-Veröffentlichung RFC (Request for Comments) 1738 definiert. URLs sind als ein untergeordneter Teil von Universellen Ressourcenidentifikatoren definiert, die in der IETF-Veröffentlichung RFC 1630 definiert sind. Das Format eines URL, wie in RFC 1738 definiert, ist:
<Schema>:<Schema-abhängige Information>.
Ein URL enthält den Namen des verwendeten Schemas (<Schema>), gefolgt von einem Doppelpunkt und dann der Zeichenkette (die <Schema-abhängige Information>), deren Interpretation von den Schema abhängt. Schemata, die aktuell überall im Internet verwendet werden, umfassen „http", „gopher", „ftp" und „news" usw. Der Zweck dieser Schemata ist, den Endbenutzer und/oder die Anwendung darüber zu informieren, auf welchen Ressourcentyp versucht wird zuzugreifen, und/oder welcher Mechanismus verwendet werden soll, um diese Ressource zu erhalten. Das Format von jeder Schema-abhängigen Information beruht auf dem verwendeten Schematyp. Die Schema-abhängige Information für HTTP ist zum Beispiel von der verschieden, die von FTP verwendet wird. Jedoch bestehen die meisten Schemata aus den folgenden Informationen:

• Name und Domain des Servers, auf dem sich die Datei befindet, plus
• dem „Standort oder Pfad" zu der Datei.

Deshalb werden viele URLs für HTTP-, FTP- und Gopher-Ressourcen als
schema://server.domain/vollständiger-pfad-der-datei
angegeben, wobei das Schema von der Internetadresse des Servers durch zwei Schrägstriche vorwärts (//) und die Internetadresse von dem vollständigen Pfad der Datei durch einen einzelnen Schrägstrich vorwärts (/) getrennt ist.
Diese Ausführung der vorliegenden Erfindung verwendet ein neues URL-Schema, das als ATM-URL bezeichnet wird. In der Syntax dieses Schemas werden URLs für Ressourcen auf einem ATM-Netz durch die Zeichenkette atm://identifiziert. Die Schema-abhängige Information ist in diesem Fall von einem anderen Typ im Vergleich zu der, die bei konventionellen URL-Schemata wie den oben angegebenen verwendet werden. Die Schema-abhängige Information ist in zwei Segmente unterteilt. Die Unterteilung zwischen den zwei Segmenten ist durch ein Separatorzeichen markiert. In dieser Ausführung ist das Separator zeichen „@", obwohl das Schema alternativ mit anderen Separatorzeichen implementiert werden kann. Ein ATM-URL hat das folgende Format:
atm://ATM-Parameter@ATM-Adresse-des-Servers.Subadresse/Vollständiger-Pfad-der-Datei
In dem ersten Segment befinden sich die ATM-Parameter. Das zweite Segment enthält die Adresse des ATM-Servers. Die ATM-Parameter und die Adresse des ATM-Servers sind durch das „@"-Zeichen unterteilt. Das Format des Pfads der Datei verbleibt unverändert und ist von der Adresse des ATM-Servers durch einen einzelnen Schrägstrich vorwärts separiert. Die Adresse des ATM-Servers kann auf mehrere Weisen angegeben werden:

• Natives E.164-Adressierungsschema, wie es in der ITU-T Empfehlung E164 (Mai 1997) definiert ist
• Ein ATM-Endsystem-Adressierungs(AESA, ATM End System Addressing)-Schema
• Eine namensbasierte Adresse

Wenn eine namensbasierte Adresse verwendet wird, dann verwendet die Anwendung des Kunden einen Domain-Nameserver, um den Namen in eine entsprechende Netzwerkadresse umzuwandeln.
Die Verwendung von Unteradressierung für entweder das E.164 oder das AESA-Adressierungsschema ist in der URL optional. Dies wird erreicht, indem die Adresse des ATM-Servers und die Sub-Adresse durch das „."-Zeichen separiert werden, wodurch sich die Länge des Adressfelds des ATM-Servers vergrößert. Dieses ATM-Format ermöglicht immer noch, dass Suchzeichenketten ausgeführt werden, wie etwa, indem ein „?"-Zeichen an das Ende des Pfades der Datei angehängt wird.
Tabelle 2 unten identifiziert die ATM-Parameter, die in dem Abschnitt server.domain der ATM-URL angegeben sind. Die ATM-Parameter sind von links nach rechts kodiert. Diese ATM-Parameter stellen die Hauptinformationselemente (IEs, Information Elements) dar, die in den Signalisierungprotokollen nach ATM-F UNIv3.0, UNIv3.1, UNI v4.0, UNIv4.1 und ITU-T Q.2931 angegeben sind. Wie in Tabelle 2 gezeigt ist, kann die Länge gewisser Felder mit ATM-Parametern variieren. Um sicherzustellen, dass der Web-Browser die Informationen in dem URL zuverlässig dekodierern kann, ist jeder Parameter von einem anderen durch ein Schlüsselzeichen separiert. In dieser Ausführung wird das „."-Zeichen verwendet, um die verschiedenen ATM-Parameter in dem URL abzugrenzen. Es ist klar, dass das „."-Zeichen nicht das einzige Schlüsselzeichen ist, das verwendet werden kann. Andere Schlüsselzeichen wie etwa "@", "?", #", ":", "/" oder "\" können verwendet werden. RFC 1783 enthält mehr Informationen über die Verwendung von Schlüsselzeichen.
In dem ATM-URL ist nur ein Exemplar von jedem Feld definiert, d. h., die Felder wiederholen sich nicht. Der Grund dafür ist die Tatsache, dass die entsprechende Information nur einmal in der ATM-Signalisierungs-SETUP- oder der LEAF-SETUP-REQUEST-Nachricht vorhanden sein kann.
Die WinSock2 SPI ist für die Kodierung der ATM-Informationen im richtigen Format verantwortlich, das von dem darunter liegenden ATM-Signalisierungsprotokoll verwendet wird. Weitere Informationen bezüglich der WinSock2-Spezifikation sind in der WinSock 2.0 Spezifikation, Mai 1996, Version 2.2.0 angegeben. Die WinSock2 SPI ist für das Hinzufügen der zusätzlichen obligatorischen ATM-IEs verantwortlich, die in dem ATM-URL nicht vorhanden sind, aber von dem darunterliegenden ATM-Signalisierungsprotokoll gebraucht werden.
Die darunterliegenden Signalisierungsprotokolle sind für jegliches Zusammenwirken zwischen verschiedenen Protokollen von Signalisierungsystemen verantwortlich. Es liegt in der Verantwortung des Signalisierungsprotokolls und nicht der Anwendung (das heißt des Web-Browsers), sicherzustellen, dass die vom Benutzer ausgewählte Funktionalität vom Netz unterstützt werden kann.
Die in Tabelle 2 verwendeten Abkürzungen sind im Glossar unten aufgelistet.
Die Funktionalität und Kodierung der ATM-Parameter, die in Tabelle 2 gezeigt sind, werden nun beschrieben.
Feld mit der Version des UNI-Protokolls
Mehrere verschiedene ATM-UNI-Signalisierungsprotokolle können von dem ATM-Server und von dem Web-Browser unterstützt werden. Der ATM-URL hat ein Feld, das beschreibt, welches Protokoll oder welche Protokolle von dem ATM-Server unterstützt werden. Diese Methode führt zu weniger Problemen des Zusammenwirkens und erfolgreicheren Versuchen des Anrufaufbaus zwischen dem Web-Browser und dem/den ATM-Server(n).
Feld mit der Verbindungstopologie
Es werden drei verschiedene Verbindungstopologien, wie in UNIv3.1 und UNIv4.0/4.1 definiert, identifiziert. Diese umfassen Punkt-zu-Punkt, Punkt-zu-Mehrpunkt und Leaf Initiated Join (LIJ). Wenn der Server eine dieser Verbindungstopologien angezeigt hat, dann kann der Benutzer sie in der ATM-GUI nicht ändern. Wenn dieses Feld jedoch als „benutzerdefiniert" kodiert wird, dann kann der Benutzer irgendeine Topologie auswählen, vorausgesetzt, sie wird von dem Protokoll unterstützt.
UNIv4.0 (ATM-FORUM af-sig-0061.000) definiert zwei Typen von LIJ-Verbindungen. Diese sind als LIJ-Netzverbindungen und LIJ-Rootverbindungen bekannt. In dem vorliegenden Beispiel sollen nur LIJ-Netzverbindungen unterstützt werden.
Wie in UNIv4.0 definiert ist, ist es im Kontext einer LIJ-Verbindung das Netz, das die ATM-Parameter, wie etwa Bandbreite, QoS, Verkehrstypen usw. auswählt, und nicht das Leaf (das heißt, der Web-Browser). Wenn der ATM-URL als eine LIJ-Verbindung kodiert ist, dann sind nur manche der ATM-Parameter für den Web-Browser erforderlich. Diese ATM-Parameter enthalten

• LIJ-Anrufidentifikator;
• Adressinformation des ATM-Servers (das heißt, die Nummer der angerufenen Partei);
• ATM-Adresse des Web-Browsers (das heißt, die Nummer der anrufenden Partei).

Wie der Anrufreferenzwert wird der Wert der LIJ-Leaf-Sequenznummer von dem Signalisierungsprotokollstack des Web-Browsers erzeugt und muss deshalb nicht in der ATM-URL übertragen werden.
Feld mit dem LIJ-Anrufidentifikator
Der LIJ-Anrufidentifikator wird zusammen mit der Nummer der angerufenen Partei verwendet, um einen LIJ-Anruf an der Root-Schnittstelle eindeutig zu identifizieren. Wie in UNIv4.0 definiert ist, wird der LIJ-Anrufidentifikator als ein 32-Bit-Integer dargestellt. Gültige Werte des LIJ-Anrufidentifikators reichen deshalb von 0 bis 4294967296 (d. h. 0–2³²).
Feld mit dem AAL-Typ
Über der ATM-Schicht gibt es mehrere ATM-Anpassungsschichten, die verschiedene Funktionen unterstützen, die verwendet werden können. Dieses Beispiel ermöglicht, dass die folgenden AAL-Typen in dem ATM-URL kodiert werden:

• AAL-Typ 1 wie in ITU-T Recommendation I.363.1 definiert;
• AAL-Typ 2 wie in ITU-T Recommendation I.363.2 definiert;
• AAL-Typ 3/4 wie in ITU-T Recommendation I.363.3 definiert;
• AAL-Typ 5 wie in ITU-T Recommendation I.363.5. definiert

Der WinSock2 SPI fügt zusätzliche AAL-Informationen zu der AAL-IE hinzu, wie etwa maximale Vorwärts- und Rückwärts-CPCS-SDU-Größe, MID-Bereich und SSCS-Typ, usw. Die UNIv4.0-Spezifikation und ITU-T Empfehlung definieren eine Liste von AAL-Parametern, die für die Signalisierung zwischen zwei Einheiten auf gleicher Ebene verwendet werden.
Feld mit Funktionen des B-Kanals
Bei ATM-Verbindungen gibt es mehrere verschiedene Funktionen des B-Kanals, die in Abhängigkeit in des unterstützten Diensttyps verwendet werden können. Dieses Beispiel ermöglicht, dass die folgenden Funktionen des B-Kanals in der ATM-URL kodiert werden:

• B-Kanal Klasse BCOB-A;
• B-Kanal Klasse BCOB-C;
• B-Kanal Klasse BCOB-X;
• virtueller Pfad (VP)-Dienst

Feld mit der Dienstkategorie
ATM ermöglicht, dass mehrere Funktionen der Übertragung mit ATM (ATC, ATM Transfer Capabilities) oder Dienstkategorien angegeben werden. Tabelle 1 unten zeigt die verschiedenen ATC- oder Dienstkategorien, die von ATM-F und ITU-T unterstützt werden.
Tabelle 1 ATCs oder Dienstkategorien, die von ITU-T und ATM-F unterstützt werden
VBR-rt entspricht ITU-T SBR mit QoS der Klasse 1.
ITU-T Q.2961.1 Anhang A ermöglicht als eine Option die Unterstützung von UBR.
Verschiedene ATCs oder Dienstkategorien werden durch verschiedene Verkehrsparameter definiert. Zum Beispiel werden Definitionen, die CBR und UBR entsprechen, nur durch die Spitzenbandbreite definiert, wogegen VBR durch die Spitzen- und die aufrechterhaltbare Bandbreite plus der maximalen Größe eines Bursts (MBS, Maximum Burst Size) definiert ist.
Felder mit Spitzen- und aufrechterhaltbarer Bandbreite vorwärts und rückwärts plus Felder mit MBS
Die Werte der Spitzen- und der aufrechterhaltbaren Bandbreite (sowohl für die Vorwärts- als auch die Rückwärtsrichtung) können entweder auf „benutzerdefiniert" oder „serverdefiniert" gesetzt werden. Wenn sie als benutzerdefiniert kodiert sind, dann liegt es in der Verantwortung der Endnutzer, die gewünschten Werte dafür einzugeben. Wenn der Web-Browser feststellt, dass ein Feld als „benutzerdefi niert" kodiert ist, soll er die ATM-GUI aufrufen, die dem Benutzer ermöglicht, die geeigneten Werte einzugeben. Wenn jedoch die Werte der Vorwärts- oder Rückwärtsbandbreite als „serverdefiniert" kodiert sind, dann hat der Server vorausgewählte Werte für die geeigneten Felder für Vorwärts- und Rückwärtsbandbreite. Es ist möglich, die Werte für die Spitzen-/aufrechterhaltbare Bandbreite vorwärts als „benutzerdefiniert" zu kodieren, die Spitzen-/aufrechterhaltbare Bandbreite rückwärts jedoch als „serverdefiniert" und umgekehrt. Die gleichen Prinzipien lassen sich auf die Vorwärts- und Rückwärts-MBS anwenden.
Felder mit Vorwärts- und Rückwärts-QoS
Die Vorwärts- und Rückwärts-QoS kann entweder von dem Server oder von dem Benutzer gewählt werden. Wenn sie als „benutzerdefiniert" kodiert ist, dann soll der Benutzer über die ATM-GUI auswählen, ob die QoS-Werte richtig sind, sonst werden die QoS-Werte von dem Server gewählt. Die QoS-Klassen sind die gleichen, wie in ATM-F UNIv3.1 definiert. Deshalb stellt Klasse 1 die höchste Qualität dar, während 4 die geringste Qualität ist. Klasse 0 stellt die QoS als „nicht angegeben" dar und wird in Verbindung mit UBR verwendet. Es ist möglich, den Wert der Vorwärtsbandbreite als „benutzerdefiniert" zu kodieren, die Rückwärtsbandbreite jedoch als „serverdefiniert" und umgekehrt.
Alle ATM-Signalisierungsprotokolle, die in diesem Patent unterstützt werden, ermöglichen, dass QoS-Klassen signalisiert werden. U-NIv4.0/4.1 ermöglicht jedoch auch als eine Option für individuelle QoS-Parameter, dass Werte signalisiert werden. Deshalb kann mit dem QoS-Feld des ATM-URL die Unterstützung von individuellen QoS-Parametern angegeben werden. Es liegt jedoch in der Verantwortung des Endnutzers oder der Anwendung, die Werte für die indivi duellen QoS-Parameter bereitzustellen. In der Spezifikation von U-NIv4.0 sind mehr Informationen bezüglich der Signalisierung von individuellen QoS-Parametern angegeben.
Feld mit Markierung
Die Markierung von ATM-Zellen ist eine Funktion, die sowohl von der ATM-F UNIv4.0 als auch von der ITU-T Recommendation Q.2961.6 unterstützt wird. Die Markierung von ATM-Zellen bedeutet das Verringern der Priorität von Zellen von CLP = 0 auf CLP = 1, wenn von ihnen angenommen wird, dass sie ihren Vertrag bezüglich des Verkehrs verletzen. Es sei angemerkt, dass ATM-F UNIv4.0 und ITU-T Q.2961.6 sich in ihrem Ansatz bezüglich des Markierens unterscheiden. Das Signalisierungsprotokoll von ATM-F UNIv4.0 unterstützt lokales Markieren und verwendet Oktett 17 der IE der Breitband-B-Kanal-Funktionen (B-BC Broadband Bearer Capability), um anzuzeigen, ob Vorwärts- oder Rückwärtsmarkierung angewendet werden kann. ITU-T Q.2961.6 verwendet Oktett 17 der IE der B-BC nicht, sondern definiert zwei zusätzliche Kodepunkte der Breitband-Übertragungsfunktionen, in (Oktett 5a) der IE der B-BC, um globales Markieren zu unterstützen. Die WinSock2-SPI kodiert die Signalisierungsnachricht, um Markieren zu unterstützen, das davon abhängt, welches Signalisierungsprotokoll unterstützt wird.
Verhandlungsfeld
Die Verhandlung von ATM-Verkehrsparametern ist eine Signalisierungsfunktion, die sowohl von ATM-F- UNIv4.0 als auch von der ITU-T Empfehlung Q2962 unterstützt wird. Die ATM-Signalisierungsverhandlung ermöglicht, entweder einen Alternativen ATM-Verkehrsdeskriptor oder einen Minimal Akzeptablen ATM-Verkehrsdeskriptor anzugeben. Es sei angemerkt, dass nicht beide Werte gleichzeitig angegeben werden können. Der Benutzer kann die Werte für den Alter nativen oder den Minimal Zulässigen ATM-Verkehrsdeskriptor manuell über die ATM-GUI wählen, oder dies kann automatisch durch die Anwendung geschehen.
Modifikationsfeld
Die ITU-T Empfehlungen Q.2963.1 und Q.2963.2 ermöglichen, dass die Werte von Vorwärts- und Rückwärts-ATM-Verkehrsdeskriptoren (das heißt, die Zellenraten) während des aktiven Teil des Anrufs modifiziert werden. Diese Funktionalität ist nur in den Signalisierungprotokollen nach ITU-T verfügbar, und nicht in den ATM-F Signalisierungprotokollen. Q.2963.1 ist nur für die Verwendung in Verbindungen vom CBR-Typ vorgesehen, wogegen Q.2963.2 für die Verwendung in Verbindungen vom VBR-Typ vorgesehen ist. Damit der Web-Browser weiß, ob die Modifikationsfunktionalität von dem ATM-Server unterstützt wird, muss diese Information in dem ATM-URL kodiert werden. Da der Web-Browser die Dienstkategorie aus dem ATM-URL feststellen kann, ist nur ein Wert für das Modifikationsfeld erforderlich. Der Benutzer kann diesen Modifikationsprozess manuell aufrufen, um die Zellenrate über die Verwendung der ATM-GUI entweder zu erhöhen oder zu verringern, oder dies kann automatisch über die Anwendung geschehen, die die ATM-SVC verwendet. Wenn der Benutzer die Modifikationsprozeduren manuell aufruft, dann müssen die richtigen Funktionen von der ATM-GUI unterstützt werden.
In Bezug auf die Parameter, die in Tabelle 2 aufgelistet sind, sei angemerkt, dass der Wert für die Spitzen- und/oder Aufrechterhaltbare Zellenrate und die Größe des maximalen Bursts von den Einschränkungen der physikalischen Schicht und der Funktionalität der ATM-Vermittlung(en) abhängt, die für die SVC verwendet werden. Wenn irgendeine der Funktionen, die in der Tabelle aufgelistet sind, von dem ATM-Server nicht unterstützt wird, dann ist dies durch den Buchstaben „x" gekennzeichnet. Ungleich der darunterliegenden Elemente der Signalisierunginformationen (IEs, Informationen Elements) sind die Parameter, die in der Tabelle aufgelistet sind, positionsabhängig, da sie keinen weiterführenden Identifikator haben. Die Nummer der anrufenden Partei in der Tabelle nicht gezeigt. Die Adresse des ATM-Servers wird der IE mit der Nummer der angerufenen Partei von der Schnittstelle zum Dienstanbieter (SPI, Service Provider Interface) von WinSock2 zugeordnet.
ABR-Informationsfelder, die in der IE der ABR-Setup-Parameter befördert werden, sind in der Richtung vom Benutzer zum Netz nur optional, wie in UNIv4.0 definiert ist. Deshalb sind diese Informationen, die von den ATM-Setup-Parametern befördert werden, in dem ATM-URL nicht definiert. Dies schließt nicht aus, dass die anrufende Partei die IE der ABR-Setup-Parameter in eine SETUP-Nachricht einschließt.
ABR-Informationen, die in der IE der zusätzlichen ABR-Parameter befördert werden, sind in der Richtung vom Benutzer zum Netzwerk bloß optional, falls der Benutzer explizit einen Satz von zusätzlichen ABR-Parametern angeben möchte, wie durch UNIv4 definiert ist. Dadurch sind diese Informationen, die durch die IE der zusätzlichen ABR-Parameter befördert werden, nicht in dem ATM-URL definiert. Dies schließt nicht aus, dass die anrufende Partei die IE der zusätzlichen ABR-Parameter in eine SETUP-Nachricht einschließt. Die zulässige Kombination von Verkehrsparametern, QoS und Funktionalität des Nutzkanals muss den Spezifikationen nach UNIv4.1 entsprechen.
Die Verhandlung der ABR-Parameter ist in dieser Implementierung möglich, vorausgesetzt, dass das Verhandlungsfeld in dem ATM-URL entsprechend kodiert ist. UNIv4.1 und ITU-T Q.2961.3 definieren, welche ABR-Parameter verhandelt werden können.
Da aktuell keine übereinstimmende Definition die PCR-Kategorie (CLP = 0) nutzt, wird diese folglich in der Kodierung des ATM-URL nicht unterstützt.
Ein Beispiel einer ATM-URL, die entsprechend Tabelle 2 kodiert ist, ist das folgende:
atm://1.1.x.5.2.2.1.500.x.x.375.x.32.250.x.x.187.x.64.1.1.x.x.x@470 10203040506070809000a0b0c0d0f01020304/public/video/.mpg
Die Eigenschaften einer entsprechenden ATM-SVC (switched virtual circuit) sind die folgenden:

• Server unterstützt ATM-F UNIv3.1;
• Typ der Verbindungstopologie ist Punkt-zu-Punkt;
• Wert des LIJ-Anrufidentifikators wird nicht unterstützt, da Punkt-zu-Punkt Verbindung erforderlich ist;
• Typ des AAL ist type 5;
• Funktionalität des B-Kanals ist BCOB-X;
• VBR-Dienstkategorie wird vom Server ausgewählt;
• Wert der Spitzenbandbreite vorwärts (CLP = 0 + 1) wird durch den Server definiert;
• Wert der Spitzenbandbreite vorwärts (CLP = 0 + 1) beträgt 500 kBit/s;
• Minimale Bandbreite vorwärts wird nicht verwendet, (d. h. weder ABR noch VBR ist ausgewählt);
• Aufrechterhaltbare Bandbreite vorwärts (CLP = 0 + 1) wird nicht verwendet;
• Wert der aufrechterhaltbaren Bandbreite vorwärts (CLP = 0), der von dem Server definiert wird, beträgt 375 kBit/s;
• MBS vorwärts (CLP = 0 + 1) wird nicht verwendet;
• Wert der MBS vorwärts (CLP = 0), die von dem Server definiert wird, beträgt 32;
• Wert der Spitzenbandbreite rückwärts (CLP = 0 + 1) wird durch den Server definiert;
• Wert der Spitzenbandbreite rückwärts (CLP = 0 + 1) beträgt 250 kBit/s;
• Minimale Bandbreite rückwärts wird nicht verwendet, (das heißt, weder ABR noch VBR sind ausgewählt);
• Aufrechterhaltbare Bandbreite rückwärts (CLP = 0 + 1) wird nicht verwendet;
• Wert der aufrechterhaltbaren Bandbreite rückwärts (CLP = 0), der von dem Server definiert wird, beträgt 187 kBit/s;
• MBS rückwärts (CLP = 0 + 1) wird nicht verwendet;
• Wert von MBS rückwärts (CLP = 0), der vom Server definiert wird, beträgt 64;
• QoS-Klasse vorwärts, die vom Server definiert wird, ist Klasse 1;
• QoS-Klasse rückwärts, die vom Server definiert wird, ist Klasse 1;
• Markieren wird nicht unterstützt;
• Verhandlung wird nicht unterstützt;
• Modifikation wird nicht unterstützt.

Die Serveradresse wird nach dem AESA-Schema mit dem folgenden Wert angegeben:

• 47010203040506070809a0b0c0d0e0f0102 0304

Der Pfad und der Name der Datei ist public/video.mpg.
2 ist ein Flussdiagramm, das in weiteren Details das Verhalten eines Systems beschreibt, das mit ATM-URLs arbeitet. Die gezeigten Schritte sind die folgenden:

1. Der Benutzer durchsucht Web-Seiten nach relevanten Informationen, als ob er einen Standard-Webbrowser benutzt würde. Es wurde keine ATM-SVC aufgebaut.
2. Wenn der Benutzer auf den gewünschten ATM-Hyperlink/URL klickt, oder ein Lesezeichen verwendet, dann führt der Web-Browser folgende Operationen aus:
3. Zuerst muss der Web-Browser feststellen, ob dies eine ATM-URL-Anfrage ist, und wenn dem so ist, muss er die ATM-Informationen analysieren/dekodieren. Diese Informationen werden gespeichert und verwendet, um dabei zu helfen, das Profil der Funktionalität der Signalisierungnachricht zu konstruieren, sowie den Socket und den Typ der Protokoll-Zustandsmaschine festzustellen. Es sei angemerkt, dass die ATM-URL nicht alle IEs enthält, die in den Signalisierungprotokollen definiert sind, die von diesem Patent unterstützt werden. Dies hat zwei Gründe. Erstens werden nicht alle der definierten IEs in den SETUP- oder LEAF-SETUP-REQUEST-Nachrichten der ATM-Signalisierung gesendet. Zweitens enthalten die ATM-Informationen in der URL nur Informationen, die von dem Web-Browser gebraucht werden. Dem Web-Browser oder der WinSock2-API ist es freigestellt, gültige zusätzliche ATM-Informationen hinzuzufügen, bevor die ATM-SVC eingeleitet wird. Ein Beispiel dieser zusätzlichen ATM-Informationen können die Nummer der anrufenden Partei, Unteradressen der anrufenden Partei, Auswahl des Durchgangsnetzes (TNS, Transition Network Selector), Breitbandsenden Beendet, Breitband-Wiederholungsanzeiger, Informationen der oberen und unteren Breitbandschicht, Kompatibilität der oberen und unteren Schmalbandschicht, usw. Bevor Daten zwischen den zwei Einheiten gesendet werden können, muss der Web-Browser die richtige Implementierung der Zustandsmaschine für das Protokoll des URL-Schemas verwenden. Die Zustandsmaschine für das ATM-Protokoll muss auch der ATM-Socket-Beschreibung zugeordnet werden. Da das URL-Schema „atm://" ist, weiß der Web-Browser, dass er die Zustandsmaschine für das ATM-Protokoll verwenden muss, und erzeugt ATM-Sockets. Die Zustandsmaschine wird von dem Web-Browser verwendet, um sein Verhalten zu definieren, wenn er Daten über eine Verbindung sendet und empfängt. Diese Zustandsmaschine wurde für die Verwendung bei ATM-Verbindungen entwickelt. Die ATM-Zustandsmaschine wird unten mit Bezug auf 4 in weiteren Details beschrieben.
4. Wenn jedoch der Webbrowser-Client nach dem Dekodieren der ATM-URL feststellt, dass kein Wert oder keine Werte der ATM-Parameter von dem Web-Browser manuell angegeben werden müssen, dann wird die ATM-GUI nicht gestartet und der Web-Browser verwendet die darunterliegende Funktionalität der Anwendungsprogrammierschnittstelle (API, Application Programming Interface) von Winsock2, um eine ATM-SVC zum gewünschten Ziel aufzubauen. Die Eigenschaften dieser ATM-SVC sind dieselben, wie die Werte, die von dem HTTP-Server in der ATM-URL zurückgegeben werden. Dies entspricht dem Zustand ATM_EINSTELLUNGEN_EMPFANGEN in 4.
5. Wenn von dem Benutzer gefordert wird, bestimmte Werte für ATM-Parameter zu definieren, startet der Web-Browser die ATM-GUI, die in 3 gezeigt ist. Diese ATM-GUI ist eine Erweiterung traditioneller Webbrowser-Anwendungen, dahingehend, dass sie den Endbenutzern ermöglicht, Werte für die ATM-Parameter einzugeben, die in der ATM-URL als „benutzerdefiniert" kodiert werden. Diese Werte, die von dem Endbenutzer über die ATM-GUI eingegeben werden, werden auch gespeichert, um zu helfen, das Profil oder Eigenschaften der Signalisierungsnachrichten zusammenzustellen, die an den/die ATM-Server gesendet werden. Dies entspricht dem Zustand ATM_EINSTELLUNGEN_EMPFANGEN in 4.
6. WinSock2 ist für die Erzeugung von ATM-Sockets für den Web-Browser und den ATM-Server verantwortlich, um darüber zu kommunizieren. Dies schließt ein, dass der Web-Browser und der ATM-Server eine Anzahl von WinSock2-Funktionsaufrufen machen. Wenn die ATM-Sockets erzeugt wurden, aber nicht miteinander verbunden sind, dann entspricht dies dem Zustand ATM_VERBINDUNG_BEGINNEN, wie in 4 gezeigt ist.
7. Nachdem die Server- und Client-Sockets erzeugt sind, kommuniziert WinSock2 mit dem darunterliegenden Stapel des Signalisierungsprotokolls, um eine ATM-SVC aufzubauen und verbindet die beiden ATM-Sockets logisch miteinander. Die WinSock2-SPI ist dafür verantwortlich, die ATM-URL-Parameter aufzunehmen, sowie möglicherweise Informationen, die von dem Benutzer hinzugefügt wurden, und sie in den richtigen Formaten zu kodieren, um sie für das darunter liegende Signalisierungsprotokoll zu verwenden, sei es UNIv3.0, UNIv3.1, UNIv4.0, UNIv4.1 oder Q.2931. Die WinSock2-SPI ist auch für das Einschließen von obligatorischen Signalisierungs-IEs verantwortlich, die nicht in dem ATM-URL definiert sind. Beispiele dieser obligatorischen IEs schließen den Protokoll-Diskriminator, die Anrufreferenz, die Länge der Nachricht, den Typ der Nachrichten und die Referenz des Endpunkts (für Punkt-zu-Mehrpunkt-Verbindungen) sowie die LIJ-Sequenznummer (für LIJ-Verbindungen) ein. Wenn die ATM-SVC erfolgreich aufgebaut ist, dann können Datensätze für die Rechnungsstellung erzeugt werden, und der Zustand ATM_ANFRAGE_SENDEN wird erreicht, siehe 4. Wenn der Aufbau der SVC jedoch fehlschlägt, startet der Web-Browser ein Fenster, um den Benutzer von dem Ereignis zu informieren, und tritt in den ATM_FEHLER_GEFUNDEN-Zustand ein.
8. Nachdem die ATM-SVC aufgebaut ist, können Daten zwischen dem Web-Browser und dem ATM-Server gesendet und empfangen werden. Bevor die Dateien) heruntergeladen werden, gibt der ATM-Server die Gesamtlänge der Datei, die heruntergeladen werden soll, an den Web-Browser zurück. Die Anzahl von Datenbytes, die von dem Web-Browser empfangen wird, wird inkrementiert und mit der Dateigröße verglichen, die in dem Zustand DATEIGRÖSSE_EMPFANGEN in 4 erhalten wird. Wenn die zwei Werte gleich sind, dann wurde die gesamte Datei übertragen und der Zustand ATM_ÜBERTRAGUNG_ANHALTEN wird erreicht, ansonsten wird die Übertragung fortgesetzt. Wenn Daten heruntergeladen werden, wird die Steuerung von der Zustandsmaschine an die anrufende Anwendung zurückgegeben, sodass sie keine Befehle des Benutzers blockiert. Das Wissen über die Dateigröße ermöglicht dem Web-Browser, den Zustand des Fortschritts der Übertragung anzuzeigen (wobei er den Anteil der empfangenen Bytes im Vergleich mit der Gesamtanzahl anzeigt, die noch empfangen werden soll), und die verbleibende Übertragungszeit zu schätzen. Da viele verschiedene Datentypen heruntergeladen werden können, muss der Web-Browser wissen, wie er jeden Datentyp interpretieren muss. In Abhängigkeit der zugeordneten Typen von Mehrzweck-Internet-Mailerweiterungen (MIME, Multipurpose Internet Mail Extensions) werden die Daten entweder einer integrierten Anwendung, einem Dateinamen auf einer lokalen oder entfernt angeordneten Platte oder der Anzeige des Web-Browsers zugewiesen.
9. Wenn während des Prozesses des Herunterladens Fehler auftreten, geht die Zustandsmaschine in den Zustand ATM_FEHLER_BEENDET über. Dies kann aus verschiedenen Gründen geschehen, wie etwa, dass der ATM-Server die Größe der Datei in dem ersten Paket nicht sendet; oder die Übertragung eines Puffers nicht abgeschlossen werden kann, weil es entweder ein Versagen des Netzwerks oder der Anwendung gab, usw.
10. Wenn der Benutzer das Herunterladen der Datei beenden möchte, kann er dies tun, indem er den „Abbrechen"-Knopf in der Dialogbox des Fortschritts drückt, oder alternativ, indem er den „Stop"-Knopf auf der GUI des Web-Browsers drückt. Dies verursacht, dass der Zustand ATM_FEHLER_eintritt, wie in 4 gezeigt ist, und veranlasst, dass die ATM-SVC aufgelöst wird. Vorausgesetzt, dass Ende-zu-Ende-Unterstützung zwischen dem Web-Browser und dem ATM-Server besteht, was Signalisierung nach ITU-T Rec. Q.2963.1 oder Q.2963.2 und (Q.2725.2 oder Q.2725.3) unterstützt, dann kann der Endbenutzer die Verkehrseigenschaften der ATM-SVC modifizieren. Dieser Modifikationsprozess kann über die Verwendung der ATM-GUI und dadurch erreicht werden, dass der Benutzer oder die Anwendung automatisch neue Informationen eingibt, was für den Benutzer transparent sein kann. 3 zeigt mehr Informationen.
11. Nachdem die Datei(en) einmal zu dem Web-Browser heruntergeladen worden sind, startet der ATM-Server automatisch den ersten Schritt, um die ATM-Sockets zu schließen. Indem die Sockets geschlossen werden, wird der ATM-Server wiederum veranlasst, die ATM-SVC zwischen sich selbst und dem Web-Browser aufzulösen. Alle Mechanismen der Rechnungsstellung, die der SVP zugeordnet sind, sollten gestoppt werden. Der Web-Browser ist nun in dem Zustand ATM_ÜBERTRAGUNG_ANHALTEN, wie in 4 gezeigt ist.
12. Nachdem die ATM-SVC aufgelöst worden ist, können der Server und der Client dann ihre ATM-Sockets, die der SVC zugeordnet sind, vollständig herunterfahren und alle Ressourcen freigegeben, die ihnen zugeordnet sind. Der Web-Browser ist nun in dem Zustand ATM_RESSOURCEN_FREIGEBEN, wie in 4 gezeigt ist, und die Steuerung wird dem Anrufprozess in dem Web-Browser zurückgegeben.

Die bevorzugte Ausführung der oben beschriebenen Erfindung bietet einer Anzahl von Vorteilen. Sie ermöglicht, dass die dynamische Bandbreite und QoS-Eigenschaften, die der ATM-Technik zugeordnet sind, ausgenutzt werden und hilft wesentlich, die Komplexität des Aufbaus von ATM-SVCs vor dem Endbenutzer zu verbergen. Deshalb können die Prozesse, die am Aufbau einer ATM-SVC beteiligt sind, für den Benutzer fast transparent werden. Es wird geglaubt, dass die Transparenz oder Einfachheit der Benutzung helfen wird, den Einsatz von ATM-SVC-Funktionalität zu den Endbenutzern voranzutreiben. Deshalb kann ein ATM-basierter Web-Browser auf gleiche Weise arbeiten, wie ein IP-Webbrowser, wie etwa Netscape Navigator und Microsoft Internet Explorer. Der HTTP-Server, der die ATM-URL der Datei speichert, die der Benutzer abrufen möchte, ist besser aufgestellt, um die ATM-Eigenschaften zu verstehen, die von der Datei gefordert werden, als der Endbenutzer. Der Endbenutzer kann die volle Kontrolle darüber haben, wann eine ATM-SVC aufgebaut und aufgelöst wird, indem er die grafische Benutzerschnittstelle (GUI) für ATM verwendet. Der Benutzer kann über die ATM-GUI auch die ATM-Informationen in der URL modifizieren. Da die ATM-SVC von dem Benutzer zum Server aufgebaut wird, hat sie keine tiefgreifenden Ein flüsse auf das traditionelle Rechnungsstellungsmodell. Es wird ein hoher Grad von Unabhängigkeit von den darunter liegenden ATM-Signalisierungprotokollen erreicht. Die ATM-URL kann entweder mit ATM-F- oder ITU-T ATM UNI-Signalisierungprotokollen verwendet werden.
TABELLE 2
Glossar

ABR

verfügbare Bitrate (Available Bit Rate)

ABT

ATM-Blockübertragung (ATM Block Transfer)

ARP

Adresszuordnungsprozess (Adress Resolution Process)

ATM

Asynchroner Übertragungsmodus (Asynchronous Transfer Mode)

ATM-F

ATM-Forum

B-HLI

Informationen der oberen Breitbandschicht (Broadband High Layer Information)

B-LLI

Informationen der unteren Breitbandschicht (Broadband Low Layer Information)

CBR

Konstante Bitrate (Constant Bit Rate)

DNS

Domainnamendienst (Domain Name Service)

FR

Frame Relay

GUI

Graphische Benutzerschnittstelle (Graphical User Interface)

HTML

Markierungsbasierte Hypertext-Sprache (Hyper-Text Marked-up Language)

HTTP

Hypertext-Übertragungsprotokoll (Hyper-Text Transfer Protocol

IE

Informationselement (Information Element

IETF

Arbeitsgruppe Internet-Entwicklung (Internet Engineering Task Force)

IP

Internetprotokoll (Internet Protocol)

ITU-T

internationale Telekommunikationsunion-Normungs-Sektor (International Telecommunications Union-Standardisation Sector)

PVC

Permanent Virtual Circuit

QoS

Dienstqualität (Quality of Service)

RFC

Anforderung von Kommentaren (Request For Comments)

SPI

Schnittstelle zum Diensteanbieter (Service Provider Interface)

SVC

Vermittelte virtuelle Leitung (Switched Virtual Circuit)

TCP

Übertragungssteuerungsprotokoll (Transmission Control Protocol)

UBR

Nicht angegebene Bitrate (Unspecified Bit Rate)

UDP

Benutzerdatagrammprotokoll (User Datagram Protocol)

UNI

Schnittstelle zum Netz des Benutzers (User Network Interface)

URL

Einheitlicher Ressourcenortsbezeichner (Uniform Resource Locator)

VBR

Variable Bitrate (Variable Bit Rate)

VCI

Identifikator eines virtuellen Kanals (Virtual Channel Identificator)

VPI

Identifikator eines virtuellen Pfades (Virtual Path Identificator)

VPCI

Identifikator einer Verbindung über einen virtuellen Pfad (Virtual Path Connection Identificator)

Claims

Schema eines einheitlichen Ressourcenortsbezeichners mit einem einheitlichen Ressourcenortsbezeichner (URL, Uniform Resource Locator), wobei der einheitliche Ressourcenortsbezeichner einen Identifiziererteil für die Leitungsvermittlung, der eine Ressource als über ein leitungsvermitteltes Netz zugänglich identifiziert, einen Adressteil, der die Adresse der Ressource umfasst, und einen Dienstparameterteil umfasst.
Schema eines einheitlichen Ressourcenortsbezeichners nach Anspruch 1, bei dem der einheitliche Ressourcenortsbezeichner das Format: <Identifiziererteil für die Leitungsvermitlung>://<Dienstparamterteil>*<Adressteil> hat, wobei * ein vorher festgelegtes Separierungszeichen ist.
Schema eines einheitlichen Ressourcenortsbezeichners nach Anspruch 1 oder 2, bei dem der Identifiziererteil die Ressource als über ein ATM-Netz zugänglich identifiziert.
Schema eines einheitlichen Ressourcenortsbezeichners nach Anspruch 3, bei dem der Dienstparameterteil ATM-Dienstparameter enthält.
Schema eines einheitlichen Ressourcenortsbezeichners nach einem der vorangehenden Ansprüche, bei dem der Dienstparameterteil einen Identifizierer für eine Verbindungstopologie enthält.
Schema eines einheitlichen Ressourcenortsbezeichners nach einem der vorangehenden Ansprüche, bei dem der Dienstparameterteil einen Parameter enthält, der eine Verbindungsbandbreite anzeigt.
Maschinenlesbarer Übertrager, der ein Schema eines einheitlichen Ressourcenortsbezeichners nach einem der vorangehenden Ansprüche überträgt.
Verfahren zum Betreiben eines Endgeräts, das direkt oder indirekt mit einem leitungsvermittelten Netz verbunden ist, wobei das Verfahren folgendes enthält: a) Lesen eines einheitlichen Ressourcenortsbezeichners (URL, Uniform Resource Locator), wobei der URL einen Identifiziererteil für die Leitungsvermittlung, der eine Ressource als über ein leitungsvermitteltes Netzwerk zugänglich identifiziert, einen Adressteil, der die Adresse der Ressource umfasst, und einen Dienstparameterteil umfasst; b) nachfolgendes Aufbauen einer Verbindung zwischen einem Kundenendgerät und der Ressource, wobei die Verbindung Eigenschaften hat, die wenigstens teilweise von einem oder mehreren Parametern bestimmt werden, die in dem Dienstparameterteil enthalten sind.
Verfahren nach Anspruch 8, das das Lesen des einheitlichen Ressourcenortsbezeichners von einem Server enthält, der von dem Endgerät entfernt angeordnet ist.
Verfahren nach Anspruch 8 oder 9, bei dem Schritt (b) von dem Endgerät eingeleitet wird.
Verfahren nach einem der Ansprüche 8 bis 10, bei dem der Identifiziererteil die Ressourcen als über ein ATM-Netz zugänglich identifiziert, und der Dienstparameterteil einen oder mehrere ATM-Dienstparameter enthält.
Endgerät für die Verwendung in einem Kommunikationsnetz, das ein leitungsvermitteltes Netz enthält, wobei das Endgerät folgendes enthält: a) eine Netzwerkschnittstelle für die Verbindung mit dem Kommunikationsnetz; b) einen Prozessor, der dazu eingerichtet ist, folgende Schritte auszuführen: i) Lesen eines einheitlichen Ressourcenortsbezeichners (URL), wobei der URL einen Identifiziererteil für die Leitungsvermittlung, der eine Ressource als über das leitungsvermittelte Netzwerk verfügbar identifiziert, einen Adressteil, der die Adresse der Ressource umfasst, und einen Dienstparameterteil umfasst; ii) nachfolgendes Aufbauen einer Verbindung zwischen dem Kundenendgerät und der Ressource, wobei die Verbindung Eigenschaften hat, die wenigstens teilweise von einem oder mehreren Parametern bestimmt werden, die in dem Dienstparameterteil enthalten sind.
Datenserver für die Verwendung in einem Kommunikationsnetz, das ein leitungsvermitteltes Netz enthält, wobei der Datenserver ein gespeichertes Programm mit einem Schema eines einheitlichen Ressourcenortsbezeichners nach einem der Ansprüche 1 bis 6 enthält.