Die Internet- Protokollweltmidas1.e-technik.tu-ilmenau.de/~webkn/Webdaten/Lehre/WS2017/Di… ·...

Die Internet-Protokollwelt Wintersemester 2017/18

Prof. Jochen Seitz 1

Die Internet-Protokollwelt7. QUALITY OF SERVICE IM INTERNET

Übersicht

Quality of Serive, QoS

Integrated Services, IntServ

Differentiated Services, DiffServ

DIE INTERNET-PROTOKOLLWELT - 7. QUALITY OF SERVICE IM INTERNET 238



Dienstgüte – Quality of Service, QoS„Quality of Service is the collective effect of service performance,

which determine the degree of satisfaction of a user of the service”

ITU-T Recommendation E.800

Von der Zufriedenheit des Benutzers hängt die Güte des Dienstes (QoS) ab – jedoch fehlt die technische Überprüfbarkeit

Notwendig:

◦ Dienstgüteparameter qualitative Eigenschaften eines Dienstes

◦ Dienstklassen Grad der Garantien

◦ Dienstverträge zu garantierende QoS-Parameter, deren Werte und Grad der Einhaltung (Dienstklasse)

◦ Dienstgütemechanismen Maßnahmen zur Einhaltung von Dienstverträgen

◦ Management der Dienste Verwaltung und Reservierung von Ressourcen


Dienstgüteparameter (QoS-Parameter)Leistungsorientierte Dienstgüteparameter

◦ Verzögerung:

Ende-zu-Ende-Verzögerung (Delay)

Schwankung der Ende-zu-Ende-Verzögerung (Jitter)

◦ Durchsatz:

minimaler/mittlerer/maximaler Durchsatz(in [bit/s] oder [Pakete/s])

maximaler Burst (Länge, Dauer)

ZuverlässigkeitsorientierteDienstgüteparameter

◦ Medienabhängige Fehlerraten:

z. B. Bitfehlerrate des Übertragungsmediums

◦ Ressourcenabhängige Fehlerraten:

z. B. Paketverlustraten in den Warteschlangen der Zwischensysteme

Funktionale Dienstgüteparameter

◦ Sicherheit

◦ Gruppenkommunikation (Multicast)




RessourcenRessourcen◦ Netzwerkressourcen

Übertragungskapazität (Bandbreite, Kanäle)

Übertragungszeit

◦ Systemressourcen auf Zwischen- und Endsystemen

Pufferspeicher

Rechenzeit

Reservierung von Ressourcen◦ durch Ressourcenmanagement

Verwaltung von Ressourcen

Belegung,

Überwachung,

Freigabe, ...

Verteilung der Reservierungsnachrichten durch Reservierungsprotokolle


Dienstklassen (QoS-Klassen)Deterministische Klasse

◦ exakte Einhaltung vorgegebener Schranken der QoS-Parameter

◦ Ressourcenreservierung exklusiv für einen Nutzer

keine Konflikte möglich, aber „Besetztfall” (keine Ressourcen mehr übrig)

Statistische Klasse

◦ Wahrscheinlichkeit für die Einhaltung vorgegebener Schranken: Verzögerung für 95% der Pakete unter 100ms

◦ Überbuchung von Ressourcen

Konflikte möglich (je höher die Wahrscheinlichkeit der Garantie, desto geringer sind Ressourcenkonflikte)

Bestmögliche Klasse

◦ keinerlei Garantien für Dienstgüteparameter

◦ keinerlei Ressourcenreservierung

Konflikte „vorprogrammiert”




Dienstgüte – VereinbarungAngabe der Dienstgüte:◦ Quantitativ,

d. h. nachprüfbar durch Messung

Angabe eines Mittelwerts

Angabe eines Toleranzintervalls

◦ Qualitativ, d. h. relativ, eventuell nachweisbar durch Vergleich, beeinflusst durch subjektive, menschliche Wahrnehmung


Dienstgüte im InternetInternet zunehmend Teil der Unternehmensinfrastruktur

◦ Virtuelle Private Netze, VPN

◦ Allgemein verfügbare Kundenschnittstelle (z. B. Home-Banking)

