und -netze Globale Vernetzung Das Internet t der neuen Generation Globale Vernetzung Internet-Ausbau am Beispiel Esnet / Qwest IPv6 IP und Multimedia

Transkript

1 Globale Vernetzung Stand 1991 Telekommunikationsdienste und -netze Das Internet t der neuen Generation IPv6 IP und Multimedia Fachgebiet Kommunikationsnetze 179 Globale Vernetzung Stand 1997 Internet-Ausbau am Beispiel Esnet / Qwest

2 Motivation für eine neue Internet-Protokollsuite t t Geschichte ht von IPv6 Adressierungsprobleme IP-Adressraum kaum mehr ausreichend Class-B-Adressen sind nahezu erschöpft CIDR nur Übergangslösung Keine hierarchische Adressierung Routing-Tabellen wachsen sehr schnell, daher ineffizientes i Routing Sicherheitsprobleme Verstärkte Dienstgüteanforderungen durch Multimediaanwendungen 1993 Call for Proposals für IP next generation (IPng) in RFC Vorschlag: SIPP (Simple Internet Protocol Plus) als Kombination aus drei eingereichten Vorschlägen 1995 Proposed Standard Internet Protocol Version 6 in RFC 1883 erste prototypische Implementierungen sanfte Migration erwünscht 1996 Erstes IPv6-Backbone (6Bone), erste Produkte am Markt erhältlich 1998 IPv6 als RFC 2460 zum Draft Standard erhoben 2006 Verbreitung noch immer sehr gering Änderungen / Verbesserungen immer noch in Diskussion Eigenschaften von IPv6 im Überblickbli IPv6-Adresse Erweiterte t Adressierungsmöglichkeiten it Neues IP-Paketkopfformat Einfachere Struktur Verbesserte Behandlung von Optionen Segmentierung nur Ende-zu-Ende Autokonfiguration von IP-Systemen Dienstgüteunterstützung Multicast-Integration t t Sicherheitsvorkehrungen 128 bit lange Adressen Theoretisch 3, Adressen Optimistische Abschätzung: pro m 2 Pessimistische Abschätzung (RFC1715): pro m 2 Neue Notation 8 durch Doppelpunkte getrennte 4-stellige Hexadezimalzahlen 5800:0000:0000:0000:0000:0000:0056:0078 Reihen von Nullen können weggelassen werden 5800::56:78 IPv6-Adressen können Strukturinformation zur hierarchischen Lokalisierung beinhalten

3 IPv6-Adressen: aggregierbare Unicast-Adresse IPv6-Adressen: Spezielle Unicast-Adressen Top-Level Aggregation (TLA) große Internet Service Providers (ISP) mit Transitnetzen, an denen andere ISPs angeschlossen sind Next-Level Aggregation (NLA) Organisationen auf einer niedrigeren Stufe Mehrere NLA-Ebenen möglich Site-Level Aggregation (SLA) Individuelle Adressierungshierarchie einer einzelnen Organisation Öffentliche Topologie 24 Standort-Topologie TLA ID Res. NLA ID SLA ID Interface ID Lokale Unicast-Adressen Link-lokal für Konfigurationszwecke oder IP-Netze ohne Router Standort-lokale für noch nicht an das Internet angeschlossene IP-Netze, einfach rekonfigurierbar Kompatible Unicast-Adressen IPv4-kompatibel: Präfix (96 0 -Bits) + IPv4-Adresse IPv4-mapped: Präfix (80 0 -Bits Bits) + IPv4-Adresse IPX-kompatibel oder OSI-kompatibel Unspezifizierte Adresse 0::0 (oder ::) beim Booten Loopback-Adresse 0::1 (oder ::1) entspricht der v4-adresse IPv6-Adressen: Anycast IPv6-Adressen: Multicast t Neuer Adresstyp in IPv6 Teil des Unicast-Adressraums Adressierung einer ganzen Gruppe, der am wenigsten belastete / nächste / am besten erreichbare... IP-Knoten antwortet Für jede Anycast-Adresse existiert ein eigener Eintrag in der Routing-Tabelle Anycast-Adressierung somit nur für Router relevant Anwendungsbeispiel: Verteilung eines Web- Servers auf mehrere physikalische Knoten Alle Router und Endsysteme unterstützen tüt Multicast Vordefinierte Multicast-Gruppen für Kontrollfunktionen IGMP wurde in ICMPv6 integriert Die Multicastadresse enthält zusätzlich Flags (Unterscheidung temporär/permanent) Scope (Wirkungsgrad / Reichweite des Pakets) Flags Scope 8 bit 4 bit 4 bit Gruppenidentifikation 112 bit

