RNAP. A Framework for Resource Negotiation and Pricing in the Internet

Transkript

1 RNAP A Framework for Resource Negotiation and Pricing in the Internet Ausarbeitung zum Seminarvortrag Abteilung IV Institut für Informatik Rheinische Friedrich-Wilhelms-Universitt Bonn Andrei Svirida,M.Nr November 2001

2 Inhaltsverzeichnis 1 Einführung 1 2 Existenzberechtigung von RNAP Netzwerkmodell von RNAP Begriffe Annahmen Notwendigkeit von RNAP Problemstellung RNAP als mögliche Lösung Vorteile von RNAP vor anderen Konzepten Aufbau und Funktionsweise von RNAP Architektur von RNAP RNAP-Centralized RNAP-Distributed Kompatibilität zwischen RNAP-C und RNAP-D Kommunikationsprotokoll von RNAP Format einer RNAP-Nachricht Typen der RNAP-Nachrichten Beispiel für typischen Verhandlungsablauf Aggregation von Microflows Gebührenerfassung und Gebührenberechnung RNAP-Kommunikationsprotokoll und Gebührenefaßung Preisgestaltung in RNAP-D Preisgestaltung in RNAP-C Zusammenfassung 22 A Einführung in QoS in IP-Netzen 23 A.1 Was ist QoS? A.2 Wichtige QoS-Parameter A.3 Implementierung von QoS

3 Zusammenfassung In dieser Arbeit wird das Rahmenwerk RNAP für Better then Best Effort (BBE) - Netze betrachtet. Mit Hilfe von RNAP kann zwischen dem Netz und dem Nutzer die Vereinbarung getroffen werden, welche Dienstgüte zu welchen Kosten dem Nutzer vom Netz garantiert werden kann.

4 Kapitel 1 Einführung Die Entwicklung und Benutzung der IP-basierten Multimedia-Anwendungen wie Videoübertragung oder IP-Telefonie hat in der letzten Zeit erheblich zugenommen. Heutige Multimedia-Anwendungen stellen hohe Anforderungen an die Dienstgüte(z.B. Durchsatz, Fehlerrate, Latenz und Jitter), die von bestenenden Best Effort Service-Netzen nicht erfüllt werden können. Um dieses Problem zu lösen wurden Konzepte für Better then Best Effort - Netze entwickelt, bei denen das Netz Anwendungen eine bestimmte Dienstgüte (Quality of Service) garantieren kann. Dabei entstehen unter anderem folgende Probleme: Auf welche Weise kann die Anwendung vom Netz den Dienst mit einer bestimmten Dienstgüte anfordern? Auf welche Weise kann das Netz die Gebühren berechnen, die dem Nutzer der Anwendung durch Inanspruchnahme einer bestimmten Dienstgüte entstehen? In dieser Arbeit wird das Rahmenwerk RNAP betrachtet, das eine Lösung für die genannten Probleme darstellt. Das wichtigste Bestandteil von dem Rahmenwerk ist das gleichnamige Kommunikationsprotokoll RNAP (Resource Negotiation and Pricing Protocol). Weiter wird der Begriff RNAP für die Bezeichnung des gesamten Rahmenwerks benutzt, falls nicht anders angegeben. Mit Hilfe von RNAP kann zwischen der Anwendung und dem Netz die Vereinbarung getroffen werden, welche Dienstgüte zu welchen Kosten vom Netz zur Verfügung gestellt wird. Dieser Vorgang kann sich nach folgendem Schema abspielen: 1. Die Anwendung fordert mit Hilfe von RNAP vom Netz die Informationen über verfügbare Dienste sowie über die voraussichtlichen Kosten für die Inanspruchnahme dieser Dienste an. 2. Die Anwendung entscheidet, welche Dienste für welchen Zeitraum in Anspruch genommen werden müßen und teilt diese Entscheidung dem Netz mit Hilfe von RNAP mit. 3. Das Netz macht notwendige Resourcenreservierungen und informiert durch RNAP die Anwendung, daß der Dienst mit der angeforderten Dienstgüte zur Verfügung steht. 4. Die Anwendung sendet oder empfängt die Daten mit der reservierten Dienstgüte und informiert durch RNAP das Netz, daß der angeforderte Dienst nicht mehr gebraucht wird. 1

5 KAPITEL 1. EINFÜHRUNG 2 5. Das Netz berechnet die Gebühren, die dem Nutzer für die Übertragung der Daten entstehen. RNAP unterstützt bestehende Konzepte zur QoS-Sicherung int-serv und diff-serv und ermöglicht die Vereinbarung der Dienstgüte sowohl für Microflows als auch für deren Aggregate. Diese Eigenschaft unterscheidet RNAP von dem int-serv-kommunikationsprotokol RSVP, das nur für die Unterstützung von Microflows konzipiert ist. (4) Ein anderer wichtiger Unterschied zu RSVP besteht in der eingebauten Unterstützung der Gebührenberechnung und Gebührenerfassung. Die Arbeit ist auf folgende Weise aufgebaut: im folgenden Kapitel wird begründet, warum die Entwicklung eines Rahmenwerks zur Signallisierung der QoS-Anforderungen notwendig ist. Hier werden auch die Annahmen über das zugrundeliegende Netzwerk und wichtige Begriffe definiert. Im Kapitel 3 werden Gesamtarchitektur, Kommunikationsprotokoll und Mechanismen zur Gebührenerfasßung von RNAP-Rahmenwerk betrachtet. Das letzte Kapitel faßt die Ergebnisse dieser Arbeit zusammen. Index A gibt eine kurze einführung in die QoS -Thematik, dort werden unter anderem die wichtigsten QoS-Eigenschaften eines Dienstes definiert. Diese Arbeit basiert zum großen Teil auf (20), (22), (19) und (21).

6 Kapitel 2 Existenzberechtigung von RNAP In diesem Kapitel wird begründet, warum die Entwicklung eines neuen Konzepts zur Signallisieurng der QoS-Anforderungen notwendig ist. Dieses Kapitel hat folgenden Aufbau: in nächsten zwei Unterkapiteln werden die Annahmen über das zugrundeliegende Rechnernetz dargestellt. Weiter werden die QoS-relevanten Problemstellungen betrachtet, die sich in Zusammengang mit diesem Modell ergeben. Es werden die Anforderungen definiert, die an RNAP bei seiner Entwicklung gestellt wurden. Im letzten Unterkapitel werden die Unterschiede zwischen RNAP und anderen Protokollen zur Signallisieurng der QoS-Anforderungen diskutiert. 2.1 Netzwerkmodell von RNAP In dieser Arbeit wird folgendes Modell für ein IP-basiertes Netzwerk betrachtet: Netz A B4 Netz B B5 B6 B3 Netz C B1 B2 B7 B8 Anwendung S1 Netzwerk S2 B2 Border Router Interner Router E1 E2 Abbildung 2.1: Modell für ein IP-basiertes Netzwerk 3

