Vorlesung Rechnernetze II Teil 3 Sommersemester 2007

Transkript

1 Vorlesung Rechnernetze II Teil 3 Sommersemester 2007 Christian Grimm Fachgebiet Distributed Virtual Reality (DVR) Lehrgebiet Rechnernetze

2 Übersicht Architektur von Routern Queues, Switching Fabric Head of Line Blocking Virtual Input Queues Queueing und Quality of Service Active Queue Management: Random Early Detect Scheduling: Weighted Fair Queueing Policing: Leaky Bucket und Token Bucket IETF Integrated Services Resource Reservation Protocol IETF Differentiated Services C. Grimm 25. April 2007 Folie 2

3 Architektur von Routern grundlegende Funktionen eines Routers Ausführen von Routing-Algorithmen Ermittlung des geeigneten Weges Bearbeiten von Routing-Protokollen z.b. RIP, OSPF, BGP Transfer von IP-Paketen zwischen ein- und ausgehenden Ports Komponenten eines Routers Input Port 1 Output Port 1 Switching Fabric Input Port m Output Port n Routing Processor typisch m=n, d.h. sämtliche Ports arbeiten full duplex C. Grimm 25. April 2007 Folie 3

4 Aufgaben der Input Ports Input Port Line Termination Data Link Processing Lookup and Forwarding (Queueing) Switching Fabric Line Termination Aufgaben des Physical Layer Data Link Processing Aufgaben des Data Link Layer Lookup and Forwarding / Queueing (Erläuterung s.u.) Anmerkungen in der Praxis werden mehrere Ports auf Line Cards zusammengefasst Full Duplex Mode erfordert Input und Output Port an jedem Interface C. Grimm 25. April 2007 Folie 4

5 Lookup and Forwarding Bestimmen des Ziels Auswerten der Ziel-Adresse aus IP-Paket Bestimmung des geeigneten Weges zu dem Ziel Suche des geeigneten Output Port durch Lookup in Forwarding Table bei einfachen Routern erfolgt Lookup durch Routing Processor besser Forwarding Table wird von Routing Processor erstellt lokale Kopien werden in jedem Input Port gespeichert Weiterleiten (Forwarding) des IP-Paketes an die Switching Fabric Queueing wird dann notwendig, wenn Switching Fabric belegt ist (s.u.) empfangene Kontroll- und Routing-Informationen werden direkt an Routing Processor übergeben C. Grimm 25. April 2007 Folie 5

6 Forwarding Table Lookup Aufgabe effiziente Suche in einer Liste von IP-Adressen oder IP-Netzen IPv4: 32 Bit Match IPv6: 64 Bit Match, da nur 64 Bit des routing prefix relevant (s.u.) CIDR: longest Prefix Match, Länge der zu suchenden Pattern variiert Verarbeitung sollte mindestens mit Line Speed erfolgen Line Speed ist die Datenrate des Input Port Beispiel: Berechnung der maximalen Dauer eines Lookup bei Line Speed betrachtet wird ein Link OC-48 entspricht einer Datenrate von 2,4 GBit/s angenommen wird eine mittlere Paketgröße von 256 Byte/Paket entspricht Bit/Paket ein vollständig gefüllter Link enthält somit ca. 1, Pakete/s Lookup in Line Speed erfordert entsprechend viele Forwarding Table Lookups pro Sekunde daraus folgt maximale Dauer eines Forwarding Table Lookup von 853,3 ns Anmerkung: Wert variiert bei schwankenden Paketgrößen C. Grimm 25. April 2007 Folie 6

7 Suchalgorithmen für Forwarding Table Lookup lineare Suche kommt nicht in Frage, da O(N), N = Anzahl der Elemente digitale Suchverfahren mit Binary Search Trees (BST) bis zu O(log 2 (N)) möglich, N = Anzahl der Elemente Tries (von retrieval, auch Prefix Tree), Radix Tree oder PATRICIA Tries (Practical Algorithm to Retrieve Information Coded in Alphanumeric) bis zu O(log 2 (M)) möglich, M = Länge des Schlüssels Abbildung durch Hardware Content Addressable Memory (CAM) IP-Adresse stellt Speicheradresse in CAM dar Inhalt der Speicheradresse ist die gesuchte Forwarding Information Anmerkung zu IPv6 IPv6 enthält eine vorgegebene Struktur der Adressen (Global) Routing Prefix Subnet ID Interface ID Lookup kann zweistufig auf (Global) Routing Prefix und Subnet ID unterteilt werden C. Grimm 25. April 2007 Folie 7

8 Switching Fabric Variante 1: Shared Memory Switching über Memory IP-Pakete werden in Speicher des Routing Processors kopiert und dort ausgewertet nach Auswertung werden IP-Pakete in Speicher des Output Port kopiert 1 1,3 2 3 (Shared) Memory 2 Performance Routing Processor Bandbreite des Speichers sei B, durch zwei Kopiervorgänge ergibt sich max. Rate B/2 Verbesserung durch Shared Memory Ports und Routing Processor teilen gemeinsamen Speicher dieser Ansatz erfordert lediglich den Austausch von Speicheradressen, nicht von Inhalten Nachteil: aufwändiges Speicher-Management besonders bei modularen Routern übliches Verfahren in Routern mittlerer Leistungsklasse C. Grimm 25. April 2007 Folie 8

9 Switching Fabric Variante 2: Shared Bus Switching über einen gemeinsamen Bus IP-Pakete werden direkt von Input Port an Output Port gesendet es kann jeweils nur ein IP-Paket über den gesamten Bus übertragen werden 1 2 Bus 3 Performance Routing Processor maximaler Durchsatz wird durch Bandbreite des Bus bestimmt Implementierung Verfahren setzt Nutzung einer lokalen Forwarding Table in Input Ports voraus eine schlechte Alternative wäre ständige Kommunikation mit Routing Processor übliches Verfahren in Routern einfacher und mittlerer Leistungsklasse C. Grimm 25. April 2007 Folie 9

