rsvp: the reservationprotocol

1The ReSerVation Protocol

RSVP: The ReSerVation Protocol

March 19, 1998

Gordon Chaffee

Berkeley Multimedia Research CenterUniversity of California, BerkeleyEmail: [email protected]

URL: http://bmrc.berkeley.edu/people/chaffee


Outline

• Introduction

• RSVP: The Protocol

• Priority Queuing Algorithms

• Other Reservation Technologies

• Comparison of RSVP and ATM


Quality of Service Requirements (1)

• Real-time applications• Interactive applications are sensitive to packet delays

(telephone)

• Non-interactive applications can adapt to a wider range of packet delays (audio, video broadcasts)

• Guarantee of maximum delay is useful

ArrivalOffsetGraph

PlayoutPoint

Sampled Audio

Playout Buffer must be small for interactive applications


Quality of Service Requirements (2)

• Elastic applications• Interactive data transfer (e.g. HTTP, FTP)

• Sensitive to the average delay, not to the distribution tail

• Bulk data transfer (e.g. mail and news delivery)• Delay insensitive

• Best effort works well

Document

Document is only useful when it is completely received. This means average packet delay is important, not maximum packet delay.Document


Discussion

• What is the problem?• Different applications have different delay, bandwidth,

and jitter needs

• Some applications are very sensitive to changing network conditions: the packet arrival time distribution is important

• Solutions• Make applications adaptive

• Build more flexibility into network


RSVP Overview• What is RSVP?

• Method for application to specify desired QoS to net

• Switch state establishment protocol (signaling)

• Multicast friendly, receiver-oriented

• Simplex reservations (single direction)

• Why run RSVP?• Allows precise allocation of network resources

• Guarantees on quality of service

• Heterogeneous bandwidth support for multicast

• Scalable (?)


RSVP Design Criteria

• Heterogeneous receivers (multicast)• Varying bandwidth needs

• Merging of resource reservations

• Dynamic membership

• Minimize control protocol overhead

• Soft state in routers• Reservations timeout if not refreshed periodically

• Adapt to routing changes gracefully: reestablish reservations


Protocol Independence

• RSVP designed to work with any protocol• Protocol must provide QoS support

• Examples: ATM, IP with Integrated Services

• Integrated Services• Defines different levels of packet delivery services

• Defines method to communicate with applications:Flowspec


Integrated Services Introduction

• IP only supports best effort delivery

• Want to send real-time traffic over Internet• Telephone, audio, video

• Benefits• Infrastructure costs amortized over larger number of

services

• Simpler infrastructure setup


Integrated Services Model

• Flow specification

• Routing

• Admission control

• Policy control

• Resource reservation

• Packet scheduling


RSVP Functional Diagram

Application

RSVPD

AdmissionsControl

PacketClassifier

PacketScheduler

PolicyControl

DATA

DATA

RSVPD

PolicyControl

AdmissionsControl

PacketClassifier

PacketScheduler

DATA

RoutingProcess

Host Router


What is a flow?

• Equivalent packets by some classification• RSVP: Set of packets traversing a network element that

are all covered by the same QoS request

• Packet classifier determines which packets belong to which flows• IPv6 includes a flow label to ease classification

• ISP usage (UUNET)• Microflow: TCP or similar bandwidth connection

• Macroflow: Large aggregates of packets flowing between two superhubs


Describing and Identifying a Flow

• Flowspec defines traffic parameters• Traffic parameters: bandwidth, buffering requirements

• Uses token bucket specification

• Filterspec identifies packets in flow• Simplest filter: Source, Dest address/port pair

• Data filter: classifies packets according to contents


Client Traffic Shaping

• Issue: Need traffic shaping to meet allocated resources

• Source promises that data traffic will conform to a particular shape

• Why describe and shape traffic?• Network knows what to expect, can manage traffic better

• Better admission control decisions

• Network can police flows