◦ Multimediales Internet (MP3, Voice over IP, Streams, Spiele, ...)

Aber:

◦ Fehlende Unterstützung für Anwendungsanforderungen (Durchsatzgarantie, Echtzeitanforderung, begrenzte Verzögerungsschwankung, etc.)

◦ Ressourcenmangel im Internet, insbesondere an den Netzübergängen

◦ Erfolg der Paketweiterleitung abhängig von der aktuellen Netzlast




Einfache Maßnahmen für Dienstgüte„Unendliche” Übertragungskapazität

◦ Beliebige(?) Steigerung der Kapazität durch Verwendung spezieller Übertragungstechniken (beispielsweise WDMA)

◦ Problem: Stauung an Netzübergängen mit unterschiedlichen Kapazitäten, dadurch keine Voraussage bezüglich Verzögerung und Jitter

Einfache Prioritäten◦ Berücksichtigung unterschiedlicher Anforderungen durch unterschiedliche Priorisierung

◦ Problem: keine Ressourcenreservierung, also keine Garantie

Adaptive Applikationen◦ Anpassung an die aktuellen Gegebenheiten im Netz

◦ Mehr Intelligenz in den Anwendungen

◦ Problem: Mindestmaß an Dienstgüte muss garantiert werden


„Traditionelle” AnwendungenKein hartes Zeitlimit für die Auslieferung der Daten

◦ Daten werden durch lange Verzögerungszeiten nicht unbrauchbar

◦ Anwendungen können mit heutigem Internet gut auskommen

◦ Andere Bezeichnung: elastische Anwendungen

Verzögerungsanforderungen unterschiedlicher elastischer Anwendungen können beliebig

stark variieren

◦ Interaktiv (z. B. telnet) – wenig tolerant gegenüber Verzögerungen

◦ Interaktiv mit Bursts (z. B. ftp) – tolerant gegenüber Verzögerungen in der Dateiübertragungsphase

◦ Asynchron (z. B. E-Mail) – sehr tolerant gegenüber Verzögerungen




Echtzeit-AnwendungenHarte zeitliche Anforderungen an die Auslieferung der Daten

◦ Audio- und Videoströme

◦ Fabrikautomatisierung (Industrie 4.0)

Spezielle Eigenschaften von Audio-/Videoanwendungen

◦ Zu spät eintreffende Daten werden wie verlorengegangene behandelt

◦ Nutzung redundanter Information, um Datenverluste auszugleichen

◦ Erhöhung dieser Redundanz durch spezielle Codierung und Fehlerbehandlung

◦ Adaptivitätsmöglichkeiten:

Verzögerungsadaptivität

Ratenadaptivität


Aktivitäten bei der Bereitstellung von Dienstgüte Dienstgütespezifikation und -abbildung

◦ Dienstvertrag (Service Level Agreement, SLA)

◦ Keine standardisierten QoS-Parameter

◦ Unterschiedliche QoS-Parameter in verschiedenen ISO/OSI-Schichten

Dienstgüteaushandlung, Zugangskontrolle und Ressourcenreservierung◦ Unterschiedliche Beteiligte

Dienstgüteüberwachung, -aufrechterhaltung und -richtlinien◦ Policies

◦ Benachrichtigung der Kommunikationspartner, wenn QoS nicht mehr aufrecht erhalten werden kann

Dienstgüteneuaushandlung und -adaption




Bereitstellung von Dienstgüte


Wegewahl

Warteschlangen &Bedienstrategien

Daten-pakete

KlassifiziererVerkehrsmeterVerkehrsformer

Ressourcen-verwaltung

Reservierungs-protokolle

Zugangs-kontrolle

BenutzerkontenPreismodellAbrechnung

Signali-sierung

DienstvertragGewünschte Dienstgüte muss spezifiziert werden:

◦ qualitative oder quantitative Aussagen durch den Dienstbenutzer

◦ Gleichzeitig Charakterisierung des Verkehrs durch den Dienstbenutzer

◦ Überprüfung der geforderten Güte durch den Diensterbringer

◦ Angebot einer Dienstgüte unter Berücksichtigung der geäußerten Wünsche und der momentanen Auslastung: Dienstvertrag oder Verkehrsvertrag