7 KAPITEL 2. EXISTENZBERECHTIGUNG VON RNAP Begriffe In Zusammenhang mit diesem Modell werden folgende Begriffe eingeführt. Sender ist eine Anwendung, die den Dienst einer bestimmten Qualität zum Versenden der Daten in Anspruch nehmen will. In Netzmodell auf der Abbildung 3.7 werden Sender mit S 1 und S 2 bezeichnet. Emfpänger ist eine Anwendung, die den Dienst einer bestimmten Qualität zum Empfangen der Daten in Anspruch nehmen will. In Netzmodell auf der Abbildung 3.7 werden Emfpänger mit R 1 und R 2 bezeichnet. Service Provider ist ein Anbieter für Netzzugänge. Service Provider verwaltet eines oder mehrere Netze und stellt die Interoperabilitat zwischen seinen und fremden Netzen sicher. Flow,Microflow ist ein Datenstrom zwischen Sender und Empfänger. Ein Microflow wird eindeutig durch einen 5-Tupel (IP-Adresse des Senders, Port des Senders, IP-Adresse des Empfängers, Port des Empfängers, Transportprotokoll) identifiziert Aggregation,Deaggregation, Aggregat Unter Aggregation wird die Zusammenfassung von mehreren Microflows zu einem einzigen Datenstrom verstanden, der dann Aggregat heißt. So könnte zum Beispiel der Router B 3 die Microflows S 1 E 1 und S 2 E 2 zu einem Aggregat A 1 zusammenfaßen. Unter Deaggregation versteht man die Wiederherstellung einzelner Microflows aus einem Aggregat. So könnte zum Beispiel der Router B 5 aus dem Aggregat A 1 die Microflows S 1 E 1 und S 2 E 2 wiederherstellen. Admininstrative Domäne Unter Admininstativen Domäne werden Netz oder Netze verstanden, die von einem Service Provider verwaltet werden. Acces Network ist ein Netz, an welches Sender oder Empfänger direkt angeschlossen sind. Transit Network ist ein Netz, das weder an Sender noch an Emfpänger angeschloßen ist aber die Daten zwischen Access Networks von Sender und Empfänger überträgt. Border Router ist ein Router, der das Netz mit anderen Netzen oder mit den Nutzern verbindet. In Netzmodell auf der Abbildung 3.7 werden Border Router mit BR 1..BR 8 bezeichnet. Verhandlung Mit Verhandlung ist in dieser Arbeit der Nachrichtenaustausch zwischen einzelnen Netzknoten(wie z.b. Anwendungen auf dem Nutzerrechner oder Routern) gemeint, dessen Ziel die Vereinbarung einer bestimmten Dienstgüte zwischen diesen Knoten ist. Es kann aber auch geschehen, daß eine Verhandlung wegen fehlender Ressourcen oder der für Nutzer inakzeptablen Kosten zu keiner Vereinbarung führt. In diesem Fall kann kein Dienst mit gewünschter Dienstgüte von Anwendung in Anspruch genommen werden ingress-router und egress-router Begriffe ingress-router und degress-router beziehen sich auf ein Netz und einen Datenstrom, der dieses Netz durchquert. Mit ingress-router wird ein Border Router gemeint, der Pakete des

8 KAPITEL 2. EXISTENZBERECHTIGUNG VON RNAP 5 Datenstroms von anderen Netzen entgegennimmt und in das Netz weitetleitet.. Unter egress- Router versteht man den Border Router, an dem Pakete des Datenstroms das Netz verlassen und an ein anderes Netz weitergeleitet werden. Wenn man von einem Datenstrom zwischen S 1 und E 1 ausgeht, dann ist der Router B 4 der ingress-router und B 5 der egress-router für diesen Strom im Netz B Annahmen In dieser Arbeit wird von folgenden Annahmen über das Rechnernetz ausgegangen: Die beteiligten Netzwerke sind IP-basiert Die beteiligten Netzwerke sind in einer oder anderen Form QoS-fähig. Praktisch heißt das, dass jedes Netz bestimmte Garantien zur Dienstgüte bei der Übertragung der Pakete zwischen seinen ingress- und egress-routern geben kann. Es werden keine konkreten Anforderungen weder an die QoS-Implementierung noch an die unterstützten Dienste gestellt. Für die Durchsetzung der QoS-Fähigkeit kann ein Netz int-serv (3), diff-serv (2) oder andere Verfahren benutzen. IP-Pakete eines Datenstroms werden auf dem Weg vom Sender zum Empfänger nicht fragmentiert. Bei der Fragmentierung der Pakete in einem IP-Netzwerk enthält nur das erste Fragment die Informationen aus dem Transportlayer (Portnummern), die zur eindeutigen Identifizierung des Datenstroms dienen. Die Fragmentierung der Pakete würde diese Identifizierung und somit die Zuweisung der IP-Pakete zu einem Microflow unmöglich machen. Die Verfahren aus (9) und (8) können benutzt werden, um den MTU festzustellen, bei dem keine Fragmentierung notwendig ist. Route eines Datenstroms, für den eine bestimmte Dienstgüte vereinbart wurde, ändert sich nicht während der gesamten Datenübertragung. Die ausführliche Diskussion dieses Problems, die auf RNAP in ähnlicher Weise wie auf RSVP zutrifft sowie ein möglicher Lösungsansatz namens route pinning ist in RFC 1633, Punkt 5.2 Routing and Reservations (4) zu finden. Kurz zusammengefaßt, besteht der Ansatz von route pinning darin, die Router so zu modifizieren, daß sie keine Routenänderungen für Datenströme mit der BBE-Dienstgüte durchführen. Diese Arbeit beschränkt sich aus Platzgründen auf die Betrachtung von Unicast-Übertragung. 2.2 Notwendigkeit von RNAP In diesem Unterkapitel wird zuerst ein konkretes Szenario betrachtet, welches Probleme demonstriert, die die Entwicklung von RNAP motiviert haben. Danach werden diese Probleme allgemeiner formuliert und es werden Anforderungen definiert, die an RNAP gestellt werden Problemstellung Im Beispielszenario möchte der Emfpänger R 1 Daten vom Sender S 1 während eines bestimmten Zeitraums mit einer bestimmten Dienstgüte empfangen. Um das Besipiel konkreter zu machen, könnte Empfänger E 1 einen Videostrom mit folgender Dienstgüte anfordern:

9 KAPITEL 2. EXISTENZBERECHTIGUNG VON RNAP 6 QoS-Parameter Wert Bandbreite 100 Kbit/s Latenz weniger als 100 ms Jitter weniger 10 ms Fehlerrate weniger als 0.1% Es wird davon ausgegangen, daß das Netz über bestimmte Mechanismen zur Sicherung der Dienstgüte verfügt (siehe Annahmen auf der Seite 5) und befaßen uns in dieser Arbeit mit den Fragen der QoS-bezogenen Kommunikation zwischen der Anwendungund dem Netz sowie mit den Fragen der Gebührenerfaßung und Gebührenberechnung. In Zusammenhang mit dem obigen Szenario ergeben sich folgende Problemstellungen: Wie kann eine Anwendung mit dem Netz eine Vereinbarung über die Dienstgüte treffen, die der Anwendung vom Netz zur Verfügung gestellt wird? Wie erfaßt das Netz die Gebühren für die Bereitstellung eines Dienstes? Dabei ist beachten, daß ein IP-Paket auf dem Weg vom Sender zum Empfänger Netzwerke von mehreren Service Providern durchqueren kann. Welche Strategien zur Gebührenberechnung sind technisch möglich und sinnvoll? RNAP als mögliche Lösung Bei der Entwicklung von RNAP wurde ein Rahmenwerk gesucht, welches folgende Anforderungen erfüllen soll: 1. Das Rahmenwerk soll die Kommunikation zwischen der Anwendung auf der Nutzerseite und den QoS-sichernden Mechanisem auf der Service Provider-Seite ermöglichen. Die Anwendung soll durch diese Kommunikation die Mögichkeit bekommen, Aufzählung der verfügbaren Dienste anzufragen... Preisinformationen zu den einzelnen Diensten anzufragen... einen oder mehrere Dienste für sofortige Nutzung oder sie für einen späteren Zeitpunkt zu reservieren 2. Das Rahmenwerk soll die Vereinbarung der Dienstgüte sowohl für einzelne Datenströme als auch für deren Aggregate ermöglichen. Dieses Thema wird ausfürhlich im Kapitel 3.3 behandelt. 3. Das Rahmenwerk soll die Erfassung der Gebühren für die Nutzung der Dienste ermöglichen. 4. Das Rahmenwerk soll möglichst wenig Anforderungen auf die eingesetzte Gebührenberechnungstrategie stellen, damit eine Vielzahl von verschiedenen Strategien angewandt werden kann. 5. Das Rahmenwerk muß mit bestehenden QoS-Sicherung-Mechanismen wie int-serv (3) und diffserv (2) koexistieren und interagieren können. Es ist wichtig anzumerken, dass RNAP Funktionen zur Vereinbarung der Übertragunsdienstgüte und Gebührenerfassung bereitstellt, aber keine zusätzlichen QoS-Sicherung-Mechanisem einführt. Mit Einschränkungen kann RNAP mit RSVP (4) verglichen werden. Später wird auf die Unterschiede zwischen RNAP und RSVP detailliert eingegangen.

