Reservation von Ressourcen im Internet Prof. B. Plattner ETH Zürich IP Next Generation - RSVP (1)
Motivation und Konzept von RSVP Realisierung eines Integrated Services Internet erfordert Mechanismen für die Reservation von Ressourcen Übertragungskapazität auf Links Speicherplatz und Verarbeitungskapazität in Routern Ressourcen müssen in Hosts und entlang der Route in Routern bereitgestellt werden RSVP stellt einen Mechanismus bereit, mit welchem Reservationsinformation im Netz transportiert werden kann In jedem Host/Router versucht RSVP, die verlangten Ressourcen zu reservieren (Admission Control, Policy Control) -> Parametrisierung des Datenpfads IP Next Generation - RSVP (2)
Einbettung von RSVP in Hosts und Routern Control path Data path IP Next Generation - RSVP (3)
Beispiel IP Next Generation - RSVP (4)
Anforderungen Muss mit IPv4 und IPv6 anwendbar sein Unabhängig von spezifischen Routing-Protokollen Muss sich Routenänderungen anpassen können Anwendbar für Punkt-Punkt und für Mehrpunkt- Mehrpunkt-Kommunikation (IP Unicast und Multicast) Skalierbarkeit: Multicast-Gruppen beliebiger Grösse sollen möglich sein Kompatibel mit Internet Integrated Services Model (mehrere Dienstklassen) Kompatibel mit Soft-State-Prinzip Schrittweises Roll-Out im Internet soll möglich sein ( Non- RSVP Clouds ) -> differentiated services IP Next Generation - RSVP (5)
Charakterisierung RSVP-Flows sind unidirektional: Sender und Empfänger werden als logisch verschieden betrachtet, auch wenn oft ein Sender auch Empfänger ist. RSVP ist ein Signalisierungsprotokoll. Hat selbst keine Echtzeit- Anforderungen. Skalierbarkeit für grosse Multicast-Gruppen wird durch das Zusammenfassen von Reservationen erreicht. IP Next Generation - RSVP (6)
Prinzipien des Resource Reservation Protocol (RSVP) Empfänger-orientierte Reservation (diese wissen, was sie wollen); Sender schicken path messages, Empfänger schicken Reservationen auf dem Rückwärtspfad. Empfänger können die gesendeten Pakete filtern lassen Auswahl von Paketen gewisser Sender oder Applikationen. Beispiele: File-Transfer parallel zu einem Audio-Datenstrom; Auswahl des Sprechenden in einer Video-Konferenz. Filterung basierend auf Applikation könnte Flow Label verwenden. Das Filtern von Quellen und die Reservation von Ressourcen sind voneinander getrennt. Konzept des "Soft State : Auffrischen von Reservationen IP Next Generation - RSVP (7)
Dienstelemente von RSVP RSVP-Session: identifiziert durch (Zieladresse, Protokoll-ID [, Destinationsport]) Destinationsport ist eine Verallgemeinerung von TCP/UDP-Ports, in der aktuellen Version der Spezifikation jedoch auf diese beschränkt. Protocol-ID ist gegenwärtig nur IP Bei Multicast-Sessionen identifiziert die Zieladresse allein die Session Elementare RSVP-Reservation: flowspec und filter spec = flow descriptor flowspec: Spezifiziert die gewünschte Quality of Service (QoS): Service Class, Rspec, Tspec filter spec: spezifiziert die Pakete einer Session, für welche die Reservation gilt (gegenwärtig Sender IP-Adresse/Port-Nummer) IP Next Generation - RSVP (8)
Reservation Styles Style: Auswahl von optionalen Elementen in einer Reservation Behandlung von Reservationen für verschiedene Sender in einer Session: Spezifische Reservation für jeden Sender (distinct) oder eine gemeinsame Reservation für alle Sender (shared) Auswahl der Sender, deren Pakete die reservierten Ressourcen belegen können Auswahl des Senders Explicit Wildcard Distinct Fixed-Filter style Nicht definiert Shared Shared- Explicit style Wildcard-Filter style IP Next Generation - RSVP (9)
Beispiele für die Verwendung von Filtern Disziplinierte Audio-Konferenz: Wenn immer nur ein Teilnehmer spricht, müssen Ressourcen nur für einen Audio-Kanal getätigt werden. Keine besondere Filterung notwendig. Video-on-Demand übers Internet: Reservation eines einzigen Kanals, über den nur die Pakete einer einzigen Quelle übertragen werden: Anwendung für fixes Filter. Desktop-Konferenz (mit Video-Übertragung) mit 10 Teilnehmern: Ein Empfänger reserviert so, dass er nur zwei Bilder mit guter Qualität empfängt: Das des Sprechenden und das des vorangehenden Sprechers. Die restlichen Bilder werden in best-effort Qualität übertragen. Anwendung für wildcard oder shared-explicit filter. IP Next Generation - RSVP (10)
Ablauf von RSVP Identifikation einer Session durch Session-ID Sender schickt path request (mit Sessionsbeschreibung) in einem IPv6-Paket an die Destination. Die Router entlang der Route merken sich die Daten der Session und den Pfad zum Sender. Empfänger schicken reservation requests zum nächsten Router. Enthält u.a. flowspec, filter spec. Policy control und Admission control stellen Zulässigkeit bzw. Machbarkeit der Reservation fest. Die Reservation wird gemacht (zeitlich begrenzt) und der Request in Richtung Sender weitergeleitet. path und reservation requests werden periodisch wiederholt (-> soft state) IP Next Generation - RSVP (11)
Formate von RSVP-Nachrichten IPv6 Header RSVP Ext. Header RSVP Object IP Next Generation - RSVP (12)
Typen von RSVP-Nachrichten Typ Path message Reservation message Path m. error indication Reservation m. error indication Path teardown message Reservation teardown message Verwendung Sender -> Empfänger; Charakterisierung der Daten pro Sender Reservationen der Empfänger Fehlerrückmeldung für fehlgeschlagene Path message Fehlerrückmeldung für fehlgeschlagene Reservation Expliziter Abbau der Path-Information Freigabe der reservierten Ressourcen IP Next Generation - RSVP (13)
Beispiel: Live-Präsentation mit 2 Sendern und 2 Empfängern S1 S2 L2 L1 R1 L5 R2 E1 L3 L4 E2 IP Next Generation - RSVP (14)
Aktuelle Arbeitsgebiete RSVP ist seit September 1997 ein proposed standard. Relation zwischen Routing und Reservationen -> route pinning. Adaptive Anwendungen, Kompression und hierarchische Codierung von (Echtzeit-)Datenströmen. Differentiated services. Aktive Filterung von Datenströmen im Netz (Active Networks?). Praktische Erprobung des Integrated Services -Konzepts im Internet. Verrechnung von Kommunikationsdienstleistungen. -> grösstenteils sind dies aktuelle Forschungsthemen IP Next Generation - RSVP (15)
Literaturhinweise RSVP Working Group des IETF: http://www.ietf.org/html.charters/rsvpcharter.html RSVP Project: http://www.isi.edu/div7/rsvp/rsvp.html [RFC 1633] Braden, R., Clark, D., and S. Shenker, "Integrated Services in the Internet Architecture: an Overview", RFC 1633, ISI, MIT, and PARC, June 1994. [RFC 2207] Berger, L. and T. O'Malley, "RSVP Extensions for IPSEC Data Flows", RFC 2207, September 1997. [RFC 2210] Wroclawski, J., "The Use of RSVP with Integrated Services", RFC 2210, September 1997. [PolArch96] Herzog, S., "Policy Control for RSVP: Overview". Work in Progress. [RSVP93] Zhang, L., Deering, S., Estrin, D., Shenker, S., and Zappala, "RSVP: A New Resource ReSerVation Protocol", IEEE Network, September 1993. ftp://parcftp.xerox.com/pub/net-research/rsvp.ps.z IP Next Generation - RSVP (16)