Einhaltung der so ausgehandelten Dienstgüte

◦ strikt bei deterministischen Klassen

◦ mit eventuellen kurzzeitigen Verletzungen bei statistischen Klassen

Dienstanbieter muss Nachweis über seine Zugeständnisse führen




VerkehrsmeterVerkehrsmeter begutachten Datenströme

◦ Überprüfung der Konformität mit dem Verkehrsvertrag, keine aktive Beeinflussung des Datenverkehrs

◦ Eingabe:

Verkehrsprofil (Datenstrom, Dienstgüteparameter, Dienstklasse)

◦ Ausgabe:

Konformitätsaussage

Binäre Entscheidung

Mehrere Konformitätsklassen

◦ Beispiele:

Token Bucket (überprüft Senderate und Burst)

Leaky Bucket (zusätzlich noch Verkehrsformung)


T

Verkehrsmeter: Beispiel Token Bucket„Eimer” mit maximaler Füllung B Token

Token-Ankunftsrate R [Token/s]

Überwachung der Einhaltung einer Rate R [byte/s] mit einer Toleranz (Burst) B

◦ Pakete sind konform, wenn bei Paketankunft noch genügend Token im Eimer vorhanden sind(1 byte = 1 Token)

◦ Sind zu wenige Token da, werden Pakete als nicht konform markiert

◦ Es erfolgt keine Pufferung, bis genügend Token vorhanden sind


T

T

TTT

konform

nichtkonform

TokenBucket

T



VerkehrsformerVerkehrsformer beeinflussen aktiv die Charakteristik des Verkehrs:◦ Ziel: Wiederherstellung von Konformität bzw. eines bestimmten Verkehrsmusters

◦ Beispiele:

Verkehrsglätter

Verwerfer

Degradierer

ordnet Paketen eine niedrigere Dienstkategorie zu


Verkehrs-glätter

Verwerfer

Degra-dierer

Verkehrsformer: Beispiel Leaky Bucket„Eimer” mit maximaler Füllung B [byte]

Pakete werden in den Eimer gefüllt und „tröpfeln“ mit der Rate R [byte/s] aus dem Eimer heraus (undichter Eimer)

Neben Überwachung der Einhaltung einer maximalen Rate R und einer Toleranz (Burst) B zusätzlich Glättung des Ausgangsstromes auf die Rate R:◦ Ein Paket der Länge L byte wird gesendet, wenn L byte aus

dem Eimer getropft sind

◦ Hat ein neu ankommendes Paket kein Platz mehr im Eimer, wird es verworfen

◦ Pakete werden somit so lange verzögert, bis das Senden konform zur Rate ist


LeakyBucket



KlassifikationselementeKlassifizierer identifizieren Datenströme aus der Menge aller Pakete:

◦ Zuordnung Paket Verkehrsprofil

◦ Arten von Klassifizierern:

Klassifizierer für aggregiertes Verhalten (Aggregate Classifier)

Viele Datenströme werden gleich behandelt

Sehr einfache und schnelle Klassifikation

Klassifizierer anhand mehrerer Paketkopffelder (Multi-Field Classifier)

Kombination eines oder mehrerer Paketkopffelder wie IP-Adressen, IP-Protokollfeld, Port-Nummern, ...

Sehr komplizierte und aufwändige Klassifikation

◦ Informationen für die Klassifikation werden in der Vermittlungseinrichtung gespeichtert

Verkehrsprofile

Reservierungsdaten


Warteschlangen und BedienstrategienWarteschlangen speichern Pakete

◦ Wie sie ankommen (First In First Out)

◦ Nach Priorität (verschiedene Warteschlangen)

◦ Nach Dringlichkeit (Earliest Deadline First)

Bedienstrategien bestimmen die nächste Warteschlange

◦ Reihenfolgefestlegung der exklusiven Ressourcennutzung (Bandbreite, Speicher) in Abhängigkeit von einem Scheduling-Algorithmus, z. B.:

Round Robin

Simple Priority Queueing

Weighted Fair Queueing


Scheduler