10 KAPITEL 2. EXISTENZBERECHTIGUNG VON RNAP Vorteile von RNAP vor anderen Konzepten Für die oben diskutierten Problemstellungen existieren neben RNAP andere Ansätze, von denen RSVP (4) die größte Verbreitung hat. Folgende Eingenschaften unterscheiden RNAP von RSVP: RNAP ist ein reines Signalling-Konzept und hängt nicht von einem bestimmten Konzept zur Durchsetzung von QoS ab. So kann RNAP mit bestehenden Konzepten wie int-serv (3) und diff-serv (2) zusammenarbeiten. RSVP wurde als Bestandteil von int-serv entwickelt und hat keine integrierten Möglichkeiten der Zusammenarbeit mit diff-serv. Ein möglicher Ansätz für die Integration von RSVP mit diff-serv wird in (5) beschrieben. RNAP hat im Unterschied zu RSVP eingebaute Meachnismen zur Unterstützung der Gebührenerfassung und Gebührenberechnung. Bei der Verhandlung des Nutzers mit dem Netz mit Hilfe von RNAP werden nicht nur die Informationen über die Dienstgüte sondern auch die Informationen zu dem aktuellen Preis des Dienstes ausgetauscht. Der Vorteil für den Provider besteht hier darin, Preise für die Dienste flexibler gestalten zu können, um z.b. auf kurzfristig stark wachsende Nachfrage nach den Resourcen mit Erhöhung des Preises reagieren zu können. Das grundsätzliche Problem der schlechten Skalierbarkeit von RSVP hat bisher seine weite Verbreitung verhindert. RNAP versucht, dieses Problem durch Aggregation der Microflows zu lößen. Dabei werden mehrere Microflows zu einem einzigen Datenstrom zusammengefaßt, was einen wesentlich niedrigeren Verwaltungsaufwand für diese Microflows auf Backbone-Routern bedeuten kann. Bei RNAP besteht die Möglichkeit, während einer laufenden Datenübetragung eine Neuverhandlung durchzuführen, bei der für einen bestehenden Datenstrom ein neuer Dienst eventuell zu einem anderem Preis angefordert werden kann. RSVP ist ein emfpängerorientiertes Protokoll, d.h. die Reservierung kann nur von Empfänger durchgeführt werden. Im Unterschied dazu kann bei RNAP sowohl der Sender als auch Emfpänger der Initiator der Reservierung sein.

11 Kapitel 3 Aufbau und Funktionsweise von RNAP 3.1 Architektur von RNAP In diesem Kapitel wird wieder das Modell und das Szenario aus betrachtet. In RNAP wird in dieses Modell der Host Resource Negotiator () eingeführt: Netz A B4 Netz B B5 B6 B3 Netz C B1 B2 B7 B8 Anwendung S1 Netzwerk S2 B2 Border Router Interner Router E1 E2 Host Resource Negotiator Abbildung 3.1: Modell des Netzwerks mit s dient als Schnittstelle für den Austausch der QoS-relevanten Informationen zwischen der Anwendung und dem Netz. ist verantwortlich für die Ermittlung der verfügbaren Dienste und deren Kosten sowie für die Verhandlung mit dem Netz(siehe 2.1.1). Bei der Verhandlung fordert bein Netz einen oder mehrer Dienste mit einer bestimmten Dienstgüte an. Dabei werden der Typ des Dienstes(z.B. guaranteed service (16), controlled load service (18), premium service (7), assured service (6), best effort service (14)) sowie die QoS-Parameter angegeben, die den gewünschten Dienst näher spezifizieren. Man unterscheidet zwischen den QoS-Parametern, die an alle Dienste angewendet werden können (wie z.b. Möglichkeit der Unterbrechung des Dienstes von der Netzseite) und denjenigen, die nur für bestimmte Dienste gelten(wie z.b. Datenrate, Burst-Größe, Fehlerrate, Latenz, Jitter). 8

12 KAPITEL 3. AUFBAU UND FUNKTIONSWEISE VON RNAP 9 kann die Verhandlung sowohl für einen als auch für mehrere Flows (siehe 2.1.1) durchführen. Ein wichtiger Punkt ist, daß immer nur mit seinem Acces Network (siehe 2.1.1) kommuniziert, auch im Fall, daß der Flow (siehe 2.1.1) mehrere Netzwerke durchquert. Das in der obigen Abbildung dargestellte Model erläutert zwar, wie die Anwendung als Schnittselle für die Verhandlung der Dienstgüte benutzen kann, läßt aber offen, wie die s miteinander kommunizieren. Um die Kommunikation zwischen zwei s zu ermöglichen, unterstützt RNAP zwei verschiedene Architekturen: die zentralisierte Architektur RNAP-C (RNAP-Centralized) und die verteilte Architektur RNAP-D(RNAP-Distributed) RNAP-Centralized Network Resource Negotiator Network Resource Negotiator Netz A B4 B4 Netz B B5 B6 Netz C Network Resource Negotiator B1 B2 B7 B8 Anwendung S1 Netzwerk S2 B2 Border Router Interner Router E1 E2 NRN Network Resource Negotiator Host Resource Negotiator Abbildung 3.2: RNAP-Centralized Architektur In der zentralisierten Architektur erfolgt die Verhandlung zwischen und dem Netzwerk durch Network Resource Negotiator (NRN). Es gibt mindestens einen NRN für jede Administrative Domäne(siehe 2.1.1). NRN hat folgende Aufgaben: NRN führt Verhandlungen mit s NRN verwaltet die in seinem Netz verfügbaren Resourcen