• Bursty traffic costly to router, network


Traffic Shaping Example

Flow 1

Flow 2

Data Queue

Data Queue


Traffic Shapers

• Simple leaky bucket• Isosynchronous flow: regular intervals between packets

• Token bucket• Bursty flow


Simple Leaky Bucket

• Sends data at fixed intervals onto network

• Bursts bigger than β are discarded

• Traffic never injected faster than ρ• Can be used with cells or datagrams

Data

= bucket size= rate data is sent onto network


Token Bucket

• Sends bursty traffic onto network

• Bucket filled with tokens at rate ρ• Data transmitted when enough tokens exist

• Allows bursts, but enforces upper bound

Data

= bucket size in tokens= rate tokens are added to bucket

Data Queue


Restrictions on Reservations

• Admissions• Is bandwidth available?

• Policy• Service guarantees give preferential access to network

bandwidth

• Permissions

• Pricing issues

• What are the policies of nodes on the path?• Policy data represents a scaling and security issue


Resource Reservation Model

• Senders advertise using flowspecs

• RSVP daemons forward advertisements to receivers, update available bandwidth, minimum delay

• Receivers reservations use flowspec, filterspec combination (flow descriptor)

• Sender/receiver notified of changes

• Reservations are merged in multicast case


Reservation Styles

• Wildcard Filter (WF)• Shared reservation, select all upstream senders

• Traffic from upstream senders shares a single pipe

• Appropriate for audio

• Shared Explicit (SE)• Shared reservation, explicit sender selection

• Appropriate for audio

• Fixed Filter (FF)• District reservations, explicit sender selection

• Appropriate for video


RSVP Service Types

• Controlled load

• Guaranteed service


Controlled Load Service

• Definition• Service that gives a flow the QoS it would receive if the

network was unloaded.

• Statistical guarantee

• No delay bounds

• Motivation• Support delay sensitive applications

• Minimal functionality


Controlled Load Requirements

• Admission Control• Ensure adequate resources are available

• Link bandwidth

• Computational power for processing flow

• Adequate buffer space to handle bursty traffic

• Operation• Little or no average packet queuing delay

• Little or no congestion loss

• Time period: significantly longer than burst time


Guaranteed Service

• Definition• Service providing guaranteed delay and bandwidth

• Firm guarantee on end-to-end queuing delays

• Delay• Two parts:

• Fixed delay: transmission delays, etc

• Queuing delay

• Queuing delay is a function of token bucket and data rate

• Often assumed that application has no control over delay

• Application can choose queuing sizes


RSVP Flowspecs

Peak Data Rate [p]

Minimum Policed Unit [m]

Maximum Policed Unit [M]

Token Bucket Rate [r]

. . .

Token Bucket Size [b]

Sender TSpec, Controlled Load Flowspec

Peak Data Rate [p]

Minimum Policed Unit [m]

Maximum Policed Unit [M]

Token Bucket Rate [r]

. . .

Token Bucket Size [b]

Guaranteed Flowspec

Rate [R]

Slack Term [S]


Packet Scheduling

• Implemented in hosts/routers to control link allocation

• Queuing algorithms• Weighted Fair Queuing (WFQ)

• Class Based Queuing (CBQ)

• Queue management• Random Early Detection (RED)


Weighted Fair Queuing (WFQ)

• Traffic placed into queues according to flow specification, flow filter

• Fair queuing• Implements fairness of bit by bit scheduling on a per

packet basis

• Gives queues a fair share of total bandwidth

• Weighted• Queue are not weighted evenly for scheduling

• Proven: adequate for Guaranteed Service


Class Based Queuing (CBQ)

• Combines scheduling and link sharing

• Hierarchical link sharing• Hierarchical queues

• Enables protocol, organization isolation

• Scheduling• Does not define a particular scheduling algorithm

• General scheduler for low latency when no congestion

• Link-sharing policing scheduler when congested

