Protocols with QoS Support 29/9 - 2003 INF5070 – Media Storage and Distribution Systems:
-
Upload
albert-simcoe -
Category
Documents
-
view
212 -
download
0
Transcript of Protocols with QoS Support 29/9 - 2003 INF5070 – Media Storage and Distribution Systems:
Protocols Protocols with QoS Supportwith QoS Support
29/9 - 2003
INF5070 – Media Storage and Distribution Systems:
2003 Carsten Griwodz & Pål Halvorsen
INF5070 – media storage and distribution systems
Overview Quality-of-Service
Resource reservation
Protocols: IPv4 IPv6 Tenet ATM IntServ RSVP DiffServ MPLS …
Quality-of-Service
2003 Carsten Griwodz & Pål Halvorsen
INF5070 – media storage and distribution systems
Quality–of–Service (QoS) – I
Many definitions, e.g.:
“QoS represents the set of those quantitative and qualitative characteristics of a distributed multimedia system that are necessary to achieve the required functionality of an application” Vogel et. al.: “Distributed Multimedia and QoS: A Survey”, IEEE Multimedia 1995
2003 Carsten Griwodz & Pål Halvorsen
INF5070 – media storage and distribution systems
Quality–of–Service (QoS) – II Different semantics or classes of QoS:
determines reliability of offered service utilization of resources
max
reserved A
reserved B
time
reso
urc
es
unusedavailable resources
reserved C
2003 Carsten Griwodz & Pål Halvorsen
INF5070 – media storage and distribution systems
Quality–of–Service (QoS) – IIIBest effort QoS:
system tries its best to give a good performance no QoS calculation (could be called no effort QoS)
simple – do nothing
QoS may be violated unreliable service
Deterministic guaranteed QoS: hard bounds QoS calculation based on upper bounds (worst case) premium better name!!??
QoS is satisfied even in the worst case high reliability
over-reservation of resources poor utilization and unnecessary service rejects
QoS values may be less than calculated hard upper bound
2003 Carsten Griwodz & Pål Halvorsen
INF5070 – media storage and distribution systems
Quality–of–Service (QoS) – IV Statistical guaranteed QoS:
QoS values are statistical expressions (served with some probability) QoS calculation based on average (or some other statistic or stochastic value)
resource capabilities can be statistically multiplexed more granted requests
QoS may be temporarily violated service not always 100 % reliable
Predictive QoS: weak bounds QoS calculation based previous behavior of imposed workload
resource capabilities can be statistically multiplexed more granted requests possibly more exact workload description (if past and actual behavior
matches)
QoS may be temporarily violated service not 100 % reliable QoS values may be less than calculated hard upper bound
Resource Reservation
2003 Carsten Griwodz & Pål Halvorsen
INF5070 – media storage and distribution systems
Resource Reservation – I Reservations is fundamental for reliable enforcement of
QoS guarantees per-resource data structure (information about all usage) QoS calculations and resource scheduling may be done based
on the resource usage pattern
reservation protocols negotiate desired QoS by transferring information about resource
requirements and resource usage between the end-systems and the intermediate systems participating in the data transfer
reservation operationo calculate necessary amount of resources based on the QoS
specificationso reserve resources according to the calculation (or reject request)
resource scheduling enforce resource usage with respect to resource administration
decisions
2003 Carsten Griwodz & Pål Halvorsen
INF5070 – media storage and distribution systems
Resource Management Phasesuser’s QoS
requirementstim
e Phase 1:
Phase 2:
Phase 3:
admission test and calculation of QoS guarantees
rejection or renegotiation
resource reservation QoS guarantees to user
negotiation
data transmission QoS enforcement by proper scheduling
monitoring and adaptation “notification”
renegotiation
enforcement
specification
confirmation
renegotiation
stream termination resource deallocation termination
not necessary an own phase, some protocols start sending at once
2003 Carsten Griwodz & Pål Halvorsen
INF5070 – media storage and distribution systems
Reservation Directions Sender oriented:
sender (initiates reservation) must know target addresses
(participants) in-scalable good security
1. reserve
2. reserve
3. reserve
receiver
sender
data flow
2003 Carsten Griwodz & Pål Halvorsen
INF5070 – media storage and distribution systems
Reservation Directions Receiver oriented:
receiver (initiates reservation) needs advertisement before
reservation must know “flow” addresses
sender need not to know receivers more scalable in-secure 1. reserve
2. reserve
3. reserve
receiver
sender
data flow
2003 Carsten Griwodz & Pål Halvorsen
INF5070 – media storage and distribution systems
Reservation Directions Combination:
start sender oriented reservation
additional receivers join at routers(receiver based)
receiver
sender
data flow
reserve from nearest router
1. reserve
2. reserve
3. reserve
Routing
2003 Carsten Griwodz & Pål Halvorsen
INF5070 – media storage and distribution systems
Routing
physicallink
network
applicationtransport
2003 Carsten Griwodz & Pål Halvorsen
INF5070 – media storage and distribution systems
Routing
216.239.51.101
129.42.16.99
80.91.34.111
129.240.148.31
129.240.148.31
66.77.74.20
209.73.164.90
192.67.198.54
209.189.226.17
193.99.144.71
81.93.162.20
2003 Carsten Griwodz & Pål Halvorsen
INF5070 – media storage and distribution systems
Routing
216.239.51.101
129.42.16.99 80.91.34.111
129.240.148.31
129.240.148.31
66.77.74.20
209.73.164.90192.67.198.54
209.189.226.17
193.99.144.71
81.93.162.20
… - …216.239.51.101 - IF1209.189.226.17 - IF280.91.34.111 - IF3209.189.226.* - 209.189.226.17129.240.* - 80.91.34.11181.93.* - 80.91.34.111192.67.* - 80.91.34.111209.73.* - 80.91.34.111129.240.148.* - 80.91.34.111193.99.* - 80.91.34.11166.77.74.20 - 80.91.34.111… - …
2003 Carsten Griwodz & Pål Halvorsen
INF5070 – media storage and distribution systems
Routing
216.239.51.101
129.42.16.99 80.91.34.111
129.240.148.31
129.240.148.31
66.77.74.20
209.73.164.90192.67.198.54
209.189.226.17
193.99.144.71
81.93.162.20
Protocols
2003 Carsten Griwodz & Pål Halvorsen
INF5070 – media storage and distribution systems
Internet Protocol version 4 (IPv4) – I
IP is THETHE network layer protocol within the Internet IPv4
defined by RFC 791 (1981) – STD 5 unreliable datagram service (neither flow nor error
control) no fixed routes
flexibility for path selection reordering problems not suitable for time critical continuous media data but, source routing is optional
o loose – specify some router IP addresses to be passed in order o strict – specify all routers to be passed in order
maximum 64 KB datagrams including headers segmentation for smaller subnets (e.g., 1500 B for standard
Ethernet) reassembly in end-system’s IP-layer
2003 Carsten Griwodz & Pål Halvorsen
INF5070 – media storage and distribution systems
Internet Protocol version 4 (IPv4) – II
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Version| IHL |Type of Service| Total Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Identification |Flags| Fragment Offset | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Time to Live | Protocol | Header Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Options | Padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
indicates the format of the internet header, i.e., version 4
length of the internet header in 32 bit words, and thus points to the beginning of the data (minimum value of 5)
indication of the abstract parameters of thequality of service desired – somehow treathigh precedence traffic as more important – tradeoff between low-delay, high-reliability, andhigh-throughput – NOT used, bits now reused
datagram length(octets) includingheader and data - allows the lengthof 65,535 octets
identifying value to aid assembly of fragments
fragments allowed flag allowed and last fragment flag
indicate where this fragment belongs in datagram
checksum on the header only – TCP, UDP over payload. Since some header fields change(TTL), this is recomputed and verified at each point
indicates used transport layer protocol
disable a packet to circulate forever,decrease value by at least 1 in each node – discarded if 0
32-bit address fields. May be configured differently from small to large networks
options may extend the header. If the options do not end on a 32-bit boundary, the remaining fields are padded in the padding field (0’s)
2003 Carsten Griwodz & Pål Halvorsen
INF5070 – media storage and distribution systems
128-bit address fields
disable a packet to circulate forever, decrease value by at least 1 in each node – discarded if 0
length of payload in bytes.If zero, indicates that the payload length is carried in a Jumbo Payload option.
Identifies the type of headerimmediately following theheader – e.g., TCP, UDP, butalso EXTENSION headers
version of protocol, i.e., version 6
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Version| Prio. | Flow Label | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Payload Length | Next Header | Hop Limit | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Source Address + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Destination Address + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Internet Protocol version 6 (IPv6) – I
IPv6 defined by RFC 1883 (1995), but
revised by RFC 2460 (1998) simplified header:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Version| Traffic Class | Flow Label | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Payload Length | Next Header | Hop Limit | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Source Address + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Destination Address + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
the 4-bit priority field hasbeen replaced by an 8-bit traffic class field. To identify and distinguish between different classes or priorities
label packets which requests special handling by the IPv6 routers, such as non-default quality of service or real-time
2003 Carsten Griwodz & Pål Halvorsen
INF5070 – media storage and distribution systems
Internet Protocol version 6 (IPv6) – II
IPv6 enlarged address space (2128 = 3.4 x 1038 addresses)
simplified headers reduce packet processing time
“jumbograms” allows packets larger than 64 KB (using a extension header)
strict routing (source can fix route to destination using a routing extension header)
inclusion of security concepts and mobile end-systems
may specify only a geographical range for a multicast session
some support for QoS concepts – each packet header includes ...
... a 8-bit traffic class field – defined by DiffServ ... a 20-bit flow label
2003 Carsten Griwodz & Pål Halvorsen
INF5070 – media storage and distribution systems
Internet Protocol version 6 (IPv6) – IV
Flow labels “a flow is a sequence of packets sent from the source to the
destination for which the source desires special handling by the routers”
each flow must have same flow label, priority and addresses flow = pseudo-connection
before start or during transmissiono set up flow between source and destinationo route is cached – table entries in a router allows fast packet switchingo routers can reserve resources
during data transmissiono routers can identify flows by a unique “flow label/address” combinationo routers can treat packets according to the flow type
still experimental use
BUT;BUT; IPv6 itself does not define mechanisms for IPv6 itself does not define mechanisms for QoS treatment – must use additional protocolsQoS treatment – must use additional protocols
2003 Carsten Griwodz & Pål Halvorsen
INF5070 – media storage and distribution systems
IP Multicast Limiting IP multicast geographically
IPv4 – interpretation of TTL header field is used(non-standardized MBONE use)
IPv6 – multicast address contains a 4-bit scope field possible geographical limits
machine LAN organization country (v4 only) continent (v4 only) global – no limit
2003 Carsten Griwodz & Pål Halvorsen
INF5070 – media storage and distribution systems
Tenet – I
Late 80’s/early 90’s, Tenet group at Berkeley
Aims for network support for real-time continuous media applications
Real-time communication model
Real-time channels: end-to-end connection with performance guarantees and traffic restrictions associated with a set of nodes and links (a route) through which
real-time packets pass resource reservation in route nodes admission control
2003 Carsten Griwodz & Pål Halvorsen
INF5070 – media storage and distribution systems
Tenet – II Traffic specification:
expressing peak and average load on the network indication of the burstiness of the load parameters:
minimum packet inter-arrival time average packet inter-arrival time averaging interval maximum packet size
Supported QoS parameters (by which users describe their requirements): upper bound on end-to-end message delay delay violation probability bound buffer overflow probability bound delay jitter bound (optional) a throughput guarantee is obtained from the traffic specification
2003 Carsten Griwodz & Pål Halvorsen
INF5070 – media storage and distribution systems
Tenet – III Protocol suite:
Real-time Channel Administration Protocol (RCAP) performs channel setup uses the traffic description and performance requirement
to find a route and maps the global requirement onto local resources
performs admission control and reservations on the way
Real-time Message Transport Protocol (RMTP) intended for message based real-time transport
Continuous Media Transport Protocol (CMTP) offers a stream based interface and a time-driven
mechanism for audio and video – may demand data from application
Real-time Internet Protocol (RTIP) replaces IP schedules packets according to resource reservations made by RCAP
applicationapplication
physical layerphysical layer
data link layerdata link layer
real-timeinternet protocol
real-timeinternet protocol
real-time messagetransport protocol
real-time messagetransport protocol
continuous mediatransport protocol
continuous mediatransport protocol
real-time channeladministration protocol
real-time channeladministration protocol
2003 Carsten Griwodz & Pål Halvorsen
INF5070 – media storage and distribution systems
Defined by ATM Forum and International Telecommunication Union (ITU)
Targeted for all kinds of traffic within the same network (i.e., both continuous and discrete data types)
A full suite of protocols: physical layer – deals with voltages, bit timing
and framing on the physical medium ATM layer – defines the ATM cell structure adaptation layer – analogous to the Internet
transport layer supporting different services
Today: “IP-over-ATM” IP rules – TCP/IP is used in every end-system
ATM used as link-layer technology however, ATM may forward data quickly ATM may be used in the Internet backbone running under IP uses AAL5 to transport IP datagrams over the ATM network
Asynchronous Transfer Mode (ATM) – I
ATM physical layerATM physical layer
ATM layerATM layer
ATM adaptation layer (AAL)ATM adaptation layer (AAL)
2003 Carsten Griwodz & Pål Halvorsen
INF5070 – media storage and distribution systems
Asynchronous Transfer Mode (ATM) – II Service classes
constant bit rate (CBR)(real-time, guaranteed constant rate)
variable bit rate (VBR) – real-time and non-real-time available bit rate (ABR)
(slightly better than best effort – a minimum guarantee, only class with congestion control)
unspecified bit rate (UBR)(best effort, no guarantees)
Virtual channels (VC) the ATM network sets up a VC between sender and receiver a path consisting of a sequence of links each link has a virtual circuit identifier (VCI) used for routing
(included in the cell header) ATM backbones usually use permanent VCs, i.e., saving VC
setup and teardown Virtual paths
2003 Carsten Griwodz & Pål Halvorsen
INF5070 – media storage and distribution systems
Asynchronous Transfer Mode (ATM) – III The ATM standard specifies a number of QoS parameters
traffic generation by sender: cell rate (sustainable (SCR) / peak (PCR) / minimum (MCR)) maximum burst size (MBS) cell delay variation tolerance (CDVT)
service provided by network: cell transfer delay (CTD) –
cell transit time from source to destination cell delay variation (CDV) –
variance in transfer delays
cell loss ratio (CLR) – fraction of cells lost or delivered too late
cell error rate (CER) – fraction of cells with bit errors
severly-errored cell block ratio (SECBR) – fraction of an N-cell block with M or more cells damaged
cell misinsertion rate (CMR) – number of cells delivered to wrong destination
cannot benegotiated – part of network QoS offer
2003 Carsten Griwodz & Pål Halvorsen
INF5070 – media storage and distribution systems
Asynchronous Transfer Mode (ATM) – VI
Traffic contracts
the VC acts like a contract between customer and network for a service
consist of a connection traffic descriptor and a set of QoS parameters
which traffic to be offered which service class compliance requirements
the QoS parameters are negotiated during the VC setup (can be specified either explicitly or implicitly)
2003 Carsten Griwodz & Pål Halvorsen
INF5070 – media storage and distribution systems
Asynchronous Transfer Mode (ATM) – V
Different service categories require different parameters
Traffic description
Min lossguarantee
(CLR)
Delay/variance
guarantee (CDV)
Bandwidth guarantee
Feedback control
CBR PCR + + + -rt-VBR PCR, SCR,
MBS + + + -nrt-VBR PCR, SCR,
MBS + - + -ABR PCR, MCR + - + +UBR PCR - - - -
2003 Carsten Griwodz & Pål Halvorsen
INF5070 – media storage and distribution systems
Asynchronous Transfer Mode (ATM) – VI Application areas for ATM service categories (by ATM Forum)
CBR rt-VBR nrt-VBR ABR UBR
critical data 2 1 3 1 n/s
ISDN – video conference 3 ? ? n/s n/s
compressed audio 1 3 2 2 1
video distribution 3 2 1 n/s n/s
interactive multimedia 3 3 2 2 1
3 – good2 – fair1 – not good, not applicable with advantagen/s – not suitable
may be more useful now!!??
2003 Carsten Griwodz & Pål Halvorsen
INF5070 – media storage and distribution systems
Integrated Services (IntServ) – I Framework by IETF to provide individualized
QoS guarantees to individual application sessions
Goals: efficient Internet support for applications which require service
guarantees fulfill demands of multipoint, real-time applications (like video
conferences) do not introduce new data transfer protocols
In the Internet, it is based on IP (v4 or v6) and RSVP (described later)
Two key features reserved resources – the routers need to know what resources are
available (both free and reserved) call setup (admission call) – reserve resources on the whole path from
source to destination
2003 Carsten Griwodz & Pål Halvorsen
INF5070 – media storage and distribution systems
Integrated Services (IntServ) – II Admission call:
traffic characterization and specification one must specify the traffic one will
transmit on the network (Tspec) one must specify the requested QoS
(Rspec – reservation specification)
signaling for setup send the Tspec and Rspec to all routers
per-element admission test each router checks whether the requests
specified in the R/Tspecs can be fulfilled if YES, accept; reject otherwise
1. request: specify traffic (Tspec), guarantee (Rspec)
1
2
32. consider request against available resources
3. accept or reject
receiver
sender
2003 Carsten Griwodz & Pål Halvorsen
INF5070 – media storage and distribution systems
Integrated Services (IntServ) – III IntServ introduce two new services enhancing the
Internet’s traditional best effort:
guaranteed service guaranteed bounds on delay and bandwidth for applications with real-time requirements
controlled-load service “a QoS closely to the QoS the same flow would receive from an
unloaded network element” [RFC 2212], i.e., similar to best-effort in networks with limited load
no quantified guarantees, but packets should arrive with “a very high percentage”
for applications that can adapt to moderate losses, e.g., real-time multimedia applications
2003 Carsten Griwodz & Pål Halvorsen
INF5070 – media storage and distribution systems
Both service classes uses token bucket to police a packet flow: packets need a token to be forwarded
each router has a b-sized bucket with tokens:if bucket is empty, one must wait
new tokens are generated at a rate r and added:if bucket is full (little traffic), the token is deleted
the token generation rate r serves to limit the long term average rate
the bucket size b serves to limit themaximum burst size
Integrated Services (IntServ) – IV
token wait queue
bucket
token generation
2003 Carsten Griwodz & Pål Halvorsen
INF5070 – media storage and distribution systems
Integrated Services (IntServ) – V Usual protocol structure:
applicationapplication
data linkdata link
IPIP
UDPUDP RSVPRSVP
RTPRTP
2003 Carsten Griwodz & Pål Halvorsen
INF5070 – media storage and distribution systems
Resource Reservation Protocol (RSVP) - I
Defined by RFC 2205 (1997)
A protocol to signal reservations of resources in the Internet contains protocol elements for control no support for data transfers (reservation signals only) simplex protocol, i.e., makes reservations for unidirectional flows receiver-oriented, i.e., the receiver initiates and maintains resource
reservations maintains a “soft” state – graceful changes to dynamic
memberships and automatic adaptation to route changes (timeouts)
companion protocol to IP – supports both IPv4 and IPv6 transported as raw IP datagram with protocol number 46 filtering provides support for heterogeneous receivers and different
reservation styles
2003 Carsten Griwodz & Pål Halvorsen
INF5070 – media storage and distribution systems
RSVP will generally require raw network I/O sends raw IP datagrams using
protocol 46
operates on top of IP, i.e., takes the place of the transport protocol
does not perform traditional transport layer services – must add a transport protocol (UDP)
Resource Reservation Protocol (RSVP) - II
applicationapplication
data linkdata link
IPIP
UDP UDP RSVPRSVP
2003 Carsten Griwodz & Pål Halvorsen
INF5070 – media storage and distribution systems
same multicast group and port
Sessions a data flow with particular destination and transport protocol defined by (destination address, protocol ID)
IP address IP protocol ID
may carry multiple data flows Data flows are distinguished by
source IP address and source port (IPv4) source IP address and flow label (IPv6)
Transmission model:
Resource Reservation Protocol (RSVP) - III
2003 Carsten Griwodz & Pål Halvorsen
INF5070 – media storage and distribution systems
Resource Reservation Protocol (RSVP) - IV
Two fundamental messages: PATH:
sender sends a PATH message downstream following the data path sent using same source and destination addresses includes:
o hop-addresseso sender template (describes data packet format)o sender Tspec (traffic characteristics generated by sender)o sender Adspec (advertisement information)o ...
RESV: receiver sends a RESV message upstream using the path described
in the PATH message sent to previous hop only includes:
o flowspec: reservation requests, desired QoS (e.g., RFC 1363)o filterspec: reservation styleo reverse data paths for the flowo ...
flow descriptor
2003 Carsten Griwodz & Pål Halvorsen
INF5070 – media storage and distribution systems
Creating and maintaining a reservation state: the SOURCE
multicasts data flows sends PATH messages with traffic
characteristics (Tspec) describing flows the RECEIVER
joins multicast group receives the PATH message determines own QoS requirements based the PATH Tspec sends a RESV message with request and filters
the ROUTERS reserve according to incoming flowspecs downstream merge and forward the RESV messages to next node using largest
flowspec
the reservations are maintained using “soft” states the reservation has an associated timer – a timeout removes the
reservation periodically refreshed by PATH and RESV messages
Resource Reservation Protocol (RSVP) - V
2003 Carsten Griwodz & Pål Halvorsen
INF5070 – media storage and distribution systems
Resource Reservation Protocol (RSVP) - VI
3 Mbps
5 Kbps
1 Mbps10 Mbps
1 Mbps
PATH PATH PATH
PATHPATH
PATH
PATH
PATH
PATH
PATH
RESV5 Kbps
reserved 5 Kbps
RESV1 Mbps
reserved 1 Mbps
RESV1 Mbps
rese
rved
1 M
bps
merging
RESV10 Mbps
reserved 10 Mbps
merging
RESV10 Mbps
rese
rved
10
Mbp
s
RESV3 Mbps
rese
rved
3 M
bps
RESV3 Mbps
rese
rved
3 M
bps
RESV1 Mbps
rese
rved
1 M
bps
mergingRESV
3 Mbps
reserved 3 Mbps
merging
RESV10 Mbps
rese
rved
10
Mbp
s
2003 Carsten Griwodz & Pål Halvorsen
INF5070 – media storage and distribution systems
Resource Reservation Protocol (RSVP) - VII
RSVP in hosts and routers:1. RESV with flowspec and filterspec to RSVP daemon2. policy control to check privileges etc.3. admission control using flowspec4. forward RESV message5. control of local modules: classifier and scheduler
applicationprocess
RSVPdaemon
policycontrol
admissioncontrol
routingprocess
RSVPdaemon
policycontrol
admissioncontrol
packetclassifier
packetscheduler
packetclassifier
packetschedulerdata
2003 Carsten Griwodz & Pål Halvorsen
INF5070 – media storage and distribution systems
Resource Reservation Protocol (RSVP) - VIII
Reservation styles a reservation request includes a set of options called
the reservation style
shared vs. distinct reservations concerns treatment of reservations of different senders shared – single reservation for all senders (e.g., video conference
audio) distinct – one reservation per sender (e.g., video conference
video)
explicit vs. wildcard concerns selection of senders explicit – specify senders (e.g., teleteaching) wildcard – automatically select all senders (e.g., video
conference)
2003 Carsten Griwodz & Pål Halvorsen
INF5070 – media storage and distribution systems
Resource Reservation Protocol (RSVP) - IX
distinctreservation
sharedreservation
explicitsender
selection
Fixed:distinct reservation (not shared) for each sender
Shared-explicit:single reservation shared by a specified list of senders
wildcardsender
selectionundefined
Wildcard:single reservation shared by flows form all senders
2003 Carsten Griwodz & Pål Halvorsen
INF5070 – media storage and distribution systems
Resource Reservation Protocol (RSVP) - X
The RSVP standard [RFC 2205] allows to reserve link bandwidth – it does NOT...NOT...:
...define how the network should provide the reserved bandwidth to the data flows – the routers must implement these mechanisms themselves
...specify how to do resource provisioning – which must likely be done using a proper scheduling mechanism
...determine the route – it is not a routing protocol, but relies on others
...determine which data to drop in case of overflow, i.e., the most important data may be lost
...perform an admission test, but it assumes that the routers perform admission control
THUS; RSVP can only be used as a small piece in THUS; RSVP can only be used as a small piece in the the QoS guarantee puzzleQoS guarantee puzzle Kurose, J. F., Ross, K. W.: “Computer Networking: A Top-Down Approach Featuring the Internet”, 2nd edition, Addison Wesley, 2002
2003 Carsten Griwodz & Pål Halvorsen
INF5070 – media storage and distribution systems
Differentiated Services (DiffServ) – I
IntServ and RSVP provide a framework for per-flow QoS, but they … … give complex routers
much information to handle … have scalability problems
set up and maintain per-flow state information periodically PATH and RESV messages overhead
… specify only a predefined set of services new applications may require other flexible services
DiffServ [RFC 2475] tries to be both scalable and flexible
2003 Carsten Griwodz & Pål Halvorsen
INF5070 – media storage and distribution systems
Differentiated Services (DiffServ) – II
ISP favor DiffServ Basic idea
multicast is not necessary
make the core network simple due to many users implement more complex control operations at the edge aggregation of flows –
reservations for a group of flows, not per flow thus, avoid scalability problems on routers with many
flows
do not specify services or service classes instead, provide the functional components on which
services can be built thus, support flexible services
2003 Carsten Griwodz & Pål Halvorsen
INF5070 – media storage and distribution systems
Differentiated Services (DiffServ) – III
Two set of functional elements: edge functions: packet classification and traffic conditioning core function: packet forwarding
At the edge routers, the packets are tagged with a DS-mark (differentiated service mark) uses the type of service field (IPv4) or the traffic class field
(IPv6) different service classes (DS-marks) receive different service subsequent routers treat the packet according to the DS-mark classification:
incoming packet is classified (and steered to the appropriate marker function) using the header fields
the DS-mark is set by marker once marked, forward classifier marker
forward
2003 Carsten Griwodz & Pål Halvorsen
INF5070 – media storage and distribution systems
Differentiated Services (DiffServ) – IV
Note, however, that there is no “rules” for classification – it is up to the network provider
A metric function may be used to limit the packet rate: the traffic profile may define rate and maximum bursts if packets arrive too fast, the metric function assigns another marker
function telling the router to delay or drop the packet
classifier markerforward
shaper /dropper
2003 Carsten Griwodz & Pål Halvorsen
INF5070 – media storage and distribution systems
Differentiated Services (DiffServ) – V
In the core routers, a DS-marked packet is forwarded according to a per-hop behavior (PHB) associated with the DS-tag the PHB determines how the router resources are used and shared
among the competing service classes the PHB should be based on the DS-tag only – simple forwarding
decisions, no need for QoS-states for each source-destination pair packets with same DS-tag are treated equally – regardless of
source or destination (traffic aggregating)
a PHB can result in different service classes receiving different performance
performance differences must be observable and measurable to be able to monitor the system performance
no specific mechanism for achieving these behaviors are specified- any mechanism can by used as long as the performance specification is met
2003 Carsten Griwodz & Pål Halvorsen
INF5070 – media storage and distribution systems
Differentiated Services (DiffServ) – VI
Currently, two PHBs are under active discussion
expedited forwarding [RFC 3246] specifies a minimum departure rate of a class, i.e., a guaranteed
bandwidth the guarantee is independent of other classes, i.e., enough
resources must be available regardless of competing traffic
assured forwarding [RFC 2597] divide traffic into four classes each class is guaranteed a minimum amount of resources each class are further partitioned into one of three “drop”
categories(if congestion occur, the router drops packets based on “drop” value)
2003 Carsten Griwodz & Pål Halvorsen
INF5070 – media storage and distribution systems
core routers
Differentiated Services (DiffServ) – VII
Edge router:use header fields to lookup right DS-tag and mark packet
Core router:use PHB according to DS-tag to forward packet
fast and scalable due to simple core routers
2003 Carsten Griwodz & Pål Halvorsen
INF5070 – media storage and distribution systems
Internet Streaming Protocol, Version 2 (ST-II) – I
ST-II is defined by RFC 1190/1819 It is a connection-oriented supplement to IP
with two components: ST: reservations and data management SCMP (ST control message protocol): reliable
control messages
Main concepts: unreliable data transfers, reliable control a negotiated packet size (no fragmentation and reassembly) routing tree from sender to multiple receivers flow specification describing QoS parameters during connection
setup
applicationapplication
linklink
transporttransport
ST-II ST-II SCMPSCMP
2003 Carsten Griwodz & Pål Halvorsen
INF5070 – media storage and distribution systems
Internet Streaming Protocol, Version 2 (ST-II) – II
The resource reservation is sender-oriented SCMP sends a message with a flow specification if the routers and the destination accepts the call, the call is
returned (possibly modified) to the source typical parameters include
bandwidth delay delay variance size
Max delay
12
Min delay
2
size 4096
Max delay
12
Min delay
5
size 2048
Max delay
12
Min delay
9
size 2048
connect connect
accept/reject
Fast Routing
2003 Carsten Griwodz & Pål Halvorsen
INF5070 – media storage and distribution systems
Routing Speed-up ATM
Virtual Channels and Virtual Path RSVP
IP and Port Mapping ST-II
Hop ID MPLS
Label
2003 Carsten Griwodz & Pål Halvorsen
INF5070 – media storage and distribution systems
Multiprotocol Label Switching (MPLS)
Multiprotocol Label Switching Separate path determination from hop-by-hop
forwarding Forwarding is based on labels Path is determined by choosing labels
Distribution of labels On application-demand
LDP – label distribution protocol By traffic engineering decision
RSVP-TE – traffic engineering extensions to RSVP
2003 Carsten Griwodz & Pål Halvorsen
INF5070 – media storage and distribution systems
Multiprotocol Label Switching (MPLS)
MPLS works above multiple link layer protocols
Carrying the label Over ATM
Virtual path identifier or Virtual channel identifier Maybe shim
Frame Relay data link connection identifier (DLCI) Maybe shim
Ethernet, TokenRing, … Shim
Shim?
2003 Carsten Griwodz & Pål Halvorsen
INF5070 – media storage and distribution systems
Link Layer HeaderShim
Multiprotocol Label Switching (MPLS)
Shim: the label itself
Network Layer Header …
Shim
20 bitslabel
3 bitsexperimental
1 bitBottom of stack
8 bits TTL
2003 Carsten Griwodz & Pål Halvorsen
INF5070 – media storage and distribution systems
Routing using MPLS
216.239.51.101
129.42.16.99 80.91.34.111
129.240.148.31
129.240.148.31
66.77.74.20
209.73.164.90192.67.198.54
209.189.226.17
193.99.144.71
81.93.162.20
…
Label 12 –
IF 1
Label 27 –
IF 2
…
Added label
Remove label
Reserved path for this label
2003 Carsten Griwodz & Pål Halvorsen
INF5070 – media storage and distribution systems
MPLS Label Stack
ISP 1ISP 1
ISP 2ISP 2
ISP 3
The ISP 1 Classifies the packet Assigns it to a reservation Performs traffic shaping Adds a label to the packet
for routers in his net
The ISP 1 Buys resources from ISP 2The ISP 2 Repeats classifying, assignment,
shaping Adds a label for the routers in his net He pushes a label on the label
stack
2003 Carsten Griwodz & Pål Halvorsen
INF5070 – media storage and distribution systems
MPLS Label Stack
ISP 1ISP 1
ISP 2ISP 2
ISP 3
The End:Summary
2003 Carsten Griwodz & Pål Halvorsen
INF5070 – media storage and distribution systems
Summary Timely access to resources is important for multimedia
application to guarantee QoS – reservation might be necessary
Many protocols have tried to introduce QoS into the Internet, but no protocol has yet won the battle... often NOT only technological problems, e.g.,
scalability flexibility ...
but also economical and legacy reasons, e.g., IP rules – everything must use IP to be useful several administrative domains (how to make ISPs agree) router manufacturers will not take the high costs (in amount of
resources) for per-flow reservations pricing ...
2003 Carsten Griwodz & Pål Halvorsen
INF5070 – media storage and distribution systems
Some References1. ATM Forum, http://www.atmforum.com2. ATM Forum: “ATM Service Categories”, http://www.atmforum.com/aboutatm/6.html3. Danthine, A., Bonaventure, O.: “From Best Effort to Enhanced QoS”,
in: Spaniol, O., Danthine, A., Effelsberg, W. (Eds.): “Architecture and Protocols for High-Speed Networks”, Kluwer Achademic Publishers, 1994, pp. 179-201
4. Kurose, J. F., Ross, K. W.: “Computer Networking: A Top-Down Approach Featuring the Internet”, 2nd edition, Addison Wesley, 2002
5. Steinmetz, R., Nahrstedt, C.: “Multimedia: Computing, Communications & Applications”, Prentice Hall, 1995
6. Tenet group: http://tenet.berkeley.edu/tenet.html
The RFC repository maintained by the IETF Secretariat can be found at http://www.ietf.org/rfc.htmlThe following RFCs might be interesting with respect to this lecture:
RFC 791: Internet Protocol RFC 1883: Internet Protocol, Version 6 (IPv6) RFC 2460: Internet Protocol, Version 6 (IPv6), Obsoletes: 1883 RFC 2212: Specification of Guaranteed Quality of Service RFC 2205: Resource ReSerVation Protocol (RSVP) RFC 1363: A Proposed Flow Specification RFC 2475: An Architecture for Differentiated Services RFC 3246: An Expedited Forwarding PHB (Per-Hop Behavior) RFC 2597: Assured Forwarding PHB Group RFC 1190: Experimental Internet Stream Protocol, Version 2 (ST-II) RFC 1819: Internet Stream Protocol Version 2 (ST2): Protocol Specification - Version
ST2+