13 KAPITEL 3. AUFBAU UND FUNKTIONSWEISE VON RNAP 10 NRN konfiguriert Router in seinem Netzwerk, damit die mit Nutzern getroffene Vereinbarungen über Dienstgüte vom Netzwerk eingehalten werden können. NRN kommunzieiert mit benachbarten NRNs und tauscht relevante Informationen aus NRN kann entweder als eigentständige Einheit in der Netzinfrastruktur implementiert werden oder andere Einheiten, wie z.b. Bandwidth Broker (BB) (17) in dem diff-serv Modell (2) ergänzen. Im ersten Fall werden die Entscheidungen über Resourcenreservierung (reservation and admission decisions) vom NRN selber getroffen. Im zweiten Fall muß NRN mit den benutzten Einheiten der Netzinfrastruktur kommunizieren und die Entscheidungen über Resourcenreservierung (reservation and admission decisions) von diesen empfangen. RNAP-C funktioniert mit dem sogenannten out-of-band messaging. Bei out-of-band messaging enthält ein IP-Paket keine Informationen, die explizit auf die QoS-Eigenschaften dieses Pakets schliëssen laßen. Stattdessen werten alle Border-Router auf dem Weg des Pakets seine Adressdaten(Quell- und Zieladdresse, Portnummern) aus, weisen dieses Paket einem Microflow zu und erfragen bei dem zuständigen NRN die Entscheidung, wie Pakete dieses Micrfolows zu behandeln sind. Im Fall, daß für diesen Microflow eine Vereinbarung über die Dienstgüte getroffen wurde, werden die Router von NRN so konfiguriert, daß Pakete dieses Microflows entsprechend dieser Vereinbarung behandelt werden.

14 KAPITEL 3. AUFBAU UND FUNKTIONSWEISE VON RNAP RNAP-Distributed Netz A B4 Netz B B5 B6 B3 Netz C B1 B2 B7 B8 Anwendung S1 Netzwerk S2 B2 Border Router mit RNAP-Unterstützung Interner Router mit RNAP-Unterstützung E1 E2 Host Resource Negotiator Abbildung 3.3: RNAP-Distributed Architektur In der verteilten Architektur von RNAP existiert im Unterschied zum RNAP-C keine zentrale Einheit, welche alle QoS-relevanten Informationen verwaltet und als Schnittstelle zwischen und dem Netz gilt. Stattdessen wird das RNAP-Kommunikationsprotokoll von allen Routern des Netzes implementiert. Fehlen einer zentralen Eineit, welche Daten über alle gemachten Reservierungen verwaltet, macht bei RNAP-D das in-band-messaging notwendig. Ähnlich wie bei RNAP-C arbeitet RNAP-D mit outof-band messaging. Die RNAP-Nachrichten in der RNAP-D-Architektur werden aber im Unterschied zu RNAP-C nicht von NRNs sondern von Routern ausgewertet und bearbeitet Kompatibilität zwischen RNAP-C und RNAP-D Der Format von RNAP-Nachrichten ist unabhängig von der benutzen Architektur. Deswegen können beide Architekturen koexistieren. So kann z.b. die Administrative Domäne, welche die RNAP-C- Architektur einsetz, Nachrichten mit der Administrativen Domäne austauschen, die RNAP-D benutzt. Insbsondere ist es für einen nicht von Bedeutung, welche RNAP-Architektur in seinem Netz benutzt wird. 3.2 Kommunikationsprotokoll von RNAP Die Kommunikation zwischen einzelnen Elementen vom Rahmenwerk RNAP (wie z.b., NRN, Router) erfolgt durch das gleichnamige Kommunikationsprotokoll:Resource Negotiation And Pricing

15 KAPITEL 3. AUFBAU UND FUNKTIONSWEISE VON RNAP 12 Protocol, das in diesem Kapitel detailliert betrachtet wird. Der Begriff RNAP wird hier im engen Sinne für die Bezeichnung des Kommunikationsprotokolls und nicht des gesamten Rahmenwerks benutzt. RNAP ermöglicht die Verhandlung zwischen den Anwendung und dem Netz durch den Austausch von RNAP-Nachrichten. Als Transportprotokoll für RNAP wird UDP benutzt. In folgender Sektion wird der Aufbau einer RNAP-Nachricht betrachtet. Weiter werden Beispiele eines typischen Verhandlungsablaufs für RNAP-C und RNAP-D gegeben Format einer RNAP-Nachricht RNAP-Nachricht Flow ID Aggregation Flag Aggregate Flow ID ID Service Type Service Indpendent Parameters Service Specific Parameters Service Price Price... Flow ID Aggregation Flag Aggregate Flow ID ID Service Type Service Indpendent Parameters Service Specific Parameters Service Price Price Abbildung 3.4: Format einer RNAP-Nachricht Eine RNAP-Nachricht kann beliebige Anzahl von Id-Service-Price Tripeln enthalten. Inhalt der Felder einer Nachricht wird abhängig vom Typ der Nachricht interpretiert. Manche Felder oder Feldelemente bleiben bei einzelnen Nachrichtentypen ungenutzt. Einzelne Felder haben folgende Bedeutung: Id Das Feld Id wird zur Identifizierung eines einzelnen Datenstroms benutzt. Es besteht aus drei Elementen: Flow ID,Aggregation Flag und Aggregate Flow ID. Flow ID ein ein Tupel aus Quell-IP-Adresse, Quell-Port, Ziel-IP-Adresse, Zielport und dem ID des Transportprotokolls. Flow ID wird benutzt, um einen Datenstrom eindeutig zu identifizieren. Felder Aggregation Flag und Aggregate Flow ID werden für die Aggregation von Flows benutzt und werden ausführlich im entsprechenden Kapitel diskutiert.

16 KAPITEL 3. AUFBAU UND FUNKTIONSWEISE VON RNAP Service Das Feld Service beschreibt die Eigenschaften des Dienstes, auf den sich die RNAP-Nachricht bezieht. Dieses Feld besteht aus den Elementen Service Type, Service Independent Parameters (SIP) und Service Specific Parameters. Das Element Service Type definiert den Typ des Dienstes, z.b. Premium Service (7). Das Element Service Independent Parameters beschreibt allgemeine Eigenschaften eines Dienstes, die für alle Dienste sinnvoll interpretiert werden können. Dazu zählen: Verhandlungsfähigkeit der Anwendung (negotiation capability) gibt an, ob die Anwendung in der Lage ist, im Laufe der Datenübertragung eine Neuverhandlung durchzuführen. Verhandlungsintervall (negotiation interval) gibt an, für welche Zeit die vereinbarte Dienstgüte und Preis gelten. Läuft diese Zeit ab, muß eine Neuverhandlung durchführen. Aus der Sicht der regelmäßigen Neuverhandlung kann RNAP mit RSVP verglichen werden, in dem dieses Konzept den Namen soft state trägt. Das Verhandlungsintervall von RNAP kann man mit dem cleanup timeout interval von RSVP vergleichen ((4), Punkt 2.3). Im Unterschied zu RSVP, wo die Anwendung für den regelmäßigen Versand der Resv-Nachrichten ((4), Punkt 2.1) verantwortlich ist, kann in RNAP diese Funktionalität der Anwendung von abgenommen werden. Möglichkeit der Unterbrechung (preemption capability) gibt an, ob die Bereitstellung des Dienstes während des aktuellen Verhandlungsintervalls vom Netz unterbrochen kann. Der Sinn von dieser Option ist es, im Fall der Resourcenknappheit den Anwendungen Vorzug zu geben, mit denen ein Dienst ohne Möglichkeit der Unterbrechung ausgehandelt wurde. Dabei ist der Preis einies ununterbrechbaren Dienstes für den Anwender höher als der eines unterbrechbaren. Es folgt ein kurzes kurzes Szenario, das dem Leser den Zweck dieser Option verdeutlichen soll. Im Beispielszenario gibt es zwei Anwendungen. Die erste Anwendung ermöglicht das Anhören eines Internet-Radiosenders, die zweite erlaubt die Durchführung einer Videokonferenz zwischen zwei Teilnehmern. Der Nutzer der ersten Anwendung ist bereit, die Möglichkeit der eventuellen Unterbrechung oder Qualitätsverschlechterung der Übertragung in Kauf zu nehmen, falls sie durch niedrigere Kosten ausgeglichen wird. Deswegen fordert die erste Anwendung einen Dienst mit der Möglichkeit der Unterbrechung vom Netz an. Für die Nutzer der zweiten Anwendung steht die Sicherstellung der Übertragungsqualität während der gesamten Videokonferenz im Vordegrund, auch wenn es höhere Kosten bedeutet. Die zweite Anwendung fordert daher einen Dienst ohne Möglichkeit der Unterbrechung vom Netz an. Startzeit und Endzeit (Starting / Ending Time) definieren die Zeit, wann der Nutzer den Dienst in Anspruch nehmen will. Dieser Parameter ist optional und ermöglicht die Reservierung der Resourcen in voraus. Damit soll es z.b. möglich sein, Netzwerkresourcen für eine wichtige Videokonferenz vorsorglich bereits eine Woche vor der Konferenz zu reservieren.