Scheduling-AlgorithmenZiel: einfache Implementierung◦ Für alle Dienstklassen

◦ Problem: In schnellen Netzen nur sehr wenig Zeit für die Bearbeitung einzelner Dateneinheiten(bei 1 Gbit/s ATM müssen ca. 2.358.490 Pakete/s bearbeitet werden)

◦ Speicheranforderungen zur Zustandshaltung möglichst gering

◦ Zugriffsgeschwindigkeit auf den aktuellen Zustand möglichst effizient

Anforderungen bei best-effort Diensten:◦ Fairness: gleichmäßige Verteilung aller Ressourcen gemäß steigenden Anforderungen, aber nur so viele

Ressourcen wie benötigt

◦ Absicherung: keine Beeinträchtigung von (fairen) Kommunikationsvorgängen durch andere Kommunikationsvorgänge, die ein höheres Datenaufkommen haben


Aggregierung von DatenströmenZusammenfassen mehrerer Datenströme hinsichtlich der Bedienreihenfolge

◦ Vorteil: reduzierte Zustandshaltung

Wichtiges Argument in großen Netzen

◦ Vorgehensweise

Einteilung der Datenströme in Klassen

Aggregierte Betrachtung der Klassen

◦ Problem

Datenströme innerhalb einer Klasse nicht voneinander abgesichert

Fairness und Absicherung dann nur noch zwischen den Klassen und nicht mehr innerhalb einer Klasse

Keine festen Garantien mehr für einzelne Ströme innerhalb einer Klasse




RessourcenverwaltungProbleme:◦ Beschränkte Ressourcen

Übertragungskapazität

Pufferkapazität

Rechenzeit

Konkurrenz der Anwendungen um gemeinsam zu benutzende Ressourcen

Aufgaben:◦ Regelung von Ressourcenzugang und -nutzung

Ansätze:◦ Reservierung „on demand”

◦ Langzeit-Reservierung

◦ Vor-Reservierung


Dienstgüteaushandlung bei MulticastZusätzliche Problematik durch Konflikte bei der Dienstgüteaushandlung für mehrere Empfänger:

Konfliktauflösung beim Sender:

◦ Abweisung des Verbindungsaufbauwunsches

◦ Ablehnung eines einzelnen Empfängers

◦ Aufbau der Multicast-Verbindung mit unterschiedlicher Dienstgüte

Filterung des Datenstroms

Hierarchische Codierung der Daten


Empfänger 2(min 5Mbit/s; max 10Mbit/s)

Empfänger 1(min 20Mbit/s; max 40Mbit/s)[1;50]

Sender(min 1Mbit/s; max 50Mbit/s)

Router



Dienstgütearchitekturen im InternetEinführung von Dienstgütemechanismen schwierig und teuer:

◦ Änderung der Router im Internet teuer

◦ Reservierung von Netzwerkressourcen aufwändig

◦ Abrechnung der genutzten Dienste unklar

◦ Skalierbarkeit unklar

Anforderungen seitens der Anwendungen und der Anwender werden aber immer relevanter

Bislang mehrere Ansätze:

◦ IP Type of Service

◦ Stream Transport Protocol Version 2, ST2

◦ Integrated Services, IntServ

◦ Differentiated Services, DiffServ


Dienstgüte in IPv4IP-Basiskommunikationsdienst (Wiederholung):

◦ Verbindungslos und unzuverlässig

◦ Abschnittsweise Weiterleitung, speichervermittelt

◦ „Best Effort”-Diensterbringung

Entwurfsprinzipien:◦ Keine Zustandsinformationen in den Zwischensystemen

◦ Datenstrom-spezifische Informationen in den End-Systemen (Fate Sharing)

◦ Einfaches und schnelles Netz mit intelligenten Endsystemen

Dienstgüte nur im „Type-of-Service”-Feld beschrieben

Auf dieser Basis keine Garantien möglich


VorrangVerzö-gerung

Durch-satz

Zuver-lässigk.

0 0

0 3 4 5 6 7 bit1 2



Integrated Services ArchitectureArchitektur für integrierte Dienste (Mitte der 90er Jahre)

◦ Unterstützung multimedialer Anwendungen