4 Vergleich der Adressierungs- arten in IPv4 und IPv6 Paketköpfe Vergleich zwischen IPv4 und IPv6 Adressie- Verwendete Notwendige IPv4 IPv6 rungsart Schnittstellen Auslieferungen V HL TOS Total Length Identifier Segmentierinfo V C Flow Label Payload Length Next hdr. Hop Limit 190 Unicast Obligatorisch Obligatorisch 1 1 Multicast Optional Obligatorisch Gruppe Alle in der Gruppe Broadcast Obligatorisch Alle Alle Anycast Obligatorisch Gruppe 1 TTL Protocol IP Source Address Header Checksum IP Destination Address V: Version HL: Header Length TOS: Type of Service TTL: Time To Live C: Class : gelöscht : verschoben 20 byte 128 bit Source IPv6 Address 128 bit Destination IPv6 Address 40 byte 191 Erweiterungspaketköpfe tkö Beispiele für Erweiterungspaketköpfe tkö Verkettung von Erweiterungspaketköpfen (Extention Headers) Kleiner minimaler Paketkopf Je nach Anforderungen seitens der Anwendungen und/oder Eigenschaften der Netze Einfügen von Erweiterungspaketköpfen in bestimmter Reihenfolge Verkettung der Erweiterungspaketköpfe Einfache Einführung neuer zukünftiger Erweiterungen und Optionen Router muss nicht alle Erweiterungspaketköpfe bearbeiten Aufgaben der Erweiterungspaketköpfe beispielsweise Sicherheitsüberprüfung Segmentierung Source Routing Netzmanagement IPv6-Header NH IPv6-Header NH TCP-Header +Daten Routing Header NH TCP-Header +Daten Routing Fragment IPv6-Header Header Header NH NH NH NH = Next Header TCP-Header +Daten

5 ICMPv6 IPv6: Segmentierung ICMPv6 ersetzt die Protokolle ICMP(v4), IGMP(v4) und ARP(v4) ICMPv6 wird über IPv6 transportiert Wert des Next Header -Felds: 58 Liefert so viel wie möglich vom betroffenen Paket zurück, ohne die minimale MTU von 576 byte zu überschreiten Arbeitet wie TCP und UDP mit einem Pseudo-Header: Type Code Checksum Depending on Type Additional Data depending di on Type Nur der Sender kann Segmentieren Ist das Paket zu groß, senden die Router eine ICMPv6- Nachricht packet too big Feststellen der maximalen Paketgröße (Maximum Transfer Unit MTU) mittels Angabe im ICMPv6-Paket: MTU= 1500 SYN; MSS=1440 Data; 1440 byte ICMPv6 error Packet too big MTU=576 R1 MTU= 576 R2 MTU= 1500 SYN; ACK MSS= IPv6: Unterstützung tüt mobiler Knoten IPv6: automatische Adresskonfiguration Mobile Rechner sind ohne Umkonfiguration ihrer IP-Rechner nicht in einem Fremdnetz betreibbar Durch Autokonfiguration bekommen Rechner eine neue gültige IP-Adresse Damit sie erreichbar bleiben, bleibt die alte IP-Adresse weiterhin gültig Spezielle Architektur für das Weiterleiten von IP-Nachrichten notwendig Spezielles Kapitel zur Mobilkommunikation Heimatnetz? Fremdnetz Neue, gültige und alte IP-Adresse Plug & Play Beschaffung der eigenen IP-Adresse Entdeckung doppelter IP-Adressen Adressauflösung Bestimmung von ortsabhängigen Parametern (Subnetz-ID, MTU, DNS-Server,...) Entdeckung von Routern Unterstützung mobiler Endgeräte Prinzip der Nachbarschaftserkennung (Neighbour Discovery) Spezielle ICMP-Nachrichten: Router Solicitation / Advertisement Neighbour Solicitation / Advertisment