17 KAPITEL 3. AUFBAU UND FUNKTIONSWEISE VON RNAP 14 Das Element Service Specific Parameters (SSP) beschreibt die dienstspezifischen Eigenschaften eines Dienstes, wie z.b. minimale Datenrate, maximale Jitter oder mittlere Fehlerrate (siehe A.2) Price Das Feld Price enthält die Preisinformationen zu dem in Feld Service beschriebenen Dienst Typen der RNAP-Nachrichten Query sendet dem lokalen NRN die Query-Nachricht, um die Preisinformationen zu einem oder mehreren verfügbaren Diensten anzufragen. Für diese Nachricht ist nur das Feld Service relevant. Quotation Beim Erhalt der Query-Nachricht sendet NRN dem die Quotation-Nachricht mit den Verfügbarkeits- und Preisinformationen zu den in Query-Nachricht angeforderten Diensten. Für diese Nachricht sind die Felder Service und Price relevant. Reserve sendet dem NRN die Reserve-Nachricht, um beim NRN den Dienst mit einer bestimmten Güte für einen oder mehreren Datenströme oder Datenstromaggregate (siehe 3.3) anzufordern. Eine Reserve-Nachricht enthält einen oder mehrere (Id,Service,Price) Tripel. Dabei identifiziert Id den Datenstrom, für den die im Service spezifizierte Dienstgüte angefordert wird. Commit Die Commit-Nachricht wird von NRN als Antwort auf die Reserve-Nachricht geshickt. Jedem (Id,Service,Price) Tripel aus der Reserve-Nachricht entspricht ein 4-Tupel (Status,Id,Service,Price) in der Commit-Nachricht. Dabei gibt das Feld Status an, ob der in Reserve-Nachricht angeforderte Dienst bereitgestellt werden kann oder nicht. Die Entscheidung über die Bereitstellung des Dienstes kann sowohl von NRN selber als auch von externen Netzeinheiten, wie z.b. Bandwidth Broker (17) in der diffserv-architektur getroffen werden. Das Feld Status kann folgende Werte annehmen: Close Accepted : der angeforderte Dienst wird bereitgestellt. Felder Id,Service und Price haben übliche Bedeutung. Rejected : der angeforderte Dienst kann nicht bereitgestellt werden. Das Feld Service enthält die Angaben über die bestmögliche Dienstgüte, die vom Netz aktuell bereitgestellt werden kann. Admit Incomplete: der angeforderte Dienst wird mit einer schlechteren Dienstgüte als gefordert (dafür aber zu einem niedrigeren Preis) bereitgestellt. Die Felder Service und Price enthalten die Angaben über die bereitgestellte Dienstgüte und den Preis dafür. sendet dem NRN die Close - Nachricht, um die Sitzung zu beenden. Damit wird die Bereitstellung der vereinbarten Dienstgüte für alle Datenströme dieses s eingestellt.

18 KAPITEL 3. AUFBAU UND FUNKTIONSWEISE VON RNAP 15 Release Die Release-Nachricht wird von NRN an verschickt und bestätigt die Close- Nachricht. Optional kann die Release-Nachricht die Information über die Kosten der gesamten Sitzung enthalten. Preempt Falls der zwischen und NRN vereinbarte Dienst als unterbrechbar (siehe Möglichkeit der Unterbrechung, Seite 13) gilt, kann NRN durch den Versand der Preempt- Nachricht dem NRN mitteilen, daß die Bereitstellung des Dienstes unterbrochen wird. Der Grund dafür könnte z.b. Fehlen der Resourcen für die als ununterbrechbar vereinbarten Dienst sein Beispiel für typischen Verhandlungsablauf Die Ablauf einer typischen Verhandlung von RNAP wird am Modell aus 2.1 (Seite 3) und dem Beispielszenario aus (Seite 5) demonstriert. Im Beispielszenario will der Nutzer der Anwendung R 1 vom Sender S 1 Daten mit einer bestimmten Dienstqualität empfangen. Dabei wird die Übetragung der Daten von dem Nutzer der Anwendung R1 initiiert. RNAP ist im Unterschied zu RSVP ist ein weder sender- noch empfängerorintiertes Protokoll. Die Reservierung eines Dienstes kann sowohl von dem Sender als auch von dem Empfänger initiiert werden, was was durch die im Vergleich zu RSVP größere Intelligenz der NRNs in RNAP-C bzw. der Router in RNAP-D erreicht wird. Bei der Verhandlung gibt der verhandelnde an, ob der Dienst für den Versand oder Empfang der Daten von der Gegenseite angefordert wird. Weiter wird der Ablauf der Verhandlung zwischen den Anwendungen und dem Netz für das oben beschriebene Beispielszenario geschildert.

19 KAPITEL 3. AUFBAU UND FUNKTIONSWEISE VON RNAP Verhandlungsablauf in RNAP-Centralized von Emfpänger 1 NRN von Netz A NRN von Netz B NRN von Netz C von Sender 6 Query Query Query Query Verhandlung Quotation Quotation Quotation Quotation Reserve Reserve Reserve Reserve 8 Commit Commit Commit Commit Asynchrone Quotation- Nachricht Quotation Quotation Quotation Quotation 9 Reserve Reserve Reserve Reserve Neuverhandlung Commit Commit Commit Commit Ende der Sitzung Close Release Close Release Close Release Close Release 12 Abbildung 3.5: Verhandlungsablauf in RNAP-Centralized Die Verhandlung zwischen dem Emfpänger und den beteiligten Netzen läuft auf folgende Weise ab: 0. Die Anwendung teilt ihrer mit, welchen Dienst mit welchen Eigenschaften für welchen Datenstrom sie vom Netz in Anspruch nehmen möchte. Ab diesem Zeitpunkt übernimmt die Sicherstellung der Dienstgüte dieses Datenstroms. 1. sendet seinem NRN die Query-Nachricht, um die Verfügbarkeit und Preise des Dienstes mit gewünschten Güte anzufragen. 2. Der NRN A leitet die Query-Nachricht an den NRN B weiter. Auf diese Weise wird die Query- Nachricht bis zum NRN im Zielnetz NRN C weitergeleitet. 3. Der NRN im Zielnetz ermittelt die Verfügbarkeit und Preis des Dienstes in seinem Netz, fragt beim nach, ob die Anwendung in der Lage ist, Daten für den Dienst bereitzustellen und sendet die Quotation-Nachricht an den NRN B zurück. 4. NRN B ermittelt die Verfügbarkeit und den Preis des Dienstes in seinem Netz, addiert seinen Preis zu dem vom NRN C eingetragenen Preis und leitet die Quotation-Nachricht an den NRN A weiter.

