RSVP and Integrated Services in the Internet: A Tutorial

Download Report

Transcript RSVP and Integrated Services in the Internet: A Tutorial

RSVP and Integrated Services
in the Internet: A Tutorial
Paul P. White, University College London
IEEE Communications Magazine,
May 1997
Members:劉佳妮、陳駿元、魏君竹
Presenter:劉佳妮
Date:2002/12/10
1
Outline
 Introduction
 IETF integrated services
 Guaranteed service
 Controlled-Load service
 RSVP(Resource reservation protocol)
 Path messages
 Reservation styles and merging
 Slack Term
 Summary
2
Introduction
 The current Internet consists of a multitude of
networks built from various link-layer
technologies and relies on the Internet Protocol
(IP) to interwork between them.
 IP offers an unreliable, connectionless networklayer service.
 IP delivery model is often referred to as “besteffort” .
 Transmission Control Protocol (TCP) required to
provide end-to-end reliability.
3
Introduction(cont.)
 For non-real-time Internet traffic such as File
Transfer Protocol (FTP) data, the best-effort
delivery model of IP has not been a problem.
 Many real-time applications are delay sensitive
to the point where the best-effort delivery model
of IP can be inadequate.
 Quality of service (QoS) with regard to
bandwidth, packet delay, and loss through the
RSVP.
4
IETF integrated services
 In response to the growing demand for an
integrated services Internet, the Internet
Engineering Task Force (IETF) set up an
Integrated Services (intserv) Working Group .
 RSVP is one kind of QoS and the resource must
be reserved along with the transmission
schedling behavior.
 The Intserv architecture defines two major
classes of service:
Guaranteed service
Controlled-load service
5
Guaranteed service
Guaranteed Service provides an assured
level of bandwidth,a firm end-to-end delay
bound, and no queuing loss for conforming
packets of a data flow.
 It is intended for applications with
stringent real-time delivery requirements,
such as certain audio and video
applications.
The token bucket model
6
Guaranteed service(cont.)
 Leaky Bucket parameters (r,b)
 r :Token bucket rate
 b :Token bucket size
 Tspec:
 p : Peak data rate
 m :Minimum policed unit
 M :Maximum packet size
 Rspec:
 R: Reserved rate ( R>>r)
 S: slack term
(Signify the difference between the desired delay and the delay
obtained by using reservation level R)
7
Guaranteed service(cont.)
 Rspec: describes service requested from
network
controlled-load: none
guaranteed: delay target
 Tspec: describes flow’s traffic characteristics
average bandwidth + burstiness: token bucket filter
token rate r
bucket depth B
must have a token to send a byte
must have n tokens to send n bytes
start with no tokens
accumulate tokens at rate of r per second
can accumulate no more than B tokens
8
Guaranteed service(cont.)
 Simple Delay bound : b/R
Request guarantee transmission rate is R
The amount of traffic generated over interval t is
bounded by rt+b
The maximum queueing delay experienced by any
packet will be bound by b/R
 Multiplex Delay bound:b/R+C/R+D
The delay which depends on flow transmission rate
is C.
Non-rate-dependent delay is D
9
Controlled-load service
Provides approximately the same QoS
under heavy loads as under light loads.
Intended for applications that can tolerate
a certain amount of loss or delay to a
reasonable level.
Controlled-load service simply prioritizes
the packets in the flow, ensuring that they
do not wait too long in router queues as
they cross the network.
10
RSVP
 Resource ReSerVation Protocol.
 Allows applications running in hosts to reserve resources
in the Internet for their data flows.
 RSVP software must be present in the receivers, sender,
and routers.
 Two principle characteristics of RSVP
 It provides reservations for bandwidth in multicast
trees(unicast is handled as a special case).
 It is receiver-oriented.
 RSVP is not a routing protocol and sometimes referred
to as a signaling protocol that allows hosts to establish
and tear-down reservations for data flows.
11
RSVP(cont.)
 RSVP depends on an underlying routing
protocol(unicast or multicast) to determine the
routes for the flows.
 Operation
12
RSVP(cont.)
訊息種類
功能
PATH
從傳送端的電腦中傳送資料流資訊給接收端電腦。
RESV
從接收端電腦中傳送保留項目的請求,其中的內容包括了
頻寬大小、服務層級以及來源的IP位址
PATHErr
這是用來回應PATH訊息所產生的錯誤
RESVErr
這是用來回應RESV訊息所產生的錯誤
PATH-TEAR
沿著運作的路徑移除PATH的狀態。
RESV-TEAR
沿著運作的路徑移除保留項目
RESV-CONF
選項設定。假如接收端需要一個確認訊息,那麼傳送端就
會發出這個訊息給接收端
13
Path Message
 Originate at the senders and flow downstream
towards the receivers.
 The principle purpose of the path messages is to
let the routers know on which links they should
forward the reservation messages.
 Each Path message includes the following
information:
Phop
Sender Template
Sender Tspec
Adspec
14
Reservation styles and merging
 A reservation message specifies whether
merging of reservations from the same session
is permissible.
 A reservation style also specifies from which
senders in a session the receiver desires to
receive data.
 There are currently three reservation styles
 Fixed-filter style(FF)
 Wildcard-filter style(WF)
 Shared-explicit style(SE)
15
Fixed-filter style(FF)
 It specifies a list of senders from which it wants to
receive a data flow along with a single bandwidth
reservation. These reservation are distinct, i.e., they are
not to be shared.
16
Wildcard-filter style(WF)
 It is telling the network that it wants to receive all flows
from all upstream senders in the session and that its
bandwidth reservation is to be shared among the
senders.
17
Shared-explicit style(SE)
 It specifies a list of senders from which it wants to
receive a data flow along with a single bandwidth
reservation. This reservation is to be shared among all
the senders in the list.
18
19
Slack Term
 Slack Term which S(ms) as well as the amount
of bandwidth, R to be installed in each router
along the path.
 S represents the amount by which the end-toend delay bound .
20
Slack Term(cont.)
 R3 can only reserve a value of 2Mb/s which if used
as the new reservation value in the propagated Resv
message will cause an increase in the end to end
delay bound di.
 The request can be accepted and a reservation of
2Mb/s installed in R3.(R=2Mb/s, S2=S1-di)
 R2 and R1 also reserving 2Mb/s.
21
Summary
 In this tutorial we have looked at the controlledload and guaranteed service classes that can
provide end applications with enhanced QoS
commitments over conventional best-effort
delivery.
 RSVP can be used by end applications to select
and invoke the appropriate class and QoS level.
22