pro Datenstrom relativ viel Information notwendig nur begrenzte Menge von Strömen reservierbar schlechte Skalierbarkeit

Transkript

1 6.10 Probleme Zustand im Router pro Datenstrom relativ viel Information notwendig nur begrenzte Menge von Strömen reservierbar schlechte Skalierbarkeit Fragestellungen Muss pro Datenstrom reserviert werden? Wie kann die Reservierung authentisiert werden? Wie kann die Reservierung abgerechnet werden? IntServ nicht für den WAN-Bereich geeignet im LAN denkbar aber kaum real eingesetzt E.69 7 Differentiated Services DiffServ-Architektur definiert in RFC 2475 (1998) Zielsetzung Reduktion der Komplexität bessere Skalierbarkeit als IntServ keine Signalisierung von Ende zu Ende notwendig lediglich Router an Netzwerkgrenzen in komplexere Aufgaben involviert Klassifikation der Pakete einfache Router im Kernnetzwerk Weiterleitung und Behandlung gemäß Regeln für Verkehrsklassen einfache Abrechnung z.b. nach Volumen und Verkehrsklasse Verbesserung der Dienstgüte nicht notwendigerweise so gut wie garantierte Dienstgüte E.70

2 7.1 Idee Einheitliche Behandlung von Paketen einer Verkehrsklasse Pakete unterschiedlicher Ströme zusammengefasst zu einer Verkehrsklasse Identifikation der Verkehrsklasse durch Marke DSCP (DiffServ Code Point) definiert in RFC 2474 (1998) Einsatz des ursprünglichen ToS-Felds im IP-Header (TOS = Type of Service) gleiche Behandlung für alle Pakete mit gleicher Marke auf selbem Link BA = Behavior Aggregate PHB = Per Hop Behavior das beobachtbare Weiterleitungsverhalten für Pakete eines BA absolute Dienstgüte: z.b. Verlustrate, Verzögerung relative Dienstgüte: z.b. weniger Verzögerung als andere BA E Idee (2) Aufbau einer DiffServ-Domäne Sender Eingangsrouter Transitrouter DiffServ-Domäne DSCP DSCP Ausgangsrouter DSCP Empfänger Markierung am Eingang Behandlung in der Domäne gemäß Marke E.72

3 7.2 Eingangsrouter Klassifikation und Verkehrsformung im eingehenden Grenzrouter (Edge Router) zu einem DiffServ-Netzwerk (Ingress Router) z.b. Zugangsrouter bei DSL-Verbindung z.b. Zugangsrouter zwischen zwei Providern markiert adäquaten DSCP im TOS-Feld TOS-Feld im IP-Header ursprünglich für einfache Priorisierung von Paketen gedacht sechs Bit genutzt für DSCP (kompatibel zur ursprünglichen Priorisierung) codiert verschiedene Verkehrsklassen E Eingangsrouter (2) Markierung Ableitung der DCSP-Marke aus: Absender-, Senderadresse inkl. Portnummern statisch konfiguriert dynamisch über Signalisierung des Providers konfiguriert Dienstnutzung (z.b. aus Portnummern oder TOS-Feld hergeleitet) IEEE 802.1p-Prioritäten vorangegangener Reservierung über RSVP Umsetzung der Reservierungsanforderung auf PHB Übergang von IntServ auf DiffServ Ummarkierung Umwandlung von eingehenden DSCP in transportierte DSCP gemäß Vereinbarungen (Service Level Specification, SLS) eingehende Marken vom Endnutzer oder von anderer Providerdomäne E.74

4 7.2 Eingangsrouter (3) Verkehrsformung Formierung des Datenstroms mit verschiedenen Strategien Behandlung von Paketen, die das vereinbarte Profil übertreten z.b. Nutzung höherer Bandbreite als vereinbart Verwerfen von Paketen Verzögern von Paketen Markierung mit weniger wertvollen Marken E Weiterleitung im Kernnetzwerk Per-Hop-Behavior (PHB) Verhalten eines Routers im Kernnetzwerk bezüglich der Markierung von Paketen Verschiedene Verkehrsklassen Best Effort (RFC 2474) keine besondere Behandlung Assured Forwarding (RFC 2597) vier Subklassen pro Subklasse drei Unterklassen zur Unterscheidung für Paketverwerfung (unterschiedliche Paketverlustraten) garantierte Bandbreite, keine garantierte Verzögerung Expedided Forwarding (RFC 3246, 3247) garantierte Bandbreite, kürzest mögliche Verzögerung emuliert eigene Leitung E.76