20 KAPITEL 3. AUFBAU UND FUNKTIONSWEISE VON RNAP NRN A verhält sich wie NRN B und leitet die von ihm um Preisinformationen aktualisierte Quotation-Nachricht an den von Emfpänger 1 weiter. 6. wertet die Quotation-Nachricht aus und entscheidet, ob der Dienst in Anspruch genommen werden soll. Bei einer positiven Entscheidung sendet die Reserve-Nachricht an seinen. Die Reserve-Nachricht wird ähnlich zu der Query-Nachricht zu dem NRN von Zielnetz weitergeleitet. 7. Der NRN C macht notwendige Resourcenreservierungen und sendet als Bestätigung der erfolgreichen Verhandlung die Commit-Nachricht an den von Sender. Dabei wird der Preis des Dienstes wie bei der Quotation-Nachricht inkrementell berechnet. 8. Der von Sender empfängt die Commit-Nachricht und informiert die Anwendung über die Verfügbarkeit des Dienstes mit der gewünschten Dienstgüte. Die Anwendung kann den Empfang der Daten beginnen. 9. NRN von Netz C versendet in regelmäßigen Abständen die Quotation-Nachricht mit Preisinformationen. 10. Da in RNAP das soft state -Verfahren benutzt wird, aktualisiert von Empfänger die Reservierung durch regelmäßigen Versand der Reserve-Nachricht. Der Ablauf ist dabei identisch zum Ablauf beim Versand der Reserve-Nachricht bei der ersten Verhandlung. 11. Der Empfänger möchte die Sitzung unterbrechen und sendet die Close-Nachricht an den Sender. 12. Der Sender bestätigt den Abbau der Sitzung durch den Versand der Release-Nachricht Verhandlungsablauf in RNAP-Distributed Der Verhandlungsablauf in RNAP-Distributed ist ähnlich zum Verhandlungsablauf in RNAP-Centralized. Da in RNAP-Distributed aber keine zentrale Verwaltungseinheit in Form von NRN existiert, übernehmen die Router innerhalb des Netzes die Bearbeitung von RNAP-Nachrichten und die Durchführung von Resourcenreservierungen. 3.3 Aggregation von Microflows Nach dem Aufbau einer RNAP-Sitzung muß jeder beteiligte NRN (in RNAP-C) oder Router (in RNAP-D) Informationen zu allen Microflows dieser Sitzung verwalten. Durch die Verwaltung der Informationen für jeden einzelnen Microflow wird es möglich, jedem Microflow genau die für ihn vereinbarte Dienstgüte sicherzustellen. Der entscheidende Nachteil dieser Vorgehensweise ist die schlechte Skalierbarkeit in Bezug auf die Anzahl von Microflows. Die Verwaltung der Daten zu einzelnen Microflows auf Backbond-Routern, welche Pakete von zehn- oder hunderttausenden Microflows weiterleiten, ist technisch unmöglich oder höchst ineffezient. Ein möglicher Ansatz zur Lösung dieses Problems besteht darin, die Microflows mit gleichen oder ähnlichen Anforderungen an die Dienstgüte zu den Microflow-Aggregaten zusammenzufaßen. Dabei wird ein Microflow-Aggregat aus der Sicht der RNAP-Architektur als eigenständiger Microflow betrachtet. Dieser Ansatz basiert zum großen Teil auf der Arbeit Aggregation of RSVP for IPv4 and IPv6 Reservations (1). Es wird zuerst die Aggregation der Microflows betrachtet, die das gleiche Zielnetz haben. Auf die Behandlung der Aggregation der Microflows mit verschiedenen Zielnetzen sowie die Möglichket der

21 KAPITEL 3. AUFBAU UND FUNKTIONSWEISE VON RNAP 18 mehrstufigen Aggregation wird aus Platzgründen verzichtet. Es wird die Aggregation in RNAP-D betrachtet, dabei wird das Szenario in der folgenden Abbildung benutzt: S1 B5 B10 Netz A B6 B9 Netz C S2 B4 B7 Backbone-Netzwerk B8 B11 B2 B13 E1 Netz B B3 B12 Netz D B14 B1 E2 Anwendung Interner Router Netzwerk NRN Network Resource Negotiator B2 Border Router Host Resource Negotiator Microflow Microflow-Aggregat Abbildung 3.6: Aggregation und Deaggregation in RNAP-D Am Beispiel des obigen Szenarios werden einige Begriffe präzisiert: Aggregation Unter Aggregation versteht man die Zusammenfaßung mehrerer Microflows mit gleichen oder änhlichen Anforderungen an die Dienstgüte zu einem einzigen Datenstrom, der Aggregat heißt. Dabei ergeben sich die Dienstgüteanforderungen des Aggregats aus den Dienstgüteanforderungen einzelner Microflows. Die Bandbreite des Aggregats wird durch Aufaddieren der Bandbreiten der Microflows berechnet. Falls sich die restlichen Parameter der Microflows wie Latenz oder Jitter leicht unterscheiden, wird dem Aggregat eine Dienstgüte zugewiesen, so daß die Dienstgüteanforderungen von allen beteiligten Microflows erfüllt sind. Im obigen Szenario wird die Aggregation von Microflows S 1 E 1 und S 2 E 2 zu einem Aggregat von dem Router B 6 durchgeführt. Aus der Sicht des Routers B 7 existiert statt der beiden Microflows nur noch ein einziger Datenstrom B 7 B 9. Aggregationspunkt ist der Border Router, an dem die Aggregation erfolgt. Deaggregation Um die Microflows wieder einzeln behandeln zu können, müßen aus dem Aggregat ursprüngliche

