Upload
others
View
6
Download
0
Embed Size (px)
Citation preview
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
2The ReSerVation Protocol
Outline
• Introduction
• RSVP: The Protocol
• Priority Queuing Algorithms
• Other Reservation Technologies
• Comparison of RSVP and ATM
3The ReSerVation Protocol
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
4The ReSerVation Protocol
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
5The ReSerVation Protocol
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
6The ReSerVation Protocol
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 (?)
7The ReSerVation Protocol
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
8The ReSerVation Protocol
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
9The ReSerVation Protocol
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
10The ReSerVation Protocol
Integrated Services Model
• Flow specification
• Routing
• Admission control
• Policy control
• Resource reservation
• Packet scheduling
11The ReSerVation Protocol
RSVP Functional Diagram
Application
RSVPD
AdmissionsControl
PacketClassifier
PacketScheduler
PolicyControl
DATA
DATA
RSVPD
PolicyControl
AdmissionsControl
PacketClassifier
PacketScheduler
DATA
RoutingProcess
Host Router
12The ReSerVation Protocol
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
13The ReSerVation Protocol
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
14The ReSerVation Protocol
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
15The ReSerVation Protocol
Traffic Shaping Example
Flow 1
Flow 2
Data Queue
Data Queue
16The ReSerVation Protocol
Traffic Shapers
• Simple leaky bucket• Isosynchronous flow: regular intervals between packets
• Token bucket• Bursty flow
17The ReSerVation Protocol
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
18The ReSerVation Protocol
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
19The ReSerVation Protocol
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
20The ReSerVation Protocol
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
21The ReSerVation Protocol
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
22The ReSerVation Protocol
RSVP Service Types
• Controlled load
• Guaranteed service
23The ReSerVation Protocol
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
24The ReSerVation Protocol
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
25The ReSerVation Protocol
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
26The ReSerVation Protocol
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]
27The ReSerVation Protocol
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)
28The ReSerVation Protocol
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
29The ReSerVation Protocol
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
30The ReSerVation Protocol
CBQ Example
Company B
Real-Time
HTTPFTP
telnet IP DECnet
Company A
Video Audio
60% 40%
30%
20% 10%
20% 10%
LINK
20% 20%
31The ReSerVation Protocol
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
32The ReSerVation Protocol
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
33The ReSerVation Protocol
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
34The ReSerVation Protocol
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
35The ReSerVation Protocol
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
36The ReSerVation Protocol
RSVP Multicast Reservation (1)
R5 R6
R3R2
R1
R4 R7
Sender
Receiver
PATH
PATH
PATH
PATH
PATH
PATH
PATH
PATHPATH
37The ReSerVation Protocol
RSVP Multicast Reservation (2)
R5 R6
R3R2
R1
R4 R7
Sender
Receiver
38The ReSerVation Protocol
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
39The ReSerVation Protocol
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
40The ReSerVation Protocol
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
41The ReSerVation Protocol
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
42The ReSerVation Protocol
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
43The ReSerVation Protocol
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
44The ReSerVation Protocol
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
45The ReSerVation Protocol
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
46The ReSerVation Protocol
Our Test Setup
• Testbed• FreeBSD 2.2.1 with ISI’s RSVP daemon
• mgen for generating, reserving traffic
• Test: many small bandwidth reservations
47The ReSerVation Protocol
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
48The ReSerVation Protocol
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
49The ReSerVation Protocol
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
50The ReSerVation Protocol
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
51The ReSerVation Protocol
Other Reservation Technologies
• The telephone network• Single, basic service (64Kbs)
• Guaranteed, low delay resources
• Circuit based system
• ATM
52The ReSerVation Protocol
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
53The ReSerVation Protocol
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
54The ReSerVation Protocol
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.