10 Switching Fabric Variante 3: Crossbar Switching über Crossbar (Interconnection Network) sämtliche Input und Output Ports sind über eine Matrix miteinander verknüpft Verfahren ermöglicht mehrere parallele Vermittlungen gleichzeitig (hier Pakete 1 und 2) es kann weiterhin jeweils nur ein IP-Paket an einen Output Port übertragen werden z.b. Router Cisco GSR: 16 x 2,4 GBit/s Routing Processor Performance hängt wesentlich von Verkehrsmix ab Worst Case: Verkehr von allen Input Ports auf einen Output Port Best Case: Verkehr von allen Input Ports auf unterschiedliche Output Ports übliches Verfahren in Routern hoher Leistungsklasse weitere Verbesserung durch parallele Crossbars möglich C. Grimm 25. April 2007 Folie 10

11 Aufgaben der Output Ports Output Port Switching Fabric Queueing Data Link Processing Line Termination Auslesen der IP-Pakete aus (Shared) Memory, Bus oder Crossbar Übertragen der IP-Pakete an Zieladresse bei gefüllten Links kurzzeitige Speicherung der IP-Pakete (Queueing)! Line Termination Aufgaben des Physical Layer Data Link Processing Aufgaben des Data Link Layer C. Grimm 25. April 2007 Folie 11

12 Queueing im Input Port Problem Switching Fabric verteilt aggregierten Verkehr aller Input Ports an Output Ports bei blockierter Switching Fabric ist Queueing im Input Port notwendig Head-of-the-Line (HOL) Blocking vorderstes Paket in Queue blockiert nachfolgenden Pakete Beispiel: 2 blockiert 1 in Input Port 3 zum Zeitpunkt T 0 (ggf. sogar noch bei T 1!) HOL Blocking führt zu unnötigen Paketverlusten HOL Blocking muss vermieden werden! Switching Fabric 0 4 Switching Fabric Zeitpunkt T 0 Zeitpunkt T 1 C. Grimm 25. April 2007 Folie 12

13 Vermeidung HOL: Virtual Output Queueing Ansatz in jedem der M Input Ports werden N separate Queues für jeden Output Port geführt d.h. Pakete werden bereits im Input Port nach Zielen sortiert zentraler Scheduler arbeitet alle Queues Q(m,n) für Output Port n ab, z.b. Round Robin Input 1 Q(1,1) Output 1 A 1,1 (n). Q(1,N) Input M. Q(M,1) Switching Fabric. Output N. Q(M,N) Anmerkungen Erweiterung durch n parallele Scheduler, jeweils den Output Ports zugeordnet in der Regel gilt M=N, da jeder Port gleichzeitig Input und Output sein kann C. Grimm 25. April 2007 Folie 13 Centralized Scheduler

14 Queueing im Output Port Problem Switching Fabric liefert mehr IP-Pakete als über den Link gesendet werden können Queuing IP-Pakete werden in Queue des Output Port kurzzeitig gespeichert Reduzierung der Queue wird erst dann wieder möglich, wenn Switching Fabric weniger IP-Pakete liefert als über Link gesendet werden können (Erinnerung: Little s Law!) bei Überlauf der Queue in Input oder Output Port entstehen Paketverluste! Switching Fabric 7 4 Switching Fabric Zeitpunkt T 0 Zeitpunkt T n C. Grimm 25. April 2007 Folie 14

15 Queueing Auswirkungen des Queueing überlaufende Queues in Routern sind der wesentliche Grund für Paketverluste Queuing in Routern hat deshalb maßgeblichen Einfluss auf die Netzwerk-Performance Erinnerung Netzwerk-Performance: Datenrate, Packet Loss, Delay und Jitter das zentrale Problem: Auswahl des nächsten zu sendenden IP-Pakets aus Queue geeignete Auswahl ist Aufgabe des so genannten Packet Schedulers durch Packet Scheduler wird Quality of Service maßgeblich gesteuert Strategien (Algorithmen) für Auswahl des nächsten IP-Pakets einfachster Ansatz: First Come First Served (FCFS) alternativ werden einzelne Verbindungen betrachtet: Weighted Fair Queueing (WFQ, s.u.) mögliches Verhalten bei gefüllter Queue Drop Tail: Verwerfen neu eintreffender IP-Pakete Drop Random: IP-Pakete werden zufällig aus Queue gelöscht Active Queue Management (AQM) gezieltes Markieren und Löschen von IP-Paketen aus der Queue wird bereits bei Erreichen bestimmter Füllstände ausgelöst, nicht erst bei gefüllten Queues C. Grimm 25. April 2007 Folie 15

16 AQM: Random Early Detect (RED) RED ist ein weit verbreiteter AQM-Algorithmus eingehende IP-Pakete werden zufällig ausgewählt und markiert (mark) bei Erreichen bestimmter Füllstände werden markierte Pakete verworfen (drop) Ziel: Congestion Avoidance in Routern durch frühzeitigen Lastabwurf vereinfachte Darstellung des Algorithmus zunächst Berechnung des gewichteten Mittelwerts avg k der Anzahl IP-Pakete in Queue Berechnung nach Exponential Weighted Moving Average (EWMA) vgl. EstimatedRTT in TCP w: Faktor für Wichtung des aktuellen Füllstandes gegenüber vergangenen Füllständen n: aktuelle Anzahl IP-Pakete in Queue avg k = ( 1 w ) avg k-1 + w n Berechnung der Wahrscheinlichkeit p a, dass ein eintreffendes IP-Paket markiert wird min th, max th : minimaler bzw. maximaler Threshold für die Anzahl IP-Pakete in Queue max p : maximaler Wert für die Wahrscheinlichkeit, dass ein Paket markiert wird count: Anzahl IP-Pakete seit dem letzten markierten IP-Paket p b = max p (avg k min th ) / (max th min th ) p a = p b / ( 1 count p b ) empfohlene Werte für Parameter und Bewertung von RED s. Literatur C. Grimm 25. April 2007 Folie 16