• Scheduling per hierarchy


CBQ Example

Company B

Real-Time

HTTPFTP

telnet IP DECnet

Company A

Video Audio

60% 40%

30%

20% 10%

20% 10%

LINK

20% 20%


Random Early Detection (RED)

• Random Early Detection (RED)• Queue management algorithm for congestion control

• Random packet drops as average queue length increases

• Can use Explicit Congestion Notification bit instead of dropping packet

• Works well for TCP

• Useful for congested Controlled Load service


Reservation Merging

Receiver#1

Receiver#2

Receiver#3

Reservations mergeas they travel up tree.

R6

R3

R1

R4 R7

(1) 50Kbs

(2) 50Kbs

(3) 50Kbs

(4) 100 Kbs

(5) 100 Kbs

(6) 100 Kbs

(7) 100 Kbs

(8) 60Kbs

(9) 60Kbs


Resource Reservation

• Senders advertise using PATH message

• Receivers reserve using RESV message• Flowspec + filterspec + policy data

• Travels upstream in reverse direction of Path message

• Merging of reservations

• Sender/receiver notified of changes


RSVP UDP Reservation (1)

R4

R5

R3R2

R1

Host A24.1.70.210

Host B128.32.32.69PATH

PATH

PATH

2

2. The Host A RSVP daemon generates a PATHmessage that is sent to the next hop RSVP router, R1, in the direction of the session address, 128.32.32.69.

PATH3

3. The PATH message follows the next hop path through R5 and R4 until it gets to Host B. Each router on the path creates soft session state with the reservation parameters.

1. An application on Host A creates a session, 128.32.32.69/4078, by communicating with the RSVP daemon on Host A.

1


RSVP UDP Reservation (2)

R4

R5

R3R2

R1

Host A24.1.70.210

Host B128.32.32.69

PATHPATH

PATH

PATH

RESV

RESV

RESV

5

5. The Host B RSVP daemon generates a RESV message that is sent to the next hop RSVP router, R4, in the direction of the source address, 24.1.70.210.

RESV

6

6. The RESV message continues to follow the next hop path through R5 and R1 until it gets to Host A. Each router on the path makes a resource reservation.

4. An application on Host B communicates with the local RSVP daemon and asks for a reservation in session 128.32.32.69/4078. The daemon checks for and finds existing session state.

4


RSVP Multicast Reservation (1)

R5 R6

R3R2

R1

R4 R7

Sender

Receiver

PATH

PATH

PATH

PATH

PATH

PATH

PATH

PATHPATH


RSVP Multicast Reservation (2)

R5 R6

R3R2

R1

R4 R7

Sender

Receiver


TSpecs, AdSpecs, and RSpecs

• Traffic source sends TSpec (Traffic Specification)• Consists of FlowSpec and AdSpec

• AdSpec updated to reflect network capabilities• Routers update minimum delay and maximum bandwidth

• Termed One Pass With Advertisement (OPSA)

• RSpec• Receiver uses Controlled Load or Guaranteed FlowSpec

to reserve network resources


RSVP and TCP

• RSVP provides a bandwidth reservation

• TCP is not a constant bitrate service• Slow start gives exponential growth until loss

• Periodic probes for higher bandwidth

• TCP behavior leads to best effort delivery

Ban

dwid

th

Time

Bandwidth Reserved with RSVP

Slow Start

Linear Increase

Best Effort DeliveryPacket Drop

Multiplicative Decrease


Problems with Merging Reservations

• Issue: who pays for service, how much?

• Merging different types of flows• Flow 1: Low delay, low bandwidth

• Flow 2: High delay, high bandwidth

• Flow with low delay, high bandwidth satisfies Flows 1 and 2, but it may cost much more than Flow 1 or 2.

• Only certain flows can be easily merged given price constraints


Reservation Merging and Price

Ba n

dwid

th

Latency

Reservation 2:High Bandwidth,

High Latency

