Upload
others
View
8
Download
0
Embed Size (px)
Citation preview
IP Next Generation - RSVP (1)© B. Plattner /H. Lubich
Reservation von Ressourcen im Internet
Prof. B. PlattnerETH Zürich
IP Next Generation - RSVP (2)© B. Plattner /H. Lubich
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 (3)© B. Plattner /H. Lubich
Einbettung von RSVP in Hosts und Routern
Control path
Data path
IP Next Generation - RSVP (4)© B. Plattner /H. Lubich
Beispiel
IP Next Generation - RSVP (5)© B. Plattner /H. Lubich
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 (6)© B. Plattner /H. Lubich
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 (7)© B. Plattner /H. Lubich
Prinzipien des Resource Reservation Protocol (RSVP)
• Empfänger-orientierte Reservation (diese wissen, was sie wollen); Sender schicken path messages, Empfängerschicken 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 (8)© B. Plattner /H. Lubich
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 (9)© B. Plattner /H. Lubich
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 desSenders Distinct Shared
Explicit Fixed-Filterstyle
Shared-Explicit style
Wildcard Nicht definiert Wildcard-Filterstyle
IP Next Generation - RSVP (10)© B. Plattner /H. Lubich
Beispiele für die Verwendung von Filtern
• “Disziplinierte” Audio-Konferenz: Wenn immer nur ein Teilnehmer spricht, müssen Ressourcen nur für einenAudio-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 10Teilnehmern: Ein Empfänger reserviert so, dass er nur zwei Bilder mit guter Qualität empfängt: Das des Sprechenden und das des vorangehenden Sprechers. Dierestlichen Bilder werden in “best-effort” Qualität übertragen. Anwendung für wildcard oder shared-explicitfilter.
IP Next Generation - RSVP (11)© B. Plattner /H. Lubich
Ablauf von RSVP
• Identifikation einer Session durch Session-ID• Sender schickt path request (mit Sessionsbeschreibung)
in einem IPv6-Paket an die Destination. Die Routerentlang der Route merken sich die Daten der Session undden Pfad zum Sender.
• Empfänger schicken reservation requests zum nächstenRouter. 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 derRequest in Richtung Sender weitergeleitet.
• path und reservation requests werden periodisch wiederholt (-> soft state)
IP Next Generation - RSVP (12)© B. Plattner /H. Lubich
Formate von RSVP-Nachrichten
IPv6 Header
RSVP Ext. Header
RSVP Object
IP Next Generation - RSVP (13)© B. Plattner /H. Lubich
Typen von RSVP-Nachrichten
Typ Verwendung
Path message Sender -> Empfänger;Charakterisierung der Daten proSender
Reservation message Reservationen der Empfänger
Path m. error indication Fehlerrückmeldung für fehlgeschlagenePath message
Reservation m. errorindication
Fehlerrückmeldung für fehlgeschlageneReservation
Path teardown message Expliziter Abbau der Path-Information
Reservation teardownmessage
Freigabe der reservierten Ressourcen
IP Next Generation - RSVP (14)© B. Plattner /H. Lubich
Beispiel: Live-Präsentation mit 2 Sendernund 2 Empfängern
S1
R1 R2
S2 E2
E1L2
L1L4
L3L5
IP Next Generation - RSVP (15)© B. Plattner /H. Lubich
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 (16)© B. Plattner /H. Lubich
Literaturhinweise
• RSVP Working Group des IETF: http://www.ietf.org/html.charters/rsvp-charter.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