5 7.3 Weiterleitung im Kernnetzwerk (2) Verhalten der Core-Router ähnliches PHB für gleiche DSCP-Marken ableitbares Verhalten der gesamten DiffServ-Domäne Dienstgüte Markierung im Ingress-Router (eingehender Router) definiert Behandlung in der DiffServ-Domäne Transit-Router nicht in Dienstgüteanforderungen involviert realisieren lediglich PHB wenig bis kein Zustand erforderlich im Ingress-Router lediglich Behavior-Aggregate kontrollierbar bzw. zuordenbar E Ausgangsrouter Aufgaben des Ausgangsrouters (Egress Router) am Ausgang einer DiffServ-Domäne evtl. Verkehrsformung evtl. Umsetzung von Marken gemäß Vereinbarung mit folgendem Provider übernimmt Aufgaben des Eingangsrouters der folgenden Domäne evtl. Umsetzung von Marken in neue TOS-Felder evtl. Umsetzung von Marken auf IEEE 802.1p-Prioritäten E.78

6 7.5 Bandbreitenbroker Zentrale Instanz einer DiffServ-Domäne Annahme von Reservierungswünschen Berechnung der potenziellen Netzlast und der Netzkapazitäten Zugangskontrolle (Admission Control) Konfiguration der Edge-Router konfiguriert mit Domänen-Policies z.b. limitiere EF-Services auf 20% der Netzkapazität Signalisierung Broker muss in die Signalisierung von Reservierungswünschen einbezogen werden E Bewertung Höhere Skalierbarkeit als IntServ kein Zustand in Transitroutern einfaches Verfahren Limitierte Garantie Garantie nur auf Behavior Aggregate nicht von Ende zu Ende Einsatz heute in dedizierten Szenarien z.b. innerhalb eines Providernetzes E.80

7 8 TCP-Friendly Rate Control Problem TCP-Verbindungen passen sich an Netzwerklast an bei höherer Last wird genutzte Bandbreite reduziert UDP-Ströme werden durch einzelne Pakete geformt keine Anpassung von UDP-Strömen im Netzwerkstack UDP-Ströme können TCP-Verkehr dominieren Ergebnis: kein oder wenig Fortschritt im Netzwerk d.h. schlechte Dienstgüte Anpassung der Netznutzung für UDP-Datenströme TCP-freundliche Kontrolle der Bandbreite (RFC 3448, 2003) E.81 8 TCP-Friendly Rate Control (2) Berechnung der verfügbaren Bandbreite T T = s R p t RTO p 2 + p1 ( + 32p ) s = Größe eines Pakets R = Round-Trip-Time kann über RTCP-Reports berechnet werden sollte geglättet werden t RTO = TCP-Retransmit Timeout wird vereinfacht als 4R angenommen p = Verlustrate aus RTCP-Reports ableitbar sollte geglättet werden (RFC beschreibt Verfahren zur Vermeidung von Oszillationen) E.82

8 8 TCP-Friendly Rate Control (3) Verhalten bei multimedialen Datenströmen Berechnung ergibt kleinere Senderate als geplant Anpassen des Codecs Resignalisierung, Aushandeln eines anderen Codecs Anpassen der Codierung z.b. Verringern der Daten in Enhancement-Layern z.b. Ratenanpassung in adaptiven Codecs E.83 9 Fehlerkorrektur Paketverluste beeinträchtigen Dienstgüte bei Multimediakommunikation Optionen zur Behebung von Fehlern definiert in RFC 2354 (1998) Alternativen ARQ = Automatic Repeat on Request Pakete werden auf Anforderung wiederholt Interleaving Aufteilung der Daten auf mehrere Pakete Paketverlust leichter zu verkraften FEC = Forward Error Correction redundaten Information erlaubt (teilweise) Rekonstruktion verlorener Daten Path Diversity redundante Übertragung über mehrere Routen durchs Netzwerk E.84

