Reservation von Ressourcen im Internet Prof. B. Plattner ETH Zürichpeople.ee.ethz.ch/~plattner/Kursunterlagen/IPng/RSVP.pdf · Beispiele für die Verwendung von Filtern • “Disziplinierte”

IP Next Generation - RSVP (1)© B. Plattner /H. Lubich

Reservation von Ressourcen im Internet

Prof. B. PlattnerETH Zürich


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


Einbettung von RSVP in Hosts und Routern

Control path

Data path


Beispiel


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


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.


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


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)


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


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.


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)


Formate von RSVP-Nachrichten

IPv6 Header

RSVP Ext. Header

RSVP Object


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


Beispiel: Live-Präsentation mit 2 Sendernund 2 Empfängern

S1

R1 R2

S2 E2

E1L2

L1L4

L3L5


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


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

Documents

Reservation von Ressourcen im Internet Prof. B. Plattner ETH Zürichpeople.ee.ethz.ch/~plattner/Kursunterlagen/IPng/RSVP.pdf · Beispiele für die Verwendung von Filtern • “Disziplinierte”