17 Quality of Service bisher: making the best of best effort Datenübertragung über TCP/IP ist konzipiert für Effektivität: Übertragung nutzt verfügbare Ressourcen optimal aus Fairness: dabei faire Nutzung der Ressourcen und faire Behandlung aller Teilnehmer Ansatz genügt für Anwendungen mit geringen Anforderungen, typisch z.b. Filetransfers neue Anwendungen stellen neue Anforderungen Echtzeitanwendungen stellen konkrete Anforderungen an die Netzwerk-Performance Einhaltung konkreter Anforderungen kann nach Best Effort nicht gewährleistet werden Folge: Echtzeitanwendungen könnten u. U. nicht oder nur temporär eingesetzt werden Frage wie kann die Qualität eines Dienstes im Internet gewährleistet werden? zwei Ansätze der IETF für Quality of Service (QoS) im Internet IETF Integrated Services enthält (Resource) ReSerVation Protocol (RSVP): Signalisierung von Reservierungen IETF Differentiated Services C. Grimm 25. April 2007 Folie 17

18 Quality of Service, Szenario 1 Konfiguration Link zwischen Routern R 1 und R 2 hat maximale Kapazität von 1,5 MBit/s Host H 1 möchte Video-Daten mit 1 MBit/s an Host H 3 senden Host H 2 möchte FTP-Daten mit 1 MBit/s an Host H 4 senden Video H 1 1 MBit/s H 3 H 2 1 MBit/s R 1 1,5 MBit/s R 2 H 4 FTP Problem Video-Anwendung ist bei mangelnder Performance nicht nutzbar Video-Daten müssen jedoch kontinuierlich mit 1 MBit/s übertragen werden Unterschreitung von 1 MBit/s führen ggf. zum Versagen des gesamten Dienstes FTP-Daten können durchaus verzögert und mit geringerer Rate übertragen werden C. Grimm 25. April 2007 Folie 18

19 Quality of Service, Szenario 1 Ansatz für Lösung Router sollte Video-Daten bevorzugt übertragen Router kann jedoch nicht zwischen Video- und FTP-Daten unterscheiden Video H 1 1 MBit/s H 3 H 2 1 MBit/s R 1 1,5 MBit/s R 2 H 4 FTP Forderung Markierung der IP-Pakete in Abhängigkeit des Inhalts z.b. über Type-of-Service (ToS, IPv4) oder Traffic Class (IPv6) im IP-Header diese Information kann bei AQM berücksichtigt werden C. Grimm 25. April 2007 Folie 19

20 Quality of Service, Szenario 2 Konfiguration wie Szenario 1 low-budget Video H 1 1 MBit/s H 3 H 2 1 MBit/s R 1 1,5 MBit/s R 2 H 4 Premium FTP Erweiterung Kunden zahlen für unterschiedliche Services Kunde von H 1 (Video-Daten) zahlt für low-budget -Service Kunde von H 2 (FTP-Daten) zahlt für Premium-Service C. Grimm 25. April 2007 Folie 20

21 Quality of Service, Szenario 2 Problem FTP-Daten sollten mit besserer Performance als Video-Daten übertragen werden den Routern ist jedoch nicht bekannt, für welche Services die Absender zahlen low-budget Video H 1 1 MBit/s H 3 H 2 1 MBit/s R 1 1,5 MBit/s R 2 H 4 Premium FTP Forderung Router sollten verschiedene Klassen von Verkehrsflüssen unterscheiden können z.b. anhand von IP-Adressen, Anwendungen (Ports) oder Service-Levels Entscheidung muss an Hand von Regeln auf Router getroffen werden Informationen von Anwendung (ToS bzw. Traffic Class) sind nicht unbedingt vertrauenswürdig C. Grimm 25. April 2007 Folie 21

22 Quality of Service, Szenario 3 Konfiguration wie Szenario 1 Video H 1 1 MBit/s H 3 H 2 1 MBit/s R 1 1,5 MBit/s R 2 H 4 FTP Erweiterung Router R 1 und R 2 enthalten QoS-Mechanismen zur Priorisierung der Video-Daten dem Video-Datenstrom wird damit zwischen R 1 und R 2 die volle Datenrate gewährt hier 1 MBit/s FTP-Daten stehen folglich 0,5 MBit/s zur Verfügung C. Grimm 25. April 2007 Folie 22

23 Quality of Service, Szenario 3 Problem H 1 sendet plötzlich Video-Daten mit einer Datenrate von 1,5 MBit/s IP-Pakete mit FTP-Daten können von R 1 nicht mehr berücksichtigt werden Video H 1 1 MBit/s H 3 H 2 1 MBit/s R 1 1,5 MBit/s R 2 H 4 FTP Forderung Überschreitungen der mit 1 MBit/s reservierten Verbindung zwischen R 1 und R 2 dürfen die Übertragung anderer Datenströme (hier FTP-Daten mit 0,5 MBit/s) nicht negativ beeinflussen d.h. Datenströme müssen voneinander isoliert werden C. Grimm 25. April 2007 Folie 23

24 Quality of Service, Szenario 3 Isolation Ansatz 1: Monitoring und Policing Monitoring an ausgewählten Stellen werden Datenströme gemessen typisch am Eingang, hier Edge-Router R 1 ggf. werden IP-Pakete markiert Verfahren und Kriterien s.u. Policing Regeln, nach denen bei Bedarf gezielt IP-Pakete verzögert oder verworfen werden werden in Abhängigkeit der verwendeten (und bezahlten) Services angewendet Ansatz 2: Verwendung logischer Links zwischen R 1 und R 2 werden logische Links von 1 MBit/s und 0,5 MBit/s eingerichtet d.h. Ansatz entspricht Zeit- oder Frequenzmultiplex damit typischer Nachteil des Multiplexing wird Link von H 1 und H 3 nicht genutzt, können freie Ressourcen nicht für FTP-Transfer genutzt werden C. Grimm 25. April 2007 Folie 24