22 KAPITEL 3. AUFBAU UND FUNKTIONSWEISE VON RNAP 19 Microflows wiederhergestellt werden. Dafür wird das Verfahren der Deaggregation benutzt. Im obigen Beispiel erfolgt die Deaggregation der Microflows für das Zielnetz C am Router B 9. Deaggregationspunkt ist der Border Router, an dem die Deaggregation erfolgt. Die Aggregation und Deaggregation der Microflows erfolgt durch die Aggregation und die Deaggregation der RNAP-Nachrichten an den Aggregation- bzw. Deaggregationspunkten. Für die Aggreation der RNAP-Nachrichten werden Elemente Aggregation Flag und Aggregate Flow Id des Feldes Id der RNAP-Nachricht benutzt (siehe Abbildung 3.4). Geht man von den Microflows S 1 E 1 und S 2 E 2 aus, werden die Query- und Reserve-Nachrichten für die beiden Microflows am Router B 6 aggregiert. So werden im obigen Szenario die Query- und Reserve-Nachrichten der beiden Microflows am Router B 6 zu einer einzigen Query- bzw Reserve-Nachricht zusammengeführt. Diese Nachricht wird dann an den Router B 7 weitergeleitet, der die Resourcenreservierung für den Aggregat der Microflows vornimmt. Gleichzeitig sendet der Router B 6 die beiden Querybzw. Reserve-Nachrichten direkt an den Deagregationspunkt B 9, um die Wiederherstellung einzelner RNAP-Nachrichtne aus dem Aggregat zu ermöglichen. 3.4 Gebührenerfassung und Gebührenberechnung In dieser Sektion wird die Unterstützung von RNAP für die Erfaßung und Berechnung der Gebühren für die Nutzung der Dienste dargestellt. Zuerst wird das Kommunikationsprotokoll aus der Sicht der Gebührenefaßung betrachtet, weiter wird auf die Probleme der Preisgestaltung in RNAP-C und RNAP-D eingegangen RNAP-Kommunikationsprotokoll und Gebührenefaßung RNAP-Nachrichten Query, Reserve und Quotation enthalten das Feld Price (siehe 3.2). Folgende Abbildung zeigt den Aufbau von diesem Feld: Typ der Nachricht ID Service New Price Current Charge Accumulated Charge Account Price Charge Fraction Other options Data Abbildung 3.7: RNAP-Kommunikationsprotokoll und Gebührenefaßung Das Feld Price besteht aus folgenden Elementen: 1. New Price enthält den Preis des Dienstes für das nächste Verhandlungsintervall (siehe 3.4.1). Einheiten für den Preis sind dienstspezifisch, beispielsweise könnten Währung/Zeiteinheit oder Währung/Megabyte als Einheiten dienen. In diesem Fall kann die Anwendung Kosten für das aktuelle Verhandlungsintervall durch das Multiplizieren der Intervalldauer mit der entsprechenden Zeiteinheit ausrechnen.

23 KAPITEL 3. AUFBAU UND FUNKTIONSWEISE VON RNAP Current Charge enthält die Kosten des vorhergehnden Verhandlungsintervalls. Als Einheit für dieses Feld dient eine Währung. 3. Accumulated Charge enthält die bisher aufgelaufenen Kosten der gesamten Sitzung. Als Einheit für dieses Feld dient eine Währung 4. Data Das Feld Data wird in der Query- und Reserve-Nachricht benutzt. Dieses Feld wird von dem ausgefüll, der die RNAP-Nachricht erzeugt. Es hat folgende Elemente: Account enthält die Kontoinformationen des Absenders der RNAP-Nachricht. Diese Kontoinformationen werden für die Gebührenberechnung und später für die Abrechnung benutzt. Charging Fraction gibt den Anteil der Gebühren für die Nutzung des Dienstes, die der Absender der RNAP-Nachricht zu zahlen bereit ist. Möchte z.b. der Absender der RNAP- Nachricht nur für die Hälfte der Nutzungsgebühren aufkommen, setzt er den Wert von Charging Fraction auf 0.5 (in der Annahme, daß die Gegenseite die andere Hälfte von Gebühren übernimmt). Im Fall, daß die Gegenseite die gesamten Gebühren übernehmen soll, wird dieses Feld auf 0 gesetzt. Other options Das Feld Other options ist optional und für anwendugsspezifische Informationen reserviert. Die Bedeutung einzelner Feldelemente hängt von dem Typ der Nachricht ab. Nach der Eröffnung einer Sitzung sendet der vom Sender eine Query-Nachricht an den vom Empfänger. Dabei füllt er die Felder Account und Charging Fraction aus. Das Feld Account dient zur Identefizierung des Nutzers der Anwendung. Als Antwort auf die Query-Nachricht erhält der eine Quotation-Nachricht. Das Feld New Price dieser Nachricht enthält die Preise für die Dienste, die im Service-Teil dieser Nachricht beschrieben sind. Falls der Nutzer den mitgeteilten Preis akzepziert, anwortet mit einer Reserve-Nachricht, in der ähnlich zu Query-Nachricht Felder Account und Charging Fraction ausgefüllt sind. Nach der erfolgreichen Resourcenreservierung erhält der die Commit-Nachricht, bei der im Feld New Price Preise für die bereitgestellten Dienste aufgeführt sind. Während der Übertragung führt in regelmäßigen Abständen Neuverhandlungen durch (siehe und ). Dafür wird in regelmässigen die Reserve-Nachricht gesendet. Commit-Nachrichten, die als Antworten auf diese Reserve-Nachricht versandt werden, enthalten neben dem Preis des Dienstes im Feld New Price auch die gesamten Kosten der Sitzung im Feld Accumulated Charge sowie die Kosten des vorhergehenden Verhandlungsintervalls im Feld Current Charge. Die Gebührenerfaßung wird an den einzelnen Elementen der RNAP-Architektur(NRN in RNAP-C, Router in RNAP-D) durch die Auswertung des Felds Account der Reserve-Nachricht möglich, da es die Zuweisung von einer RNAP-Reservierung zu einem bestimmten Nutzerkonto erlaubt Preisgestaltung in RNAP-D In der verteilten Architektur RNAP-D ist ein Router für die Verwaltung der Gebühreninformationen zu jedem von seinen Microflows verantwortlich. Der Preis für die Benutzung eines Dienstes setzt

24 KAPITEL 3. AUFBAU UND FUNKTIONSWEISE VON RNAP 21 sich aus Preisen zusammen, die einzelne Router auf der Übertragungsstrecke angeben. Das erfolgt auf folgende Weise: bei der Weiterleitung der Commit-Nachricht, die als Bestätigung der erfolgreichen Resourcenreservierung dient, werden von jedem Router Elemente New price, Current Charge, Accumulated Charge des Feldes Price aktualisiert, und zwar werden der von diesem Router verlangte Preis bzw. die bereits entstandenen Kosten zu den Werten in diesem Feldern aufaddiert. Beim Erhalt der Commit-Nachricht kann durch Auswerten dieser Felder den Preis bzw. die enstandenen Kosten für die gesamte Übertragungsstrecke abfragen Preisgestaltung in RNAP-C In der zentralisierten Architektur RNAP-C wird die Gebühreninformation von dem gesamten Netz durch den zugehörigen NRN verwaltet. Router im Netz stellen dem NRN die Informationen bereit, die für die Gebührenberechnung notwendig sind, wie z.b. der Datenvolumen oder die Datenrate einzelner Microflows. NRN faßt diese Informationen zusammen und wendet eine Preisgestaltungsstrategie an, um die Preise und Gebühren für jeden einzelnen Microflow zu berechnen. Nach der Berechnung werden die Preise und Gebühren ähnlich wie bei RNAP-C durch Aufaddieren der Werte in der Commit-Nachricht dem Initiator der Verhandlung mitgeteilt.

25 Kapitel 4 Zusammenfassung In dieser Arbeit wurde das Rahmenwerk für die Signallisierung der Diensgüteanforderungen RNAP untersucht. Es wurden Annahmen über die Netzwerkumgebung definiert und Anforderungen formuliert, die an RNAP gestellt werden. Weiter wurde gezeigt, auf welche Weise und mit welchen Mechanismen RNAP die gestellten Anforderungen erfüllt. Es wurden Eigenschaften von RNAP betrachtet, die es von den konkurrierenden Konzepten unterscheiden. Dazu zählen: Unterstützung der Mechanismen zur Gebührenerfassung und Gebührenberechnung. Unterstützung der bestehenden Konzepte zur Sicherung der Dienstgüte wie int-serv oder diffserv. Möglichkeit der mehrstufigen Aggregation von Microflows Möglichkeit der erneuten Verhandlung während der laufenden Datenübertragung. Möglichkeit, die Verhandlung sowohl von der Sender- als auch der Emfpängerseite zu initiieren. Obwohl es noch Bedarf an der Weiterentwicklung und Verfeinerung des Konzepts besteht, kann das Rahmenwerk als Grundlage fr die Implementierung des QoS-Rahmenwerks der nächsten Generation dienen. 22