Reservation 1:Low Bandwidth,

Low Latency

Merged Reservation:High Bandwidth,

Low Latency

Price: Darker = More Costly


RSVP Routing Problems

• Routing is separated from admission control

• If route changes, reservation must be made along new route• New reservation takes time to setup

• New reservation might fail

• Old route could still be working fine

• Route pinning• Always use the route where reservation is in place


Routing Problems (cont’d)

• Reservation failure• Primary route has inadequate bandwidth although

secondary has enough

• Telephone system has a crankback feature• Allows secondary routes to be considered if reservation

on primary route fails

• ATM• Routing combined with admission control


Usage and Implementation

• RSVP is not widely available• Best effort delivery across links with no RSVP services

• Reservation flag to specify that traffic traveled over a non-RSVP link

• Some links will have guaranteed performance for some traffic, but not all• Policy issues at boundaries of networks


Current RSVP Implementations

• Cisco router has RSVP support

• RSVP daemon available from USC ISI• Runs on Solaris, BSD Net 2 derivatives

• Limitations• Filtering is currently based on host id/port numbers

• Would like better filtering for layered codecs


Our Test Setup

• Testbed• FreeBSD 2.2.1 with ISI’s RSVP daemon

• mgen for generating, reserving traffic

• Test: many small bandwidth reservations


Our Testbed Network

100 MbsEthernet Hub

Workstation

Workstation

Workstation

RSVPRouter

Workstation

RSVPRouter

Workstation

100 Mbs Link

10 Mbs Link

LaptopLaptopWBMRC2 Mbs Capacity

Traffic Generator

BMRCNetwork

UCBMBONE

RSVPRouter

Workstation

100 Mbs LinkWorkstation100 Mbs

Ethernet Hub

Workstation

10 Mbs Link


Our Test Results

• RSVP daemon failed near 5 reservations• Incorrectly implemented daemon on non-leaf routers

• Kernel crashes and control data corruption

• Debugging tools also failed

• Solaris implementation worked better

• Unable to complete our tests

• Conclusion: tools, daemon still immature


Stony Brook Performance Test

• Tzi-cker Chiueh and Anindya Neogi (New York State Univ at Stony Brook)

• Testbed• Cisco router using WFQ for real-time connections

• Precept software for flow generation and reservations

• Measured performance using a varying numbers of real-time sessions


Stony Brook Performance Results

• Control traffic overhead was minimal

• Control messages should be sent at high priority

• Real-time packet classification and scheduling has significant overhead• Packet losses show up at 400 sessions

• Too much work for WFQ classifier, scheduler

• FIFO scheduler on non-real-time traffic worked

• Effective link bandwidth lowered


Other Reservation Technologies

• The telephone network• Single, basic service (64Kbs)

• Guaranteed, low delay resources

• Circuit based system

• ATM


RSVP Stream Aggregation

• Aggregation of unicast flows only• Aggregate data traffic

• Aggregate control traffic

• Fit into pre-allocated service classes• Similar to telephone network scheme


RSVP Debugging

• Multicast capable services need debugging built into protocol

• Diagnostic messages• Collect state information on all nodes along path for a

session

• Requestor sends DREQ message to first hop RSVP router

• First hop router fills in its state, forwards toward sender(s)

• Packet reaches sender, changed to DREP, and sent directly to requestor


Will RSVP Succeed?

• Telcos and long-haul ISPs want constant bit-rate allocations• RSVP will not control backbone allocations

• Need simpler mechanism such as differentiated service

• Microsoft, networking vendors see demand for QoS over IP• RSVP is only alternative today

• RSVP might find a home in corporate networks

• Current implementations immature• Internet 2 testbed will experiment with deployment

This document was created with Win2PDF available at http://www.daneprairie.com.The unregistered version of Win2PDF is for evaluation or non-commercial use only.

http://www.daneprairie.com

rsvp: the reservationprotocol

Documents