Transcript IntServ, DiffServ, RSVP

15-441 Computer Networking
Intserv, Diffserv, RSVP
1
Motivation
• Internet currently provides only single class of
“best-effort” service.
• No admission control and no assurances about delivery
• Existing applications are elastic.
• Tolerate delays and losses
• Can adapt to congestion
• Future “real-time” applications may be inelastic.
• Should we modify these applications to be more
adaptive or should we modify the Internet to
support inelastic behavior?
Lecture 22: 11/20/2001
2
Application Types
• Elastic applications.
• Wide range of acceptable rates, although faster is better
• E.g., data transfers such as FTP
• Continuous media applications.
• Lower and upper limit on acceptable performance
• Sometimes called “tolerant real-time” since they can adapt to the
performance of the network
• E.g., changing frame rate of video stream
• “Network-aware” applications
• Hard real-time applications.
• Require hard limits on performance – “intolerant real-time”
• E.g., control applications
Lecture 22: 11/20/2001
3
Improving QOS in IP Networks
• IETF groups are working on proposals to provide
better QOS control in IP networks, i.e., going beyond
best effort to provide some assurance for QOS.
• Work in Progress includes RSVP, Differentiated
Services, and Integrated Services.
Lecture 22: 11/20/2001
4
Overview
•
•
•
•
Principles for QoS
Integrated Services (Intserv)
Differentiated Services (Diffserv)
Resource ReSerVation Protocol (RSVP)
Lecture 22: 11/20/2001
5
Principles for QOS Guarantees
• Simple model for sharing and congestion studies
(“dumbell topology”):
Lecture 22: 11/20/2001
6
Principles for QOS Guarantees
(more)
• Consider a phone application at 1Mbps and an FTP
application sharing a 1.5 Mbps link.
• Bursts of FTP can congest the router and cause audio packets to
be dropped.
• Want to give priority to audio over FTP.
• PRINCIPLE 1: Marking of packets is needed for router
to distinguish between different classes; and new
router policy to treat packets accordingly.
Lecture 22: 11/20/2001
7
Principles for QOS Guarantees
(more)
• Applications misbehave (audio sends packets at a rate
higher than 1Mbps assumed above).
• PRINCIPLE 2: provide protection (isolation) for one
class from other classes.
• Require Policing Mechanisms to ensure sources adhere to
bandwidth requirements; Marking and Policing need to be
done at the edges:
Lecture 22: 11/20/2001
8
Principles for QOS Guarantees
(more)
• Alternative to Marking and Policing: allocate a set portion
of bandwidth to each application flow; can lead to
inefficient use of bandwidth if one of the flows does not
use its allocation.
• PRINCIPLE 3: While providing isolation, it is desirable
to use resources as efficiently as possible.
Lecture 22: 11/20/2001
9
Principles for QOS Guarantees
(more)
• Cannot support traffic beyond link capacity.
• PRINCIPLE 4: Need a Call Admission Process; application
flow declares its needs, network may block call if it cannot
satisfy the needs .
Lecture 22: 11/20/2001
10
Summary
Lecture 22: 11/20/2001
11
A Short History of Internet QoS
• Lots of initial research in the late 80s and early
90s.
• Often takes a telecommunications view of the network.
• ATM QoS and Integrated services were
developed based on these results.
• Focus on per-flow, hard QoS.
• Effort was driven by perceived application needs.
• In the last 5 years, the focus has shifted towards
Differentiated services.
• Focus is on QoS for flow aggregates, e.g., all the flows
belonging to one customer.
Lecture 22: 11/20/2001
12
Overview
•
•
•
•
Motivation for QoS
Integrated Services (Intserv)
Differentiated Services (Diffserv)
Resource ReSerVation Protocol (RSVP)
Lecture 22: 11/20/2001
13
IETF Intserv
• Focus on per-flow QoS.
• Support specific applications such as video
streaming.
• Based on mathematical guarantees.
• Many concerns:
•
•
•
•
Complexity
Scalability
Business model
Charging
Lecture 22: 11/20/2001
14
Components of Integrated
Services
• Type of service model
• What does the network promise?
• Service interface
• How does the application describe what it wants?
• Packet scheduling
• How does the network meet promises?
• Establishing the guarantee
• How is the promise communicated to/from the network?
• How is admission of new applications controlled?
Lecture 22: 11/20/2001
15
Service Models
• Network can support traffic streams with different
“quality of service”.
• Best effort
• Predictive or differentiated services
• Strong guarantees on the level of service (real-time)
• The set of services that is supported on a specific
network can be viewed as a service model.
• Model that can be used to select a service
• E.g., cost versus performance tradeoffs
• Network architecture that supports the set of services
• Considers interactions between services
Lecture 22: 11/20/2001
16
Service Models
• Guaranteed service
•
•
•
•
Targets hard real-time applications.
User specifies traffic characteristics and a service requirement.
Requires admission control at each of the routers.
Can mathematically guarantee bandwidth, delay, and jitter.
• Controlled load.
• Targets applications that can adapt to network conditions within a
certain performance window.
• User specifies traffic characteristics and bandwidth.
• Requires admission control at each of the routers.
• Guarantee not as strong as with the guaranteed service.
• e.g., measurement-based admission control.
• Best effort
Lecture 22: 11/20/2001
17
Service Interface
• Session must first declare its QoS requirement and
characterize the traffic it will send through the network
• R-spec: defines the QoS being requested by receiver
(e.g., rate r)
• T-spec: defines the traffic characteristics of sender (e.g.,
leaky bucket with rate r and buffer size b).
• A signaling protocol is needed to carry the R-spec and Tspec to the routers where reservation is required; RSVP is
a leading candidate for such signaling protocol.
Lecture 22: 11/20/2001
18
Packet scheduling
• Guaranteed service
• Use token bucket filter to characterize traffic
• Described by rate r and bucket depth b
• Use WFQ at the routers
• Parekh’s bound for worst case queuing delay = b/r
Lecture 22: 11/20/2001
19
Call Admission
• Call Admission: routers will admit calls based on
their R-spec and T-spec and base on the current
resource allocated at the routers to other calls.
Lecture 22: 11/20/2001
20
Overview
•
•
•
•
Motivation for QoS
Integrated Services (Intserv)
Differentiated Services (Diffserv)
Resource ReSerVation Protocol (RSVP)
Lecture 22: 11/20/2001
21
Differentiated Services
• Intended to address the following difficulties with Intserv
and RSVP;
• Scalability: maintaining states by routers in high speed
networks is difficult due to the very large number of flows
• Flexible Service Models: Intserv has only two classes,
want to provide more qualitative service classes; want to
provide ‘relative’ service distinction (Platinum, Gold, Silver,
…)
• Simpler signaling: (than RSVP) many applications and
users may only want to specify a more qualitative notion of
service
Lecture 22: 11/20/2001
22
Diffserv - Motivation
• Do fine-grained enforcement only at the edge of the
network.
• Typically slower links at edges
• E.g., mail sorting in post office
• Label packets with a field.
• E.g., a priority stamp
• The core of the network uses only the type field for QoS
management.
• Small number of types with well defined forwarding behavior
• Can be handled fast
• Example: expedited service versus best effort
• Evolution rather than revolution
Lecture 22: 11/20/2001
23
Diffserv - Discussion
• Diffserv defines an architecture and a set of forwarding
behaviors.
• It is up to the service providers to define and implement end-to-end
services on top of this architecture.
• Offers a more flexible service model; different providers can offer
different service.
• One of the main motivations for Diffserv is scalability.
• Keep the core of the network simple.
• Focus of Diffserv is on supporting QoS for flow
aggregates.
• Although architecture does not preclude more fine-grained
guarantees.
Lecture 22: 11/20/2001
24
Edge Router/Host Functions
• Classification: marks
packets according to
classification rules to be
specified.
• Metering: checks whether
the traffic falls within the
negotiated profile.
• Marking: marks traffic that
falls within profile.
• Conditioning: delays and
then forwards, discards, or
remarks other traffic.
Lecture 22: 11/20/2001
25
Classification and Conditioning
• Packet is marked in the Type of Service (TOS) in
IPv4, and Traffic Class in IPv6.
• 6 bits used for Differentiated Service Code Point
(DSCP) and determine PHB that the packet will
receive.
• 2 bits are currently unused.
Lecture 22: 11/20/2001
26
Core Functions
• Forwarding: according to “Per-Hop-Behavior” or
PHB specified for the particular packet class; such
PHB is strictly based on class marking (no other
header fields can be used to influence PHB).
• BIG ADVANTAGE:
No state info to be maintained by routers!
Lecture 22: 11/20/2001
27
Forwarding (PHB)
• PHB result in a different observable (measurable)
forwarding performance behavior.
• PHB does not specify what mechanisms to use to
ensure required PHB performance behavior.
• Examples:
• Class A gets x% of outgoing link bandwidth over time
intervals of a specified length.
• Class A packets leave first before packets from class B.
Lecture 22: 11/20/2001
28
Forwarding (PHB)
• Expedited Forwarding (EF):
• Guarantees a certain minimum rate for the EF traffic.
• Implies isolation: guarantee for the EF traffic should not
be influenced by the other traffic classes.
• Admitted based on peak rate.
• Non-conformant traffic is dropped or shaped.
• Possible service: providing a virtual wire.
Lecture 22: 11/20/2001
29
Forwarding (PHB)
• Assured Forwarding (AF):
• AF defines 4 classes with some bandwidth and buffers
allocated to them.
• The intent is that it will be used to implement services
that differ relative to each other (e.g., gold, silver,…).
• Within each class, there are three drop priorities, which
affect which packets will get dropped first if there is
congestion.
• Lots of studies on how these classes and drop priorities
interact with TCP flow control.
• Non-conformant traffic is remarked.
Lecture 22: 11/20/2001
30
Example of EF: A Virtual Leased
Line Service
• Service offers users a dedicated traffic pipe.
• Guaranteed bandwidth between two points.
• Very low latency and jitter since there should be no
queuing delay (peak rate allocation).
• Admission control makes sure that all links in the
network core have sufficient EF bandwidth.
• Simple case: sum of all virtual link bandwidth is less
than the capacity of the slowest link.
• Traffic enforcement for EF traffic limits how much
EF traffic enters the network.
Lecture 22: 11/20/2001
31
Differentiated Services Issues
• AF and EF are not even in a standard track yet… research
ongoing.
• The key to making Diffserv work is bandwidth
management in the network core.
• Simple for simple services such as the virtual pipe, but it is much
more challenging for complex service level agreements.
• Notion of a “bandwidth broker” that manages the core network
bandwidth.
• Definition of end-to-end services for paths that cross
networks with different forwarding behaviors
• Some packets will be handled differently in different routers.
• Some routers are not DiffServ capable.
Lecture 22: 11/20/2001
32
Overview
•
•
•
•
Motivation for QoS
Integrated Services (Intserv)
Differentiated Services (Diffserv)
Resource ReSerVation Protocol (RSVP)
Lecture 22: 11/20/2001
33
Components of Integrated
Services
• Type of service model
• What does the network promise?
• Service interface
• How does the application describe what it wants?
• Packet scheduling
• How does the network meet promises?
• Establishing the guarantee
• How is the promise communicated to/from the network
• How is admission of new applications controlled?
Lecture 22: 11/20/2001
34
Role of RSVP
• Rides on top of unicast/multicast routing
protocols.
• Must be present at sender(s), receiver(s), and
routers.
• Carries resource requests all the way through the
network.
• At each hop consults admission control and sets
up reservation. Informs requester if failure.
Lecture 22: 11/20/2001
35
Reservation Protocol: RSVP
Upper layer protocols and applications
IP service interface
IP
ICMP IGMP RSVP
Link layer service interface
Link layer modules
Lecture 22: 11/20/2001
36
RSVP Goals
• Used on connectionless networks.
• Should not replicate routing functionality.
• Should co-exist with route changes.
• Support for multicast.
• Different receivers have different capabilities and want different QOS.
• Changes in group membership should not be expensive.
• Reservations should be aggregate – I.e. each receiver in group should not
have to reserve.
• Should be able to switch allocated resource to different senders.
• Limit control overhead.
• Modular design – should be generic “signaling” protocol.
• Result:
• Receiver-oriented
• Soft-state
Lecture 22: 11/20/2001
37
Receiver-Initiated Reservation
• Receiver initiates reservation by sending a reservation
over the sink tree.
• Assumes multicast tree has been set up previously.
• Also uses receiver-initiated mechanism.
• Hooks up with the reserved part of the tree.
• How far the request has to travel to the source depends on the
level of service requested.
• Uses existing routing protocol, but routers have to store the sink
tree (reverse path from forwarding path).
• Properties:
• Scales well: can have parallel independent connect and disconnect
actions – single shared resource required.
• Supports receiver heterogeneity: reservation specifies receiver
requirements and capabilities.
Lecture 22: 11/20/2001
38
Soft State
•
•
•
•
Routers keep state about reservation.
Periodic messages refresh state.
Non-refreshed state times out automatically.
Alternative: Hard state
•
•
•
•
No periodic refresh messages.
State is guaranteed to be there.
State is kept till explicit removal.
Why could there be a problem?
• Properties of soft state:
• Adapts to changes in routes, sources, and receivers.
• Recovers from failures
• Cleans up state after receivers drop outs
• Philosophy: reservation is an optimization.
Lecture 22: 11/20/2001
39
RSVP Service Model
• Make reservations for simplex data streams.
• Receiver decides whether to make reservation
• Control messages in IP datagrams (proto #46).
• PATH/RESV messages sent periodically to refresh
soft state.
• One pass:
• Failed requests return error messages - receiver must
try again.
• No end to end ack for success.
Lecture 22: 11/20/2001
40
Basic Message Types
• PATH message
• RESV message
• CONFIRMATION message
• Generated only upon request.
• Unicast to receiver when RESV reaches node with
established state.
• TEARDOWN message
• ERROR message (if PATH or RESV fails)
Lecture 22: 11/20/2001
41
PATH Messages
• PATH messages carry sender’s T-spec.
• Token bucket parameters
• Routers note the direction PATH messages
arrived and set up reverse path to sender.
• Receivers send RESV messages that follow
reverse path and setup reservations.
• If reservation cannot be made, user gets an error.
Lecture 22: 11/20/2001
42
RESV Messages
•
•
•
•
•
RESV messages carry receiver’s R-spec.
Forwarded via reverse path of PATH.
Queuing delay and bandwidth requirements.
Source traffic characteristics (from PATH).
Filter specification
• Which transmissions can use the reserved resources?
• Reservation style.
• Router performs admission control and reserves
resources.
Lecture 22: 11/20/2001
43
Router Handling of RESV
Messages
• If new request rejected, send error message.
• If admitted:
•
•
•
•
Install packet filter into forwarding dbase.
Pass flow parameters to scheduler.
Activate packet policing if needed.
Forward RESV message upstream.
Lecture 22: 11/20/2001
44
RSVP reservations
• Reservations from multiple receivers for a single
sender are merged together at branching points.
• Reservations for multiple senders may be added
up:
• Video conference
• Reservations for multiple senders may not be
added up:
• Audio conference, not many talk at same time.
• Only subset of speakers (filters).
Lecture 22: 11/20/2001
45
Reservation Styles
• Three styles
• Wildcard/No filter – does not specify a particular sender
for group.
• Fixed filter – sender explicitly specified for a
reservation.
• Video conference
• Dynamic filter – valid senders may be changed over
time.
• Audio conference
Lecture 22: 11/20/2001
46
Example
A
C
S1
B
D
S2, S3
R1
R2
R3
• Senders S1, S1, S3
• Receivers R1, R2, R3
• Router interfaces A,B,C,C
Lecture 22: 11/20/2001
47
Wildcard Filter Reservation
• R1, R2, and R3 want to reserve 4b, 3b, and 2b,
respectively (b is given rate).
4b
A
C
S1
4b
B
4b
R1
D
S2, S3
R2
3b
Lecture 22: 11/20/2001
R3
48
Fixed Filter Reservation
• R1 wants to reserve 4b for S1 and 5b for S2.
• R2 wants to reserve 3b for S1 and b for S3.
• R3 wants to reserve b for S1.
S1:4b A
C
S1
B
S1:4b
S2:5b
R1
D
S2, S3
S2:5b
S3:b
R2
S1:3b
S3:b
Lecture 22: 11/20/2001
R3
49
Dynamic Filter Reservation
• R1 wants to reserve b for S1 and S2 (shared).
• R2 wants to reserve 3b for S1 and S3 (shared).
• R3 wants to reserve 2b for S2.
S1:3b A
C
S1
B
R1
D
R2
(S1,S2,S3):3b
R3
S2, S3
(S2,S3):3b
(S1,S2):b
Lecture 22: 11/20/2001
50
Changing Reservation
• Receiver-oriented approach and soft state make it
easy to modify reservation.
• Modification sent with periodic refresh.
Lecture 22: 11/20/2001
51
Routing Changes
• Routing protocol makes routing changes.
• In absence of route or membership changes,
periodic PATH and RESV messages refresh
established reservation state.
• When change, new PATH messages follow new
path, new RESV messages set reservation.
• Non-refreshed state times out automatically.
Lecture 22: 11/20/2001
52
State in Switches
• Have to keep sink tree information.
• No such thing as inverse multicast routing.
• Also have to keep information on sources if filters are
used.
• Selected in path message.
• Used in aggregation and propagating information to switches.
• Also used in limiting protocol overhead.
• Switches do not propagate periodic reservation and path
messages.
• They periodically regenerate copies that summarize the
information they have.
• Raises concerns about scalability.
Lecture 22: 11/20/2001
53
RSVP - Review
• Concentration on multicast may have been wrong
idea.
• Unicast considered as special case of multicast.
• Receiver initiation – handle negotiation at
application level.
• Receiver heterogeneity – how can low-capability
receiver benefit from video sent at high
bandwidth?
• Layered encoding
• Soft state
• Hard state works in telephony network
Lecture 22: 11/20/2001
54