26 Anhang A Einführung in QoS in IP-Netzen A.1 Was ist QoS? QoS steht für Quality of Service, also die Dienstqualität oder die Dienstgüte. Allgemein versteht man unter QoS die Fähigkeit des Netzes, einzelnen Netzelementen wie Routern oder Anwendungen eine bestimmte Dienstgüte garantieren zu können. Speziell in IP-Netzen wird mit Dienst die Übertragung der IP-Pakete zwischen Netzknoten (z.b. Hosts oder Routern) gemeint. Weiter wird QoS in IP-basierten Netzwerken betrachtet. Die Dienstgüte in solchen Netzwerken wird durch die sogenannten QoS-Parameter charakterisiert. Wichtigste davon sind in folgender Sektion aufgeführt. A.2 Wichtige QoS-Parameter Folgende Erläuterungen beziehen sich auf die IP-basierte Netze.(14) Bandbreite (bandwidth) ist ein Maß für die Kapazität des Übertragungkanals, also für die Grösse der Daten die innerhalb einer Zeiteinheit vom Sender aufs Medium gelegt werden können. Die Bandbreite wird in kilobits per second (Kbps) und megabits per second (Mbps) gemessen. Latenz ist die Zeit zwischen dem Versand eines IP-Pakets durch den Sender der und dem Empfang dieses IP-Pakets durch den Empfänger. Diese Zeit setzt sich aus 1. Übertragungszeiten auf dem Medium 2. Bearbeitungszeiten in den Zwischenknoten(z.B. Routern) zusammen. Jitter tritt auf, falls Pakete, die in gleichen Zeitabständen vom Sender verschickt wurden mit verschiedenerr Latenz am Empfänger ankommen. Quantitativ kann Jitter durch Varianz der Latenzzeiten abgeschätzt werden. Fehlerrate (packet loss) ist das Verhältnis zwischen der Anzahl von verlorengagangenen und verschickten IP-Paketen zwischen zwei Netzknoten. Verfügbarkeit eines Dienstes (service availability) 23

27 ANHANG A. EINFÜHRUNG IN QOS IN IP-NETZEN 24 A.3 Implementierung von QoS Die IP-basierten Netze (wie z.b. Internet) wurden ursprünglich als Best Effort -Netze konzipiert. Das heißt, es werden vom Netz ausdrücklich keine Garantien für eine bestimmte Dienstgüte übernommen. In der letzten Zeit wurden einige Konzepte für die Erweiterung der bestehenden IP-Netze um QoS entwickelt, dabei haben sich int-serv (3) und diff-serv (2) als Standarde etabliert.

28 Abbildungsverzeichnis 2.1 Modell für ein IP-basiertes Netzwerk Modell des Netzwerks mit s RNAP-Centralized Architektur RNAP-Distributed Architektur Format einer RNAP-Nachricht Verhandlungsablauf in RNAP-Centralized Aggregation und Deaggregation in RNAP-D RNAP-Kommunikationsprotokoll und Gebührenefaßung

29 Literaturverzeichnis [1] Baker, F. ; Iturralde, C. ; Faucheur, F. L. ; Davie, B.: RFC 3175: Aggregation of RSVP for IPv4 and IPv6 Reservations. September Status: INFORMATIONAL. [2] Blake, S. ; Black, D. ; Carlson, M. ; Davies, E. ; Wang, Z. ; Weiss, W.: RFC 2475: An Architecture for Differentiated Services. Dezember Status: PROPOSED STANDARD. [3] Braden, R. ; Clark, D. ; Shenker, S.: RFC 1633: Integrated Services in the Internet Architecture: an Overview. Juni Status: INFORMATIONAL. [4] Braden, Ed., R. ; Zhang, L. ; Berson, S. ; Herzog, S. ; Jamin, S.: RFC 2205: Resource ReSerVation Protocol (RSVP) Version 1 Functional Specification. September Status: PROPOSED STANDARD. [5] Ford, P. ; Yavatkar, R. ; Baker, F. ; Zhang, L. ; Speer, M. ; Braden, R.: RFC 2998: A Framework for Integrated Services Operation over Diffserv Networks. Februar Status: INFORMATIONAL. [6] Heinanen, J. ; Finland, Telia: RFC 2597: Assured Forwarding PHB Group. Februar Status: INFORMATIONAL. [7] Jacobson, V.: RFC 2597: An Expedited Forwarding PHB. Februar Status: INFORMA- TIONAL. [8] McCann, J. ; Deering, S. ; Mogul, J.: RFC 1981: Path MTU Discovery for IP version 6. August Status: PROPOSED STANDARD. [9] Mogul, J. C. ; Deering, S. E.: RFC 1191: Path MTU discovery. November Obsoletes RFC1063 (10). Status: DRAFT STANDARD. [10] Mogul, J. C. ; Kent, C. A. ; Partridge, C. ; McCloghrie, K.: RFC 1063: IP MTU discovery options. Juli Obsoleted by RFC1191 (9). Status: UNKNOWN. [11] Mogul, J. C. ; Postel, J.: RFC 950: Internet Standard Subnetting Procedure. August Updates RFC0792 (15). See also STD0005 (? ). Status: STANDARD. [12] Postel, J.: RFC 760: DoD standard Internet Protocol. Januar Obsoleted by RFC0791, RFC0777 (14; 13). Obsoletes IEN123 (? ). Status: UNKNOWN. Not online. [13] Postel, J.: RFC 777: Internet Control Message Protocol. April Obsoleted by RFC0792 (15). Obsoletes RFC0760 (12). Status: UNKNOWN. Not online. [14] Postel, J.: RFC 791: Internet Protocol. September Obsoletes RFC0760 (12). See also STD0005 (? ). Status: STANDARD. 26

30 LITERATURVERZEICHNIS 27 [15] Postel, J.: RFC 792: Internet Control Message Protocol. September Obsoletes RFC0777 (13). Updated by RFC0950 (11). See also STD0005 (? ). Status: STANDARD. [16] Shenker, S. ; Partridge, C. ; Guerin, R.: RFC 2212: Specification of Guaranteed Quality of Service. September Status: PROPOSED STANDARD. [17] Team, QBone Signaling D. QBone Bandwidth Broker Architecture, Oktober 2001 [18] Wroclawski, J.: RFC 2211: Specification of the Controlled-Load Network Element Service. September Status: PROPOSED STANDARD. [19] X. Wang, H. S. A Framework for Resource Negotiation and Pricing in the Internet. April 2000 [20] X. Wang, H. S. An Integrated Resource Negotiation, Pricing and QoS Adaptation Framework for Multimedia Applications. April 2000 [21] X. Wang, H. S. Pricing Network Resources for Adaptive Applications in a Differentiated Services Network. April 2000 [22] X. Wang, H. S. RNAP: A Resource Negotiation and Pricing Protocol. April 2000