25 Quality of Service, Szenario 4 Konfiguration wie Szenario 1 Video H 1 1 MBit/s H 3 H 2 1 MBit/s R 1 1,5 MBit/s R 2 H 4 Video Erweiterung Hosts H 1 und H 2 senden Video-Daten mit 1 MBit/s und gleichen Performance- Anforderungen C. Grimm 25. April 2007 Folie 25

26 Quality of Service, Szenario 4 Problem Datenströme übersteigen Kapazität des Links zwischen R 1 und R 2 bei gleichen Verlusten würden beide Datenströme mit 0,75 MBit/s übertragen entspricht mittlerer Verlustrate von 25 % beide Datenströme werden unbrauchbar Video H 1 1 MBit/s H 3 H 2 1 MBit/s R 1 1,5 MBit/s R 2 H 4 Video Forderung Forderungen der Anwendungen müssen geprüft und akzeptiert bzw. abgelehnt werden d.h. Anwendungen müssen Anforderungen an Performance mitteilen und reservieren können Router müssen entsprechend Anforderungen prüfen und akzeptieren oder ablehnen können hier: eine Anforderung kann akzeptiert werden, die andere wird abgelehnt C. Grimm 25. April 2007 Folie 26

27 Zusammenfassung grundlegender QoS-Prinzipien Packet Classification Klassifizierung der IP-Pakete anhand verschiedener Parameter z.b. anhand von IP-Adressen, Anwendungen (Ports) oder Service-Levels Isolation: Monitoring und Policing unterschiedliche Datenströme dürfen sich nicht gegenseitig stören bei Überschreitung der Anforderungen gezieltes Einwirken auf Verkehrsflüsse High Resource Utilization werden reservierte Ressourcen nicht genutzt, sollten sie anderen Datenströmen zur Verfügung gestellt werden Call Admission Anforderungen zur Reservierung von Ressourcen müssen formuliert, geprüft und akzeptiert oder abgelehnt werden Anmerkung: Anforderungen müssen Ende-zu-Ende erfüllbar sein Frage: wer formuliert die Anforderungen die Anwendung oder der Anwender? C. Grimm 25. April 2007 Folie 27

28 Scheduling First-Come-First-Served Discipline Link-Scheduling Discipline Auswahl des nächsten zu sendenden IP-Paketes aus Queue des Output Ports Eigenschaften First-Come-First-Served (FCFS) Discipline auch First-In-First-Out (FIFO) genau eine Queue in Output Port IP-Pakete werden in der Reihenfolge des Eintreffens gesendet Arrivals Departures Ablauf Queue Link (Packet in Service) Arrival t Packet in Service leer leer leer t Departure C. Grimm 25. April 2007 Folie 28

29 Scheduling Priority Queueing Discipline Annahme: den IP-Paketen wurden bereits Prioritäten zugewiesen z.b. durch ToS-Feld im IP-Header, s. o. Eigenschaften für jede Klasse von Prioritäten steht eine eigene Queue zur Verfügung innerhalb einer Queue werden IP-Pakete gemäß FCFS bearbeitet IP-Pakete werden nicht in der Reihenfolge des Eintreffens gesendet Queue 1: hohe Priorität Arrivals Departures Link Classifier Queue 2: niedrige Priorität Ablauf Arrival 4 5 t Packet in Service leer leer leer t Departure C. Grimm 25. April 2007 Folie 29

30 Scheduling Round Robin Discipline Eigenschaften IP-Pakete werden zirkulierend N verschiedenen Queues zugewiesen die N Queues werden zyklisch abgearbeitet IP-Pakete werden in der Reihenfolge des Eintreffens gesendet Work Conserving ist eine Queue leer, wird unmittelbar die nächste ausgelesen Queue 1 Arrivals Departures Link Ablauf Classifier Queue 2 Arrival t Packet in Service leer leer leer t Departure C. Grimm 25. April 2007 Folie 30

31 Scheduling Weighted Fair Queuing Discipline Eigenschaften Mischung aus Priority Queueing Discipline und Round Robin Discipline jeder Queue i wird eine Wichtung w i zugewiesen, i = 1,..., N Anteil der Service Time für eine Queue hängt von Wichtung ab z.b. erhalten Queues für Echtzeit-Daten höhere Wichtung IP-Pakete werden nicht in der Reihenfolge des Eintreffens gesendet Queue 1 w 1 Arrivals Departures w 2 Link Ablauf Classifier Queue 2 Arrival t Packet in Service leer leer leer t Departure C. Grimm 25. April 2007 Folie 31

32 Scheduling Weighted Fair Queuing Discipline Berechnung der Paketrate einer Weighted Fair Queue jede Queue i hat Anteil an gesamter Service Time von N w j = 1 i w j w i der Queue i steht im Mittel ein Anteil an der gesamten Paketrate R von R zu N w Anmerkung: die Paketrate entspricht nicht der Datenrate! j = 1 j C. Grimm 25. April 2007 Folie 32