6 IPv6: Sicherheitsvorkehrungen h it h IPv6 und Multimedia IPsec Sicherheit auch auf IP-Ebene Verschlüsselung Authentifizierung Realisierung durch spezielle Erweiterungspaketköpfe p Authentication Header Überprüfung der Datenintegrität Überprüfung der Senderidentität Security Encapsulation Header Vertraulichkeit Integrität und Authentizität IPv6 ist für Multimediaströme t vorbereitet t Flow Label Pakete mit gleichem Ziel bekommen identisches Label und können so gleichbehandelt werden Priorität Einstufung der Pakete nach Dringlichkeit Grobe Unterscheidung Non real time Real time Spezielle Mechanismen in den Routern notwendig Migration hin zu IPv6 Migrationsverfahren: Tunneling Zurzeit kommunizieren die Rechner im Internet vorwiegend über IPv4 Wie migriert man Millionen von Rechnern hin zu IPv6? Alle Rechner mit einem Schlag umstellen nicht möglich Langsame, schrittweise Migration auf IPv6 mit zeitweise Co-Existenz beider Standards Verfahren Tunneling Dual Stack Protokolltranslation IPv6 IPv4 t IPv6-Pakete Pakete werden in speziellen Routern in IPv4- Pakete eingekapselt und wieder ausgepackt. Kommunikation nur zwischen solchen Tunnelendpunkten möglich Andere Router bemerken nichts von IPv6 Automatisch (Zuweisung von IPv4-kompatiblen Adressen) oder konfigurierbar (fest konfigurierte Adressen für Tunnelendpunkte) IPv6-Paket IPv6- R1 IPv4- R1 IPv4- R2 IPv4- R3 IPv6- R2 IPv6-Paket je nach Verbreitungsgrad optimal

7 Migrationsverfahren: Dual Stack Sowohl Endknoten als auch Router verfügen über zwei Protokollstacks: IPv4 und IPv6 Der DNS-Rückgabewert entscheidet, welcher Stack verwendet wird DNS muss also auch beide Protokolle unterstützen IPv4-Adressen können so eingespart werden Anwendungen Socket-Schnittstelle UDP für IPv4 TCP für IPv4 UDP für IPv6 TCP für IPv6 IPv4 etc. IPv6 etc. Migrationsverfahren: Protokolltranslation l ti Übersetzung von IPv4-Pakete P in IPv6-Pakete P Anwendungsschicht muss davon unabhängig bleiben Beispiele Stateless IP/ICMP Translator (SIIT) Network Address Translation Protocol Translation (NAT-PT) Socket-based IPv4/IPv6 Gateway Bump In The Stack (BIS) Netzschnittstelle IPv6 in der Praxis Das 6Bone Betriebssysteme sind in der Regel IPv6-tauglich Sehr viele Produkte unterstützen im Grunde genommen den neuen IP-Standard Aber In der Regel wird IPv4 verwendet (Investitionsschutz) Ergänzungen zur IPv4-Welt ermöglichen weiterhin den Einsatz der alten Technik Anwendungen benötigen (noch) nicht die speziellen Eigenschaften von IPv6 IPv6 kommt immer noch nur in speziellen Forschungsnetzen zum Einsatz 6bone als IPv6-Backbone Internet2 als Entwicklungsplattform Weltweites IPv6-Testnetzwerk Migrationsforschung Verbindung der IPv6-Hauptknoten t über konfigurierte i IPv4-Tunnel

8 Internet t 2 t t2 / Das Internet 2 ( ist ein Konsortium, in dem 180 Universitäten organisiert sind, die mit Industrie und Regierung zusammenarbeiten, um neue Netzanwendungen und technologien zu entwickeln und zu realisieren. Die Arbeit wird in so genannten Working Groups durchgeführt: Engineering (IPv6, Multicast, QoS, Routing, Sicherheit...) Middleware (PKI, VidMid, MACE (Middleware Architecture Committee for Education)...) ) Anwendungen (Arts & Humanities, Digital Video, Health Sciences, Veterinary Medical, Voice over IP...) Internet2 t2 Universities iti Download of The Matrix DVD (Comparison of the Internet2 Land Speed Record)