◦ Abkehr vom zustandslosen Router

Zustand je Datenstrom in jedem Router

Besondere Behandlung der Pakete wie in Verkehrsprofil abgelegt

Erhalten der Robustheit durch „Soft State”-Reservierung über spezielles Reservierungsprotokoll

◦ Ergänzung der bestehenden Internet-Architektur

◦ Integration gruppenkommunikationsbasierter Anwendungen


Das Signalisierungsprotokoll RSVPZiel:

◦ Signalisierung von Reservierungsanforderungen in IP-basierten Netzen Resource Reservation Protocol, RSVP

◦ Datentransfer weiterhin über IP

Konzept:

◦ Empfängerbasierte Signalisierung von Reservierungsanforderungen für unidirektionalen Datenfluss

◦ Unterstützung heterogener Dienstqualität bei Multicast

◦ Soft States

Periodische Erneuerung der Zustandsdaten durch Endsysteme

Keine Quittung für die Reservierung an den Empfänger

Kein expliziter Abbau der Reservierung erforderlich, da Zeitgeber zugeordnet sind, nach deren Ablauf die jeweilige Reservierung gelöscht wird




RSVP – Ablauf


PATH

RESV

RESV = Reservation

RSVP-Router

RSVP-Router

Probleme der Integrated Services ArchitectureSkalierbarkeit

◦ Jeder Router verwaltet Zustandsinformation (Qualitätsparameter, Sender- und Empfängeradressen) pro

Datenstrom

◦ Paketweiterleitung wird durch die Klassifizierung jedes einzelnen Pakets komplexer

◦ Leistung des Routers sinkt bei großer Anzahl von Reservierungen

Frei wählbare Qualitätsparameter

◦ Router muss eine sich dynamisch ändernde Anzahl von Dienstgüteparametern unterstützen

◦ Paket-Scheduling ist daher komplex und nicht so leistungsstark




Differentiated Services1997 erste Vorschläge, um skalierbare Dienstgüte im Internet bereitzustellen (D. Clark, V. Jacobson)

Vorläuferdokument „A Two-Bit Architecture” (RFC 2638)

Anfang 1998 Arbeitsgruppe „Differentiated Services” in der IETF

Ziele:◦ Qualitativ bessere, anwendungsunabhängige Dienste mittels einfacher, skalierbarer Mechanismen

(Keep It Simple and Stupid)

◦ Reduktion der Komplexität im Netzinnern: weniger Zustände, weniger Funktionalität

◦ Kompatibilität zu existierenden Anwendungen und Endsystemen

Vorgehensweise:◦ Aggregation des Verkehrs im Netzinnern zu Dienstklassen

◦ Aggregierte Klassifikationszustände, einfache Paketklassifizierer

◦ Komplexere Funktionen (Klassifizierung, Markierung, Überprüfung) nur an Netzgrenzen


Differentiated Services im ÜberblickIN – Interior Node

BN – Boundary Node


DS-Domäne A

DS-Domäne B

DS-Region

Sender Empfänger

DS-Grenzknoten(Boundary Node)

DS Innerer Knoten(Interior Node)

Eingangs-knoten

Ausgangs-knoten

BNBN

BNBN

ININ

IN

BNBN

BN

BN

IN

IN IN

IN



Differentiated Services – DiensteEnde-zu-Ende Dienste

Spezifikation über SLA

Kombination aus den PDBs

Domänenweites Weiterleitungsverhalten

Per-Hop Behavior, PHB + verkehrsbeeinflussende Maßnahmen

Abschnittweises Paketweiterleitungsverhalten

Paketbearbeitung innerhalb eines Knotens

Bestimmte Warteschlangenmechanismen


Dienstspezifikation

Per-Domain Behavior(PDB)

Per-Hop Behavior(PHB)

PHB-Implementierung

Vergleich Differentiated vs. Integrated Services

Best Effort Integrated ServicesDifferentiated

Services

QoS-Garantie Keine Pro DatenstromAggregierte

Datenströme

Konfiguration KeinePro Sitzung Ende-zu-

EndeZwischen Domänen

Typ der Garantie Keine Soft individuell Aggregiert

Dauer der Garantie