9 9.1 ARQ Automatic Repeat on Demand Empfänger erkennt Paketverlust Empfänger ermittelt Möglichkeit des Retransmits Abschätzung der Ankunftszeit Wert des Pakets zur Ankunftszeit RTP-Retransmit definiert in RFC 4588 (2006) separater Datenstrom für erneut gesendete Pakete entweder: verschiedene SSRCs oder: verschiedene Sitzungen mit gleicher SSRC erneutes Senden Einpacken der Originalpayload in ein neues RTP-Paket Integration der Originalsequenznummer E ARQ (2) RTP Paketformat für Retransmits V=2 P X CC M PT ARQ Sequence Number Original Time Stamp Synchronization Source (SSRC) Identifier Contributing Source (CSRC) Identifier... Original Sequence Number Original Data Padding PadNr Original Sequenznummer wird eingefügt Sequenznummer des RTP-Pakets gilt für die laufenden Retransmit-Pakete Time-Stamp ist vom Originalpaket E.86

10 9.2 Interleaving Verteilten der kontinuierlichen Daten auf mehrere Pakete Verlust eines Pakets führt nicht zu großer Lücke sondern zu mehreren kleinen Lücken im Datenstrom Aufteilung auf Pakete Paketverlust rekonstruierter Strom E FEC Forward Error Correction zusätzliche Übertragung von redundanter Information Medienunabhängige Codierung Beispiel: XOR-Verknüpfung der vorherigen drei Pakete wird als viertes Paket hinterhergeschickt Verlust eines Pakets erlaubt die anderen Zurückzurechnen Medienabhängige Codierung Beispiel MPEG: geringer aufgelöste Informationen zum vorherigen Frame werden im Paket des nächsten Frames mitgeschickt (Enhancementlayer) E.88

11 9.4 Path Diversity Versenden des Pakets über mehrere Routen typisch: zwei Routen Doppelte Netzlast Vorteil geringere Ausfallwahrscheinlichkeit geringere Verzögerung erstes ankommendes Paket wird verwendet E Referenzen Verwendete Ressourcen, weitere Informationen H. Schulzrinne, S. Casner, R. Frederick, V. Jacobson: RTP: A transport protocol for real-time applications. RFC July, H. Schulzrinne, S. Casner: RTP profile for audio and video conferences with minimal control. RFC July M. Baugher, D. McGrew, M. Naslund, E. Carrara, K. Norrman: The Secure Real-time Transport Protocol (SRTP). RFC March Wikipedia. < R. Braden, D. Clark, S. Shenker: Integrated Services in the Internet Architecture: an Overview. RFC June1994. R. Braden, L. Zhang, S. Berson, S. Herzog, S. Jamin: Resource ReSerVation Protocol (RSVP) - Version 1 Functional Specification. RFC Sep J. Wroclawski: Specification of the Controlled-Load Network Element Service. RFC 2211, Sep S. Shenker, C. Partridge, R. Guerin: Specification of Guaranteed Quality of Service. RFC 2212, Sep E.90

12 10 Referenzen (2) Verwendete Ressourcen, weitere Informationen (fortges.) M. Seaman, A. Smith, E. Crawley, J. Wroclawski: Integrated Service Mappings on IEEE 802 Networks. RFC 2815, May A. Ghanwani, W. Pace, V. Srinivasan, A. Smith, M. Seaman: A Framework for Integrated Services Over Shared and Switched IEEE 802 LAN Technologies. RFC 2816, May D. Durham, R. Yavatkar: Inside the Internet s Resource Reservation Protocol. Wiley, J. Kurose, K. Ross: Computer Networking. Addison-Wesley, S. Blake, D. Black, M. Carlson, E. Davies, Z. Wang, W. Weiss: An Architecture for Differentiated Services. RFC 2475, Dec K. Nichols, S. Blake, F. Baker, D. Black: Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers. RFC 2474, Dec J. Heinanen, F. Baker, W. Weiss, J. Wroclawski: Assured Forwarding PHB Group. RFC 2597, June E Referenzen (3) Verwendete Ressourcen, weitere Informationen (fortges.) B. Davie, A. Charny, J.C.R. Bennett, K. Benson, J.Y. Le Boudec, W. Courtney, S. Davari, V. Firoiu, D. Stiliadis: An Expedited Forwarding PHB (Per-Hop Behavior). RFC 3246, March A. Charny, J.C.R. Bennett, K. Benson, J.Y. Le Boudec, A. Chiu, W. Courtney, S. Davari, V. Firoiu, C. Kalmanek, K.K. Ramakrishnan: Supplemental Information for the New Definition of the EF PHB (Expedited Forwarding Per-Hop Behavior). RFC 3247, March C. Perkins, O. Hodson: Options for Repair of Streaming Media. RFC 2354, June E.92