9 Abilene Network Logical Map Aktueller Status des Abilene- Netzes November Dienstgüte im Internet t Einfache Maßnahmen für Dienstgüte Internet wird zunehmen Teil der Unternehmensinfrastruktur Virtuelle Private Netze (VPN) Allgemein verfügbare Kundenschnittstelle (z.b. Home-Banking) Multimediales Internet (MP3, Voice over IP, Spiele,...) Aber: Fehlende Unterstützung für Anwendungsanforderungen (Durchsatzgarantie, ti Echtzeitanforderung, begrenzte Verzögerungsschwankung, etc.) Ressourcenmangel im Internet Erfolg der Paketweiterleitung abhängig von der aktuellen Netzlast Unendliche Unendliche Übertragungskapazität Durch Verwendung spezieller Übertragungstechniken (beispielsweise WDMA) kann die verfügbare Kapazität beliebig (?) gesteigert t werden Problem: Stauung an Netzübergängen mit unterschiedlichen Kapazitäten, dadurch keine Voraussage bezüglich Verzögerung und djitter Einfache Prioritäten ausreichend 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

10 Dienstgüte Parameter Grobe Unterscheidung nach Dienstklassen 214 Dienstgüteparameter: Leistungsspezifische Parameter (Durchsatz, Verzögerung, g, Verzögerungsschwankung, g g, Zuverlässigkeit, Priorität, Verbindungsauf- und abbaufehlerwahrscheinlichkeit, Übertragungsfehlerwahrscheinlichkeit,...) Betriebliche Parameter (Kosten, Verfügbarkeit, Reichweite, Persistenz,...) Allgemeine Parameter (Sicherheit, Kommunikationsform, Synchronisation,...) Angabe der Dienstgüte: Quantitativ, dh d.h. nachprüfbar durch hmessung Qualitativ, d.h. relativ, eventuell nachweisbar durch Vergleich, beeinflusst durch subjektive, menschliche Wahrnehmung 215 Bestmögliche Klasse (Best-Effort) Dienstklasse des heutigen Internet Keine Ressourcenreservierung Konflikte bei zu hoher Last Statistische Klasse Dienstgüteparameter t werden statistisch ti ti eingehalten Beispiel: 80% der Pakete haben eine Verzögerung von weniger als 100 ms Ressourcen werden reserviert, aber dabei bis zu einem gewissen Grade überbelegt Konflikte immer noch möglich Deterministische Klasse Dienstgüteparameter werden immer eingehalten (harte Garantie) Ressourcen stehen einem Benutzer exklusiv zur Verfügung Keine Konflikte, dafür Besetztfall Traditionelle Anwendungen Realzeit-Anwendungen Kein 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 g Verzögerungen in der Dateiübertragungsphase Asynchron (z.b. ) sehr tolerant gegenüber Verzögerungen Harte zeitliche Anforderungen an die Auslieferung der Daten Audio- und Videoströme Fabrikautomatisierung Audio-/Videoanwendungen Nutzung redundanter Information bezüglich Datenverluste Zu spät eintreffende Daten werden wie verlorengegangene behandelt Erhöhung dieser Redundanz durch spezielle Codierung und Fehlerbehandlung Adaptivitätsmöglichkeiten: Verzögerungsadaptivität Ratenadaptivität ti ität