KeineKurzlebig (Sitzung,

Soft State)Langfristig

Zustandshaltung Keine Pro DatenstromPro aggregierter

Reservierung

Signalisierung Keine RSVP Noch nicht definiert

Multicast-Unterstützung

IP-MulticastEmpfängerorientiert,

heterogen

IP-Multicast, sonst keine spezielle Unterstützung




LiteraturBRAUN, Torsten (1999): IPnG: Neue Internet-Dienste und virtuelle Netze. Protokolle, Programmierung und Internetworking. Heidelberg: dpunkt-Verlag (dpunkt-Lehrbuch).

BRAUN, Torsten; DIAZ, Michel; GABEIRAS, José Enríquez; STAUB, Thomas (2008): End-to-End Quality of Service overHeterogeneous Networks. Berlin, New York: Springer-Verlag.

HARDY, Daniel; MALLEUS, Guy; MEREUR, Jean-Noel (Hg.) (2002): Networks. Internet · Telephony · Multimedia. Berlin: Springer.

ITU-T Recommendation E.800 (09/2008): Series E: Overall Network Operation, Telephone Service, Service Operation and Human Factors - Quality of Telecommunication Services: Concepts, Models, Objectives and Dependability Planning – Terms and Definitions Related to the Quality of Telecommunication Services.

SZIGETI, Tim; HATTINGH, Christina (2005): End-to-End QoS Network Design. Quality of Service in LANs, WANs, and VPNs. Indianapolis: Cisco Press.

VAUGHAN, Collin (2012): Network Quality of Service. New York: Nova Science Publishers (Computer Science, Technology and Applications).

VEGESNA, Srinivas (2001): IP Quality of Service. Indianapolis: Cisco Press.

ZHANG, Ruonan; CAI, Lin; PAN, Jianping (2016): Resource Management for Multimedia Services in High Data Rate Wireless Networks. Cham, Switzerland: Springer.


Requests for CommentsBRADEN, Bob; ZHANG, Lixia; BERSON, Steve; HERZOG, Shai; JAMIN, Sugih (1997): Resource ReSerVation Protocol (RSVP) --Version 1 Functional Specification. Internet Engineering Task Force (IETF) (Request for Comments, 2205).

WROCLAWSKI, John (1997): The Use of RSVP with IETF Integrated Services. Internet Engineering Task Force (IETF) (Request for Comments, 2210).LI, Tony; REKHTER, Yakov (1998): A Provider Architecture forDifferentiated Services and Traffic Engineering (PASTE). Internet Engineering Task Force (IETF) (Request forComments, 2430).

NICHOLS, Kathleen; BLAKE, Steven; BAKER, Fred; BLACK, David L. (1998): Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers. Internet Engineering Task Force (IETF) (Request for Comments, 2474).

NICHOLS, Kathleen; JACOBSON, Van; ZHANG, Lixia (1999): A Two-bit Differentiated Services Architecture for the Internet. Internet Engineering Task Force (IETF) (Request for Comments, 2638).

NICHOLS, Kathleen; CARPENTER, Brian (2001): Definition ofDifferentiated Services Per Domain Behaviors and Rules for theirSpecification. Internet Engineering Task Force (IETF) (Request forComments, 3086).GROSSMAN, Dan (2002): New Terminology and Clarifications forDiffserv. Internet Engineering Task Force (IETF) (Request forComments, 3260).

KOMPELLA, Kireeti; LANG, Jonathan P. (2004): Procedures forModifying the Resource reSerVation Protocol (RSVP). Internet Engineering Task Force (IETF) (Request for Comments, 3936).AMANTE, Shane; CARPENTER, Brian; JIANG, Sheng (2011): Rationale for Update to the IPv6 Flow Label Specification. Internet Engineering Task Force (IETF) (Request for Comments, 6436).


Die Internet- Protokollweltmidas1.e-technik.tu-ilmenau.de/~webkn/Webdaten/Lehre/WS2017/Di… ·...

Documents

Transcript of Die Internet- Protokollweltmidas1.e-technik.tu-ilmenau.de/~webkn/Webdaten/Lehre/WS2017/Di… ·...