33 Policing Regulierung der Daten- bzw. Paketrate Messen und Regulieren (Traffic Shaping) einer zeitabhängigen Größe Frage: über welchen Zeitraum wird gemessen und reguliert? Regulieren über kurze Zeitraum bewirkt z.b. hohe Glättung der Datenrate Beispiel: Regulieren auf 100 Pakete/s bewirkt eine höhere Glättung als Pakete/min Pakete/min lässt durchaus Pakete/s zu danach nur noch Pakete in 59 s Average Rate (mittlere Paket- oder Bitrate) Betrachtung der Rate über längeren Zeitraum, Größenordnung Minuten Peak Rate (maximale Paket- oder Bitrate) Betrachtung der Rate über kurzen Zeitraum, Größenordnung Sekunden Burst Size Anzahl der Pakete oder Bits innerhalb des kürzest möglichen Zeitraumes im Beispiel unten wird Zeitraum 10 ms betrachtet, in Praxis auch kleiner in der Praxis üblich: Kombination der drei Angaben Average Rate Pakete/min = 100 Pakete/s = 1 Paket /10 ms Peak Rate Pakete/min = Pakete/s = 15 Pakete/10 ms Burst Size Pakete/min = Pakete/s = 100 Pakete/10 ms C. Grimm 25. April 2007 Folie 33

34 Erläuterung von Paketraten und Burst Size Paketrate Burst übersteigt die Peak Rate! Peak Rate Average Rate Burst Size t Paketrate ungleiche mittlere Raten im Intervall [0,T 1 ] gleiche mittlere Raten im Intervall [0,T 2 ] Paketrate T 1 T 2 t Paketrate T 1 T 2 t T 1 T 2 t C. Grimm 25. April 2007 Folie 34

35 Regulieren der Datenrate Leaky Bucket Policer neue Pakete treffen mit variabler Rate ein Bucket enthält max. C Pakete Pakete fließen mit einer maximalen Rate r ab Füllen des Bucket der Bucket enthält maximal C Pakete jedes neue Paket wird im Bucket abgelegt, solange noch Platz vorhanden ist ist kein Platz vorhanden, wird Paket verworfen (entspricht einem Überlauf des Bucket) mit jedem Zeittakt T wird ein Paket aus Bucket übertragen enthält der Bucket Pakete, fließen Sie mit einer maximalen Paketrate r = 1 Paket / T ab d.h. Leaky-Bucket-Algorithmus begrenzt Peak Rate des Datenstrom auf maximale Paketrate r Implementierung Bucket wird als Warteschlange mit endlicher Anzahl Warteplätze dargestellt mit jedem Zeittakt wird das erste Paket aus der Warteschlange entnommen einfacher Übergang von Paket- auf Datenraten: es werden Byte anstatt Pakete gezählt C. Grimm 25. April 2007 Folie 35

36 Regulieren der Datenrate Token Bucket Policer neue Token werden mit Rate r generiert Bucket enthält max. b Token Arrivals Departures ggf. Warten auf Token im Bucket entferne ein Token aus Bucket Queue Link Füllen des Bucket neue Token werden mit der Rate r generiert Bucket enthält maximal b Token enthält Bucket weniger als b Token, werden neue Token in Bucket aufgenommen enthält Bucket b Token, werden neue Token verworfen Implementierung des Bucket als einfacher Zähler für die Token Erhöhung des Zählers mit jedem Zeittakt um ein Token, wenn Zähler < b Verringerung des Zählers mit jedem gesendeten Paket um ein Token einfacher Übergang von Paket- auf Datenraten: es werden Byte anstatt Pakete gezählt C. Grimm 25. April 2007 Folie 36

37 Regulieren der Datenrate Token Bucket Policer neue Token werden mit Rate r generiert Bucket enthält max. b Token Arrivals Departures ggf. Warten auf Token im Bucket entferne ein Token aus Bucket Queue Link Regulieren der Paketrate für jedes zu übertragende Paket wird ein Token aus Bucket entfernt falls Bucket leer ist, muss auf neue Token gewartet werden maximale Anzahl Pakete P, die während Zeitraum t den Policer verlassen: P = r t + b b entspricht Füllstand des Bucket zu Beginn der Übertragung es wird angenommen, dass der Bucket zu Beginn der Übertragung maximal gefüllt b = b r t entspricht der Anzahl neuer Token während des Zeitraums t daraus die maximale mittlere Paketrate m im Intervall t: m = P / t = (r t + b) / t = r + b / t für Bursts mit t 0 wird annähernd P = b d.h. das maximale Volumen eines Bursts entspricht der Größe b des Bucket für Bursts mit t > 0 laufen allerdings während des Bursts weitere Token in den Bucket (s. u.) C. Grimm 25. April 2007 Folie 37

38 Regulieren der Datenrate Token Bucket Policer Berechnung der maximalen Dauer eines Burst hier auf Datenraten bzw. einzelne Byte angewendet r: Bitrate, mit der neue Token generiert werden b: Kapazität des Bucket P: maximale Anzahl Byte, die während des Zeitraums t den Token Bucket Policer verlassen m = P / t: maximale mittlere Ausgaberate des Token Bucket Policer in Zeitraum t das maximal übertragene Volumen während eines Bursts der Dauer S ergibt sich zu P = r S + b Herleitung s. o. mit der maximalen Ausgaberate m ergibt sich ebenfalls das maximale Volumen des Burst über die Dauer S m = P S P = m S Gleichsetzen der beiden Ansätze liefert m S = r S + b Anmerkung: der einfache Ansatz S = b / m ist zur Berechnung der Dauer falsch, da während der Ausgabe des Burst weitere Token eintreffen! C. Grimm 25. April 2007 Folie 38 Herleitung s. o. nach S auflösen : ( m r ) S = b S = b m r