11 Bereitstellung t von Dienstgüte Verkehrsvertrag Ressourcenverwaltung Signali- sierung Daten- pakete Reservierungs- protokolle Klassifizierer Verkehrsmeter Verkehrsformer Zugangs- kontrolle Wegewahl Benutzerkonten Preismodell Abrechnung Warteschlangen & Bedienstrategien Gewü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: Verkehrsvertrag Einhaltung der so ausgehandelten Dienstgüte strikt bei deterministischen Klassen mit eventuellen kurzzeitigen Verletzungen bei statistischen Klassen Neudeutsch Service Level Agreement Dienstanbieter muss Nachweis über seine Zugeständnisse führen! Verkehrsmeter Verkehrsmeter: Beispiel i Token Bucket Verkehrsmeter 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är Mehrere Konformitätsklassen Beispiele Token Bucket (überprüft Senderate und Burst) Leaky Bucket (zusätzlich noch Verkehrsformung) Eimer Eimer mit maximaler Füllung B Token Tokenankunftsrate R Ü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 (keine Pufferung, bis genügend Token vorhanden sind!) T T T T Token Bucket T T konform T nichtkonform

12 Verkehrsformer Verkehrsformer: Beispiel i Leaky Bucket Verkehrsformer beeinflussen aktiv die Charakteristik des Verkehrs: Ziel: Wiederherstellung von Konformität bzw. eines bestimmten Verkehrsmusters Beispiele: Verkehrsglätter Verwerfer Degradierer Verwerfer Verkehrsglätter Degradierer (ordnet dem Datenstrom eine niedrigere Dienstkategorie zu) Eimer Eimer mit maximaler Füllung B byte Pakete werden in den Eimer gefüllt und tröpfeln mit der Rate R aus dem Eimer heraus (rinnender 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 Leaky Bucket Klassifikationselemente l t Warteschlangen und Bedienstrategien t i Klassifzierer identifizieren Datenströme aus der Menge aller Pakete: Zuordnung Paket Verkehrsprofil Arten von Klassifizierern: Klassifizierer für aggregiertes Verhalten (Aggregate Classifier) Viele Datenströme erfahren das gleiche Verhalten Sehr einfache und schnelle Klassifikation Ansatz: Differentiated Services über Codepoint im Paket Klassifizierer für mehrere Paketkopffelder (Multi-Field Classifier) Kombination eines oder mehrerer Paketkopffelder wie IP-Adressen, IP- Protokollfeld, Port-Nummern,... Sehr komplizierte und aufwändige Klassifikation Klassifikationsinformationen stehen in Datenbasis Verkehrsprofile Reservierungsdaten Warteschlangen 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 Beispiele: Round Robin Simple Priority Queueing Weighted Fair Queueing Scheduler

13 Scheduling-Algorithmen ith Aggregierung von Datenströmen t Einfache Implementierung Für alle Dienstklassen Problem: In schnellen Netzen nur sehr wenig Zeit für die Bearbeitung einzelner Dateneinheiten (bei 1Gb/s ATM müssen ca Pakete/s bearbeitet werden) Speicheranforderungen zur Zustandshaltung sollten möglichst gering und die Zugriffsgeschwindigkeit auf den aktuellen Zustand möglichst effizient sein. Anforderungen bei best-effort Diensten: Fairness: Ressourcen werden gemäß steigenden Anforderungen gleichmäßig verteilt, wobei nur so viele Ressourcen wie benötigt verteilt werden. Absicherung: Verbindungen, die ein höheres Datenaufkommen haben, dürfen andere (faire) Verbindungen nicht beeinträchtigen. Mehrere Datenströme werden aggregiert betrachtet hinsichtlich der Bedienreihenfolge Vorteil: Zustandshaltung reduziert sich Wichtiges Argument in großen Netzen Vorgehensweise Einteilung der Datenströme in Klassen Aggregierte Betrachtung der Klassen Problem Datenströme innerhalb einer Klasse sind nicht voneinander abgesichert Fairness und Absicherung dann nur noch zwischen den Klassen gegeben und nicht mehr innerhalb einer Klasse Keine festen Garantien mehr für einzelne Ströme innerhalb einer Klasse realisierbar Ressourcenverwaltung Dienstgüteaushandlung bei Multicast t Probleme: Bereitstehende Ressourcen sind beschränkt: Übertragungskapazität Pufferkapazität Rechenzeit Anwendungen konkurrieren k um gemeinsam zu benutzende Ressourcen Aufgaben: Regelung von Ressourcenzugang und -nutzung Ansätze: Reservierung on demand Langzeit-Reservierung Vor-Reservierung Zusätzliche Problematik durch Konflikte bei der Dienstgüteaushandlung für mehrere Empfänger: Sender (min 1Mb/s; max 50Mb/s) [1;50] Empfänger 1 (min 20Mb/s; max 40Mb/s) Konfliktauflösung beim Sender: Empfänger 2 Abweisung des Verbindungsaufbauwunsches (min 5Mb/s; max 10Mb/s) Ablehnung eines einzelnen Empfängers Aufbau der Multicast-Verbindung mit unterschiedlicher Dienstgüte Filterung des Datenstroms Hierarchische Codierung der Daten

14 Dienstgütearchitekturen im Internet t Dienstgüte in IP version 4 Einfü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 Differentiated Services IP-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 t Endsystemen Dienstgüte nur im Type-of-Service -Feld beschrieben Vorrang Verzö- Durch- Zuver- gerung satz lässigk bit Auf dieser Basis können keine Garantien gegeben werden! Integrated t Services Architecture t Das Signalisierungsprotokoll RSVP Architektur für integrierte i t 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 g Erhalten der Robustheit durch Soft State -Reservierung Ergänzung der bestehenden Internet-Architektur Integration gruppenkommunikationsbasierter Anwendungen Ziel: Signalisierung von Reservierungsanforderungen in IP-basierten Netzen 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 Empfänger erhält keine Quittung für die Reservierung Kein expliziter Abbau der Reservierung erforderlich, da Zeitgeber zugeordnet sind, nach deren Ablauf die jeweilige Reservierung gelöscht wird

15 RSVP Ablauf Probleme der Integrated Services Architecture t PATH RESV RESV = Reservation RSVP- Router RSVP- Router Skalierbarkeit Jeder Router verwaltet Zustandsinformation (Qualitätsparameter, Sender- und Empfängeradressen) pro Datenstrom Leistung des Routers sinkt bei großer Anzahl von Reservierungen Paketweiterleitung wird durch die Klassifizierung jedes einzelnen Pakets komplexer Frei wählbare Qualitätsparameter Router muss eine sich dynamisch ändernde Anzahl von Dienstgüten unterstützen Paket-Schedulung ist daher komplex und nicht so leistungsstark Differentiated t Services Differentiated Services im Überblickbli 1997 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 t 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 (schnelle Einführung) Vorgehensweise: Aggregation des Verkehrs im Netzinnern zu Dienstklassen Aggregierte Klassifikationszustände, einfache Paketklassifizierer Komplexere Funktionen (Klassifizierung, Markierung, Überprüfung) nur an Netzgrenzen DS-Grenzknoten (Boundary Node) BN BN IN DS-Region DS-Domäne A IN IN Ausgangsknoten Eingangsknoten BN BN BN BN IN DS-Domäne B IN IN DS Innerer Knoten (Interior Node) BN IN BN Sender Empfänger

16 Differentiated Services Dienste Vergleich Differentiated vs. Integrated t Services Dienstspezifikation Per-Domain Behavior (PDB) Ende-zu-Ende Dienste Spezifikation über SLA Kombination aus den PDBs Domänenweites Weiterleitungsverhalten Per-Hop Behavior (PHB) + verkehrsbeeinflussende Maßnahmen Best Effort Integrated Services Differentiated Services QoS-Garantie Keine Pro Datenstrom Konfiguration Keine Aggregierte Datenströme Zwischen Domänen Typ der Garantie Keine Soft individuell Aggregiert Per-Hop Behavior (PHB) Abschnittweises Paketweiterleitungsverhalten Paketbearbeitung innerhalb eines Knotens Dauer der Kurzlebig Keine Garantie (Sitzungszeit) Zustandshaltung Keine Pro Datenstrom Langfristig Pro aggregierter Reservierung PHB-Implementierung Bestimmte Warteschlangenmechanismen Pro Sitzung Endezu-Ende Signalisierung Keine RSVP Noch nicht definiert IP-Multicast, sonst Multicast- Empfängerorientiert, IP-Multicast keine spezielle Unterstützung heterogen Unterstützung Literaturt RFCs (1) BRAUN, T:IPnG T.: Neue Internet-Dienste und virtuelle Netze: Protokolle, Programmierung und Internetworking. Heidelberg : dpunkt-verlag, ISBN EFFELSBERG, W.: Vorlesung Rechnernetze Rechnernetze. Sommersemester GROSSMANN, H.P.: Vorlesung Kommunikationsnetze Historische Entwicklung ng des Internet. technik ni ulm.de/lomiweb/lehre/kommunikationsnetze/. Sommersemester NAU, T.: Vorlesung Computer Networks IPv6. ulm.de/lomiweb/lehre/computernetworks/ws0102/materials/ipv6.pdf. / t / t i l /IP df Wintersemester 2001/02. NIEMANN, M.: Vorlesung Rechnernetze IPng / IPv6. bielefeld.de/lecture/networks/ip-niemann.pdf. ld d / /IP i df Sommersemester ZITTERBART, M.: Vorlesung Next Generation Internet. Sommersemester BRADNER, S.; MANKIN, A.: IP: Next DEERING, S.; HINDEN, R.: Internet Generation (IPng) White Paper Solicitation, Dezember 1993 (RFC1550). Protocol, Version 6 (IPv6) Specification, Dezember 1998 (RFC2460). CALLON,, R. ; HASKIN,, D.: Routing Aspects of IPv6 Transition, September 1997 (RFC2185). BRADEN, R. ; ZHANG, L. ; BERSON, S. ; HERZOG, S. ; JAMIN, S.: Resource ReSerVation Protocol (RSVP) Version 1 Functional Specification, September 1997 (RFC2205). WROCLAWSKI, J.: The Use of RSVP with IETF Integrated t Services, September 1997 (RFC2210). LI, T. ; REKHTER, Y.: A Provider Architecture for Differentiated Services and Traffic Engineering (PASTE), Oktober 1998 (RFC2430). NICHOLS,, K. ; BLAKE,, S. ; BAKER,, F. ; BLACK, D.: Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers, Dezember 1998 (RFC2474). BLAKE, S. ; BLACK, B D. ; CARLSON, M.; DAVIES, E. ; WANG, Z. ; WEISS, W.: An Architecture for Differentiated Service, Dezember 1998 (RFC2475). NICHOLS, K. ; JACOBSON, V. ; ZHANG, Z L.: A Two-bit Differentiated Services Architecture for the Internet, Juli 1999 (RFC2638). HERZOG, S.: RSVP Extensions for Policy Control, Januar 2000 (RFC2750)

17 RFCs (2) BONAVENTURE, O.;CNODDER, ; S.D.:A NORDMARK, E.;GILLIGAN, ; R.:Basic Rate Adaptive Shaper for Differentiated Services, Oktober 2000 (RFC2963). Transition Mechanisms for IPv6 Hosts and Routers, Oktober 2005 (RFC4213). NICHOLS,, K. ; CARPENTER,, B.: Definition of Differentiated Services Per Domain Behaviors and Rules for their Specification, April 2001 (RFC3086). RAMAKRISHNAN, K. ; FLOYD, S. ; BLACK, D.: The Addition i of Explicit i Congestion Notification (ECN) to IP, September 2001 (RFC 3168). GROSSMAN, D.:New Terminology and Clarifications for Diffserv, April 2002 (RFC3260). KOMPELLA, K. ; LANG, J.: Procedures for Modifying the Resource reservation Protocol (RSVP), Oktober 2004 (RFC3936). HINDEN R. ; THALER,, D.: IPv6 Host-to- Router Load Sharing, November 2005 (RFC4311). CONTA, A. ; DEERING, S. ; GUPTA, M.: Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification, März 2006 (RFC4443). NARTEN, T. ; NORDMARK, E. ; SIMPSON, W. ; SOLIMAN, S H.: Neighbor Discovery for IP Version 6 (IPv6), September 2007 (RFC4861). THOMSON, S. ; NARTEN, T. ; JINMEI, T.: IPv6 Stateless Address Autoconfiguration, September 2007 (RFC4862). 242