TF-TEN

Stuttgart 96-08-29

RSVP Overview

Olav.Kvittem@uninett.no

IETF working groups

Integrated Services (intserv)

The working group will focus on defining a minimal set of global requirements which transition the Internet into a robust integrated-service communications infrastructure.

Enhanced Internet service model
Defining the application service, router scheduling and (general) subnet interfaces.
Developing router validation requirements which can ensure that the proper service is provided

Current Internet-Drafts

Specification of Guaranteed Quality of Service
Specification of General Characterization Parameters
Intgrated Services Management Information Base
Specification of the Controlled-Load Network Element Service
Specification of Committed Rate Quality of Service (38997 bytes)
Integrated Services Management Information Base Guaranteed Service Extensions
The Use of RSVP with IETF Integrated Services

Resource Reservation Setup Protocol (rsvp)

The primary purpose of this working group is to evolve the RSVP specification and to introduce it into the Internetstandards track.

Current Internet-Drafts

Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification
RSVP Cryptographic Authentication
RSVP Management Information Base
RSVP Diagnostic Messages
Local Policy Modules (LPM): Policy Enforcement for Resource Reservation Protocols
Accounting and Access Control Policies for Resource Reservation Protocols (14731 bytes).
RSVP Extensions for Policy Control
RSVP Operation Over IP Tunnels

Integrated Services over Specific Link Layers (issll)

The ISSLL Working Group defines specifications and techniques needed to implement Internet Integrated Services capabilities within specific network technologies.

Current Internet-Drafts

Providing integrated services over low-bitrate links
IP Integrated Services Support in ATM

Integrated Service model

Flow specification

characteristics of a traffic stream by a source
service requirements (flowspec)

Routing

Quality-based routing
MOSPF, CBT ...

Resource reservation

bandwith reservation
buffer reservation

Admission control

grant or deny access

Packet Scheduling

scheduling alorithms
weighted fair queuing ?

resource ReSerVation Protocol (RSVP)

A vehicle for the applications to communicate their requirements to the network
A switch state establishment protocol

Design criteria

Multicast support with multiple senders and heterogeneous reivers not supported
heterogeneous receivers - different QOS
dynamic membership - leaf join
aggregation of resource reservations - minimize demand
user selects sources/channel ( to limit resource use)
adapt to routing changes gracefully -
restablish reservations automatically
control protocol overhead - scaling to large conferences
independent of other components of the service paradigm

RSVPs major features include:

(1) the use of \Q\Qsoft state''in the routers,
(2) receiver-controlled reservation requests,
(3) flexible control over sharing of reservations and forwarding of subflows, and
(4) the use of IP multicast for data distribution.

Make reservations

RSVP daemon makes reservation
Admission control - checks for resources
Policy control - check permissions
Packet classifier - determines QOS for each packet
Packet scheduler - orders packets to obtain QOS
Transparent to traffic and policy controls

Reservation properties

Receiver-oriented reservation that merge = scales
Uses available routing protocols (defines interface)
Both IPv4 and IPv6
Soft state - reservations time out and is refreshed = recovers nicely
Simplex - unidirectional flows
Transparent to not-supporting routers

Reservation elements

session = flow destination(address) and transport protocol (TCP/UDP) and port (sender view)
Flow descriptor = flowspec + filter spec
(receiver view)
Flowspec =QOS spec
Filter spec = select packets to receive
Sender address + UDP/TCP port
Reservation request carried upstream
merging requests until upstream request >= current
Unreliable confirmation from the merge point to the requester

Reservation Styles

Wildcard-Filter = multiple wildcarded senders share the same reservation (only one talk at a time)
Fixed-Filter = distinct reservations per sender(video)
Shared Explisit = explisit list of senders share the same reservation

Protocol mechanisms

Path messages

Sender sends Path messages down-stream
Stores IP-address of previous hop for reverse path

Resv messages

reservation messages by receiver
follows reverse path to create reservations upstream

Teardown

Will timeout by soft state, but explicit teardown
is recommended by sender or receiver

Confirmation

can be requested by receiver for reservations
no quaraties for delivery of confirmation

Host model

H1 A receiver joins the multicast group specified by DestAddress, using IGMP.
H2 A potential sender starts sending RSVP Path messages to theDestAddress.
H3 A receiver application receives a Path message.
H4 A receiver starts sending appropriate Resv messages, specifying the desired flow descriptors.
H5 A sender application receives a Resv message.
H6 A sender starts sending data packets.

Implementations

The ISI prototype,

available from the ftp://ftp.isi.edu/rsvp/release directory,
contains code for a workstation used as a host or router.
It includes an RSVP daemon program,
an API,
RSVP interfaces for some of the MBONE tools, and some test tools.
Most of this code was developed under SunOS, but it is easily portable to a variety of BSD-based operating systems.

Cisco release 11.2 is expected to have an implementation

Last Modified: 07:59pm MET DST, August 28, 1996