39 Anmerkungen Token Bucket Zusammenfassung Token Bucket Policer Average Rate über langen Zeitraum entspricht r Peak Rate m in Zeitraum (Burst Size) S wird durch b und r bestimmt Burst Size S wird durch b, r und m bestimmt (s. Peak Rate) Burst Size, Average Rate und Peak Rate sind nicht unabhängig voneinander! Frage: wie kann Datenrate des Burst unabhängig von S und b begrenzt werden? Antwort: durch Reihenschaltung von Token und Leaky Buckets d. h. Datenrate des Burst wird über Peak Rate des Leaky Bucket geregelt r 1 b Annahmen r 2 < m, d. h. Leaky Bucket begrenzt kurzzeitige Bursts r 2 > r 1, d. h. Leaky Bucket begrenzt über langen Zeitraum gesehen Average Rate des Token Bucket nicht C des Leaky Bucket sehr groß (keine Verluste) r 2 Burst Size wird zuerst durch b, r 1 und m bestimmt, dann zusätzlich durch r 2 Peak Rate wird in Leaky Bucket durch r 2 bestimmt Average Rate wird in Token Bucket durch r 1 bestimmt C. Grimm 25. April 2007 Folie 39

40 Beispiel zu Leaky und Token Bucket Eingangslast: Burst mit einer Dauer von 40 ms und einer Datenrate von 25 MBit/s R [MBit/s] a) Ausgabe nach einem Leaky Bucket mit r 1 = 2 MBit/s R [MBit/s] MBit/s für 40 ms t [ms] MBit/s für 500 ms t [ms] b) Ausgabe nach einem Token Bucket mit b = 250 KBit, m = 25 MBit/s, r 1 = 2 MBit/s R [MBit/s] MBit/s für 10,87 ms MBit/s für 364,13 ms t [ms] C. Grimm 25. April 2007 Folie 40

41 Beispiel zu Leaky und Token Bucket c) Ausgabe nach einem Token Bucket mit b = 500 KBit, m = 25 MBit/s, r 1 = 2 MBit/s R [MBit/s] d) Ausgabe nach einem Token Bucket mit b = 750 KBit, m = 25 MBit/s, r 1 = 2 MBit/s R [MBit/s] MBit/s für 21,74 ms 10 2 MBit/s für 228,26 ms t [ms] MBit/s für 32,61 ms MBit/s für 92,39 ms t [ms] e) wie c), danach Leaky Bucket mit r 1 = 10 MBit/s, C sehr groß (d. h. keine Verluste) R [MBit/s] MBit/s für 62,50 ms MBit/s für 187,49 ms t [ms] C. Grimm 25. April 2007 Folie 41

42 Beispiel zu Leaky und Token Bucket Berechnung Beispiel b) Dauer des Bursts b S = m r Bit = Bit/s Bit/s = 10,87 ms während des Burst übertragenes Datenvolumen P Burst = m S = Bit/s 10,87 ms = Bit verbleibendes Datenvolumen PRe st = Bit/s 40 ms PBurst = Bit Übertragungsdauer des verbleibenden Datenvolumens mit einer Datenrate von 2 MBit/s S P r PRe Bit/s Rest st Re st = = = 364,13 ms C. Grimm 25. April 2007 Folie 42

43 Beispiel zu Leaky und Token Bucket Berechnung Beispiel e) Frage: wie lange dauert das Regulieren des Datenstroms aus Abb. c) auf 10 MBit/s? Ansatz gesucht ist der Zeitpunkt t, an dem das Volumen des Datenstrom aus c) dem Volumen eines konstanten Datenstrom mit 10 MBit/s entspricht aus c): die Dauer des Bursts von 25 MBit/s beträgt 21,74 ms aus c): nach 21,74 ms (ab dem Zeitpunkt t 21,74 ms) treffen Daten mit einer Rate von 2 MBit/s ein 10 MBit/s t 10 MBit/s t t = 25 MBit/s 21,74 ms + 2 MBit/s 2 MBit/s t ( 10 MBit/s 2 MBit/s) t = ( 25 MBit/s 2 MBit/s) 23 MBit/s 21,74 ms = 8 MBit/s = 62,50 ms ( t 21,74 ms) = 25 MBit/s 21,74 ms 2 MBit/s 21,74 ms 21,74 ms Übertragungsdauer des verbleibenden Datenvolumens mit einer Datenrate von 2 MBit/s S 25 MBit/s 40 ms 10 MBit/s 62,50 ms 2 MBit/s Re st = = 187,49 ms C. Grimm 25. April 2007 Folie 43

44 Kombination von WFQ und Token Bucket r 1 b 1 Queue 1 w 1 Arrivals r n b n Link Departures Ansatz System enthält Queues für n verschiedene Flows mit Wichtungen w i (i = 1,..., N) Flow i erhält anteilige Paketrate R i an gesamter Paketrate R mit R i = R w i / Σw j vor jede Queue wird ein Token Bucket mit r i und b i geschaltet (mit r i < R i ) für dieses System lässt sich u. a. ein wichtiger QoS-Parameter, nämlich die maximale Verzögerung d max, die ein Paket in Queue i erfährt, angeben! Herleitung Classifier maximale Verzögerung d max erfährt das letzte Paket in einer voller Queue maximal b i Pakete in Queue i, Datenrate ist R i : d max = b i / R i = b i / (R w i / Σw j ) C. Grimm 25. April 2007 Folie 44 Queue N w N

45 IETF Integrated Services (IntServ) Ziel Architektur, um individuelle QoS-Garantien in IP-Netzen bereitzustellen Ansatz Router können ihre Ressourcen anteilig bestimmten Verkehrsströmen zuweisen erfordert Management der Ressource auf den Routern bevor eine Anwendung Daten über eine Verbindung mit gesicherten QoS-Parametern überträgt, werden die notwendigen Reservierungen auf den Routern vorgenommen dieser Vorgang wird Call Setup oder Call Admission bezeichnet die Anwendung teilt den Routern ihre Anforderungen mit erfordert Protokoll zur Übertragung von Reservierungs-Informationen die Beschreibung der Anforderungen erfolgt durch Rspec und Tspec (RFC 2210 und RFC 2215) Rspec: Reservation Specification, spezifiziert die QoS-Parameter (s.u.) Tspec: Traffic Specification, spezifiziert den zu sendenden Verkehr (s.u.) jeder Router zwischen Quelle und Ziel muss Reservierung durchführen und bestätigen können die Signalisierung der Reservierungen wird über ein eigenes Protokoll (RSVP, s.u.) übertragen Unterscheidung zwischen zwei Dienst-Klassen (RFCs 2211 und 2212) Guaranteed Quality of Service: mathematisch belegte Gewährleistung von Delay und Bandwidth Implementierung auf Routern z.b. durch dedizierte Token Buckets Controlled-Load Network Element Service: schwächere, aber auch unklare Gewährleistungen C. Grimm 25. April 2007 Folie 45

46 IETF Integrated Services (IntServ) Ablauf Quelle RSVP-Requests Ziel RSVP-Replies Quelle sendet RSVP-Request mit Anforderungen an ersten Router auf Weg zum Ziel Rspec und Tspec im RSVP-Request beschreiben die Anforderungen des Dienstes der Router vergleicht Anforderungen mit seinen verfügbaren Ressourcen können Ressourcen reserviert werden, wird der RSVP-Request an nächsten Router geleitet können Ressourcen nicht reserviert werden, wird negative RSVP-Reply an Quelle gesendet Ziel erhält schließlich RSVP-Request mit den gewünschten Anforderungen die RSVP-Reply wird möglichst über denselben Weg an die Quelle zurückgesendet erst jetzt werden Ressourcen auf Routern tatsächlich reserviert bei durchgehend erfolgreicher Reservierung erhält Quelle positive RSVP-Reply Quelle kann danach Daten der Anwendung über reservierten Pfad senden Fragen wie werden Reservierungen wieder frei gegeben? was passiert bei Änderung der Routen? skaliert dieses Verfahren? C. Grimm 25. April 2007 Folie 46

47 RSVP Spezifikation R. Braden, L Zhang et. al. Resource ReSerVation Protocol (RSVP) Version 1 Functional Specification. IETF RFC 2205, September 1997 danach zahlreiche ergänzende RFCs zu RSVP Entwurf Version 2: M. Brunner, R. Greco. Towards RSVP Version 2. IETF Draft, Oktober Eigenschaften von RSVP Ende-zu-Ende Austausch von Reservierungs- und Signalisierungs-Informationen dient dabei im Wesentlichen der Reservierung von Bandbreite (Datenrate) alle beteiligten Systeme (Sender, Empfänger und Router) müssen RSVP-fähig sein der Empfänger eines Datenflusses initiiert die Reservierung auf den Routern RSVP ist receiver-oriented setzt Multicast-Routing voraus, d.h. RSVP ist UDP-basiert wesentliches Ziel von RSVP war die Unterstützung multicast-basierter Videokonferenzen die Reservierungen müssen in bestimmten Abständen wiederholt werden (Soft State) nach Ablauf von Timeouts verfallen Reservierungen Router können Reservierungen zusammenfassen, s. Beispiel RSVP spezifiziert nicht die Umsetzung der Reservierungen auf den Routern C. Grimm 25. April 2007 Folie 47

48 RSVP Beispiel Situation: Quelle soll einen Video-Datenstrom an Multicast-Gruppe senden Quelle sendet zunächst RSVP-Request mit Reservierungswunsch an Multicast-Gruppe Router prüfen Reservierung und leiten RSVP-Request an nächsten Router weiter hier: A an B, B an C und D auf den Anschlussleitungen der Ziele stehen geringe Datenraten zur Verfügung diese Datenraten werden den Upstream-Routern in RSVP-Replies mitgeteilt Router können auf dem weiteren Rückweg Reservierungen zusammenfassen Router D fasst z.b. 100 kbit/s und 20 kbit/s zu 100 kbit/s zusammen, nicht zu 120 kbit/s Quelle kann Video-Daten von 3 MBit/s mit verschiedenen Layern senden Video-Datenstrom sollte mindestens drei Layer mit 20, 100, und kbit/s enthalten Problem: Router B und D müssen die richtigen Pakete aus Video-Datenstrom weiterleiten... Quelle A B kbit/s C D MBit/s 3 MBit/s kbit/s C. Grimm 25. April 2007 Folie 48

49 IETF Differentiated Services (DiffServ) Erfahrungen mit Integrated Services Verfahren skaliert nicht, individuelle Anforderungen können nicht bereitgestellt werden d.h. Reservierung beliebiger QoS-Parameter ist zu viel lediglich zwei Dienst-Klassen d.h. Guaranteed Quality of Service und Controlled-Load Network Service ist zu wenig kaum durchgehende IntServ- (d.h. RSVP-)Infrastruktur gegeben Spezifikation von DiffServ S. Blake, D. Black et. al. An Architecture for Differentiated Services. IETF RFC 2475, Dezember D. Grossman. New Terminology and Clarifications for Diffserv. IETF RFC 3260, April 2002 Ansatz von DiffServ Unterteilung in Edge- und Core-Router komplexe Funktionen auf Edge-Routern (und auf den Endgeräten) einfache Funktionen auf Core-Routern Bereitstellung von Komponenten, aus denen Dienst-Klassen definiert werden d.h. keine Vorgabe fester Dienst-Klassen wie bei IntServ C. Grimm 25. April 2007 Folie 49

50 IETF Differentiated Services (DiffServ) Edge Functions: Packet Classification and Traffic Conditioning Edge bezeichnet den DiffServ-fähigen Host oder den ersten DiffServ-fähigen Router Markieren des Differentiated Services Field (DS) im IP-Header (s.u.) Analogie zu einer Eintrittskarte Core Function: Forwarding untersucht IP-Header auf DS-Feld und leitet Paket an nächsten Router weiter Per-Hop Behaviour IP-Pakete werden im Core ausschließlich anhand dieser Markierung behandelt keine Berücksichtigung von Quell- oder Zieladeresse unterschiedliche Flows mit gleicher Markierung werden gleich behandelt (R1 R2 R3) Analogie: Inhaber gleicher Eintrittskarten werden gleich behandelt H 1 H 4 H 3 H 2 R 1 R 3 R 2 C. Grimm 25. April 2007 Folie 50

51 DiffServ Klassifizierung und Markierung Ablauf Classifier Marker Classifier ordnet Flow einer bestimmten Klasse zu, Kriterien s.u. Marker markiert IP-Paket entsprechend der zugeordneten Klasse beides erfolgt im ersten DiffServ-fähigen Gerät auf dem Weg zum Ziel (d.h. am Edge) Markierung erfolgt im IP-Header durch Verwendung eines 8-Bit Feldes in IPv4: Type of Service (ToS) in IPv6: Traffic Class dieses Feld wird in DiffServ als Differentiated Services Field (DS) bezeichnet Aufbau des DS-Feldes DSCP CU DSCP: Differentiated Service Code Point aus 6 Bit, d.h. 2 6 = 64 verschiedene Klassen CU: currently unused, Bits werden in IPv4 bereits durch andere Dienste genutzt C. Grimm 25. April 2007 Folie 51

52 DiffServ Klassifizierung und Markierung Kriterien für Klassifizierung typisch anhand der Felder im IP-Header Source und Destination IP Address, Protocol ID (Protokoll in Transport Layer) zusätzlich anhand der Port Numbers in den Headern der Transportprotokolle liefern Hinweise auf verwendete Dienste häufig werden vollständige Flows betrachtet Flow: Source und Destination IP Address, Source und Destination Port Number, Protocol ID DiffServ spezifiziert nicht die konkrete Einteilung und Behandlung der Klassen die Vergabe von Regeln und Einteilung der Klassen erfolgt typisch manuell auf Edge Router müssen Kriterien zur Klassifizierung konfiguriert werden auf Core Router müssen Regeln zur Behandlung der Klassen konfiguriert werden Beispiele Video-Anwendungen erhalten eine eigene Klasse Identifizierung und Klassifizierung ist anhand der Port Numbers möglich sämtliche IP-Pakete dieser Klasse werden bevorzugt behandelt Daten aus dem Netz eines bestimmten Providers erhalten eine eigene Klasse Identifizierung und Klassifizierung ist anhand der Source IP Address möglich sämtliche IP-Pakete dieser Klasse werden aufgrund des spez. Peerings nachrangig behandelt C. Grimm 25. April 2007 Folie 52

53 DiffServ Kontrolle der QoS-Parameter Vergabe der QoS-Parameter jeder Klasse wird ein bestimmtes Traffic Profile zugeordnet in dem Traffic Profile wird z.b. Average Rate oder Burst Size festgelegt Metering vergleicht die QoS-Parameter des eingehenden Flows mit dem vereinbarten Profil bei Überschreitung der vereinbarten Parameter wird Shaper aktiviert DiffServ legt nicht das konkrete Verhalten des Shapers fest Meter Classifier Marker Shaper Drop C. Grimm 25. April 2007 Folie 53

54 Per-Hop Behaviour (PHB) Per-Hop Behaviour auf jedem Hop (Router am Edge oder im Core) werden messbare Regeln verwendet Beispiele Klasse A erhält x% der ausgehenden Datenrate innerhalb eine Zeitintervalls IP-Pakete der Klasse B werden bevorzugt gegenüber IP-Paketen der Klasse C behandelt Expedited Forwarding Per-Hop Behaviour (RFC 3246) spezifiziert eine minimale Datenrate der zugeordneten Klasse steht die minimale Datenrate garantiert zur Verfügung entspricht einem logischen Link mit minimaler Bandbreite Ansatz erfordert die Isolation verschiedener Klassen Assured Forwarding Per-Hop Behaviour (RFC 2597) Einteilung in vier Klassen (Analogie Consumer, Silver, Gold, Platinum) jede Klasse enthält drei unterschiedliche Level für drop preference IP-Pakete unterer Klassen werden frühzeitig verworfen, um Ressourcen für IP-Pakete höherer Klassen frei zuhalten C. Grimm 25. April 2007 Folie 54

55 Bewertung DiffServ Verbesserung gegenüber IntServ erkennbar flächendeckende Verbreitung von DiffServ dennoch unwahrscheinlich flächendeckend bedeutet Provider-übergreifend wichtige Mechanismen fehlen bzw. sind noch nicht zuverlässig verfügbar Authentifizierung Accounting durch Overprovisioning mittlerweile genügend Ressourcen in Backbones s. Rechnernetze II IP im WAN QoS ist derzeit eher ein Problem im Access-Bereich End-to-End Performance wird häufig auf der ersten und letzten Meile entschieden zum Teil wird QoS im WAN durch instabiles Routing beeinträchtigt C. Grimm 25. April 2007 Folie 55

56 Literatur J. F. Kurose, K. W. Ross. Computer Networking A Top-Down Approach Featuring the Internet. Addison Wesley, 3nd Ed., 2005 Random Early Detection, Queue Management Homepage Sally Floyd, hier: S. Floyd, V. Jacobson. Random Early Detection gateways for Congestion Avoidance. IEEE/ACM Transactions on Networking, Vol. 1, No. 4, August 1993, S N. McKeown. A Fast Switched Backplane for a Gigabit Switched Router. Business Communications Review, Dezember Full paper at A. Tanenbaum. Computer Networks. Addison Wesley, 4th Ed., C. Grimm 25. April 2007 Folie 56

57 Übersicht Architektur von Routern Queues, Switching Fabric Head of Line Blocking Virtual Input Queues Queueing und Quality of Service Active Queue Management: Random Early Detect Scheduling: Weighted Fair Queueing Policing: Leaky Bucket und Token Bucket IETF Integrated Services Resource Reservation Protocol IETF Differentiated Services C. Grimm 25. April 2007 Folie 57